Package Details: jabref 5.15-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: 213
Popularity: 0.067418
First Submitted: 2012-06-07 22:47 (UTC)
Last Updated: 2025-01-17 16:00 (UTC)

Dependencies (4)

Required by (0)

Sources (8)

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 .. 7 8 9 10 11 12 13 14 15 16 17 .. 22 Next › Last »

Bevan commented on 2020-03-23 18:50 (UTC)

gothicVI: It looks like gradle tries to use an unsuitable path for its files when building. I will try to come up with a fix later today.

gothicVI commented on 2020-03-23 17:33 (UTC)

Hi all, version 5.0-2 fails to update from version 5.0-1 and fails to install after a removal. Here's the console output:

:: Starte den Buildvorgang:
Running as unit: run-u2354.service
Press ^] three times within 1s to disconnect TTY.
==> Erstelle Paket: jabref 5.0-2 (Mo 23 Mär 2020 18:31:43 CET)
==> Prüfe Laufzeit-Abhängigkeiten...
==> Prüfe Buildtime-Abhängigkeiten...
==> Empfange Quellen...
  -> Lade jabref-5.0.tar.gz herunter...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   119  100   119    0     0    340      0 --:--:-- --:--:-- --:--:--   339
100 9209k    0 9209k    0     0  2948k      0 --:--:--  0:00:03 --:--:-- 4896k
  -> jabref.sh gefunden
  -> jabref.desktop gefunden
==> Überprüfe source Dateien mit sha256sums...
    jabref-5.0.tar.gz ... Durchgelaufen
    jabref.sh ... Durchgelaufen
    jabref.desktop ... Durchgelaufen
==> Entpacke Quellen...
  -> Entpacke jabref-5.0.tar.gz mit bsdtar
==> Beginne build()...
Exception in thread "main" java.lang.RuntimeException: Could not create parent directory for lock file /.gradle/wrapper/dists/gradle-6.2.1-bin/5m14x4d33sfxbtkeo25s43l8q/gradle-6.2.1-bin.zip.lck
        at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:43)
        at org.gradle.wrapper.Install.createDist(Install.java:48)
        at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:107)
        at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:63)
==> FEHLER: Ein Fehler geschah in build().
    Breche ab...
Finished with result: exit-code
Main processes terminated with: code=exited/status=4
Service runtime: 4.609s

Ausführung des Befehls 'systemd-run --pipe --wait --pty -p DynamicUser=yes -p CacheDirectory=pikaur -E HOME=/tmp -p WorkingDirectory=/var/cache/pikaur/build/jabref sh -c trap "exit 2" INT ; makepkg --force' ist fehlgeschlagen.
:: Versuchen, wiederherzustellen?
[R] Build nochmal versuchen
[p] überspringe PGP-Signaturprüfung
[c] überspringe Checksummen-Prüfung
[i] ignoriere Architektur
[d] entferne Build-Verzeichnis und versuche erneut
[e] edit PKGBUILD
------------------------
[u] überspringe Build dieses Pakets
[a] bauen aller Pakete abbrechen
> a

Are there missing dependencies?

billypilgrim commented on 2020-03-20 10:40 (UTC)

@Bevan Great, thanks for your response and for your work on this package :-). That all sounds sensible.

Bevan commented on 2020-03-19 23:37 (UTC)

The package now only contains Java resources again and no JRE.

For now, it requires jdk-openjdk in version 13. I will make this more flexible in future, since JabRef seems to work fine with JDK 14 as well.

Bevan commented on 2020-03-19 12:18 (UTC) (edited on 2020-03-20 09:10 (UTC) by Bevan)

billypilgrim: This package is not supposed to ship the prebuilt portable version for long, so no, it is not becoming a jabref-bin.

I would love to get rid of the JRE. If this is not possible, I at least would like to build the package from scratch to use our own JRE instead of someone's. This is however a non-trivial process. Pull requests are always welcome :)

Since people started asking if this package is still maintained at all, I decided to temporarily distribute the portable version until a better solution is found.

billypilgrim commented on 2020-03-19 10:58 (UTC)

@Bevan Thanks for updating this to v5. The only issue is that I think this package should be called jabref-bin as per the standard AUR naming conventions. It would be nice not to have an entire bundled JRE with the package.

Rhinoceros commented on 2020-03-19 09:44 (UTC)

Ah yes good point. I always forget "the downloaded source filename must be unique" in my PKGBUILDs. Thanks for the reply.

Bevan commented on 2020-03-19 09:41 (UTC)

Rhinoceros: The plan is to rename the downloaded files to include package name and version. So with an update of the package, they get new names and old versions lying around are not used. See https://wiki.archlinux.org/index.php/PKGBUILD#source

Rhinoceros commented on 2020-03-19 09:39 (UTC)

@Bevan Thank you for maintaining this package! Out of interest, how can you actually prevent this issue? I had similar errors in yay, but as you say, it was just the previous version, so I cleanbuilt. However, as a package maintainer, can you actually force a re-download by the users?

Bevan commented on 2020-03-19 09:06 (UTC)

blegat: You likely still have an old version of LICENSE.md lying around in the folder where makepkg is running. Removing it should solve the problem.

I will make the package more robust against this issue in future.