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.
I believe this is a duplicate of 459210, which is under active review. *** This bug has been marked as a duplicate of bug 459210 ***
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)
This bug should take over the part of BZ #459210
*** Bug 459210 has been marked as a duplicate of this bug. ***
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.
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.
This is because of bug 475112. ffcall needs to be compiled with -fPIC. Can also try compiling gnustep-base with libffi instead of ffcall.
GNUstep's page lists libffi as required and ffcall as optional. Should we block on 475112, or switch requirement to libffi?
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.
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.
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.
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.
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-2.src.rpm
- 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.
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.
Ah, you mean 488534. Updating the BLOCK; if Axel does not get to it, I should have time to review the changes this weekend.
Missing dependencies: BuildRequires: gnutls-devel BuildRequires: avahi-compat-libdns_sd-devel BuildRequires: gmp-devel
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"?
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
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.
OK, sounds good for mee.
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-2.fc10.src.rpm
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
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-3.fc10.src.rpm
Ping Charles
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.
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.
Ping Michel
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
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)
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
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 :)
(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
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
New Package CVS Request ======================= Package Name: gnustep-base Short Description: GNUstep Base library package Owners: s4504kr Branches: devel, F-10, F-11 InitialCC:
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
cvs done.
Build done.
Package Change Request ====================== Package Name: gnustep-base New Branches: EL-6 Owners: s4504kr
CVS done (by process-cvs-requests.py).
Package SCM Request ====================== Package Name: gnustep-base New Branches: epel7 Owners: s4504kr
There already seems to be a epel7 branch.