Debian Bug report logs - #455501
dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi

version graph

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

Reported by: Jussi Hakala <jussi.hakala@hut.fi>

Date: Mon, 10 Dec 2007 13:48:02 UTC

Severity: normal

Tags: pending

Found in version dpkg/1.13.25

Fixed in version dpkg/1.15.4

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 <team@dpkg.org>:
Bug#455501; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Jussi Hakala <jussi.hakala@hut.fi>:
New Bug report received and forwarded. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Jussi Hakala <jussi.hakala@hut.fi>
To: submit@bugs.debian.org
Subject: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
Date: Mon, 10 Dec 2007 15:46:01 +0200
[Message part 1 (text/plain, inline)]
Package: dpkg
Version: 1.13.25

Etch's dpkg does not recognize arm-none-linux-uclibcgnueabi as a valid 
architecture. Don't know if this architecture string is exactly a proper 
one to begin with, but at compile time it seemed like the most 
reasonable one from all the options...

Anyway, we need a separate architecture for armel+uclibc.

Meanwhile, made this horrid patch to get the architecture recognized as 
armel, as with the ordinary arm+glibc equivalent.

[dpkg-uclibc.patch (text/x-diff, inline)]
diff -Nur old/dpkg-1.13.25/scripts/controllib.pl new/dpkg-1.13.25/scripts/controllib.pl
--- old/dpkg-1.13.25/scripts/controllib.pl	2007-08-29 16:35:03.000000000 +0300
+++ new/dpkg-1.13.25/scripts/controllib.pl	2007-11-20 17:47:34.000000000 +0200
@@ -95,7 +95,7 @@
 	return $cpu;
     } elsif ($os =~ /^(none|gnu)-(.*)/) {
 	return "$2-$cpu";
-    } elsif ("$os-$cpu" eq "gnueabi-linux-arm") {
+    } elsif ($cpu eq "arm" && $os =~ /gnueabi/) {
 	return "armel";
     } else {
 	return "$os-$cpu";
diff -Nur old/dpkg-1.13.25/ostable new/dpkg-1.13.25/ostable
--- old/dpkg-1.13.25/ostable	2007-08-29 16:35:05.000000000 +0300
+++ new/dpkg-1.13.25/ostable	2007-11-20 17:57:11.000000000 +0200
@@ -13,7 +13,7 @@
 # system part of the output of the GNU config.guess script.
 #
 # <Debian name>	<GNU name>	<config.guess regex>
-gnueabi-linux	linux-gnueabi	linux[^-]*-gnueabi
+gnueabi-linux	linux-gnueabi	linux[^-]*-[^-]*gnueabi
 gnu-linux	linux-gnu	linux[^-]*(-gnu)?
 none-darwin	darwin		darwin[^-]*
 none-freebsd	freebsd		freebsd[^-]*

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#455501; Package dpkg. 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 <team@dpkg.org>. Full text and rfc822 format available.

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

From: Guillem Jover <guillem@debian.org>
To: Jussi Hakala <jussi.hakala@hut.fi>, 455501@bugs.debian.org
Subject: Re: Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
Date: Tue, 11 Dec 2007 17:26:43 +0200
Hi,

On Mon, 2007-12-10 at 15:46:01 +0200, Jussi Hakala wrote:
> Package: dpkg
> Version: 1.13.25

> Etch's dpkg does not recognize arm-none-linux-uclibcgnueabi as a valid 
> architecture.

Just to clarify, the version in etch is not going to be updated for
this anyway, that's Debian release policy.

> Don't know if this architecture string is exactly a proper 
> one to begin with, but at compile time it seemed like the most reasonable 
> one from all the options...

It seems like a valid GNU triplet. Although for dpkg purposes the
-none- is unneeded.

> Anyway, we need a separate architecture for armel+uclibc.

Given other conversations, I take this is for Maemo. And my same
concerns apply, why do you need a new architecture? And do you realize
this would imply having two different dpkg db (there's no multiarch
support yet anyway)?

> Meanwhile, made this horrid patch to get the architecture recognized as 
> armel, as with the ordinary arm+glibc equivalent.

This is the completely wrong approach, I'd recommend you don't do that
in Maemo either.

thanks,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <team@dpkg.org>:
Bug#455501; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Jussi Hakala <jussi.hakala@hut.fi>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <team@dpkg.org>. Full text and rfc822 format available.

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

From: Jussi Hakala <jussi.hakala@hut.fi>
To: 455501@bugs.debian.org
Subject: Re: Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
Date: Wed, 12 Dec 2007 13:13:26 +0200
Guillem Jover wrote:
> Just to clarify, the version in etch is not going to be updated for
> this anyway, that's Debian release policy.

Didn't expect it would.

I issued a bug because I thought it would be nice to have a record of 
etch dpkg-architecture breaking when the toolchain advertises itself as 
an uclibc toolchain.

> Given other conversations, I take this is for Maemo. And my same
> concerns apply, why do you need a new architecture? And do you realize
> this would imply having two different dpkg db (there's no multiarch
> support yet anyway)?

Yes, I know.

You're correct, the patch is for maemo. The bug however, is about 
debian. However it will be handled in maemo, is, in the end, not 
relevant here.

>> Meanwhile, made this horrid patch to get the architecture recognized as 
>> armel, as with the ordinary arm+glibc equivalent.
> 
> This is the completely wrong approach, I'd recommend you don't do that
> in Maemo either.

I realize that.

As I said earlier, the patch here is a quick (and ugly) fix to 
circumvent a problem with dpkg-architecture searching specifically for 
-gnueabi in architecture strings.

It's not intended as a solution. It was a way to create armel packages 
which are built against uclibc instead of breaking down completely.

Regards,

  Jussi





Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#455501; Package dpkg. 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>. Full text and rfc822 format available.

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

From: Guillem Jover <guillem@debian.org>
To: Jussi Hakala <jussi.hakala@hut.fi>, 455501@bugs.debian.org
Subject: Re: Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
Date: Fri, 2 May 2008 06:10:10 +0300
Hi,

On Wed, 2007-12-12 at 13:13:26 +0200, Jussi Hakala wrote:
> Guillem Jover wrote:
>> Just to clarify, the version in etch is not going to be updated for
>> this anyway, that's Debian release policy.
>
> Didn't expect it would.
>
> I issued a bug because I thought it would be nice to have a record of  
> etch dpkg-architecture breaking when the toolchain advertises itself as  
> an uclibc toolchain.

Sure, no problem with that, it's always good to have bugs on file, but
the only problem here is trying to overload the meaning of armel for a
different architecture.

>>> Meanwhile, made this horrid patch to get the architecture recognized 
>>> as armel, as with the ordinary arm+glibc equivalent.
>>
>> This is the completely wrong approach, I'd recommend you don't do that
>> in Maemo either.
>
> I realize that.
>
> As I said earlier, the patch here is a quick (and ugly) fix to  
> circumvent a problem with dpkg-architecture searching specifically for  
> -gnueabi in architecture strings.
>
> It's not intended as a solution. It was a way to create armel packages  
> which are built against uclibc instead of breaking down completely.

The proper fix (if desired) is to create a name for this supposed
uclibc based architecture. Then those warnings go away by themselves.
I'm tempted to close this bug report unless there's someone starting a
real Debian arm eabi uclibc port.

regards,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#455501; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Jussi Hakala <jussi.hakala@hut.fi>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

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

From: Jussi Hakala <jussi.hakala@hut.fi>
To: Guillem Jover <guillem@debian.org>, 455501@bugs.debian.org
Subject: Re: Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
Date: Wed, 04 Jun 2008 12:51:40 +0300
Guillem Jover wrote:
> Sure, no problem with that, it's always good to have bugs on file, but
> the only problem here is trying to overload the meaning of armel for a
> different architecture.

I understand. But surely we can choose a different name (uarmel?) and 
after we've agreed with the arch naming scheme, this can be implemented 
properly.

> The proper fix (if desired) is to create a name for this supposed
> uclibc based architecture. Then those warnings go away by themselves.

Agreed. The patch was only intended as a temporary solution. I'd rather 
see a working package with somewhat conflicting architecture, than no 
package at all and an error message when trying to build the package.

> I'm tempted to close this bug report unless there's someone starting a
> real Debian arm eabi uclibc port.

Sure.

However, the core problem is not entirely armel related. When we want to 
use something else than glibc (uClibc, Newlib, dietlibc, Klibc, ...) in 
any architecture, we want (generally) those packages to be of different 
arch than the ones built against "vanilla" glibc.

Therefore, it would be reasonable that a uniform naming scheme would 
exist in the architecture names.

When we have an idea what that scheme could be, we can reimplement the 
patch properly.

Regards,

  Jussi




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#455501; Package dpkg. 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>. Full text and rfc822 format available.

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

From: Guillem Jover <guillem@debian.org>
To: Jussi Hakala <jussi.hakala@hut.fi>, 455501@bugs.debian.org
Subject: Re: Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
Date: Tue, 1 Jul 2008 07:11:33 +0300
[Message part 1 (text/plain, inline)]
On Wed, 2008-06-04 at 12:51:40 +0300, Jussi Hakala wrote:
> Guillem Jover wrote:
>> Sure, no problem with that, it's always good to have bugs on file, but
>> the only problem here is trying to overload the meaning of armel for a
>> different architecture.
>
> I understand. But surely we can choose a different name (uarmel?) and  
> after we've agreed with the arch naming scheme, this can be implemented  
> properly.
>
>> The proper fix (if desired) is to create a name for this supposed
>> uclibc based architecture. Then those warnings go away by themselves.
>
> Agreed. The patch was only intended as a temporary solution. I'd rather  
> see a working package with somewhat conflicting architecture, than no  
> package at all and an error message when trying to build the package.

I think producing this kind of packages with overloaded architectures
is really bad, might give really confusing errors, and you'll have to
migrate at some point to use the new architecture name as they are
going to be incompatible anyway. It was a pain to move the arm with
eabi binaries to proper armel at Nokia...

>> I'm tempted to close this bug report unless there's someone starting a
>> real Debian arm eabi uclibc port.
>
> Sure.
>
> However, the core problem is not entirely armel related. When we want to  
> use something else than glibc (uClibc, Newlib, dietlibc, Klibc, ...) in  
> any architecture, we want (generally) those packages to be of different  
> arch than the ones built against "vanilla" glibc.

Right (except for s/generally/always/. :)

> Therefore, it would be reasonable that a uniform naming scheme would  
> exist in the architecture names.

There's already one, it is probably not well documented though. The
Debian architectures are now internally handled as triplets (which
are more or less the reversed GNU triplets), so for armel we have:

  Debian arch		Debian triplet		GNU triplet

  armel			gnueabi-linux-arm	arm-linux-gnueabi

The most common arches right now are GNU/Linux based so those do not
include the abi nor the os, they are implicit, and the cpu might get
mapped to make it distinguishible, in the previous case we have to
merge the eabi and arm info into a single arch name.

Ideally those would be called linux-<arch>, which is less confusing
(people would not assume any kernel running on <arch>, but for
historical reasons I don't see this changing).


For the new "common" ones we use <kernel>-<cpu>, like in:

  kfreebsd-i386		gnu-kfreebsd-i386	i386-kfreebsd-gnu

And in this case the abi is implicit, if we wanted a different libc,
then we'd have to include it explicitly.


And for really uncommon ones we'd use something like <abi>-<kernel>-<cpu>
for example:

  uclibc-linux-armel	uclibceabi-linux-arm	arm-linux-uclibceabi


I'm attaching a patch which should make uclibc based architectures
work.

regards,
guillem
[a.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#455501; Package dpkg. (Wed, 01 Jul 2009 12:06:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ron <ron@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 01 Jul 2009 12:06:04 GMT) Full text and rfc822 format available.

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

From: Ron <ron@debian.org>
To: debian-embedded@lists.debian.org
Cc: 455501@bugs.debian.org
Subject: Re: new architecture wishlist
Date: Wed, 1 Jul 2009 21:32:07 +0930
On Tue, Jun 30, 2009 at 03:29:08PM +0200, Simon Richter wrote:
> a few days ago I asked on #debian-dpkg whether it was possible to get a
> mechanism for adding new architectures to dpkg by dropping extra tables
> into a specific directory.

I've cc'd #455501 on this, as that is still an open thread on what to
do about the linux uclibc targets, and the last suggestion there was for:

 uclibceabi-linux	linux-uclibceabi	linux[^-]*-uclibceabi
 uclibc-linux		linux-uclibc		linux[^-]*-uclibc

 uclibceabi-linux-arm	uclibc-linux-armel
 uclibc-linux-<cpu>	uclibc-linux-<cpu>

I'd like to suggest that the form in triplettable should instead be:

 uclibceabi-linux-arm	uclibc-armel
 uclibc-linux-<cpu>	uclibc-<cpu>

As this is consistent with other arches there in that we assume 'linux'
by default, and only add the extra qualification for non-linux kernels.

I've been building uclibc toolchains and using them for active development
for more than two years now, originally with the old ABI and most recently
with gcc-4.4 and EABI, and this has been working well ...

But that said, I now _don't_ think we should add these to dpkg by default,
if anything we should _only_ more formally define the form that should be
used.  But more on that in a moment.

> Given that these tables are ordered by regex specificity and that there
> ought to be at least some arbitration in the architecture namespace, it
> appeared to be the best solution to simply add new architectures in the
> dpkg package, whether they are official Debian architectures or not.

Hmm, ok, that is indeed something of a problem for just dropping extra
definitions in a foo.d for dpkg to read (which I'd also lobbied for
previously).  But we _do_ already have DPKG_DATADIR now, and I have
used that successfully with the most recent toolchain I built.

There are a few issues with it, but none that seem insurmountable.
What other problems are other people having with that which make it
an unacceptable solution at present?  The basic concept seems sound,
the only troubles I've seen are the usual issues that environment vars
all have.

What if we allow just a single set of foo-table.local files on each
machine?  That if present will override the packaged tables from dpkg,
but will not be overwritten each time dpkg is updated.  If people want
multiple additional arches it will be up to the local admin to merge
them into the *.local files provided for that use (along with any from
the official set they require) ...


> So I'd like to collect a wishlist here and ask for comments:
> 
> Debian      GNU arch                    GNU regex
> -----------------------------------------------------------------------
> armebuc     armeb-uclinux-uclibceabi    arm.*b-uclinux[^-]*-[^-]*eabi
> armeluc     arm-uclinux-uclibceabi      arm-uclinux[^-]*-[^-]*eabi

I'm against defining these two for the same reason I'm against defining
the linux-uclibc ones above.  The _only_ reason for using these builds
is you are really tight on space, which pretty much guarantees that
_every_ actually useful build will be incompatible with every other (as
there are gazillions of configuration options to include or exclude
various things).

Making some 'official' definition of what these consist of just doesn't
seem practical -- either they will include _everything_, which aside from
being impossible for things like MMU support, will simply make them too
bloated and so useless for _everyone_ -- or they will be defined to suit
the first player and everyone else will be left out in the cold.

Either we should leave these as 'user defined' arches, that people can
define locally as they please -- or probably better, use these as a
standard form, that people can then customise to make their own custom
uclibc_foo-armel arch.  That _should_ work, but I haven't actually made
a toolchain like that to prove it.  A few autoconf globs may need to be
tweaked in some things, but by eye most seem to have wildcards in the
right places for this to work.  Mostly I'm just not certain they all
agree on _where_ in the name we have freedom to add things like that,
but that doesn't seem unfixable (or undesirable to fix) either.

> win32       i586-mingw32msvc            i(3,4,5,6)86-mingw32msvc
> win64       (to be decided by mingw maintainers)
> cygwin32    i686-cygwin                 i(3,4,5,6)86-cygwin

I'm against adding these because after some 8+ years of maintaining
the mingw toolchain (since gcc 2.95), they are still utter vapourware,
don't really fit with being a distro arch in any sensible way (there
is nowhere you can install the 'native' packages), and aren't required
at all for creating a mingw-cross development environment hosted on
Debian systems.  People have been cross building for this target for
many years now, and every effort that has started with defining what
to call the arch has amounted to absolutely nothing at all.  In the
meantime, plenty of people and projects seem to be getting their work
done with this toolchain just fine.  We even dropped some of the above
'arches' from dpkg-cross a couple of years ago when that was merged
with dpkg, and I have no link to offer re any real complaints about
that which I'm aware of to date.

I think the double handling of building 'native' packages that will
never be used and then dpkg-cross'ing them is an 'obvious' reuse of
existing cross build methods, but one that fits badly to an arch that
doesn't follow the norms of a Debian system at all.  If people really
want to do this, then IMO they should prove this first with local use
of DPKG_DATADIR for now.  It would be a mistake to complicate the
dpkg-cross mechanisms to cope with this, and vice-versa.  And however
seductive this may look as an 'easy' first step, you aren't going to
have to go too much further than that to hit nasty trouble.

If we're going somehow support 'debs' of non-debian arches, we really
need to answer the "how are they different" and "where are we going
to put them" questions much more thoroughly before we concrete parts
of that into dpkg.


Anyhow, I'd been meaning to follow up to #455501 for a while now with
a report on how all that was all looking, so this was a pretty good
cue to get a coredump from me on that.  I think the next step I'd like
to see here now is some broader discussion on the known failings of
DPKG_DATADIR, and a few more people thinking about the best ways to
address that.

Being able to locally define an arch is _very_ useful for embedded
developers -- but enumerating every arch they define before we even get
a chance to see if they make it out of the R&D lab seems intractable
and wasteful of a still rather limited namespace.  dpkg should probably
stick to just defining arches that debian distributes, but provide us
enough knobs to tweak for new arches to be easily bootstrapped, some of
which may later become part of the project archives too.

There may be other arches that we do want to add to dpkg already, but
my feeling on this particular lot is that pretty much all of them will
come back to bite us later if we hardcode this in the distro dpkg now.

Thanks for giving us some time to have another look at what to do about
all this though ...  It would be really nice to bed down a few more of
the things that we are actually pretty sure about now ...

Cheers,
Ron






Information forwarded to debian-bugs-dist@lists.debian.org, sjr@debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#455501; Package dpkg. (Tue, 28 Jul 2009 16:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Richter <sjr@debian.org>:
Extra info received and forwarded to list. Copy sent to sjr@debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 28 Jul 2009 16:57:03 GMT) Full text and rfc822 format available.

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

From: Simon Richter <sjr@debian.org>
To: Debian Bug Tracking System <455501@bugs.debian.org>
Subject: dpkg: patch for extra uClinux and uClibc architectures
Date: Tue, 28 Jul 2009 18:49:17 +0200
[Message part 1 (text/plain, inline)]
Package: dpkg
Followup-For: Bug #455501

Hi,

this would be the proposed patch adding architectures for uClibc based
Linux and uClinux. Using uClinux implies uClibc, so it is not mentioned
explicitly in the arch name.

This is mainly useful in connection with multiarch.

   Simon

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dpkg depends on:
ii  coreutils                     6.10-6     The GNU core utilities
ii  libc6                         2.7-18     GNU C Library: Shared libraries
ii  lzma                          4.43-14    Compression method of 7z format in

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt                      0.7.20.2+lenny1 Advanced front-end for dpkg

-- no debconf information
[ostable.diff (text/plain, attachment)]
[triplettable.diff (text/plain, attachment)]

Added tag(s) pending. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Sun, 02 Aug 2009 16:18:27 GMT) Full text and rfc822 format available.

