Debian Bug report logs - #594179
Please add new architecture armhf (ie. quads instead of triplets) support in dpkg

version graph

Package: dpkg; Maintainer for dpkg is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg is src:dpkg.

Reported by: Konstantinos Margaritis <markos@genesi-usa.com>

Date: Tue, 24 Aug 2010 10:57:00 UTC

Severity: normal

Tags: patch

Merged with 604660

Found in version dpkg/1.15.8.4

Fixed in version dpkg/1.16.0

Done: Guillem Jover <guillem@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Tue, 24 Aug 2010 10:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Konstantinos Margaritis <markos@genesi-usa.com>:
New Bug report received and forwarded. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 24 Aug 2010 10:57:03 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Konstantinos Margaritis <markos@genesi-usa.com>
To: submit@bugs.debian.org
Subject: Please add new architecture armhf (ie. quads instead of triplets) support in dpkg
Date: Tue, 24 Aug 2010 13:45:42 +0300
[Message part 1 (text/plain, inline)]
Package: dpkg
Version: 1.15.8.4
Severity: normal
Tags: patch

*** Please type your report below this line ***

Hi,

You probably are aware of the new armhf port started on debian-ports.org. [1]
As mentioned in the mail, the most important patch necessary for the port is 
in dpkg, in order to add support for the architecture. I attach a patch 
necessary for dpkg to detect armhf as arm-hardfloat-linux-gnueabi. The changes 
affect only dpkg-architecture.pl and Dpkg.pm perl scripts, and of course the 
ostable/triplettable. The important difference is that now these scripts work 
internally with quads instead of triplets, however in the case of the rest of 
the arches, the vendor field is set to 'undef'. I have tested it on armel and 
it works as before.

Last, in the patch I have included some simple print statements for debugging 
purposes, I assumed they should be useful to whomever wants to see how it 
works. It's also possible that I have misunderstood some dpkg internals and I 
have made a mistake, in that case feel free to suggest a better method. Still, 
I've build ~3000 armhf packages using that patch already with no problems so 
far -well, none dpkg-related at any rate.

Due to its significant importance -the armhf port is useless without this 
patch- we would greatly appreciate if you could incorporate the patch in some 
future version of dpkg.

Regards

Konstantinos Margaritis
Senior Software Engineer, armhf port maintainer
Genesi USA

[1]: http://lists.debian.org/debian-arm/2010/08/msg00008.html
[dpkg-quads-armhf.patch (text/x-patch, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Tue, 07 Sep 2010 11:03:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Konstantinos Margaritis <markos@genesi-usa.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 07 Sep 2010 11:03:07 GMT) Full text and rfc822 format available.

Message #10 received at 594179@bugs.debian.org (full text, mbox):

From: Konstantinos Margaritis <markos@genesi-usa.com>
To: 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org, Matt Sealey <matt@genesi-usa.com>
Subject: dpkg armhf patch acceptance status?
Date: Tue, 7 Sep 2010 14:01:37 +0300
Hi all,

  I really would like to know the stance of the dpkg maintainers regarding the 
armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file as 
bug reports, but without the dpkg patch, those patches would be useless, so 
I'm holding back, but that in the meantime increases the workload as newer 
packages appear all the time and I have to forward port the armhf patches all 
the time. Plus, the whole port is unusable without dpkg functioning properly. 
The patched version I have uploaded in debian-ports works fine without any 
side-effects whatsoeer. I'm not asking for immediate acceptance, but even a 
short mail of 'it's ok, but needs more work here and there' will do. 

I'm posting this with both hats on, Genesi and Debian (I recently rejoined 
Debian as a DD). WRT Genesi, the company has been a long time supporter of 
Debian -the recent donation of dozens of EfikaMX systems to DDs and 2x2TB SATA 
disks for storage of the debian-ports archive only strengthens that position. 
WRT Debian, I know that the port is not yet an accepted official one -heck, 
it's not even usable yet, but the patch -or something that provides the same 
functionality- is absolutely needed for the port to actually exist and evolve. 

I would really appreciate a reply.

Regards

Konstantinos Margaritis
Genesi USA, Senior Software engineer, armhf port maintainer




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Tue, 07 Sep 2010 13:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hector Oron <zumbi@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 07 Sep 2010 13:09:03 GMT) Full text and rfc822 format available.

Message #15 received at 594179@bugs.debian.org (full text, mbox):

From: Hector Oron <zumbi@debian.org>
To: 594179@bugs.debian.org
Subject: Re: Bug#594179: dpkg armhf patch acceptance status?
Date: Tue, 7 Sep 2010 14:07:34 +0100
[Message part 1 (text/plain, inline)]
Hello,

  I would like to second this patch as ARM porter.

Cheers,
-- 
 Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us."

-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Wed, 08 Sep 2010 09:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 08 Sep 2010 09:42:03 GMT) Full text and rfc822 format available.

Message #20 received at 594179@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Konstantinos Margaritis <markos@genesi-usa.com>
Cc: 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org, Matt Sealey <matt@genesi-usa.com>
Subject: Re: dpkg armhf patch acceptance status?
Date: Wed, 8 Sep 2010 11:40:13 +0200
Hi!

[ I'm leaving for two days, and running out the door just right now, so
  this mail is a bit rushed, and might contain inaccuracies and
  repetition due to lack of proper review, sorry about that, I'll try
  to clarify anything unclear once I get back. ]

On Tue, 2010-09-07 at 14:01:37 +0300, Konstantinos Margaritis wrote:
>   I really would like to know the stance of the dpkg maintainers regarding the 
> armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file as 
> bug reports, but without the dpkg patch, those patches would be useless, so 
> I'm holding back, but that in the meantime increases the workload as newer 
> packages appear all the time and I have to forward port the armhf patches all 
> the time. Plus, the whole port is unusable without dpkg functioning properly. 
> The patched version I have uploaded in debian-ports works fine without any 
> side-effects whatsoeer. I'm not asking for immediate acceptance, but even a 
> short mail of 'it's ok, but needs more work here and there' will do. 

I don't quite like the current implementation, which abuses the vendor
for information related to the ABI.

So, recapping a bit the long thread about the new port:


I agree with Paul Brook that abusing the vendor in this way poses a
compatibility issue with upstreams, I'd rather not use something like
this which is probably Debian specific.


We currently need something like this in dpkg-dev because the mappings
need to be bidirectional, as dpkg-dev needs to be able to convert
from GNU triplet to Debian architecture and the other way around.

Steve wondered why this is the case, and that's because for
cross-compiling purposes dpkg-architecture infers the host architecture
from the CC environment variable through the -dumpmachine option.
Chaning this is possible but, would break a current way of
cross-compiling which has been around for a long time.


The toolchain has the same triplet for binary incompatible producing
objects, which seems like a bug/misfeature to me, and that's one of
the assumptions dpkg-dev has relied on, in the same way as multiarch
when deciding to use the triplet as a unique token for the installation
directories. Although one can produce binary incompatible output with
normal gcc options, like changing the calling conventions with something
like for example -fpcc-struct-return, but those are not part of the
default ABI, and are expected and warned as producing incompatible
binaries.

This also causes issue with not being able to have installed two
cross-toolchains for say armel and armhf as they share triplet,
although you can use the armel toolchain with few options to build for
armhf, but then you'd need to specify those as part of the CC variable.
Also that also happens with biarch, you can produce i386 binaries from
an x86_64 toolchain, yet they both have their own triplet.

I'm just wondering if this is also the case for mips triarch, or do
those have each their own triplet, and is only arm that has this
issue?

Anyway, ideally I'd rather see this addressed by giving armhf a real
triplet, which would also make multiarch life way easier as there'd not
be any need to define an artificial set of neutral architecture names
to be able to place objects in the file system. But if this is not going
to happen, and thus the assumptions dpkg-dev is making have been just
wrong, then I'd rather drop the bidirectional mappings, and be done
with it. This will need careful consideration though, as it's breaking
a current interface, but something that could be done for dpkg 1.16.x.


I can propose a patch for this once I get back.


thanks,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Wed, 08 Sep 2010 17:12:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 08 Sep 2010 17:12:04 GMT) Full text and rfc822 format available.

Message #25 received at 594179@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Konstantinos Margaritis <markos@genesi-usa.com>, 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org, Matt Sealey <matt@genesi-usa.com>
Subject: Re: dpkg armhf patch acceptance status?
Date: Wed, 8 Sep 2010 10:10:06 -0700
[Message part 1 (text/plain, inline)]
On Wed, Sep 08, 2010 at 11:40:13AM +0200, Guillem Jover wrote:
> This also causes issue with not being able to have installed two
> cross-toolchains for say armel and armhf as they share triplet,
> although you can use the armel toolchain with few options to build for
> armhf, but then you'd need to specify those as part of the CC variable.
> Also that also happens with biarch, you can produce i386 binaries from
> an x86_64 toolchain, yet they both have their own triplet.

> I'm just wondering if this is also the case for mips triarch, or do
> those have each their own triplet, and is only arm that has this
> issue?

mips have distinct triplets for each of their archs, yes.

> Anyway, ideally I'd rather see this addressed by giving armhf a real
> triplet, which would also make multiarch life way easier as there'd not
> be any need to define an artificial set of neutral architecture names
> to be able to place objects in the file system.

I realize this is ideal, but:

 - there's been very strong upstream pushback on this, asserting that this
   is the correct triplet to use for both arm calling conventions, so if we
   require a distinct triplet for armhf (instead of using the vendor field),
   that's going to block any armhf port for quite a while (possibly
   indefinitely)

 - armhf was not the sole motivation for the proposal to define neutral
   architecture names; x86 was already a problem because of the changing
   triplets depending on which level of instruction set compatibility is
   targeted.  *Both* of these examples show that GNU triplets are not
   defined in a way that they map directly to what we need for multiarch, so
   it's best to explicitly define our mapping externally.

So even if you persuaded the upstream toolchain folks to specify a new
triplet for armhf after all, I think we should still go ahead with a
separate name mapping table for multiarch.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Fri, 10 Sep 2010 07:39:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 10 Sep 2010 07:39:08 GMT) Full text and rfc822 format available.

Message #30 received at 594179@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Konstantinos Margaritis <markos@genesi-usa.com>
Cc: 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org, Matt Sealey <matt@genesi-usa.com>
Subject: Re: dpkg armhf patch acceptance status?
Date: Fri, 10 Sep 2010 09:35:24 +0200
Steve Langasek <vorlon@debian.org> writes:

> On Wed, Sep 08, 2010 at 11:40:13AM +0200, Guillem Jover wrote:
>> This also causes issue with not being able to have installed two
>> cross-toolchains for say armel and armhf as they share triplet,
>> although you can use the armel toolchain with few options to build for
>> armhf, but then you'd need to specify those as part of the CC variable.
>> Also that also happens with biarch, you can produce i386 binaries from
>> an x86_64 toolchain, yet they both have their own triplet.
>
>> I'm just wondering if this is also the case for mips triarch, or do
>> those have each their own triplet, and is only arm that has this
>> issue?
>
> mips have distinct triplets for each of their archs, yes.
>
>> Anyway, ideally I'd rather see this addressed by giving armhf a real
>> triplet, which would also make multiarch life way easier as there'd not
>> be any need to define an artificial set of neutral architecture names
>> to be able to place objects in the file system.
>
> I realize this is ideal, but:
>
>  - there's been very strong upstream pushback on this, asserting that this
>    is the correct triplet to use for both arm calling conventions, so if we
>    require a distinct triplet for armhf (instead of using the vendor field),
>    that's going to block any armhf port for quite a while (possibly
>    indefinitely)
>
>  - armhf was not the sole motivation for the proposal to define neutral
>    architecture names; x86 was already a problem because of the changing
>    triplets depending on which level of instruction set compatibility is
>    targeted.  *Both* of these examples show that GNU triplets are not
>    defined in a way that they map directly to what we need for multiarch, so
>    it's best to explicitly define our mapping externally.
>
> So even if you persuaded the upstream toolchain folks to specify a new
> triplet for armhf after all, I think we should still go ahead with a
> separate name mapping table for multiarch.
>
> Cheers,

