Package Details: jabref 5.6-1

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: 206
Popularity: 0.139522
First Submitted: 2012-06-07 22:47 (UTC)
Last Updated: 2022-04-28 20:56 (UTC)

Dependencies (4)

Required by (0)

Sources (3)

Pinned Comments

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

Bevan commented on 2022-05-06 18:35 (UTC)

@Flupp: The tar is created during build, so it's not coming from upstream directly. Weirdly, I cannot reproduce your problem:

tar tvf src/jabref-5.6/build/distributions/JabRef-5.6.tar | grep codec
-rw-r--r-- 0/0          335042 2020-03-29 19:14 JabRef-5.6/lib/commons-codec-1.11.jar

And similarly, it's correct in pkg as well:

ls -la pkg/jabref/usr/share/java/jabref/lib/commons-codec-1.11.jar
-rw-r--r-- 1 bevan bevan 335042  6. Mai 20:25 pkg/jabref/usr/share/java/jabref/lib/commons-codec-1.11.jar

I wonder if this depends on the Java version used during the build step. Maybe gradle fetches different sources then. When running makepkg, there will be an output like the following:

Using JDK from /usr/lib/jvm/java-18-openjdk to build JabRef.

What does it say in your case?

Flupp commented on 2022-05-06 09:46 (UTC)

Currently (version 5.6-1) I get:

java.lang.module.FindException: java.io.FileNotFoundException: /usr/share/java/jabref/lib/commons-codec-1.11.jar (Permission denied)

It seems this file comes from the line

  tar xf distributions/JabRef-${pkgver}.tar -C "${pkgdir}"/usr/share/java/${pkgname} JabRef-${pkgver}/lib --strip-components=1

in the PKGBUILD. Actually, I am not sure if this is a packaging issue or an upstream issue since the permission is already wrong in the tar (600).

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

malacology commented on 2022-01-07 09:01 (UTC)

I would suggest you to replace your archlinux-java-runtime with the packages official supports, it would make makepkg easier

Bevan commented on 2021-09-07 08:51 (UTC)

@eyolf Thanks for the hint! CSL styles and locales are now included in 5.3-3.

eyolf commented on 2021-09-05 09:44 (UTC)

