Re: [fedora-java] Circular dependencies in BuildRequires
by Sérgio Basto
Hi,
sorry I fail to send to ML in first time
On Seg, 2014-08-25 at 10:32 -0400, Michael Simacek wrote:
>
> ----- Original Message -----
> > From: "Sérgio Basto" <sergio(a)serjux.com>
> > To: "Michael Simacek" <msimacek(a)redhat.com>
> > Sent: Monday, August 25, 2014 3:33:46 PM
> > Subject: Re: [fedora-java] Circular dependencies in BuildRequires
> >
> > On Dom, 2014-08-24 at 13:18 -0400, Michael Simacek wrote:
> > > ----- Original Message -----
> > > > From: "Sérgio Basto" <sergio(a)serjux.com>
> > > > To: java-devel(a)lists.fedoraproject.org
> > > > Sent: Sunday, August 24, 2014 6:33:36 PM
> > > > Subject: [fedora-java] Circular dependencies in BuildRequires
> > > >
> > > > Hi,
> > > > I'm trying bring eclipse 4.4 to Fedora 20 [1]
> > > >
> > > > eclipse need jetty , jetty needs objectweb-asm 5 , normally I do :
> > > > fedpkg clone $package
> > > > cd $package
> > > > fedpkg switch-branch f21;fedpkg srpm ; mock -r fedora-20-x86_64
> > > > --no-clean --rebuild ./$package.fc21.src.rpm
> > > >
> > > > So I build objectweb-asm 5 , after that I can't almost build anything
> > > > because multiple dependencies
> > > >
> > > > jdependency [2] needs maven-plugin-tools , hawtjni, plexus-containers
> > > > that need be rebuild for new objectweb-asm
> > > >
> > > > hawtjni-1.10-2.fc21 [3] needs maven-plugin-tools
> > > >
> > > > maven-dependency-analyzer [4] needs maven-plugin-tools, hawtjni etc
> > > >
> > > > maven-plugin-tools can't be build because depends on maven
> > > >
> > > > maven depends on sisu, sisu-mojos and maven-wagon
> > > >
> > > > sisu depends on javapackages-tools-4.1.0
> > > >
> > > > javapackages-tools have an error that BuildRequires: javapackages-tools
> > > > >= 4.0.0 , impossible , but removing it depends on xmvn-resolve >=
> > > > 2.0.0
> > > >
> > > > repoquery --releasever=21 xmvn-resolve --source
> > > > xmvn-2.0.1-1.fc21.src.rpm
> > > > xmvn depends on maven >= 3.2.1-10 and sisu-mojos
> > > >
> > > > how we build it on a new arch or from scratch ? I try looking for
> > > > bootstrap some packages have references to bootstraping but no flags
> > > > on .spec
> > >
> > > We generally don't need to really build it from scratch. Most Java packages
> > > are noarch,
> > > so they already should work on the new arch. We just need to import them
> > > and then
> > > do proper rebuild from source when all the dependencies are satisfied.
> >
> > ok how I compile all in Fedora 20 ?
>
> I'm afraid for bootstraping from scratch you'll need some hack like:
> 1. Temporarily bundle pre-built JARs for the packages instead of building them from source so
> other pacakges can use them as a dependency.
> 2. When all the packages in the dependency cycle are built like this, remove bundled stuff
> and rebuild them properly from source, because now they can use dependencies from point 1.
>
> But I still don't understand why you want to do it from scratch. Why don't you
> use objectweb-asm3, javapackages-tools, sisu etc. from F20?
> You don't need newer versions of these, do you?
I need update sisu to have sisu-mojos for compile maven-3.2.2, that
requires it, and I'm stuck here btw.
I can't build sisu-0.2.1 on Fedora 20 but now, it seems to me, that is a
problem with %mvn_build macro rpm, because all packages that I want
rebuild ends with :
java.lang.RuntimeException: Failed to load XMvn configuration
I'm sending sisu-0.2.1 to build in copr for us see the build error on :
http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedor...
> >
> >
> > > Eclipse 4.4 is already available for Fedora 20 in Mat Booth's Copr:
> > > http://copr-fe.cloud.fedoraproject.org/coprs/mbooth/eclipse-luna/
> >
> > I don't like the approaching and have a second eclipse , I "need"
> > eclipse 4.4 as an upgrade of eclipse of the system
> >
> > please see status of my tries in
> > http://copr.fedoraproject.org/coprs/sergiomb/eclipse_4.4/builds/
> >
> > I understand that objectweb-asm only can build it after have
> > objectweb-asm3 , I try bootstrap some packages .
> >
> > Now in a circular dependencies of sisu and xmvn , xmvn > 2 needs sisu >
> > 0.2.1
> >
> > > > I try compile also objectweb-asm3 , objectweb-asm3.spec have a big bug
> > > > IMHO
> > > > # shade-jar utility used in this spec file needs this
> > > > BuildRequires: objectweb-asm3
> > > >
> > > > repoquery --releasever=21 -f /usr/bin/shade-jar --source
> > > > javapackages-tools-4.1.0-2.fc21.src.rpm
> > > >
> > > > but correctly, I think that should be:
> > > > BuildRequires: /usr/bin/shade-jar
> > > >
> > > > but we don't have any shade-jar in Fedora 20 , can we remove shade-jar
> > > > scripting from spec ?
> > >
> > > shade-jar script is part of javapackages-tools and it needs
> > > objectweb-asm3-processor to work,
> > > but javapackages-tools don't Require it (most likely to not increase
> > > install size).
> > >
> > >
> > > Michael Simacek
> > >
> > > >
> > > >
> > > > any feedback is welcome !
> > > >
> > > > Thanks,
> > > >
> > > > [1]
> > > > http://copr.fedoraproject.org/coprs/sergiomb/eclipse_4.4/builds/
> > > >
> > > > [2]
> > > > http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedor...
> > > > [3]
> > > > http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedor...
> > > > [4]
> > > > http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedor...
> > > >
> > > >
> > > > --
> > > > Sérgio M. B.
> > > >
> > > > --
> > > > java-devel mailing list
> > > > java-devel(a)lists.fedoraproject.org
> > > > https://admin.fedoraproject.org/mailman/listinfo/java-devel
> >
> > --
> > Sérgio M. B.
> >
> > --
> > Sérgio M. B.
--
Sérgio M. B.
9 years, 3 months
Circular dependencies in BuildRequires
by Sérgio Basto
Hi,
I'm trying bring eclipse 4.4 to Fedora 20 [1]
eclipse need jetty , jetty needs objectweb-asm 5 , normally I do :
fedpkg clone $package
cd $package
fedpkg switch-branch f21;fedpkg srpm ; mock -r fedora-20-x86_64
--no-clean --rebuild ./$package.fc21.src.rpm
So I build objectweb-asm 5 , after that I can't almost build anything
because multiple dependencies
jdependency [2] needs maven-plugin-tools , hawtjni, plexus-containers
that need be rebuild for new objectweb-asm
hawtjni-1.10-2.fc21 [3] needs maven-plugin-tools
maven-dependency-analyzer [4] needs maven-plugin-tools, hawtjni etc
maven-plugin-tools can't be build because depends on maven
maven depends on sisu, sisu-mojos and maven-wagon
sisu depends on javapackages-tools-4.1.0
javapackages-tools have an error that BuildRequires: javapackages-tools
>= 4.0.0 , impossible , but removing it depends on xmvn-resolve >=
2.0.0
repoquery --releasever=21 xmvn-resolve --source
xmvn-2.0.1-1.fc21.src.rpm
xmvn depends on maven >= 3.2.1-10 and sisu-mojos
how we build it on a new arch or from scratch ? I try looking for
bootstrap some packages have references to bootstraping but no flags
on .spec
I try compile also objectweb-asm3 , objectweb-asm3.spec have a big bug
IMHO
# shade-jar utility used in this spec file needs this
BuildRequires: objectweb-asm3
repoquery --releasever=21 -f /usr/bin/shade-jar --source
javapackages-tools-4.1.0-2.fc21.src.rpm
but correctly, I think that should be:
BuildRequires: /usr/bin/shade-jar
but we don't have any shade-jar in Fedora 20 , can we remove shade-jar
scripting from spec ?
any feedback is welcome !
Thanks,
[1]
http://copr.fedoraproject.org/coprs/sergiomb/eclipse_4.4/builds/
[2]
http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedor...
[3]
http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedor...
[4]
http://copr-be.cloud.fedoraproject.org/results/sergiomb/eclipse_4.4/fedor...
--
Sérgio M. B.
9 years, 3 months
icedtea-web crash
by gil
hi
when i try to use http://digiland.libero.it/chat.php
icedtea-web crash [1]
any ideas?
thanks in advance
regards
gil
[1] The folloing exception has occured. For more information, try to
launch the browser from the command line and examine the output.
For even more information you can visit
http://icedtea.classpath.org/wiki/IcedTea-Web and follow the steps
described there on how to obtain necessary information to file bug
Additional information may be available in the console or logs. Even
more information is available if debugging is enabled.
Another available info:
IcedTea-Web Plugin version: 1.5 (fedora-2.fc19-i386)
16/08/14 14.16
Exception was:
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could
not initialize applet. For more information click "more information button".
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:746)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:675)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:908)
Caused by: net.sourceforge.jnlp.LaunchException: The applet is signed
but its manifest specifies Sandbox permissions. This is not yet
supported. Try running the applet again, but choose the Sandbox run option.
at
net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:206)
at
net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkAll(ManifestAttributesChecker.java:79)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.
(JNLPClassLoader.java:288)
at
net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:351)
at
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:418)
at
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:394)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:711)
... 2 more
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization
Error: Run in Sandbox call performed too late. The classloader was
notified to run the applet sandboxed, but security settings were already
initialized.
at
net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.setRunInSandbox(JNLPClassLoader.java:2385)
at
net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:203)
... 8 more
This is the list of exceptions that occurred launching your applet.
Please note, those exceptions can originate from multiple applets. For a
helpful bug report, be sure to run only one applet.
1) at 16/08/14 14.16
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Run
in Sandbox call performed too late. The classloader was notified to run
the applet sandboxed, but security settings were already initialized.
at
net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.setRunInSandbox(JNLPClassLoader.java:2385)
at
net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:203)
at
net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkAll(ManifestAttributesChecker.java:79)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.
(JNLPClassLoader.java:288)
at
net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:351)
at
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:418)
at
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:394)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:711)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:675)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:908)
2) at 16/08/14 14.16
net.sourceforge.jnlp.LaunchException: The applet is signed but its
manifest specifies Sandbox permissions. This is not yet supported. Try
running the applet again, but choose the Sandbox run option.
at
net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:206)
at
net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkAll(ManifestAttributesChecker.java:79)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.
(JNLPClassLoader.java:288)
at
net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:351)
at
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:418)
at
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:394)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:711)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:675)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:908)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization
Error: Run in Sandbox call performed too late. The classloader was
notified to run the applet sandboxed, but security settings were already
initialized.
at
net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.setRunInSandbox(JNLPClassLoader.java:2385)
at
net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:203)
... 8 more
3) at 16/08/14 14.16
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could
not initialize applet. For more information click "more information button".
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:746)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:675)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:908)
Caused by: net.sourceforge.jnlp.LaunchException: The applet is signed
but its manifest specifies Sandbox permissions. This is not yet
supported. Try running the applet again, but choose the Sandbox run option.
at
net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:206)
at
net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkAll(ManifestAttributesChecker.java:79)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.
(JNLPClassLoader.java:288)
at
net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:351)
at
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:418)
at
net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:394)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:711)
... 2 more
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization
Error: Run in Sandbox call performed too late. The classloader was
notified to run the applet sandboxed, but security settings were already
initialized.
at
net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.setRunInSandbox(JNLPClassLoader.java:2385)
at
net.sourceforge.jnlp.runtime.ManifestAttributesChecker.checkPermissionsAttribute(ManifestAttributesChecker.java:203)
... 8 more
9 years, 3 months
/usr/lib/jni support in Fedora
by Florian Weimer
As far as I can tell, currently, System.loadLibrary() is mostly unusable
for Java libraries because they cannot influence the library search
path. If you want to transparently load a DSO, you need to use
System.load() and hard-code the path. This probably means patching
upstream sources.
Debian patches the default search path so that System.loadLibrary()
searches /usr/lib/jni for DSOs with native code. This means that
classes which call System.loadLibrary() just work, assuming that the
Debian package installs its DSOs into /usr/lib/jni.
Can we do something similar in Fedora? We probably want /usr/lib/jni
and /usr/lib64/jni, for consistency with the rest of the system.
The upstream default search path starts with
"/usr/java/packages/lib/amd64" (and variants for other architectures),
but this isn't mentioned in the Fedora guidelines. I'm also not sure if
we want to use this file system location because it doesn't look
particularly FHS-compliant. But the proprietary JDKs could install a
symlink there so that /usr/lib{,64}/jni is searched as well.
--
Florian Weimer / Red Hat Product Security
9 years, 4 months