Note that uclibc also suffers this problems. x86_64-linux-uclibc is in
no way unique as different uclibc compile options create different ABIs
all with the same tripplet.

I filed a wishlist bug against dpkg-architecture to please provide
DEB_HOST_ABI / DEB_BUILD_ABI and to start giving that as
DEB_HOST_GNU_TYPE / DEB_BUILD_GNU_TYPE initialy. Ports where this is
insufficient can then extend the table to give a unique value.

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Mon, 13 Sep 2010 18:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 13 Sep 2010 18:57:04 GMT) Full text and rfc822 format available.

Message #35 received at 594179@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: Konstantinos Margaritis <markos@genesi-usa.com>, 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org, Matt Sealey <matt@genesi-usa.com>
Subject: Re: dpkg armhf patch acceptance status?
Date: Mon, 13 Sep 2010 11:54:52 +0200
On Wed, Sep 08, 2010, Guillem Jover wrote:
> Steve wondered why this is the case, and that's because for
> cross-compiling purposes dpkg-architecture infers the host architecture
> from the CC environment variable through the -dumpmachine option.
> Chaning this is possible but, would break a current way of
> cross-compiling which has been around for a long time.

 Should perhaps use "dpkg --print-architecture" instead?  or is it for
 cross-compiling dpkg itself on systems without dpkg?

-- 
Loïc Minier




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Mon, 04 Oct 2010 21:30:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hector Oron <zumbi@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 04 Oct 2010 21:30:06 GMT) Full text and rfc822 format available.

Message #40 received at 594179@bugs.debian.org (full text, mbox):

