I am orphaning jython and the following other Java packages that
require or is required by it:
My name is Akshat Sharma. I am an student and developer from India. I know java and want to contribute to fedora organization to explore the various capacities of java beyond my current use case. I am relatively new to open source and development in java but i will always try to contribute and learn to my capacity.
I just got a bug report for clojure package that clojure is unable to
start after installing it in a F33 container, it reports the following
/usr/bin/clojure: line 8: /usr/share/java-utils/java-functions: No such
file or directory
The /usr/bin/clojure is wrapper script generated with %jpackage_script
macro. The clojure package explicit requirement for javapackages-tools
package (which provides the /usr/share/java-utils/java-functions file)
was removed little while ago, as I thought it would be auto required
as stated in the Java howto:
The requires generator also always generates Requires on java-headless
Has this changed and should I add the explicit requirement for
Dependencies for clojure package are:
$ rpm -qR clojure
java-headless >= 1:1.8
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
I no longer have the bandwidth to maintain so many Eclipse plug-ins,
so I just orphaned the following:
Eclipse CDT and Linuxtools may still be installed through the Eclipse
Marketplace by going to "Help" -> "Eclipse Marketplace" and searching
for your favourite plug-ins there.
I would like to keep jacop in Fedora. It is in danger of removal, due
to the orphaning of scala. I've taken a look at keeping scala in
Fedora, and updating it to its most recent version; see:
One issue is that recent scala needs jline 3.x (we have 2.x in
Rawhide), and jline 3.x needs jansi 2.x (we have 1.x in Rawhide).
Neither is backwards compatible with its previous major version. I
have made jansi 1.x/2.x and jline 2.x/3.x parallel installable, but
there is still at least one issue. The current jansi package
jansi = 1.18-5.fc33
mvn(org.fusesource.jansi:jansi) = 1.18
mvn(org.fusesource.jansi:jansi-project:pom:) = 1.18
mvn(org.fusesource.jansi:jansi:pom:) = 1.18
osgi(org.fusesource.jansi) = 1.18.0
The jansi2 package on COPR Provides:
jansi2 = 2.1.0-1.fc34
jansi2(x86-64) = 2.1.0-1.fc34
mvn(org.fusesource.jansi:jansi) = 2.1.0
mvn(org.fusesource.jansi:jansi:pom:) = 2.1.0
osgi(org.fusesource.jansi) = 2.1.0
There is overlap between the Provides, albeit with different version
numbers. How should this be handled? I guess that packages that need
version 1.x would have to include "BuildRequires: jansi < 2" and
Also, is it better to keep the existing jansi and jline packages, and
add jansi2 and jline3 packages as I have done on COPR, or would it be
better to add jansi1 and jline2 packages containing the current
contents of jansi and jline, and then move jansi and jline to their
I appreciate any thoughts anyone has on the matter. Regards,
I had risen this topic during jdk11 bump. but it somehow get lost.
The idea is, to provide rpm macros, keeping the default source/target eventually - for jdk11 and up -the release - numbers for javac to use.
Then to provide tooling, which will help packagers to use them - for ant and maven it should be simple. For others, probably nothing to do on our side, each packager will be able to patch/sed theirs builds as necessary (Still it will help a lot for future).
I do not know how to provide them as default (except hardcoding in xmvn, and only allow to disable them on demand).
This will smooth the bump to jdk17 in f36 really a lot.
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com M: +420775390109