N00b questions - I need help getting started on packaging.
by Ludovic Hirlimann
Hi,
I'm ludo - I'd like to package josm - which requires Apcahe derby and apache-common-jcs-*.
I've managed to compile derby on my fedora 32 vagrant host.
For that I had to force the compiler to not be the 1.8 using the JAVA_HOME variable so ants would use the compiler from the 11-openjdk-devel package.
I'm reading https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/ and https://fedora-java.github.io/howto/latest/.
I'm far from being a java programmer and this is my first attempt at building a linux package. And that's why I'm writing this email.
I've got some inspiration from https://src.fedoraproject.org/rpms/derby/pull-request/1#request_diff as derby used to be packaged for fedora/RHEL in the past.
Looking at that spec file, I don't see how one can specify which version of javac to use and force while buidling. I also don't understand the need to the patch files nor do I get the fact that this ant build needs maven magic in the packaging.
I'll gladly RTFM anything sent to me, but I'd like to figure out the next steps in order to package derby , now that I have a build that doesn't fail.
Thanks in advance for your patience and time
Ludovic
3 years, 4 months
Strange Java package build failures (Error in <unknown> scriptlet ?)
by Fabio Valentini
Hi everybody,
Since ~2 days ago, the rawhide koji buildroot has exhibited some
*really weird* issues when building Java packages with maven (when
building packages locally with "mock -r fedora-rawhide-x86_64
--enablerepo local foo.src.rpm").
During installation of the build dependencies, some random (?) Java
package will have a scriptlet failure like this: "Error in <unknown>
scriptlet in rpm package mockito" (the package that this error occurs
in is not always the same). This is always the last scriptlet run
before the "Verifying" stage of "dnf install".
Then, later, during execution of %build, the following errors show up,
which make the it fail:
/usr/share/maven/bin/mvn: Failed to set JAVACMD
The JAVA_HOME environment variable is not defined correctly
This environment variable is needed to run this program
NB: JAVA_HOME should point to a JDK not a JRE
Sometimes, scrubbing the mock buildroot makes the next build succeed,
sometimes it doesn't. I tried entering the buildroot with "mock shell"
but it didn't yield any useful information.
I see that the scripts setting up JAVA_HOME etc. try to find a java +
javac executable, but they're all there, and the alternatives setup
also looks sane (no broken links in /etc/alternatives).
The only Java related updates I see in the buildroot for the "critical
time frame" are builds of java-11-openjdk, but I'm not sure how they
could have introduced such inconsistently buggy buildroot behaviour :(
Does anybody have an idea what might be the problem here? It's really
annoying to be unable to build Java packages locally most of the time
(curiously, I haven't seen this issue happen in any koji builds yet).
Fabio
3 years, 7 months
Giving up on the jNeuroML bits: will use COPR if possible
by Ankur Sinha
Hello,
First, thanks Fabio and the others for working on the Java packages. I'm
sure we're all most grateful for the mammoth amount of work that you've
put in to keep things moving.
I'd joined the Java SIG primarily to get jNeuroML into Fedora, which
underlies most of the NeuroML stack[1] along with other java
neuroscience tools. After spending some time to try and get the deps
unorphaned etc., I've realised that this is far beyond my capabilities,
both time and knowledge wise---it's just too much work to
update/patch/drop/unorphan deps. (And this is without the fiasco that is
gradle.)
There are other neuro-sig packages that are suffering the same fate
too---their dep trees are just too large + complex for someone not
working with them actively to take on. Zbyszek also orphaned hdfview,
for example:
https://src.fedoraproject.org/rpms/hdfview
So, I'm giving up on getting all of this into Fedora. We'll see if they
can go into COPR where we may be able to bundle deps and so on. Stuff
that's too hard for COPR even will just have to be documented so that
users can install it all themselves.
Thanks again, I'll stick around to help where I can, and if there is a
neuro-sig package that can get into Fedora relatively easily, I will of
course do that.
[1] https://github.com/NeuroML/jNeuroML
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
3 years, 7 months