Spec Name or Url: http://spindazzle.org/FE/devel/jogl.spec SRPM Name or Url: http://spindazzle.org/FE/devel/jogl-1.1.1-1.src.rpm Description: Java bindings for the OpenGL API The JOGL Project hosts a reference implementation of the Java bindings for OpenGL API, and is designed to provide hardware-supported 3D graphics to applications written in the Java programming language. Is is part of a suite of open-source technologies initiated bu the Game Technology Group at Sun Microsystems. JOGL provides full access to the APIs in the OpenGL 1.5 specification as well as nearly all vendor extensions, and integrated with the AWT and Swing widget sets. This package includes both jar files and native (gcj) code. It will work with both the gcj and Sun VM alternatives. See http://fitzsim.org/blog/?p=7 for some detail.
*** Bug 167481 has been marked as a duplicate of this bug. ***
Why did you import the package into CVS without anybody else reviewing your package? The rules exist for a reason and apply to everyone now. http://fedoraproject.org/wiki/Extras/NewPackageProcess Please review the Extras package process
Ok, my bad. Sorry. It's a bit confusing. At first somebody told me to apply for CVS access. I was granted access yesterday, and then was pointed at http://fedoraproject.org/wiki/Extras/Contributors Which says post your first SRPM and then apply for access. But I've already been given access so I thought I could skip to step 11. So, should I remove it now (although I don't know how)? Or maybe somebody can review it quickly? Thanks.
You can remove the "Epoch: 0" from FC3+ packages, and also the "0:" in the versioned dependency. Epoch in versioned dependencies are needed in cases however where the epoch is greater than zero. %ghost %doc %{_javadocdir}/%{name} What is the purpose of this? This looks extremely odd. I didn't test a build yet and I don't know java packaging too well, so hopefully we can get more input from someone else.
+ cd make + ant -Duser.home=/home/builder/rpmbuild/SOURCES linux javadoc.dev.x11 /usr/bin/build-classpath: error: could not find jaxp_parser_impl Java extension for this JVM /usr/bin/build-classpath: error: All specified jars were not found Buildfile: build.xml I noticed this error when building other java things like bootchart. It doesn't seem to be fatal to the build process. Do we have any package that contains this, and what does it do, and why doesn't the build fail? Should it become a BuildRequires?
(In reply to comment #4) > You can remove the "Epoch: 0" from FC3+ packages, and also the "0:" in the > versioned dependency. Epoch in versioned dependencies are needed in cases > however where the epoch is greater than zero. Ok. I was just following the practice established in all of the FC java packges. > %ghost %doc %{_javadocdir}/%{name} > What is the purpose of this? This looks extremely odd. To be honest, I'm not sure. It's just established practice for FC java packages. > I didn't test a build yet and I don't know java packaging too well, so hopefully > we can get more input from someone else. I'll add fitzsim to CC. I hope he doesn't mind :-)
(In reply to comment #5) > + cd make > + ant -Duser.home=/home/builder/rpmbuild/SOURCES linux javadoc.dev.x11 > /usr/bin/build-classpath: error: could not find jaxp_parser_impl Java extension > for this JVM > /usr/bin/build-classpath: error: All specified jars were not found > Buildfile: build.xml > > I noticed this error when building other java things like bootchart. It doesn't > seem to be fatal to the build process. Do we have any package that contains > this, and what does it do, and why doesn't the build fail? Should it become a > BuildRequires? ant is generating this error. jaxp_parser_impl is managed by alternatives and provided by multiple packages, including java-1.4.2-gcj-compat and xerces-j2. I don't understand why it's not set up properly in this build environment. The reason the build doesn't fail is because libgcj.jar contains all of the classes provided by jaxp_parser_impl. java-1.4.2-gcj-compat simply symlinks jaxp_parser_impl.jar to libgcj.jar. Perhaps the build would fail if you tried building using the Sun VM alternative. I'm hoping fitzsim has some insight into why the jamp_parser_impl alternative is broken.
(In reply to comment #6) > (In reply to comment #4) > > > %ghost %doc %{_javadocdir}/%{name} > > What is the purpose of this? This looks extremely odd. > > To be honest, I'm not sure. It's just established practice for FC java > packages. The original intention in JPackage (where the practice was inherited from) was to be able to install multiple versions of javadocs for a package in parallel, and to have an unversioned symlink pointing at the last installed version. However, there are several major flaws with the current JPackage (and FC, and the one in this package) implementation, to name a few: - It doesn't work. The symlinks cause a rpm conflict between different versions of the javadoc packages, even when %ghost'd. - It requires write access to %{_javadocdir} in %post and expects to succeed -> breaks in %{_netsharedpath} setups where /usr/share is (NFS) mounted read only. - The idea of "last version installed" is not very good in the first place. "Newest" could be slightly more useful. However, the unversioned %{_javadocdir}/%{name} is very useful eg. for javadoc crosslinking between packages as well as bookmarking, IDE config etc. For now, I'd suggest packaging %{_javadocdir}/%{name} as usual (not %ghost), and removing the %post javadoc scriptlet altogether.
(In reply to comment #8) > For now, I'd suggest packaging %{_javadocdir}/%{name} as usual (not %ghost), > and removing the %post javadoc scriptlet altogether. Ok, done. I've placed a revised spec file and srpm here: http://spindazzle.org/FE/devel
Looks good enough, go ahead and import the changes. Don't forget to add %{?dist} after the number in the Release tag before you request another build. Do you want this in FE4 too?
(In reply to comment #10) > Looks good enough, go ahead and import the changes. Don't forget to add > %{?dist} after the number in the Release tag before you request another build. Thanks! Done. > Do you want this in FE4 too? No, FE5 is fine for now. Thanks again.
*** This bug has been marked as a duplicate of bug 690282 ***