Bug#356408: Addition
On Sat, 11 Mar 2006, Jiří Paleček wrote: I forgot to describe the testcase: Try installing it, then remove, then delete /etc/test/test.conf, then install again. This has always been a feature. An administrator can remove a conffile and dpkg should respect this local change (a removal is considered a change just like another). Thus this is not a bug. If you want an improvement, you need to come up with a way to differentiate a manual remove from the admin with a file lost due to another problem. I don't know of any... I suggest closing this bug. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#338863: failure: ... died from signal 11. Compiling eclipse and using make-jpkg
On Tue, 09 May 2006, [EMAIL PROTECTED] wrote: I've made more test. The failure only happens when I execute dpkg-buildpackage inside fakeroot. As root all works fine. Please give the version of fakeroot that you're using. But this bug should most probably be reassigned to fakeroot. Please check that you're using the latest fakeroot of the official amd64 respository (ie from a normal Debian mirror). http://ftp.debian.org/debian/pool/main/f/fakeroot/fakeroot_1.5.8_amd64.deb Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#375749: tar: -: file name read contains nul character
On Wed, 28 Jun 2006, Bob Tanner wrote: On Tuesday 27 June 2006 17:04, you wrote: dpkg-1.13.22$ dpkg-buildpackage -rfakeroot -sa snip dh_builddeb -a dpkg-deb: building package `dpkg' in `../dpkg_1.13.22_i386.deb'. tar: -: file name read contains nul character dpkg-deb: building package `dselect' in `../dselect_1.13.22_i386.deb'. tar: -: file name read contains nul character No one can duplicate this bug? Everybody can but AFAIK it's only a warning (ie it has no consequences on the package generated). Concerning lintian, it has been fixed today to call tar with the --wildcards parameter. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#378340: dpkg-dev: no support for XB-Python-Version yet?
On Mon, 17 Jul 2006, Toni Mueller wrote: Hello, On Sun, 16.07.2006 at 19:06:58 +1000, Brendan O'Dea [EMAIL PROTECTED] wrote: On Sat, Jul 15, 2006 at 03:19:45PM +0200, Toni Mueller wrote: dpkg-genchanges: warning: unknown information field `Xb-Python-Version' in input data in package's section of control info file It's just a warning. Check the generated package; if you run 'dpkg --info whatever.deb' you should see a Python-Version header. yes, it's a warning, and I assume(d) that you want to make the warning go away. IMHO, developer tools should not emit warnings for conditions which are mandated by the policy. Therefore I reported the bug because apparently tools and policy are currently out of sync. Except that there's no real agreement that this field is needed as part of the python policy. Quite a number of packages do not use it... Still, the warning is annoying. When people use a XC or XS prefix, they probably didn't create a new field by error ... I understand that we want to be more careful for standard headers but for XC/XS headers, we could be a bit less picky. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#428507: dpkg: The error in package upgrading if the old version contains symlinks.
severity 428507 normal thanks On Tue, 12 Jun 2007, Dmitry E. Oboukhov wrote: Package: dpkg Version: 1.13.25 Severity: grave Please don't inflate the severity without good reasons. If the old version of the package contains symlink, and the new version tries to save a directory into the same place, then an upgrade won't be correct. This has always been the case and it's not a bug but a feature. It's that way so that the local admin can effectively move a sub-directory somewhere else (where he has more spaces for example) and replace the directory with a symlink. If the package really wants to replace a symlink, it has to remove the symlink in the preinst script. This behaviour is documented in the Debian Policy: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html | A directory will never be replaced by a symbolic link to a directory or | vice versa; instead, the existing state (symlink or not) will be left | alone and dpkg will follow the symlink if there is one. I'll let the dpkg maintainer close this bug (or merge it if he prefers, of tag wontfix). The bug that the symlink doesn't not replace the directory is already documented in #182747. #406715 is another variant where the symlink is silently ignored when a pre-existing directory is there (although in that case it concerns two different packages). Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#430367: Integrate support of a newer dpkg-shlibdeps working at the symbol level
Package: dpkg
Version: 1.14.4
Please find attached a patch integrating my work on dpkg-shlibdeps in the
current dpkg version. I've put my work in a git repository on
git://git.debian.org/git/private/hertzog/dpkg (branch dpkg-shlibdeps)
It creates a set of modules in /usr/lib/dpkg/Dpkg/ as I need some shared
code between dpkg-gensymbols and dpkg-shlibdeps.
There's no documentation update yet, but I shall work on that once the
code is integrated. I'll maintain that code over time and do any possible
bugfixes and enhancements that may appear.
I expect at least some enhancements in the way we handle the symbols files
over the set of architectures (ie to share some information instead of
having simply debian/package.symbols.arch).
Any comments welcome. Please note that the code in the bzr branch is
outdated now. I did substantial changes to put some code in modules.
For reference, the following wiki page contains the initial spec that lead
me in this work:
http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
diff --git a/configure.ac b/configure.ac
index a023b03..1b899ef 100644
--- a/configure.ac
+++ b/configure.ac
@@ -112,6 +112,7 @@ AC_CONFIG_FILES([ Makefile
origins/Makefile
po/Makefile.in
scripts/Makefile
+ scripts/modules/Makefile
scripts/po/Makefile.in
src/Makefile
utils/Makefile ])
diff --git a/debian/dpkg-dev.install b/debian/dpkg-dev.install
index fda7604..d5e165c 100644
--- a/debian/dpkg-dev.install
+++ b/debian/dpkg-dev.install
@@ -8,6 +8,7 @@ usr/bin/dpkg-checkbuilddeps
usr/bin/dpkg-distaddfile
usr/bin/dpkg-genchanges
usr/bin/dpkg-gencontrol
+usr/bin/dpkg-gensymbols
usr/bin/dpkg-name
usr/bin/dpkg-parsechangelog
usr/bin/dpkg-scanpackages
@@ -15,6 +16,7 @@ usr/bin/dpkg-scansources
usr/bin/dpkg-shlibdeps
usr/bin/dpkg-source
usr/lib/dpkg/controllib.pl
+usr/lib/dpkg/Dpkg
usr/lib/dpkg/parsechangelog
usr/share/locale/*/LC_MESSAGES/dpkg-dev.mo
usr/share/man/*/*/822-date.1
diff --git a/scripts/Makefile.am b/scripts/Makefile.am
index b8b3643..45eaedf 100644
--- a/scripts/Makefile.am
+++ b/scripts/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with automake to produce Makefile.in
-SUBDIRS = po
+SUBDIRS = po modules
bin_SCRIPTS = \
822-date \
@@ -10,6 +10,7 @@ bin_SCRIPTS = \
dpkg-distaddfile \
dpkg-genchanges \
dpkg-gencontrol \
+ dpkg-gensymbols \
dpkg-name \
dpkg-parsechangelog \
dpkg-scanpackages \
@@ -36,6 +37,7 @@ EXTRA_DIST = \
dpkg-distaddfile.pl \
dpkg-genchanges.pl \
dpkg-gencontrol.pl \
+ dpkg-gensymbols.pl \
dpkg-name.sh \
dpkg-parsechangelog.pl \
dpkg-scanpackages.pl \
diff --git a/scripts/dpkg-gensymbols.pl b/scripts/dpkg-gensymbols.pl
new file mode 100755
index 000..c1066e0
--- /dev/null
+++ b/scripts/dpkg-gensymbols.pl
@@ -0,0 +1,235 @@
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+our $version;
+our $dpkglibdir;
+BEGIN {
+$version=1.14.4; # This line modified by Makefile
+$dpkglibdir=/usr/lib/dpkg; # This line modified by Makefile
+push(@INC,$dpkglibdir);
+}
+require 'controllib.pl';
+
+use Dpkg::Version qw(compare_versions);
+use Dpkg::Shlibs qw(@librarypaths);
+use Dpkg::Shlibs::Objdump;
+use Dpkg::Shlibs::SymbolFile;
+
+our $progname;
+our (%f, %fi);
+our %p2i;
+our @librarypaths;
+
+our $host_arch= `dpkg-architecture -qDEB_HOST_ARCH`;
+chomp $host_arch;
+
+require 'dpkg-gettext.pl';
+textdomain(dpkg-dev);
+
+my $controlfile = 'debian/control';
+my $changelogfile = 'debian/changelog';
+my $packagebuilddir = 'debian/tmp';
+
+my $sourceversion;
+my $stdout;
+my $oppackage;
+my $compare = 1; # Bail on missing symbols by default
+my $output;
+my $debug = 0;
+
+sub version {
+printf _g(Debian %s version %s.\n), $progname, $version;
+
+printf _g(
+Copyright (C) 2007 Raphael Hertzog.
+);
+
+printf _g(
+This is free software; see the GNU General Public Licence version 2 or
+later for copying conditions. There is NO warranty.
+);
+}
+
+sub usage {
+printf _g(
+Usage: %s [option ...]
+
+Options:
+ -ppackage generate symbols file for package.
+ -Ppackagebuilddir temporary build dir instead of debian/tmp.
+ -elibrary explicitely list libraries to scan.
+ -vversion version of the packages (defaults to
+ version extracted from debian/changelog).
+ -clevelcompare generated symbols file with the
+ reference file in the debian directory.
+ Fails if difference are too important
+ (level goes from 0 for no check, to 4
+ for all checks). By default checks at
+ level 1.
+ -Ofile write to file, not .../DEBIAN/symbols.
+ -O write to stdout, not .../DEBIAN/symbols.
+ -d display debug information during work.
+ -h, --help show this help message.
+ --version
Bug#430958: dpkg should call fsync() before rename()
On Thu, 28 Jun 2007, Russell Coker wrote: Package: dpkg Version: 1.13.25 Severity: normal Below is part of the output of stracing dpkg when installing a package. As you can see it opens the file without O_SYNC and renames it without calling fsync() first. This means that a reboot during the period for which write- back caching is active (which depends on the load of the machine, the amount of free RAM, and the filesystem in use) will cause loss of file data. If the machine reboots while dpkg unpacks a package, dpkg will know that the package is not cleanly unpacked/updated and this will simply get fixed later after the reboot when the user finishes his update. I fail to see a scenario where this behaviour leads to a problem. If the .dpkg-new file is not written on disk, I don't see why the directory content would be updated on disk. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#430367: Integrate support of a newer dpkg-shlibdeps working at the symbol level
On Sun, 01 Jul 2007, Frank Lichtenheld wrote:
On Sun, Jul 01, 2007 at 12:45:56PM +0200, Frank Lichtenheld wrote:
1) Apply the part of the patch that adds the modules. Since that doesn't
add anything useful to dpkg in its own right, we should probably make
this in a branch
2) Do some code clean-up
I'll gladly do the code cleanup if you can elaborate on what's not okay
according to your (perl coding) standards.
In general, I might even be interested in doing this for more of the perl
code contained in dpkg (though I don't want to promise anything).
3) Add a minimal test suite (no excuse not to do this for entirely new
code!)
Something simple with Test::More should suffice, but if someone
prefers a more sophisticated framework, I will not stand in his way.
What do you want to test? The scripts or the modules or both?
We always need binaries and libraries to do the test, how do you expect me
to handle that?
4) when satisfied with the result, apply the rest of the patch
5) Merge to trunk/
On second thought: as we don't apply the patch in trunk/, I will apply
it completly and not in separate steps
Please find attached a patch rebased on the latest trunk (as requested on
IRC).
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
diff --git a/configure.ac b/configure.ac
index a023b03..1b899ef 100644
--- a/configure.ac
+++ b/configure.ac
@@ -112,6 +112,7 @@ AC_CONFIG_FILES([ Makefile
origins/Makefile
po/Makefile.in
scripts/Makefile
+ scripts/modules/Makefile
scripts/po/Makefile.in
src/Makefile
utils/Makefile ])
diff --git a/debian/dpkg-dev.install b/debian/dpkg-dev.install
index fda7604..d5e165c 100644
--- a/debian/dpkg-dev.install
+++ b/debian/dpkg-dev.install
@@ -8,6 +8,7 @@ usr/bin/dpkg-checkbuilddeps
usr/bin/dpkg-distaddfile
usr/bin/dpkg-genchanges
usr/bin/dpkg-gencontrol
+usr/bin/dpkg-gensymbols
usr/bin/dpkg-name
usr/bin/dpkg-parsechangelog
usr/bin/dpkg-scanpackages
@@ -15,6 +16,7 @@ usr/bin/dpkg-scansources
usr/bin/dpkg-shlibdeps
usr/bin/dpkg-source
usr/lib/dpkg/controllib.pl
+usr/lib/dpkg/Dpkg
usr/lib/dpkg/parsechangelog
usr/share/locale/*/LC_MESSAGES/dpkg-dev.mo
usr/share/man/*/*/822-date.1
diff --git a/scripts/Makefile.am b/scripts/Makefile.am
index b8b3643..45eaedf 100644
--- a/scripts/Makefile.am
+++ b/scripts/Makefile.am
@@ -1,6 +1,6 @@
## Process this file with automake to produce Makefile.in
-SUBDIRS = po
+SUBDIRS = po modules
bin_SCRIPTS = \
822-date \
@@ -10,6 +10,7 @@ bin_SCRIPTS = \
dpkg-distaddfile \
dpkg-genchanges \
dpkg-gencontrol \
+ dpkg-gensymbols \
dpkg-name \
dpkg-parsechangelog \
dpkg-scanpackages \
@@ -36,6 +37,7 @@ EXTRA_DIST = \
dpkg-distaddfile.pl \
dpkg-genchanges.pl \
dpkg-gencontrol.pl \
+ dpkg-gensymbols.pl \
dpkg-name.sh \
dpkg-parsechangelog.pl \
dpkg-scanpackages.pl \
diff --git a/scripts/dpkg-gensymbols.pl b/scripts/dpkg-gensymbols.pl
new file mode 100755
index 000..c1066e0
--- /dev/null
+++ b/scripts/dpkg-gensymbols.pl
@@ -0,0 +1,235 @@
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+our $version;
+our $dpkglibdir;
+BEGIN {
+$version=1.14.4; # This line modified by Makefile
+$dpkglibdir=/usr/lib/dpkg; # This line modified by Makefile
+push(@INC,$dpkglibdir);
+}
+require 'controllib.pl';
+
+use Dpkg::Version qw(compare_versions);
+use Dpkg::Shlibs qw(@librarypaths);
+use Dpkg::Shlibs::Objdump;
+use Dpkg::Shlibs::SymbolFile;
+
+our $progname;
+our (%f, %fi);
+our %p2i;
+our @librarypaths;
+
+our $host_arch= `dpkg-architecture -qDEB_HOST_ARCH`;
+chomp $host_arch;
+
+require 'dpkg-gettext.pl';
+textdomain(dpkg-dev);
+
+my $controlfile = 'debian/control';
+my $changelogfile = 'debian/changelog';
+my $packagebuilddir = 'debian/tmp';
+
+my $sourceversion;
+my $stdout;
+my $oppackage;
+my $compare = 1; # Bail on missing symbols by default
+my $output;
+my $debug = 0;
+
+sub version {
+printf _g(Debian %s version %s.\n), $progname, $version;
+
+printf _g(
+Copyright (C) 2007 Raphael Hertzog.
+);
+
+printf _g(
+This is free software; see the GNU General Public Licence version 2 or
+later for copying conditions. There is NO warranty.
+);
+}
+
+sub usage {
+printf _g(
+Usage: %s [option ...]
+
+Options:
+ -ppackage generate symbols file for package.
+ -Ppackagebuilddir temporary build dir instead of debian/tmp.
+ -elibrary explicitely list libraries to scan.
+ -vversion version of the packages (defaults to
+ version extracted from debian/changelog).
+ -clevelcompare generated symbols file with the
+ reference file in the debian directory.
+ Fails if difference are too important
+ (level goes from 0 for no check, to 4
+ for all checks). By default checks at
+ level 1.
+ -Ofile write to file, not .../DEBIAN/symbols
Bug#430367: Integrate support of a newer dpkg-shlibdeps working at the symbol level
On Sun, 01 Jul 2007, Frank Lichtenheld wrote: I would give Raphael commit rights to the repository with the understanding that he limits himself to the branch integrating his work for now (I really see no need for technical measures enforcing that, we are all grown-ups, right?) Sure, I have no problem with that. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#431597: dpkg-shlibdeps doesn't parse include in ld.so.conf
On Thu, 05 Jul 2007, Goswin von Brederlow wrote: FWIW, this is fixed in the new dpkg-shlibdeps that I'm preparing (which supports per-symbol dependencies). The code is in a branch on SVN: http://svn.debian.org/wsvn/dpkg/branches/dpkg-shlibdeps-buxy/scripts/?rev=0sc=0 So wait a bit until dpkg maintainers agree to merge the branch on the trunk. :-) Cheers, Could you extract just the include changes or is that to mangled together? I could but I see no hurry in fixing that right now. I'd rather work on getting my branch ready for integration. You can do it as well, it's not that complicated. There's a new function dedicated to (recursively) parse this file. It's called parse_ldso_conf and it's in scripts/modules/Shlibs.pm. You just need to integrate it in the main script. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#435126: dpkg-source please ignore vcs dirs for native packages too
tags 435126 + patch
thanks
Hello,
I agree with maks that it would be nice if dpkg-source excluded those
directories by default. Thus I made this small patch.
If Guillem or Frank are OK with this patch, I can apply it myself.
I tested it here and it works fine at least in the case of dpkg's git
repository.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
From 854f7973ba2ca50123b64ddc60adac04c61bde43 Mon Sep 17 00:00:00 2001
From: Raphael Hertzog [EMAIL PROTECTED]
Date: Thu, 2 Aug 2007 19:18:12 +0200
Subject: [PATCH] dpkg-source: exclude directories created by distributed VCS from a native tarball build
It's much more convenient to be able to start a build from the VCS tree
instead of having to make an export or similar. This is particularly true
with distributed VCS which tend to keep all their stuff in a single directory
at the root of the tree. Current list includes bzr/git/hg/darcs/arch.
---
scripts/dpkg-source.pl |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/scripts/dpkg-source.pl b/scripts/dpkg-source.pl
index 1ed1213..20c98fb 100755
--- a/scripts/dpkg-source.pl
+++ b/scripts/dpkg-source.pl
@@ -56,7 +56,8 @@ my %type; # used by checktype
my %filepatched; # used by checkdiff
my %dirtocreate; # used by checkdiff
-my @tar_ignore;
+my @tar_ignore = qw(--exclude=.git --exclude=.bzr --exclude=_darcs
+ --exclude=.hg --exclude={arch});
use POSIX;
use Fcntl qw (:mode);
--
1.5.2.4
Bug#281057: Ping!
Hello Egmont, On Thu, 16 Nov 2006, Egmont Koblinger wrote: During these 2 years no valuable comments arrived from any Debian/Dpkg developers. I wonder why... Isn't there anyone caring about this bug? (Is there anyone caring about Dpkg at all?) Or you simply lack developer resources? (Well, that could be an excuse for an unreproducible bug report or a bug report without a patch, but I feel I've done everything anyone could have done to locate and fix this bug; all you have to do is verify it and then apply the patch.) We clearly lack developers resources and the number of bugs accumulated on dpkg is so high, that's it's difficult to keep track of them. Guillem or Ian, can you look at the patches? The first one seems ok and the second one may need some adjustement depending on the value of instdir I guess... I haven't looked in details the values that it can have. If it's either empty or the chroot, then it's fine, otherwise it might need adjustment. If you check the bug archives of Debian, you'll see that I already posted several bug reports and patches (well, not very much, maybe a dozen) and some of them were successfully applied, making Debian a slightly better distro. Unfortunately this is not my first bugreport where I have to wait years for anyone to move his fingers. If you continue developing with this approach, all you'll reach is that I'm going to fix these bugs for myself and not send any feedback at all. It's not worth it for me to spend my time explaining the story if noone's listening to me. Is this what you want? I hope not... Please continue sending your patch and bug reports, even if they're not treated quickly, it's important to have them recorded. Hopefully one day we'll get more volunteers. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#432893: Processed: severity of 432893 is important
On Wed, 29 Aug 2007, Kurt Roeckx wrote: severity 432893 serious thanks On Wed, Aug 29, 2007 at 02:42:03AM +, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.7 severity 432893 important Bug#432893: dpkg: Failed install followed by failed remove results in installed state Severity set to `important' from `serious' Please explain why you think this is not a release critical bug. You seem to have gone and changed, mostly lowered, the severity of various bugs on packages. As far as I can see, you're not the maintainer of those packages. So I'm just going to set the severity of this one back. For the record, Philippe Cloutier alias Filipus Klutiero (and chealer on IRC) was already banned from the BTS control interface. I don't know if his ban has been lifted or if he uses another email. CCings BTS admins for info. Filipus, please stop changing severities without the consent of the maintainer. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#432893: Processed: severity of 432893 is important
Hi, On Tue, 11 Sep 2007, Filipus Klutiero wrote: I don't see why I should not change the severity of a report against a package I'm not maintaining if the severity looks incorrect and the maintainance team didn't state anything about the severity. If you were basing that on something, please let me know. Consider that changing severities of bug reports is not your business and they are not considered a positive contribution of your own. The release team will lower severities = serious if they are over-inflated, the maintainer can do so as well. If you believe a severity to be wrong, please state so in the bug log and let the maintainer change it if he wishes and that's it. You make us loose valuable time arguing on severities. I hope you can find some better way of contributing to the Debian project because your current stance on handling bug severities is not very much appreciated. In any case, considering what you wrote, I'll refrain from changing the severity of reports against dpkg, which means I will not downgrade this report even if Kurt does not answer timely. You're not in a position where you can request/expect timely responses. People have the right to ignore you because you're not the maintainer and they don't believe your contributions to be useful. As long as your contributions are NOT backed by some solid technical skills, this won't change. This doesn't apply only to dpkg but also to all Debian packages. If bug-triager is something that appeals to you, I'd suggest to concentrate on a single package and cooperate up-front with the maintainer and decide of a strategy to clean up the BTS. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#441904: dpkg: [update-alternatives]: Please add a machine-readable variant of --display
Hi, On Mon, 10 Sep 2007, Frank Küster wrote: We had to fix some older alternatives breakage from a package we took over, and used update-alternatives --display to see whether we needed to do anything. Unfortunately, # [EMAIL PROTECTED] update-alternatives --display xdvi.bin xdvi.bin - Status ist auto. Link verweist zur Zeit auf /usr/bin/xdvi-xaw.bin /usr/bin/xdvi-xaw.bin - Priorität 30 Gegenwärtig »beste« Version ist /usr/bin/xdvi-xaw.bin. # which is impossible to parse (at least not if we think about all the other languages). This showed up in #438551, and we fixed it by prepending LC_ALL=C to our call to u-a, but it would be nice if there was an interface to query update-alternative's status with respect to a particular alternative. Something which doesn't change with localization, and hardly with time (and if it does, gets an entry in NEWS.Debian). What about readlink /etc/alternatives/xdvi.bin ? Or did you specifically need the info about the status (auto or not)? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#423679: dpkg-dev: dpkg-shlibdeps fails when libraries of multiple architectures are in the path
On Sun, 13 May 2007, Sam Hartman wrote: Package: dpkg-dev Version: 1.13.25 Severity: normal I have an i386 system with both i386 and amd64 libraries in /etc/ld.so.conf. This is useful because it makes it easier to run amd64 binaries. Modern ld.so will just skip libraries of architecture that conflict with the executable. However, dpkg-shlibdeps runs objdump, which complains if the format is unrecognized. So, dpkg-shlibdeps always fails on my system because it finds /lib64/libc.so.6 before /lib/libc.so.6. Can you precise how we can more generally reproduce that? It doesn't seem to be reproducible with current unstable. 1/ First off it looks like amd64 binaries are nowadays recognized by i386's objdump... so your failure case might have disappeared. In fact, I tested with a powerpc library and objdump didn't fail on it either. 2/ Then I tried to put the powerpc libc first in my LD_LIBRARY_PATH and it looks like ld.so doesn't skip over it like you say. Instead I got failures like: /usr/bin/perl: error while loading shared libraries: /home/rhertzog/tmp/libc/lib/libdl.so.2: ELF file data encoding not little-endian Doing the same with an amd64 lib effectively works, but that means that the principle is not applicable to all arches... It's true that a failure of objdump -a will lead to the end of dpkg-shlibdeps. However I'm reluctant to remove the failure case now that objdump is apparently able to parse correctly more formats. So I'd suggest closing this bug. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#445852: dpkg-buildpackage: fails with perl errors
On Tue, 09 Oct 2007, Giovanni Mascellani wrote: All'incirca Mon, 8 Oct 2007 22:16:21 +0200, Frank Lichtenheld [EMAIL PROTECTED] sembrerebbe aver scritto: These don't look like perl errors, but like shell errors. Somehow the perl script gets executed as shell script. Do you have dpkg-cross installed? Hmm, but why does it happens? I have dpkg-cross installed, but I can't see what does this mean. Sorry, I'm not very expert with Perl! It means that dpkg-cross diverted /usr/bin/dpkg-buildpackage and installed its own copy of that file. That copy reuses the original dpkg-buildpackage by sourcing it, and thus making the assumption that's it's written in shell. That assumption has been broken by the latest upload. So this is really a dpkg-cross bug. See http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/54-dpkg-cross-2.0.0-fragility-expected!.html Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#440841: dpkg-dev: source package gpg verification doesn't restrict valid keys to debian-keyring
On Thu, 25 Oct 2007, Sami Liedes wrote: However, it still fails to do what you describe: The .dsc can be signed by *anyone* whose key I happen to have in my keyring, not only by the person in the Maintainer: field, without giving any clue to whose signature the .dsc has. I can't think what that's good for. Krhm. It seems I got ignored after first misunderstanding the intent of the programmer even if his code doesn't work. Even at the risk of being flamed at, I need to point out that this is still a very real security bug. apt purpots to verify something gpg-wise, but utterly fails. I guess we are lucky it's not very verbose about its attempt to verify so there's hope nobody trusts it, but that's just a partial defense. As I pointed out in my previous mail, the fact that a key exists in some user's public key ring simply does not imply any trust at all. Allowing anyone's valid signature in the .dsc, not only the maintainer's, is just plain broken behavior. Sorry, signature is about making sure you can identify who is the author of the source package. It's written nowhere than only DD should be able to sign source packages. It's not a security bug, it's a feature. You might want to convert this in a wishlist bug asking for a parameter where you can list keyrings to consider while checking the signature. But no more. I don't think the default behaviour will ever change. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#440841: dpkg-dev: source package gpg verification doesn't restrict valid keys to debian-keyring
On Thu, 25 Oct 2007, Sami Liedes wrote: Sorry, signature is about making sure you can identify who is the author of the source package. It's written nowhere than only DD should be able to sign source packages. No, but it fails to do that either. It doesn't verify that it's signed by the person in the Maintainer: field. It only verifies that it's signed by _anyone whose key is in the user's public key ring_, and it doesn't tell who. The maintainer is not necessarily the uploader of the package to Debian. So such a check doesn't make sense. If you want to make sure that the package has been generated by a person part of a precise set, you'd ll need to request the --keyring option as I already explained. That's not the feature you describe, and unless misunderstand something, I don't think the current behavior is good for anything. If you don't pollute your personal keyring, it can be useful. Otherwise yes the current behaviour is not of much use. Not being useful doesn't make it a security threat, though. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#20471: patch to check rdepends on unpack
On Tue, 30 Oct 2007, Ian Jackson wrote: tags 20471 + patch thanks I have prepared and tested a change that fixes this problem. It's available at http://www.chiark.greenend.org.uk/~ian/git/dpkg/dpkg.bugfixes/ as the branch bug20471 Please either attach a copy of the patch or use git.debian.org so that we can browse the changes via gitweb. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#432893: Bug#443334: policy: postinst abort-remove state.
On Tue, 30 Oct 2007, Ian Jackson wrote: Ian Jackson writes (policy: postinst abort-remove state.): prerm remove can be called only from unpacked, config-failed and installed. So Kurt is correct to say that policy is wrong to say it remains installed since the package might not be installed. However, the purpose of running the postinst is to (try to) put the package into installed. That's what the postinst always does. Idly thinking about this a day or two ago, it came to me that obviously we are all approaching this from the wrong angle. The point of running the postinst is to `put the package back into installed' as an error-unwinding task, to try to undo what was done earlier, on the presumption that the package was previously installed. The problem occurs when this presumption is not true. We have missed a possible response to this situation: not run the postinst at all. I think this would be much better. After all the surprise is that the package became installed. Redefining the postinst's semantics so that the package doesn't count as installed in this case is the wrong answer - the right answer is not to attempt to fix up the package in this case. If it was broken beforehand then there's no reason why an aborted removal should try to restore it to fully working state. Indeed! I have to say that I wasn't convinced by your refutal of the change done for #432893 because the diagnosis of the problem was clear... ending up with an installed package when you tried to remove it and it wasn't cleanly installed before was definitely wrong. So reverting the change without proposing an alternative fix doesn't seemed the right thing to do. Now the situation is a bit clearer IMO. Will you implement that change ? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#20471: patch to check rdepends on unpack
Hi, On Thu, 01 Nov 2007, Ian Jackson wrote: Raphael Hertzog writes (Re: Bug#20471: patch to check rdepends on unpack): I just did that locally and attached is the corresponding patch (created by git-format-patch for easy inclusion). I adjusted the commit log, the changelog and fixed some trailing spaces (that the pre-commit hook forbid me to commit). Where is your patch available as a public git branch ? bug20471 branch in git://git.debian.org/~rhertzog/dpkg.git http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=bug20471 On Thu, 01 Nov 2007, Ian Jackson wrote: Raphael Hertzog writes (Re: Bug#20471: patch to check rdepends on unpack): I just did that locally and attached is the corresponding patch (created by git-format-patch for easy inclusion). I adjusted the commit log, the changelog and fixed some trailing spaces (that the pre-commit hook forbid me to commit). Firstly, surely applying patches, rather than merging using the RCS, defeats the purpose of using the RCS ? As long as the serie of patches matches the series of commits, it doesn't make any difference for git. git-format-patch and git-am are precisely used to exchange changesets over email. (We come again to the same discussion: it's the content that matters not the precise id of the commit) Secondly, what is wrong with a bit of trailing whitespace ? Not much, except that we advise to enable the default pre-commit hooks and it forbids committing with trailing whitespaces (but the reason we suggest this is that it also forbids to commit conflict markers, and some translators managed to do this). And I got caught by this after cherry-picking your commit on top of the official master branch. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452013: Bug#452012: Path.pm exits subroutine via last
On Mon, 19 Nov 2007, Joey Hess wrote:
Exiting subroutine via last at /usr/share/perl5/Dpkg/Path.pm line 52.
On Mon, 19 Nov 2007, Joey Hess wrote:
dpkg-gencontrol -plibaa-bin -ldebian/changelog -isp
-Tdebian/libaa-bin.substvars -Pdebian/libaa-bin
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
dpkg-gencontrol: error: error occurred while parsing
Thansk for the report, both bugs have been fixed in the git repo.
First fix:
http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=7e9e9a72c90b7bf159a217d2009889f7f3984f98
Second one:
http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=8959140e24a056f5be53eb1563345c84baa8e0ef
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
severity 452022 wishlist thanks On Mon, 19 Nov 2007, Aurelien Jarno wrote: Package: dpkg-dev Version: 1.14.8 Severity: serious Huh ?! I know it's important for you, but that doesn't make it RC. problem: it potentially breaks all unofficial architectures, as the symbols for those architectures are not available on mole and may vary a bit. This is not a justification. This causes packages to fails to build in case of differences in the list of symbols, and will progressively break all unofficial architectures, even those that we want to *integrate as an official* architecture sooner or later. You're too pessimistic IMO. If the package has debian/package.symbols.arch files then it will not fail because it won't find a symbols file for the given architecture and will thus generate a brand new one (and the comparison will only find new symbols and it will not fail). It will only fail if the package provides a debian/package.symbols file (i.e. common to all architectures) and if symbols listed in that file disappear on non-official architectures. As already suggested, please ignore new or missing symbols on unofficial architectures and generate a new symbols file in that case (the current list of official architectures is: alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc). I won't harcode such a behaviour in dpkg. However what is doable is have an environment variable that will override the check level that that the package is using. Then you just have to make sure that the buildd of the unofficial arches define that environment variable. Does that seem reasonable? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
On Tue, 20 Nov 2007, Aurelien Jarno wrote: Even if it is not important for you that doesn't give you the right to ignore the problem as you did until now. We've had only one unconclusive IRC discussion, that's not really ignoring the problem. And I still believe, you're over exagerating the problem unless there are good reasons why exported API differ on unofficial architectures more than on official architectures (this could be the case for kfreebsd-*, I don't know). I guess it is also very important for the release team, because armel is supposed to be shipped with lenny in order to drop arm for lenny + 1. This architecture has to be kept in good shape. And we'll make sure to find a statisfying solution once you give me all the relevant infos to really understand how far reaching the problem is. debian/package.symbols.arch files then it will not fail because it won't find a symbols file for the given architecture and will thus generate a brand new one (and the comparison will only find new symbols and it will not fail). As already explained, this is the case. Mole doesn't provide symbols for unofficial architectures (which I can understand), so packages will never have the symbols file for unofficial architectures. Did you read what I wrote? I said it will not fail if the package provides only debian/*.symbols.arch. And note that I am speaking of real examples. Just try on libusb for example. On which architecture did you try? And how? Where do I have an account on an armel machine or a kfreebsd one? Note that this is a case where the API is supposed to be stable across architectures... can you show me what the differences are and why they are legitimate? Please show me the build-failure. I won't harcode such a behaviour in dpkg. However what is doable is have an environment variable that will override the check level that that the package is using. Then you just have to make sure that the buildd of the unofficial arches define that environment variable. Does that seem reasonable? Unfortunately I don't really like this idea because sbuild doesn't keep environment variables, and I don't really want to patch sbuild every time I want to update it instead of using the .deb package directly from debian-admin. This is surely a feature that could be added to sbuild. I asked neuro on IRC, I'm waiting his answer. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
On Tue, 20 Nov 2007, Aurelien Jarno wrote: Though it's worth asking ourselves if it would make sense to have an intermediary fallback between debian/*.symbols.arch and debian/*.symbols that would be debian/*.symbols.kernel. While it will fixes the problem due to the variation of the ABI across kernels, I am not sure that is the problem we will see the most. The most problematic variations, will happens on the same kernel, as it could be seen from bugs #441736, #429600 or #342084. Riku said in #441736: This is the same bug as on unixodbc, #429600, #342084. The issue is that some supplementary symbols are exported due to libtool working differently with C++ libs for apparently no good reasons. It is not really armel-specific (except for the fact that armel generated supplementary symbols that should be not exported according to the version script). In any case, having new symbols as is the case in those reports will not generate a failure with the default behaviour of dpkg-gensymbols unless the maintainer want those failures. So it's still not representative of failures that we're likely to get due to dpkg-gensymbols (unless many maintainers decide to increase the level of checks, which I doubt. Furthermore maintainers that do that are likely reactive maintainer that will quickly integrate changes needed for unofficial architectures). That said, we might want to have the possibility to flag private symbols in symbols file and have a mode where the disparition of private symbols doesn't cause a failure. Not sure about it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
On Tue, 20 Nov 2007, Aurelien Jarno wrote: The issue is that some supplementary symbols are exported due to libtool working differently with C++ libs for apparently no good reasons. It is not really armel-specific (except for the fact that armel generated supplementary symbols that should be not exported according to the version script). Please read the bug log again. The supplementary symbols are not the same on the different architectures, which causes some architectures to have missing symbols compared to some others. In which case it doesn't make sense to have a common symbols file and the problem is solved. In any case, having new symbols as is the case in those reports will not generate a failure with the default behaviour of dpkg-gensymbols unless the maintainer want those failures. Wrong. Some symbols are missing on armel: Error: incorrect soname libodbcinstQ.so.1, missing symbol: Base QGList::count() const In turn this is caused by a bug in libtool because that symbol should never have been exported on any arch... and on armel gcc was doing the right thing by inlining the function properly. So the initial problem is not armel-specific and I fail to see why we should ignore it when this failure enabled us to discover a bug in libtool. And if you want a permanent work-around, I already suggested the environment variable. I haven't seen any other better alternative yet. So it's still not representative of failures that we're likely to get due to dpkg-gensymbols (unless many maintainers decide to increase the level of checks, which I doubt. Furthermore maintainers that do that are likely reactive maintainer that will quickly integrate changes needed for unofficial architectures). As explained, it would have also failed on armel without increasing the level of checks. Because of a bug in libtool. I fail to see why we should be more lax just because libtool has bugs. That said, we might want to have the possibility to flag private symbols in symbols file and have a mode where the disparition of private symbols doesn't cause a failure. Not sure about it. That is not a correct solution. If you are able to list private symbols, better not export them instead of flagging them. Yes, but that's not something I control. In fact, if that's what you want, it's better to fail so that we can report problems to maintainers who will then prod upstream to implement a version script or similar. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
On Tue, 20 Nov 2007, Aurelien Jarno wrote: Please read the bug log again. The supplementary symbols are not the same on the different architectures, which causes some architectures to have missing symbols compared to some others. In which case it doesn't make sense to have a common symbols file and the problem is solved. Except that the problem appearing only on unofficial architectures, mole provide a common symbols file. That is where the problem lies. If we manage to have common symbol set for hurd-i386 and all the other arches, then I think it should be doable to have the same symbol set on unofficial architectures (or at least a superset). So the initial problem is not armel-specific and I fail to see why we should ignore it when this failure enabled us to discover a bug in libtool. Even if the bug is present in all architectures, its effects are only visible on armel. And maintainers do not care about unofficial architectures, so the package will simply FTBFS. The fix is to remove one private symbol from the debian/*.symbols file so that the lack of the symbol doesn't generate a failure. This fix is trivial and can be done easily in a porter NMU without risking to break everything. libtool is buggy, and that is even more true for older versions. And if you look at the archive, you will see that most of libraries use an old libtool version. Indeed, but maybe the implementation of proper symbols versioning in the debian package will trigger the required relibtoolizing... because hurd-i386 also needs it in many cases. The library has to fixed, but the job of porters is not to fix general problems with libraries, we already have a lot of work to do in other domains. But if porters doesn't fix this, the maintainer will simply ignore the problem, even if a bug report is sent. If we follow your logic, we shouldn't do anything because maintainers are not doing their work. While there's some truth in that, I just can't accept this conclusion. That said, we might want to have the possibility to flag private symbols in symbols file and have a mode where the disparition of private symbols doesn't cause a failure. Not sure about it. That is not a correct solution. If you are able to list private symbols, better not export them instead of flagging them. Yes, but that's not something I control. In fact, if that's what you want, it's better to fail so that we can report problems to maintainers who will then prod upstream to implement a version script or similar. I totally agree it's better to fail in such cases, but it is better to fails on all architectures, so that the problem is not just ignored. If only... there's no way for me to know if a symbol was intendend to be private or not. So I can't do this. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452226: dpkg-dev: new dpkg-shlibdeps breaks kdebase/experimental
reassign 452226 kdebase 4:3.96.0-1 retitle 452226 FTFBS due to missing dependency information thanks Hi, On Wed, 21 Nov 2007, brian m. carlson wrote: Package: dpkg-dev Version: 1.14.9 Severity: serious File: /usr/bin/dpkg-shlibdeps Justification: breaks unrelated packages (through build-essential) dpkg-shlibdeps has regressed. It now causes kdebase/experimental (3.96.0) to FTBFS with the following error messages: It has not regressed, it's just no more accepting things that are *wrong* like a public library without shlibs information. It has been announced quite some time in advance: http://lists.debian.org/debian-devel-announce/2007/09/msg4.html You have 3 solutions: - make sure that the lib has no SONAME so that it's identified by dpkg-shlibdeps as a private library - add --ignore-missing-info to the dpkg-shlibdeps call (you can pass this via dh_shlibdeps -- --ignore-missing-info) - add dependency information for this library (shlibs is not possible given that it has no version, however symbols files are possible) I would provide you with more information if it were clear from the error messages what name and version you were looking for. Ah, it seems that dpkg-shlibdeps assumes a certain format for SONAMEs, even though this shared object appears to be a private plugin specific to the konqueror package. It has no characteristic of a private plugin (it has a SONAME, it's in a public directory). Perhaps Dpkg::Shlibs::Objdump should instead determine that something is a public library if it has a certain SONAME format (as well as DYNAMIC), and instead punt if it doesn't. During the discussions on -devel, Steve Langasek suggested me to use the SONAME+DYNAMIC as the criterion to define a public library. Then extract_from_shlibs would not need that code, and although no shlibs file would be generated, it would at least not cause the build to fail. dpkg 1.14.7 says instead: dpkg-shlibdeps: warning: format of 'NEEDED libkdeinit4_keditbookmarks.so' not recognized dpkg-shlibdeps: warning: format of 'NEEDED libkdeinit4_kfmclient.so' not recognized dpkg-shlibdeps: warning: format of 'NEEDED libkdeinit4_konqueror.so' not recognized but it does not fail. It's not the lack of version that makes it fail. It's the lack of dependency information. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
On Tue, 20 Nov 2007, Riku Voipio wrote: On armel architecture, the symbol differences have usually been inlined softfloat symbols being exported. Which is additional symbols and would thus not break symbol checking (if I understood correctly). Yes. What is more worrying is the lack of unofficial arch information in mole. You're welcome to help make it available. mole is hosted on merkel, its source code is on a public repository. Jeroen seemed to think that it shouldn't be too difficult to do. Jeroen, can you look into it? Thus maintainers are not aware of issues with their packages on unofficial archs until someeon files a bug. That's true even for official arches in many cases. :) Anyway, I have nothing against adding support for unofficial arches on mole but the unofficial arches need to be made available in some coherent archive to not have to hardcode an URL for each unofficial arch. Be that gnuab.org or doorstep.debian.net, it doesn't matter much. Though it's worth asking ourselves if it would make sense to have an intermediary fallback between debian/*.symbols.arch and debian/*.symbols that would be debian/*.symbols.kernel. One option would be to use dpkg-architecture provided variables: I know that, it's precisely because it's easy to do that I suggested it. If it's useful, I'll implement it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
On Tue, 20 Nov 2007, Raphael Hertzog wrote: Unfortunately I don't really like this idea because sbuild doesn't keep environment variables, and I don't really want to patch sbuild every time I want to update it instead of using the .deb package directly from debian-admin. This is surely a feature that could be added to sbuild. I asked neuro on IRC, I'm waiting his answer. FWIW, Ryan is not interested to add this feature. During the discussion, we came to the conclusion that we should rather avoid using debian/*.symbols files in favor of debian/*.symbols.arch when the package maintainer is not sure if there's going to be differences in the set of symbols for all architectures. He can use #include to avoid duplicating the content too many times. That way unofficial arch won't use symbols files until the maintainer explicitely added support for them. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452262: dpkg-shlibdeps: Undefined subroutine main::capit.
On Wed, 21 Nov 2007, Sebastian Harl wrote: When running dpkg-shlibdeps (with the -d command line option) from debian/rules of one of my packages, it aborts with the following error message: Undefined subroutine main::capit called at /usr/bin/dpkg-shlibdeps line 62. Thanks for the report, it's fixed in the git repo and will be in 1.14.10. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452318: dpkg-dev: new dpkg-shlibdeps spews insane amount of warnings
On Wed, 21 Nov 2007, Sune Vuorela wrote: Package: dpkg-dev Version: 1.14.9 Severity: normal When building kdebase - after using quite some time to get --ignore-missing-info to go thru the build system, I now get a insane unreadable amount of warnings. The only thing it does is cluttering the build log and make it hard to try to locate anything important. Well, I wouldn't print them if they were not meant to be brought to the maintainer's attention? Please don't print the dpkg-shlibdeps: warning: symbol _ZN7QWidget7setMaskERK7QRegion used by debian/kdebase-bin/usr/lib/libkdeinit_kxkb.so found in none of the libraries. Somewhat like the other failures that you suffered from, if this was properly identified as a plugin (i.e. without SONAME), you wouldn't see it. There's another alternative: make sure the plugin is linked against libraries it really uses... fix the build system to pass the proper -lqt flag or whatever (I haven't checked which precise library provide this symbol). lines unless some --debug flag is added. I don't think that's an option for me. I might add some code to rate-limit the display of those messages... maybe after 5 for each binary it stops printing them unless some verbose flag is set. But they are meant to be displayed by default. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452339: dpkg-dev: fails to parse some shlibs files
On Thu, 22 Nov 2007, Aurelien Jarno wrote:
Package: dpkg-dev
Version: 1.14.9
Severity: serious
From my build log:
dh_compress -pkzenexplorer -X .dcl -X .docbook -X -license -X .tag -X .sty -X
.el
dh_fixperms -pkzenexplorer
dh_makeshlibs -pkzenexplorer
dh_installdeb -pkzenexplorer
dh_perl -pkzenexplorer
dh_shlibdeps -pkzenexplorer
dpkg-shlibdeps: failure: No dependency information found for libusb-0.1.so.4
(used by debian/kzenexplorer/usr/bin/kzenexplorer).
dh_shlibdeps: command returned error code 65280
make: *** [binary-predeb-IMPL/kzenexplorer] Error 1
But libusb-0.1.so.4 has a shlib file:
[volta:~]$ cat /var/lib/dpkg/info/libusb-0.1-4.shlibs
libusb-0.1 4 libusb-0.1-4 (= 2:0.1.12)
udeb: libusb-0.1 4 libusb-0.1-udeb (= 2:0.1.12)
I can't reproduce this on i386 while building kzenexplorer_0.6-1. I fear
that the lookup of the library on amd64 provides a name which is not the
real name but somehow a symlink lib like /usr/lib64/libusb-0.1-4 since
we're now respecting ld.so.conf properly with includes.
Can you apply the attached patch to dpkg-shlibdeps and re-run the build after
adding -v to dpkg-shlibdeps (use dh_slibdeps -- -v for this), that way
I'll have all the required information.
Please also paste me /etc/ld.so.conf and /etc/ld.so.conf.d/*
Thanks,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
diff --git a/scripts/dpkg-shlibdeps.pl b/scripts/dpkg-shlibdeps.pl
index 8902b94..800460d 100755
--- a/scripts/dpkg-shlibdeps.pl
+++ b/scripts/dpkg-shlibdeps.pl
@@ -100,7 +100,8 @@ foreach my $file (keys %exec) {
failure(_g(couldn't find library %s (note: only packages with .
'shlibs' files are looked into).), $soname)
unless defined($lib);
- $libfiles{$lib} = $soname if defined($lib);
+ $libfiles{$lib} = $soname;
+ print Library $soname found in $lib\n if $debug;
}
my $file2pkg = find_packages(keys %libfiles);
my $symfile = Dpkg::Shlibs::SymbolFile-new();
@@ -114,6 +115,7 @@ foreach my $file (keys %exec) {
# Empty package name will lead to consideration of symbols
# file from the package being built only
$file2pkg-{$lib} = [];
+ print No associated package found for $lib\n if $debug;
}
# Load symbols/shlibs files from packages providing libraries
@@ -327,6 +329,7 @@ Dependency fields recognised are:
sub add_shlibs_dep {
my ($soname, $pkg) = @_;
+print Looking up shlibs dependency of $soname provided by '$pkg'\n if
$debug;
foreach my $file ($shlibslocal, $shlibsoverride, @pkg_shlibs,
$admindir/info/$pkg.shlibs,
$shlibsdefault)
@@ -334,12 +337,14 @@ sub add_shlibs_dep {
next if not -e $file;
my $dep = extract_from_shlibs($soname, $file);
if (defined($dep)) {
+ print Found $dep in $file\n if $debug;
foreach (split(/,\s*/, $dep)) {
$dependencies{$cur_field}{$_} = 1;
}
return 1;
}
}
+print Found nothing\n if $debug;
return 0;
}
Bug#452339: dpkg-dev: fails to parse some shlibs files
On Thu, 22 Nov 2007, Aurelien Jarno wrote: No associated package found for /usr/lib/libusb-0.1.so.4 dpkg-shlibdeps: failure: No dependency information found for libusb-0.1.so.4 (used by debian/kzenexplorer/usr/bin/kzenexplorer). Looking up shlibs dependency of libusb-0.1.so.4 provided by '' Found nothing dh_shlibdeps: command returned error code 65280 What happened is: - kzenexplorer has an RPATH /usr/lib:/lib on amd64 (and not on i386) - the new dpkg-shlibdeps now support this directive correctly - thus it finds a symlink in /usr/lib/libusb-0.1.so.4 which has been created by ldconfig and which is not owned by any package (instead of finding the packaged symlink in /lib/libusb-0.1.so.4) So my diagnostic was not far from the truth. I supposed that I should try a dpkg -S on realpath(library) as fallback when I don't find an associated package. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452511: About dpkg-shlibdeps checks
[ CCing #452511 as I provide an explanation of why we shouldn't change back to --ignore-missing-info by default without careful consideration ] On Fri, 23 Nov 2007, Pierre Habouzit wrote: Damn I wanted to answer to that, and forgot: I don't think anyone wants a revert. I'd expect you to make lower the dpkg-shlibdeps expectations for a while, so that we can take our time to catalog every issues that it raise. If only things were as simple as that. Go read #452339 and understand that the new dpkg-shlibdeps fully respects any local ld.so.conf configuration, and any broken RPATH information in binaries. This means that because of unexpected local configuration, or because of bad RPATH, dpkg-shlibdeps might find a copy of the library that is not packaged (even in /usr/local/ [1]). If later on I don't find the dependency information because the library is not associated to any package, and if I silently ignore that information as you suggest it to me, we will have produced packages with missing dependencies. I'd rather be more strict and relax the rules as we identify cases where I have been too strict, than let people upload broken .debs during weeks and later discover that we have to scan the full archive to rebuild a bunch of them. Yes, the situation is not always as simple as it looks like. [1] BTW, should I just skip any directory matching ^/usr/local while trying to find the library used by a binary? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452577: dpkg-dev: dpkg-shlibdeps no longer optimizes dpkg --search usage
On Fri, 23 Nov 2007, Aaron M. Ucko wrote: dpkg-shlibdeps's latest incarnation (as of 1.14.8 and its experimental predecessors) introduces a performance regression: it runs dpkg --search once per executable or library being examined, rather than caching its results any fashion. As each call requires scanning every package's contents AFAICT, the resulting procedure can take a LONG time on systems with many packages installed. (It would be great if dpkg-query could itself run faster, but that's a separate issue.) Somehow I was thinking I had implemented a cache but I must have mixed up with something else. Thanks for the check! (At any rate, the rewrite at least resulted in much clearer and more readily patched logic.) I did my best to make it understandable compared to the old code. :) Could you please review and apply the attached patch (against 1.14.10) when you get a chance? Applied. But it doesn't give a huge performance boost. On a run on kdemultimedia, it saves 8 seconds out of 3m12. I think we could save much more by caching the Dpkg::Shlibs::Objdump::Object objects created by the line: my $id = $dumplibs_wo_symfile-parse($lib); But optimizing this part probably needs somewhat more care and is a bit less straightforward. I also wonder how much memory it would cost on big packages. But if you have some time to spend on it, I'll happily review a patch. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#439979: dpkg-dev: Please support removal of dpkg-cross diversions
user [EMAIL PROTECTED] clone 439979 -1 reassign 439979 dpkg-dev 1.14.5 reassign -1 dpkg-dev 1.14.5 retile 439979 dpkg-buildpackage: support cross-building by setting up the environment usertag 439979 dpkg-buildpackage retitle -1 dpkg-shlibdeps: support cross-building by scanning required directories usertag -1 dpkg-shlibdeps thanks On Tue, 28 Aug 2007, Neil Williams wrote: As outlined on the debian-dpkg lists, I've been testing the removal of the dpkg-cross diversions of dpkg-buildpackage and dpkg-shlibdeps during the rewrite of dpkg-cross and I now have two patches (slightly modified from the last ones posted to the list) that I would like to see in dpkg-dev as a beginning to a process to merge dpkg-cross back into dpkg. Okay, to make it easier to not loose track of this I properly reassigned this to dpkg-dev and split it in two issues: one for dpkg-buildpackage and one for dpkg-shlibdeps. Contrary to what Hector forwarded from you on -devel, the changes for dpkg-shlibdeps are relatively independant from the rest and since I've been doing the work on dpkg-shlibdeps I can review and merge a good patch of you. If you don't provide the patch, it'll take some more time but I'll get around to it sometime. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#453267: Bug#439979: dpkg-dev: Please support removal of dpkg-cross diversions
On Wed, 28 Nov 2007, Neil Williams wrote: I thought Guillem wanted to review the use of /usr/arm-linux-gnu/lib and /usr/arm-linux-gnu/include ? I do have perl code that solves the problem (used it to cross build GPE for Emdebian) involving adding search directories to LD_LIBRARY_PATH but I wasn't sure if Guillem was looking at a different implementation for those directories. I don't know what he plan to do, but for dpkg-shlibdeps's part it's clear that we need to fix the list of directories to search. So I'd be ready to apply a patch for this part. We can always tweak it later if needed. CC'ing debian-dpkg to find out. Guillem gets the BTS mail, no need for an explicit CC to the list. directory of symlinks or something else? Should Raphael and I work on a solution for dpkg-shlibdeps using LD_LIBRARY_PATH using the example below? The real fix doesn't change LD_LIBRARY_PATH but directly the official list of directories in scripts/Dpkg/Shlibs.pm and also directories listed in a LD_LIBRARY_PATH submitted by the package might need to be adjusted in a similar way (s|/usr/lib/|/usr/arch-triplet/lib/|) (provided that the on-the-fly conversion done by dpkg-cross converts all of what's below /usr/lib/ in packages in that way. That is what I'm using with the current dpkg-shlibdeps from 1.14.11 and AFAICT it is fine (providing that the cross paths are added to the standard paths and not replace them or perl gets confused). Care to elaborate on why perl gets confused ? In any case, since we would _not_ change LD_LIBRARY_PATH, it shouldn't be a problem. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#454057: please move dpkg-architecture
On Sun, 02 Dec 2007, Robert Millan wrote: Please could you move dpkg-architecture from dpkg-dev to dpkg ? It seems that because of this, it turns out that having the xorg meta-package installed requires dpkg-dev and hence binutils (because of type-handling). dpkg-architecture is perl and the goal is rather to get rid of perl in dpkg than the contrary. So my first vote is against this change. Why does xorg need dpkg-architecture ? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#453885: dpkg-shlibdeps changes can't track symlinks (/usr/lib, /usr/lib64)
On Sun, 02 Dec 2007, Matthias Klose wrote: The gcj-4.X packages fail to build with this version of dpkg: dpkg-shlibdeps: failure: no dependency information found for /usr/lib64/libgcj_bc.so.1 (used by debian/gcj-4.3/usr/lib/gcc/x86_64-linux-gnu/4.3/ecj1). dh_shlibdeps: command returned error code 512 Hum, /usr/lib64 is scanned after /usr/lib so it means that debian/gcj-4.3/usr/lib/gcc/x86_64-linux-gnu/4.3/ecj1 has a RPATH pointing to /usr/lib64 ... Is that true ? Is there a good reason for this ? I must say that I find the construction of the libgcj-bc package very fragile. It doesn't contain the library it's supposed to contain but only a symlink to the library which is contained in another package (libgcj8-1 on i386). This is done to build code which is independent of the libgcj soversion (see /usr/lib/gcj/). On the contrary, that is rather stable than fragile. What's the purpose of the package ? Avoiding to hardcode a version in build-depends ? Why can't you add this symlink+shlibs directly into libgcj8-1 ? Since the soname is different, it shouldn't create any problem. Why don't you ship the shlibs file in the package that provides the library ? On i386: libgcj8-1: /usr/lib/libgcj.so.81.0.0 If you had done that, you wouldn't not have had that failure because dpkg-shlibdeps fallbacks to the realpath of the library when the first match doesn't give back a package. It is shipped in the same package. libgcj_bc is a different library than libgcjX-Y which is used when building with -findirect-dispatch. You can better see this by looking at the libgcj_bc.so file in the libgcj8-dev package. I don't follow you: $ dpkg -L libgcj-bc /. /usr /usr/lib /usr/share /usr/share/doc /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/libgcj-bc /usr/lib/libgcj_bc.so.1 /usr/share/doc/libgcj-bc There's no library in that package. There's only the symlink and the shlibs. And the symlink points to a lib in libgc8-1: $ ls -al /usr/lib/libgcj_bc.so.1 lrwxrwxrwx 1 root root 12 2007-09-05 08:47 /usr/lib/libgcj_bc.so.1 - libgcj.so.81 $ dpkg -S /usr/lib/libgcj.so.81 libgcj8-1: /usr/lib/libgcj.so.81 Granted there's another file libgcj_bc.so file in /usr/lib/gcc/i486-linux-gnu/4.2/libgcj_bc.so but it seems unrelated for our case. Anyway, I think I'll modify the code to not report a lib found though an official symlink like those (instead I'll resolve the directory symlink beforehand). Expect a fix later this week. Thanks. Many upstream build systems do hardcode /usr/lib64 for x86_64, and /usr/lib32 is used as a synonym for /emul/something ... Resolving symlinks is not without problems however. Think of people with symlinks like /usr - /scratch/usr. So it's not easy to implement it properly. Ideally I should have some code that report all valid names that a file can have... but I don't know of any code doing that right now. You should consider fixing the problem of RPATH on your side too. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#453267: tested patch
On Tue, 04 Dec 2007, Neil Williams wrote:
+my @shlibdeps=();
+# ARCH for some awkward builds
+my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{ARCH}) if
($ENV{ARCH});
What's the role of $ARCH ? And why shall we consider that we're
crossbuilding only because this variable is set ?
+# host for normal cross builds.
+$crossprefix = $ENV{DEB_HOST_GNU_TYPE}
+if (($ENV{DEB_HOST_GNU_TYPE}) and ($ENV{DEB_HOST_GNU_TYPE} ne
$ENV{DEB_BUILD_GNU_TYPE}));
I think you should use the functions contained in Dpkg::Arch instead of
relying only the environment variables here...
use Dpkg::Arch qw(get_host_arch get_build_arch debarch_to_gnutriplet);
[...]
if (get_host_arch() ne get_build_arch()) {
$crossprefix = debarch_to_gnutriplet(get_host_arch());
}
+# target when building a cross compiler
+$crossprefix = $ENV{DEB_TARGET_GNU_TYPE}
+if (($ENV{DEB_TARGET_GNU_TYPE}) and ($ENV{DEB_TARGET_GNU_TYPE} ne
$ENV{DEB_BUILD_GNU_TYPE}));
Why would we need a special treatment of libs when creating a
cross-compiler? The cross-compiler runs on the build arch but is not linked
against any lib of the target arch so it doesn't need to scan the
directories of the target arch.
(I may be missing something here, but I don't see what currently)
+if ($crossprefix)
+{
+@shlibdeps = ( ${crossprefix}/lib, /usr/${crossprefix}/lib,
+/${crossprefix}/lib32, /usr/${crossprefix}/lib32,
+/${crossprefix}/lib64, /usr/${crossprefix}/lib64,
+/emul/ia32-linux/lib, /emul/ia32-linux/usr/lib );
+}
There's no need for a special escapment of the variables here.
/usr/$crossprefix/something works ok.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Bug#453885: dpkg-shlibdeps changes can't track symlinks (/usr/lib, /usr/lib64)
On Mon, 03 Dec 2007, Matthias Klose wrote: Hum, /usr/lib64 is scanned after /usr/lib so it means that debian/gcj-4.3/usr/lib/gcc/x86_64-linux-gnu/4.3/ecj1 has a RPATH pointing to /usr/lib64 ... Is that true ? Is there a good reason for this ? maybe not; but this kind of thing is hardcoded upstream, so you'll see this in other packages as well. I know we're not going to clean all RPATH magically, but it might still be nice to clean them progressively. :) I'll still fix the generic problem that dpkg-shlibdeps has been seeing. Since the soname is different, it shouldn't create any problem. no, then all the -gcj packages would depend on libgcj8-1, not on libgcj-bc. That's not true. You can perfectly put a shlibs file in libgcj8-1 that's going to generate a dependency on libgcj-bc for binaries linked to libgcj_bc.so.1. Please consider this approach. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#453267: tested patch
On Tue, 04 Dec 2007, Neil Williams wrote:
On Wed, 5 Dec 2007 00:01:22 +0100
Raphael Hertzog [EMAIL PROTECTED] wrote:
On Tue, 04 Dec 2007, Neil Williams wrote:
+my @shlibdeps=();
+# ARCH for some awkward builds
+my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{ARCH}) if
($ENV{ARCH});
What's the role of $ARCH ? And why shall we consider that we're
crossbuilding only because this variable is set ?
Not cross building - building a cross compiler.
Do we need to check twice for building a cross-compiler ? We don't need to
check $ARCH if we already have DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE,
no ?
gcc relies on $ARCH when preparing libgcc1-$arch-cross and other
toolchain libraries.
Fine, but I don't think that dpkg-shlibdeps has to check $ARCH at all.
Without the patch, I get:
dpkg-shlibdeps: failure: couldn't find library libc.so.6 needed by
debian/libgcc1-arm-cross/usr/arm-linux-gnu/lib/libgcc_s.so.1 (its RPATH
is '').
OK, but this means that you can't build a cross-compiler without having
the target libc6 ... which in theory you might not yet have since the
cross-compiler might be your only choice to compile that library.
Is that a real requirement or just a consequence of the fact that
dpkg-shlibdeps got more strict in the checks that it does ?
Maybe, the call to dpkg-shlibdeps should exclude files found below
/usr/$target/ ... this can be easily done with dh_shlibdeps.
+# host for normal cross builds.
+$crossprefix = $ENV{DEB_HOST_GNU_TYPE}
+if (($ENV{DEB_HOST_GNU_TYPE}) and ($ENV{DEB_HOST_GNU_TYPE} ne
$ENV{DEB_BUILD_GNU_TYPE}));
I think you should use the functions contained in Dpkg::Arch instead of
relying only the environment variables here...
Those variables are only defined in a cross build, not when building a
cross compiler or a toolchain.
Yes and what does that have to do with my remark ? Using the functions
instead of the variables is still nicer to detect a cross build.
My remark was generic and didn't concern the case of building a
cross-compiler at all.
Why would we need a special treatment of libs when creating a
cross-compiler? The cross-compiler runs on the build arch but is not linked
against any lib of the target arch so it doesn't need to scan the
directories of the target arch.
The cross compiler needs to build cross libraries that *are* called
when preparing the cross compiler itself.
Are called ? You mean that are analyzed by dpkg-shlibdeps ?
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Bug#454379: Processed: Re: Bug#454379: libzvbi0 -- Doesn't purge all files after piuparts Install+Upgrade+Purge test
retitle 454379 obsolete conffiles are not deleted on purge thanks Hi, On Wed, 05 Dec 2007, Debian Bug Tracking System wrote: reassign 454379 dpkg Bug#454379: libzvbi0 -- Doesn't purge all files after piuparts Install+Upgrade+Purge test Bug reassigned from package `libzvbi0' to `dpkg'. Christian, this has been hastily reassigned to dpkg. You should at least explain the problem... As far as I understand, the file /etc/default/libzvbi0 was in the sarge package but it's no more in the sid version of the package but the conf files stays even after the purge because: - dpkg doesn't remove conffiles on upgrade, it just mark them as obsolete (can be seen on dpkg -s package in the Conffiles field) - apparently even during purge it doesn't remove conffiles which are obsolete Can you confirm ? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#453267: tested patch
On Wed, 05 Dec 2007, Neil Williams wrote:
Raphael Hertzog wrote:
On Tue, 04 Dec 2007, Neil Williams wrote:
On Wed, 5 Dec 2007 00:01:22 +0100
Raphael Hertzog [EMAIL PROTECTED] wrote:
On Tue, 04 Dec 2007, Neil Williams wrote:
+my @shlibdeps=();
+# ARCH for some awkward builds
+my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{ARCH}) if
($ENV{ARCH});
What's the role of $ARCH ? And why shall we consider that we're
crossbuilding only because this variable is set ?
Not cross building - building a cross compiler.
Do we need to check twice for building a cross-compiler ? We don't need to
check $ARCH if we already have DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE,
no ?
My first patch did exactly that - and failed on building a cross
compiler. gcc needs dpkg-shlibdeps to take notice of $ARCH in the
preparation of libgcc1-$arch-cross and other libraries used in the
complete toolchain. It needs (and sets) DEB_TARGET_GNU_TYPE !=
DEB_BUILD_GNU_TYPE at other stages of the build.
If that's the case, I'd like to know if this is deliberate and really
required... can't the gcc package be consistent and always have both
DEB_TARGET_GNU_TYPE and DEB_BUILD_GNU_TYPE properly set ?
(Ccing [EMAIL PROTECTED] to have their opinion)
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Bug#454616: dpkg-dev: g++ links -lm by default, and dpkg-shlibdeps complains
On Thu, 06 Dec 2007, Colin Watson wrote: Perhaps dpkg-shlibdeps should ignore libm.so.6 for binaries also linked against libstdc++.so.*? Yeah, I agree. A fix has been committed to the git repo. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#453267: tested patch
On Sun, 09 Dec 2007, Neil Williams wrote:
I'm ok with a
supplementary specific check for building of a cross-compiler, but not
with a generic check like testing the ARCH environment variable.
OK, I have a solution for that - replace $ARCH with $GCC_TARGET.
I've tested with this change to the patch for scripts/Dpkg/Shlibs.pm
# GCC_TARGET for cross compiler builds
my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
($ENV{GCC_TARGET});
...
I went for ARCH before because, in the context of building a cross
compiler, ARCH is only set at certain times. GCC_TARGET is set at the
beginning and is present throughout the build.
If I understand you correctly, we can check for GCC_TARGET only and we
don't need to check DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE.
Is that correct and does that work ?
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Bug#455520: dpkg-dev: sort before in dependencies
On Mon, 10 Dec 2007, Adeodato Simó wrote: I can see how the recent change of sorting the Depends field can be useful. However, I would very much like to ask that if a package: Depends: foo (= 1.1), foo ( 1.2) that the final order is kept like that, because reading sequentially: Depends: foo ( 1.2), foo (= 1.1) feels a bit... inappropriate. Granted. I improved the sort algorithm to fix that. The fix is in the git repo, it will be in the next upload. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#457151: dpkg-dev -- should not reorder Build-Depends
On Thu, 20 Dec 2007, Kumar Appaiah wrote: Fine by me. But do you think this calls for a bug against those packages which unnecessarily depend on atlas due to this change? I can file wishlists against those, and they surely should not need atlas, as they have been without it earlier. It makes sense, at least as long as we have no way to differentiate the generic build requirement from the build requirement on official Debian buildd. It's still an issue that we need to tackle once but it's so low priority that I never managed to go forward with a proposition. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#457371: dpkg: please add the DEB_VARIANT build environment variable
On Sat, 22 Dec 2007, Simon Richter wrote:
the attached patch adds a new variable DEB_VARIANT to the build
environment, which can be used to build different binary packages out of
the same source package in different circumstances.
I like the idea of standardizing on a variable name to detect for which
distribution/variant we're building.
--- /tmp/CTGRa1SVPh/dpkg-1.14.12/scripts/dpkg-buildpackage.pl 2007-10-18
00:41:02.0 +0200
+++ /tmp/Zg4BEoCa5A/dpkg-1.14.12/scripts/dpkg-buildpackage.pl 2007-12-22
00:09:07.0 +0100
@@ -48,6 +48,7 @@
-usunsigned source.
-ucunsigned changes.
-aarch Debian architecture we build for (implies -d).
+ -VvariantDistribution variant we build for
-b binary-only, do not build source. } also passed to
-B binary-only, no arch-indep files. } dpkg-genchanges
-S source only, no binary files. }
@@ -106,6 +107,11 @@
my $diffignore = '';
my $binarytarget = 'binary';
my $targetarch = my $targetgnusystem = '';
+my $variant = debian;
+
+if (defined($ENV{'DEB_VARIANT'})) {
+ $variant = $ENV{'DEB_VARIANT'};
+}
IMO the default variant should be a variable imported from the Dpkg.pm
(scripts/Dpkg.pm) module much like we're doing for other variables like
$dpkglibdir and so on.
Otherwise it looks fine.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Bug#457739: /usr/bin/dpkg-gensymbols: dpkg-gensymbols doesn't grok #DEPRECATED ...# versions properly
On Tue, 25 Dec 2007, Pierre Habouzit wrote: -#DEPRECATED: 1.1.6# [EMAIL PROTECTED] 1.1.3 -#DEPRECATED: 1.1.6# [EMAIL PROTECTED] 1.1.3 +#DEPRECATED: 1.1.6-1# [EMAIL PROTECTED] 1.1.3 +#DEPRECATED: 1.1.6-1# [EMAIL PROTECTED] 1.1.3 [EMAIL PROTECTED] 1.1.3 [EMAIL PROTECTED] 1.1.3 [EMAIL PROTECTED] 1.1.3 Which should not yield a diff as 1.1.6-1 = 1.1.6 Indeed doko already noticed it and notified me. So it was fixed in git already: http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=261d067696bd54c87108c32957226bf9fbfcf35a Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#457784: dpkg-source: fails to build source package with -sp/-sk
On Tue, 25 Dec 2007, Philipp Kern wrote:
It seems to me that $origtargz is not set correctly, i.e. it's non-empty
only on some special codepaths, whereas it was initialised on
declaration before.
Indeed. I committed the patch attached. Feel free to try it and report if
there are any bad side-effects to this change.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
commit e1cc494b6e8811fd4fc9fed2a7d458ae8849ccdd
Author: Raphael Hertzog [EMAIL PROTECTED]
Date: Wed Dec 26 14:47:50 2007 +0100
dpkg-source: fix regression in the behaviour of options -sk -sK -sp -sP
Those options need the name of a tarball in $origtargz but this variable
was only set if -sa or -sA was used (or if a tarball was explicitely
listed on the command line). $origtargz is now again set at declaration
time if we can find a corresponding tarball. Also add some comments to
make this part of the code somewhat more understandable.
diff --git a/ChangeLog b/ChangeLog
index 497ba7e..5421f37 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2007-12-26 Raphael Hertzog [EMAIL PROTECTED]
+
+ * scripts/dpkg-source.pl: Provide a sane default $origtargz in all
+ cases when such a file exists.
+
2007-12-20 Raphael Hertzog [EMAIL PROTECTED]
* scripts/dpkg-shlibdeps.pl: Always consider the shlibs of the
diff --git a/debian/changelog b/debian/changelog
index a67755f..d962f66 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -35,6 +35,7 @@ dpkg (1.14.13) UNRELEASED; urgency=low
sure that the generated dependency is at least as strict as this one.
* Fix dpkg-gensymbols to not update version info of a deprecated symbol.
Closes: #457739
+ * Fix dpkg-source's behaviour with options -sk -sK -sp -sP. Closes: #457784
[ Guillem Jover ]
* Ignore the man pages when building without NLS support. Closes: #457673
diff --git a/scripts/dpkg-source.pl b/scripts/dpkg-source.pl
index 020a0c4..0640db4 100755
--- a/scripts/dpkg-source.pl
+++ b/scripts/dpkg-source.pl
@@ -416,7 +416,22 @@ if ($opmode eq 'build') {
my $origdir = $dir.orig;
my $origtargz;
+# Try to find a .orig tarball for the package
+my @origtargz = map { $basename.orig.tar.$comp_ext{$_} } ($compression,
@comp_supported);
+foreach my $origtar (@origtargz) {
+ if (stat($origtar)) {
+ -f _ || error(_g(packed orig `%s' exists but is not a plain file),
+ $origtar);
+ $origtargz = $origtar;
+ last;
+ } elsif ($! != ENOENT) {
+ syserr(_g(unable to stat putative packed orig `%s'), $origtar);
+ }
+}
+
if (@ARGV) {
+ # We have a second-argument orig-dir or orig-targz, check what it
+ # is to decide the mode to use
my $origarg = shift(@ARGV);
if (length($origarg)) {
stat($origarg) ||
@@ -447,27 +462,20 @@ if ($opmode eq 'build') {
$sourcestyle);
}
} elsif ($sourcestyle =~ m/[aA]/) {
- my @origtargz = map { $basename.orig.tar.$comp_ext{$_} }
($compression, @comp_supported);
- foreach my $origtar (@origtargz) {
- if (stat($origtar)) {
- -f _ || error(_g(packed orig `%s' exists but is not a plain
file),
- $origtar);
- $sourcestyle =~ y/aA/pP/;
- $origtargz = $origtar;
- last;
- } elsif ($! != ENOENT) {
- syserr(_g(unable to stat putative packed orig `%s'),
$origtar);
- }
- }
- if (!$origtargz) {
+ # We have no explicit orig-dir or orig-targz, try to use
+ # a .orig tarball first, then a .orig directory and fall back to
+ # creating a native .tar.gz
+ if ($origtargz) {
+ $sourcestyle =~ y/aA/pP/; # .orig.tar.ext
+ } else {
if (stat($origdir)) {
-d _ || error(_g(unpacked orig `%s' exists but is not a
directory),
$origdir);
- $sourcestyle =~ y/aA/rR/;
+ $sourcestyle =~ y/aA/rR/; # .orig directory
} elsif ($! != ENOENT) {
syserr(_g(unable to stat putative unpacked orig `%s'),
$origdir);
} else {
- $sourcestyle =~ y/aA/nn/;
+ $sourcestyle =~ y/aA/nn/; # Native tar.gz
}
}
}
Bug#457833: dpkg-shlibdeps: Doesn't find 32 bit libraries on amd64.
forcemerge 453885 457833 thanks On Wed, 26 Dec 2007, Kurt Roeckx wrote: When building wine on amd64 we get the following error: dpkg-shlibdeps: failure: no dependency information found for /usr/lib32/libxml2.so.2 (used by debian/libwine/usr/lib/wine/msxml3.dll.so). The problem is that /usr/lib32 is a symlink in the libc6-i386 package to /emul/ia32-linux/usr/lib where the library really is and that the dynamic linker's search path contains /usr/lib32/. So dpkg-shlibdeps doesn't find the package that has libxml2.so.2 in it. Can you retry with a dpkg snapshot taken from git ? git clone git://git.debian.org/git/dpkg/dpkg.git This was already reported in #453885 and should be fixed in the next upload. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#457964: please add common symbols for armel
On Thu, 27 Dec 2007, Riku Voipio wrote: __exidx_end and __exidx_start are arm eabi internal symbols from libgcc. I suggest blacklisting them in SymbolFile.pm: Thanks I added those symbols to the blacklist. Will be in dpkg-dev 1.14.15. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#458276: 'man dpkg-gensymbols dpkg-shlibdeps dpkg-source deb-symbols' typos: explicitely, overriden, versionned, neccessary, mininal and unversionned
On Sat, 29 Dec 2007, A. Costa wrote: Found some typos in '/usr/share/man/man1/dpkg-gensymbols.1.gz', '/usr/share/man/man1/dpkg-shlibdeps.1.gz', '/usr/share/man/man1/dpkg-source.1.gz', and '/usr/share/man/man5/deb-symbols.5.gz', see attached '.diff' files. Hope this helps... Thanks applied to the git repo. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#363323: dpkg-gencontrol: support multiple -T options
On Tue, 18 Apr 2006, Peter Eisentraut wrote: It would be useful in some cases if dpkg-gencontrol could read substitution variables from multiple files. So letting -T options accumulate rather than overwrite each other would be nice. What is this use case precisely? Given that you can add multiple substitution variables to the same file, I'm wondering why you'd prefer having multiple files. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#454036: dpkg-dev: dpkg-shlibdeps misses symbols and thus outputs false warnings
Hi, a long mail with some IRC discussion of the problem. On Sun, 02 Dec 2007, Bernhard R. Link wrote: dpkg-shlibdeps misses some symbols and thus prints warnings about not using symbols from a library even when doing so. [...] Thus those symbols are actually needed. (They are variables with the object class of the widget, referencing the actual used methods as function pointers, thus no other symbols from this library are used). | $ objdump -R debian/xbuffy/usr/bin/xbuffy | debian/xbuffy/usr/bin/xbuffy: file format elf32-sparc | | DYNAMIC RELOCATION RECORDS | OFFSET TYPE VALUE [...] | 00028a40 R_SPARC_COPY boxWidgetClass [...] | From what I can tell, it seems not to be visible with -w -f -p -T: They are visible: | $ objdump -w -f -p -T debian/xbuffy/usr/bin/xbuffy | debian/xbuffy/usr/bin/xbuffy: file format elf32-sparc | architecture: sparc:v8plus, flags 0x0112: | EXEC_P, HAS_SYMS, D_PAGED | start address 0x00011660 [...] | DYNAMIC SYMBOL TABLE: [...] | 00028a40 gDO .bss 0004 boxWidgetClass Except that the symbol is marked as contained in .bss section. Since I didn't know the precise role of that .bss section (documentation says it's for uninitialized data) I asked vorlon: vorlon buxy: 454036: definitely a dpkg-dev bug, data symbols should also be part of the list being checked [...] buxy the bug log has has the relevant objdump output on the binary vorlon right Q_ The problem being it's a copy relocation? vorlon yes, seems so vorlon Q_: do you know of any case when there should be an exported symbol in .bss that /isn't/ a copy relocation? Q_ I have no idea. vorlon ok vorlon buxy: my guess is that it's reasonable, at least as a next pass, to treat all .bss symbols you find as unresolved symbols vorlon if we find exceptions, we can sort those out after : But after some more reseach it appeared that it's not really reasonable: buxy vorlon: I don't think I can consider dynamic symbols marked contained in .bss as undefined... buxy vorlon: because I see for example on objdump -T /bin/ls: 0805b864 g DO .bss 0004 GLIBC_2.0 optarg and on libc6: 0011a6bc gDO .bss 0004 GLIBC_2.0 optarg buxy and undefined on both sides doesn't make sense vorlon buxy: ah, neat :) Q_ buxy: In libc6 it also has a relocation: R_X86_64_GLOB_DAT optarg buxy Q_: yeah, I was just checking that how should I interpret that ? vorlon right, so objdump -R and then you have to know which relocs indicate its undefined such as R_386_COPY and R_X86_64_COPY yay arch-specificity vorlon meaning what? $ objdump -T -p -m -f -R /lib/libc.so.6 |grep optarg 0014c3c4 gDO .bss 0004 GLIBC_2.0 optarg 00148fe8 R_386_GLOB_DAToptarg $ that's a dynamic reloc, no? at least, it shows up only under -R Q_ -R are the dynamic relocs. buxy so where is optarg defined ? :) Q_ GLOB_DAT seems to be saying something about the GOT. vorlon buxy: in libc.so.6, I guess... Q_ But I need to read it a few times before I understand I think. -- aike est parti (Quit: Leaving) Q_ buxy: .dynsym also contains an optarg@@GLIBC_2.2.5 vorlon seen how? buxy .dynsym is -T no ? but I don't see it Q_ I'm still a bit confused. But it's in .bss yes. I was looking with readelf, which shows: 1243: 0035cde0 8 OBJECT GLOBAL DEFAULT 33 optarg@@GLIBC_2.2.5 Where the 33 is .bss So, it's just an unintiliased global variable? noshadow Q_: sound reasonable for optarg buxy possibly, but what does it mean to have the symbols defined on both sides ? Q_ And the relocation is just something else that wants to use it. Q_ buxy: It's a copy relocation, like most variables. buxy and how I can differentiate it from the libXaw case where I need to find out that the binary really needs a symbol that comes from libXaw ? vorlon because xbuffy has the copy relocation, and libXaw doesn't the copy relocation, AFAIU, is what tells ld.so to go looking for the matching symbol Q_ What the copy relocation does it copy the pointer in your .bss Since it can't go thru a GOT or simular for it. buxy okay, so I should parse -R find symbols with R_*_COPY relocations and consider looking for a corresponding symbol in the libs vorlon well, that's my understanding, but I'm not sure how to parse what Q_ said Q_ buxy: I think you can look at all relocations. Q_ Hmm, or not. buxy Q_: I don't think I can reasonably do that... what does it mean for me to look for optarg while scanning libc6 ? :) Q_ buxy: I don't understand your last question. buxy Q_: currently the symbols like optarg with .bss in objdump -T are considered as defined and are thus output in DEBIAN/symbols files, so it means that I consider that libraries provide them Q_ I think you should just look for a defined symbol, like you do with the other undefined symbols. buxy except that I don't look in the current binary at all Q_ Oh, in case of a copy relocation it's not defined. edmonds awesome:
Bug#459359: dpkg-gensymbols: Provide a way to rely on symbol versioning when generating symbols files
Package: dpkg-dev Version: 1.14.14 Severity: wishlist User: [EMAIL PROTECTED] Usertags: dpkg-gensymbols Matthias Klose suggested me to support wildcards in symbols files. The idea is that the maintainer could then create the symbols files this way: libc.so.6 libc6 #MINVER# [EMAIL PROTECTED] 2.0 [EMAIL PROTECTED] 2.1 [EMAIL PROTECTED] 2.1.1 [EMAIL PROTECTED] 2.2 [...] dpkg-gensymbols would still generate full symbols files (with all symbols listed) but it would take the version from the matching wildcard. The downside is that when using this facility, dpkg-gensymbols has no way to detect symbols that have disappeared since previous version. I find this idea interesting to ease the work on very complex libs that have sane upstreams (like glibc or some gcc libs) but I'd like to have the opinion of others too. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#459359: dpkg-gensymbols: Provide a way to rely on symbol versioning when generating symbols files
On Sat, 05 Jan 2008, Steve Langasek wrote: [EMAIL PROTECTED] 2.2 [...] Perhaps to limit the possibilities of abuse, wildcards should only be supported in symbol names if there's an accompanying symbol version (with no wildcard expansion)? What do you mean exactly ? I don't plan to allow wildcards in symbol version. I'm not even sure if I want other wildcards except a single * in symbol names. One can always add the symbol manually in the file and still make use of wildcards for the remaining symbols. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#205011: dpkg-dev: dpkg-source fails on NFS
On Tue, 12 Aug 2003, Peter Karlsson wrote: Don't use 'soft'. It's broken. Removing it makes no difference. The build still fails. To ensure it wasn't something weird with the build paths, I copied the files to another directory (still NFS), and the build still fails. If I copy the files to a local directory, the build succeeds. Peter, is this something that you can still reproduce ? Looking at the bug log, it really seems like a NFS bug or something very specific to your configuration. I don't really see what dpkg-source could do that that would lead to a failure on NFS... Please close the bug if you can't reproduce it anymore. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#31352: Should be marked as wontfix?
On Mon, 07 Jan 2008, Benjamin M. A'Lee wrote: Package: dpkg Followup-For: Bug #31352 Since the Debian project apparently intends to continue distributing non-free software, should this bug be marked as wontfix? Added to this is the fact that an APT frontend generally makes no assumptions about whether something is free or not (consider a third-party repository, which may contain non-free packages but not conform to the Debian archive's naming convention), and also the fact that dselect just isn't very widely used any more anyway. I'm not sure it needs a wontfix though. I see two answers to this bug: - make sure that unknown packages are not displayed as Recommends/Suggests in dselect. That way when non-free is disabled, the user doesn't see them. - make sure that the Enhances: field is properly supported by dselect so that packages can use a reversed relationship to avoid speaking of the non-free part within the free part Although I agree that it's largely irrelevant to focus on dselect nowadays. The same principle should be used in aptitude and apt for instance. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#31352: Should be marked as wontfix?
On Mon, 07 Jan 2008, Christian Perrier wrote: Since the Debian project apparently intends to continue distributing non-free software, should this bug be marked as wontfix? The point is not even wanting to distribute non-free software or not. Even if Debian wasn't distributing non-free software (which is highly debatable), tools have no reason to blacklist repositories that do. Our priorities are our users blah blah blah. Of course, blacklisting repositories is not something acceptable. However, before closing this bug, it makes sense to verify that dselect doesn't show packages in Suggests: or Recommends: if they don't exist according to its list of packages. That way, when non-free is not used, non-free packages are not shown, which seems to be the right behaviour. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#460037: Upgrade to dpkg 1.14.15 breaks dpkg-dev 1.14.14 but doesn't conflict
forcemerge 459815 460037
thanks
On Thu, 10 Jan 2008, Devin Carraway wrote:
Package: dpkg
Version: 1.14.15
Severity: normal
On upgrading to dpkg 1.14.15 without upgrading dpkg-dev (APT held it
back because of the implied install of lzma), package builds began
failing thusly:
dpkg-source -b quelcom-0.4.0
compression is not defined in %Dpkg::EXPORT_TAGS at /usr/bin/dpkg-source
line 6
main::BEGIN() called at /usr/share/perl5/Dpkg.pm line 6
eval {...} called at /usr/share/perl5/Dpkg.pm line 6
Can't continue after import errors at /usr/bin/dpkg-source line 6
BEGIN failed--compilation aborted at /usr/bin/dpkg-source line 6.
dpkg-buildpackage: failure: dpkg-source -b quelcom-0.4.0 gave error exit
status 255
... on explicitly upgrading dpkg-dev also, dpkg-source worked again.
Already reported, merging bugs.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Bug#433477: dpkg-gencontrol -v fails to set ${binary:Version}
On Tue, 17 Jul 2007, Stephen Gildea wrote:
When using the -v flag of dpkg-gencontrol to set the version number
of the binary package being built, the subst variable binary:Version
fails to be set correctly. Instead of getting the value specified with
the -v, it gets the version of the source.
It is useful to have an accurate binary:Version when you want to have
the -dev package depend on the library (= ${binary:Version}).
It's not necessarily as evident as you make it look like. Usage of -v is
only required when the version of the binary package doesn't match the
version of the source package... and when you use ${binary:Version} you
want to refer to the version of another binary package (ie not the one
currently handled by dpkg-gencontrol) and why would you assume that the
other binary package shares the same version than the package currently
treated ? It might well be that the other binary package shares the same
version as the source package.
Though, given the use cases we have for those variables and given the
official definition of that variable in deb-substvars(5), I think this
change should probably be done.
Other opinions are welcome of course...
Can you tell us for which package you needed this change?
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Bug#457741: Bug#460158: zsh-doc would not install
On Thu, 10 Jan 2008, Clint Adams wrote: On Fri, Jan 11, 2008 at 12:35:57AM +0100, arno renevier wrote: zsh-doc upgrade did not work today. I tried to uninstall, and reinstall, and it looks like package is uninstallable. Here is the output I get with aptitude install zsh-doc: This is bug #457741 on dpkg. I haven't investigated at all and I'm in no way an expert concerning info files. But from what I've read, I must say that I'm not yet sure that it's a bug in dpkg... Is there a real standard on what an info file should look like ? Or are we at the mercy of every output change of the info file generator ? I'd gladly fix install-info (until we manage to get rid of it that is :)) if someone could point me to relevant information. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#460435: dpkg-parsechangelog man page is out of date
Package: dpkg-dev User: [EMAIL PROTECTED] Usertags: dpkg-parsechangelog The merge of the parsechangelog branch has added several features to the program (see its usage screen) but they are not yet documented in dpkg-parsechangelog(1). It's even more needed since one of the option refer to the man page for further details: --format outputformat see man page for list of available output formats, defaults to 'dpkg' for compatibility with dpkg-dev Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#459359: dpkg-gensymbols: Provide a way to rely on symbol versioning when generating symbols files
On Sun, 13 Jan 2008, Matthias Klose wrote: afaiu the rationale for having symbols files was to get smoother dependency information for shared libraries. This still can be done with the wildcard approach. The check of dropped symbols could be done by maintaining a database of symbol files for each package separate of the package, and then check if a new upload drops symbols from a shared library. An external check is not interesting as it wouldn't prevent an upload of a bad package. But I can live with the lack of such a check given the premise that a library with versioning probably has a sane upstream. :) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#433290: dpkg: /usr/bin/man not found
On Wed, 18 Jul 2007, Raphael Hertzog wrote: $ dpkg -S /usr/bin/editor non-packaged symlink to /etc/alternatives/editor: /usr/bin/editor non-packaged symlink to /usr/bin/vim: /etc/alternatives/editor non-packaged symlink to /etc/alternatives/vim: /usr/bin/vim non-packaged symlink to /usr/bin/vim.full: /etc/alternatives/vim vim-full: /usr/bin/vim.full I just implemented this. Please find the patch attached. I should add that applying this patch will break dpkg-shlibdeps which parses the output of dpkg -S. So if it's ever applied, dpkg-shlibdeps needs to be fixed at the same time (and a proper Breaks needs to be added to dpkg). Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#461247: dpkg: update-alternatives --test doesn't work as advertised
On Thu, 17 Jan 2008, Toby Speight wrote: Package: dpkg Version: 1.14.7 Severity: important File: /usr/sbin/update-alternatives /[ update-alternatives --help ] | Options: | --test don't do anything, just demonstrate. \ But when I tried using --test to check my --remove-all command, I got no output, and I discovered that the remove-all had actually been performed. Luckily, I had got my command right... Confirmed: $ grep testmode scripts/update-alternatives.pl my $testmode = 0; $testmode= 1; So it looks like this never got implemented... this was already the case in dpkg 1.1.4 in 1996 (this is as far as I can go in the history). Thus I suggest to simply remove that option altogether from the script and the manual page. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#454628: Processed: forcibly merging 330256 454628
On Fri, 18 Jan 2008, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.13 forcemerge 330256 454628 Bug#330256: delete obsolescent not-locally-changed conffiles Bug#454628: obsolete conffiles are not deleted on purge Forcibly Merged 330256 454628. Note that while both are probably tightly related, they are not exactly the same problem. The first is speaking of removing conffiles on upgrade when they would be marked obsolete if the conffile is unmodified... and the second speaks of removing those obsolete files (modified or unmodified doesn't matter here, though if the first is fixed, we would only have modified files here) on purge. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#281057: Rebased patches
Hello,
FWIW I rebased the patchs. Please find them attached. It looks like 2 pretty
minor bugfixes that should be safe to apply.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
From fb03c754185dfb50c34b6863ed5060e3d0a78490 Mon Sep 17 00:00:00 2001
From: Egmont Koblinger [EMAIL PROTECTED]
Date: Thu, 1 Nov 2007 16:17:12 +
Subject: [PATCH] Fix a bug in configuration file handling where dpkg didn't respect the --root argument
* src/processarc.c: lstat correct conffile path even with --root.
Previously we would incorrectly ignore --root here. Closes: #281057
---
src/processarc.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/processarc.c b/src/processarc.c
index 1550414..cbad9ba 100644
--- a/src/processarc.c
+++ b/src/processarc.c
@@ -60,7 +60,7 @@ void process_archive(const char *filename) {
static char *cidirbuf = NULL, *reasmbuf = NULL;
static struct fileinlist *newconffiles, *newfileslist;
static enum pkgstatus oldversionstatus;
- static struct varbuf infofnvb, fnvb, depprobwhy;
+ static struct varbuf infofnvb, fnvb, cfnvb, depprobwhy;
static struct tarcontext tc;
int c1, r, admindirlen, i, infodirlen, infodirbaseused, status;
@@ -670,7 +670,12 @@ void process_archive(const char *filename) {
for (cfile= newfileslist; cfile; cfile= cfile-next) {
if (!cfile-namenode-filestat) {
cfile-namenode-filestat= nfmalloc(sizeof(struct stat));
- if (lstat(cfile-namenode-name, cfile-namenode-filestat)) {
+ varbufreset(cfnvb);
+ varbufaddstr(cfnvb,instdir);
+ varbufaddc(cfnvb,'/');
+ varbufaddstr(cfnvb,cfile-namenode-name);
+ varbufaddc(cfnvb,0);
+ if (lstat(cfnvb.buf, cfile-namenode-filestat)) {
if (!(errno == ENOENT || errno == ELOOP || errno == ENOTDIR))
ohshite(_(unable to stat other new file `%.250s'),
cfile-namenode-name);
--
1.5.3.8
From 88605d1adc515e052c7f7b29ff45b79925bb3343 Mon Sep 17 00:00:00 2001
From: Ian Jackson [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 21:19:36 +0100
Subject: [PATCH] * src/processarc.c (process_archive): Fix incorrect sizeof in a memset call.
---
src/processarc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/processarc.c b/src/processarc.c
index cbad9ba..ac48208 100644
--- a/src/processarc.c
+++ b/src/processarc.c
@@ -680,7 +680,7 @@ void process_archive(const char *filename) {
ohshite(_(unable to stat other new file `%.250s'),
cfile-namenode-name);
memset(cfile-namenode-filestat, 0,
- sizeof(cfile-namenode-filestat));
+ sizeof(*cfile-namenode-filestat));
continue;
}
}
--
1.5.3.8
Bug#20471: Rebased patch
FWIW, I just rebased Ian's patch and fixed the small conflict. It only
needs some further tweaking for the 0 = NULL changes in theory.
(But I did no tests by myself)
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
From 01738a918c6ec921e93df16bddf86ef389008641 Mon Sep 17 00:00:00 2001
From: Ian Jackson [EMAIL PROTECTED]
Date: Tue, 30 Oct 2007 19:50:06 +
Subject: [PATCH] Check dependencies _on_ the package we're to upgrade. Closes: #20471.
This ensures that the new package will (when it is configured)
satisfy the current setup. We don't mind already-broken dependencies.
Some additional useful comments about dependencies in processarc.c.
---
src/archives.c | 49 +++
src/archives.h |2 +
src/depcon.c | 17 +++
src/processarc.c | 56 +++--
4 files changed, 112 insertions(+), 12 deletions(-)
diff --git a/src/archives.c b/src/archives.c
index 60ee2d5..c96cbc2 100644
--- a/src/archives.c
+++ b/src/archives.c
@@ -1059,6 +1059,55 @@ void check_conflict(struct dependency *dep, struct pkginfo *pkg,
return;
}
+static void cu_rdepends_istobe(int argc, void **argv) {
+ struct pkginfo *pkg= argv[0];
+ assert(pkg-clientdata-istobe == itb_normal);
+ pkg-clientdata-istobe= itb_installnew;
+}
+
+void check_rdepends(struct dependency *dep, struct pkginfo *pkg,
+const char *pfilename) {
+ static struct varbuf whynot;
+ int originally, afterwards;
+
+ /* Was this dependency previously satisfied ? If not we don't worry
+ * if it's not going to be satisfied, either. But we count it as
+ * having been previously satisfied even if it technically isn't
+ * because a satisfying package is only unpacked. That avoids
+ * accidentally permanently breaking the dependency just because the
+ * satisfying package happens not to be configured for some reason
+ * (eg because you have just unpacked the good version but haven't
+ * yet configured it).
+ */
+ assert(pkg-clientdata-istobe == itb_installnew);
+ pkg-clientdata-istobe= itb_normal;
+ push_cleanup(cu_rdepends_istobe,~0, 0,0, 1,(void*)pkg);
+ originally= depisok(dep,whynot,0,1);
+ pop_cleanup(ehflag_normaltidy);
+
+ if (!originally) {
+varbufaddc(whynot,0);
+debug(dbg_depcon, disregarding rdepends; dependency already
+ broken:\n %s, whynot.buf);
+return;
+ }
+
+ afterwards= depisok(dep,whynot,0,1);
+ if (afterwards)
+return;
+
+ varbufaddc(whynot,0);
+ fprintf(stderr, _(dpkg: %s containing %s breaks existing dependency:\n%s),
+ pfilename, pkg-name, whynot.buf);
+ if (!(fc_depends ||
+ ignore_depends(dep-up) ||
+ ignore_depends(pkg))) {
+ohshit(_(existing dependency problem - not installing %.250s),pkg-name);
+fprintf(stderr, _(dpkg: warning - ignoring
+ existing dependency problem!\n));
+ }
+}
+
void cu_cidir(int argc, void **argv) {
char *cidir= (char*)argv[0];
char *cidirrest= (char*)argv[1];
diff --git a/src/archives.h b/src/archives.h
index 5696c19..2824f2e 100644
--- a/src/archives.h
+++ b/src/archives.h
@@ -67,6 +67,8 @@ void check_conflict(struct dependency *dep, struct pkginfo *pkg,
const char *pfilename);
void check_breaks(struct dependency *dep, struct pkginfo *pkg,
const char *pfilename);
+void check_rdepends(struct dependency *dep, struct pkginfo *pkg,
+const char *pfilename);
struct fileinlist *addfiletolist(struct tarcontext *tc,
struct filenamenode *namenode);
diff --git a/src/depcon.c b/src/depcon.c
index 30e5936..4595326 100644
--- a/src/depcon.c
+++ b/src/depcon.c
@@ -341,12 +341,19 @@ int depisok(struct dependency *dep, struct varbuf *whynot,
switch (provider-up-up-clientdata-istobe) {
case itb_installnew:
-/* Don't pay any attention to the Provides field of the
- * currently-installed version of the package we're trying
- * to install. We dealt with that by using the available
- * information above.
+/* The Provides field of the currently-installed version
+ * of the package we're trying to install doesn't really
+ * help, but we should at least mention it. We dealt with
+ * the possibility that the to-be-installed version would
+ * help when we checked the available information, above.
*/
-continue;
+sprintf(linebuf, _( %.250s %.250s provides %.250s
+ but is to be supplanted.\n),
+ provider-up-up-name,
+ versiondescribe(provider-up-up-installed.version,
+vdew_nonambig),
+ possi-ed-name);
+break;
case itb_remove:
sprintf(linebuf, _( %.250s provides %.250s but is to be removed.\n),
provider-up-up-name,
Bug#445552: dpkg-buildpackage should systematically check build-deps before calling clean
On Sun, 07 Oct 2007, Frank Lichtenheld wrote: On Sat, Oct 06, 2007 at 09:17:21PM +0200, Loïc Minier wrote: 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. This behaviour is as old as dpkg-checkbuilddeps itself (see cf5d2919f686a15e8e623130b74af3ba2428fbeb in git). Changing the behaviour would obviously be correct, the question is whether it would actually be better. Do we have any idea of how many packages/services actually use dpkg-buildpackage -S ? I'm leaning towards correctness if it doesn't break too many stuff. Alternatively, we could make it display a warning and not actually exit. And this warning can itself warn that in the future it might fail at that point if -d is not passed. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#354999: setting package to dpkg dpkg-dev dselect, tagging 354999
Hi, On Fri, 18 Jan 2008, Justin Pryzby wrote: On Fri, Jan 18, 2008 at 08:38:03AM +0200, Guillem Jover wrote: tags 354999 + pending What change are you making? I just checked (after realizing that my http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=925bf488839ed0442700d80c0df681c34bf2ec87 It's the --help output that has been clarified. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#461327: important priority too high for dselect
On Thu, 17 Jan 2008, Joey Hess wrote: Package: dselect Version: 1.14.7 Severity: normal Tags: d-i dselect's priority was recently dropped from required to important (#452652), but important is still a much-inflated priority (so is standard -- optional would be ok). dselect is not the kind of core unix tool that policy defines as candidates for important. We have changed that to optional in the git repo. Did you also open a bug on ftpmaster's side? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#229357: Can we require build-arch/indep targets for lenny?
On Sat, 13 Oct 2007, Frank Lichtenheld wrote: 1) Build-Options field As pointed out this doesn't scale very well and there is no real way to make it default behaviour one day. This would be the way to go though if it only needs to be specified for few packages (either because we think that few packages actually need build-arch support or because of the solution I propose below, combining it with autodetection). IMO combining Build-Options and Standards-Version could be enough to get the best of both worlds. Use Build-Options to declare that the package supports some should rules of the policy but also auto-set some flags based on the version of the policy: if it's greater than the version which changed a rule in a must, then we define the corresponding flag. That way maintainers don't have to carry dozen of options indefinitely. I would be interested to gather some input from the interested persons regarding their exact position. I think the following questions should give us a good understanding or their position: (want == 'I want it and I also think it would be possible to do') 1) Do you want to change sbuild to actually respect policy? Yes. 1a) (SKIP if 'no' to 1) Before lenny's release? I don't mind. 3) Do you want for all packages to support build-arch in the nearer future (longest lenny+1) [== policy 'must']? 4) (SKIP if 'yes' to 3) In the farer future? I think it makes sense in the long term, yes. 5) Do you think autodetection can work and should be used? I must say I'm not very convinced by the various tricks tried and suggested. That said I wouldn't oppose all of them either. 6) (SKIP if 'yes' to 5) Do you think that autodetection can work and should be used, if packages would have the ability to override it if they know they get detected wrong? Seems reasonable, but you still have to let them declare if they support the target build-arch if they declare skip-auto-detection. :-) So basically the process would be: - if Build-Options contains build-arch, call build-arch/indep - unless Build-Options contains skip-auto-detection (or whatever name we come by), do an auto-detection and call build-arch/indep - otherwise you have to call build After considering all the arguments I believe that the best solution would be to try to implement autodetection _and_ support Build-Options to give maintainers the ability to override it. Build-Options is simply the easiest and best-working possibility, but for good behaving packages it should not be neccessary. And I strongly believe that after lenny's release dpkg-buildpackage should start to check the 'correct' build-dependencies according to policy (i.e. requiring b-d-i if build-arch is not supported). I would volunteer to implement the solution I propose (in the near future) if there are enough supporters. Ack from me at least. It's time to take a decision here. First step is to add the Build-Options support IMO. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#355654: dpkg-buildpackage to be able to override /usr/bin/make -f in debian/rules
Hi,
On Tue, 07 Mar 2006, Davor Ocelic wrote:
A simple patch to allow this behavior is attached. It adds the -M
option which should be used like say:
dpkg-buildpackage -M'/usr/local/bin/make -f'
I didn't like this intermediary command. What you really wanted to do is
not use debian/rules as build command but a custom command that is
/usr/local/bin/make -f debian/rules.
On Sun, 26 Aug 2007, Robert Millan wrote:
I'm attaching an updated version of Davor's patch (against 1.14.5).
Note that this allows to do very useful things such as:
dpkg-buildpackage -B -rfakeroot -Mmake -j `getconf _NPROCESSORS_ONLN` -f
We have the -j command now, so it's much less useful. Still I have created
another patch that implements what I explained above: it offers a -R
option to replace debian/rules by whatever you want.
(the other patches were meant for the old shell version of
dpkg-buildpackage anyway)
Frank, any comments or is it safe to commit?
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
From 1b77732a7ab316ca7d71f8db62b5079aa5915adc Mon Sep 17 00:00:00 2001
From: Raphael Hertzog [EMAIL PROTECTED]
Date: Sat, 19 Jan 2008 21:53:18 +0100
Subject: [PATCH] dpkg-buildpackage: add a new -R option and allow parameters in -r
* scripts/dpkg-buildpackage.pl: Add a new -R option to be able to replace
debian/rules by something else. The replacement command can contain
parameters (and thus spaces). Fix -r option to also accept parameters.
* man/dpkg-buildpackage.1: Document the new option and the changed
behaviour of -r.
---
man/dpkg-buildpackage.1 | 20 +---
scripts/dpkg-buildpackage.pl | 26 +++---
2 files changed, 28 insertions(+), 18 deletions(-)
diff --git a/man/dpkg-buildpackage.1 b/man/dpkg-buildpackage.1
index 2a84119..e0a16b7 100644
--- a/man/dpkg-buildpackage.1
+++ b/man/dpkg-buildpackage.1
@@ -117,24 +117,30 @@ command it executes with
if one has been specified. Otherwise, if none has been specified,
\fBfakeroot\fP will be used by default, if the command is present.
.I gain-root-command
-should be the name of a program on the
+should start with the name of a program on the
.B PATH
and will get as arguments the name of the real command to run and the
arguments it should take.
.I gain-root-command
-should not contain spaces or any other shell metacharacters.
-.\ what happens, if it contains spaces? (hs)
+can include parameters but no shell metacharacters.
.I gain-root-command
might typically be
.BR fakeroot , sudo , super or really .
.B su
-is not suitable, since it requires a
-.B \-c
-option to run a command and even then it can only invoke the user's
-shell with
+is not suitable, since it can only invoke the user's shell with
.B \-c
instead of passing arguments individually to the command to be run.
.TP
+.BI \-R rules-file
+Building a Debian package usually involves invoking
+.B debian/rules
+as a command with several standard parameters. With this option it's
+possible to use another executable as rules file to build the package.
+Alternatively it can be used to execute the standard rules file with
+another make program (for example by using
+.B /usr/local/bin/make -f debian/rules
+as \fIrules-file\fR).
+.TP
.BI \-p sign-command
When
.B dpkg\-buildpackage
diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index a841e3d..2c8911f 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -38,6 +38,7 @@ Usage: %s [options ...]
Options:
-rgain-root-command
command to gain root privileges (default is fakeroot).
+ -Rrules rules file to execute (default is debian/rules).
-psign-command
-d do not check build dependencies and conflicts.
-D check build dependencies and conflicts.
@@ -86,7 +87,8 @@ sub testcommand {
return $fullcmd -x $fullcmd;
}
-my $rootcommand = '';
+my @debian_rules = (debian/rules);
+my @rootcommand = ();
my $signcommand = '';
if ( ( ($ENV{GNUPGHOME} -e $ENV{GNUPGHOME})
|| ($ENV{HOME} -e $ENV{HOME}/.gnupg) )
@@ -122,7 +124,7 @@ while (@ARGV) {
} elsif (/^-j(\d*)$/) {
$parallel = $1 || '-1';
} elsif (/^-r(.*)$/) {
- $rootcommand = $1;
+ @rootcommand = split /\s+/, $1;
} elsif (/^-p(.*)$/) {
$signcommand = $1;
} elsif (/^-k(.*)$/) {
@@ -203,23 +205,25 @@ while (@ARGV) {
} elsif (/^-E$/) {
$warnable_error = 0;
push @passopts, '-E';
+} elsif (/^-R(.*)$/) {
+ @debian_rules = split /\s+/, $1;
} else {
usageerr(_g(unknown option or argument %s), $_);
}
}
if ($ == 0) {
-warning(_g(using a gain-root-command while being root)) if ($rootcommand);
+warning(_g(using a gain-root-command while being root)) if (@rootcommand);
} else {
-$rootcommand ||= 'fakeroot';
+push @rootcommand, fakeroot unless @rootcommand;
-if (!testcommand($rootcommand)) {
- if ($rootcommand eq
Bug#114774: dpkg-checkbuilddeps: patch for new features
On Sun, 07 Oct 2001, Yann Dirson wrote:
The attached patch adds a couple of flags to help working with
build-deps, taking advantage of the already existing mechanics.
-m output met dependencies on stdout, instead of
unmet dependencies on stderr
-d BuildDepStr use given string for build-depends instead of
getting it from control file
-c BldConflStr use given string for build-conflicts instead of
getting it from control file
I've added those features to be able to easily implement a
build-information generator, that tries to be as accurate as possible.
I have plans to enhance dpkg-dev itself to provide information concerning
the build environment so it may not be so important to add those features.
And the original patch doesn't apply anymore.
Though I think that -d and -c can be interesting, so I wrote a new patch
to support them (it's attached). I'll apply it for dpkg 1.14.17.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
From 67a899db6569414af208c063b9c7f1d37f0eed6d Mon Sep 17 00:00:00 2001
From: Raphael Hertzog [EMAIL PROTECTED]
Date: Sat, 19 Jan 2008 22:55:01 +0100
Subject: [PATCH] dpkg-checkbuilddeps: add -d and -c options to override build-depends/conflicts
* scripts/dpkg-checkbuilddeps.pl: Add support of options -d and -c to use
build dependencies/conflicts given on the command line instead of those
retrieved from debian/control.
* man/dpkg-checkbuilddeps.1: Document the new options.
---
man/dpkg-checkbuilddeps.1 |6
scripts/dpkg-checkbuilddeps.pl | 50 +++
2 files changed, 35 insertions(+), 21 deletions(-)
diff --git a/man/dpkg-checkbuilddeps.1 b/man/dpkg-checkbuilddeps.1
index 2214ced..96c7585 100644
--- a/man/dpkg-checkbuilddeps.1
+++ b/man/dpkg-checkbuilddeps.1
@@ -25,6 +25,12 @@ Change the location of the \fBdpkg\fR database. The default location is
Ignore \fIBuild\-Depends\-Indep\fR lines. Use when no arch-indep packages will
be built.
.TP
+.BI \-d build-depends-string
+.TP
+.BI \-c build-conflicts-string
+Use the given build dependencies/conflicts instead of those contained in the
+debian/control file.
+.TP
.B \-h
Show the usage message and exit.
.
diff --git a/scripts/dpkg-checkbuilddeps.pl b/scripts/dpkg-checkbuilddeps.pl
index 1a82dbc..bf375fb 100755
--- a/scripts/dpkg-checkbuilddeps.pl
+++ b/scripts/dpkg-checkbuilddeps.pl
@@ -21,6 +21,10 @@ sub usage {
Options:
control-file control file to process (default: debian/control).
-B binary-only, ignore -Indep.
+ -d build-deps use given string for Build-Depends instead of
+ retrieving it from control file
+ -c build-conf use given string for Build-Conflicts instead of
+ retrieving it from control file
--admindir=directory
change the administrative directory.
-h show this help message.
@@ -29,8 +33,11 @@ Options:
my $binary_only=0;
my $want_help=0;
+my ($bd_value, $bc_value);
if (! GetOptions('-B' = \$binary_only,
'-h' = \$want_help,
+ '-d=s' = \$bd_value,
+ '-c=s' = \$bc_value,
'--admindir=s' = \$admindir)) {
usage();
exit(2);
@@ -46,30 +53,31 @@ my $control = Dpkg::Control-new($controlfile);
my $fields = $control-get_source();
my $facts = parse_status($admindir/status);
-my (@unmet, @conflicts);
-
-push @unmet, build_depends('Implicit-Build-Depends',
- Dpkg::Deps::parse('build-essential'), $facts);
-if (defined($fields-{Build-Depends})) {
- push @unmet, build_depends('Build-Depends',
- Dpkg::Deps::parse($fields-{Build-Depends},
-reduce_arch = 1), $facts);
-}
-if (defined($fields-{C Build-Conflicts})) {
- push @conflicts, build_conflicts('Build-Conflicts',
- Dpkg::Deps::parse($fields-{Build-Conflicts},
-reduce_arch = 1, union = 1), $facts);
+unless (defined($bd_value) or defined($bc_value)) {
+$bd_value = 'build-essential';
+$bd_value .= , . $fields-{Build-Depends} if defined $fields-{Build-Depends};
+if (not $binary_only and defined $fields-{Build-Depends-Indep}) {
+ $bd_value .= , . $fields-{Build-Depends-Indep};
+}
+$bc_value = $fields-{Build-Conflicts} if defined $fields-{Build-Conflicts};
+if (not $binary_only and defined $fields-{Build-Conflicts-Indep}) {
+ if ($bc_value) {
+ $bc_value .= , . $fields-{Build-Conflicts-Indep};
+ } else {
+ $bc_value .= $fields-{Build-Conflicts-Indep};
+ }
+}
}
-if (! $binary_only defined($fields-{Build-Depends-Indep})) {
- push @unmet, build_depends('Build-Depends-Indep',
- Dpkg::Deps::parse($fields-{Build-Depends-Indep},
-reduce_arch = 1
Bug#355654: dpkg-buildpackage to be able to override /usr/bin/make -f in debian/rules
On Sun, 20 Jan 2008, Frank Lichtenheld wrote: We have the -j command now, so it's much less useful. Still I have created another patch that implements what I explained above: it offers a -R option to replace debian/rules by whatever you want. (the other patches were meant for the old shell version of dpkg-buildpackage anyway) Frank, any comments or is it safe to commit? Hrm, the whole split(/\s+/) is somewhat ugly It's not very nice but works in 99% of the use case that I can imagine. The alternative is to accept those options multiple times: -R/usr/local/bin/make -R-f -Rdebian/rules I didn't find that to be nicer. (and BTW not documented for the -R option). It's indirectly documented by the fact that one can use a value like the example given (/usr/local/bin/make -f debian/rules) which contains spaces. If you have something more specific in mind, please feel free to suggest it. Please do not commit before the upcoming upload, to give us a chance to think that over. Sure, I didn't plan to commit before anyway. I don't want to introduce bugs at the last minute. :) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#114774: dpkg-checkbuilddeps: patch for new features
On Sun, 20 Jan 2008, Frank Lichtenheld wrote: On Sat, Jan 19, 2008 at 11:07:20PM +0100, Raphael Hertzog wrote: Though I think that -d and -c can be interesting, so I wrote a new patch to support them (it's attached). I'll apply it for dpkg 1.14.17. You really should add a option to set Build-Depends-Indep then, too. -d replaces Build-Depends and Build-Depends-Indep at the same time. Same for -c and Build-Conflicts/Build-Conflits-Indep. That's why the manual page refers to build dependencies and build conflicts and not the precise field names. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#456332: dpkg could use an elevated pre-depends or depends on lzma
On Tue, 22 Jan 2008, Ian Jackson wrote: Raphael Hertzog writes (Bug#456332: dpkg could use an elevated pre-depends or depends on lzma): On Tue, 18 Dec 2007, Ian Jackson wrote: IMO the lzma binary package should Provide a new virtual package name, lzma-deb-support or some such. Packages could Pre-Depend on that. What does it bring? I assume you mean why do it like that. The answer is that you don't need the lzma support in cases where it's not needed. The dependencies are more accurate. You don't need a virtual package for that. You just need to have each package depend on the right decompressor. I would only be in favor of that if we modify dpkg to auto-generate that dependency, unfortunately right now we only know how to compress when dpkg-deb -b -Zsomething is called and this is after dpkg-gencontrol obviously. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#462172: dpkg-dev: Undefined subroutine Dpkg::Cdata::capit called at /usr/share/perl5/Dpkg/Cdata.pm
On Wed, 23 Jan 2008, Tino Keitel wrote: Package: dpkg-dev Version: 1.14.15 Severity: normal Hi, recent versions of dpkg-dev cause failures with dpkg-buildpackage. With 1.14.15 it works fine. It if works with 1.14.15 don't report the bug against 1.14.15 as you did. Take care to put the first version that you know to be broken in the Version: field in your bug report. Here is a failed run with 1.14.16.1 and a successful run with 1.14.15: Just for your information, the build will fail again with the fixed version (1.14.16.3) but you'll see an error message this time. You likely have a duplicate fields in debian/control... Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#462216: start-stop-daemon with --retry hangs on
On Wed, 23 Jan 2008, Patrick Matthäi wrote: Package: dpkg Version: 1.14.16.2 Severity: critical Hello, since the last updates on the dpkg package, I noticed that all start scripts which are using the start-stop-daemon with the '--retry 60' option no longer works on stopping them. Please check for duplicate bug reports before filing a new bug. It's already fixed in 1.14.16.3. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#462225: start-stop-deamon: select() failed for pause: Invalid argument
On Tue, 22 Jan 2008, Andreas Påhlsson wrote: Package: dpkg Version: 1.13.25 Severity: important Tags: patch Lighttpd often dies when rotating the logs. Trying to reproduce the error manually I got the following error. [EMAIL PROTECTED]:~# /etc/init.d/lighttpd reload * Reloading web server configuration lighttpd start-stop-daemon: select() failed for pause: Invalid argument (Invalid argument) This may or may not be the cause of the logrotate problems. But it surely tells me that start-stop-daemon is broken. Thanks for going as far as a patch but when you do that, you should really try to work from the latest version (ie the one in unstable). start-stop-daemon has just seen some significant changes (check dpkg 1.14.16.3) and I believe this bug has been fixed as I now see: if (interval.tv_sec 0 || interval.tv_usec 0) interval.tv_sec = interval.tv_usec = 0; Would you like to verify that before we close the bug ? (It's rather unlikely that we do a dpkg update in stable for this specific problem) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#462318: dpkg-dev: symbols to blacklist for armel
On Wed, 23 Jan 2008, Aurelien Jarno wrote: libvorbis does not build on armel: | dpkg-gensymbols: warning: some new symbols appeared in the symbols file. | dpkg-gensymbols: warning: debian/libvorbisfile3/DEBIAN/symbols doesn't match completely debian/libvorbisfile3.symbols | | --- dpkg-gensymbolsSkeySn 2008-01-09 00:34:54.0 + | +++ dpkg-gensymbolsYZDMhU 2008-01-09 00:34:54.0 + | @@ -1,4 +1,6 @@ | libvorbisfile.so.3 libvorbisfile3 #MINVER# | + [EMAIL PROTECTED] 1.2.0.dfsg-3 | + [EMAIL PROTECTED] 1.2.0.dfsg-3 | [EMAIL PROTECTED] 1.1.2 | [EMAIL PROTECTED] 1.1.2 | [EMAIL PROTECTED] 1.1.2 | dh_makeshlibs: command returned error code 5 It looks like __aeabi* symbols should be blacklisted on armel. Can you check if there are other similar symbols? The blacklist is an explicit list of symbols, and I try to avoid using regex for the blacklist. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#462413: dpkg-shlibdeps: please special-case libgcj_bc.so.1
Hi, On Thu, 24 Jan 2008, Matthias Klose wrote: Currently dpkg-shlibdeps emits wrong-leading warnings for packages linked against libgcj_bc.so: dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked with libgcj_bc.so.1 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked with libpthread.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked with librt.so.1 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked with libz.so.1 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked with libdl.so.2 (it uses none of its symbols). If libgcj_bc.so.1 is found as a dependency, only the symbols built from the libgcj_bc.c file should be evaluated. Sorry, I don't understand what you mean. Can you give some more details? The only thing that I special case currently is libm which is auto-added by g++ thus I don't display that warning for binaries that do also link against libstdc++. I fail to see the same logic here. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#456332: dpkg could use an elevated pre-depends or depends on lzma
On Thu, 24 Jan 2008, Ian Jackson wrote: Yes, but if the decompressor packages are reorganised at all, or we decide to change again how it is implemented in dpkg, all of those packages will become broken. Given that this will be a pre-depends and will be in a large number of packages, I think it is important that it be very stable. Ok, makes sense. I would only be in favor of that if we modify dpkg to auto-generate that dependency, unfortunately right now we only know how to compress when dpkg-deb -b -Zsomething is called and this is after dpkg-gencontrol obviously. How about if we arrange to pass -Zsomething to dpkg-gencontrol, and have a table in dpkg-dev to map something to deb-decompressor-something for values where it is needed ? The problematic part is arrange to pass -Zsomething to dpkg-gencontrol ... the -Z of dpkg-buildpackage is for dpkg-source and not dpkg-deb -b. And even if we knew right from the start what compressor to use, the dpkg-gencontrol call is hidden in debian/rules and we have no way to pass anything (except maybe an environment variable which isn't really nice). Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#456332: dpkg could use an elevated pre-depends or depends on lzma
On Thu, 24 Jan 2008, Ian Jackson wrote: How do we expect to choose which packages will use which compressors ? Right now, maintainers choose that by adding the right -Z option in the dh_builddeb call (which forwards the option to dpkg-deb -b). So they put it directly in the rules file. Ideally in the end the maintainer would decide, so it ought to be in the source package somewhere. But we want to override it too. I think for overriding it, an environment variable is fine. Perhaps we could just tell maintainers to put export DPKG_DEB_COMPRESSOR ?= ... in their rules. Hrm, that doesn't work so well if different packages want different compression schemes. A debian/control file field ? The debian/control field is the only viable option IMO. It would be somewhat similar to the Package-Type: header which has no real use except influencing the behaviour of another tool during the build. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#456332: dpkg could use an elevated pre-depends or depends on lzma
On Fri, 25 Jan 2008, Ian Jackson wrote: Raphael Hertzog writes (Bug#456332: dpkg could use an elevated pre-depends or depends on lzma): The debian/control field is the only viable option IMO. It would be somewhat similar to the Package-Type: header which has no real use except influencing the behaviour of another tool during the build. Having slept on it I think this is the right answer. Compression-Type: gzip|bzip2|lzma|... converted into Pre-Depends: deb-decompressor-lzma by dpkg-gencontrol Ok. and into an appropriate -Z option by dpkg-buildpackage, then ? Well, no. dpkg-buildpackage doesn't call dpkg-deb --build. dpkg-gencontrol must push the field in DEBIAN/control and dpkb-deb --build must read that field there and use the corresponding compressor. I'm still not convinced that this is the right approach, Pre-Depends are supposed to not be used lightly. Does the package need to be configured, isn't a simple dependency enough ? And furthermore, while I can understand the need to not add the dependency to dpkg itself, in practice most systems will have all the compressors installed anyway. And we're speaking of: $ dpkg -s lzma | grep Installed Installed-Size: 292 $ dpkg -s bzip2 | grep Installed Installed-Size: 124 Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#445552: dpkg-buildpackage should systematically check build-deps before calling clean
On Sun, 27 Jan 2008, Frank Lichtenheld wrote: On Fri, Jan 18, 2008 at 04:02:56PM +0100, Raphael Hertzog wrote: Alternatively, we could make it display a warning and not actually exit. And this warning can itself warn that in the future it might fail at that point if -d is not passed. At some point I would like to introduce a configuration file for dpkg-buildpackage so that one can define his own preferred behaviour (no more -uc -us, looking forward to that...) For now how about this patch that implements that compromise solution you described: It looks fine. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#462318: symbols to blacklist for arme
Hello, On Thu, 31 Jan 2008, Riku Voipio wrote: Is there a easy way to generate .symbols files for all library packages for a selected arch? I presume mole has some code to do that but the sources hide from me. This would make it possible to do a exhaustive search of arch-specific symbols. http://svn.debian.org/viewsvn/qa/trunk/mole/worker/symbols.tester?rev=1732view=log See also the live install in alioth:~hertzog/mole/ Basically unpack the package in a directory and run dpkg-gensymbols -Punpackdir -ppackage -vversion -O Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#462413: dpkg-shlibdeps: please special-case libgcj_bc.so.1
On Thu, 24 Jan 2008, Raphael Hertzog wrote: Hi, On Thu, 24 Jan 2008, Matthias Klose wrote: Currently dpkg-shlibdeps emits wrong-leading warnings for packages linked against libgcj_bc.so: dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked with libgcj_bc.so.1 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked with libpthread.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked with librt.so.1 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked with libz.so.1 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/ecj-gcj/usr/bin/ecj-gcj shouldn't be linked with libdl.so.2 (it uses none of its symbols). If libgcj_bc.so.1 is found as a dependency, only the symbols built from the libgcj_bc.c file should be evaluated. Sorry, I don't understand what you mean. Can you give some more details? After a quick chat on IRC, it looks like the core problem might be that libgcj_bc.so.1 in fact has a SONAME libgcj.so.X since it's just a symlink... At build time, it links with a libgcj_bc.so that contains just the official symbols but at run time the official symbols are looked up in another library... because libgcj_bc.so.1 is a symlink to that library. The differing SONAME are probably the root cause of this problem. We should find a way to register both SONAME as aliases to avoid this. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#464907: dpkg seems not to check for broken versioned dependencies when upgrading
On Sat, 09 Feb 2008, Joey Hess wrote: libzlui-gtk depends on libzlcore (= 0.8.12-3). I have both installed. If I tell dpkg to upgrade to a new 0.8.13 version of libzlcore, it does so, leaving libzlui-gtk with a broken dependency. At no point does dpkg complain about that dependency being broken. I haven't checked, but this sounds very similar to #20471. There's a patch in that bug. If you can take some time to verify if it also fixes this issue, it would be nice. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#464907: [jo...@debian.org: Re: Bug#464907: dpkg seems not to check for broken versioned dependencies when upgrading]
Hi Ian, since you wrote the patch that Joey has been testing, can you look what's wrong with it ? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ ---BeginMessage--- I haven't checked, but this sounds very similar to #20471. There's a patch in that bug. If you can take some time to verify if it also fixes this issue, it would be nice. I applied this patch on top of current git master (rev 98cdd8883f0661e24ff72d4c29d73554586eddf8), and have been using it today while doing whatever, and it seemed to cause this failure: [EMAIL PROTECTED]:/home/joey/tmp/xterm-231dpkg -i ../xterm_231-2boldmode1_i386.deb dpkg: ../../src/depcon.c:218: depisok: Assertion `dep-type == dep_depends || dep-type == dep_predepends || dep-type == dep_breaks || dep-type == dep_conflicts || dep-type == dep_recommends || dep-type == dep_suggests || dep-type == dep_enhances' failed. Other packages installed ok; I was able to downgrade to unstable's dpkg and then install xterm successfully. Here's the package's header, just in case: Package: xterm Version: 231-2boldmode1 Architecture: i386 Maintainer: Debian X Strike Force [EMAIL PROTECTED] Installed-Size: 1108 Depends: libc6 (= 2.7-1), libfontconfig1 (= 2.4.0), libice6 (= 1:1.0.0), libncurses5 (= 5.6+20071006-3), libsm6, libx11-6, libxaw7, libxext6, libxft2 ( 2.1.1), libxmu6, libxt6, xbitmaps Recommends: xutils Suggests: xfonts-cyrillic Provides: x-terminal-emulator Section: x11 Priority: optional -- see shy jo signature.asc Description: Digital signature ---End Message---
Bug#465340: dpkg: Broken call to open in Dpkg/Control.pm
On Tue, 12 Feb 2008, Frank Lichtenheld wrote: On Tue, Feb 12, 2008 at 12:39:21AM +0100, Soren Hansen wrote: On Tue, Feb 12, 2008 at 12:25:13AM +0100, Frank Lichtenheld wrote: Granted my perl-fu is not that strong, and looking at the documentation, I might have exaggerated the extent of this bug somewhat. Could you please go into more detail what you tried to fix? The particular bug I was fixing was when called with -c-, i.e. read the control file from stdin. From perldoc: In the 2-arguments (and 1-argument) form opening '-' opens STDIN and opening '-' opens STDOUT. Without my patch, it's the 3-argument version of open, so opening - fails (as there is no such file). Ok, thanks. Now I understand :) Even if we understand it, I don't think it's a change that we really want. The documentation doesn't mention the possibility of using - as filename for standard input and I'd rather that you fix the Ubuntu package that is doing that instead of changing dpkg. The precise point the 3 arg syntax is to be able to use weird filenames without encountering problems due to the various syntax of the open call. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#465651: Dpkg/Version.pm needs to use Dpkg::Gettext
On Wed, 13 Feb 2008, Adam Heath wrote: Undefined subroutine Dpkg::Version::_g called at /usr/share/perl5/Dpkg/Version.pm line 204. If I use Dpkg::Gettext, the problem goes away. Thanks for spotting this, the fix has been committed. It will be in 1.14.17. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#466957: dpkg tests check installed dpkg rather than newly compiled
On Thu, 21 Feb 2008, Mike Frysinger wrote: Package: dpkg Version: 1.14.16.6 Severity: normal The check target in scripts/Makefile.am does not tweak PATH which means when it executes `dpkg`, it grabs it from PATH instead of src/dpkg in the build directory. This patch should fix things: Thanks. I suppose the problem that it fixes is that in your case, there's no dpkg in your standard PATH, is that right ? I'll commit a slightly modified version of the patch which also includes the scripts sub-directory as we probably also want to be able to use the included scripts. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#466971: dpkg [dpkg] lists output of option -L in alphabetical order
user [EMAIL PROTECTED] usertag 466971 dpkg-query severity 466971 wishlist retitle 466971 dpkg-query -L should sort the file list thanks On Fri, 22 Feb 2008, Jari Aalto wrote: Package: dpkg Version: 1.14.16.6 Severity: minor Please adjust the option -L so that the listing is presented alphabetically. In example below, the maekrd line ! is detached from the rest of the manpages. Rather the rest of the man pages are detached from the one marked with !... and they are detached because they are symlinks. Symlinks always appear at the end of dpkg -L. I don't know if there's a good reason for this or if this is simply an implementation detail that leacks into the user interface. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#452806: [debchange] dch -a shouldn't modify existing entries
On Fri, 22 Feb 2008, Josselin Mouette wrote: Le vendredi 22 février 2008 à 00:07 +0100, Frank Lichtenheld a écrit : On Thu, Feb 21, 2008 at 09:47:21PM +, Adam D. Barratt wrote: debchange simply parses the output of dpkg-parsechangelog(1) in order to derive the changes. dpkg-pc is stripping the whitespace before debchange begins processing it; I'm therefore reassigning the bug. I really fail to see a good reason why it shouldn't. Because it introduces differences to some lines in the changelog in a completely unrelated commit, which makes history harder to use. Huh? What tool is reinjecting the output of dpkg-parsechangelog into debian/changelog ? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
