gnustep-base: FTBFS: Build fails with several test failures

Bug #1277975 reported by Andreas Moog
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gcc
Unknown
Unknown
gnustep-base (Ubuntu)
Fix Released
High
Unassigned

Bug Description

 affects ubuntu/gnustep-base
 importance high
 tag ftbfs trusty
 done

Hi there,

the package gnustep-base fails to build in current Ubuntu.

(Hopefully) Relevant part of the log:
--------------------------------------

--- Running tests in base/NSCalendarDate ---
--- Running tests in base/NSCharacterSet ---
--- Running tests in base/NSConnection ---
--- Running tests in base/NSCountedSet ---
--- Running tests in base/NSData ---
--- Running tests in base/NSDate ---
--- Running tests in base/NSDateFormatter ---
--- Running tests in base/NSDictionary ---
--- Running tests in base/NSException ---
--- Running tests in base/NSFileHandle ---
--- Running tests in base/NSFileManager ---
--- Running tests in base/NSHTTPCookie ---
--- Running tests in base/NSHashTable ---
--- Running tests in base/NSHost ---
--- Running tests in base/NSIndexPath ---
--- Running tests in base/NSInvocation ---
--- Running tests in base/NSJSONSerialization ---
--- Running tests in base/NSKeyedArchiver ---
--- Running tests in base/NSLocale ---

base/NSLocale/general.m:
Failed test: general.m:60 ... NSLocaleGroupingSeparator key returns '.'
Failed test: general.m:73 ... NSLocaleQuotationBeginDelimiterKey key works
Failed test: general.m:77 ... NSLocaleQuotationEndDelimiterKey key returns 'xx6'
--- Running tests in base/NSLock ---
--- Running tests in base/NSMapTable ---
--- Running tests in base/NSMethodSignature ---
--- Running tests in base/NSMutableArray ---
--- Running tests in base/NSMutableAttributedString ---
--- Running tests in base/NSMutableCharacterSet ---
--- Running tests in base/NSMutableData ---
--- Running tests in base/NSMutableDictionary ---
--- Running tests in base/NSMutableIndexSet ---
--- Running tests in base/NSMutableSet ---
--- Running tests in base/NSMutableString ---
--- Running tests in base/NSNumber ---
--- Running tests in base/NSNumberFormatter ---

base/NSNumberFormatter/basic10_4.m:
Failed test: basic10_4.m:145 ... negativeFormat used for -ve number
--- Running tests in base/NSObject ---
--- Running tests in base/NSOperation ---

Session terminated, terminating shell... ...terminated.
make[1]: *** [internal-check] Terminated
make[2]: *** [check] Terminated
make: *** [debian/build-shared-stamp] Terminated
Build killed with signal 15 after 60 minutes of inactivity
******************************************************************************
Build finished at 20140129-0115
FAILED [dpkg-buildpackage died]

A full buildlog is available at https://launchpadlibrarian.net/163984571/buildlog_ubuntu-trusty-i386.gnustep-base_1.24.0-1ubuntu3_FAILEDTOBUILD.txt.gz

Thanks for your time!

Regards,
  Andreas

--
PGP-encrypted mails preferred
PGP Fingerprint: 74CD D9FE 5BCB FE0D 13EE 8EEA 61F3 4426 74DE 6624

Revision history for this message
Paul Gevers (paul-climbing) wrote :