There is a number of CLS entry preview files included in JabRef, which need to be added in the build stage by adding cp buildres/csl/csl-locales/* src/main/resources/csl-locales/ according to the developers.

malacology commented on 2021-08-17 08:08 (UTC)

JabRef will need to add option dependency grobid in the later version (maybe). I would like to update it but seems an error presents. https://github.com/kermitt2/grobid/issues/817

MartinX3 commented on 2021-07-06 09:57 (UTC)

Jabref 5.3 supports java 16

Bevan commented on 2021-06-28 22:26 (UTC) (edited on 2021-07-07 21:05 (UTC) by Bevan)

The following comment is now obsolete!

As MartinX3 pointed out, the current version of Jabref only builds with Java 14 or Java 15. This gives us two problems:

  • Arch does not provide any of these versions in their repositories.
  • pacman doesn't give us a way to specify this as a dependency. Something like 'java-runtime>=14' 'java-runtime<16' will also be satisfied if people have Java 11 and Java 16 installed.

I therefore added a dependency on Java 15. To satisfy this dependency, you can install either of the following packages:

MartinX3 commented on 2021-06-22 19:44 (UTC) (edited on 2021-06-22 19:51 (UTC) by MartinX3)

General error during semantic analysis: Unsupported class file major version 60

Because it uses gradle 6.5 and java 17 to build the software. But java 16 support got introduced with gradle 7.0

Their graddlewrapper got upgraded to 7.0 on May 3, 2021 So either this package should force a java version < 16 or containing a hotfix to update the gradle wrapper version.

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.

Bevan commented on 2020-08-02 15:55 (UTC)

@juiin: Could you please test if you have the same problem with official build from https://www.fosshub.com/JabRef.html?dwl=JabRef-5.0-portable_linux.tar.gz ?

ruiin commented on 2020-08-02 15:46 (UTC)

Hi, I have the issue that the JabRef window becomes unresponsive (no menus like 'file', 'quality', while it works to select an item) on the second screen of a multi-screen setup.

Version: 2020-03-29 16:22 Error at runtime: (java:643023): Gdk-WARNING **: 17:45:00.905: XSetErrorHandler() called with a GDK error trap pushed. Don't do that.

Thanks

rmagno commented on 2020-07-09 13:20 (UTC) (edited on 2020-07-09 13:21 (UTC) by rmagno)

@Bevan: Thanks again!

rmagno@midget ~> sudo pacman -Qkq

No output is what I got. So seemingly it had been only those jre-* packages that were affected. I am guessing that at some point I must have forced pacman to ignore dependencies, like you said before.

BTW: Thank you for maintaining JabRef in Arch!

Bevan commented on 2020-07-09 13:17 (UTC)

@magno: Maybe quickly run sudo pacman -Qkq to make sure that no other packages are affected. It will output missing files and their corresponding package, so no output at all is what you want.

rmagno commented on 2020-07-09 13:10 (UTC)

Thank you @Bevan! JabRef works now again.

Reinstalling jre-openjdk and jre-openjdk-headless did solve it. And I had indeed many missing files. I can't, for the life of me, understand what I did that could explain this...

rmagno@midget ~> sudo pacman -S jre-openjdk jre-openjdk-headless
warning: jre-openjdk-14.0.1.u7-1 is up to date -- reinstalling
warning: jre-openjdk-headless-14.0.1.u7-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (2) jre-openjdk-14.0.1.u7-1  jre-openjdk-headless-14.0.1.u7-1

Total Installed Size:  179.63 MiB
Net Upgrade Size:        0.00 MiB

:: Proceed with installation? [Y/n] 
(2/2) checking keys in keyring                          [#############################] 100%
(2/2) checking package integrity                        [#############################] 100%
(2/2) loading package files                             [#############################] 100%
(2/2) checking for file conflicts                       [#############################] 100%
(2/2) checking available disk space                     [#############################] 100%
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/jaotc
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/java
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/javac
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/javap
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/jdeprscan
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/jdeps
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/jfr
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/jimage
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/jjs
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/jlink
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/jmod
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/jpackage
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/jrunscript
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/keytool
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/rmid
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/rmiregistry
warning: could not get file information for usr/lib/jvm/java-14-openjdk/bin/serialver
warning: could not get file information for usr/lib/jvm/java-14-openjdk/conf
warning: could not get file information for usr/lib/jvm/java-14-openjdk/legal
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/classlist
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/ct.sym
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/jexec
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/jfr/default.jfc
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/jfr/profile.jfc
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/jrt-fs.jar
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/jspawnhelper
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/jvm.cfg
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libawt.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libawt_headless.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libdt_socket.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libextnet.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libfontmanager.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libinstrument.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libj2gss.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libj2pcsc.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libj2pkcs11.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libjaas.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libjava.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libjavajpeg.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libjdwp.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libjimage.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libjli.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libjsig.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/liblcms.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libmanagement.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libmanagement_agent.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libmanagement_ext.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libmlib_image.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libnet.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libnio.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libprefs.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/librmi.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libsctp.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libsunec.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libverify.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libzip.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/modules
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/psfont.properties.ja
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/psfontj2d.properties
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/security/blacklisted.certs
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/security/cacerts
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/security/default.policy
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/security/public_suffix_list.dat
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/server/classes.jsa
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/server/libjsig.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/server/libjvm.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/tzdb.dat
warning: could not get file information for usr/lib/jvm/java-14-openjdk/release
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libawt_xawt.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libjawt.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libjsound.so
warning: could not get file information for usr/lib/jvm/java-14-openjdk/lib/libsplashscreen.so
:: Processing package changes...
(1/2) reinstalling jre-openjdk-headless                 [#############################] 100%
(2/2) reinstalling jre-openjdk                          [#############################] 100%
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...

Now archlinix-java correctly lists java-14-openjdk:

rmagno@midget ~> archlinux-java status
Available Java environments:
  java-14-openjdk
  java-8-openjdk (default)

Bevan commented on 2020-07-09 13:04 (UTC)

OK, yo all required packages are installed. The java executable should be coming with jre-openjdk-headless which you have installed:

pacman -Qo /usr/lib/jvm/java-14-openjdk/bin/java
/usr/lib/jvm/java-14-openjdk/bin/java is owned by jre-openjdk-headless 14.0.1.u7-1

Reinstalling jre-openjdk and jre-openjdk-headless will hopefully fix that but of course the question remains why this file was lost.

rmagno commented on 2020-07-09 13:00 (UTC)

rmagno@midget ~> pacman -Qs openjdk
local/jdk-openjdk 14.0.1.u7-1
    OpenJDK Java 14 development kit
local/jdk8-openjdk 8.u252-1
    OpenJDK Java 8 development kit
local/jre-openjdk 14.0.1.u7-1
    OpenJDK Java 14 full runtime environment
local/jre-openjdk-headless 14.0.1.u7-1
    OpenJDK Java 14 headless runtime environment
local/jre8-openjdk 8.u252-1
    OpenJDK Java 8 full runtime environment
local/jre8-openjdk-headless 8.u252-1
    OpenJDK Java 8 headless runtime environment
rmagno@midget ~> archlinux-java status
Available Java environments:
  java-8-openjdk (default)

The workaround proposed does not work because seemingly I don't have the java executable in /usr/lib/jvm/java-14-openjdk/bin...

rmagno@midget ~> ls -l /usr/lib/jvm/java-14-openjdk/bin/
total 240
-rwxr-xr-x 1 root root 14272 May 23 19:20 jar*
-rwxr-xr-x 1 root root 14280 May 23 19:20 jarsigner*
-rwxr-xr-x 1 root root 14312 May 23 19:20 javadoc*
-rwxr-xr-x 1 root root 14272 May 23 19:20 jcmd*
-rwxr-xr-x 1 root root 14344 May 23 19:20 jconsole*
-rwxr-xr-x 1 root root 14272 May 23 19:20 jdb*
-rwxr-xr-x 1 root root 14272 May 23 19:20 jhsdb*
-rwxr-xr-x 1 root root 14304 May 23 19:20 jinfo*
-rwxr-xr-x 1 root root 14304 May 23 19:20 jmap*
-rwxr-xr-x 1 root root 14272 May 23 19:20 jps*
-rwxr-xr-x 1 root root 14280 May 23 19:20 jshell*
-rwxr-xr-x 1 root root 14312 May 23 19:20 jstack*
-rwxr-xr-x 1 root root 14272 May 23 19:20 jstat*
-rwxr-xr-x 1 root root 14280 May 23 19:20 jstatd*
-rwxr-xr-x 1 root root 14272 May 23 19:20 rmic*

Bevan commented on 2020-07-09 12:45 (UTC) (edited on 2020-07-09 12:46 (UTC) by Bevan)

Thanks for your feedback. The error message actually comes from a custom launch script I use and not from jabref itself. The problem is obviously that your java 14 installation does not show up in archlinux-java.

To debug this issue, could you please run pacman -Qs openjdk and post the output here?

As a temporary workaround, you can try to edit /usr/bin/JabRef and replace the line

/usr/bin/archlinux-java-run --min 13 -- \

by

/usr/lib/jvm/java-14-openjdk/bin/java \

Does this work for you?

rmagno commented on 2020-07-09 12:29 (UTC) (edited on 2020-07-09 12:31 (UTC) by rmagno)

Hi @Bevan: Thank you for your feedback.

I don't know what is going on. It seems I have the latest version of jdk-openjdk but JabRef still complains about not finding a suitable JVM:

magno@midget ~> sudo pacman -S jdk-openjdk
warning: jdk-openjdk-14.0.1.u7-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (1) jdk-openjdk-14.0.1.u7-1

Total Installed Size:  86.99 MiB
Net Upgrade Size:       0.00 MiB

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                                                                                                                                            [#########################################################################################################] 100%
(1/1) checking package integrity                                                                                                                                          [#########################################################################################################] 100%
(1/1) loading package files                                                                                                                                               [#########################################################################################################] 100%
(1/1) checking for file conflicts                                                                                                                                         [#########################################################################################################] 100%
(1/1) checking available disk space                                                                                                                                       [#########################################################################################################] 100%
:: Processing package changes...
(1/1) reinstalling jdk-openjdk                                                                                                                                            [#########################################################################################################] 100%
:: Running post-transaction hooks...
(1/3) Arming ConditionNeedsUpdate...
(2/3) Updating icon theme caches...
(3/3) Updating the desktop file MIME type cache...
magno@midget ~> JabRef
No suitable JVM found.
Available:         java-8-openjdk
Default:           java-8-openjdk
Min. required:     13
Max. required:     20
Package required:  
Candidates:        
Features required: 
magno@midget ~> archlinux-java status
Available Java environments:
  java-8-openjdk (default)

Bevan commented on 2020-07-09 06:47 (UTC)

@magno: That normally should not happen. It means that only java 8 is installed on your system. However, this package has a dependency on java-runtime>=13. You should be able to fix it by installing the package jdk-openjdk.

The question is, how could you end up in this situation? Did you remove some packages and forced pacman to ignore dependencies?

rmagno commented on 2020-07-09 00:41 (UTC)

I can't run JabRef.

I am getting:

No suitable JVM found.
Available:         java-8-openjdk
Default:           java-8-openjdk
Min. required:     13
Max. required:     20
Package required:  
Candidates:        
Features required: 

quickwater commented on 2020-05-05 19:11 (UTC)

Bevan: I have tried getting the files manually by wget or using a browser. Sometimes it worked, sometimes it gave me 404. However, your idea about firewall made me think that it could be a problem with a Brazilian internet provider. I connected to a VPN, et voilà, everything is working fine. So everything seems to be resolved. Thanks a lot for your help.

Bevan commented on 2020-05-05 18:49 (UTC)

quickwater: Thanks for clarifying. Since the problem is not specific to this package, it's unlikely that we can solve it here. But maybe we can learn something about the issue nevertheless.

In your first post you mentioned https://jcenter.bintray.com/org/openjdk/jmh/jmh-core/1.21/jmh-core-1.21.jar as not downloadable. What happens if you manually try to download that file, e.g., using

curl --output jmh-core-1.21.jar -L https://jcenter.bintray.com/org/openjdk/jmh/jmh-core/1.21/jmh-core-1.21.jar

or

wget https://jcenter.bintray.com/org/openjdk/jmh/jmh-core/1.21/jmh-core-1.21.jar

? Are you maybe behind some kind of firewall? Either because you are using a company network or maybe you are in a state that filters internet access?

quickwater commented on 2020-05-05 18:33 (UTC) (edited on 2020-05-05 18:37 (UTC) by quickwater)

Bevan: no, it wasn't resolved. I deleted the comment because I wanted to try to solve it first, before asking help here. Looks like it is not temporary problem. I am sure it is not in PKGBUILD, since I tried to build jabref from the git repository with the same result.

Bevan commented on 2020-05-05 16:13 (UTC)

quickwater: Wasn't this issue solved five days ago (since you deleted your first comment on that)? I tried building when you posted this first and it worked for me so I assumed it was a temporary hickup.

quickwater commented on 2020-05-05 16:01 (UTC)

Cannot build because gradle cannot get resources such as jmh-core, xstream, javaparser-symbol-solver-core-3.13.5.jar and others. What could be a possible reason? Thanks.

Bevan commented on 2020-04-03 09:22 (UTC)

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 (UTC)

Please add archlinux-java-run as dependency!

sirocco commented on 2020-04-01 08:17 (UTC)

Performance issues with version 5.0 (large databases)

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

Bevan commented on 2020-03-31 14:37 (UTC)

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 (UTC) (edited on 2020-03-31 14:30 (UTC) by hseara)

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 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

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.

gothicVI commented on 2020-03-23 19:47 (UTC)

@Bevan: that fixed it though it took quite some time as it had to download gradle and build java for some reason. Anyhow, thanks a lot!

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

gothicVI, can you please retry with the newest PKGBUILD?

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.

blegat commented on 2020-03-19 09:00 (UTC) (edited on 2020-03-19 09:00 (UTC) by blegat)

I just tried to update and I got:

==> Validating source files with sha256sums...
    JabRef-5.0-portable_linux.tar.gz ... Passed
    LICENSE.md ... FAILED

Bevan commented on 2020-03-18 08:57 (UTC)

Sorry that the update to JabRef 5 takes a while. I'm planning to do it within the next couple of days.

Rhinoceros commented on 2020-03-09 10:00 (UTC)

@SebRut $pkgver never has whitespace in it, and URLs never have spaces either, so those changes are pointless.

SebRut commented on 2020-01-03 11:51 (UTC)

I'm getting the follwing, easily fixed warnings when running shellcheck:

In /dev/stdin line 68:
source=(https://github.com/JabRef/jabref/releases/download/v${pkgver}/JabRef-${pkgver}.jar
                                                            ^-------^ SC2206: Quote to prevent word splitting/globbing, or split robustly with mapfile or read -a.                                                                                                            
                                                                             ^-------^ SC2206: Quote to prevent word splitting/globbing, or split robustly with mapfile or read -a.                                                                                           


In /dev/stdin line 69:
        https://raw.githubusercontent.com/JabRef/jabref/v${pkgver}/LICENSE.md
                                                         ^-------^ SC2206: Quote to prevent word splitting/globbing, or split robustly with mapfile or read -a.                                                                                                               


In /dev/stdin line 72:
noextract=(JabRef-${pkgver}.jar)
                  ^-------^ SC2206: Quote to prevent word splitting/globbing, or split robustly with mapfile or read -a.

For more information:
  https://www.shellcheck.net/wiki/SC2206 -- Quote to prevent word splitting/g...

duckmayr commented on 2019-10-13 15:36 (UTC)

UPDATE: I was able to install jabref.

After thinking a little harder about the error message I saw, I realized archlinux-java-run was probably an additional dependency (beyond java8-openjfx), which probably wasn't in the official repos. Sure enough, I just needed to get it from the AUR at https://aur.archlinux.org/packages/archlinux-java-run/

It might be worthwhile to have as a pinned comment the process to install jabref from scratch, so that people know to get both the java8-openjfx and archlinux-java-run dependencies setup from the get-go. (Or maybe others don't have such problems, and it would only help someone relatively inexperienced with the AUR like me...).

duckmayr commented on 2019-10-13 15:00 (UTC)

I am having some trouble installing, even after following the pinned comment. Specifically, these are the commands I ran:

git clone <https://aur.archlinux.org/jabref.git>
cd jabref/
sudo pacman -Syu
sudo pacman -S --asdeps java8-openjfx
makepkg -si

and I got as output

==> Making package: jabref 4.3.1-3 (Sun 13 Oct 2019 09:49:23 AM CDT)
==> Checking runtime dependencies...
==> Installing missing dependencies...
error: target not found: archlinux-java-run>=4
==> ERROR: 'pacman' failed to install missing dependencies.

Any thoughts? Thanks!

(This is my first time posting on AUR; please let me know if there's information I haven't provided that is expected).

Bevan commented on 2019-08-02 19:05 (UTC)

myops: As far as I can tell, the checksum is still correct. Maybe you have an old/modified version of the LICENSE.md file lying around?

curl https://raw.githubusercontent.com/JabRef/jabref/v4.3.1/LICENSE.md 2>/dev/null|sha256sum 
d0a8248eeaafc526f1137703fdc5aac1c8fae106f94c4bef56e3650e2c4c73a7  -

myops commented on 2019-08-02 15:35 (UTC)

Please update the checksum for LICENSE.md in PKGBUILD.

n.vaughan commented on 2019-07-25 23:17 (UTC) (edited on 2019-07-25 23:18 (UTC) by n.vaughan)

@Rhinoceros You're right! Very odd indeed.

Rhinoceros commented on 2019-07-25 23:16 (UTC) (edited on 2019-07-25 23:16 (UTC) by Rhinoceros)

@n.vaughan You just needed to follow the pinned comment. It looks like you are using the old PKGBUILD. The current one already has that line in it!

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=jabref#n16

n.vaughan commented on 2019-07-25 23:10 (UTC) (edited on 2019-07-25 23:12 (UTC) by n.vaughan)

@Rhinoceros, I just changed the line:

depends=('archlinux-java-run>=4' 'java-openjfx'

to:

depends=('archlinux-java-run>=4' 'java8-openjfx'

in the PKGBUILD file. It now works fine.

Rhinoceros commented on 2019-07-25 22:52 (UTC)

@n.vaughan It's in the official repos, not the AUR. Did you follow the pinned comment? pacman -Syu then pacman -S --asdeps java8-openjfx

n.vaughan commented on 2019-07-25 22:48 (UTC)

I couldn't find java8-openjfx in the AUR, only java-openjfx. The install failed.

Rhinoceros commented on 2019-07-25 09:37 (UTC)

Thank you for the quick update!

Bevan commented on 2019-07-25 06:48 (UTC)

Important note on the java-openjfx update:

Arch restructured the java-openjfx package. Version 8 which is required by jabref is now called java8-openjfx. To update your system, you need to temporarily uninstall jabref, then make a full system update and finally build and install the newest version:

  • pacman -R jabref
  • pacman -Syu
  • pacman -S --asdeps java8-openjfx
  • makepkg
  • pacman -U jabref-4.3.1-3-any.pkg.tar

Rhinoceros commented on 2019-07-24 22:33 (UTC)

The change has reached the stable repos now.

# pacman -Syu
...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing java-openjfx (11.0.3.u1-1) breaks dependency 'java-openjfx<9' required by jabref

Bevan commented on 2019-06-18 08:05 (UTC)

That we get openjfx for newer Java versions is great news! I'll update the dependencies for this package as soon as the change reaches the stable repos. People using testing that want to install openjfx 11 probably need to modify this package to get around dependency issues.

totsilence commented on 2019-06-18 07:58 (UTC)

There is a new package (currently in testing): java8-openjfx. I think (at least when java8-openjfx leaves testing) this package should depend on that package, as java-openjfx was upgraded to java 11.

dschrempf commented on 2019-02-05 12:40 (UTC)

Sorry for the late response, I didn't have notifications enabled. Both of your commands give the same output:

openjdk version "1.8.0_202" OpenJDK Runtime Environment (build 1.8.0_202-b26) OpenJDK 64-Bit Server VM (build 25.202-b26, mixed mode)

At the moment, I am using the latest jar file provided at "https://builds.jabref.org/master/"! This seems to work better.

Bevan commented on 2019-01-11 09:40 (UTC)

@dschrempf: I think there are known issues like this with the current JabRef version that will be fixed in version 5 (e.g. https://github.com/JabRef/jabref/issues/4458).

However, this may very well depend on the version of the JRE used. Could you please run the following two commands and post the output here?

archlinux-java-run --min 8 --max 8 --feature javafx -- -version

archlinux-java-run --min 8 --max 8 -- -version

Thanks!

dschrempf commented on 2019-01-11 09:33 (UTC)

I noticed that java was not quitting after closing JabRef (this led to memory problems when reopening for a few times). I removed '--feature javafx' from 'archlinux-java-run' and then it worked. I am not sure if this breaks something, just wanted to let you know!

commented on 2018-11-14 12:09 (UTC)

pikaur -S jabref Reading repository package databases... Reading local package database... Resolving AUR dependencies... :: New dependency will be installed from repository: java-openjfx (for jabref) -> 8.u172-2 :: AUR package will be installed: jabref -> 4.3.1-2 :: New dependency will be installed from AUR: archlinux-java-run (for jabref) -> 4-1

archlinux-java status Available Java environments: java-8-openjdk/jre (default)

Okay, the problem is that the installation of java-openjfx implicitly makes PyCharm search for JDK, which is not installed. Probably, a PyCharm bug.

Bevan commented on 2018-11-14 09:41 (UTC)

@alleut: This package should not affect other software at all. At least I don't know how it would.

I can however imagine that this package required you to install a different JDK and now your java installation is not configured proberly. Can you try running "archlinux-java fix"? If it does not help, please post the output of "archlinux-java status". Also see https://wiki.archlinux.org/index.php/java#Switching_between_JVM

commented on 2018-11-14 00:45 (UTC)

Installation breaks PyCharm Community: "No JDK found. Please validate either PYCHARM_JDK, JDK_HOME or JAVA_HOME environment variable points to valid JDK installation."

Bevan commented on 2018-07-19 17:42 (UTC)

Unia: Thanks for the report! Indeed, gtk2 seems to be required for JavaFX, however it's only a make dependency of java-openjfx. I just added a bunch of JavaFX dependencies here, including gtk2.

Unia commented on 2018-07-19 14:31 (UTC)

This needs gtk2 to be added as a dependency. Without it, I get

Graphics Device initialization failed for :  es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found

Installing gtk2 fixes this.

Bevan commented on 2018-06-24 20:09 (UTC)

flocomkoko: The java version is pinned to version 8 in the requirements already. And no, archlinux-java-run is required anyway because people have multiple versions of java installed.

commented on 2018-06-24 20:07 (UTC)

Since jabref only works with java 8 could the java version in the requirements be pinned to java 8 and the dependency on archlinux-java-run be removed?

Bevan commented on 2018-06-04 08:30 (UTC)

robguinness: Seems like the package builds fine but for some reason the installation fails.

I guess you are using some kind of AUR helper for installation. Unfortunately it doesn't give you the reason why installation failed. Please try building and installing the package manually as described in https://wiki.archlinux.org/index.php/Arch_User_Repository#Installing_packages and see if it works or gives any more useful output.

robguinness commented on 2018-06-04 08:09 (UTC) (edited on 2018-06-04 08:17 (UTC) by robguinness)

I wasn't able to install. Strangely, the terminal output shows conflicting info:

(1/1) Arming ConditionNeedsUpdate... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Downloading JabRef-4.3.jar... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 604 0 604 0 0 943 0 --:--:-- --:--:-- --:--:-- 943 100 54.2M 100 54.2M 0 0 400k 0 0:02:18 0:02:18 --:--:-- 577k -> Downloading LICENSE.md... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1131 100 1131 0 0 4400 0 --:--:-- --:--:-- --:--:-- 4383 -> Found jabref.sh -> Found jabref.desktop ==> Validating source files with sha256sums... JabRef-4.3.jar ... Passed LICENSE.md ... Passed jabref.sh ... Passed jabref.desktop ... Passed ==> Extracting sources... ==> Starting prepare()... ==> Entering fakeroot environment... ==> Starting package()... ==> Tidying install... -> Removing libtool files... -> Purging unwanted files... -> Removing static library files... -> Stripping unneeded symbols from binaries and libraries... -> Compressing man and info pages... ==> Checking for packaging issue... ==> Creating package "jabref"... -> Generating .PKGINFO file... -> Generating .BUILDINFO file... -> Generating .MTREE file... -> Compressing package... ==> Leaving fakeroot environment. ==> Finished making: jabref 4.3-1 (Mon Jun 4 10:28:40 EEST 2018) ==> Installing package jabref with pacman -U... [sudo] password for rob: ==> WARNING: Failed to install built package(s). ==> Cleaning up...

arrhenius commented on 2018-01-21 15:36 (UTC)

"LICENSE.md fails checksum validity check."

Solved by removing ~/.cache/pacaur/jabref

commented on 2018-01-15 23:50 (UTC)

LICENSE.md fails checksum validity check.

Rhinoceros commented on 2018-01-08 09:30 (UTC)

That seems logical to me, too.

Bevan commented on 2018-01-08 09:28 (UTC)

Rhinoceros: That makes sense, yes. Hm... I could require java-openjfx=8 here since jabref currently only works with Java 8 anyway.

Rhinoceros commented on 2018-01-08 09:24 (UTC)

Oh yeah… I can see that now. I have no idea. Ahhh… perhaps it's because jre provides java-openjfx=9, and I already had that installed?

Bevan commented on 2018-01-08 07:53 (UTC)

Rhinoceros: How did you manage to install this package without installing java-openjfx first? It is a dependency.

Rhinoceros commented on 2018-01-08 04:00 (UTC)

The new version failed to start on my system with:

Error: Could not find or load main class org.jabref.JabRefMain

I'm using java-8-openjdk. After installing java-openjfx, jabref could again launch.

dvzrv commented on 2018-01-01 11:20 (UTC)

@Bevan: it was the license file. Deleted and reinstalled.

pryre commented on 2018-01-01 07:37 (UTC)

I was also having some issues building the package. Cleaned out the cache of my AUR helper, then had no issues installing it. Might have something strange going on with scrap files from between versions, but it was a simple fix.

Bevan commented on 2017-12-30 11:04 (UTC) (edited on 2017-12-30 11:04 (UTC) by Bevan)

curl https://raw.githubusercontent.com/JabRef/jabref/v4.1/LICENSE.md 2>/dev/null | sha256sum : d0a8248eeaafc526f1137703fdc5aac1c8fae106f94c4bef56e3650e2c4c73a7

... which is exactly the checksum given in the PKGBUILD. Even in upstream's master branch the file was not touched since May: https://github.com/JabRef/jabref/commits/master/LICENSE.md

billypilgrim and dvzrv: Maybe you have still an old file from JabRef 3 lying around? If necessary, please download the file manually and check where the difference is coming from.

billypilgrim commented on 2017-12-30 10:19 (UTC)

This package is no longer building as LICENSE.md has changed

Bevan commented on 2017-12-29 14:17 (UTC)

dvzrv: They do for me. I just rechecked. Maybe one of the downloads failed / got corrupted?

dvzrv commented on 2017-12-29 14:01 (UTC)

@Bevan: The checksums don't match

j0hannes commented on 2017-12-27 17:17 (UTC)

If you use the current version (4.1-1) be sure to always have a backup of your bib files as it randomly overwrites entries when editing.

Huulivoide commented on 2017-12-10 15:13 (UTC)

Java 9 support would be nice. Just need to add '--add-modules java.xml.bind' to the command line if Java 9 is used.

Bevan commented on 2017-11-25 18:48 (UTC)

Since people keep commenting without reading through the comments before, here's a summary on why this is not updated to JabRef 4.0: - JabRef 4.0 has a series of serious bugs (won't start, won't stop, will eat gigabytes of memory, ...). - Most of these bugs are fixed in git by now but no release includes them yet. - Applying these patches to this package would require everyone to rebuild the JAR file and install several build-time dependencies. - People wanting to build the JAR from current git can use the jabref-git package here in AUR. - There is no need to duplicate jabref-git in this package, it is already there. Use it. - If you really really want to install JabRef 4.0 without these patches, take this PKGBUILD: https://github.com/michaellass/AUR/tree/jabref-4/jabref - You can also download a prebuilt jar file from https://builds.jabref.org/master/ - Unfortunately these jar files are not archived which is why I cannot use them here. Please refrain from asking why this has not been updated yet, why I do not apply patches from git, or when I will update this package. I will likely just ignore these questions in future.

d4muck commented on 2017-11-25 10:33 (UTC)

@Bevan when will you update to v4? As I understood you wrote in your pinned comment that you solved both issues

Bevan commented on 2017-11-13 10:28 (UTC)

hseara: This looks to me like another instance of JabRef is running but has somehow crashed. Could you check for any running java instances with ps and kill them if they relate to jabref? Or, alternatively, reboot.

hseara commented on 2017-11-13 10:20 (UTC) (edited on 2017-11-13 10:45 (UTC) by hseara)

@Bevan Thanks your suggestion. If you cannot open jabref and you get the following message: 11:16:21.281 [AWT-EventQueue-0] WARN org.jabref.logic.remote.server.RemoteListenerServerLifecycle - Port is blocked java.net.BindException: Address already in use (Bind failed) .... 11:16:21.357 [AWT-EventQueue-0] INFO org.jabref.JabRefMain - Arguments passed on to running JabRef instance. Shutting down. check for open instances of jabref and kill them. Note: In multi-user system environments check the following issue: (https://github.com/JabRef/jabref/issues/2282)

Rhinoceros commented on 2017-10-25 10:29 (UTC)

@Bevan Ah, fair enough. Thank you for the explanation.

Bevan commented on 2017-10-25 08:44 (UTC)

Rhinoceros: Currently this package uses a prebuilt jar-file. To apply the changes, this would have to be changed to build the jar-file from source on PKGBUILD. That is possible for sure, but then again there is also a jabref-git package here in the AUR which pretty much does exactly that. By the way: There are also prebuilt jar-files for the current git revision, but as far as I can see they only keep the most recent version on the server, so we cannot just use that: https://builds.jabref.org/master/

Rhinoceros commented on 2017-10-25 00:52 (UTC)

@Bevan Could you possibly backport the fixes into 4.0 instead? That's what normally happens on "official" Arch packages. You can get the fixes in patch format by appending `.patch` to the github urls that you list in your comment.

Zebra commented on 2017-10-07 17:16 (UTC)

Bevan: Reasonable enough. Thanks for maintaining!

Bevan commented on 2017-10-07 14:39 (UTC)

Zebra: Thanks for the feedback! The issue of not properly exiting is now fixed in git by the following three commits: https://github.com/JabRef/jabref/commit/7ef2b3a01687648d7cdeca1498551426117bdf84 https://github.com/JabRef/jabref/commit/85363d077e42c28ffe7b3cac7cd854c8c8786273 https://github.com/JabRef/jabref/commit/fae290caa38aedbea3a2d093419e5ade4e62d620 I'd like to wait for a release including these fixes before pushing JabRef 4 to AUR. The other issue of long starting time seemed to be an issue with leftover configuration from an older JabRef version, I could fix it by cleaning that up. Ogion: Good point, JabRef 4 uses JavaFX now so that package is required. I will add it as a dependency.

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.

Rhinoceros commented on 2017-01-23 00:16 (UTC)

It looks like jabref.sh selects the latest version of java installed, rather than following the default, as set in archlinux-java. This can cause problems, because it selects the buggy version in my case [1]. I understand that jabref needs java 8, not java 7, but it might be worth following archlinux-java if a version 8 is selected, otherwise defaulting to one of the version 8s. Hard-coding the version seems wrong IMO. [1] https://bugs.archlinux.org/task/52625

danmc commented on 2016-12-15 15:57 (UTC)

The license has changed to MIT since version 3.6.

Bevan commented on 2016-07-16 09:23 (UTC)

@antony: This issue occured when there was already a "src" directory lying around from the last build. I now changed the PKGBUILD to only extract from the JAR what is needed which solves this issue.

anntzer commented on 2016-07-16 01:16 (UTC)

Cuurently fails to build: ==> Extracting sources... -> Extracting JabRef-3.5.jar with bsdtar com/: Can't replace existing directory with non-directory <elided> META-INF/maven/org.apache.httpcomponents/httpcore-nio/: Can't replace existing directory with non-directory bsdtar: Error exit delayed from previous errors. ==> ERROR: Failed to extract JabRef-3.5.jar Aborting... :: failed to build jabref package(s)

Bevan commented on 2016-07-15 22:20 (UTC)

@chicomag: The .jar file needs to be extracted because this is where we get the application icon get from, so extracting is actually intended. I don't see any disadvantage of this, because we package only what is needed (jar file, icon, start script, desktop file).

chicomag commented on 2016-07-15 22:00 (UTC)

Please, add noextract=("JabRef-${pkgver}.jar") to the PKGBUILD, because makepkg is extracting the file, and this is not intended.

koppor commented on 2016-06-05 17:43 (UTC)

BibLaTeX mode is a file-based mode now. Switch the mode using File -> "Switch to BibLaTeX mode". See also blog entry "April 19, 2016 – Release of JabRef 3.3" on http://www.jabref.org/blog/. (Sorry, currently no deep links possible).

Bevan commented on 2016-04-19 20:36 (UTC)

@Moneysac: Will push the new version in a moment but please use the "flag out-of-date" function in future. Regarding the BibLaTeX mode: I think the option just moved. In Preferences->General you can change the standard mode from BibTeX to BibLaTeX.

Moneysac commented on 2016-04-19 11:25 (UTC)

Version 3.3 is available. This package does not provide the biblatex mode which is important for online references.

anntzer commented on 2016-02-04 08:58 (UTC) (edited on 2016-02-04 08:58 (UTC) by anntzer)

jabref.sh should just force Java 8 (like the jabref-git package does: https://aur.archlinux.org/cgit/aur.git/tree/jabref.sh?h=jabref-git), otherwise jabref will fail to start on environments where Java 7 is the default.

zzjjzzgggg commented on 2016-01-11 13:54 (UTC)

It seems that the 3.2 version has been released. Shall we update this package now? http://www.jabref.org/

gbc921 commented on 2015-12-31 10:35 (UTC)

The link is working now. The problem seemed to on Sourceforge, that did not have any mirrors available at that time. Thanks,

gbc921 commented on 2015-12-31 00:13 (UTC)

Jabref source link on sourceforge is broken (even trying to download through the browser redirects to the initial page). I'm not sure if it is related to Sourceforge or upstream, will contact dev and post any news here.

Francois_B commented on 2015-12-17 14:03 (UTC)

That sounds. I tried to remove java7 before asking you but I still have few packages that depends on java7, and one critical for me. They may work with java8. I'll contact the maintainers to check that. note for others, small typo in the command path: /usr/lib/jvm/java-8-openjdk/jre/bin/java -jar /usr/share/java/jabref/JabRef-3.0.jar Thank you.

Bevan commented on 2015-12-16 14:58 (UTC) (edited on 2015-12-16 14:59 (UTC) by Bevan)

@Francois_B: It looks to me like you try running it with an older Java version. Please try running it by executing: /usr/lib/jvm/java-8-openjdk/bin/java -jar /usr/share/java/jabref/JabRef-3.0.jar For a permanent solution you may copy this into a custom start script in /usr/local/bin. But it may need adjustments on future JabRef updates. A clean solution would probably be to remove Java 7 from your system instead, if you do not need it for some reason.

Francois_B commented on 2015-12-16 14:51 (UTC)

I have this error: $ jabref Exception in thread "main" java.lang.UnsupportedClassVersionError: net/sf/jabref/JabRefMain : Unsupported major.minor version 52.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482) Anybody has an idea?

anntzer commented on 2015-12-15 19:34 (UTC)

In order to make this work even when the default Java installed is Java7, you may want to apply the following solution to jabref.sh: https://wiki.archlinux.org/index.php/Java#Launching_an_application_with_the_non-default_java_version

Bevan commented on 2015-12-01 10:08 (UTC)

@etienne: Ah, yet another Java application that needs this hack. Update will come in a minute. Thanks! :)

commented on 2015-12-01 10:06 (UTC)

On Gnome Shell the starter of Jabref is not the same as the one of the opened application, so I get two Jabref symbols in the starter panel when running. To avoid this, I simply had to add the line StartupWMClass=net-sf-jabref-JabRefMain to my jabref.desktop. To keep the change I copied /usr/share/applications/jabref.desktop to ~/.local/share/applications/ and applied the modification there.

Bevan commented on 2015-12-01 09:50 (UTC)

It seems like JabRef 3 deliberately requires Java 8: http://sourceforge.net/p/jabref/mailman/message/34657526/ I will change the dependencies accordingly. If people would rather stick with Java 7 they can get the old PKGBUILD for JabRef 2.11.1 here: https://aur.archlinux.org/cgit/aur.git/tree/?h=jabref&id=7cab7b0cfdc458d429f39fa80583eb22da48d08d

bayone commented on 2015-12-01 01:30 (UTC) (edited on 2015-12-01 01:36 (UTC) by bayone)

@Bevan: jabref 3.0 crashes with jre7-openjdk. I had to switch to jre8-openjdk to get it to work. It also says on sourceforge it requires java 1.8 (jre8).

Bevan commented on 2015-07-16 20:14 (UTC)

@torta: sourceforge.net seems to have problems with their load balancing at the moment. You may replace the first entry in source by http://ufpr.dl.sourceforge.net/project/jabref/jabref/2.10/JabRef-2.10.jar to work around this temporarily.

torta commented on 2015-07-16 20:06 (UTC)

@magno, i'am having the same problem. How do you solve it? ==> Validando las fuentes con sha1sums... JabRef-2.10.jar ... HA FALLADO jabref.sh ... Aprobado jabref.desktop ... Aprobado ==> ERROR: ¡Uno o más archivos no superaron el control de validación! ==> ERROR: Makepkg no ha podido compilar jabref.

hseara commented on 2015-07-11 18:12 (UTC)

I had little time to deal with the AUR4 migration lately. Therefore, I do not mind if you want to maintain it from this point on.

Bevan commented on 2015-07-08 12:21 (UTC)

I just migrated this package to AUR4. If the original maintainer (hseara) wants it back I will transfer the ownership back of course. Otherwise I will keep maintaining it.

hseara commented on 2015-02-11 17:27 (UTC)

@magno everything works fine. The problem is in your side ==> Retrieving sources... -> Downloading JabRef-2.10.jar... % Total % Received % Xferd Average Speed Time Time Time Current 100 14.5M 100 14.5M 0 0 8937k 0 0:00:01 0:00:01 --:--:-- 26.7M -> Found jabref.sh -> Found jabref.desktop ==> Validating source files with sha1sums... JabRef-2.10.jar ... Passed jabref.sh ... Passed jabref.desktop ... Passed

rmagno commented on 2015-02-10 16:54 (UTC)

==> Making package: jabref 2.10-2 (Tue Feb 10 16:52:07 WET 2015) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Found JabRef-2.10.jar -> Found jabref.sh -> Found jabref.desktop ==> Validating source files with sha1sums... JabRef-2.10.jar ... FAILED jabref.sh ... Passed jabref.desktop ... Passed ==> ERROR: One or more files did not pass the validity check! The build failed. If checksums are corrected with updpkgsums, the this error: install: cannot stat ‘images/JabRef-icon-48.png’: No such file or directory

hseara commented on 2014-05-08 06:41 (UTC)

As web search is not required feature to use jabref and to avoid enforcing too many dependencies on installation I have added "gsettings-desktop-schemas" package as an optional dependency. Thanks for the tip, I did not realize as I have whole gnome installed.

anntzer commented on 2014-05-07 22:11 (UTC)

Please add a dependency on gsettings-desktop-schemas, as jabref core-dumps in its absence when trying to perform a web search.

commented on 2013-04-05 04:28 (UTC)

users of non reparenting window managers such as dwm edit /usr/bin/jabref and add the line; export _JAVA_AWT_WM_NONREPARENTING=1