Package Details: jabref 5.15-2

Git Clone URL: https://aur.archlinux.org/jabref.git (read-only, click to copy)
Package Base: jabref
Description: Graphical Java application for managing BibTeX and biblatex (.bib) databases
Upstream URL: https://www.jabref.org/
Licenses: MIT
Submitter: Allan
Maintainer: Bevan
Last Packager: Bevan
Votes: 213
Popularity: 0.21
First Submitted: 2012-06-07 22:47 (UTC)
Last Updated: 2024-09-23 19:59 (UTC)

Dependencies (4)

Required by (0)

Sources (7)

Pinned Comments

Bevan commented on 2024-03-28 17:57 (UTC)

Everyone who struggles to update right now: Please install the jdk21-openjdk package. It provides java-environment=21.

Bevan commented on 2022-03-14 20:04 (UTC)

@shmilee: I like that idea. Implemented in 5.5-2 using JABREF_OPTIONS as variable name.

Note that you can then also put that environment variable into your .bashrc, .pam_environment or something similar to be automatically applied.

shmilee commented on 2022-03-12 13:51 (UTC)

How about add an extra JavaOptions variable in launch script /usr/bin/jabref like this?

............
--module-path ${ROOT}/lib \
${JABREF_EXT_Options} \
--patch-module .............

So we can add the -Djdk.gtk.version=2 flag or -Dglass.gtk.uiScale=144dpi flag by cmdline, no need to edit /usr/bin/jabref after upgrade.

JABREF_EXT_Options='-Dglass.gtk.uiScale=144dpi -Djdk.gtk.version=2' jabref

matteodelabre commented on 2020-11-17 14:25 (UTC)

Using JabRef with i3wm, I’m running into the issue described at https://github.com/JabRef/jabref/issues/5867 in which clicking the menu bar sometimes opens then immediately closes the associated menu, rendering it unusable.

I was able to fix this issue by adding the -Djdk.gtk.version=2 flag after line 9 in https://aur.archlinux.org/cgit/aur.git/tree/jabref.sh?h=jabref (as suggested in the related bug report https://bugs.openjdk.java.net/browse/JDK-8251240). This change also removes the “XSetErrorHandler() called with a GDK error trap pushed. Don't do that.” warning mentioned by ruiin in a previous comment.

So far, I have not encountered any adverse side-effect from this workaround.

Latest Comments

« First ‹ Previous 1 .. 13 14 15 16 17 18 19 20 21 Next › Last »

Ogion commented on 2017-10-07 13:53 (UTC)

The aur Package from your github link works just fine for me, except for one thing: I had to install `java-openjfx` from the repo, before JabRef would actually run. You should probably add that to the Depends.

Zebra commented on 2017-10-07 10:44 (UTC)

Bevan: I testet your package just now (4.0.1) and cannot reproduce your issues. Stops at once. start up time is 3.5 seconds max.

Bevan commented on 2017-10-04 16:51 (UTC) (edited on 2017-10-07 14:40 (UTC) by Bevan)

I have an update for JabRef 4.0 but I have serious issues with this version: * JabRef does not quit, it stays active after exit waiting for some futex. * On one machine JabRef needs many minutes to start, checking for duplicate aliases If you want to try the new package, you can get it from here: https://github.com/michaellass/AUR/tree/jabref-4/jabref I will only push it to the AUR as soon as those major issues are solved. Update: Problem no. 1 is now solved in git, problem no. 2 was a local issue with leftover data from older JabRef versions.

Bevan commented on 2017-08-24 08:14 (UTC)

koppor: Thanks for the updates! The new package release now explicitly calls java 8. I also looked into the .desktop file and the start script. The first has slightly different entries (Icon and StartupWMClass), so we cannot use it as is. But I changed the one provided by this package to be as close as possible. The start script provided here is very specific to Arch Linux as it calls archlinux-java to find out what JVM was selected by the user. So I'm not sure how valuable this is for upstream. It could be a starting point for a more universal start script that supports multiple distributions though.

koppor commented on 2017-08-18 08:26 (UTC)

JabRef will soon release version 4.0, which depends on JavaFX. I think, one has only to add "java-openjfx" to the list of dependencies. The java-runtime should be set to precisely 8, as JabRef currently does not run at Java9: https://github.com/JabRef/jabref/issues/2594

koppor commented on 2017-08-18 08:24 (UTC)

JabRef now also tries to maintain a .desktop file. See https://github.com/JabRef/jabref/blob/master/buildres/snapcraft/jabref.desktop. Maybe, that file can be used? We can also place it somehwere else in the src tree. Maybe directly at buildres/? The JabRef team is also often asked to provide a jabref.sh (see https://github.com/JabRef/JabFox/issues/19). Maybe, you could provide your jabref.sh as pull request to JabRef's main repository? I would propose the scripts/ folder as the location.

n-st commented on 2017-06-03 20:40 (UTC)

JabRef has recently had its license updated. The PKGBUILD contains the checksum of the v3.8.2 license, but downloads the license from the master branch (currently v4.x beta), so the checksum test fails. Try this patch as a fix: http://x7f.uk/jamaxa.patch

Bevan commented on 2017-02-03 14:14 (UTC)

@Rhinoceros: Thanks a lot! :)

Rhinoceros commented on 2017-02-02 23:30 (UTC)

Thanks @Bevan. Here's a replacement to jabref.sh that works for me. It checks if java 8 is selected as the default java, and if not, reverts to your original script of selecting the alphabetically-last java. This *should* keep everyone happy! :) #!/bin/sh if [[ "$(archlinux-java get)" == java-8-* ]] then exec /usr/bin/java -jar /usr/share/java/jabref/JabRef-VERSION.jar "$@" else # Force usage of latest java version JVM_PATH=$(find /usr/lib/jvm/* -maxdepth 0 -type d | sort | tail -n1) exec $JVM_PATH/jre/bin/java -jar /usr/share/java/jabref/JabRef-VERSION.jar "$@" fi

Bevan commented on 2017-02-02 21:37 (UTC)

@Rhinoceros: I guess you are right. It's difficult to find something here to make everybody happy but I will try soon.

« First ‹ Previous 1 .. 13 14 15 16 17 18 19 20 21 Next › Last »