Message sent on to Jussi Hakala <jussi.hakala@hut.fi>:
Bug#455501. (Sun, 02 Aug 2009 16:18:37 GMT) Full text and rfc822 format available.

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

From: Guillem Jover <guillem@debian.org>
To: 455501-submitter@bugs.debian.org
Subject: Bug#455501 marked as pending
Date: Sun, 02 Aug 2009 16:09:33 +0000
tag 455501 pending
thanks

Hello,

Bug #455501 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=9d015f4

---
commit 9d015f4fb71cc13c9920c8d62f64f3c2f097389a
Author: Guillem Jover <guillem@debian.org>
Date:   Sun Aug 2 18:04:01 2009 +0200

    Add uClibc Linux support to ostable and triplettable
    
    Closes: #455501

diff --git a/debian/changelog b/debian/changelog
index dbe76dd..35763b2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -23,6 +23,7 @@ dpkg (1.15.4) UNRELEASED; urgency=low
   * Add fakeroot to dpkg-dev Recommends. Closes: #536821
   * Fix an always false test when trying to decide which package to deselect
     to resolve a dependency problem in dselect.
+  * Add uClibc Linux support to ostable and triplettable. Closes: #455501
 
   [ Raphael Hertzog ]
   * Replace install-info by a wrapper around GNU's install-info. The wrapper




Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Sun, 06 Sep 2009 08:51:17 GMT) Full text and rfc822 format available.

