Bug 276163 - archivers/snappy-java: bad dependency syntax in BUILD_DEPENDS
Summary: archivers/snappy-java: bad dependency syntax in BUILD_DEPENDS
Status: Closed Unable to Reproduce
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-01-06 23:51 UTC by dougs@dawnsign.com
Modified: 2024-01-26 11:16 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (language.devel)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dougs@dawnsign.com 2024-01-06 23:51:04 UTC
Ran into issue while rebuilding snappy-java as follows:



# make reinstall clean
===>  Deinstalling for snappyjava
===>   Deinstalling snappyjava-1.1.10.5
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        snappyjava: 1.1.10.5

Number of packages to be removed: 1

The operation will free 2 MiB.
[1/1] Deinstalling snappyjava-1.1.10.5...
[1/1] Deleting files for snappyjava-1.1.10.5: 100%
===>   snappyjava-1.1.10.5 depends on executable: cmake - found
===>   snappyjava-1.1.10.5 depends on executable: sbt - found
Error: bad dependency syntax in BUILD_DEPENDS
expecting: pattern:origin[@flavour][:target]
got: /bin/java:
===>   snappyjava-1.1.10.5 depends on package: gmake>=4.3 - found
Errors with dependencies.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/archivers/snappy-java
*** Error code 1

Stop.
make: stopped in /usr/ports/archivers/snappy-java
#

