[Pkg-ia32-libs-maintainers] NMU ia32-libs 20100905

[Goswin von Brederlow]

Philipp Kern <pkern at debian.org> writes:

> On Thu, Sep 09, 2010 at 08:58:11AM +0200, Goswin von Brederlow wrote:
>> And ld-2.11.1.so will load the elf binary and locate any listed
>> libraries in /lib32, /usr/lib32, /usr/local/lib32 or
>> /usr/lib/i486-linux-gnu (from /etc/ld.so.conf.d/i486-linux-gnu.conf).
>
> And the ld.so.conf file is shipped by whom exactly?

libc6-i386 on amd64. On ia64 there is no such file and
/usr/lib/i486-linux-gnu won't be checked. But ia32-libs* use only the
biarch directories, not the multiarch dir so that is OK.

>> Yes you did and there was. Hence the ticket for it. Just because it
>> hadn't passed review and was uploaded yet doesn't mean it didn't
>> exist. One of the reasons the review took so long was that I included
>> the RC bugfix you mentioned. Plus the package is painfull to review in
>> any case as you might have noticed.
>
> The ticket references a non-existing file on mentors.d.n.  Thus I cannot check
> if you fixed it correctly.  Just fixing the symlink would've left it broken
> because it also needed a ld.so.conf snippet to add /emul/ia32-linux/{usr/,}lib
> to the library search path at all.

Mentors.d.n removes files after a while or when a new version (like the
unstable upload) is upploaded so it is not surprising it is gone.

Why should it need a ld.so.conf snipplet to add /emul/...? /lib32 and
/usr/lib32 are hardcoded in the ld.so and they link to /emul/... 

> I suppose we don't see any such update soon if even the referenced thing
> went away.  (See for yourself, log into rt.debian.org with guest/readonly and
> see the current state of #2283.  The thing I "screwed" up for getting
> sun-java back in sync.)

The point is that if you had just asked you could have kicked the
security team to get on with it or uploaded it via s-p-u and saved
yourself the work of doing your own upload.

> Of course the question remains: Obviously if the ia64 upload was cross-build
> and not installed afterwards (as it was not installable), how was it tested?
>
> (Yes, I do realize that buildd uploads are not tested neither.  But in this
> case a binary upload was made that was not built in a clean environment.)
>
> Bye
> Philipp Kern

The ia64 upload shouldn't have been build. Can't be cross build as long
as dpkg-shlibdeps picks the wrong depends when cross building. I guess
FS simply forgot about that in the haste. It's the first upload that
depends on ia32-libs-core. Shit happens. At least now we get to test if
binNMUs work as they should.

The ia64 upload wasn't tested and has never ever been tested (at least
since bdale gave up). None of us have (root) access to ia64 so the best
we can do is upload the package blind and then ask the Debian Admins to
install it on the ia64 developer machine.

We also rely on bugreports from users to tell us when something is
broken. But look at how long it took someone to notice the ld.so link
was broken on ia64 (about 6 years). Ia64 seems pretty much dead and the
debian-ia64 ML seems equaly non-responsive. All of that together makes
it hard to maintain the package.

MfG
        Goswin