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

[Philipp Kern]

On Thu, Sep 09, 2010 at 04:47:54PM +0200, Goswin von Brederlow wrote:
> > 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.
> 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/... 

To my knowledge /usr/lib32 is not hardcoded in the i386 linker we use on ia64.
amd64 uses the native linker, so that one has more knowledge than reusing the i386
one on ia64.

> 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.

To the point that sun-java* wouldn't be fixed for the point release last
Staurday, right.

> 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.

Or asking the admins to work something out, like me telling them what to
do to get ia32-libs fixed for Lenny.  It's not that they're totally
uncooperative.

> 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.

Right, but then it would make sense to drop it, instead of claiming to
support it and inventing new solutions like ia32-libs-core.  I do understand
where you're coming from, but I don't know if it's useful to have a new
ia64-only solution that nobody looked at before the release.

Kind regards,
Philipp Kern

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-ia32-libs-maintainers/attachments/20100909/353b0ad1/attachment.pgp>