From: Hector Oron <zumbi@debian.org>
To: 594179@bugs.debian.org
Subject: dpkg: `armhf' patch acceptance status?
Date: Mon, 4 Oct 2010 17:28:19 -0400
Hello,

  Is there any update on this patch?

Best Regards,
-- 
 Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."

-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Mon, 08 Nov 2010 14:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hector Oron <zumbi@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 08 Nov 2010 14:54:03 GMT) Full text and rfc822 format available.

Message #45 received at 594179@bugs.debian.org (full text, mbox):

From: Hector Oron <zumbi@debian.org>
To: 594179@bugs.debian.org
Cc: markos@debian.org
Subject: dpkg: armhf support
Date: Mon, 8 Nov 2010 14:52:09 +0000
[Message part 1 (text/plain, inline)]
Dear maintainers,

 Is there any update on this patch? armhf port is currently up to 80% of the archive already built [1].
 Thanks all

[1] http://buildd.debian-ports.org/stats/graph.png

Best regards,
-- 
 Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us."

-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html
[signature.asc (application/pgp-signature, inline)]

Forcibly Merged 594179 604660. Request was from Aurelien Jarno <aurelien@aurel32.net> to control@bugs.debian.org. (Wed, 24 Nov 2010 13:24:14 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Tue, 07 Dec 2010 14:03:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Hector Oron <hector.oron@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 07 Dec 2010 14:03:06 GMT) Full text and rfc822 format available.

Message #52 received at 594179@bugs.debian.org (full text, mbox):

From: Hector Oron <hector.oron@gmail.com>
To: 594179@bugs.debian.org
Cc: Neil Williams <codehelp@debian.org>, Wookey <wookey@debian.org>, Konstantinos Margaritis <markos@debian.org>
Subject: dpkg: emdebian.org and other machines patched for armhf support
Date: Tue, 7 Dec 2010 14:02:16 +0000
Hello,

  I am patching machines to support armhf, which it is almost at 90%
built. I know you are very busy with squeeze release, but could you
give a comment if the patch is wrong or right, as we are using it for
patching machines? Why is it taking so long to include such
architecture?
  Let me know if I can help you out doing a NMU if you do not have the time.

Best regards,
-- 
 Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."

-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Tue, 07 Dec 2010 14:57:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Konstantinos Margaritis <markos@genesi-usa.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 07 Dec 2010 14:57:07 GMT) Full text and rfc822 format available.

Message #57 received at 594179@bugs.debian.org (full text, mbox):

From: Konstantinos Margaritis <markos@genesi-usa.com>
To: Hector Oron <hector.oron@gmail.com>, debian-arm@lists.debian.or, "linaro-dev" <linaro-dev@lists.linaro.org>
Cc: 594179@bugs.debian.org, Neil Williams <codehelp@debian.org>, Wookey <wookey@debian.org>
Subject: Re: dpkg: emdebian.org and other machines patched for armhf support
Date: Tue, 7 Dec 2010 16:55:12 +0200
On Tuesday 07 December 2010 16:02:16 Hector Oron wrote:
> Hello,
> 
>   I am patching machines to support armhf, which it is almost at 90%
> built. I know you are very busy with squeeze release, but could you
> give a comment if the patch is wrong or right, as we are using it for
> patching machines? Why is it taking so long to include such
> architecture?
>   Let me know if I can help you out doing a NMU if you do not have the
> time.

Nice timing Hector, I was just thinking of sending a mail to the lists (so I'm 
cross-posting this mail to both debian-arm and linaro-dev lists as they are 
[in]directly involved in this).

In essence, I would like to express my objection in having the same triplet 
for both softfp and hard ABIs. I know upstream (ARM) objects, but IMHO they 
just haven't done the extensive compiling I have and didn't consider the 
problems (I doubt anyone else has built ~8000 packages for a hardfloat port).

So, what is the problem: I'm trying to port some compilers now to armhf now -
gnat, openjdk, etc- using cross-compiling (you know, build a cross-compiler on 
an arch that already supports gnat, then use that cross-compiler to build a 
native binary and use that binary to build the final compiler on the native 
machine. It's a complicated process with lots of problems, but I've done this 
before -I actually did the gnat powerpc port for Debian back in 2000, using 
that same method, things have evolved since then but not that much. 

With a different triplet, I just have to add a new triplet entry for armhf to 
gnat's setup scripts. 

Using the same triplet, I would have to actually go to great lengths to change 
the scripts to use something else than the gnu triplet to decide cpu/system 
detection -not to mention that I would have to push for acceptance for each 
and every such patch. I'm sorry, but right now I have better things to do than 
this. 

Anyway, I know this point has been stressed before, but I now I would like to 
re-surface this issue again. 

Till now I was mostly indifferent, but now I'm convinced that we should *not* 
force the same triplets for the two abis until there is a concrete migration 
plan of OS detection using another method. It mostly ends down to unnecessary 
over-engineering with little benefit and way too many problems. I like 
simplicity and any other solution than a single triplet is not simple at the 
moment.

So, what does this mean? It means that someone has first to propose a proper 
solution for handling this sort of stuff when a single triplet -something like 
that has been proposed in http://bugs.debian.org/596298 but though it's a good 
idea, it has not been discussed as much as it should. It has to actually be 
decided and even then we still would have to change many configure scripts to 
use that, as gcc for example configures based on the gnu triplet, NOT 
something as arbitrary as DEB_{HOST,BUILD}_ABI. In real terms, this means it's 
going to take a very long time to actually have something that works -no I 
don't think 6 months are enough.

Anyway, with regards to the actual bug report, I have done a 1.15.8.6+armhf.1 
release -in debian-ports.org/unreleased for now- which fixes a bug I missed 
previously. Some tests also fail, but that's beside the point, they have to be 
fixed to support quads as well -which I will do in the next days and I will 
send a complete patch. For that matter, I have tested the patch on amd64 and 
i386 and it doesn't break anything. 

The problem is that with ~7600 packages built and still the port is not 
recognized by dpkg. 

So, bottom line, until the issue with multiarch/DEB_HOST_ABI is actually 
*decided* could you please please get armhf support into dpkg proper? Or at 
least give a good reason why you do not accept the patch?

Thanks

Konstantinos





Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Tue, 07 Dec 2010 17:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Konstantinos Margaritis <markos@genesi-usa.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 07 Dec 2010 17:03:03 GMT) Full text and rfc822 format available.

Message #62 received at 594179@bugs.debian.org (full text, mbox):

From: Konstantinos Margaritis <markos@genesi-usa.com>
To: Paul Brook <paul@codesourcery.com>
Cc: debian-arm@lists.debian.org, 594179@bugs.debian.org, linaro-dev@lists.linaro.org
Subject: Re: dpkg: emdebian.org and other machines patched for armhf support
Date: Tue, 7 Dec 2010 18:58:54 +0200
On 7 December 2010 18:35, Paul Brook <paul@codesourcery.com> wrote:
>> In essence, I would like to express my objection in having the same triplet
>> for both softfp and hard ABIs. I know upstream (ARM) objects, but IMHO they
>> just haven't done the extensive compiling I have and didn't consider the
>> problems (I doubt anyone else has built ~8000 packages for a hardfloat
>> port).
>
> As the relevant upstream maintainer I'll confirm this objection.  In the past
> gcc used to try and guess which config to use based on variants of the
> triplet. In practice this caused more problems than it solved, especially when
> you have a single toolchain that can target multiple variants.
>
> If you want different triplets then I suggest you use the vendor field. e.g
> arm-debian_armel-linux-gnueabi and arm-debian_armhf-linux-gnueabi.

Which is exactly what I am doing. You are right I should be more
specific. Right now,
armhf uses arm-hardfloat-linux-gnueabi -which as was suggested here uses
the vendor field. It works fine, in truth, only a handful of packages break with
the vendor field and the fix is trivial.

What was suggested to me was that the vendor field should *NOT* be used
and a single arm-linux-gnueabi should be used for both softfp and hard ABIs.
I'm sorry but especially in the case of compilers and in particular
cross-compilers,
this just does not work. Unless there is another way of OS (and ABI) detection,
like the DEB_HOST_ABI fields, there is no way to know which ABI to compile from.

So, my objection is in not keeping the arm-hardfloat-linux-gnueabi
triplet. I did not
suggest a different triplet altogether, just the ability to use the
vendor field and thus
in essence make a different triplet -but not too different.

Konstantinos




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Thu, 17 Feb 2011 11:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 17 Feb 2011 11:30:03 GMT) Full text and rfc822 format available.

Message #67 received at 594179@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#594179: dpkg armhf patch acceptance status?
Date: Thu, 17 Feb 2011 12:27:30 +0100
        Hey

 Trying to kick the dust a bit as having the triplet "in the air" is
 kind of an unhappy situation for armhf   :-)

On Wed, Sep 08, 2010, Guillem Jover wrote:
> We currently need something like this in dpkg-dev because the mappings
> need to be bidirectional, as dpkg-dev needs to be able to convert
> from GNU triplet to Debian architecture and the other way around.
> 
> Steve wondered why this is the case, and that's because for
> cross-compiling purposes dpkg-architecture infers the host architecture
> from the CC environment variable through the -dumpmachine option.
> Chaning this is possible but, would break a current way of
> cross-compiling which has been around for a long time.

 So this use case is "CC=arm-linux-gnueabi-gcc dpkg-buildpackage" and it
 just guesses the -a flag that you should have set?

> The toolchain has the same triplet for binary incompatible producing
> objects, which seems like a bug/misfeature to me, and that's one of
> the assumptions dpkg-dev has relied on, in the same way as multiarch
> when deciding to use the triplet as a unique token for the installation
> directories.

 You describe this as a bug/misfeature, that might be true but I don't
 think we can challenge this usage of triplets in the upstream
 toolchain, and multiarch is moving to having its own tuples instead now
 (http://wiki.debian.org/Multiarch/Tuples).

> This also causes issue with not being able to have installed two
> cross-toolchains for say armel and armhf as they share triplet,
> although you can use the armel toolchain with few options to build for
> armhf, but then you'd need to specify those as part of the CC variable.

 Even if we could co-install them, I'm not sure how
 /some-armel-path/arm-linux-gnueabi-gcc and
 /some-armhf-path/arm-linux-gnueabi-gcc could helpfully be installed on
 the same system   :-/

 It's a real limitation of the upstream toolchain.

> Also that also happens with biarch, you can produce i386 binaries from
> an x86_64 toolchain, yet they both have their own triplet.

 Yes but x86 goes to the other extreme, with separate triplets for
 compatible ABIs ({i386,i486,i586,i686}-linux-gnu); the fact is the
 triplet is not a good ABI specifier.

> Anyway, ideally I'd rather see this addressed by giving armhf a real
> triplet, which would also make multiarch life way easier as there'd not
> be any need to define an artificial set of neutral architecture names
> to be able to place objects in the file system. But if this is not going
> to happen, and thus the assumptions dpkg-dev is making have been just
> wrong, then I'd rather drop the bidirectional mappings, and be done
> with it. This will need careful consideration though, as it's breaking
> a current interface, but something that could be done for dpkg 1.16.x.

 Having a separate triplet (not using the vendor field) like e.g. lpia
 would mean a lot of pain IMO, and we'd have to fix many packages to
 cope with it, including reaching out to upstream etc.  It was pain for
 lpia for sure.

 We could have an additional set of preprocessor macros which dpkg
 checks for to decide which Debian architecture we're talking about; the
 the would only be done if there is more than one architecture using the
 same triplet in dpkg tables.  This alone is a bit fragile though, as it
 means that if a new ABI is introduced to an existing triplet and is not
 immediately added as a new dpkg architecture, then people might be
 picking the wrong dpkg architecture when using a toolchain defaulting
 to thenew ABI.

 I wonder whether it would be a good idea to use multiarch tuples
 internally; dpkg would still have to map to/from GNU triplets, but it
 would force implementors to think about their ABI.  I am not sure how
 we can ensure that we've mapped to the right tuple though.  Neither am
 I sure that the multiarch tuples are frozen already, so it might be too
 early for that either.

    Bye
-- 
Loïc Minier




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Thu, 17 Feb 2011 20:06:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 17 Feb 2011 20:06:06 GMT) Full text and rfc822 format available.

Message #72 received at 594179@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org
Subject: Re: dpkg armhf patch acceptance status?
Date: Thu, 17 Feb 2011 12:03:06 -0800
Loïc's latest post drew my attention back to this thread, where I see I had
this message flagged for follow-up:

On Fri, Sep 10, 2010 at 09:35:24AM +0200, Goswin von Brederlow wrote:

> > I realize this is ideal, but:

> >  - there's been very strong upstream pushback on this, asserting that this
> >    is the correct triplet to use for both arm calling conventions, so if we
> >    require a distinct triplet for armhf (instead of using the vendor field),
> >    that's going to block any armhf port for quite a while (possibly
> >    indefinitely)

> >  - armhf was not the sole motivation for the proposal to define neutral
> >    architecture names; x86 was already a problem because of the changing
> >    triplets depending on which level of instruction set compatibility is
> >    targeted.  *Both* of these examples show that GNU triplets are not
> >    defined in a way that they map directly to what we need for multiarch, so
> >    it's best to explicitly define our mapping externally.

> > So even if you persuaded the upstream toolchain folks to specify a new
> > triplet for armhf after all, I think we should still go ahead with a
> > separate name mapping table for multiarch.

> Note that uclibc also suffers this problems. x86_64-linux-uclibc is in
> no way unique as different uclibc compile options create different ABIs
> all with the same tripplet.

We have a draft proposal for tuples to use in the filesystem paths for
multiarch: http://wiki.debian.org/Multiarch/Tuples

uclibc is included in the design, with a single identifier of 'uclibc'.  We
probably need to have a better definition here.  Where is the right place to
raise this point for discussion in Debian?  Should I bring this up on the
debian-embedded list?  Are there other stakeholders who would have input
regarding the array of available uclibc ABIs and how to specify these?

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Thu, 17 Feb 2011 20:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Luke Kenneth Casson Leighton <lkcl@lkcl.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 17 Feb 2011 20:21:03 GMT) Full text and rfc822 format available.

Message #77 received at 594179@bugs.debian.org (full text, mbox):

From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Konstantinos Margaritis <markos@genesi-usa.com>
Cc: 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org, Matt Sealey <matt@genesi-usa.com>
Subject: Re: dpkg armhf patch acceptance status?
Date: Thu, 17 Feb 2011 20:19:42 +0000
On Tue, Sep 7, 2010 at 12:01 PM, Konstantinos Margaritis
<markos@genesi-usa.com> wrote:
> Hi all,
>
>  I really would like to know the stance of the dpkg maintainers regarding the
> armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file as
> bug reports, but without the dpkg patch, those patches would be useless, so
> I'm holding back, but that in the meantime increases the workload as newer
> packages appear all the time and I have to forward port the armhf patches all
> the time.

 konstantinous,

 this is PRECISELY why i advocate - and continue to advocate - a build
system based around bitbake (NOT REPEAT NOT THE ENTIRE OPENEMBEDDED
INFRASTRUCTURE AS ASSUMED BY SOME PEOPLE WHO THEN ASSUMED I WAS A
F*****G IDIOT FOR EVEN MENTIONING BITBAKE)

 the reason is plain and simple: patches-to-packaging such as the
patch to dpkg you refer to can be applied easily by bitbake
infrastructure prior to a build, in fact the entire debian packaging
of dpkg and other packages that you are maintaining differences on can
themselves be committed to a bitbake-compatible git repository, that
git repository uploaded, managed, distributed and generally worked on
by *other* people not just yourself;

 each set of patches-to-debian-packages, as they *are* accepted
upstream can then be *dropped* from the git repository;

 and so on and so forth.

 there are damn good reasons why i mentioned and advocated the use of
bitbake as both a package-development as well as a build AND a
cross-build tool, precisely to help _you_ to cater for the exact
circumstances in which debian developers now find themselves causing
quite some awkwardness as the build progresses.

 perhaps, even, horror-of-horrors or hope-beyond-hope depending on
which side of the fence you sit, such a system might even help to
manage the scenario where large-scale en-masse changes could be
planned, developed, made and reviewed to ubuntu packages, thus
allowing ubuntu to actually be what it should have bloody well been in
the first place: nothing more than an extra debian repository with
overrides for certain packages.

 what stops that from being desirable let alone feasible is the fact
that ubuntu is designed to be idiot-proof, thus only the idiots use
it, and that keeps them the bloody hell away from debian, which is
GREAT! :)

 l.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Thu, 17 Feb 2011 21:45:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Konstantinos Margaritis <markos@genesi-usa.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 17 Feb 2011 21:45:06 GMT) Full text and rfc822 format available.

Message #82 received at 594179@bugs.debian.org (full text, mbox):

From: Konstantinos Margaritis <markos@genesi-usa.com>
To: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Cc: 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org, Matt Sealey <matt@genesi-usa.com>
Subject: Re: dpkg armhf patch acceptance status?
Date: Thu, 17 Feb 2011 23:43:19 +0200
[Message part 1 (text/plain, inline)]
Luke,

1. My name is Konstantinos, or Kostas, or if you prefer, just call me
markos. It's not konstantinos, and it's not konstantinous.
2. My workload is big even without considering "crazy" solutions of
distro-wide bitbake-integrations. If you so strongly believe that this
method works so great, feel freel to demonstrate it by *proving* it works.
Otherwise, it's just noise that distracts me from my work. I seem to
remember someone famous saying sth like "show the code or sth..."... :P
So, please don't hijack the thread and the bug report, with something
totally irrelevant.

Konstantinos (http://en.wikipedia.org/wiki/Constantine_%28name%29)

On 17 February 2011 22:19, Luke Kenneth Casson Leighton <lkcl@lkcl.net>wrote:

> On Tue, Sep 7, 2010 at 12:01 PM, Konstantinos Margaritis
> <markos@genesi-usa.com> wrote:
> > Hi all,
> >
> >  I really would like to know the stance of the dpkg maintainers regarding
> the
> > armhf dpkg patch. I have a ton of armhf patches that I'm waiting to file
> as
> > bug reports, but without the dpkg patch, those patches would be useless,
> so
> > I'm holding back, but that in the meantime increases the workload as
> newer
> > packages appear all the time and I have to forward port the armhf patches
> all
> > the time.
>
>  konstantinous,
>
>  this is PRECISELY why i advocate - and continue to advocate - a build
> system based around bitbake (NOT REPEAT NOT THE ENTIRE OPENEMBEDDED
> INFRASTRUCTURE AS ASSUMED BY SOME PEOPLE WHO THEN ASSUMED I WAS A
> F*****G IDIOT FOR EVEN MENTIONING BITBAKE)
>
>  the reason is plain and simple: patches-to-packaging such as the
> patch to dpkg you refer to can be applied easily by bitbake
> infrastructure prior to a build, in fact the entire debian packaging
> of dpkg and other packages that you are maintaining differences on can
> themselves be committed to a bitbake-compatible git repository, that
> git repository uploaded, managed, distributed and generally worked on
> by *other* people not just yourself;
>
>  each set of patches-to-debian-packages, as they *are* accepted
> upstream can then be *dropped* from the git repository;
>
>  and so on and so forth.
>
>  there are damn good reasons why i mentioned and advocated the use of
> bitbake as both a package-development as well as a build AND a
> cross-build tool, precisely to help _you_ to cater for the exact
> circumstances in which debian developers now find themselves causing
> quite some awkwardness as the build progresses.
>
>  perhaps, even, horror-of-horrors or hope-beyond-hope depending on
> which side of the fence you sit, such a system might even help to
> manage the scenario where large-scale en-masse changes could be
> planned, developed, made and reviewed to ubuntu packages, thus
> allowing ubuntu to actually be what it should have bloody well been in
> the first place: nothing more than an extra debian repository with
> overrides for certain packages.
>
>  what stops that from being desirable let alone feasible is the fact
> that ubuntu is designed to be idiot-proof, thus only the idiots use
> it, and that keeps them the bloody hell away from debian, which is
> GREAT! :)
>
>  l.
>
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Fri, 18 Feb 2011 10:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 18 Feb 2011 10:15:03 GMT) Full text and rfc822 format available.

Message #87 received at 594179@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Loïc Minier <lool@dooz.org>, 594179@bugs.debian.org
Cc: debian-arm@lists.debian.org, debian-dpkg@lists.debian.org, Matthias Klose <doko@debian.org>
Subject: Re: Bug#594179: dpkg armhf patch acceptance status?
Date: Fri, 18 Feb 2011 11:13:11 +0100
[Message part 1 (text/plain, inline)]
[ CCing Matthias, as I'd like your opinion on my proposed solution
  involving some Debian gcc changes. ]

Hi!

On Thu, 2011-02-17 at 12:27:30 +0100, Loïc Minier wrote:
>  Trying to kick the dust a bit as having the triplet "in the air" is
>  kind of an unhappy situation for armhf   :-)

I think it's fair to assume several of you have already peeked into the
notes I circulated on IRC the other day, :) I'm reincluding them here
although slightly redacted and extended, for the benefit of the rest
of the people. I'll still reply to specific points you rised below.


GNU triplets
------------

* gcc upstream claims GNU triplets do not fully encode ABI:
  - Thus cannot be used properly to map deb arch ←→ GNU triplet.
  - Thus cannot be used for multiarch paths.
  - Thus cannot be used for default cross-toolchains sharing GNU triplet.
  - Thus we'd need yet another ABI encoding and mapping for multiarch
    and dpkg arches, instead of being able to just use GNU triplets.
    The one being currently proposed can be found at
    <http://wiki.debian.org/Multiarch/Tuples>.

* But the GNU triplets have always encoded the ABI, it's even
  extremely explicit in some cases, for example with the arm EABI,
  executable formats (elf, aout, ecoff, etc) or stuff like
  powerpc-*-eabispe* or powerpc-*-eabialtivec* (supported by gcc
  upstream).

* And we already use GNU triplets for powerpcspe (powerpc-linux-gnuspe)
  and lpia (i386-linux-gnulp) arches, and these do not need gcc upstream
  support as are handled transparently by the -gnu* patterns, and any
  differing ABI options are selected by the Debian gcc packaging.

* There's other gcc options which can change the ABI of the default
  compiler besides the --with-float one, like --with-long-double-128,
  etc, and still they are not a problem mainly for two reasons:

  1) In case they do not need to coexist, they can be handled like
     other transitions, like it was done in Debian, by renaming
     shared library packages or with versioned symbols and handling
     both ABIs at the same time.

  2) No one seems to have needed to create coexisting default toolchains
     with diverging ABI options at the same time until now, or they have
     done so privately.

* I think it's important to be able to consistently support co-installing
  different default cross-compilers for different ABIs which would
  otherwise share the same triplet. And while we could avoid the problem
  for multiarch libraries co-installations by using the multiarch tuples,
  we would not be able to avoid it for the cross-compilers.

* The assumption that each GNU triplet denotes a different ABI is so
  entrenched in the GNU build system, that we have things like the
  following all over the place to properly support cross-building:

  ,---
  ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
    confflags += --build $(DEB_HOST_GNU_TYPE)
  else
    confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
  endif
  `---

  This would not hold true any longer if we didn't use a unique triplet
  per arch, and would thus break in quite annoying ways. For further
  details why that's needed check the autotools-dev section
  “Calling GNU configure properly” in its README.Debian.