Notification sent to Jussi Hakala <jussi.hakala@hut.fi>:
Bug acknowledged by developer. (Sun, 06 Sep 2009 08:51:18 GMT) Full text and rfc822 format available.

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

From: Guillem Jover <guillem@debian.org>
To: 455501-close@bugs.debian.org
Subject: Bug#455501: fixed in dpkg 1.15.4
Date: Sun, 06 Sep 2009 08:00:39 +0000
Source: dpkg
Source-Version: 1.15.4

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.15.4_all.deb
  to pool/main/d/dpkg/dpkg-dev_1.15.4_all.deb
dpkg_1.15.4.dsc
  to pool/main/d/dpkg/dpkg_1.15.4.dsc
dpkg_1.15.4.tar.gz
  to pool/main/d/dpkg/dpkg_1.15.4.tar.gz
dpkg_1.15.4_amd64.deb
  to pool/main/d/dpkg/dpkg_1.15.4_amd64.deb
dselect_1.15.4_amd64.deb
  to pool/main/d/dpkg/dselect_1.15.4_amd64.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 455501@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: Sun, 06 Sep 2009 09:37:45 +0200
Source: dpkg
Binary: dpkg dpkg-dev dselect
Architecture: source amd64 all
Version: 1.15.4
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
Closes: 9771 33394 218018 373602 429262 455501 472208 494714 496114 523980 531307 535138 535327 535353 536538 536821 537558 537559 537741 537742 537800 540019 540382 541412 541829 542254 542254 542254 544037
Changes: 
 dpkg (1.15.4) unstable; urgency=low
 .
   [ Guillem Jover ]
   * Call _g instead of g_ in dpkg-name.
   * Fix inverted logic when deciding to assume the architecture in dpkg-name
     when the package didn't have such field.
   * Do not take into account Revision and Package_Revision fields in dpkg-name
     and dpkg-scanpackages as they have been handled already by “dpkg-deb -I”.
   * Switch dpkg-scansources to use Dpkg::Cdata instead of duplicating the
     .dsc parsing code. As a side effect it now handles properly bogus files.
   * Do not remap obsolete fields in dpkg-scanpackages as they have been
     handled already by “dpkg-deb -I”.
   * Properly mark packages being purged for disappearance from the database.
     This will make the status database not be left behind with traces of old
     not-installed packages. Closes: #472208
   * On parse mark not-installed leftover packages for automatic removal from
     the database on next dump. This obsoletes the --forget-old-unavail option,
     thus making it now a no-op. Closes: #33394, #429262
   * Document “hold” under package selection states instead of flags in dpkg(1).
   * Remove trailing ‘/’ and ‘/.’ from the directory name to be used as the
     package name on “dpkg-deb -b”. Closes: #218018, #373602
   * Remove obsolete ‘hold’ and ‘hold-reinstreq’ internal status flags.
   * Add fakeroot to dpkg-dev Recommends. Closes: #536821
   * Fix an always false test when trying to decide which package to deselect
     to resolve a dependency problem in dselect.
   * Add uClibc Linux support to ostable and triplettable. Closes: #455501
   * Add uClinux support to ostable and triplettable.
     Thanks to Simon Richter <sjr@debian.org>.
   * When aborting due to file conflicts print the version of the conflicted
     package. Closes: #540019
   * Remove double slash in database path visible to the user in some error
     conditions.
   * Stop macthing sparc64-*-* GNU triplets with sparc Debian architecture.
   * Add support for config.d style directories in dpkg and dselect,
     (/etc/dpkg/dpkg.cfg.d and /etc/dpkg/dselect.cfg.d respectively).
   * Define DPKG_MAINTSCRIPT_ARCH on the maintainer script environment to the
     architecture the package got built for.
   * Document DPKG_MAINTSCRIPT_PACKAGE maintainer script environment variable
     in dpkg man page.
   * Document DPKG_RUNNING_VERSION maintainer script environment variable
     in dpkg man page.
   * Change po4a usage to not create unwated changes depending if doing out or
     in-tree builds.
   * Use po4a “--previous” support when updating the man pages.
     Suggested by Christian Perrier <bubulle@debian.org>.
   * On configuration error print file name and line number.
   * Allow quoting values in configuration file options.
   * Add new --pre-invoke and --post-invoke hooks in dpkg.
   * Add new --control-path command to dpkg-query.
   * Use ohshit on bad version syntax in --compare-versions.
   * Add Multi-Arch to the list of known binary package fields for dpkg-dev.
     Thanks to Steve Langasek <vorlon@debian.org>.
 .
   [ Raphael Hertzog ]
   * Replace install-info by a wrapper around GNU's install-info. The wrapper
     will be dropped in squeeze+1. dpkg now Breaks: old versions of
     info-browsers that do not depend on the new install-info package
     that provides the real functionality. Closes: #9771, #523980
     See http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo for details.
   * Fix dpkg's preinst in case /var/lib/dpkg/alternatives contains unexpected
     sub-directories. Closes: #535138
     And also when one of the file doesn't contain correct alternatives
     information (improper number of lines). Closes: #537558
   * Upgrade Standards-Version to 3.8.2 (no changes).
   * Update deb-substvars(5) to list fields that do not support substvars.
     Closes: #535353
   * Fix dpkg-parsechangelog to include all entries with -v0 parameter.
     Closes: #537800
   * Fix update-alternatives to mention the correct slave link that can't
     be installed due to a conflicting file instead of quoting the master link.
   * Add support for extra override file in dpkg-scanpackages. Thanks to Robert
     Millan for the patch. Closes: #537559
   * Add support for extra override file in dpkg-scansources.
   * Document format of extra override file in a new manual page
     deb-extra-override(5).
   * Update sample in dpkg-gensymbols(1) to give an accurate listing of
     64 bit arches. Thanks to Julien Cristau for the patch. Closes: #540382
   * Create /etc/cron.daily/dpkg to handle the backup of
     /var/lib/dpkg/status in /var/backups. This is taken out of the cron
     package and need no conflicts/breaks as the code does nothing if
     the current status file is already backupped. Thanks to Leo 'costela'
     Antunes <costela@debian.org> for the patch. Closes: #541412
   * Change behaviour of dpkg --merge-avail to not update a package's
     information if the version provided is older than the one already listed
     in the available file. Thanks to Ian Jackson
     <ian@davenant.greenend.org.uk> for the patch. Closes: #496114
   * dpkg-architecture can now export DEB_{HOST,BUILD}_ARCH_{BITS,ENDIAN}
     (pointer size and endianness):
     - cputable (in dpkg) modified to contain those information
     - dpkg-dev depends on dpkg (>= 1.15.4) to ensure that we have an updated
       cputable (and so that a versioned build-dependency on dpkg-dev is enough
       to use this new feature)
     Closes: #531307
   * Split overly long Binary: field values over multiple lines. This is
     allowed since policy 3.8.3. Closes: #494714
   * Improve performance of dpkg-shlibdeps by caching minimal version
     associated to each library in Dpkg::Shlib::SymbolFile. Thanks to
     Jiří Paleček <jpalecek@web.de> for the patch.
   * Slightly improve dpkg-source(1) by giving the section name that we're
     referring to. Closes: #544037
   * Fix translation error in german manpage of dpkg-buildpackage. Thanks
     to Joachim Breitner <nomeata@debian.org>. Closes: #541829
 .
   [ Modestas Vainius ]
   * Provide a meaningful label for dpkg-gensymbols diff.
 .
   [ Updated dpkg translations ]
   * Asturian (Marcos Alvarez Costales). Closes: #535327
   * French (Christian Perrier).
   * German (Sven Joachim).
   * Italian (Milo Casagrande). Closes: #536538
   * Russian (Yuri Kozlov). Closes: #542254
   * Slovak (Ivan Masár). Closes: #537742
   * Swedish (Peter Krefting).
 .
   [ Updated dselect translations ]
   * Russian (Yuri Kozlov). Closes: #542254
   * Slovak (Ivan Masár). Closes: #537741
 .
   [ Updated man page translations ]
   * French (Christian Perrier).
   * German (Helge Kreutzmann), proofread by Jens Seidel.
   * Swedish (Peter Krefting).
 .
   [ Updated scripts translations ]
   * French completed (Christian Perrier).
   * German (Helge Kreutzmann).
   * Russian (Yuri Kozlov). Closes: #542254
   * Swedish (Peter Krefting).
