[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy

[Marco Rodrigues]

This package FTBFS due to Ubuntu building arch:all packages on i386. So isn't a Debian bug, but an Ubuntu bug.

It needs manual bootstrapping by an buildd admin, it can only be build on sparc, but can be used anywhere (in other archs), like emulators.

http://launchpadlibrarian.net/11123858/buildlog_ubuntu-hardy-i386.openbios-sparc_1.0%7Ealpha2%2B20070816-1_FAILEDTOBUILD.txt.gz

[Adam Conrad (adconrad)]

17:49 <infinity> This isn't a "bootstrap request", it's a request for me to manually build every single
                 upload of this package. :/
17:50 <infinity> A more automated solution would be to hack the current package to produce an
                 "opensbios-bootstrap_sparc.deb", and then have another source package that
                 build-depends on that and uses the binary to produce "openbios-sparc_all.deb"

Or something like that, anyway.

[Adam Conrad (adconrad)]

Note that it *is* a bug for an arch:all build to assume it has any specific architecture's (including i386) compilers or features laying around. The fact that this "works in Debian" is an artifact of Debian allowing binary uploads, not a statement that the package isn't equally buggy there.

[Loïc Minier (lool)]

I'm not sure how the solution proposed in comment #1 would work: let's say we have an openbios-bootstrap_sparc.deb in the sparc Packages.gz, we could build-dep on openbios-bootstrap in another source package only enabled for Architecture: sparc, but we'd have to build the arch: all package in binary-arch: (as binary-indep is only called on i386, right?). That would be a bit ugly. Would Launchpad actually accept an _all package built during a binary-arch build?

Also, if we can actually build arch all packages in binary-arch, I don't think we need two source packages.

[Emmet Hikory (persia)]

We can't actually build arch all packages in binary-arch : even though it's possible to convince a rules file to generate such things, Soyuz won't accept the upload (as of March 2010), so such a model doesn't work.

[Loïc Minier (lool)]

I tried "Architecture: all sparc" in control, and having two package entries with the same package name (one with Architecture: sparc, the other with Architecture: all) and both are rejected by dpkg-dev.

I tried forcing a build on sparc by adding a dummy sparc-only binary package and got this build error:
I tried forcing a build on sparc and got:
dpkg-buildpackage: host architecture sparc
 /usr/bin/fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -rf obj-*
rm -f config.xml rules.xml
rm -f *-stamp
dh_clean
 debian/rules build
dh_testdir
# Sparc32 build
config/scripts/switch-arch sparc32
chmod: cannot access `utils/dist/debian/rules': No such file or directory
Configuring OpenBIOS on sparc32 for sparc32
Initializing build tree obj-sparc32...ok.
Creating target Makefile...ok.
Creating config files...ok.
/usr/bin/make all PWD=/build/buildd/openbios-sparc-1.0
make[1]: Entering directory `/build/buildd/openbios-sparc-1.0'
/usr/bin/xsltproc
Building OpenBIOS on sparc32 for sparc32
Building...error:
tail: cannot open `/build.log' for reading: No such file or directory
make[1]: *** [build] Error 1
make[1]: Leaving directory `/build/buildd/openbios-sparc-1.0'
make: *** [build-stamp] Error 2

[Loïc Minier (lool)]

I tried building an arch: all package during binary-arch on powerpc and that built but failed to build as follows:
2010-03-22 23:05:19 INFO creating lockfile
2010-03-22 23:05:24 DEBUG Initialising connection.
2010-03-22 23:05:24 DEBUG Beginning processing
2010-03-22 23:05:24 DEBUG Checked in /srv/launchpad.net/builddmaster/incoming, found ['20090329-203858-922921-2097984', '20090330-155209-923375-2098617', '20090423-141240-957826-2147213', '20091109-122604-1337365-2776402', '20100107-132851-1434049-2953852', '20100322-230516-1575720-3215052']
2010-03-22 23:05:24 DEBUG Considering upload 20090329-203858-922921-2097984
2010-03-22 23:05:24 DEBUG Skipping 20090329-203858-922921-2097984 -- does not match 20100322-230516-1575720-3215052
2010-03-22 23:05:24 DEBUG Considering upload 20090330-155209-923375-2098617
2010-03-22 23:05:24 DEBUG Skipping 20090330-155209-923375-2098617 -- does not match 20100322-230516-1575720-3215052
2010-03-22 23:05:24 DEBUG Considering upload 20090423-141240-957826-2147213
2010-03-22 23:05:24 DEBUG Skipping 20090423-141240-957826-2147213 -- does not match 20100322-230516-1575720-3215052
2010-03-22 23:05:24 DEBUG Considering upload 20091109-122604-1337365-2776402
2010-03-22 23:05:24 DEBUG Skipping 20091109-122604-1337365-2776402 -- does not match 20100322-230516-1575720-3215052
2010-03-22 23:05:24 DEBUG Considering upload 20100107-132851-1434049-2953852
2010-03-22 23:05:24 DEBUG Skipping 20100107-132851-1434049-2953852 -- does not match 20100322-230516-1575720-3215052
2010-03-22 23:05:24 DEBUG Considering upload 20100322-230516-1575720-3215052
2010-03-22 23:05:24 DEBUG Considering changefile 6546/ubuntu/openhackware_0.4.1-4ubuntu1~arm2_powerpc.changes
2010-03-22 23:05:25 DEBUG Finding fresh policy
2010-03-22 23:05:25 ERROR Exception while processing upload /srv/launchpad.net/builddmaster/incoming/20100322-230516-1575720-3215052 (OOPS-1542FTPMASTER1)
2010-03-22 23:05:25 DEBUG Moving upload directory /srv/launchpad.net/builddmaster/incoming/20100322-230516-1575720-3215052 to /srv/launchpad.net/builddmaster/failed/20100322-230516-1575720-3215052
2010-03-22 23:05:25 DEBUG Rolling back any remaining transactions.
2010-03-22 23:05:25 DEBUG Removing lock file: /var/lock/process-upload-buildd.lock

[Adam Conrad (adconrad)]

Has anyone tried the PALO hack that I mentioned in #64501? I don't have sparc hardware to fiddle with this one, but I could fix the PPC issue, and skeleton in a similar fix for the sparc one. Ultimately, though, it will need someone to take ownership of doing the not-quite-source source uploads. Simple enough to do, I guess, if we carry an Ubuntu revision, and make it painfully obvious that the source package must be built on the native arch (with a sane toolchain, etc).

I dunno. The only non-icky solution to this is arch:all affinity in Soyuz, but that never happened while I was working for Canonical, and while I think it's still deep down on someone's TODO, it's clearly not high priority, given the relatively limited payout for a reasonably annoying change in plumbing.

[Matthias Klose (doko)]

won't fix for current development release

[Rolf Leggewie (r0lf)]

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".