* Ignoring the bi-directional 1:1 mapping would be a PITA, as it implies
  not being able to automatically bootstrap dpkg on a new port or
  dpkg package builds on foreign distros. The former is annoying but not
  done frequently, the latter is going to be a problem for each non-dpkg
  based distribution, as they'll have to bootstrap dpkg on each arch
  where dpkg is built anew. It ends up being a matter of off-loading the
  knowledge of the arch and build system from the dpkg/gcc combo to the
  porters/maintainers, which seems rather unappealing.

* Other packaging systems seem to not have made quite the same assumption
  about the GNU triplet as dpkg/Debian does. Gentoo's portage at least
  relies on the GNU triplet being unique per different arch as itseems to
  be using it on the path somehow. rpm and conary for example use uname
  which is not enough by itself, and quite unsatisfactory as it's lacking
  quite a bit of the ABI information, which probably has not presented as
  a problem for them as they do not have the amount of supported arches
  as Debian does, neither do they seem to have the same amount of
  mixes/convinations we do. So the other approaches seem to be actually
  inferior.

* The remaining problem at least for multiarch is the use of more
  specialized cpu names for the i386 triplets, i486-linux-gnu on Debian,
  which might change depending on the base instruction set to support,
  for example i686-linux-gnu on Ubuntu.

  Due to #611741, it already crossed my mind (but removed it from the
  list of solutions before sending the reply as at the time it seemed
  slighly preposterous just to fix the divergence with Ubuntu) that we
  should switch back our i386 arch to use i386 as the base cpu name for
  the triplet (i386-linux-gnu) in the same way we use it in other
  arches, like on arm where we use arm-linux-gnu instead of something
  like armv4tel-linux-gnueabi, for example. (I mentioned this already to
  Steve and Raphaël on some private conversation.)


Solution(s)
-----------

So while some of the previous points _could_ be considered corner-cases,
there are several of them piling up, which work just fine with our (and
GNU build system) current assumptions, and breaking them seems
gratuituous and way worse than not doing it, as it adds future confusion,
breakage and complexity, instead of the extremely “simple” and more
correct solution (in contrast to the claimed dpkg lameness/limitation,
which I disagree with, and I think I've proven incorrect above) of just
using a new triplet.


- Use additional pre-processor macros for armhf, inccurs an additional
  pre-processor call for the arm arches. It implies the Debian arches
  cannot be fully retrieved w/o a cross-compiler for each of the arches
  lacking information, which means we lose the univeral bi-directional
  mapping.

  This one is a no go.

- Abuse the vendor field, a hack upstream does not like either, although
  strangely enough they seem to prefer it instead of a proper triplet.

  Although viable, I don't really see the point, we might as well just
  do the right thing and use a proper triplet then.

+ Just use a new triplet arm-*-*-gnueabihf or whatever in a similar vein
  as our own -gnulp and -gnuspe.

  Would not need to be explicitly supported by gcc upstream to perform
  the automatic selection of the ABI based on the triplet for different
  variants, which seems to be the biggest reason they have against it.
  This should be satisfactory for upstream as the magic will be kept
  in the Debian packaging, and they can be kept oblivious of it.

  Package build systems might be matching against stuff like
  arm*-*-linux-gnueabi, so it might require changes to match on -gnueabi*
  instead, but is more immediate, and not like propagating config.guess
  all over the place, which we should not need as debian/rules should
  be passing --build to configure anyway, and config.sub can already
  canonicalize something like arm-linux-gnueabihf by way of the current
  patterns.

  Switch also i486-linux-gnu (Debian) and i686-linux-gnu (Ubuntu) to
  simply i386-linux-gnu (but still preserving their respective cpu
  tunnings). This also fixes this inconsistency in the i386 arch.

  So Matthias would you be amenable to including something like the
  attached patch to Debian gcc (regardless of upstream accepting it,
  although the patch is pretty minimal and non-intrusive, which would
  seem to have good chances of being accepted there)?
  What about switching the triplet for i386, I could prepare patches
  for that if you want (I think it's a one-liner though)?

  Konstantinos, would you be willing test such patch with an accompanying
  triplet in dpkg (patch attached too)? If you don't like
  arm-linux-gnueabihf, then something like arm-linux-gnueabivfp or
  whatever you want, I don't think I particularly care much, it would
  need to be prefixed arm-linux-gnueabi though so that the matches work
  transparently.

  Beware, both patches completely untested!

> On Wed, Sep 08, 2010, Guillem Jover wrote:
> > We currently need something like this in dpkg-dev because the mappings
> > need to be bidirectional, as dpkg-dev needs to be able to convert
> > from GNU triplet to Debian architecture and the other way around.
> > 
> > Steve wondered why this is the case, and that's because for
> > cross-compiling purposes dpkg-architecture infers the host architecture
> > from the CC environment variable through the -dumpmachine option.
> > Chaning this is possible but, would break a current way of
> > cross-compiling which has been around for a long time.
> 
>  So this use case is "CC=arm-linux-gnueabi-gcc dpkg-buildpackage" and it
>  just guesses the -a flag that you should have set?

That and for automatic bootstrapping purposes too.

> > The toolchain has the same triplet for binary incompatible producing
> > objects, which seems like a bug/misfeature to me, and that's one of
> > the assumptions dpkg-dev has relied on, in the same way as multiarch
> > when deciding to use the triplet as a unique token for the installation
> > directories.
> 
>  You describe this as a bug/misfeature, that might be true but I don't
>  think we can challenge this usage of triplets in the upstream
>  toolchain, and multiarch is moving to having its own tuples instead now
>  (http://wiki.debian.org/Multiarch/Tuples).

Oh, but I think I just did. :) Also given the above I don't think it
makes sense to invent a new set of tuples, the triplets should work
just fine. In addition those tuples end up relying partly on the
definition of the ABI the default gcc has for a given target, which
should not change incompatibly for a given Debian architecture, or we
are screwed anyway. So I don't see that it buys us much.

> > This also causes issue with not being able to have installed two
> > cross-toolchains for say armel and armhf as they share triplet,
> > although you can use the armel toolchain with few options to build for
> > armhf, but then you'd need to specify those as part of the CC variable.
> 
>  Even if we could co-install them, I'm not sure how
>  /some-armel-path/arm-linux-gnueabi-gcc and
>  /some-armhf-path/arm-linux-gnueabi-gcc could helpfully be installed on
>  the same system   :-/

Well for cross-toolchains you have them in the PATH, and they just get
prefixed with the triplet so you'd end up with something like:

  /usr/bin/arm-linux-gnueabi-gcc-4.4
  /usr/lib/gcc/arm-linux-gnueabi/4.4.5

and

  /usr/bin/arm-linux-gnueabihf-gcc-4.4
  /usr/lib/gcc/arm-linux-gnueabihf/4.4.5

which work just fine, as they should.

>  It's a real limitation of the upstream toolchain.

Not really, it's only a limitation if the same triplet is used for
incompatible ABIs.

> > Also that also happens with biarch, you can produce i386 binaries from
> > an x86_64 toolchain, yet they both have their own triplet.
> 
>  Yes but x86 goes to the other extreme, with separate triplets for
>  compatible ABIs ({i386,i486,i586,i686}-linux-gnu); the fact is the
>  triplet is not a good ABI specifier.

Sure, but as mentioned above, I'm now convinced the correct solution is
to switch back to i386-linux-gnu.

> > Anyway, ideally I'd rather see this addressed by giving armhf a real
> > triplet, which would also make multiarch life way easier as there'd not
> > be any need to define an artificial set of neutral architecture names
> > to be able to place objects in the file system. But if this is not going
> > to happen, and thus the assumptions dpkg-dev is making have been just
> > wrong, then I'd rather drop the bidirectional mappings, and be done
> > with it. This will need careful consideration though, as it's breaking
> > a current interface, but something that could be done for dpkg 1.16.x.
> 
>  Having a separate triplet (not using the vendor field) like e.g. lpia
>  would mean a lot of pain IMO, and we'd have to fix many packages to
>  cope with it, including reaching out to upstream etc.  It was pain for
>  lpia for sure.

If we have to fix lots of packages that means they are already buggy,
at least for the packaging bits, the packaging should not generally
be matching against the GNU triplets. For their upstream build systems
that might possibly mean changing from *-gnueabi to *-gnueabi*, but I
doubt there are many upstream build systems matching against -gnueabi
at all? Most should be matching against *-gnu* if at all.

>  We could have an additional set of preprocessor macros which dpkg
>  checks for to decide which Debian architecture we're talking about; the
>  the would only be done if there is more than one architecture using the
>  same triplet in dpkg tables.  This alone is a bit fragile though, as it
>  means that if a new ABI is introduced to an existing triplet and is not
>  immediately added as a new dpkg architecture, then people might be
>  picking the wrong dpkg architecture when using a toolchain defaulting
>  to thenew ABI.

As stated above, it does not solve many of the stated problems, so a no
go, also as a counter example, arm EABI actually uses such a macro to
define its own triplet (see config.guess).

>  I wonder whether it would be a good idea to use multiarch tuples
>  internally; dpkg would still have to map to/from GNU triplets, but it
>  would force implementors to think about their ABI.  I am not sure how
>  we can ensure that we've mapped to the right tuple though.  Neither am
>  I sure that the multiarch tuples are frozen already, so it might be too
>  early for that either.

Given the above conclusion, that the GNU triplets must be already unique
per arch and cannot arbitrarily change ABI or it'd break stuff, I don't
really see the point in switching the internal representation, because I
don't really see the point in the multiarch tuples, when the GNU triplets
seems to do the job just fine (modulo the armhf and i386 issues, which we
should just fix).

thanks,
guillem
[gcc-eabi-supermatch.patch (text/x-diff, attachment)]
[dpkg-armhf.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Fri, 18 Feb 2011 12:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Matthias Klose <doko@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 18 Feb 2011 12:33:03 GMT) Full text and rfc822 format available.

Message #92 received at 594179@bugs.debian.org (full text, mbox):

From: Matthias Klose <doko@debian.org>
To: Loïc Minier <lool@dooz.org>, 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#594179: dpkg armhf patch acceptance status?
Date: Fri, 18 Feb 2011 13:30:19 +0100
On 18.02.2011 11:13, Guillem Jover wrote:
> [ CCing Matthias, as I'd like your opinion on my proposed solution
>    involving some Debian gcc changes. ]

The armhf patch for gcc looks ok, however I would like to see this better 
addressed in Linaro and/or upstream.

>>   Yes but x86 goes to the other extreme, with separate triplets for
>>   compatible ABIs ({i386,i486,i586,i686}-linux-gnu); the fact is the
>>   triplet is not a good ABI specifier.
>
> Sure, but as mentioned above, I'm now convinced the correct solution is
> to switch back to i386-linux-gnu.

No, this doesn't work. the triplet currently is set to i586-linux-gnu. Switching 
back to to i386 would loose the sync primitives and a not working gomp.  There 
is too much relying on >= i586 in many configure's of other packages.  Not only 
for the good, as the switch in Ubuntu to i686 did show, because many configure 
files assume sse with i686-linux-gnu.

  Matthias




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Fri, 18 Feb 2011 18:12:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 18 Feb 2011 18:12:02 GMT) Full text and rfc822 format available.

Message #97 received at 594179@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Matthias Klose <doko@debian.org>
Cc: Loïc Minier <lool@dooz.org>, 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#594179: dpkg armhf patch acceptance status?
Date: Fri, 18 Feb 2011 10:09:24 -0800
[Message part 1 (text/plain, inline)]
On Fri, Feb 18, 2011 at 01:30:19PM +0100, Matthias Klose wrote:
> On 18.02.2011 11:13, Guillem Jover wrote:
> >[ CCing Matthias, as I'd like your opinion on my proposed solution
> >   involving some Debian gcc changes. ]

> The armhf patch for gcc looks ok, however I would like to see this
> better addressed in Linaro and/or upstream.

I'm not sure how Linaro could better address this, short of persuading
upstream to allocate a separate triplet for armhf - which has been
explicitly refused on the upstream mailing list.  Do you have something else
in mind here?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Sat, 19 Feb 2011 01:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 19 Feb 2011 01:39:03 GMT) Full text and rfc822 format available.

