DevHeads.net

Proposed removal of unbuildable binaries from lucid (https://wiki.ubuntu.com/LucidPlatformSupportableBinaries)

Hi all,

At UDS in Dallas, it was proposed that we run a round of removals of those
binary packages from sources that fail to build in lucid, so that we would
enter the LTS release clean and no users would wind up installing binary
packages that it would be impossible for us to provide security support for.

<a href="https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-supportable-binaries" title="https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-supportable-binaries">https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-supporta...</a>

Although it's taken longer than expected to get the list of removal
candidates together, I believe this is still the right thing for us to do
for Lucid, since anything on this list not only was failing to build at the
time of the karmic release, but remains unbuildable after five months of
development in lucid, so I am proposing here the list of packages for
removal.

A total of 391 binary packages from 124 distinct source packages would be
removed from universe and multiverse under this proposal.

Some supporting files are available at
<a href="http://people.canonical.com/~vorlon/foundations-lucid-supportable-binaries/:" title="http://people.canonical.com/~vorlon/foundations-lucid-supportable-binaries/:">http://people.canonical.com/~vorlon/foundations-lucid-supportable-binari...</a>

nbs.* - the build failure summaries from the beginning of the karmic cycle
find-current-failed-binaries.py - the script used to generate the list of
removal candidates (eyeballs welcome!)
removal-candidates.txt - the list of candidates for removal, same as
attached to this mail, showing source & binary package names; version
number of binary package to remove; and architectures the removal should
be applied to.

If there are no outstanding objections as of April 1, this removal candidate
list will be passed through the following one-liner to remove the binary
packages on the specified architectures:

while read source binary version archs; do for arch in $archs; do
if [ "$arch" = all ]; then arch= ; else arch="-a $arch"; fi; \
lp-remove-package.py -u $SUDO_USER -by \
-m "FTBFS: https://blueprints.launchpad.net/ubuntu/+spec/foundations-lucid-supportable-binaries" \
-e $version $arch $binary; done; done < removal-candidates.txt

This takes care to remove binaries on i386 or amd64 only if the package
fails to build *on that architecture*, and to only remove binaries for the
ports architectures if they're at the same version as the failing packages
on either i386 or amd64. (That may miss some binaries for ports if they
started failing to build at a different, /earlier/ version than on x86, but
avoids us accidentally removing ports binaries when the package actually
*does* build on the ports while failing to build on i386 or amd64.)

Comments welcome.

Cheers,

Comments

Re: Proposed removal of unbuildable binaries from lucid (https:/

By Michael Bienia at 03/28/2010 - 09:34

libfile-which-perl in DEPWAIT on libtest-script-perl >= 1.05 which
itself is in DEPWAIT on libprobe-perl-perl and libprobe-perl-perl waits
on getting promoted to main (MIR bug #522232).

Builds with libtest-script-perl 1.07 which is currently in DEPWAIT (see
above).

Is in DEPWAIT on libfile-which-perl (see above) but builds once
liborlite-perl got build too.

Michael

Re: Proposed removal of unbuildable binaries from lucid (https:

By Andrew at 03/28/2010 - 11:43

This has been fixed in Debian. I've just synced the package and it now
builds on Lucid correctly.

Thanks,

Andrew Starr-Bochicchio

Re: Proposed removal of unbuildable binaries from lucid (https:/

By Stefan Potyra at 03/28/2010 - 08:24

Hi,

first off big thanks for the work!

Am Sunday 28 March 2010 06:41:56 schrieb Steve Langasek:

few bits missing yet from the haskell transition. I'd hate to see this go, but
luckily we're only three syncs away to have it buildable again (bug #550208,
#550223 and #550246).

From a quick grep, gcc-4.2 seems to be a build-dep of sdlmame (multiverse)
and a dependency of gdc-4.2 (universe). Maybe we should take a look at these
as well?

Removed in unstable, source can go as well: bug #550191.

Cheers,
Stefan.

Re: Proposed removal of unbuildable binaries from lucid (https:/

By Benjamin Drung at 03/28/2010 - 07:41

Am Samstag, den 27.03.2010, 21:41 -0700 schrieb Steve Langasek:

I will package 1.52 and try to get it into Debian. It's better to have a
recent version in the archive instead of having none.

Re: Proposed removal of unbuildable binaries from lucid (https:/

By =?iso-8859-1?Q?... at 03/28/2010 - 05:54

Actually I'm not sure the FTBFS report of that one is correct; it
seemed to be missing gpg, but gnupg is Build-Essential: yes; I uploaded
a package build-deping on gnupg explicitly because I thought this was a
problem with the Launchpad chroots, but actually these *do* include
gpg, I guess Lucas' chroots were missing it. Latest upload built fine.

Anyway, please keep :-) we can sync it again after next Debian
upload.

The unmodified versin we have from Debian wants tevent 0.9.6, but we
have tevent 0.9.8; I propose syncing samba4 4.0.0~alpha8+git20090912-1
from unstable.

I had looked at zzuf a couple of times already, but I'm just realizing
that our -Bsymbolic-functions eglibc probably breaks the dynamic linker
tricks it's trying to use.

I think this one might be solved; used to fail with:
PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 75 bytes) in /build/user-php-doc_20081024-1-amd64-skQRqj/php-doc-20081024/configure.php on line 189
the build log at
<a href="http://people.ubuntuwire.org/~lucas/ubuntu-nbs/64/php-doc_20081024-1_llucid64.buildlog" title="http://people.ubuntuwire.org/~lucas/ubuntu-nbs/64/php-doc_20081024-1_llucid64.buildlog">http://people.ubuntuwire.org/~lucas/ubuntu-nbs/64/php-doc_20081024-1_llu...</a>
is from Thu Mar 11 00:51:06 +0100 2010 and php5 5.3.2-1 had this
change:
* Disable memory limit in CLI, letting ulimit do its job (Closes: #407425)
on Sat, 13 Mar 2010 15:11:48 -0600 which we merged in 5.3.2-1ubuntu1,
Tue, 16 Mar 2010 09:09:50 -0400.

Didn't try an actual build though.

Re: Proposed removal of unbuildable binaries from lucid (https:/

By Steve Langasek at 03/28/2010 - 17:53

Thanks to all for the feedback so far.

Please bear in mind that the proposal is to remove specific versions of
binary packages from the archive. Source packages will not be removed, nor
will binaries that don't match the version numbers listed in the report. So
if a fix is known for one of these issues, it's sufficient to push that fix
to Lucid using the normal processes. If it lands before the removal run,
the binaries will not be removed. If it lands after the removal run, the
package will have to go through binary NEW, but that's a trivial
requirement IMHO.

So I think there's no need to have a discussion here about individual
packages on the candidate list unless there are false-positives (jetring) or
if you think there are packages missing from the list.

The package has a Build-Essential: yes field in the Packages file, but isn't
the definition of build-essential "the set of packages that
'build-essential' depends on"? I have no idea what sets or honors a
Build-Essential: yes field in Packages.

Since you've uploaded a workaround there's no need to worry about the
package being removed now, but I wonder if we shouldn't be fixing this in
the build-essential package rather than expecting lucas's rebuilds to honor
what appears to be a non-standard field.

Here's what the archive spits out:

$ checkrdepends gcc-4.2 lucid
-- lucid/universe build deps on gcc-4.2:
hurd
-- lucid/universe build deps on g++-4.2:
chromium-browser
debtags-edit
-- lucid/universe amd64 deps on g++-4.2:
geordi
-- lucid/universe i386 deps on g++-4.2:
geordi
-- lucid/universe amd64 deps on libgfortran2:
abinit
libcojets2-gfortran
libeurodec1-gfortran
libgeant321-2-gfortran
libherwig59-2-gfortran
libisajet758-3-gfortran
libpdflib804-2-gfortran
libphotos202-1-gfortran
libphtools2-gfortran
openmx
zivot
-- lucid/universe i386 deps on libgfortran2:
abinit
libcojets2-gfortran
libeurodec1-gfortran
libgeant321-2-gfortran
libherwig59-2-gfortran
libisajet758-3-gfortran
libpdflib804-2-gfortran
libphotos202-1-gfortran
libphtools2-gfortran
openmx
zivot
-- lucid/universe powerpc deps on libgfortran2:
abinit
libcojets2-gfortran
libeurodec1-gfortran
libgeant321-2-gfortran
libherwig59-2-gfortran
libisajet758-3-gfortran
libpdflib804-2-gfortran
libphotos202-1-gfortran
libphtools2-gfortran
openmx
zivot
-- lucid/universe ia64 deps on libgfortran2:
abinit
openmx
zivot
-- lucid/universe sparc deps on libgfortran2:
abinit
libcojets2-gfortran
libeurodec1-gfortran
libgeant321-2-gfortran
libherwig59-2-gfortran
libisajet758-3-gfortran
libpdflib804-2-gfortran
libphotos202-1-gfortran
libphtools2-gfortran
openmx
zivot
-- lucid/universe build deps on libstdc++6-4.2-dev:
wine
wine1.2
-- lucid/multiverse build deps on gcc-4.2:
sdlmame
$

I think it would be ok to leave the reverse-deps uninstallable, but I don't
want to leave reverse-build-deps here since that just moves the same problem
up the stack. wine is a false-positive since it has an ORed build-dep on
libstdc++-dev as guaranteed by build-essential. chromium-browser is a
false-positive because it build-depends on g++-4.3 | g++-4.2 (but why
doesn't it just use the default g++? :/ ). That leaves hurd, debtags-edit,
and sdlmame to be resolved.

The hurd and debtags-edit build-deps are resolved in unstable, so it looks
like a sync / merge will take care of us. sdlmame is not in Debian - does
someone want to take responsibility for this package?

Stefan, do you agree that taking care of the reverse-build-deps is
sufficient, and the reverse-deps can be handled as normal uninstallable
packages?

Thanks,

Re: Proposed removal of unbuildable binaries from lucid (https:/

By Stefan Potyra at 03/29/2010 - 03:33

Hi Steve,

Am Monday 29 March 2010 00:53:51 schrieb Steve Langasek:
[..]

hm, looks like we're stuck in a fortran transition? Anyone who'd like to
volunteer to find out more about that?

Yes, sounds good to me. Just also took a look again if gdc-4.2 is used
anywhere as b-d (which would be uninstallable due to gcc-4.2-base), but this
doesn't appear to be the case.

Cheers,
Stefan.

Re: Proposed removal of unbuildable binaries from lucid (https:/

By Steve Langasek at 03/29/2010 - 00:48

... of course, hurd is the source package for the hurd kernel, which is not
meant to build on any architectures except Debian's hurd port. So I've
removed this source package and blacklisted it.

Cheers,

Re: Proposed removal of unbuildable binaries from lucid (https:/

By Fabrice Coutadeur at 03/29/2010 - 00:30

Hi,

Steve Langasek escribió:

I sponsored the 2 latest upload. I'll check with Cesare the build status
with a higher version of gcc.

Cheers,
Fabrice

Re: Proposed removal of unbuildable binaries from lucid (https:/

By Steve Langasek at 04/03/2010 - 00:49

Thanks for working on this, Stefan!

hurd has been resolved by a package removal; debtags has been resolved by a
QA upload + sync.

And this one appears to be in progress, so not treating it as a blocker.

Seeing no other objections, the identified binaries are now being removed.

Cheers,

Re: Proposed removal of unbuildable binaries from lucid (https:

By Mario Limonciello at 04/03/2010 - 22:53

Hi Steve:

On Fri, Apr 2, 2010 at 23:49, Steve Langasek
<steve. ... at canonical dot com>wrote:

I had a proposal I'd like to hear your feedback on. What about if at the
start of when the Maverick repositories open up (and -N, -O etc), the same
thing happens? Don't copy forward any binary packages who can't build on
the current toolchain. This could then set precedent for not allowing
packages that can't rebuild, period.

Re: Proposed removal of unbuildable binaries from lucid (https:/

By Steve Langasek at 04/05/2010 - 19:17

Hi Mario,

It's not practical to implement this as "don't copy forward", but I think it
would be a good idea to repeat this buildability check at the start of each
cycle and remove unbuildable binaries early in the cycle.

Cheers,