Your message dated Wed, 26 Mar 2008 14:38:28 +0100
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#472650 closed by Ove Kaaven <[EMAIL PROTECTED]>
(Bug#472650: fixed in wine 0.9.58-1)
has caused the Debian Bug report #472648,
regarding FTBFS on amd64 (Re: Bug#381341: severity)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
472648: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472648
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: wine
Severity: serious
Version: 0.9.57-1
Tags: patch
Ok, here's your new bug (yes, with patch -- see below)
On Tue, Mar 25, 2008 at 02:12:52PM +0100, Ove Kaaven wrote:
> 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?
Now that I think, you can easily disable that annoying check with:
--- wine-0.9.57.old/debian/rules 2008-03-25 16:17:32.000000000 +0100
+++ wine-0.9.57/debian/rules 2008-03-25 16:16:52.000000000 +0100
@@ -312,7 +312,7 @@
dh_makeshlibs -plibwine -n -V "libwine (= $(VERSION))"
bash debian/gendeps.sh $(patsubst build%,%,$(BUILDS))
- dh_shlibdeps -s -Llibwine -ldebian/libwine/usr/lib
+ dh_shlibdeps -s -Llibwine -ldebian/libwine/usr/lib --
--ignore-missing-info
bash debian/cleandeps.sh
# relaxed libwine dependencies for everyone else
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)
--- End Message ---
--- Begin Message ---
Version: 0.9.58-1
On Wed, Mar 26, 2008 at 01:06:16PM +0000, Debian Bug Tracking System wrote:
> * Added --ignore-missing-info to the dh_shlibdeps in debian/rules,
> to see if it might work around the broken ia32-libs package that
> the Debian amd64 port is currently suffering from. (Suggested by
> Robert Millan.)
You forgot to close this one.
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)
--- End Message ---
