Bug 475852 - Review Request: gnustep-base - GNUstep Base library package
Review Request: gnustep-base - GNUstep Base library package
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Michel Alexandre Salim
Fedora Extras Quality Assurance
: Reopened
: 459210 (view as bug list)
Depends On: 475112 488534
Blocks: 459211 475861
  Show dependency treegraph
 
Reported: 2008-12-10 14:48 EST by Jochen Schmitt
Modified: 2014-12-29 11:48 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-13 12:12:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
michel: fedora‑review+


Attachments (Terms of Use)

  None (edit)
Description Jochen Schmitt 2008-12-10 14:48:19 EST
Spec URL: http://www.herr-schmitt.de/put/gnustep-base/gnustep-base.spec
SRPM URL: http://www.herr-schmitt.de/put/gnustep-base/gnustep-base-1.16.5-1.src.rpm
Description: 
The GNUstep Base Library is a powerful fast library of general-purpose,
non-graphical Objective C classes, inspired by the superb OpenStep API but
implementing Apple and GNU additions to the API as well.  It includes for
example classes for unicode strings, arrays, dictionaries, sets, byte
streams, typed coders, invocations, notifications, notification dispatchers,
scanners, tasks, files, networking, threading, remote object messaging
support (distributed objects), event loops, loadable bundles, attributed
unicode strings, xml, mime, user defaults. This package includes development
headers too.
Comment 1 Jason Tibbitts 2008-12-10 15:13:31 EST
I believe this is a duplicate of 459210, which is under active review.

