Introduction
by Akshat Sharma
Hi,
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.
Thank you
Fas: akshatsharma5274
2 years, 4 months
javapackages-tools auto Requires
by Markku Korkeala
Hi,
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
error:
$ clojure
/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
and javapackages-tools.
https://fedora-java.github.io/howto/latest/#dependency_handling
Has this changed and should I add the explicit requirement for
javapackages-tools ?
Dependencies for clojure package are:
$ rpm -qR clojure
/usr/bin/bash
java-headless >= 1:1.8
javapackages-filesystem
mvn(org.clojure:core.specs.alpha)
mvn(org.clojure:spec.alpha)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
Best regards,
Markku Korkeala
2 years, 4 months
Orphaning some packages
by Mat Booth
Hi all,
I no longer have the bandwidth to maintain so many Eclipse plug-ins,
so I just orphaned the following:
eclipse-cdt
eclipse-remote
swt-chart
freemarker
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.
--
Mat Booth
http://fedoraproject.org/get-fedora
2 years, 4 months
jansi 2.x and jline 3.x
by Jerry James
Hi all,
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:
https://copr.fedorainfracloud.org/coprs/jjames/scala/
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
Provides:
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
libjansi.so()(64bit)
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
"Requires: jansi"?
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
latest versions?
I appreciate any thoughts anyone has on the matter. Regards,
--
Jerry James
http://www.jamezone.org/
2 years, 4 months
Macros controlling the source/target/release level flags for javac
by Jiri Vanek
Hi!
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.
Thoughts?
J.
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com M: +420775390109
2 years, 5 months