Message #102 received at 594179@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Loïc Minier <lool@dooz.org>, 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org, Matthias Klose <doko@debian.org>
Subject: Re: Bug#594179: dpkg armhf patch acceptance status?
Date: Fri, 18 Feb 2011 17:36:45 -0800
[Message part 1 (text/plain, inline)]
Hi Guillem,

Thanks for letting us know your thoughts.

On Fri, Feb 18, 2011 at 11:13:11AM +0100, Guillem Jover wrote:
> * The assumption that each GNU triplet denotes a different ABI is so
>   entrenched in the GNU build system, that we have things like the
>   following all over the place to properly support cross-building:

>   ,---
>   ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
>     confflags += --build $(DEB_HOST_GNU_TYPE)
>   else
>     confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
>   endif
>   `---

But then we also have biarch and triarch toolchains in the archive, where
the host triplet doesn't change at all and instead gcc multilib is used to
designate what ABI you want.

The upstream argument seems to be that armel/armhf isn't "cross-compiling",
it's merely ABI selection within an architecture.  This sort of "cross"
compiling doesn't yield binaries that can't be run on the build machine, and
therefore most of the cross-compilation logic in autotools doesn't apply.

(Never mind that upstream does not apply this reasoning consistently; the
fact that there's precedent means it's going to be harder to argue the point
with them.)

> * The remaining problem at least for multiarch is the use of more
>   specialized cpu names for the i386 triplets, i486-linux-gnu on Debian,
>   which might change depending on the base instruction set to support,
>   for example i686-linux-gnu on Ubuntu.

>   Due to #611741, it already crossed my mind (but removed it from the
>   list of solutions before sending the reply as at the time it seemed
>   slighly preposterous just to fix the divergence with Ubuntu) that we
>   should switch back our i386 arch to use i386 as the base cpu name for
>   the triplet (i386-linux-gnu) in the same way we use it in other
>   arches, like on arm where we use arm-linux-gnu instead of something
>   like armv4tel-linux-gnueabi, for example. (I mentioned this already to
>   Steve and Raphaël on some private conversation.)

The challenge, as Matthias points out, is that these triplets are already so
entrenched and there is so much software that handles x86 specially - even
if incorrectly!  - that it's prohibitive to switch back to i386-linux-gnu as
our triplet because of all the re-porting work we'll have to do to get
properly functioning packages on x86.

>   Package build systems might be matching against stuff like
>   arm*-*-linux-gnueabi, so it might require changes to match on -gnueabi*
>   instead, but is more immediate, and not like propagating config.guess
>   all over the place, which we should not need as debian/rules should
>   be passing --build to configure anyway, and config.sub can already
>   canonicalize something like arm-linux-gnueabihf by way of the current
>   patterns.

Yes, package build systems do match on stuff like arm*-*-linux-gnueabi; my
understanding is that this was the pattern match that was propagated when
EABI was introduced on ARM, and as a result there's a fair amount of
software that will misbuild for eabi+hf if we go with -gnueabihf.  So
basically, it's the same problem we have as for switching to i386-linux-gnu
on i386, just on a different set of software in the archive.

How do we locate the software that will be affected by such a change?  I
think this has proven non-trivial in the past.

But ultimately that's for the porters and the GCC maintainers to decide
whether they're happy with that answer; it's an aside to the main point of
my mail, coming up below.  :)

> > > The toolchain has the same triplet for binary incompatible producing
> > > objects, which seems like a bug/misfeature to me, and that's one of
> > > the assumptions dpkg-dev has relied on, in the same way as multiarch
> > > when deciding to use the triplet as a unique token for the installation
> > > directories.

> >  You describe this as a bug/misfeature, that might be true but I don't
> >  think we can challenge this usage of triplets in the upstream
> >  toolchain, and multiarch is moving to having its own tuples instead now
> >  (http://wiki.debian.org/Multiarch/Tuples).

> Oh, but I think I just did. :) Also given the above I don't think it
> makes sense to invent a new set of tuples, the triplets should work
> just fine. In addition those tuples end up relying partly on the
> definition of the ABI the default gcc has for a given target, which
> should not change incompatibly for a given Debian architecture, or we
> are screwed anyway. So I don't see that it buys us much.

The underlying intent of the tuples proposal is that we stop pretending that
GNU triplets provide a valid global one-to-one mapping to ABIs, because we
know from several concrete, high profile examples that this is not true.

You have proposed a patch that Matthias has said "looks ok", but if he adds
it to the Debian/Ubuntu gcc, that only solves the problem for Debian and
Ubuntu.  Multiarch is intended as a cross-vendor standard, fixing the FHS's
inadequate lib<qual> directories and providing binary interoperability for
anyone choosing to implement it.  How can we achieve that if we're using
strings in our paths that are dependent on distro-specific patches?  Do we
expect to tell other implementors they have to use our GCC?

The multiarch tuple proposal would externalize this problem by establishing
a central, standard, one-to-one mapping between ABIs and strings *for this
precise purpose*.  I'm perfectly happy for Matthias to accept your gcc patch
in parallel so we establish a distinct GNU-ish triplet for armhf, but unless
this can get upstreamed, I don't think it solves the problem we have with
using GNU triplets for multiarch paths.

Do you agree, or do you still think multiarch should continue to be
dependent on GNU triplets, which - as we've seen - are not managed in a
consistent manner?

> Given the above conclusion, that the GNU triplets must be already unique
> per arch and cannot arbitrarily change ABI or it'd break stuff, I don't
> really see the point in switching the internal representation, because I
> don't really see the point in the multiarch tuples, when the GNU triplets
> seems to do the job just fine (modulo the armhf and i386 issues, which we
> should just fix).

Given that there is no consensus that this is even a bug to be fixed, I am
not content to have multiarch blocked indefinitely on getting triplet fixes
propagated upstream; nor am I happy to have multiarch paths tied to
distro-specific implementation details.  Are you going to do the heavy
lifting to get these changes accepted by GCC upstream?  How long do you
think that will take, and at what point would you decide that you're not
getting anywhere and fall back to diverging from upstream for multiarch?

I've rather firmly committed to getting initial multiarch support landed in
the 11.04 Ubuntu release.  If we can (collectively) get our decision made on
the path selection *now*, that's achievable - and we can be rid of ia32-libs
from Debian (unstable) and Ubuntu within a year, and we can bring armhf up
as the first multiarch-from-the-start port in Debian.  If we instead let
ourselves get drawn into open-ended discussions trying to persuade GCC
upstream that we're right about triplets and they're wrong, it may be years
longer before we see any multiarch implementation at all.  Remember that we
were discussing multiarch before sarge was released - I don't want to still
be discussing it after wheezy is out. :(

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Mon, 21 Feb 2011 01:57:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 21 Feb 2011 01:57:05 GMT) Full text and rfc822 format available.

Message #107 received at 594179@bugs.debian.org (full text, mbox):

From: Wookey <wookey@wookware.org>
To: debian-arm@lists.debian.org
Cc: Loïc Minier <lool@dooz.org>, 594179@bugs.debian.org, debian-dpkg@lists.debian.org, Matthias Klose <doko@debian.org>
Subject: Re: Bug#594179: dpkg armhf patch acceptance status?
Date: Mon, 21 Feb 2011 01:52:44 +0000
+++ Guillem Jover [2011-02-18 11:13 +0100]:

Guillem makes some good points about how GNU triplets should (and once
did) represent ABIs, and that if they still did, dpkg (and everything
else) could use them as the definitive ABI-indicator. He's quite
right. 

_Something_ has to stand as nomenclature for the ABI. It could equally
well be GNU triplets or Multiarch Tuples. I'm quite happy for either
to be used. Multiarch directories could use triplets under those
circumstances and there would be no need for the new tuples. 

But it is also the case that a given toolchain can produce binaries of
different ABIs, so there is logic in the GCC argument that the triplet
denotes a toolchain, not (necessarily) an ABI. (e.g arm-linux-gnueabi
toolchain can produce armel and armhf binaries (and in fact there are
more incompatible ABIs it could spit out, but we're not trying to make
distros out of those).

It makes sense to me that, these days, a triplet represents a
toolchain, and an MAtuple an ABI. If there was a 1-1 mapping between
these things then triplets would suffice, but there isn't.

So it seems to me, that we either have to persuade GCC to go back to
one triplet per ABI or we need to adopt the proposed Tuples.

It is logically neater in many ways to go back to one-triplet-per-ABI,
but like Steve, I'm not optimistic about this being ultimately acceptable
to upstream or that it could be done in a sensible period of time.
Starting again with a properly defined list and some rules about new
identifiers lets us get it right this time, and arrange for it to stay
right in the future. 

So what happens if we do this? Let's look at some examples mentioned
so far:

> * I think it's important to be able to consistently support co-installing
>   different default cross-compilers for different ABIs which would
>   otherwise share the same triplet. And while we could avoid the problem
>   for multiarch libraries co-installations by using the multiarch tuples,
>   we would not be able to avoid it for the cross-compilers.

This is true, but in fact the arm-linux-gnueabi and arm-linux-gnuhf
toolchains would be the same apart from their libgcc and default options
(spec file). A multilib build of this toolchain, supporting both
options, would work for targetting both ports, but we do still lack a
good way of switching spec files to change the default target (which
would be useful for all sorts of reasons).  

> * The assumption that each GNU triplet denotes a different ABI is so
>   entrenched in the GNU build system, that we have things like the
>   following all over the place to properly support cross-building:
> 
>   ,---
>   ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
>     confflags += --build $(DEB_HOST_GNU_TYPE)
>   else
>     confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
>   endif
>   `---
> 
>   This would not hold true any longer if we didn't use a unique triplet
>   per arch, and would thus break in quite annoying ways. 