*** This bug has been marked as a duplicate of bug 459210 ***
Comment 2 manuel wolfshant 2008-12-10 15:46:50 EST
Why do you think that license should be GPLv3+ ? From what I can see:
Source/Additions/GSCompatibility.h: *No copyright* UNKNOWN
Source/callframe.h: LGPL (v2 or later)
Source/cifframe.h: LGPL (v2 or later)
Source/dld-load.h: LGPL (v2 or later)
Source/GSeq.h: LGPL (v2 or later)
Source/GSInvocation.h: LGPL (v2 or later)
Source/GSNetwork.h: LGPL (v2 or later)
Source/GSPortPrivate.h: LGPL (v2 or later)
Source/GSPrivate.h: LGPL (v2 or later)
Source/GSRunLoopCtxt.h: *No copyright* UNKNOWN
Source/GSRunLoopWatcher.h: *No copyright* UNKNOWN
Source/GSSocketStream.h: LGPL (v2 or later)
Source/GSStream.h: LGPL (v2 or later)
Source/GSURLPrivate.h: LGPL (v2 or later)
Source/hpux-load.h: LGPL (v2 or later)
Source/inet_ntop.c: ISC
Source/inet_pton.c: ISC
Source/NSCallBacks.h: LGPL
Source/NSCharacterSetData.h: *No copyright* GENERATED FILE
Source/NSConcreteNumber.h: LGPL (v2 or later)
Source/nstzfile.h: *No copyright* Public domain
Source/null-load.h: LGPL (v2 or later)
Source/objc-load.h: LGPL (v2 or later)
Source/simple-load.h: LGPL (v2 or later)
Source/thr-mach.h: GPL
Source/win32-load.h: LGPL (v2 or later)
Comment 3 Jochen Schmitt 2009-01-14 15:31:16 EST
This bug should take over the part of BZ #459210
Comment 4 manuel wolfshant 2009-01-14 17:56:40 EST
*** Bug 459210 has been marked as a duplicate of this bug. ***
Comment 5 Michel Alexandre Salim 2009-03-02 22:01:12 EST
1.18.0 (latest stable release) does not currently build on F-10 with Rawhide's gcc-objc 4.4.0:

 Linking library libgnustep-base ...
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/4.4.0/../../../../lib64/libcallback.a(misc.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-redhat-linux/4.4.0/../../../../lib64/libcallback.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [obj/x86_64/linux-gnu/gnu-gnu-gnu/libgnustep-base.so.1.18.0] Error 1

This is bizarre, as -fPIC is in %{_libdir}/GNUstep/Makefiles/target.make:

$ grep -l fPIC /usr/lib64/GNUstep/Makefiles/*
/usr/lib64/GNUstep/Makefiles/target.make

Anyone knows what could be the problem? I'll try doing an install from the upstream script, for comparison.
Comment 6 Michel Alexandre Salim 2009-03-02 22:19:10 EST
Same problem with F-10's gcc-objc 4.3.2 and upstream's gnustep-startup. If people are building fine on 32-bit systems, then it looks like gnustep-make's compiler flags are wrong on x86_64.
Comment 7 Scott Christley 2009-03-02 22:35:53 EST
This is because of bug 475112.  ffcall needs to be compiled with -fPIC.  Can also try compiling gnustep-base with libffi instead of ffcall.
Comment 8 Michel Alexandre Salim 2009-03-03 12:09:40 EST
GNUstep's page lists libffi as required and ffcall as optional. Should we block on 475112, or switch requirement to libffi?
Comment 9 Jochen Schmitt 2009-03-03 12:23:02 EST
I have blocked and ping the maintainer of libffi. If they may not reply in the next 7 days, I may make the fix by mayslf, because it's trivial and open a AWOL processs.
Comment 10 Michel Alexandre Salim 2009-03-03 14:29:23 EST
Jochen: ffcall, not libffi.

We're depending on 475112, not blocking 475112 -- we're still blocking oolite, which I've added back. Making this block gnustep-gui as well, and gnustep-gui block gnustep-backend.
Comment 11 Scott Christley 2009-03-03 16:35:22 EST
I think it is reasonable to switch to libffi.  It use to be that libffi was not well supported on some platforms and missing functionality, but I think it has caught up.  Especially if GNUstep is now recommending a version that works, we should go with that.  Think you can use the --enable-libffi and --disable-ffcall flags to configure to force usage, but it seems GNUstep should automatically pick libffi first if it finds it.
Comment 12 Michel Alexandre Salim 2009-03-03 16:58:38 EST
There's probably no need to use --disable-ffcall explicitly. If the build req is updated to libffi-devel, since we're building on Koji, ffcall won't even be installed into the chroot used for building.

Nobody seems to be in charge of this review yet, so I'll assign it to myself; Scott will be doing the pre-review on the way to getting sponsored.
Comment 14 Michel Alexandre Salim 2009-03-04 14:36:45 EST
- The spec you put up is for 1.19.0 (an unstable release)
- Any reason for the very specific gnustep-make version requirement (>= 2.0.0-14)?
  Did anything change in that version?

As long as the version in the supported repositories (F-9, F-10, and possibly EL-4 and EL-5 if we want to bring GNUstep there) is above, then we don't really need the version number.
Comment 15 Jochen Schmitt 2009-03-04 15:26:29 EST
New Releases:

Spec URL: http://www.herr-schmitt.de/put/gnustep-base/gnustep-base.spec
SRPM URL:
http://www.herr-schmitt.de/put/gnustep-base/gnustep-base-1.18.0-1.src.rpm

Sorry, I have rebuild it for 0.18.

I have a special issue with gnuste-make if I try to build the package on x86_64 systems. Because there is a new release of gnustep-make, I have a ticket, (BZ #473342) )n which I propose a SPEC file, which should fix this x86_64 releted issues.
Comment 16 Michel Alexandre Salim 2009-03-04 16:36:31 EST
Ah, you mean 488534. Updating the BLOCK; if Axel does not get to it, I should have time to review the changes this weekend.
Comment 17 Michel Alexandre Salim 2009-03-12 18:44:24 EDT
Missing dependencies:
BuildRequires:  gnutls-devel
BuildRequires:  avahi-compat-libdns_sd-devel
BuildRequires:  gmp-devel
Comment 18 Charles Lopes 2009-03-24 19:30:01 EDT
I have not been able to build the latest package on mock with the fedora-10-x86_64 configuration until I changed the install line to this:

make install DESTDIR=${RPM_BUILD_ROOT} GNUSTEP_INSTALLATION_DOMAIN=SYSTEM

Without it, everything gets installed in "/usr/local". Could it be that you build your package in an environment where /etc/GNUstep/GUNstep.conf has a LOCAL domain set to "/usr"?
Comment 19 Michel Alexandre Salim 2009-03-24 23:45:20 EDT
I have just rebuilt gnustep-make (see linked bug information); Jochen, if you
add the missing dependency, post the updated SRPM, and do a Koji scratch build
for Rawhide, I'll do the full review.

Charles, is that with 2.0.6 or 2.0.8? 2.0.8 should be in Rawhide soon; to get it earlier (or for F-10), see the last comment in

https://bugzilla.redhat.com/show_bug.cgi?id=488534
Comment 20 Charles Lopes 2009-03-25 06:53:41 EDT
Sorry, I omitted to mention that I used gnustep-make 2.0.6-15 downloaded from koji and that I compiled for fedora 10 because of the lib64 issue.

I had a look at 2.0.8-2 from koji and noticed that the domain LOCAL has been changed to "/usr". IMHO it should have been kept to "/usr/local" as the safe default while SYSTEM should be used for installations under "/usr" as in upstream gnustep-make. This new change to gnustep-make, means that end-users compiling from tar balls are likely to run "make install" and overwrite the distribution's files.
This sort of installation convention with a local default location and a separate system location is found on other systems like perl-Make for example.

I would suggest using "GNUSTEP_INSTALLATION_DOMAIN=SYSTEM" for gnustep-base and reverting the gnustep-make change.
Comment 21 Jochen Schmitt 2009-03-25 11:24:50 EDT
OK, sounds good for mee.
Comment 23 Charles Lopes 2009-03-26 07:14:55 EDT
I see that I had omitted more information in my first comment.
I had first tried using the configure parameter "--with-installation-domain" but it did not change the installation behavior. Passing "GNUSTEP_INSTALLATION_DOMAIN=SYSTEM" as a command line variable to "make install" seems to be the expected way to do it. I actually used both the configure parameter and the make variable in my trials.

There is an interesting comment on the Changelog file for 2008-11-27:
        Removed GNUSTEP_INSTALLATION_DOMAIN.
        NB.  This means that gnustep-base will now install in the local domain
        by default, and to get the old behavior you will need to do
        'make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install'
        The rationale for this change is that the system domain is for
        resources installed by the operating system packagers, but the
        local domain is for add-ons you install yourself (to be used by
        all users of the system), and you don't normally want to overwrite
        the operating system supplied version by accident.

Also, looking closer I see that "--with-installation-domain=SYSTEM" actually sets "GNUSTEP_BASE_DOMAIN" to SYSTEM into "config.mak" and that the GNUmakefile contains these lines:

-include config.mak
ifeq ($(GNUSTEP_INSTALLATION_DOMAIN),)
  GNUSTEP_INSTALLATION_DOMAIN := LOCAL
endif
ifeq ($(GNUSTEP_BASE_DOMAIN),)
  GNUSTEP_BASE_DOMAIN := LOCAL
endif
Comment 25 Jochen Schmitt 2009-04-27 12:33:38 EDT
Ping Charles
Comment 26 Charles Lopes 2009-05-26 08:41:57 EDT
Sorry for the late feedback.

The current version of the gnustep-make package does not make any difference between the Local and System domains anymore. In order to restore the upstream behaviour, I made my own version gnustep-make-2.0.8-2.fc10 where I commented out the following line in the spec file:
sed -i -e 's,/local,,' FilesystemLayouts/fhs-system


As for gnustep-base, I successfully built the package with mock for fedora-10-x86_64 and fedora-10-i386. I did so with both the original gnustep-make-2.0.8-2.fc10 and the version modified as described earlier. So I would say that the last package is fine by me. I have used it to build sogo and did not see any issues in my tests so far.
Comment 27 Jochen Schmitt 2009-05-26 11:25:47 EDT
Thats sounds fine. Please talk to the maintainer of gnustep-make about the topic you have described in your comment.


At least it may be fine to have a formal review and approvement of the package.
Comment 28 Jochen Schmitt 2009-06-18 13:28:49 EDT
Ping Michel
Comment 29 Jochen Schmitt 2009-09-14 10:20:52 EDT
I have create a new build of gnustep-base agains gnustep-make-2.2.0:

New Releases:

Spec URL: http://www.herr-schmitt.de/put/gnustep-base/gnustep-base.spec
SRPM URL:
http://www.herr-schmitt.de/put/gnustep-base/gnustep-base-1.18.0-4.fc10.src.rpm
Comment 30 Michel Alexandre Salim 2009-09-14 20:00:54 EDT
Koji F-12: http://koji.fedoraproject.org/koji/taskinfo?taskID=1679163

There are a couple of minor things to fix (see below), and this package is on the way in. I forgot -- are you a sponsored maintainer? If not, set this to block FE-NEEDSPONSOR and I'll certify that I'll sponsor you.

MUST

FIX rpmlint
gnustep-base.src: W: mixed-use-of-spaces-and-tabs (spaces: line 3, tab: line 1)

You can fix this with Emacs' "untabify" command

OK package name
OK spec file name
OK package guideline-compliant
OK license complies with guidelines
FIX license field accurate
  some files are actually GPLv3+, while others are still GPLv2+. This means
  the aggregate is GPLv3+. Most LGPL files are v2+ but some (makefiles! should
  these not be GNU public domain ?!) are LGPLv3+. Assuming that upstream
  intention is to switch files to (L)GPLv3+ as they are updated, I think we
  can say "LGPLv3+ and GPLv3+". If you could email upstream and get a
  clarification, and put a comment with the URL to the upstream mail from a
  mailing list archive, that would be great.

  The other alternative is to split out the v2 and v3 files, but that would be 
  crazy if the division is merely temporal, rather than functional (i.e. if
  there is no distinct subpackage with a different license)
OK license file not deleted
OK spec in US English
FIX spec legible
  - the comment for renaming pl mentions pllit but the file is renamed to
    pllist.
OK source matches upstream
$ md5sum gnustep-base-1.18.0.tar.gz ../SOURCES/gnustep-base-
1.18.0.tar.gz                                                                   
880491e0fc64ab3507887f43faa67572  gnustep-base-1.18.0.tar.gz
880491e0fc64ab3507887f43faa67572  ../SOURCES/gnustep-base-1.18.0.tar.gz

OK builds under >= 1 archs, others excluded
  see Koji link
FIX build dependencies complete
  gmp-devel listed twice
  /usr/bin/iconv is bad for two reasons:
  - we frown on file-based dependencies because they can be expensive to resolve
  - it is part of glibc-common which is always installed
OK library -> ldconfig
FIX own all directories
  gnustep-base-devel should additionally requires gnustep-make:
  - it is a development package, and is useless without the other makefiles
  - it installs into %{_libdir}/GNUstep/Makefiles/Additional which is owned
    by gnustep-make
OK no dupes in %files
  note: just a style thing, but %doc is normally put just under %defattr, not
  at the bottom.
OK permission
OK %clean RPM_BUILD_ROOT
OK macros used consistently
OK Package contains code
OK headers in -devel
OK if libfiles are suffixed, the non-suffixed goes to devel
OK devel requires versioned base package
OK clean buildroot before install
OK filenames UTF-8

SHOULD
OK package build in mock on all architectures
  see Koji link
? package functioned as described
  will test with Oolite later
OK scriplets are sane
FIX require package not files
  see above (iconv)
Comment 31 Michel Alexandre Salim 2009-09-14 20:08:49 EDT
And the rpmlint result from the binary RPMs:

$ rpmlint gnustep-base*
gnustep-base.x86_64: W: hidden-file-or-dir /usr/lib64/GNUstep/Libraries/gnustep-base/Versions/1.18/Resources/NSTimeZones/.README.swp
gnustep-base.x86_64: E: non-standard-executable-perm /usr/bin/gdomap 01755
gnustep-base-devel.x86_64: W: no-documentation
2 packages and 0 specfiles checked; 1 errors, 2 warnings.


hidden-file: that should be deleted in %install
gdomap: is there a reason for the sudo?

The documentation warning is.. interesting. Could you see how gnustep-make does its documentation subpackage, and create a gnustep-base-doc subpackage? It'd be easier than gnustep-make's, since gnustep-make will already be installed when you start the build process (e.g. you can do 'make -C Documentation' in %build, not delay it to %install)

Also, there is the 'Examples' directory. That should probably be not be built, but packaged as part of gnustep-base-devel, complete with the relevant makefiles, e.g.

%files devel
...
%doc Examples
Comment 32 Michel Alexandre Salim 2009-09-15 04:29:11 EDT
PS see https://bugzilla.redhat.com/show_bug.cgi?id=523371 for document-handling. Unfortunately, the GNUstep team has not updated their docs makefiles to use gnustep-config, so the makefile location still has to be specified manually (or the GNUstep.sh file sourced, I suppose)

I'm asking the Infrastructure team for a gnustep-specific mailing list; once that is set up, the next thing is probably to finalize our GNUstep packaging guidelines. I think I have an older file lying around in my Wiki space somewhere, but IIRC that dates back to when we were still arguing over how FHS-compliant we should be. Eek. Would welcome your help hashing out specific guidelines :)
Comment 33 Jochen Schmitt 2009-09-16 12:40:52 EDT
(In reply to comment #30)

> FIX rpmlint
> gnustep-base.src: W: mixed-use-of-spaces-and-tabs (spaces: line 3, tab: line 
> You can fix this with Emacs' "untabify" command

Done.

> FIX license field accurate
>   some files are actually GPLv3+, while others are still GPLv2+. This means
>   the aggregate is GPLv3+. Most LGPL files are v2+ but some (makefiles! should
>   these not be GNU public domain ?!) are LGPLv3+. Assuming that upstream
>   intention is to switch files to (L)GPLv3+ as they are updated, I think we
>   can say "LGPLv3+ and GPLv3+". If you could email upstream and get a
>   clarification, and put a comment with the URL to the upstream mail from a
>   mailing list archive, that would be great.
> 
>   The other alternative is to split out the v2 and v3 files, but that would be 
>   crazy if the division is merely temporal, rather than functional (i.e. if
>   there is no distinct subpackage with a different license)

You should not aggregate several Licenses to one which may compatible to the all of the others.

> FIX spec legible
>   - the comment for renaming pl mentions pllit but the file is renamed to
>     pllist.

Done. typo.

> FIX build dependencies complete
>   gmp-devel listed twice
>   /usr/bin/iconv is bad for two reasons:
>   - we frown on file-based dependencies because they can be expensive to

Done.

> FIX own all directories
>   gnustep-base-devel should additionally requires gnustep-make:
>   - it is a development package, and is useless without the other makefiles
>   - it installs into %{_libdir}/GNUstep/Makefiles/Additional which is owned
>     by gnustep-make

Done.

> FIX require package not files
>   see above (iconv)  

Done.

Next Release:

Spec URL: http://www.herr-schmitt.de/put/gnustep-base/gnustep-base.spec
SRPM URL:
http://www.herr-schmitt.de/put/gnustep-base/gnustep-base-1.18.0-5.fc10.src.rpm
Comment 34 Michel Alexandre Salim 2009-09-24 13:45:53 EDT
Changes look fine. I have an upcoming change for gnustep-make, that makes Documentation, Documentation/User and Documentation/Developer owned by gnustep-filesystem, but I'll fix that in gnustep-base as well when I land the changes.

APPROVED
Comment 35 Jochen Schmitt 2009-09-24 15:23:20 EDT
New Package CVS Request
=======================
Package Name: gnustep-base
Short Description: GNUstep Base library package
Owners: s4504kr
Branches: devel, F-10, F-11
InitialCC:
Comment 36 Michel Alexandre Salim 2009-09-24 21:22:20 EDT
Hi Jochen,

Some last minute notes:
- gnustep-base can Require: gnustep-filesystem instead of gnustep-make
  (-make should be required only for development packages
- gnustep-base-devel should therefore additionally Requires: gnustep-make
Comment 37 Kevin Fenzi 2009-09-25 12:28:18 EDT
cvs done.
Comment 38 Jochen Schmitt 2009-10-13 12:12:42 EDT
Build done.
Comment 39 Jochen Schmitt 2010-07-13 13:15:17 EDT
Package Change Request
======================
Package Name: gnustep-base
New Branches: EL-6
Owners: s4504kr
Comment 40 Kevin Fenzi 2010-07-13 19:16:44 EDT
CVS done (by process-cvs-requests.py).
Comment 41 Jochen Schmitt 2014-12-29 10:38:09 EST
  Package SCM Request
======================
Package Name: gnustep-base
New Branches: epel7
Owners: s4504kr
Comment 42 Kevin Fenzi 2014-12-29 11:48:13 EST
There already seems to be a epel7 branch.

Note You need to log in before you can comment on or make changes to this bug.