All Debian + -ports supported GNU triplets
Hi binutils-multiarch is currently built with support for a hardcoded list of triplets. I've changed this in Ubuntu to use --enable-targets=all [1] and used the same for the new gdb-multiarch package, but this is a bit painful as it causes some issues [2] and requires people to set the gnutarget in gdb-mutliarch [3]. So I intend to change binutils-multiarch and gdb-multiarch to --enable-targets=all Debian-supported GNU triplets. But the first column of /usr/share/dpkg/archtable only covers triplets suppored in Debian itself (not on debian-ports) and is documented as being there for historical reasons only. My current guess is to combine all GNU CPU names found in the second column of /usr/share/dpkg/cputable with all the GNU names found in the second column of /usr/share/dpkg/ostable, but that seems to be way more than the real Debian + debian-ports.org ports which we support. What would you folks suggest? Thanks for your input! [1] http://launchpadlibrarian.net/65095236/binutils_2.21.0.20110216-1ubuntu1_2.21.0.20110216-1ubuntu2.diff.gz [2] http://launchpadlibrarian.net/65218001/buildlog_ubuntu-natty-i386.armel-cross-toolchain-base_1.59_FAILEDTOBUILD.txt.gz http://launchpadlibrarian.net/65215384/buildlog_ubuntu-natty-i386.gcc-4.5-armel-cross_1.46_FAILEDTOBUILD.txt.gz [3] http://lists.linaro.org/pipermail/linaro-dev/2011-January/002022.html -- Loïc Minier -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110228160856.ga9...@bee.dooz.org
Re: Bug#594179: dpkg armhf patch acceptance status?
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
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110217112730.ga19...@bee.dooz.org
Bug#594179: dpkg armhf patch acceptance status?
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
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dpkg armhf patch acceptance status?
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 -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100913095452.gb21...@bee.dooz.org
Bug#594179: dpkg armhf patch acceptance status?
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 -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591522: dpkg-shlibdeps still fails when cross-compiling
On Tue, Aug 03, 2010, Raphael Hertzog wrote: On Tue, 03 Aug 2010, Simon Richter wrote: while using the target objdump is a Good Thing(tm), it uncovered another bug: for dependent libraries, the host's version is passed to the target objdump. That's not really accurate, it's passed to objdump -a only to verify if the binary has the same format than the executable analyzed. The full analysis comes only later if there's a match. While this looks like a regression as builds that used to work now fail, it isn't, because the builds were only correct by chance before. Symptom is that during a cross build of a library that links against libutil, the following is output: m68k-linux-gnu-objdump: /lib/libutil.so.1: File format not recognized dpkg-shlibdeps: error: m68k-linux-gnu-objdump gave error exit status 1 The correct file would be /usr/m68k-linux-gnu/lib/libutil.so.1 . The path can be retrieved from the target gcc using the -print-search-dirs option. dpkg-shlibdeps looks in the correct path as well. But it really needs a portable way to know whether a file has been built for the same architecture than the executable analyzed. It tries to do this with objdump -a and with binutils-multiarch that was working fine. It would then detect that it was the wrong version and would continue to look for the correct library. Loïc, what do you suggest? Should we parse the error instead? And/or fallback to the host objdump? I wonder whether it makes sense to look into /usr/lib at all when cross-building? Perhaps we should patch the routine which prepares a list of files to analyze to not search usr/lib when cross-building? I'm not sure where that one is. If that's not an option, I think the routine checking the format of executable could run the cross-objdump and if it fails try the host objdump as a fallback. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: armelfp: new architecture name for an armel variant
On Thu, Jul 15, 2010, Aurelien Jarno wrote: It allows to provide different versions of a given symbol using an IFUNC symbol type. This will be resolved by the dynamic loader during relocation depending on the hardware characteristics. [...] Currently only x86, x86_64, ia64, powerpc and sparc are supported, but it should not be difficult to add support for more architectures. Unfortunately, this requires getting it in the ARM ABI spec first, and apparently that can take very long, they avoid rev-ing the ABI too frequently (Linaro intends to work on this later this year [1]) [1] https://blueprints.launchpad.net/binutils-linaro/+spec/stt-gnu-ifunc and https://blueprints.launchpad.net/binutils-linaro/+spec/gold-stt-gnu-ifunc -- Loïc Minier -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100715183524.ga6...@bee.dooz.org
Re: armelfp: new architecture name for an armel variant
On Thu, Jul 08, 2010, Guillem Jover wrote: The lpia is a great example of an architecture variant that was a mistake, and should haver never been created. This is a bit oversimplified; when lpia was created, there were proposals to diverge the x86 ISA. These didn't happen though, and I agree that the end result wasn't worth the pain. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100709142817.gb14...@bee.dooz.org
Bug#583902: Integration into other tools
Hi there This is a followup to Debian #583902 which adds --path-include/--path-exclude flags. First, this is awesome, thanks! I was wondering about some related things: - how are diverts handled, that is what if a package tries to dpkg-divert an ultimately excluded file, will that be excluded and skipped? - I understand that debsums will just work because you strip .list files as well - how is integration with APT going to happen? I think APT has an option to pass random flags to dpkg (DPkg::options I think), but I wonder whether it would make sense to have an APT variable tracking list of include/excludes which need to be passed to dpkg on all calls. Also, this doesn't cover manual installation of packages by the admin, so perhaps you simply intended to use /etc/dpkg/dpkg.cfg? - is there a way to apply the includes to an installed systems/chroots? That is, I expect this will be used during image builds or on installed systems, so it will probably have to work from an existing chroot, just after debootstrap for instance (or perhaps much later); I expect it might be something like: * update file exclusion filters in some central (config?) file for dpkg * apply the filters - in the same vein, is there a way to track which packages are missing files as to allow reinstalling them when the filters get updated? For instance, if I'm stripping all man pages but later decide I want them, I would remove the filter and reinstall all the relevant packages, how would list the stripped packages? Thanks! -- Loïc Minier -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583902: Integration into other tools
On Tue, Jun 15, 2010, Martin Pitt wrote: - is there a way to apply the includes to an installed systems/chroots? Not right now. In our project where we use that we use a projectname-config package which just applies those changes in the postinst with some find | xargs rm style commands. Would be lovely if you script would base it's input (list of filters) on the dpkg.cfg format so that it could be included and shipped with dpkg as a contributed script. e.g. dpkg-apply-path-filters or something. That would avoid duplicating the list of path filters. - in the same vein, is there a way to track which packages are missing files as to allow reinstalling them when the filters get updated? For instance, if I'm stripping all man pages but later decide I want them, I would remove the filter and reinstall all the relevant packages, how would list the stripped packages? I guess you could compare the .list contents with actually installed files. Otherwise this would require install --reinstall'ing every package which is certainly possible, but takes a lot of effort. I wonder how trivial that really is with things like diverts, conffiles and such. But it sounds like a good base, I was asking because I wondered whether it would make sense for dpkg to track the delta as well. Thanks for your replies! -- Loïc Minier -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: (not) simplifying dpkg-shlibdeps with readelf
On Thu, Apr 22, 2010, Jonathan Nieder wrote: - readelf is tiny and works for all ELF targets. By contrast, multi-target objdump is large and its Debian package only supports the targets that were considered worth the trouble when it was last built. I guess you mean binutils-multiarch here; I submitted a patch in Debian #578365 to use a cross-objdump when cross-building. I expect objdump or cross-objdump should support the binaries which you're about to ship in a .deb. The only other case I can think of is when a package's build calls a non-default (cross-)compiler to generate a specific file, e.g. a firmware, in which case it might not be ELF at all. [1] To discover SONAME, NEEDED, RUNPATH, and RPATH, one could parse ‘eu-readelf --dynamic $file’ output. You might want to consider symbols as well as to have dpkg-shlibdeps and dpkg-gensymbols rely on the same underlying tool. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100426115011.ga14...@bee.dooz.org
Bug#578365: Cross objdump support
Package: dpkg
Version: 1.15.6.1
Severity: minor
Tags: patch
Hi there
When cross-building, tools using Dpkg/Shlibs/Objdump.pm will call
/usr/bin/objdump instead of its $triplet-objdump counterpart from the
cross-toolchain.
It was never reported so far because it's a common issue in upstream
build systems as well, and there's an easy workaround in the form of
binutils-multiarch. dpkg-cross depends on binutils-multiarch.
However, this means that one has to rebuild binutils-multiarch to
cross-build for an architecture not supported by binutils-multiarch.
Thanks for considering the attached patch,
--
Loïc Minier
diff -Nru dpkg-1.15.6.1/debian/changelog dpkg-1.15.6.2/debian/changelog
--- dpkg-1.15.6.1/debian/changelog 2010-03-25 00:52:32.0 +0100
+++ dpkg-1.15.6.2/debian/changelog 2010-04-19 12:38:29.0 +0200
@@ -1,3 +1,9 @@
+dpkg (1.15.6.2) UNRELEASED; urgency=low
+
+ * scripts/Dpkg/Shlibs/Objdump.pm: Use triplet-objdump when cross-building.
+
+ -- Loïc Minier l...@debian.org Mon, 19 Apr 2010 12:38:01 +0200
+
dpkg (1.15.6.1) experimental; urgency=low
[ Guillem Jover ]
diff -Nru dpkg-1.15.6.1/scripts/Dpkg/Shlibs/Objdump.pm dpkg-1.15.6.2/scripts/Dpkg/Shlibs/Objdump.pm
--- dpkg-1.15.6.1/scripts/Dpkg/Shlibs/Objdump.pm 2010-03-21 09:46:34.0 +0100
+++ dpkg-1.15.6.2/scripts/Dpkg/Shlibs/Objdump.pm 2010-04-19 12:39:43.0 +0200
@@ -80,8 +80,13 @@
return $format{$file};
} else {
local $ENV{LC_ALL} = C;
- open(P, -|, objdump, -a, --, $file)
- || syserr(_g(cannot fork for %s), objdump);
+ my $od = objdump;
+ # cross-compiling?
+ if ($ENV{'DEB_BUILD_GNU_TYPE'} ne $ENV{'DEB_HOST_GNU_TYPE'}) {
+ $od = $ENV{'DEB_HOST_GNU_TYPE'} . -objdump;
+ }
+ open(P, -|, $od, -a, --, $file)
+ || syserr(_g(cannot fork for %s), $od);
while (P) {
chomp;
if (/^\s*\S+:\s*file\s+format\s+(\S+)\s*$/) {
@@ -89,7 +94,7 @@
return $format{$file};
}
}
- close(P) or subprocerr(_g(objdump on \`%s'), $file);
+ close(P) or subprocerr(_g($od on \`%s'), $file);
}
}
}
@@ -154,8 +159,13 @@
$self-{file} = $file;
local $ENV{LC_ALL} = 'C';
-open(my $objdump, -|, objdump, -w, -f, -p, -T, -R, $file)
- || syserr(_g(cannot fork for %s), objdump);
+my $od = objdump;
+# cross-compiling?
+if ($ENV{'DEB_BUILD_GNU_TYPE'} ne $ENV{'DEB_HOST_GNU_TYPE'}) {
+ $od = $ENV{'DEB_HOST_GNU_TYPE'} . -objdump;
+}
+open(my $objdump, -|, $od, -w, -f, -p, -T, -R, $file)
+ || syserr(_g(cannot fork for %s), $od);
my $ret = $self-parse_objdump_output($objdump);
close($objdump);
return $ret;
Bug#578365: Cross objdump support
On Mon, Apr 19, 2010, Raphael Hertzog wrote:
Hum, shouldn't we call $arch-objdump only after having checked its
availability?
That would be ideal in the possible (albeit unlikely case) where
binutils-multiarch is available but not a cross-binutils.
Are there packages that can be cross-built without the binutils for the
target host? I guess in theory no (but I don't know all esoteric languages
that we have)... but maybe in practice there might be packages which are
wrongly architecture specific that could be crossbuilt without it
nevertheless. It would be sad to introduce a regression for those just
because we're trying to call something that doesn't exist.
I can't think of any example, but it might be. Note that objdump can
not be expected to parse these, so it's either our regular objdump
failing or binutils-multiarch is installed.
quotes not needed around $od
Fixed in attached patch
- close(P) or subprocerr(_g(objdump on \`%s'), $file);
+ close(P) or subprocerr(_g($od on \`%s'), $file);
No variable in translated strings (I think we can remove the translation
altogether and only put the command called in the message).
Ah right, wasn't paying attention (just rebased an old patch I had
tested); I dropped the translation altogether in the attached patch,
but this means we don't mention the processed file in the error message
anymore.
--
Loïc Minier
diff -Nru dpkg-1.15.6.1/debian/changelog dpkg-1.15.6.2/debian/changelog
--- dpkg-1.15.6.1/debian/changelog 2010-03-25 00:52:32.0 +0100
+++ dpkg-1.15.6.2/debian/changelog 2010-04-19 12:38:29.0 +0200
@@ -1,3 +1,9 @@
+dpkg (1.15.6.2) UNRELEASED; urgency=low
+
+ * scripts/Dpkg/Shlibs/Objdump.pm: Use triplet-objdump when cross-building.
+
+ -- Loïc Minier l...@debian.org Mon, 19 Apr 2010 12:38:01 +0200
+
dpkg (1.15.6.1) experimental; urgency=low
[ Guillem Jover ]
diff -Nru dpkg-1.15.6.1/scripts/Dpkg/Shlibs/Objdump.pm dpkg-1.15.6.2/scripts/Dpkg/Shlibs/Objdump.pm
--- dpkg-1.15.6.1/scripts/Dpkg/Shlibs/Objdump.pm 2010-03-21 09:46:34.0 +0100
+++ dpkg-1.15.6.2/scripts/Dpkg/Shlibs/Objdump.pm 2010-04-19 17:15:03.0 +0200
@@ -80,8 +80,13 @@
return $format{$file};
} else {
local $ENV{LC_ALL} = C;
- open(P, -|, objdump, -a, --, $file)
- || syserr(_g(cannot fork for %s), objdump);
+ my $od = objdump;
+ # cross-compiling?
+ if ($ENV{'DEB_BUILD_GNU_TYPE'} ne $ENV{'DEB_HOST_GNU_TYPE'}) {
+ $od = $ENV{'DEB_HOST_GNU_TYPE'} . -objdump;
+ }
+ open(P, -|, $od, -a, --, $file)
+ || syserr(_g(cannot fork for %s), $od);
while (P) {
chomp;
if (/^\s*\S+:\s*file\s+format\s+(\S+)\s*$/) {
@@ -89,7 +94,7 @@
return $format{$file};
}
}
- close(P) or subprocerr(_g(objdump on \`%s'), $file);
+ close(P) or subprocerr($od);
}
}
}
@@ -154,8 +159,13 @@
$self-{file} = $file;
local $ENV{LC_ALL} = 'C';
-open(my $objdump, -|, objdump, -w, -f, -p, -T, -R, $file)
- || syserr(_g(cannot fork for %s), objdump);
+my $od = objdump;
+# cross-compiling?
+if ($ENV{'DEB_BUILD_GNU_TYPE'} ne $ENV{'DEB_HOST_GNU_TYPE'}) {
+ $od = $ENV{'DEB_HOST_GNU_TYPE'} . -objdump;
+}
+open(my $objdump, -|, $od, -w, -f, -p, -T, -R, $file)
+ || syserr(_g(cannot fork for %s), $od);
my $ret = $self-parse_objdump_output($objdump);
close($objdump);
return $ret;
Bug#555743: dpkg-gencontrol: add support for Description:-s in the Source package stanza
On Tue, Mar 02, 2010, Raphael Hertzog wrote: The sensible answer is putting this information in the .dsc and thus in the Sources files. But it means that the file would get somewhat bigger and it might meant again supplementary changes in the infrastructutre if people want to see those descriptions translated (but I'm not convinced we need translations on Sources, users of those are mostly developers contrary to Packages). While that seems sensible, I wonder whether it would make sense to include the information in Packages.gz instead. There's a high level use case which is not too nicely covered at the moment: if one upgrades with a graphical package management tools displaying progress of the upgrade, it would typically show which package is being upgraded with its description, but you typically upgrade all binary packages from the same source at the same time, so in the list of packages to update, you'd likely see The GTK+ graphical user interface library (libgtk2.0-0), The programs for the GTK+ graphical user interface library (libgtk2.0-bin), Common files for the GTK+ graphical user interface library (libgtk2.0-common) while it would probably make sense to only offer a single entry for the software bundle being updated, i.e. for all binary packages provided by the same source, with a nice description. Now that use case still has a flaw in usability in that even per source package descriptions wouldn't mean much to non-developers, so it's probably a minor improvement in package managers not worth the effort of changing infrastucture etc. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528171: dpkg --print-installation-architecture isn't covered in manpage nor --help
Package: dpkg Version: 1.14.26 Severity: wishlist Hi I came across a script which calls dpkg --print-installation-architecture and works fine; it seems to act as --print-architecture; could you please document that in --help and man page? Thanks -- Loïc Minier -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#489238: Cryptic message when using | in Conflicts
Package: dpkg Version: 1.14.20 Severity: wishlist Hi, I accidentally used a | in conflicts (instead of depends) in a build and this resulter in: dpkg-gencontrol: internal error: The method merge_union() is only valid for Dpkg::Deps::Simple As discussed on IRC with Raphaël, this is a bit cryptic; perhaps the error message could be improved to point out undefined usage of | in conflicts. Thanks -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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-12 GNU C Library: Shared libraries dpkg recommends no packages. -- no debconf information -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Wed, Mar 05, 2008, Mike Bird wrote: May I suggest then that if no dpkg maintainer objects here within 48 hours that Ian should proceed with his update? May you stop in the next hour giving executive advice when you're not representing anybody whatsoever? -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage now reorganizing debian/control Depends field??
On Fri, Feb 22, 2008, Raphael Hertzog wrote: 2/ debdiff uses wdiff to show changes on field values and wdiff gives spurious differences if the sole difference between both values is a different order. Thus debdiff output is more useful with ordered Depends fields. (Probably stating the obvious, but this could be fixed at the debdiff level.) -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465282: Proposalto introduce compiler options passed from dpkg-buildpackage
On Thu, Feb 14, 2008, Frank Lichtenheld wrote: Hmm, I doubt that dpkg-dev should be the place to keep track of that. I mean, that probably depends on the version of gcc/g++/whatever used, so it's quite meaningless to make it dependent on the version of dpkg-dev you use. Should we have a new default-flags package or something which would be the place where these flags are set? Perhaps queryable with: get-default-flags --gcc get-default-flags --ld etc. -- Loïc Minier
Bug#445552: dpkg-buildpackage should systematically check build-deps before calling clean
On Fri, Jan 18, 2008, Raphael Hertzog wrote: Do we have any idea of how many packages/services actually use dpkg-buildpackage -S ? I know a lot of people do sourceful uploads in Ubuntu (all uploads are sourceful in Ubuntu and PPAs); I don't know of services doing it, but I guess things like buildserver.net might. These can actually call clean manually if they want to take the risk. I think it's not a problem to checkbuilddeps if you skip the test when -nc is passed: people will simply have to learn to -S -nc or -S -d if they want to clean (or fakeroot debian/rules clean manually, as I do). -- Loïc Minier
Bug#445552: dpkg-buildpackage should systematically check build-deps before calling clean
Package: dpkg-dev Version: 1.14.6 Severity: normal Hi, Per policy 7.6, build-deps must be available for clean; pbuilder calls dpkg-buildpackage -S to generate a source suitable to be copied into the build environment; by default, this involves cleaning before building the source, but dpkg-checkbuilddeps isn't run before cleaning. I think dpkg-builcpackage should run dpkg-checkbuilddeps and fail at this point when called with -S. Currently, clean might fail if build-deps are unavailable (such as missing patch system package), but this should really be an error detected earlier on. pbuilder will probably want to override this behavior and output a warning if dpkg-checkbuilddeps as run by pbuilder fails, but still try to continue unless clean fails. Bye, -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg-dev depends on: ii binutils 2.18-1 The GNU assembler, linker and bina ii cpio 2.9-4 GNU cpio -- a program to manage ar ii dpkg 1.14.6 package maintenance system for Deb ii make 3.81-3 The GNU version of the make util ii patch 2.5.9-4Apply a diff file to an original ii perl [perl5] 5.8.8-11 Larry Wall's Practical Extraction ii perl-modules 5.8.8-11 Core Perl modules Versions of packages dpkg-dev recommends: ii bzip2 1.0.3-7high-quality block-sorting file co ii gcc [c-compiler] 4:4.2.1-6 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.6-6The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-16 The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.1-5The GNU C compiler -- no debconf information -- Loïc Minier
Bug#41907: test to avoid self-dependencies is incorrect
tags 41907 + confirmed stop Hi, I'm still experiencing this bug today, and I suppose most people generating udebs are: bee% for i in udeb 0; do dpkg-shlibdeps -O debian/libpango1.0-$i/usr/lib/libpangoft2-1.0.so.0.1400.0; done shlibs:Depends=libc6 (= 2.3.6-6), libfontconfig1 (= 2.3.0), libfreetype6 (= 2.2), libglib2.0-0 (= 2.12.0), libpango1.0-0 (= 1.14.0), zlib1g (= 1:1.2.1) shlibs:Depends=libc6 (= 2.3.6-6), libfontconfig1 (= 2.3.0), libfreetype6 (= 2.2), libglib2.0-0 (= 2.12.0), zlib1g (= 1:1.2.1) (Note that there's an added libpango1.0-0 dependency in the udeb; would I be calling dpkg-shlibdeps with the proper flags, this would cause a self dependency in libpango1.0-udeb.) I've investigated this a little further, and found the cause to be: 1) binaries in the package which depend on the shared lib 2) special exception to not add self-dependencies in some cases in dpkg-shlibdeps: return 1 if $fn eq $curpackdir/DEBIAN/shlibs; (around 365) However, the above test is incorrect: it tests whether the shlibs where the dependencies comes from is in the same package as the binary which needs the dependency. Instead, it should test whether the shlibs would cause a dependency on the same package where the binary is from. I think that both the incorrect and the proposed fixed behaviors are both too clever for dpkg-shlibdeps, and it should simply permit filtering the generated deps instead. This could for example be used by dh_shlibdeps to implement the old behavior and permit the maintainer to extend the filtering such as in the case of udebs. Bye, -- Loïc Minier [EMAIL PROTECTED]