Yes, this is potentially a pain in the bum. We need to select a
toolchain (which could be 'arm-linux-gnueabi' for both arm port
targets, but with different default options and a different default
linker and include paths). I haven't yet worked out how those will be
selected, as currently they are built-in to the cross-compiler and
referring to it by name sets them implicictly.

debian/rules has access to the -a<DEB_HOST_ARCH> which allows the
necessary discrimiation, and automatically supplies the
/etc/dpkg-cross/cross-config.<DEB_HOST_ARCH> autoconf values, which
may be sufficient, along with config.guess.

There are a lot of instances of -L /usr/<DEB_HOST_GNU_TYPE>/lib which
need fixing for multiarch anyway, so even if we have unique GNU
triplets, work will be needed in lots of packages to make
cross-building work again. Anything which already relies on default
compiler paths should work fine.

If using non-unique toolchain triplets, we need a robust mechanism for
host ABI selection within the multilibs available.


> * Ignoring the bi-directional 1:1 mapping would be a PITA, as it implies
>   not being able to automatically bootstrap dpkg on a new port or
>   dpkg package builds on foreign distros. The former is annoying but not
>   done frequently, the latter is going to be a problem for each non-dpkg
>   based distribution, as they'll have to bootstrap dpkg on each arch
>   where dpkg is built anew. It ends up being a matter of off-loading the
>   knowledge of the arch and build system from the dpkg/gcc combo to the
>   porters/maintainers, which seems rather unappealing.

I don't think I understand this point. Who are these people that
build dpkg on non-dpkg distro, and why will they have harder
bootstraping?

> > > The toolchain has the same triplet for binary incompatible producing
> > > objects, which seems like a bug/misfeature to me, and that's one of
> > > the assumptions dpkg-dev has relied on, in the same way as multiarch
> > > when deciding to use the triplet as a unique token for the installation
> > > directories.
> > 
> >  You describe this as a bug/misfeature, that might be true but I don't
> >  think we can challenge this usage of triplets in the upstream
> >  toolchain, and multiarch is moving to having its own tuples instead now
> >  (http://wiki.debian.org/Multiarch/Tuples).
> 
> Oh, but I think I just did. :) Also given the above I don't think it
> makes sense to invent a new set of tuples, the triplets should work
> just fine. In addition those tuples end up relying partly on the
> definition of the ABI the default gcc has for a given target,

Well, we need to be able to specify the ABI (and thus paths/gcc options) to 
use. That has traditionally been done with the triplet causing gcc
defaults to be used, but it can just as well be done in an
upstreamable and cross-distro way using LSB-certified MAtuples. Either
could work - which is easier, or otherwise provides overall benefit?

> > > This also causes issue with not being able to have installed two
> > > cross-toolchains for say armel and armhf as they share triplet,
> > > although you can use the armel toolchain with few options to build for
> > > armhf, but then you'd need to specify those as part of the CC variable.

On in the spec file. 

> >  I wonder whether it would be a good idea to use multiarch tuples
> >  internally; dpkg would still have to map to/from GNU triplets, but it
> >  would force implementors to think about their ABI.  I am not sure how
> >  we can ensure that we've mapped to the right tuple though.  Neither am
> >  I sure that the multiarch tuples are frozen already, so it might be too
> >  early for that either.
> 
> Given the above conclusion, that the GNU triplets must be already unique
> per arch and cannot arbitrarily change ABI or it'd break stuff, I don't
> really see the point in switching the internal representation, because I
> don't really see the point in the multiarch tuples, when the GNU triplets
> seems to do the job just fine (modulo the armhf and i386 issues, which we
> should just fix).

This pretty-much boils down the issue. dpkg needs to use a unique and
reliable internal representation. Can that carry on being/go back to
being triplets, or do we have to use the MAtuples?  

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Mon, 21 Feb 2011 02:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 21 Feb 2011 02:27:03 GMT) Full text and rfc822 format available.

Message #112 received at 594179@bugs.debian.org (full text, mbox):

From: Wookey <wookey@wookware.org>
To: Loïc Minier <lool@dooz.org>, 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org, Matthias Klose <doko@debian.org>
Subject: Re: Bug#594179: dpkg armhf patch acceptance status?
Date: Mon, 21 Feb 2011 02:22:44 +0000
+++ Steve Langasek [2011-02-18 17:36 -0800]:
> > * The remaining problem at least for multiarch is the use of more
> >   specialized cpu names for the i386 triplets, i486-linux-gnu on Debian,
> >   which might change depending on the base instruction set to support,
> >   for example i686-linux-gnu on Ubuntu.
> 
> >   Due to #611741, it already crossed my mind (but removed it from the
> >   list of solutions before sending the reply as at the time it seemed
> >   slighly preposterous just to fix the divergence with Ubuntu) that we
> >   should switch back our i386 arch to use i386 as the base cpu name for
> >   the triplet (i386-linux-gnu) in the same way we use it in other
> >   arches, like on arm where we use arm-linux-gnu instead of something
> >   like armv4tel-linux-gnueabi, for example. (I mentioned this already to
> >   Steve and Raphaël on some private conversation.)
> 
> The challenge, as Matthias points out, is that these triplets are already so
> entrenched and there is so much software that handles x86 specially - even
> if incorrectly!  - that it's prohibitive to switch back to i386-linux-gnu as
> our triplet because of all the re-porting work we'll have to do to get
> properly functioning packages on x86.

I know little of x86 world, but are we sure this is more work than the
fixing-up we'll need to do in many packages to properly deal with
multiple available ABIs within a toolchain, and making the new
MAtuples be used correctly everywhere? (especially when
cross-building, for both matters). 

> The underlying intent of the tuples proposal is that we stop pretending that
> GNU triplets provide a valid global one-to-one mapping to ABIs, because we
> know from several concrete, high profile examples that this is not true.
> 
> You have proposed a patch that Matthias has said "looks ok", but if he adds
> it to the Debian/Ubuntu gcc, that only solves the problem for Debian and
> Ubuntu.  Multiarch is intended as a cross-vendor standard, fixing the FHS's
> inadequate lib<qual> directories and providing binary interoperability for
> anyone choosing to implement it.  How can we achieve that if we're using
> strings in our paths that are dependent on distro-specific patches?  Do we
> expect to tell other implementors they have to use our GCC?
> 
> The multiarch tuple proposal would externalize this problem by establishing
> a central, standard, one-to-one mapping between ABIs and strings *for this
> precise purpose*.

I agree that this establishment of a generic FHS multiarch library
path standard is the right thing (TM), and that it's no good if it
can't be done upstream . But equally Guillem is right that
ABI-sepecific triplets could do that job too (and with less change to
existing practice overall). 

> Given that there is no consensus that this is even a bug to be fixed, I am
> not content to have multiarch blocked indefinitely on getting triplet fixes
> propagated upstream; nor am I happy to have multiarch paths tied to
> distro-specific implementation details.  Are you going to do the heavy
> lifting to get these changes accepted by GCC upstream?  How long do you
> think that will take, and at what point would you decide that you're not
> getting anywhere and fall back to diverging from upstream for multiarch?

This is the nub of the practical problem.

> I've rather firmly committed to getting initial multiarch support landed in
> the 11.04 Ubuntu release.  If we can (collectively) get our decision made on
> the path selection *now*, that's achievable - and we can be rid of ia32-libs
> from Debian (unstable) and Ubuntu within a year, and we can bring armhf up
> as the first multiarch-from-the-start port in Debian.  If we instead let
> ourselves get drawn into open-ended discussions trying to persuade GCC
> upstream that we're right about triplets and they're wrong, it may be years
> longer before we see any multiarch implementation at all.  Remember that we
> were discussing multiarch before sarge was released - I don't want to still
> be discussing it after wheezy is out. :(

I guess I missed the first 3-odd years of this debate. I'm assuming we've
already tried reasonably hard persuading the GCC people on this point? 

Unless the feature of being able to separately specify toolchains
(triplets) and ABIs (tuples) is important (and it may be for
biarch/triarch arches, but I'm not yet convinced), then given the
extreme similarity of tuples and triplets, it does seem like
ABI-specific triplets would be a 'better' solution to this problem
than inventing a new set; and in general Debian likes to go for the
technically-best solutions even if it takes longer. (Multiarch in
general is an example of this).

However, equally, it's taken a really long time to get this far, and
if we made a reasonable effort to get GCC people to agree with
guilem's view of the world, but failed, then I'm happy that the
expediency of the new tuples is justified. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Mon, 21 Feb 2011 06:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 21 Feb 2011 06:36:03 GMT) Full text and rfc822 format available.

Message #117 received at 594179@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Matthias Klose <doko@debian.org>
Cc: Loïc Minier <lool@dooz.org>, 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#594179: dpkg armhf patch acceptance status?
Date: Mon, 21 Feb 2011 07:32:19 +0100
[ Sorry for entangling the armhf bug with the i386 stuff, subsequent
  replies should probably remove debian-arm and the bug report from
  them. ]

On Fri, 2011-02-18 at 13:30:19 +0100, Matthias Klose wrote:
> On 18.02.2011 11:13, Guillem Jover wrote:
> >[ CCing Matthias, as I'd like your opinion on my proposed solution
> >   involving some Debian gcc changes. ]
> 
> The armhf patch for gcc looks ok, however I would like to see this
> better addressed in Linaro and/or upstream.

Ok, I'll run it through upstream to see what they say. I just wanted
to check if you'd be fine including it regardless of upstream's stance
on it, to at least be able to decide on the armhf triplet issue, the
multiarch paths decision would be unrelated to this then.

> >>  Yes but x86 goes to the other extreme, with separate triplets for
> >>  compatible ABIs ({i386,i486,i586,i686}-linux-gnu); the fact is the
> >>  triplet is not a good ABI specifier.
> >
> >Sure, but as mentioned above, I'm now convinced the correct solution is
> >to switch back to i386-linux-gnu.
> 
> No, this doesn't work. the triplet currently is set to
> i586-linux-gnu. Switching back to to i386 would loose the sync
> primitives and a not working gomp.  There is too much relying on >=
> i586 in many configure's of other packages.

Oh, I think this actually strengthens my point!

The gcc-4.4:i386 package seems to be compiled on Debian to target i586
as the base instruction set, as can be seen in its debian/rules2:388,
which implies changing the triplet would not affect this (barring the
small change I'm attaching a patch for, untested), and thus the sync
primitive and gomp would be fine (at least from my understanding of
the gcc build system). And just to make this perfectly clear, I'm
not proposing to downgrade the actual instruction set base line.

So while the base instruction set was changed to i586 in gcc 4.4.0-1~exp1
it did not switch the GNU triplet to i586-linux-gnu to match:

$ dpkg --print-architecture
i386
$ gcc-4.4 -dumpmachine
i486-linux-gnu
$ gcc-4.5 -dumpmachine
i486-linux-gnu
$ gcc-4.6 -dumpmachine
i486-linux-gnu
$ grep ^i386 /usr/share/dpkg/cputable|tr -s '\t '|cut -f2
i486

So I don't see how any debian/rules could be currently relying on
the i586-linux-gnu triplet (as long as they set them correctly through
the dpkg-architecture variables, coming from gcc, and not from
config.guess).

Also having to transition all our packaging to the new triplet every
time i386 changes the base line does not seem right, and it's
something we don't do on any of the other architectures. I'd even say
it's just wrong, packages should either use the default compiler base
instruction set, set their required one independenly of it, do
multiple builds and use hwcaps for libraries or do run time detection.

Given the above we'd need to either switch to i586-linux-gnu or
i386-linux-gnu, it seems to me both will imply the same amount of
changes? And thus going for the latter seems the correct solution,
it matches with the other architectures, can be used as the multiarch
paths and can reduce some divergence with Ubuntu, all of them a clear
win! :)

> Not only for the good, as the switch in Ubuntu to i686 did show,
> because many configure files assume sse with i686-linux-gnu.

I'd say any such assumption in those packages is buggy, per above.

thanks,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Mon, 21 Feb 2011 07:39:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 21 Feb 2011 07:39:07 GMT) Full text and rfc822 format available.

