Hide Forgot
Spec URL: http://konradm.fedorapeople.org/fedora/SPECS/jna.spec SRPM URL: http://konradm.fedorapeople.org/fedora/SRPMS/jna-3.0.2-1.fc8.src.rpm Description: JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code. JNA's design aims to provide native access in a natural way with a minimum of effort. No boilerplate or generated code is required. While some attention is paid to performance, correctness and ease of use take priority.
I just tried to rebuild this on dist-f9, however it failed. http://koji.fedoraproject.org/koji/taskinfo?taskID=497773 Note: As you are in cvsextras group, you can try to rebuild your arbitrary srpm on koji like: $ koji build --scratch <target> <srpm_you_want_to_try> Currently <target> can be either dist-f9, dist-f8-updates-candidate or dist-fc7-updates-candidate. If the build is successful, the rebuilt binary rpms (and some logs) are put under http://koji.fedoraproject.org/scratch/<your_FAS_name>/task_<taskid>/
Whoops, forgot to check BRs it seems. Sorry. New URLs: Spec URL: http://konradm.fedorapeople.org/fedora/SPECS/jna.spec SRPM URL: http://konradm.fedorapeople.org/fedora/SRPMS/jna-3.0.2-2.fc8.src.rpm
Well, I am not familiar with java, so I must ask you some question. * ExcludeArch - Now "java-devel > 1.6" is provided by java-1.7.0-icedtea for all archs and this should build on all archs. - By the way now Fedora ships "java-1.6.0-openjdk" and I am not sure which mock tries to use by "BuildRequires: java-devel >= 1.6". * libffi - From build.log jna uses internall libffi, however now (at least on rawhide) libffi is system-widely provided. Would you patch against jna to use system wide libffi? * Fedora specific compilation flags - From build.log, Fedora specific compilation flags are not honored. (This compilation flags can be checked by $ rpm --eval %optflags, while build.log shows as below:) ------------------------------------------------------------------ 192 [exec] if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/builddir/build/BUILD/jna-3.0.2/native/libffi -I. -I. -I/builddir/build/BUILD/jna-3.0.2/native/libffi/include -Iinclude -I/builddir/build/BUILD/jna-3.0.2/native/libffi/src -Wall -g -fexceptions -g -O2 -MT src/debug.lo -MD -MP -MF "$depbase.Tpo" -c -o src/debug.lo /builddir/build/BUILD/jna-3.0.2/native/libffi/src/debug.c; \ ------------------------------------------------------------------ * debuginfo? strip binaries? - From build.log ------------------------------------------------------------------ 240 [exec] gcc -o /builddir/build/BUILD/jna-3.0.2/build/native/libtestlib.so -shared -Wl,-soname,/builddir/build/BUILD/jna-3.0.2/build/native/libtestlib.so -static-libgcc /builddir/build/BUILD/jna-3.0.2/build/native/testlib.o 241 [mkdir] Created dir: /builddir/build/BUILD/jna-3.0.2/build/classes/com/sun/jna/linux-i386 242 [copy] Copying 1 file to /builddir/build/BUILD/jna-3.0.2/build/classes/com/sun/jna/linux-i386 243 [mkdir] Created dir: /builddir/build/BUILD/jna-3.0.2/build.eclipse/classes/com/sun/jna/linux-i386 244 [copy] Copying 1 file to /builddir/build/BUILD/jna-3.0.2/build.eclipse/classes/com/sun/jna/linux-i386 245 [jar] Building jar: /builddir/build/BUILD/jna-3.0.2/build/linux-i386.jar ------------------------------------------------------------------ When Fedora compilation flags are correctly honored, libtestlib.so is created with debug flag "-g", and this will not be stripped as this library is packaged as jar style. - Are there any means to create "debuginfo" rpm for this library? - If not, should this library be stripped or not?
(In reply to comment #3) > Well, I am not familiar with java, so I must ask you > some question. > > * ExcludeArch > - Now "java-devel > 1.6" is provided by java-1.7.0-icedtea > for all archs and this should build on all archs. The ExcludeArch is there from when I was trying to build in koji as dist-f8 and didn't want to hit PPC build hosts. It is a mistake I will remedy. > - By the way now Fedora ships "java-1.6.0-openjdk" and > I am not sure which mock tries to use by "BuildRequires: > java-devel >= 1.6". Shouldn't matter I don't think. > * libffi > - From build.log jna uses internall libffi, however now > (at least on rawhide) libffi is system-widely provided. > Would you patch against jna to use system wide libffi? Yes. > * Fedora specific compilation flags > - From build.log, Fedora specific compilation flags are > not honored. Will fix. > * debuginfo? strip binaries? > ... > When Fedora compilation flags are correctly honored, > libtestlib.so is created with debug flag "-g", and this will not be > stripped as this library is packaged as jar style. > - Are there any means to create "debuginfo" rpm for this library? > - If not, should this library be stripped or not? I don't know how this should be handled. I will fix the other problems and then ask the java devel list about this sort of thing. Thank you for the very thorough feedback!
If there is no way to created debuginfo rpm, for now please use Fedora specific compilation flags with debug option "-g" _removed_ and upload the new srpm.
New URLs: Spec URL: http://konradm.fedorapeople.org/fedora/SPECS/jna.spec SRPM URL: http://konradm.fedorapeople.org/fedora/SRPMS/jna-3.0.2-3.fc8.src.rpm These build on koji (see http://koji.fedoraproject.org/koji/taskinfo?taskID=519026). They are built with Fedora compilation flags except "-g" (which isn't changing unless someone knows better than you or I how to generate -debuginfo for binaries in .jars). Currently, a -debuginfo package shouldn't be built at all (but I don't know how that is done). Thanks for the quick feedback!
For 3.0.2-3: * License - License tag should be LGPLv2+ * BuildRequires - BR: libffi is not needed as libffi-devel Requires libffi. ! Explicit Requires - This package has explicit Requires: "Requires: libffi" - For this package this cannot be avoided because /usr/lib/rpm/redhat/find-requires cannot check the dependency for the libraries packaged in jar file. - However usually (i.e. for non-Java rpms) these type of dependency should be detected automatically by find-requires and this type of explicit Requires should not be written So would you write a comment in the spec file why this explicit Requires is needed? (and this issue must be discussed on making Java packaging guidelines) * Requires - Like joda-time, "Requires: %{name}-%{version}-%{release}" is wrong. ? .zip file - As far as I unzipped .zip files in jna tarball, all files in the zip ball are text files. However it this is not needed on rebuilding jna, please remove these. * Some rpmlint complaint ------------------------------------------------------------- jna.i386: W: spurious-executable-perm /usr/share/doc/jna-3.0.2/LICENSE.txt jna.i386: E: wrong-script-end-of-line-encoding /usr/share/doc/jna-3.0.2/LICENSE.txt ------------------------------------------------------------- - The permission of LICENSE.txt should be 0644 and this file should not have CRLF end-of-line encoding.
(In reply to comment #6) > Currently, a -debuginfo package shouldn't be built at all (but I don't know how > that is done). Please refer to: http://fedoraproject.org/wiki/Packaging/Debuginfo section: "Useless or incomplete debuginfo packages due to other reasons"
I addressed all the issues brought up in comments 7 and 8. New URLs: Spec URL: http://konradm.fedorapeople.org/fedora/SPECS/jna.spec SRPM URL: http://konradm.fedorapeople.org/fedora/SRPMS/jna-3.0.2-4.fc8.src.rpm
Oops. Fixed Group of jna-javadocs: Spec URL: http://konradm.fedorapeople.org/fedora/SPECS/jna.spec SRPM URL: http://konradm.fedorapeople.org/fedora/SRPMS/jna-3.0.2-5.fc8.src.rpm
For -javadoc subpackages: - It seems Java related packages use -javadoc for subpackages, not -javadocs - And please use "Documentation" simply for Group. -------------------------------------------------------------------------------- This package (jna) is APPROVED by me --------------------------------------------------------------------------------
Hi, thought I'd poke in on the JRuby dependencies. This one looks like it's ready for a CVS request?
Patch0: jna-use-system-libffi-and-cflags.patch Is this patch submitted upstream? If so, it would be good to add a link to the upstream bug tracking system.
(In reply to comment #12) > Hi, thought I'd poke in on the JRuby dependencies. This one looks like it's > ready for a CVS request? In another JRuby dependency my CVS request was shot down because the java guidelines draft hasn't been approved yet (see bz# 435598). (In reply to comment #13) > Patch0: jna-use-system-libffi-and-cflags.patch > Is this patch submitted upstream? If so, it would be good to add a link to > the upstream bug tracking system. No, it's not. Ought I submit it upstream?
(In reply to comment #13) Also: With that patch I ripped out some things that might matter for non-Fedora builds, which probably isn't cool with upstream. It's probably not actually usable by anyone but us.
Not even mentioning to upstream that we're patching their code is always wrong. If they reject a patch, then we can carry it, but it's far better to get everything merged. http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream I just had a look at your patch. First, I don't understand this: -CFLAGS=$(PCFLAGS) $(COPT) $(CDEBUG) $(CDEFINES) $(CINCLUDES) \ - -DVERSION='"$(VERSION)"' -DCHECKSUM='"$(CHECKSUM)"' +CFLAGS=FEDORA Are you trying to define something? We need to use -DFEDORA then, right? On an overall level, I think you could make most of this patch conditional, like this: $(BUILD)/%.o : %.c dispatch.h $(FFI_LIB) @mkdir -p $(BUILD) ifeq ($(USE_SYSTEM_FFI),) ifneq ($(SDKROOT),) $(CC) -arch $(ARCH) $(CFLAGS) -c $< -o $@.$(ARCH) for arch in $(ALT_ARCHS); do \ $(CC) -arch $$arch -I$(BUILD)/libffi.$$arch/include $(CFLAGS) -c $< o $@.$$arch; \ done lipo -create -output $@ $@.* else $(CC) $(CFLAGS) -c $< $(COUT) endif else $(CC) $(CFLAGS) -c $< $(COUT) `pkg-config --cflags libffi` endif This would allow upstream to merge it without affecting builds on operating systems with no system ffi, or a too-old version (and the latter almost certainly includes older Fedora releases or RHEL, remember). Thanks a lot for your work on this, I'm looking forward to having JRuby in the OS!
The CFLAGS=FEDORA is replaced by sed in the spec. I removed lots of things that didn't affect Fedora in my patch. Sure the changes might be able to be cleaned up and given to upstream, but I'm not myself particularly good at makefiles. If you want to / are able to do that, please go ahead.
Is the JNA source release from here: https://jna.dev.java.net/source/browse/*checkout*/jna/trunk/jnalib/dist/src.zip?rev=HEAD too old? I'm wondering why we're doing a SVN snapshot.
I doubt HEAD is too old :). There's no particular reason for the SVN snapshot. It used to make sense for jruby to be using a svn snapshot (pre-1.0 versions) but I think now that they're almost finished with 1.1 I'll be sticking with tarballs.
Hmm...I'm confused by upstream's release page. Is src.zip really just a zip of SVN trunk? The date says it was generated Feb 1...investigating.
Oh, I don't know. I maybe misunderstood the "?rev=HEAD" portion of the link. In any case switching to a .zip or .tar.* is fine with me.
Ok, I've modified the patch in a way which will hopefully be acceptable to upstream. It's filed here: https://jna.dev.java.net/issues/show_bug.cgi?id=60
Alright, thank you very much!
Taking this, I have an update coming too.
Spec URL: http://cdn.verbum.org/jna.spec SRPM URL: http://cdn.verbum.org/jna-3.0.2-6.fc9.src.rpm Ok, lots of changes from the previous spec. * Build debuginfo package * Redo structure of library locations to match guidelines; this means that an architecture-independent jar is in /usr/share/java, and the .so is in %{_libdir}/jna/ * Restructure patch for dynlinking/CFLAGS again to hopefully be more palatable to upstream (patch is updated in the issue)
Hello, Colin: You seem to have changed the assignee to yourself, however you cannot approve your own package. What does it mean?
Hi Mamoru-san, this is now a combination of work from Conrad and me; do you think you could review it?
(In reply to comment #27) > Hi Mamoru-san, this is now a combination of work from Conrad and me; do you > think you could review it? Yes :)
Well, - Now libjnidispatch.so is out of jar file, the explicit "Requires: libffi" should be removed. - "BuildRequires: pkgconfig" should be removed. If this is needed, libffi-devel should have "Requires: pkgconfig" and actually libffi-devel correctly requires pkgconfig.
Also: - Please check the minimum Requires of java per described in the section "BuildRequires and Requires" of http://fedoraproject.org/wiki/Packaging/Java (Epoch missing)
Thanks for catching that! Updated spec: http://cdn.verbum.org/jna.spec
Sorry, however would you also provide srpm?
Yep, here it is: SRPM: http://cdn.verbum.org/jna-3.0.2-7.fc9.src.rpm
Okay, good. ---------------------------------------------------------------------- This package (jna) is APPROVED by me (again) ----------------------------------------------------------------------
New Package CVS Request ======================= Package Name: jna Short Description: Pure Java access to native libraries Owners: walters,konradm Branches: F-8 EL-5 InitialCC: Cvsextras Commits: yes
cvs done.