Bug 436036

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.