Message #122 received at 594179@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Loïc Minier <lool@dooz.org>, 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org, Matthias Klose <doko@debian.org>
Subject: Re: Bug#594179: dpkg armhf patch acceptance status?
Date: Sun, 20 Feb 2011 23:31:50 -0800
[Message part 1 (text/plain, inline)]
On Mon, Feb 21, 2011 at 02:22:44AM +0000, Wookey wrote:
> > The challenge, as Matthias points out, is that these triplets are already so
> > entrenched and there is so much software that handles x86 specially - even
> > if incorrectly!  - that it's prohibitive to switch back to i386-linux-gnu as
> > our triplet because of all the re-porting work we'll have to do to get
> > properly functioning packages on x86.

> I know little of x86 world, but are we sure this is more work than the
> fixing-up we'll need to do in many packages to properly deal with
> multiple available ABIs within a toolchain, and making the new
> MAtuples be used correctly everywhere? (especially when
> cross-building, for both matters). 

"multiple available ABIs within a toolchain" is not a problem that has to be
solved on x86 today, so yes, it is more work.  On x86 we do have at least
one tuple identifier for each ABI - we just have the problem that we have
/too many/ of them available on x86.  But while multilib toolchains are
definitely of interest on x86 (-m32/-m64), each of these ABIs also have a
distinct tuple associated with them (x86_64-linux-gnu, i<n>86-linux-gnu).

> > You have proposed a patch that Matthias has said "looks ok", but if he adds
> > it to the Debian/Ubuntu gcc, that only solves the problem for Debian and
> > Ubuntu.  Multiarch is intended as a cross-vendor standard, fixing the FHS's
> > inadequate lib<qual> directories and providing binary interoperability for
> > anyone choosing to implement it.  How can we achieve that if we're using
> > strings in our paths that are dependent on distro-specific patches?  Do we
> > expect to tell other implementors they have to use our GCC?

> > The multiarch tuple proposal would externalize this problem by establishing
> > a central, standard, one-to-one mapping between ABIs and strings *for this
> > precise purpose*.

> I agree that this establishment of a generic FHS multiarch library
> path standard is the right thing (TM), and that it's no good if it
> can't be done upstream . But equally Guillem is right that
> ABI-sepecific triplets could do that job too (and with less change to
> existing practice overall). 

Multiarch is a significant departure from existing practice one way or the
other.  I think the question of whether we maintain our ABI string list as a
delta against GNU triplets or as an entirely separate standard is really
quite a minor detail in comparison.

> I guess I missed the first 3-odd years of this debate. I'm assuming we've
> already tried reasonably hard persuading the GCC people on this point? 

In the x86 case, it's not something that GCC people can fix.  The
overloading of GNU triplets on x86_32 is now a well-entrenched practice
throughout the community, and neither they nor we can fix by fiat the
consequences of changing our triplet - only by a lot of hard work.

In the armhf case there was an upstream mailing list discussion, from which
the only emerging consensus (to the extent we can say there was one) was
that the official GNU triplet should stay the same.  This mailing list
discussion informed the BoFs we had at DebConf about multiarch tuples, and I
think it qualifies as "tried reasonably hard".  It's hard enough for my
purposes, because I'm not out to try to dictate policy to the GCC
maintainers, so when they say that's not what triplets mean, I greatly
prefer finding a path of lesser resistance.

I thought we had that with the multiarch tuples proposal, but maybe not. :/

> Unless the feature of being able to separately specify toolchains
> (triplets) and ABIs (tuples) is important (and it may be for
> biarch/triarch arches, but I'm not yet convinced), then given the
> extreme similarity of tuples and triplets, it does seem like
> ABI-specific triplets would be a 'better' solution to this problem
> than inventing a new set; and in general Debian likes to go for the
> technically-best solutions even if it takes longer. (Multiarch in
> general is an example of this).

I don't see either of these to be technically better or worse.  The fact is
that we are going to *have* to document multiple points where our directory
strings do not follow naturally from the existing array of GNU triplets; and
that documentation needs to be maintained in a readily consumable fashion.
Given those constraints, I don't think that using a modified set of GNU
triplets is any better than creating new strings from scratch.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Mon, 14 Mar 2011 08:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Konstantinos Margaritis <markos@genesi-usa.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 14 Mar 2011 08:33:03 GMT) Full text and rfc822 format available.

Message #127 received at 594179@bugs.debian.org (full text, mbox):

From: Konstantinos Margaritis <markos@genesi-usa.com>
To: 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org
Subject: Re: Bug#594179: dpkg armhf patch acceptance status?
Date: Mon, 14 Mar 2011 10:31:20 +0200
After a short discussion with Steve and later with Guillem on IRC,
I think it's time to make a final decision about this issue.

To cut the long story short, I agree with Steve's proposal on this:

arm-linux-gnueabi_hf

If we all agree on this, let's please have a dpkg release with the final armhf
triplet included so that I can continue work on the other issues
(d-i support, multiarch migration) :)

Regards

Konstantinos




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Mon, 14 Mar 2011 09:00:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 14 Mar 2011 09:00:07 GMT) Full text and rfc822 format available.

Message #132 received at 594179@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Konstantinos Margaritis <markos@genesi-usa.com>
Cc: 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org
Subject: Re: dpkg armhf patch acceptance status?
Date: Mon, 14 Mar 2011 03:47:11 -0500
Konstantinos Margaritis wrote:

> To cut the long story short, I agree with Steve's proposal on this:
>
> arm-linux-gnueabi_hf

What is the purpose of the underscore?  In other words, what is the
advantage over arm-linux-gnueabihf?  I worry that some tools may not
like it --- for example, package names like

 mlton-target-arm-linux-gnueabi_hf

are not allowed.  Which looks very much surmountable, but just in
case, it seems prudent to ask.

Just to be clear, this is not an objection (both triplets look fine to
me).  I ask in the hope of getting the rationale well documented.

Thanks,
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#594179; Package dpkg. (Mon, 14 Mar 2011 10:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Konstantinos Margaritis <markos@genesi-usa.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 14 Mar 2011 10:51:03 GMT) Full text and rfc822 format available.

Message #137 received at 594179@bugs.debian.org (full text, mbox):

From: Konstantinos Margaritis <markos@genesi-usa.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 594179@bugs.debian.org, debian-arm@lists.debian.org, debian-dpkg@lists.debian.org
Subject: Re: dpkg armhf patch acceptance status?
Date: Mon, 14 Mar 2011 12:47:03 +0200
On 14 March 2011 10:47, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Konstantinos Margaritis wrote:
>
>> To cut the long story short, I agree with Steve's proposal on this:
>>
>> arm-linux-gnueabi_hf
>
> What is the purpose of the underscore?  In other words, what is the
> advantage over arm-linux-gnueabihf?  I worry that some tools may not
> like it --- for example, package names like
>
>  mlton-target-arm-linux-gnueabi_hf
>
> are not allowed.  Which looks very much surmountable, but just in
> case, it seems prudent to ask.
>
> Just to be clear, this is not an objection (both triplets look fine to
> me).  I ask in the hope of getting the rationale well documented.

Sigh,
fine, whatever. Nothing personal Jonathan, it just feels extremely frustrating
to always have a point  raised when we're about to finally make a decision -
and yes, it's a very valid point that you raised.

So, yes, ok, finally, let's agree -for the last time I hope- on the
underscore-less
triplet:

arm-linux-gnueabihf

So, can we please, please, close this bug and get on with other issues?

Regards

Konstantinos




Added tag(s) pending. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Tue, 15 Mar 2011 00:30:03 GMT) Full text and rfc822 format available.

Message sent on to Konstantinos Margaritis <markos@genesi-usa.com>:
Bug#594179. (Tue, 15 Mar 2011 00:30:06 GMT) Full text and rfc822 format available.

Message #142 received at 594179-submitter@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: 594179-submitter@bugs.debian.org
Subject: Bug#594179 marked as pending
Date: Tue, 15 Mar 2011 00:28:22 +0000
tag 594179 pending
thanks

Hello,

Bug #594179 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

    http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=88b0c30

---
commit 88b0c3043a651a422cd0c43c38ab6d553e2214ea
Author: Guillem Jover <guillem@debian.org>
Date:   Tue Mar 15 01:24:28 2011 +0100

    Add armhf support to ostable and triplettable
    
    Closes: #594179

diff --git a/debian/changelog b/debian/changelog
index ea5abb9..d4360eb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -45,6 +45,7 @@ dpkg (1.16.0) UNRELEASED; urgency=low
     Thanks to Michel Lespinasse <walken@zoy.org>. Closes: #397121
   * Fix typo in «dpkg-name --overwrite» argument parsing so that it actually
     works at all. Thanks to Ivan Gagis <igagis@gmail.com>. LP: #728708
+  * Add armhf support to ostable and triplettable. Closes: #594179
 
   [ Raphaël Hertzog ]
   * Fail properly when debian/source/format is empty. Closes: #600854




Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Sat, 02 Apr 2011 04:21:13 GMT) Full text and rfc822 format available.

Notification sent to Konstantinos Margaritis <markos@genesi-usa.com>:
Bug acknowledged by developer. (Sat, 02 Apr 2011 04:21:13 GMT) Full text and rfc822 format available.

Message #147 received at 594179-close@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: 594179-close@bugs.debian.org
Subject: Bug#594179: fixed in dpkg 1.16.0
Date: Sat, 02 Apr 2011 04:17:19 +0000
Source: dpkg
Source-Version: 1.16.0

We believe that the bug you reported is fixed in the latest version of
dpkg, which is due to be installed in the Debian FTP archive:

dpkg-dev_1.16.0_all.deb
  to main/d/dpkg/dpkg-dev_1.16.0_all.deb