Checksums-Sha1: 
 f4e2addc34c72e3100d681b24a506903af379fe3 1211 dpkg_1.15.4.dsc
 732c4dd9cd848768b1dd270697738a84ca1baefd 7036109 dpkg_1.15.4.tar.gz
 8a1c1968e237e0261bdd26847ad3a1e9c39de696 2148332 dpkg_1.15.4_amd64.deb
 2745e187c2cb06bc448fa6ac1ae4a0f98778ef3d 704514 dselect_1.15.4_amd64.deb
 744fd0c7a3cf963a402feb5d1b49c75ba071c612 690158 dpkg-dev_1.15.4_all.deb
Checksums-Sha256: 
 b160b6bf831467169f1f0f7cfe9861f0a47d626e3b5c7376f949b057212369ff 1211 dpkg_1.15.4.dsc
 87cc8f29595e3b63f3c732bfc44b76e991114dbb6411ed82f50bf97b59716543 7036109 dpkg_1.15.4.tar.gz
 15829a1c012fba94629b4c69311c43cde03e9d5fede787c5b7983c073811719d 2148332 dpkg_1.15.4_amd64.deb
 e1d05fc002190f0637bdc7496a9e20a32171ca11a5433d8320e17194b67e6914 704514 dselect_1.15.4_amd64.deb
 295494e1cca00abc2d2a2379b27bba7a43bc1245c11ca485f4e5a93d5a5310c9 690158 dpkg-dev_1.15.4_all.deb
