Package Details: jabref 5.0-3

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: 191
Popularity: 6.16
First Submitted: 2012-06-07 22:47
Last Updated: 2020-03-29 16:22

Dependencies (3)

Required by (0)

Sources (3)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

Bevan commented on 2020-04-03 09:22

neXyon: It is already adependency: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=jabref#n16

neXyon commented on 2020-04-03 09:20

Please add archlinux-java-run as dependency!

sirocco commented on 2020-04-01 08:17

Performance issues with version 5.0 (large databases)

https://github.com/JabRef/jabref/issues/5071

Bevan commented on 2020-03-31 14:37

hseara: I also observed the issue of JabRef not properly closing a couple times, however I could never reproduce it reliably. Also startup times are quite high. Overall it is usable for me but I only deal with relatively small bib files and typically have only one open at a time.

I do think these are upstream issues but we should indeed make sure before you report the issues upstream. To do so, you can download the "JabRef Linux Portable" version from https://www.fosshub.com/JabRef.html

You can then launch it as follows:

tar xf JabRef-5.0-portable_linux.tar.gz
cd JabRef
bin/JabRef

hseara commented on 2020-03-31 14:29

Hi all, after the update to JabRef 5, the program is slow. In my case with 20 local bib files opened with a maximum of 1000 entries in some of them, it is hardly usable. Opening the program to an entirely usable state takes close to a minute. Changing from a tab (i.e. bib file) to another tab (i.e., bib file) takes 10 or more seconds. Closing the program also takes a long time. Moreover, after closing the program, java is often not always closed properly using resources in the background until manually killed. Is anybody else experiencing all these issues? If so, is this a problem of the archlinux installation, or should we start reporting all this upstream? I did not want to pollute upstream with issues if they are just arch centric and solvable by us.

gothicVI commented on 2020-03-30 12:23

@Bevan: running makepkg and makepkg --install on the snapshot did the trick. Thanks a lot. There seems to be something wrong with pikaur I'll need to investigate...

Bevan commented on 2020-03-30 07:50

gothicVI: The posted output only shows the status of a systemd-run service that pikaur uses for building. It does not show any of the actual makepkg output. Sorry, I cannot support AUR helpers here, especially when they hide what actually happens. A wild guess would just be that you aborted too quickly and gradle was still downloading things.

Please try to build the package with plain makepkg. If that fails as well I'll be glad to help.

gothicVI commented on 2020-03-30 07:32

It's me again. The update 5.0-2 -> 5.0-3 remains stuck at

:: Starte den Buildvorgang:

(Starting build process) Looking at htop there's a running build process that uses CPU for a while and then does nothing until I abort. The output being

systemctl status run-u463.service
● run-u463.service - /usr/bin/makepkg --force
     Loaded: loaded (/run/systemd/transient/run-u463.service; transient)
  Transient: yes
     Active: activating (start) since Mon 2020-03-30 09:25:59 CEST; 2min 27s ago
   Main PID: 16615 (makepkg)
      Tasks: 76 (limit: 19003)
     Memory: 2.3G
     CGroup: /system.slice/run-u463.service
             ├─16615 /usr/bin/bash /usr/bin/makepkg --force
             ├─17361 /usr/lib/jvm/java-13-openjdk/bin/java -Xmx64m -Xms64m -Dorg.gradle.appname=gradlew -classpath /var/cache/private/pikaur/build/jabref/src/jabref-5.0/gradle/wrapper/gra>
             └─17440 /usr/lib/jvm/java-13-openjdk/bin/java --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.invoke=A>

Mär 30 09:25:59 ${HOSTNAME} systemd[1]: Starting /usr/bin/makepkg --force...

and after some time

systemctl status run-u463.service
● run-u463.service - /usr/bin/makepkg --force
     Loaded: loaded (/run/systemd/transient/run-u463.service; transient)
  Transient: yes
     Active: activating (start) since Mon 2020-03-30 09:25:59 CEST; 4min 24s ago
   Main PID: 16615 (makepkg)
      Tasks: 26 (limit: 19003)
     Memory: 1.1G
     CGroup: /system.slice/run-u463.service
             ├─16615 /usr/bin/bash /usr/bin/makepkg --force
             └─17361 /usr/lib/jvm/java-13-openjdk/bin/java -Xmx64m -Xms64m -Dorg.gradle.appname=gradlew -classpath /var/cache/private/pikaur/build/jabref/src/jabref-5.0/gradle/wrapper/gra>

Mär 30 09:25:59 ${HOSTNAME} systemd[1]: Starting /usr/bin/makepkg --force...

and finally after aborting

systemctl status run-u463.service
● run-u463.service - /usr/bin/makepkg --force
     Loaded: loaded (/run/systemd/transient/run-u463.service; transient)
  Transient: yes
     Active: failed (Result: exit-code) since Mon 2020-03-30 09:31:24 CEST; 3s ago
    Process: 16615 ExecStart=/usr/bin/makepkg --force (code=exited, status=1/FAILURE)
   Main PID: 16615 (code=exited, status=1/FAILURE)

Mär 30 09:25:59 ${HOSTNAME} systemd[1]: Starting /usr/bin/makepkg --force...
Mär 30 09:31:24 ${HOSTNAME} systemd[1]: run-u463.service: Main process exited, code=exited, status=1/FAILURE
Mär 30 09:31:24 ${HOSTNAME} systemd[1]: run-u463.service: Failed with result 'exit-code'.
Mär 30 09:31:24 ${HOSTNAME} systemd[1]: Failed to start /usr/bin/makepkg --force.

Anything else I could provide for debugging?

gothicVI commented on 2020-03-24 08:27

@Bevan: That also clarifies why the upgrade from 4.x to 5.0-1 went without issues. Thanks a lot =)

Bevan commented on 2020-03-23 19:59

gothicVI: Yes, that is how it works now. With version 5, JabRef is not a simple jar-file anymore but a more complex project with many dependencies that are managed with gradle. Version 5.0-1 of this package used the prebuilt portable version. However, that was only meant as a temporary workaround.