dpkg_1.16.0.dsc
  to main/d/dpkg/dpkg_1.16.0.dsc
dpkg_1.16.0.tar.bz2
  to main/d/dpkg/dpkg_1.16.0.tar.bz2
dpkg_1.16.0_amd64.deb
  to main/d/dpkg/dpkg_1.16.0_amd64.deb
dselect_1.16.0_amd64.deb
  to main/d/dpkg/dselect_1.16.0_amd64.deb
libdpkg-dev_1.16.0_amd64.deb
  to main/d/dpkg/libdpkg-dev_1.16.0_amd64.deb
libdpkg-perl_1.16.0_all.deb
  to main/d/dpkg/libdpkg-perl_1.16.0_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 594179@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri, 01 Apr 2011 23:56:54 +0200
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source amd64 all
Version: 1.16.0
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description: 
 dpkg       - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect    - Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 31141 97076 397121 476335 483119 591858 594179 596841 598922 600854 604914 605719 606080 608829 611741 612203 612465 612472 613023 616096 616502 617923 619311 619541 620380
Changes: 
 dpkg (1.16.0) unstable; urgency=low
 .
   [ Guillem Jover ]
   * Use DPKG_MAINTSCRIPT_PACKAGE environment variable as package name on
     dpkg-divert when no --package or --local options have been specified.
   * Do not allow versions starting with non-digit when doing strict parsing,
     warn otherwise.
   * Update dpkg(1) to note that --status-fd output does not contain newlines
     in error messages anymore (this was fixed in 1.15.0).
   * Add a new --status-logger option to dpkg, similar to --status-fd but
     instead invoke the command ourselves and feed the status information
     to its standard input. Suggested by Raphaël Hertzog.
   * Add missing space in update-alternative --set-selections output.
   * Add missing options to update-alternative --help output.
   * Count “conffile name is duplicated” for dpkg-deb warning count summary.
   * Improve and clarify strings for translation. Closes: #604914
   * Prefix all fatal error messages with “error: ”.
   * Do not check presence of update-rc.d in the PATH in dpkg, as it's not
     a program needed for dpkg correct operation.
   * Fix dpkg -GEO options on multiple versions of the same packages.
     Closes: #31141
   * Propagate --admindir to programs run from maintainer scritpts.
     Closes: #97076
   * Do not fail when trying to remove the root directory. This will only
     happen either on distributions where dpkg is a foreign package manager,
     or on artificial dpkg databases.
   * Always warn when parsing any package control data which does not have
     an Architecture field except for status and status log files when
     packages are not-installed or half-installed.
   * By default reject installing packages w/o an Architecture field. They
     now need --force-architecture, dpkg will still warn about them though.
   * Fix build failure when passing --disable-nls to configure.
   * Do not segfault on “dpkg -i --no-act”.
   * Add missing semicolon to the vsnprintf() compat declaration.
     Thanks to Robert Millan. Closes: #612203
   * On install for Ubuntu adjust the i386 GNU cpu name in cputable.
     Thanks to Colin Watson <cjwatson@ubuntu.com>. Closes: #611741
   * Sync the info database directory on unpack instead of the temporary
     control information directory, and print the correct pathname on error
     instead of the last file acted on that directory.
   * Document in dpkg-query --help output and man page that --list and --show
     arguments are optional.
   * Do not read and write the available file unnecessarily.
     Thanks to Michel Lespinasse <walken@zoy.org>. Closes: #397121
   * Fix typo in «dpkg-name --overwrite» argument parsing so that it actually
     works at all. Thanks to Ivan Gagis <igagis@gmail.com>. LP: #728708
   * Add armhf support to ostable and triplettable. Closes: #594179
   * Set the modification time for unpacked symlinks on supported systems.
   * Fix undefined value useage in dpkg-genchanges when adding files w/o a
     matching architecture, because they are not present in debian/control,
     this is most commonly the case due to dpkg-distaddfile.
   * Terminate immediately on dpkg-divert rename errors instead of propagating
     up the error codes, this improves error reporting and avoids triggering
     leak detectors. Closes: #620380
   * When moving a diverted file across filesystems in dpkg-divert, remove
     the source file.
 .
   [ Raphaël Hertzog ]
   * Fail properly when debian/source/format is empty. Closes: #600854
   * Add new deb-src-control(5) manual page documenting the debian/control
     file contained in source packages.
     - it documents the X[SBC]- prefix. Closes: #476335
     - it documents the VCS-* fields too. Closes: #483119
     Thanks to Oxan van Leeuwen <oxan@oxanvanleeuwen.nl> who wrote it
     as part of the Google Code In program.
   * Enhance dpkg-shlibdeps to not fail immediatly when a library is not found.
     Instead continue and fail after all problems have been reported. Thanks
     to Chris Baines <cbaines8@gmail.com> for the patch. Closes: #596841
   * Fix dpkg-source to not list Debian packaging files as modified
     upstream files in Format "1.0" when unpacking to a non-standard
     directory.
   * Apply patch from Colin Watson to let dpkg-buildflags return -O3
     instead of -O2 when building ppc64 packages on Ubuntu. Closes: #612472
   * Add new function get_control_path() to Dpkg::Path, it wraps dpkg-query
     --control-path.
   * Update dpkg-shlibdeps to be multiarch-ready:
     - use get_control_path() to find symbols/shlibs files
     - parse correctly the output of dpkg --search
   * Small fix to support files >2GB in .deb on 64-bit systems. Closes: #616502
     Thanks to Martin Dorey <mdorey@bluearc.com> for the patch.
   * dpkg-source now keeps the file ordering in the autogenerated patch when
     regenerating it. Closes: #606080
     Thanks to Colin Watson for the patch.
   * dpkg-source now uses a timestamp retrieved from the filesystem when
     resetting the timestamp of patched files so that a time skew when using
     NFS doesn't introduce any inconsistency. Closes: #613023
     Thanks to Jonathan Nieder <jrnieder@gmail.com> for the patch and the
     diagnosis.
   * dpkg-source will now remove quilt's .pc directory when --unapply-patches
     is in use. Closes: #591858
   * dpkg-source is now a bit less strict when parsing patches:
     - it accepts seeing the same file twice; Closes: #608829
     - it doesn't match on the English text "No newline at end of file" as it
       might be translated in some cases. Closes: #612465
   * Improve parser in Dpkg::Control::Hash to not require an empty line
     before the PGP signature. Closes: #617923
     Thanks to Roger Leigh for the initial patch.
   * Fix a regression in dpkg-divert where using --rename led to a failure when
     the rename implies crossing file systems. Thanks to Durk Strooisma for
     spotting it.
   * Use the correct mtime when installing a file with statoverrides.
     Regression introduced in 1.16.0. LP: #739179
   * Remove duplicate word in german translation of dpkg(1). Closes: #616096
   * Strip repeated non-significant spaces before and after newlines
     in Uploaders. Closes: #598922
   * Ignore whitespaces after options in headers of changelog entries.
     Closes: #605719
   * Fix dpkg-source's regression with empty patches (introduced while fixing
     #613023). Closes: #619541
 .
   [ Jonathan Nieder ]
   * Remove support for use of synchronous sync(2), due to its pernicious
     side-effects and to ease maintenance.
   * Clarify that an up-to-date dpkg only needs to be unpacked for
     dpkg-maintscript-helper to work.
 .
   [ Steve Langasek ]
   * Add new variables to dpkg-architecture, DEB_HOST_MULTIARCH and
     DEB_BUILD_MULTIARCH, that return the "ideal" GNU triplet for each
     architecture which should be used as the path component for library
     installation.
 .
   [ Mark Hymers ]
   * Add support for Built-Using field. Closes: #619311
 .
   [ Updated programs translations ]
   * German (Sven Joachim).
   * Portuguese (Miguel Figueiredo).
   * Spanish (Javier Fernandez-Sanguino).
   * Swedish (Peter Krefting).
 .
   [ Updated man page translations ]
   * German (Helge Kreutzmann).
   * Swedish (Peter Krefting).
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
   * Swedish (Peter Krefting).
 .
   [ Updated dselect translations ]
   * Spanish (Javier Fernandez-Sanguino).
Checksums-Sha1: 
 ce2157f0050ae5307c0b3f867219e90eccea417f 1200 dpkg_1.16.0.dsc
 c5588cfa254ff0d698fc1eb7d9d11be9da235371 5321098 dpkg_1.16.0.tar.bz2
 68d767846ee0bd9a20d627ef3371c2c98c12e066 494608 libdpkg-dev_1.16.0_amd64.deb
 239a3d17163706530443fb847bb61703ac6e0c00 2230440 dpkg_1.16.0_amd64.deb
 59ad8d6ca4573c2bb85861472c9437ed23a0e77c 948708 dselect_1.16.0_amd64.deb
 64c9a96eb3caaf34d1d14f09c5c81c4826539da6 870310 dpkg-dev_1.16.0_all.deb
 24c2b86c3cb1867ae4ddf1e3c1a631ca73b8fe0d 746970 libdpkg-perl_1.16.0_all.deb
Checksums-Sha256: 
 dc45d4c80599fb4fb377caf497c003ef5fef8e1fcf0b0cba51bae457041c2554 1200 dpkg_1.16.0.dsc
 2536bd1493ba5de8d0914c30d6b83d4390013caa98580bd33a735cebe445004a 5321098 dpkg_1.16.0.tar.bz2
 1e1e7e02834b554932aa0b7ef48b3b2e982893011f7261629f19882a0271a1b3 494608 libdpkg-dev_1.16.0_amd64.deb
 0f7858e704d1e0dd8f7195921cb29d6e296ff71e4568cf6a99c9a89a62907670 2230440 dpkg_1.16.0_amd64.deb
 e068fa295a74e769407ab9230208a20c3385c9f978d130077a0a5b506e66e14b 948708 dselect_1.16.0_amd64.deb
 54603f6285f06b8f805394ed63c63aad3671e66c9385818361a89190ced55972 870310 dpkg-dev_1.16.0_all.deb
 10aa393491951ac72f6d8429974e7be5c62b52fbb10fe8437fceb274ce8a2b1c 746970 libdpkg-perl_1.16.0_all.deb
Files: 
 8aaddcf28fe29848e0839e4f49aa5b27 1200 admin required dpkg_1.16.0.dsc
 dc83fe7c1346a2a7bf78548306447c1d 5321098 admin required dpkg_1.16.0.tar.bz2
 700983a5d39442c66f07403f13afc3bb 494608 libdevel optional libdpkg-dev_1.16.0_amd64.deb
 7a243ebcc1618a0b7a1054c510459191 2230440 admin required dpkg_1.16.0_amd64.deb
 433d60711295f8c311c85a9d31020ac1 948708 admin optional dselect_1.16.0_amd64.deb
 6a049c453a6370cab4e0a8611ed0153e 870310 utils optional dpkg-dev_1.16.0_all.deb
 86124110a1596fddc34fff8fc29a15e8 746970 perl optional libdpkg-perl_1.16.0_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk2WnHUACgkQuW9ciZ2SjJvVoQCdEWDb2Bi1NhycZk3sZ1Ak7ARE
kR4AoPHbIFD2mzngex1DGcFIKQ1CRXaH
=QKGg
-----END PGP SIGNATURE-----





Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Sat, 02 Apr 2011 04:21:13 GMT) Full text and rfc822 format available.

Notification sent to Konstantinos Margaritis <markos@genesi-usa.com>:
Bug acknowledged by developer. (Sat, 02 Apr 2011 04:21:14 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 17 May 2011 07:55:18 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 19:14:41 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.