I wonder. Do you know if build servers can go idle for other reasons than a failure in the package? The failure is not because of a test failure (those are ignored anyways AFAICT. So, could you please try again (on a different server??) I have just asked for a sync of gnustep-base, if that also fails, is there a way to log into such a build system to see where it waiting for?

Revision history for this message
Artur Rona (ari-tczew) wrote :
Download full text (4.9 KiB)

This bug was fixed in the package gnustep-base - 1.24.6-2
Sponsored for Paul Gevers (paul-climbing)

---------------
gnustep-base (1.24.6-2) unstable; urgency=medium

  * Upload to unstable.
  * debian/compat: Set to 9 to get .build-id debugging symbols.
  * debian/control.m4 (Build-Depends): Require debhelper >= 9. Build
    against gnutls28, thanks Andreas Metzler (Closes: #753033).
    (libgnustep-base`'SOV_BASE-dbg) <Conflicts>: Remove.
    <Recommends>: Remove libobjc3-dbg.
  * debian/control: Regenerate.
  * debian/patches/hurd-ignore-NSURL-test.diff: Delete; apparently no
    longer needed.
  * debian/patches/ftbfs-mips64.patch: New; fixes FTBFS on mips64(el),
    thanks Yunqiang Su (Closes: #753961).
  * debian/patches/gnutls28.patch: New; avoid using and linking libgcrypt
    with recent GnuTLS.
  * debian/patches/NSString-buffer-overrun.patch: New, cherry-picked from
    upstream SVN.
  * debian/patches/alignment-check.patch: New, fix word-alignment
    configure test on sparc. Cherry-picked from upstream.
  * debian/patches/testsuite-fixes.patch: New.
  * debian/patches/doc-links.patch: Point links to index.html.
  * debian/patches/autoreconf.patch: Regenerate.
  * debian/patches/series: Update.
  * debian/rules (confflags): Define conditionally and pass --host to
    configure if cross-compiling.
    (install-debug): Install config.log and tests.log to analyze testsuite
    failures on the buildds.

 -- Yavor Doganov <email address hidden> Mon, 07 Jul 2014 12:16:59 +0300

gnustep-base (1.24.6-1) experimental; urgency=low

  * New upstream release:
    - Fixes FTBFS with recent libxml2 (Closes: #738347).
    - GNUSTEP_USER_DIRECTORY is no longer created unconditionally (Closes:
      #720190).
    - Fixes regression in performSelector: with message forwarding
      (Closes: #753603).
  * Ack NMUs; thanks Matthias Klose, gregor herrmann and Pino Toscano.
  * debian/patches/libobjc4.patch:
  * debian/patches/recent-libxml2-fix.patch: Remove; fixed upstream.
  * debian/patches/kfreebsd-fake-main.patch:
  * debian/patches/avoid-nsl-linkage.patch:
  * debian/patches/maxsymlinks.diff: Refresh.
  * debian/patches/autoreconf.patch: Regenerate.
  * debian/patches/texinfo5.diff: Add description.
  * debian/patches/hurd-ignore-NSURL-test.diff: Disable for now.
  * debian/patches/manpage-fixes.patch: Fix two more issues reported by
    lintian.
  * debian/patches/info-direntry.patch: Fix few texinfo warnings.
  * debian/patches/CVE-2014-2980.patch: New patch from upstream, fixes
    gdomap user security hole (Closes: #745470).
  * debian/patches/use-local-DTDs.patch: New; use local DTDs to avoid
    annoying warnings from autogsdoc when built in a chroot. Thanks
    Svante Signell (Closes: #736587).
  * debian/patches/hide-SYSTEM_CONFIG-vars.patch: New; fix for upstream
    bug #42423.
  * debian/patches/doc-links.patch: New; fix some broken links to manuals
    in the various -doc packages, thanks js (Closes: #749196).
  * debian/patches/series: Update.
  * debian/rules (build-arch): Remove dependency on patch.
    (binary-indep): Invoke dh_installxmlcatalogs with -n since only DTDs
    are being installed, not catalogs (Closes: #637093).
    (i...

Read more...

Changed in gnustep-base (Ubuntu):
status: New → Fix Released
Revision history for this message
Paul Gevers (paul-climbing) wrote :

The current build fails exactly at the same location, so this is still open. However, the package successfully builds in my pbuilder utopic chroot, so I believe it is either something on the build servers, or related to proposed updates?

Changed in gnustep-base (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Artur Rona (ari-tczew) wrote :

This package builds fine on my pbuilder too. However, I've retried the building of binaries and they have been built successful now. The exception are powerpc and ppc64el. Could you do more investigation there, please?

checking for Sleep... no
checking for objc_root_class attribute support... not present
checking whether objc really works... no
I don't seem to be able to use your Objective-C compiler to produce
working binaries! Please check your Objective-C compiler installation.
If you are using gcc-3.x make sure that your compiler's libgcc_s and libobjc
can be found by the dynamic linker - usually that requires you to play
with LD_LIBRARY_PATH or /etc/ld.so.conf.
Please refer to your compiler installation instructions for more help.
configure: error: The Objective-C compiler does not work or is not installed properly.
debian/rules:122: recipe for target 'debian/configure-stamp' failed
make: *** [debian/configure-stamp] Error 1
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Revision history for this message
Paul Gevers (paul-climbing) wrote :

Artur, can you please build a package (on powerpc / ppc64el) with the attached debdiff applied to the current package??

Revision history for this message
Paul Gevers (paul-climbing) wrote :

For background information, please see bug 1343945.

tags: added: patch
Revision history for this message
Daniel Holbach (dholbach) wrote :
Revision history for this message
Paul Gevers (paul-climbing) wrote : Re: [Bug 1277975] Re: gnustep-base: FTBFS: Build fails with several test failures

On 25-07-14 09:46, Daniel Holbach wrote:
> Build logs for the individual FTBFSes:
> - ppc64el: https://launchpadlibrarian.net/180535732/buildlog_ubuntu-utopic-ppc64el.gnustep-base_1.24.6-2ubuntu1_FAILEDTOBUILD.txt.gz
> - powerpc: https://launchpadlibrarian.net/180535689/buildlog_ubuntu-utopic-powerpc.gnustep-base_1.24.6-2ubuntu1_FAILEDTOBUILD.txt.gz

These are failures that are probably due to problems in the gcc
toolchain. We should file a proper bug report against gcc-4.8, but I
lack the understanding that Yavor has to do it (as far as we understand
it, it is described in bug 1343945).

> - i386: https://launchpadlibrarian.net/180539099/buildlog_ubuntu-utopic-i386.gnustep-base_1.24.6-2ubuntu1_FAILEDTOBUILD.txt.gz

This failure is intermittent, rebuilding probably helps. We should
disable the testcases for now to work around this issue (also present on
amd64). But I don't think that makes sense as long as the ppc issue is
not solved yet.

Paul

Revision history for this message
Dmitry Shachnev (mitya57) wrote :

This is fixed in upstream libobjc, we just need to wait for new upstream snapshot to arrive in Ubuntu.

Revision history for this message
Colin Watson (cjwatson) wrote :

Looks like this has built everywhere now; GCC 4.9 managed to build gnustep-base on powerpc and ppc64el.

Changed in gnustep-base (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Artur Rona (ari-tczew) wrote :

The question is, whether can we drop the delta in future?

Revision history for this message
Dmitry Shachnev (mitya57) wrote :

Yes, we should drop this delta, it was needed for debugging purposes only.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.