This is on FreeBSD 13.2-RELEASE-p8. Running unifi7 which requires snappyjava. openjdk17 is currently installed.
Comment 1 Ronald Klop freebsd_committer freebsd_triage 2024-01-11 13:09:53 UTC
(In reply to dougs@dawnsign.com from comment #0)
I can't reproduce. Do you have more information?

root@freebsd:/usr/ports/archivers/snappy-java # make reinstall clean
===>  Deinstalling for snappyjava
===>   Deinstalling snappyjava-1.1.10.5
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
	snappyjava: 1.1.10.5

Number of packages to be removed: 1

The operation will free 2 MiB.
[1/1] Deinstalling snappyjava-1.1.10.5...
[1/1] Deleting files for snappyjava-1.1.10.5: 100%
===>  Installing for snappyjava-1.1.10.5
===>  Checking if snappyjava is already installed
===>   Registering installation for snappyjava-1.1.10.5
Installing snappyjava-1.1.10.5...
===>  Cleaning for sbt-1.9.8
===>  Cleaning for openjdk8-8.392.08.1_1
===>  Cleaning for zip-3.0_1
===>  Cleaning for cups-2.4.7_1
===>  Cleaning for avahi-app-0.8_1
===>  Cleaning for intltool-0.51.0_1
===>  Cleaning for p5-XML-Parser-2.46
===>  Cleaning for gobject-introspection-1.78.1_1,1
===>  Cleaning for libdaemon-0.14_1
===>  Cleaning for dbus-glib-0.112
===>  Cleaning for gnome_subr-1.0
===>  Cleaning for libXi-1.8,1
===>  Cleaning for libXtst-1.2.3_2
===>  Cleaning for libinotify-20211018
===>  Cleaning for alsa-lib-1.2.10
===>  Cleaning for giflib-5.2.1
===>  Cleaning for javavmwrapper-2.7.9_1
===>  Cleaning for dejavu-2.37_3
===>  Cleaning for mkfontscale-1.2.1
===>  Cleaning for java-zoneinfo-2021.e
===>  Cleaning for snappyjava-1.1.10.5
root@freebsd:/usr/ports/archivers/snappy-java #
Comment 2 Ronald Klop freebsd_committer freebsd_triage 2024-01-11 13:16:23 UTC
Running this again after clean also builds fine.

I'm doing this on 14.0/amd64 with an up-to-date portstree of a couple of minutes ago.
Do you have any JAVA_HOME var set or something similar?

Pasting the output which overlaps with your comment.

root@freebsd:/usr/ports/archivers/snappy-java # make reinstall clean
===>  Deinstalling for snappyjava
===>   Deinstalling snappyjava-1.1.10.5
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
	snappyjava: 1.1.10.5

Number of packages to be removed: 1

The operation will free 2 MiB.
[1/1] Deinstalling snappyjava-1.1.10.5...
[1/1] Deleting files for snappyjava-1.1.10.5: 100%
===>  License APACHE20 accepted by the user
===>   snappyjava-1.1.10.5 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by snappyjava-1.1.10.5 for building
===>  Extracting for snappyjava-1.1.10.5
=> SHA256 Checksum OK for xerial-snappy-java-v1.1.10.5_GH0.tar.gz.
=> SHA256 Checksum OK for snappy-java-repository-1.1.10.5.tar.gz.
=> SHA256 Checksum OK for xerial-snappy-java-v1.1.10.5_GH0.tar.gz.
=> SHA256 Checksum OK for google-snappy-1.1.10_GH0.tar.gz.
=> SHA256 Checksum OK for google-benchmark-d572f47_GH0.tar.gz.
=> SHA256 Checksum OK for google-googletest-b796f7d_GH0.tar.gz.
=> SHA256 Checksum OK for kiyo-masui-bitshuffle-0.3.4_GH0.tar.gz.
/bin/mkdir -p /usr/ports/archivers/snappy-java/work/snappy-java-1.1.10.5/target
/bin/rm -f /usr/ports/archivers/snappy-java/work/snappy-java-1.1.10.5/sbt
cp -f /usr/ports/distfiles/google-snappy-1.1.10_GH0.tar.gz /usr/ports/archivers/snappy-java/work/snappy-java-1.1.10.5/target/snappy-1.1.10.tar.gz
cp -f /usr/ports/distfiles/kiyo-masui-bitshuffle-0.3.4_GH0.tar.gz /usr/ports/archivers/snappy-java/work/snappy-java-1.1.10.5/target/bitshuffle-0.3.4.tar.gz
(cd /usr/ports/archivers/snappy-java/work/snappy-java-1.1.10.5/google_benchmark &&  /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&  /usr/bin/find -Ed $1 $3 \(   -type d -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} +  -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE . /usr/ports/archivers/snappy-java/work/snappy-java-1.1.10.5/target/snappy-1.1.10/third_party/benchmark)
(cd /usr/ports/archivers/snappy-java/work/snappy-java-1.1.10.5/google_googletest &&  /bin/sh -c '(/usr/bin/find -Ed $1 $3 | /usr/bin/cpio -dumpl $2 >/dev/null 2>&1) &&  /usr/bin/find -Ed $1 $3 \(   -type d -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 755 "$@"'\'' . {} +  -o -type f -exec /bin/sh -c '\''cd '\''$2'\'' && chmod 0644 "$@"'\'' . {} + \)' COPYTREE_SHARE . /usr/ports/archivers/snappy-java/work/snappy-java-1.1.10.5/target/snappy-1.1.10/third_party/googletest)
===>  Patching for snappyjava-1.1.10.5
===>  Applying FreeBSD patches for snappyjava-1.1.10.5 from /usr/ports/archivers/snappy-java/files
===>   snappyjava-1.1.10.5 depends on executable: cmake - found
===>   snappyjava-1.1.10.5 depends on executable: sbt - found
===>   snappyjava-1.1.10.5 depends on file: /usr/local/openjdk8/bin/java - found
===>   snappyjava-1.1.10.5 depends on package: gmake>=4.3 - found
===>  Configuring for snappyjava-1.1.10.5
===>  Building for snappyjava-1.1.10.5
Comment 3 dougs@dawnsign.com 2024-01-12 01:56:29 UTC
I seem to recall having an issue with openjdk17 a few months ago and mucking around. I checked /.cshrc for the presence of JAVA_HOME or similar. The set path is as follows:

set path = ($JAVA_HOME/bin /sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin $HOME/bin)

# echo $JAVA_HOME
/usr/local/openjdk17

Unifi appears to make use of Java in a nonstandard way so none of my Googling is helping me in this respect.

Does snappy-java function with OpenJDK17?
Comment 4 Ronald Klop freebsd_committer freebsd_triage 2024-01-12 06:36:17 UTC
(In reply to dougs@dawnsign.com from comment #3)
AFAIK Snappy-Java works fine with jdk17.

Can you update your ports tree? Make clean in the snappy-Java dir and try again?
Comment 5 dougs@dawnsign.com 2024-01-16 19:26:17 UTC
After a ports update via gitup, running 'make index' produces this error:

make_index: /usr/ports/archivers/javatar: no entry for /bin/java:
 Done.

I'm not sure if this is related to the issue at hand.


Next, doing a 'make clean':

# cd /usr/ports/archivers/snappy-java
# make clean
/usr/ports/Mk/Scripts/depends-list.sh: 2: parameter not set
===>  Cleaning for snappyjava-1.1.10.5
# make clean-depends
/usr/ports/Mk/Scripts/depends-list.sh: 2: parameter not set
#

I don't know how to interpret this. Do you?
Comment 6 Ronald Klop freebsd_committer freebsd_triage 2024-01-16 21:59:07 UTC
Would this help? If I read Mk/bsd.java.mk again the only value JAVA_BUILD can have would be "jdk".

diff --git a/archivers/snappy-java/Makefile b/archivers/snappy-java/Makefile
index bd46c3334633..f7be155faf7d 100644
--- a/archivers/snappy-java/Makefile
+++ b/archivers/snappy-java/Makefile
@@ -39,7 +39,7 @@ GH_TUPLE=     google:snappy:${DISTVERSION:R}:google \
                kiyo-masui:bitshuffle:${BITSHUFFLE_V}:masui
 
 USE_JAVA=      yes
-JAVA_BUILD=    jre # prevent JAVA_RUN via bsd.java.mk
+JAVA_BUILD=    jdk # prevent JAVA_RUN via bsd.java.mk
 USE_LDCONFIG=  yes
 MAKE_ARGS+=    CXX="${CXX}"
 TEST_TARGET=   test
Comment 7 Ronald Klop freebsd_committer freebsd_triage 2024-01-17 09:02:23 UTC
As I can't reproduce it I sent a mail to freebsd-ports@ and freebsd-java@ to ask if others understand what is going on.
Comment 8 Ronald Klop freebsd_committer freebsd_triage 2024-01-25 22:41:27 UTC
(In reply to dougs@dawnsign.com from comment #5)
Did you get further with building ports already or are you still stuck?

As you had a similar error about "/bin/java" with javatar and javatar is totally unrelated to snappy-java (AFAIS) I'm inclined to suspect that you have something in your local setup which makes the system think java is in /bin/java.

I suspect an empty variable which make $BLA/bin/java expand to /bin/java.

# echo $BLA/bin/java
/bin/java

But I don't have further info to prove my suspicion. Sorry.

I got no reply on my mails to the mailinglists.

If no further info appears I would vote for closing the issue as "Unable to Reproduce" and re-open it if needed in the future.
Comment 9 dougs@dawnsign.com 2024-01-25 23:06:48 UTC
(In reply to Ronald Klop from comment #8)

Go ahead and mark this as unable to reproduce- I have reinstalled FreeBSD from scratch and everything is working as intended. I am sure I must have changed a Java-related variable that borked things. Too bad I cannot recall exactly what changes were made! :(

Thank you for looking into this- much appreciated!
Comment 10 Ronald Klop freebsd_committer freebsd_triage 2024-01-26 11:16:33 UTC
(In reply to dougs@dawnsign.com from comment #9)
👍