[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFH: Multiarch capable toolchain as release goal

Luk Claes <luk@debian.org> writes:

> Goswin von Brederlow wrote:
>> Wed, 21 Jun 2006 00:48:26 +0200: NMU attempt gets vetoed
> Nope, this is only a patch with a mail subject 'Patch for pending NMU of
> binutils'

The BTS doesn't show it but it was vetoed.

>> Wed, 28 Jun 2006 11:01:53 +0200: 2. maintainer misunderstands the patch
>> Thu, 29 Jun 2006 22:44:30 +0200: some discussion about the misunderstanding
>> Mon, 11 Sep 2006 15:58:28 +0200: patch update for the i386->i486 ABI change
>> Sun, 29 Apr 2007 00:12:48 +0200: prodding the maintainer for an reaction
>> Thu, 28 Jun 2007 03:43:16 +0100: first real reply by maintainer
> Patch was not ready...
>> Mon, 02 Jul 2007 19:14:35 +0200: patch fix for issues raise by maintainer
> Didn't look like the issue was settled as the mail of Aurélien on 03 Jul
> was ending questioning the patch...

He only tries to understand the problem of the i386->i486 ABI
change. That is actually a different issue and a bug that was
introduced into binutils when dpkg changed the architecture from i386
to i486. Doesn't quite belong in this bug but should be seperate.

The problem is that binutils defaults to i386-linux-gnu for the ia32
abi and debian/rules overrides that through the host/target options to
configure on i386. On amd64 though the host/target says
x86_64-linux-gnu and binutils mangles that internally to
i386-linux-gnu for the ia32 abi. There is no option to configure to
set the gnu tripplet for the alternative abis binutils builds beside
the main one.

The effect is that binutils currently has different crosscompile
directories for ia32 abi on i386 and amd64. The
140_amd64_has_i486_subtarget.dpatch patch at the end of the report
works around the issue by changing the mangling.

>> Thu, 26 Jul 2007 15:56:45 +0200: patch split into the ABI and multiarch parts
>> An NMU was tried and it and all future NMU where vetoed by the maintainer.
> I only see discussion about the misunderstanding of a patch and fixing
> of the patch after the maintainer comment.
> There was no mail asking if it was allright to NMU, nor a real NMU
> attempt AFAICS...
>> In summary:
>> - 13 month from initial report to raising a minor issue that has no
>>   negative effects on the functionality
>> - 4 days to fix the issue
> Not clear from the bug log that everything was right already...

The only issue the maintainer had with the patch was fixed. I still
think the original one was more right but the maintainer wished
otherwise and got his wish. 

>> - 9 month without reaction and counting
> 9 month waiting instead of trying to resolve the issue...

I did ask Mathias (doko) on irc a few times about it without responce
and James has me on ignore so there is no point asking him. But that
isn't aparent from the BTS.

As summarised: no reaction. Doesn't say no trying.

> Btw looks like a very colored summary to me...

and it is green. Or is it purple?

> If I want a feature to be included in a package which the maintainer is
> not really interested in, I would make sure that my patch would be ready
> to apply and/or make sure I tried to actually NMU...
> Cheers
> Luk
> PS: I would not mind having multiarch support myself...


Reply to: