Robert Millan skrev:
But you set #458013 as a blocker for this bug.
Sure, but that doesn't actually make *this* bug RC. If some RC bug was
blocked on this, *then* it might effectively be RC, but that's not the
case. So there's a few RC bugs in ia32-libs that need fixing before I'll
drop the hack, but if ia32-libs is fixed, I still don't really *have* to
drop the hack to get into lenny, so this bug isn't RC. The blocker isn't
here.
If #381341 is not the right bug
for that, we could have another, then?
Well, if you want. File one if you think it'll be of use. I suppose
you'd call it something like "can't build on amd64", and block it on the
ia32-libs stuff?
Note that there is actually something I *could* do to make wine
available on amd64 without waiting for ia32-libs to be fixed. I could
reverse the change I made in 0.9.49-1:
* Also moved the generation of the amd64.tar.lzma.uu further up in the
build process, before the dh_makeshlibs/dh_installdeb/dh_shlibdeps,
so that maintainer scripts and dependencies should be generated a bit
more like they would if the binaries were compiled directly on amd64.
If I remember right, you yourself suggested that building stuff
"natively" on amd64 would somehow encourage maintainers to add the
missing 32-bit support to Debian. I added this change to approach that
ideal, and look what happened: the wine packages have *never* built on
amd64 in the 3-4 months since I did that.
Reversing this, and thus taking wine further away from a natively-built
amd64 package again, would make wine available on amd64 again (if the
dep-wait is killed too, of course), but it would probably be a setback
for your own theory...
Still, it would be a solution to this "not updated on amd64" bug you
might file (but far from a solution to the "drop amd64 hack" bug). What
would you think?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