Files: 
 0058b0bdaa39f223792496a1617241bd 1211 admin required dpkg_1.15.4.dsc
 8fac722070803657a3123de6063ff9fd 7036109 admin required dpkg_1.15.4.tar.gz
 4b61f8b54d0d794f1a558406afcd48b2 2148332 admin required dpkg_1.15.4_amd64.deb
 16b87f9a5875fb12b3540c1f9864944c 704514 admin optional dselect_1.15.4_amd64.deb
 597f95e1e0ff2593f626a5a9ab46baa4 690158 utils optional dpkg-dev_1.15.4_all.deb

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

iEYEARECAAYFAkqjaHIACgkQuW9ciZ2SjJveYQCdH6qgKuo0wyr/5l8AwnMbXfl3
OSgAnigix67WKpmov/RZ9DYxl+/BxDvP
=hJtk
-----END PGP SIGNATURE-----





Added tag(s) pending. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Mon, 19 Oct 2009 16:28:17 GMT) Full text and rfc822 format available.

Message sent on to Jussi Hakala <jussi.hakala@hut.fi>:
Bug#455501. (Mon, 19 Oct 2009 16:29:17 GMT) Full text and rfc822 format available.

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

From: Guillem Jover <guillem@debian.org>
To: 455501-submitter@bugs.debian.org
Subject: Bug#455501 marked as pending
Date: Mon, 19 Oct 2009 16:20:05 +0000
tag 455501 pending
thanks

Hello,

Bug #455501 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=9d015f4

---
commit 9d015f4fb71cc13c9920c8d62f64f3c2f097389a
Author: Guillem Jover <guillem@debian.org>
Date:   Sun Aug 2 18:04:01 2009 +0200

    Add uClibc Linux support to ostable and triplettable
    
    Closes: #455501

diff --git a/debian/changelog b/debian/changelog
index dbe76dd..35763b2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -23,6 +23,7 @@ dpkg (1.15.4) UNRELEASED; urgency=low
   * Add fakeroot to dpkg-dev Recommends. Closes: #536821
   * Fix an always false test when trying to decide which package to deselect
     to resolve a dependency problem in dselect.
+  * Add uClibc Linux support to ostable and triplettable. Closes: #455501
 
   [ Raphael Hertzog ]
   * Replace install-info by a wrapper around GNU's install-info. The wrapper




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 17 Nov 2009 07:28:08 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: Thu Apr 17 15:51:51 2014; Machine Name: buxtehude.debian.org

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