Bug#969458: perl crash in eval command trying a failing require statement
On Thu, 03 Sep 2020, Niko Tyni wrote:
> > The $name tried is "Kali" and we don't ship any Dpkg::Vendor::Kali. The
> > code should fallback to Dpkg::Vendor::Debian and this works a few times
> > but after multiples calls, at some point it no longer works and the
> > require statement in the eval block just never returns, it seems to crash
> > the perl interpreter.
>
> This looks like a bug in dpkg to me.
Thanks for the analysis. I wasn't aware of this $SIG{__DIE__} feature...
hopefully a fixed dpkg will be released soon.
> I suspect the Perl side is working as designed?
Indeed.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running
On Wed, 18 Dec 2019, Guillem Jover wrote: > > We could add hundreds of path-based triggers, one for each binary that we > > reference in our desktop files but we would likely miss any path > > change... and it would be a bit tedious to maintain. > > I checked the kali package, and the solutions that came to mind were to > use path-based triggers either on each executable, or just on the PATH > directories. The first has the problem that you mention about moving > directories, but the second does not. > > Then instead of looking up these in the dpkg database you could search > the PATH for the programs, because that's what the .desktop files depend > on anyway. Indeed, thanks for the suggestion! Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running
On Fri, 22 Nov 2019, Guillem Jover wrote: > That still does not explain why this needs to be done outside the dpkg's > execution context, though? I don't know any point in dpkg's execution context where we are sure that we will not install/remove other packages later on. > Triggers right now should get batched more aggressively than in the > past. And I'm not quite sure why they would not be preferable to a > hook which gets executed unconditionally every time, regardless of > any package unpacking on the interested paths. This is the kind of > thing triggers were designed to cover. The current way this is > deployed seems rather iffy to me TBH. I'm not opposed to use a trigger based solution but how do you expect it to work? Watching /usr/share/applications doesn't work as there are packages that don't provide a .desktop files and where we want to install our own desktop file when the package gets installed. And I don't want to have to modify all packages for which we are shipping a .desktop file to install. We could add hundreds of path-based triggers, one for each binary that we reference in our desktop files but we would likely miss any path change... and it would be a bit tedious to maintain. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running
Hi, On Wed, 20 Nov 2019, Guillem Jover wrote: > > To achieve this in a more elegant way, could you possibly implement some > > "dpkg --is-running" test ? And/or maybe "dpkg --wait-lock-release" or > > something similar ? > > I'm not sure I understand why this is not done say via a trigger > instead? Also why this script cannot just called within the postinst > w/o putting it on the background? The package provides many desktop files and the associated icons. The script scans the list of installed packages and installs/uninstalls the desktop files corresponding to each package (we have a mapping desktop-file <--> binary package). The script might use dpkg-divert if the target desktop file already exists for some reason. As a long as dpkg is running, we might install/remove packages and it might affect the set of desktop files to install/remove. Thus doing it only in the postinst is not a viable option. Also I just want to perform the operation once, after all package operations have been completed. But path-based triggers are of no help as I really have to monitor the installation/removal of many packages. A named trigger would require changes in the hundreds of packages that can affect the menu. And the reason of kali-menu is precisely because we didn't want to have to fork hundreds of packages. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#849913: dpkg-shlibdeps: searches wrong architecture libraries
Hi Helmut,
On Tue, 03 Jan 2017, Helmut Grohne wrote:
> No, because using binutils-multiarch is broken. Whenever a new
> architecture is brought up, binutils-multiarch lacks support for it.
Ok, that makes sense.
> > That would let us use objdump to inspect any library and let
> > dpkg-shlibdeps figure out whether it's a library of the correct
> > architecture or not.
>
> Inspecting those objects is a bug in the first place. You are trying to
> work around it again rather than fixing it properly. I admit that it is
> non-trivial to fix as it is deeply rooted in glibc. dpkg-shlibdeps
> inherits it by parsing /etc/ld.so.conf.d.
I don't think it's wrong... we are trying to behave like ld.so and I guess
that ld.so does check whether the library is built for the same
architecture.
It's just that the way dpkg-shlibdeps uses to make the same test is not
reliable as you witnessed with the failure. So we should likely find a
better way to do this test.
Maybe by allowing failures on "objdump -a" or by using something else.
I just made a test and noticed that while objdump fails on binaries of
other architectures, readelf does work... but its output is human readable
and not really suitable for machine parsing.
> We could also stop working around problems and start fixing the mess
> instead.
That's what I'm doing too...
> I say let's go back to what worked and fix this properly. Why are you
> backing off now? You did agree on reverting it on regressions earlier.
> Now there is a regression. How much more crystal clear could it be?
Why do you need to be so agressive?
I'm fine with a revert if we can't find a better fix as I don't want
to affect your work negatively. But it's also crystal clear to me that
a revert is not a "proper fix".
The thing worked before because it stopped at the first library found
and it was always one for the correct architecture. Unfortunately it was
not always found in the correct path.
Ne we will always find it in the correct path but we also find libraries
for non-matching architectures and "objdump -a" unhelpfully barfs at those.
/bin/file also knows how to identify the ELF file format of any
architecture but again it's not something really suitable for machine
consumption.
I am thus suggesting the attached patch to ignore objdump failures when
we try to identify the file format but to warn about it so that we can
still have hints about the ignored library if anything goes
wrong later on.
Can you retry your cross-compiler build with this patch?
I would like to note that while the "objdump -a" failure does not happen
in all cases, I can inspect armhf binaries in my amd64 machine but not
the opposite.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
>From 86f59e1cc7b94ff8010117d42f87772b39a4b881 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?=
Date: Thu, 5 Jan 2017 12:16:11 +0100
Subject: [PATCH] Dpkg::Shlibs: ignore "objdump -a" failures in find_library()
On some architectures, "objdump -a" fails when trying to process
a foreign library with a message like this one:
objdump: /usr/lib/x86_64-linux-gnu/libc.so: File format not recognized
Since a927295c93fb7a17742441aa863aaffcf4a351b5 we are now analyzing all
libraries found and not only the first one found, so we can't afford to
fail just because objdump -a failed, instead we just issue a warning.
If the failure is not due to this problem, dpkg-shlibdeps will barf
a bit later because it was not able to find the library so I did not
add an error in case we issued a warning but did not find any other
instance of the same library.
Closes: #849913
---
scripts/Dpkg/Shlibs.pm | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/scripts/Dpkg/Shlibs.pm b/scripts/Dpkg/Shlibs.pm
index 3bb3c7baf..24ffc81c9 100644
--- a/scripts/Dpkg/Shlibs.pm
+++ b/scripts/Dpkg/Shlibs.pm
@@ -156,9 +156,14 @@ sub find_library {
foreach my $dir (@librarypaths) {
my $checkdir = "$root$dir";
if (-e "$checkdir/$lib") {
- my $libformat = Dpkg::Shlibs::Objdump::get_format("$checkdir/$lib");
- if ($format eq $libformat) {
- push @libs, canonpath("$checkdir/$lib");
+ eval {
+ my $libformat = Dpkg::Shlibs::Objdump::get_format("$checkdir/$lib");
+ if ($format eq $libformat) {
+ push @libs, canonpath("$checkdir/$lib");
+ }
+ };
+ if ($@) {
+ warning("could not identify ELF format of %s", "$checkdir/$lib");
}
}
}
--
2.11.0
Bug#849913: dpkg-shlibdeps: searches wrong architecture libraries
Hi Helmut, On Mon, 02 Jan 2017, Helmut Grohne wrote: > while working on #843073, we agreed to merge Raphaël's patch on the > provision that we would revert it if it causes breakage. Unfortunately, > that actually happened. It breaks build cross compilers (stage3): > > https://jenkins.debian.net/job/rebootstrap_musl-linux-mipsel_gcc6/19/console > | DIRNAME= DEB_HOST_ARCH=musl-linux-mipsel ARCH=musl-linux-mipsel > MAKEFLAGS="CC=something" dh_shlibdeps -plibgcc1 > -l/lib/mipsel-linux-musl:/usr/lib/mipsel-linux-musl:/lib/mipsel-linux-musl:/usr/lib/mipsel-linux-musl > | dpkg-shlibdeps -Tdebian/libgcc1.substvars -l/lib/mipsel-linux-musl > -l/usr/lib/mipsel-linux-musl -l/lib/mipsel-linux-musl > -l/usr/lib/mipsel-linux-musl > debian/libgcc1/lib/mipsel-linux-musl/libgcc_s.so.1 > | objdump: /usr/lib/x86_64-linux-gnu/libc.so: File format not recognized > | dpkg-shlibdeps: error: objdump gave error exit status 1 Can't you just install "binutils-multiarch" when you build such cross compilers? That would let us use objdump to inspect any library and let dpkg-shlibdeps figure out whether it's a library of the correct architecture or not. > Thus I am asking to do what we agreed upon: > git revert a927295c93fb7a17742441aa863aaffcf4a351b5 Please consider the suggestion above before going down that route. We could also make the error non-fatal and ignore .so files that objdump can't parse. But I would prefer using binutils-multiarch because it would be bad to ignore failures that mean something else than "file format not recognized". Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#134758: dpkg -S and symlinks
Hi, Now that some users enabled "usrmerge" it has become more important that "dpkg -S" deals sensibly with symlinks. I have thus raised the severity of this bug to important (following the discussion with Helmut in #843073). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#843073: Debian Installer Stretch Alpha 8 release
Control: tag -1 + patch Control: severity 134758 + important I add the patch tag back because this bug is about "dpkg-shlibdeps" being broken by usrmerge. Not about dpkg -S being broken. I agree that dpkg -S ought to be fixed too... but this corresponds to bug #134758. I'm thus raising the severity of #134758 to important. On Mon, 12 Dec 2016, Helmut Grohne wrote: > Thank you for taking the time to come up with a solution. Still, the > approach is wrong. dpkg-shlibdeps relies on dpkg -S to look for the > owning package of a library. [...] > dpkg-shlibdeps. Once dpkg -S produces reasonable output for such paths, > dpkg-shlibdeps will just work. Patching dpkg-shlibdeps papers over the > bug, it doesn't fix it. Yes, dpkg-shlibdeps relies on dpkg -S and knows how to parse its output. dpkg -S being a very old interface, I believe that any "fix" in that interface will break something... we will have to adapt code to understand the new lines of output or we will have to make those new lines conditional on a new command line option. So I don't buy your argument of let's just fix "dpkg -S" and everything will be fine. We will have to fix "dpkg -S" and any code that parses the output of "dpkg -S". > Your patch is an improvement in clarity and pinpoints the cause, but > that's about it. The patch replaces a fragile approach trying to avoid non-canonical paths with a more solid one where we look up all possible paths against the dpkg database. It improves dpkg-shlibdeps whether or not we end up using usrmerge for stretch. It should be merged. Following your suggestion on IRC, I am fine for it to be committed with limited review and then being reverted if it breaks anything (I'm also available to handle any subsequent bugreport). > dpkg -S has users beyond > dpkg-shlibdeps such as needrestart, massxpert, pcp, lxc, > debian-handbook, etc (as a quick codesearch "dpkg .*-S" and manual > inspection reveals). debian-handbook (my book) documents it :-) > Papering over the issue in dpkg-shlibdeps and trying to fix all > consumers does not look viable to me. Thus I am removing the patch tag As I said, I believe that all consumers will have to be fixed (or at least reviewed to ensure they are not confused by the new output we would have). > > It's easier to push work upon others... to be honest the code (that I > > wrote) in dpkg-dev that tries to identifiy the canonical version of the > > library is also somewhat hackish. > > That's what you do, indeed. dpkg-shlibdeps is known to be very fragile. > Last time Guillem touched it in fairly trivial ways, stuff broke. Your > patch hasn't seen extensive testing yet and it changes the search order, > which is a key aspect of its fragility (in particular due to multilib). What search order does it change? It still looks up libraries in the same ordered list of directories. > broke my test cases. Testing it now, but I'm quite annoyed by the amount > of breakage pushed on me. Sorry for this, but that's just our life of free software contributors, we constantly have to adapt to changes made by others. It's hard to avoid it. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#843073: Debian Installer Stretch Alpha 8 release
On Mon, 21 Nov 2016, Guillem Jover wrote: > Oh, and forgot to mention, this issue has been known for over 8 > months, and now there's this need to be pushy and rush things, etc. > I certainly do not appreciate that. I have not been involved in this project so I don't know its history but #843073 is not 8 months old and I only discovered the problem when I read about in on debian-devel and yet I have followed former discussions on debian-devel about merged-/usr. I can understand that this project was of no interest to you and that while you were aware of the problem for 8 months, you did not want to fix it by yourself. But then I'm also sympathetic to people who want to get their project moving forward and I'm always happy to assist them when it touches code that I wrote in dpkg. Feel free to direct such people towards me when you are not interested yourself. In this specific case, the merged-/usr was mostly done and ready before the freeze but then this problem (which was possibly underrated by Marco or whoever else was aware of it) came into light. I would not like that we end up with this feature reverted at freeze time because you did not find the time to merge the patch. Hence my query. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#843073: Debian Installer Stretch Alpha 8 release
Hello Guillem, On Mon, 14 Nov 2016, Michael Biebl wrote: > Just for the record: I can confirm it fixes the problem in dpkg-shlibdeps. [...] > Guillem, it would be great if you can upload a fixed dpkg soon. A full week went by already. What's your plan? I can offer to upload dpkg 1.18.15.1 to sid with just those patches if it relieves you from handling an intermediary upload until you release 1.18.16 on your usual schedule. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#843073: Debian Installer Stretch Alpha 8 release
On Mon, 14 Nov 2016, Raphael Hertzog wrote: > Please find two patches attached. Given Felipe's comment about not breaking API for find_library() I opted to create a new function, but a quick codesearch seems to indicate that no other package is relying on this function. https://codesearch.debian.net/search?q=find_library+filetype%3Aperl&perpkg=1 And the versioning of the module is 0.x indicating that the API had not been declared stable. So you can either get rid of find_library() entirely or replace it entirely with the code find_library_locations() (and then drop find_library_locations) to clean up the codebase. dpkg-shlibdeps is the only user of that function within dpkg. If you want me to rework the patches to do one of the suggested cleanup, let me know. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#843073: Debian Installer Stretch Alpha 8 release
Control: tag -1 + patch
Control: severity -1 serious
Hi Guillem,
On Sun, 13 Nov 2016, Guillem Jover wrote:
> > The /usr merge violates core assumptions in dpkg-shlibdeps. The reason
> > that amd64 isn't broken is sheer luck.
> > /etc/ld.so.conf.d/x86_64-linux-gnu.conf lists /lib before /usr/lib, so
> > dpkg-shlibdeps considers that first. Swapping them or simply removing
> > /lib (as seems reasonable on a merged /usr), breaks almost any build on
> > amd64 (e.g. dash). The breakage on amd64 is simply hidden.
>
> Right. I'm happy to assist people who want to fix this to try to find
> a proper solution in dpkg-dev, but I'm not planning on spending time
> on this on my own.
Please find two patches attached.
I checked that the command below was failing with the current dpkg-dev
and it did no longer fail with the updated one.
$ sbuild -d sid --add-depends=usrmerge --chroot-setup-commands="sed -i
's#^/usr##;t;s#^/lib#/usr&#' /etc/ld.so.conf.d/x86_64-linux-gnu.conf" dash
I believe my patch to be correct and clean.
> Err, well exactly because usemerge is a major hack, and I'm actually
> surprised we are deploying systems by default with that. As an
It's easier to push work upon others... to be honest the code (that I
wrote) in dpkg-dev that tries to identifiy the canonical version of the
library is also somewhat hackish.
I think the updated code that I submitted works better in all weird
corner cases that we could think of.
I'm happy to assist you shall any regression be found.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
>From d2e19afa0f80a955b66ad133c4ebd5b1458bd8ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?=
Date: Mon, 14 Nov 2016 11:46:09 +0100
Subject: [PATCH 1/2] Dpkg::Shlibs: add find_library_locations()
This new functions returns all paths/locations where the library has
been found. Where find_library() has some tricks to try to identify the
canonical version of the library, this one is much simpler: it scans all
directories from the library path and returns every place where it has
been found.
---
scripts/Dpkg/Shlibs.pm | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/scripts/Dpkg/Shlibs.pm b/scripts/Dpkg/Shlibs.pm
index c6221c4..dc0276a 100644
--- a/scripts/Dpkg/Shlibs.pm
+++ b/scripts/Dpkg/Shlibs.pm
@@ -1,4 +1,4 @@
-# Copyright © 2007 Raphaël Hertzog
+# Copyright © 2007,2016 Raphaël Hertzog
# Copyright © 2007-2008, 2012-2015 Guillem Jover
#
# This program is free software; you can redistribute it and/or modify
@@ -20,13 +20,14 @@ use strict;
use warnings;
use feature qw(state);
-our $VERSION = '0.02';
+our $VERSION = '0.03';
our @EXPORT_OK = qw(
blank_library_paths
setup_library_paths
get_library_paths
add_library_dir
find_library
+find_library_locations
);
use Exporter qw(import);
@@ -174,4 +175,26 @@ sub find_library {
return;
}
+sub find_library_locations {
+my ($lib, $rpath, $format, $root) = @_;
+
+setup_library_paths() if not $librarypaths_init;
+
+my @librarypaths = (@{$rpath}, @custom_librarypaths, @system_librarypaths);
+my @locations;
+
+$root //= '';
+$root =~ s{/+$}{};
+foreach my $dir (@librarypaths) {
+my $checkdir = "$root$dir";
+if (-e "$checkdir/$lib") {
+my $libformat = Dpkg::Shlibs::Objdump::get_format("$checkdir/$lib");
+if ($format eq $libformat) {
+push @locations, canonpath("$checkdir/$lib");
+}
+}
+}
+return @locations;
+}
+
1;
--
2.10.2
>From 538208594a1af8b5539d83976e8161b46ea0e40c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?=
Date: Mon, 14 Nov 2016 11:51:50 +0100
Subject: [PATCH 2/2] dpkg-shlibdeps: improve logic to identify package owning
a library
With the introduction of merged-/usr, we have libraries in that are
stored in /usr/lib but that dpkg knows under /lib. This breaks some
of the initial assumptions made in dpkg-shlibdeps.
We now scan all possible paths for a given library (instead of trying to
guessing which one is the canonical one) and whenever we find a match in
the dpkg database, we also associate the package for the associated
realpath(). That way when a library is not properly identified, we can fallback on
looking if its realpath is known and be confident that if the library
was packaged, we did identify it correctly.
Closes: #843073
---
scripts/dpkg-shlibdeps.pl | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/scripts/dpkg-shlibdeps.pl b/scripts/dpkg-shlibdeps.pl
index 3204026..f279f58 100755
--- a/scripts/dpkg-shlibdeps.pl
+++ b/scripts/dpkg-shlibdeps.pl
@@ -6,7 +6,7 @@
# Copyright © 2000 Wichert Akkerman
# Copyright © 2006 Frank Lichtenheld
# Copyright © 2006-2010,2012-2015 Guillem Jover
-# Copyrigh
Bug#836211: dpkg: Cannot upgrade some packages on overlayfs: Invalid cross-device link
Hi,
On Wed, 31 Aug 2016, Felipe Sateler wrote:
> I don't know what the correct workaround should be.
Just for the record, the attached patch is what we use in Kali
to work-around this problem. It works but it's not going to be merged in
Debian because we really want a fix at the overlayfs level instead
(and this is just a hack relying on "mv" to copy the whole-directory).
I post it just in case other derivatives have a similar need.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
commit 237e415129217670699d81287c7cab7bdf451ca7
Author: Raphaël Hertzog
Date: Fri Sep 2 13:55:29 2016 +0200
Fallback on /bin/mv when rename syscall fails with EXDEV
Work-around EXDEV error returned by overlayfs when trying to move away a
directory by calling "mv" which will do a full copy of the tree followed
by a removal of the source tree.
Closes: #836211
diff --git a/debian/changelog b/debian/changelog
index 695c55d..233e413 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+dpkg (1.18.10kali1) kali-dev; urgency=medium
+
+ * Work-around EXDEV error returned by overlayfs when trying to move
+away a directory by calling "mv" which will do a full copy of
+the tree followed by a removal of the source tree. Closes: #836211
+
+ -- Raphaël Hertzog Fri, 02 Sep 2016 13:53:39 +0200
+
dpkg (1.18.10) unstable; urgency=medium
[ Guillem Jover ]
diff --git a/src/archives.c b/src/archives.c
index d07d4a4..da43ab7 100644
--- a/src/archives.c
+++ b/src/archives.c
@@ -1021,9 +1021,25 @@ tarobject(void *ctx, struct tar_entry *ti)
/* One of the two is a directory - can't do atomic install. */
debug(dbg_eachfiledetail,"tarobject directory, nonatomic");
nifd->namenode->flags |= fnnf_no_atomic_overwrite;
- if (rename(fnamevb.buf,fnametmpvb.buf))
-ohshite(_("unable to move aside '%.255s' to install new version"),
-ti->name);
+ if (rename(fnamevb.buf,fnametmpvb.buf)) {
+ if (errno == EXDEV) {
+ struct command cmd;
+ pid_t pid;
+
+ command_init(&cmd, "mv", "move directory aside");
+ command_add_args(&cmd, "mv", fnamevb.buf, fnametmpvb.buf, NULL);
+ pid = subproc_fork();
+
+ if (pid == 0)
+command_exec(&cmd);
+
+ subproc_reap(pid, "mv", 0);
+ command_destroy(&cmd);
+ } else {
+ ohshite(_("unable to move aside '%.255s' to install new version"),
+ ti->name);
+ }
+ }
} else if (S_ISLNK(stab.st_mode)) {
/* We can't make a symlink with two hardlinks, so we'll have to
* copy it. (Pretend that making a copy of a symlink is the same
Bug#836211: dpkg: Cannot upgrade some packages on overlayfs: Invalid cross-device link
Hi,
On Wed, 31 Aug 2016, Felipe Sateler wrote:
> overlayfs does not support renaming directories when the directories
> live in the lower filesystem:
[...]
> Unfortunately this means that dpkg fails at least in the case where a
> directory is converted into a file: apt 1.3~rc2 moves
> /usr/share/bug/apt/script to /usr/share/bug/apt . This causes dpkg to
That's the change at the package level. The operation that fails
at the dpkg level is rename('/usr/share/bug/apt',
'/usr/share/bug/apt.dpkg-tmp').
> fail when running in an overlayfs with the following error:
[...]
> unable to move aside './usr/share/bug/apt' to install new version: Invalid
> cross-device link
I got the same failure here but I also saw similar reports in a Kali live
system where overlayfs is used for persistence (and with the upgrade
of gedit). So that error is affecting many Kali users. It's not a
very rare error (ex: https://bugs.kali.org/view.php?id=3473,
https://bugs.kali.org/view.php?id=3476,
https://bugs.kali.org/view.php?id=3361,
https://bugs.kali.org/view.php?id=3365).
I'm putting in copy the overlayfs kernel maintainer... Hello Miklos,
that restriction above (cf
https://github.com/torvalds/linux/blob/v4.8-rc2/fs/overlayfs/copy_up.c#L318-L322)
is very problematic for us.
Do you have plans to get rid of it?
It does not seem very correct to put the burden on user-space to be aware
of overlayfs restrictions such as this one. Renaming a directory is
not something that happens often in practice in the uses cases where
we use overlayfs but it's still frequent enough to deserve better than
a EXDEV error IMO and dpkg trying to rename "foo/" into "foo.dpkg-tmp/"
is in its right to assume that this rename will not cross any device
boundary.
I'm happy to test out kernel patches if I can help you in the process
of getting a fix.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
Bug#735377: 3.0 (native) silently ignores many binary files by default.
On Tue, 26 Apr 2016, Holger Levsen wrote: > Having done this, I checked my ~/.devscripts and found this: > > DEBUILD_DPKG_BUILDPACKAGE_OPTS="-uc -us -I -i" > > Is this why? Yes. -I and --tar-ignore in debian/source/options are cumulative. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Bug#775124: dpkg-statoverride with unknown group breaks any subsequent package installation
On Sun, 11 Jan 2015, Andreas Beckmann wrote: > another case where a "corruption" could be left after removal is > > * preinst/postinst creates a user and a statoverride > * prerm/postrm removes the user but leaves the statoverride > => statoverride file will be "corrupted" only after removal (purge?) of >the buggy package > > these wouldn't be caught by piuparts since there is no more package > installation after purge Note that piuparts could run "dpkg --audit" (and possibly also "dpkg --verify" to detect modified files) at the end. I haven't double checked, but it seems likely that dpkg will load its statoverride database in those operations and that you would thus detect those problems. Commit e4d6db177fad401ddc8432cf0e2c64e4fcf7bc0d after https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563307 introduced a "lax parsing" mode that is only used in dpkg-statoverride leaving dpkg in normal (strict) mode. So I don't think that this bug deserves an RC status since the user can drop the bad statoverride with a simple dpkg-statoverride invocation. The RC bug, if any, ought to be on the package which calls dpkg-statoverride incorrectly (or drop the user/group while it's now widely agreed that we should not drop them) (and in general this is a tool for administrators and not for package maintainers so it's doubly wrong in most cases). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769843: dpkg-maintscript-helper: Wrong pre-dependency information in man page
Hi, On Fri, 21 Nov 2014, Stefan Fritsch wrote: > On Monday 17 November 2014 01:43:46, Guillem Jover wrote: > > I've fixed this now locally by bumping the version for both symlink > > commands to just 1.17.14, which avoids translation work, and > > targetting 1.17.22. > > Thanks. It seems a build-depends is also required, see #770421. Maybe > you should mention that in the man page, too? Technically, it's debhelper (dh_installdeb) that needs to be updated in Build-Depends. You need debhelper >= 9.20131213 (first version that knew about that command). And you want to file a bug report against debhelper so that it generates a pre-dependency with 1.17.14 instead of 1.17.5. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769520: dpkg-dev: debuild clean fails to first apply patches to source in quilt 3.0 format
On Fri, 14 Nov 2014, Faheem Mitha wrote: > Hi Raphael, > > Ok, if you don't think it is a bug, please close it. I'll let Guillem do that if he agrees with me. > If you can take a moment, can you advise me what the correct approach to > handling this should be? Just make sure to push the patches before running > 'debuild clean'? Thanks. It depends on why you're trying to clean your source package. If it's just after a build, you might want to consider using the "-tc" option that calls the clean target after a successfull build. Usually "debian/rules clean" tends to work even with patches unapplied but in the few cases where it doesn't, it's certainly ok if you manually ensure that they are applied. Note that the default state of the source package after "dpkg-source -x" is patches applied... if you use a workflow where patches are unapplied, it's up to this workflow to ensure that they are applied at the correct time. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#769520: dpkg-dev: debuild clean fails to first apply patches to source in quilt 3.0 format
On Fri, 14 Nov 2014, Faheem Mitha wrote: > The subject line says it all. I noticed today that if the patches in > debian/patches are not applied, then > > debuild clean > > does not apply them, and if a patch is required to run clean > successfully, then clean fails. Included is the clean section of > debian/rules for my example package, and also the output of running > 'debuild clean' with and without patches applied. > > I think that debuild clean (or to be precise, the underlying > dpkg-buildpackage) command should apply the patches before running any > command, and presumably unapply it afterwards. I don't see a downside > to this. dpkg-buildpackage is not called when you run "debuild clean". The manual page clearly indicates that it calls "debian/rules " directly. And your log doesn't show any message of dpkg-buildpackage. In general, opting to call a specific target doesn't do any build preparation work. It's the same if you do "dpkg-buildpackage --target=clean". I'm not sure this can be considered as a bug. It behaves as documented. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767999: base-files: fails to install with pre-jessie debootstrap
On Fri, 07 Nov 2014, Guillem Jover wrote: > I'm going to revert the commit above (only in 1.17.x, it will be kept > in 1.18.x), because it is very minimal, just reintroduces again an > unnecessary package queue stage, and such regression is acceptable if > it makes buggy bootstrappers work again. But a fixed debootstrap (and > maybe cdebootstrap if that fails too) should really be pushed to stable. FWIW, cdebootstrap in stable is affected, it has been fixed in version 0.6.0 (see bug #737939). In Kali we were affected by this and our solution was to make base-files depends on base-passwd. I argued for this in #760568 first. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#759754: Updating doc about handling conffile with debian/package.maintscript instead of {post,pre}[rm,inst} files
Hi, On Thu, 18 Sep 2014, Joseph Herlant wrote: > I think the "DpkgConffileHandling" of the wiki would also be great as > it currently don't even mention that debian/package.maintscript file. It's a wiki, you should have fixed it yourself. But in this case, it already had a mention, I just extended it to mention debian/*.maintscript explicitly. > And perhaps ask Raphaël Hertzog to update its blog to integrate that > (as the link to its blog is given in the wiki and its page is the 1st > google page for renaming and removing conf files). I just did that too. Thanks for the suggestion! Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#759404: dpkg-source: base timestamp of patched files on debian/changelog
Hi, On Thu, 28 Aug 2014, Niko Tyni wrote: > In the scope of just the source package, it seems possible for dpkg-source > to remember the latest timestamp it has extracted and notice if that's > newer than the debian/changelog timestamp. dpkg-source delegates most of the extraction to "tar" so it would have to scan the directory again to find out the timestamps (or at least scan the tar archive again). > > This also gets more complicated when dealing with NFS mounts, which > > the current code is already handling correctly. > > Could you elaborate a bit on that? Is there some NFS specific code in > dpkg-source at the moment? See Dpkg::Source::Functions::fs_time() at least. > > Although some of these situations might show up from timestamp skews > > due to mismatched times from upstream, packager, or build systems for > > example, that's just a reality that I'm not sure we can ignore. > > Yeah, I see it's complicated. > > Do you think an archive-wide check for source packages having newer > files than their debian/changelog timestamps might tip the scales, or > is it clear that this is just not going to work? (I guess lintian would > be a good place for such a check.) The probability of having an older timestamp in debian/changelog seems rather low to me. I don't really understand Guillem's concerns here. However, for the few cases where it might lead to some problems, we might want to reset the timestamp of the patched files before build so that the packager detects it on build and not later when someone unpacks it for the first time. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#32877: Patch: cleaned up and applied previous patch
Hi, On Sat, 12 Jul 2014, Felix Berlakovich wrote: > I applied the patch from Vasily i. Redkin to version 1.17.10 (and moved > a redundant part into an own function). BTW his patch works great. I > did this in preparation for a possible threeway merge improvement. Is > there still any interest in such a feature? Is there any reason why this > patch was never integrated? Paul Wise pointed me at http://community.libelektra.org/wp/?p=145 and http://community.libelektra.org/wp/?p=153 which in turn brought me back to this email. A few comments: 1/ your mail doesn't contain any help offer to bring the patch to a state where it can be merged so it was not obvious that you were willing to invest time into improving it 2/ your mail was not very well formatted (a single line) and it's easy to miss it in the flow of mails 3/ you need to seek the input of Guillem Jover who is the main dpkg developer and who already reviewed earlier attempts to bring this feature 4/ yes we are interested in the feature but dpkg is an important piece of software and we must get it right from the start, so extra caution is always a good idea With a few more researches, you could have found our wiki page https://wiki.debian.org/Teams/Dpkg which then links to https://wiki.debian.org/Teams/Dpkg/Proposals/ConffileDatabase which contains the most recent attempt to bring this feature to Dpkg. Sean Finney was working on this but unfortunately he lost motivation due to lack of review by Guillem. Fortunately Guillem is much more responsive nowadays so you might have more luck to bring it to a mergeable state. More links in the archive: https://lists.debian.org/debian-dpkg/2009/09/msg00065.html https://lists.debian.org/debian-dpkg/2009/10/msg00056.html https://lists.debian.org/debian-dpkg/2009/12/msg00041.html (5 years old already :-() Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756975: dpkg-genchanges option to only include arch:all debs
Hi, On Sat, 09 Aug 2014, Joey Hess wrote: > An added wrinkle is that -S doesn't build arch specific debs at all, of > course, but a responsible user of this new DAK feature will want to > build debs, lintian and test the locally, but not upload them. > > I think this calls for more than a generic filling in of the complements > to -S. It's fine to add those options to dpkg-genchanges, but > dpkg-buildpackage would be improved by an option that built everything, > and then told dpkg-genchanges to only put source and arch:all in the > changes. Funnily this can already be done with “dpkg-buildpackage --changes-option=-S” but it will generate a _.changes file that list only the source package (that's because the filename is decided by dpkg-buildpackage while the content comes from dpkg-genchanges). So it's definitely not the good answer to your request. In fact, this would require a separate option for an extra dpkg-genchanges call. Something like --extra-changes="-S"... Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756964: dpkg-dev: dpkg-source cannot handle -p2 addition in debian/patches
Hi, On Mon, 04 Aug 2014, Norbert Preining wrote: > Umpf, not very convenient. Is there any particular reason for that? Standardization. As you say it's a convenience feature that just makes it more complicated to everybody else that righfully expects -p1 patches. > I often cherry pick from upstream svn and have to use -p2, due > to the layout of upstream svn. quilt import -p2 & quilt push is > very convenient. You can just add "&& quilt refresh -p ab" at the end of your command sequence. Isn't that enough to address your need? If yes, please close that bug because I don't believe that it's a good feature to add to dpkg-source. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'
Hi, On Tue, 13 May 2014, Gerfried Fuchs wrote: > This also affects a cowbuilder chroot and ends up in its build logs. > Either it is needed, then it should be a Depends, or not, then it > shouldn't blabber about it and end up in build logs. > > Yes, installing something in a pbuilder/cowbuilder chroot that isn't a > Build-Depends (or Depends of the base system) is a problem in the sense > that it somehow defeats the whole purpose of using a chroot for that in > the first place. :) FWIW, I agree that we should do something to get rid of that warning. It hurts more than it helps. The build log pollution is very annoying. And we have seen that installing the dependency in the build chroots is also not desirable because it will create problems during a perl transition. Is there a way to detect that NFS is in use ? If yes, then we could make the warning conditional on the usage of NFS. Otherwise we should just silence it and document the limitation when the module is not installed. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747088: python-appdirs: Upgrade failure
Control: reassign -1 python-appdirs 1.3.0-1 Control: severity -1 serious On Tue, 06 May 2014, Benjamin Drung wrote: > > Uninstalling the package (and everything that depends on it :( ) and > > reinstalling does work around the problem, and now the .egg-info item is a > > directory. > > This looks like a bug in dpkg (to fail replacing a file by a directory). > Therefore I reassign this bug. In fact, it's not clearly a bug in dpkg. The problem lies in the fact that ./usr/lib/python2.7/dist-packages/appdirs-1.3.0.egg-info is a symlink to a file... but at the point when dpkg processes that file, it has already upgraded ./usr/share/pyshared/appdirs-1.3.0.egg-info to a directory and since dpkg won't replace a symlink to a directory by a true directory, you get the error you see because now /usr/share/pyshared/appdirs-1.3.0.egg-info/* is processed twice: once in the normal path and once via the symlinked path ./usr/lib/python2.7/dist-packages/appdirs-1.3.0.egg-info/... I would suggest to handle this in the python-appdirs package because dpkg doesn't have enough information to be able to do the right thing. We're aware of this limitation and it will eventually be fixed but it won't be fixed in time for this specific case. Thus reassigning back. The proper thing to do is to remove /usr/lib/python2.7/dist-packages/appdirs-1.3.0.egg-info in the "prerm upgrade" when you upgrade from the old version. Thank you. -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#746450: dpkg-dev: New make breaks dpkg-buildpackage test for existence of targets
Hi, On Wed, 30 Apr 2014, Manoj Srivastava wrote: > Of the 73 packages that failed, 10 were due to a known > incompatibility, which has been fixed. About 20 or so were due to > various issues i the package, unrelated to this report. However, 40 > packages failed to build due to the new make is not doing the expected > thing when called as: make -f debian/rules -qn build-arch Why is this broken by the new make? Doesn't debhelper have a similar problem when trying to detect whether override_dh_foo targets are present? If not maybe the right thing to do is to fix our detection to work like the one used in debhelper... > The options, as I see it are: 4) Fix the code detecting target availability to work with the new make. > Ideally, we should just bite the bullet and demand that all > packages implement the build-arch and build-indep targets, and call > them without testing for them as needed. An experimental build of > dpkg-dev could be used to do a full archive rebuild to see how that > shakes out. Indeed but I fear the list will be much bigger than the few that you found out with the current situation. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739634: "dpkg-maintscript-helper supports" always returns 1
On Fri, 21 Feb 2014, Eugen Dedu wrote: > Sorry to ask again: why do these commands fail if no env var is set? Because they need to know in which maintainer script they are called and they need to know the package that they are acting on. Without this, they can't do the work they're supposed to do... Have a look at the code (it's just a shell script), it might help. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735377: 3.0 (native) silently ignores many binary files by default.
Hi, On Sat, 18 Jan 2014, peter green wrote: > Raphael Hertzog wrote: > >So yes, *.a, *.la, *.o and *.so are ignored by default in native source > >package > >and this is is so for as long as I can remember. > Afaict if I leave a .so or similar file in the source tree (and > don't override anything) the different source formats currently > behave as follows > > 1.0 native: include the file in the tarball Because ignore rules are not used for 1.0. > 1.0 non-native: scream and die Because the binary files are not representable in diff format and the ignore rules are not used (and besides the diff ignore rules do not cover those files). > 3.0 (native): quietly ignore the file yes > 3.0 (quilt): scream and die It depends on where the file is. In debian/, it's ignored just like in 3.0 (native) because the tar_ignore rules apply, outside of debian however, it's the usual diff_ignore rules so they are not ignored but we get a failure due to the unexpected binary file (which also can't be represented in a quilt patch). > But for *.a, *.la, *.o and *.so . If they are present in the source > tree then most likely one of two things is true. > > 1: The files are built as part of the package build process. In this > case they should be removed by the clean target to ensure that > freshly built versions are used in the package build. > 2: The files are not built as part of the package build process and > therefore need to be included in the source package (which of course > makes the package unsuitable for Debian main). > > In both of these cases quietly ignoring the files is broken > behaviour. So I don't see any justification for quietly ignoring > them being the default. Screaming and dieing would be a more sane > behaviour and would be more consistent with the behaviour of > non-native package builds. That rather makes sense and some people have been bitten by the exclusion of .so files when they wanted to install some ld linker scripts. I would be willing to drop those tar_ignore rules but this is a backwards incompatible change and I'm wary of breaking stuff. We should probably seek further input from debian-devel. Guillem, what's your opinion ? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735377: 3.0 (native) silently ignores many binary files by default.
Control: retitle -1 document how to un-ignore files ignored by default in "3.0
(native)" and "3.0 (quilt)"
On Wed, 15 Jan 2014, peter green wrote:
> When attempting to build such a package using the 3.0 native format
> the source package build and binary package builds will succeed, but
> the "source" package won't actually contain the binaries that were
> in the source tree and so when someone comes to unpack said source
> package again to make a change they will find it is incomple.
>
> IMO silently ignoring such files is a crazy default, either the
> files should be included or source package build should scream and
> die (thus prompting the packager that they need to either fix thier
> clean target or override something).
It doesn't silently ignore random binary files, it ignores the files
that are on its default ignore list and which are documented
in dpkg-source --help:
-I[]filter out files when building tarballs
(defaults to: -I*.a -I*.la -I*.o -I*.so -I.*.sw?
-I*/*~ -I,,* -I.[#~]* -I.arch-ids -I.arch-inventory -I.be -I.bzr -I.bzr.backup
-I.bzr.tags -I.bzrignore -I.cvsignore -I.deps -I.git -I.gitattributes
-I.gitignore -I.gitmodules -I.hg -I.hgignore -I.hgsigs -I.hgtags -I.shelf
-I.svn -ICVS -IDEADJOE -IRCS -I_MTN -I_darcs -I{arch}).
So yes, *.a, *.la, *.o and *.so are ignored by default in native source package
and this is is so for as long as I can remember.
If you are unhappy with the default, please change it for your package
with debian/source/options:
tar-ignore=.git
tar-ignore=.gitignore
As soon as you start being explicit about the ignore rules, the default
ignore rules are no longer used but you can put the default ignore rule
back with a single "tar-ignore" (i.e. without value).
This probably ought to be better documented. Retitling the bug accordingly.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735102: dpkg: [dpkg] dpkg-divert migrate from /usr/sbin to /usr/bin
Control: reassign -1 tiger 1:3.2.3-10 Control: retitle -1 /usr/lib/tiger/systems/Linux/2/deb_checkmd5sums hardcodes path to dpkg-divert On Mon, 13 Jan 2014, Yoric Kotchukov wrote: > Hello! > > After upgrade dpkg-divert migrate from /usr/sbin to /usr/bin, tiger complain > about > "/usr/lib/tiger/systems/Linux/2/deb_checkmd5sums: /usr/sbin/dpkg-divert: not > found". > Or problem in package "tiger"? Indeed, it's a bug in the tiger package. Reassigning there. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)
On Mon, 30 Dec 2013, Jakub Wilk wrote: > * Guillem Jover , 2013-12-30, 12:27: > >I guess it's probably a good idea to switch the default, becuse I > >assume most maintainers do more test builds than final ones. > > ACK And also, it should be friendly to non-maintainers who are just trying to rebuild the package grabbed from Debian. The assumption that the builder is the maintainer is inadequate to start with. So I'm in favor of a transition. I also agree that it makes sense to add a dedicated signing tool in dpkg-dev (merging debsign as dpkg-sign?) and that this change should dealt together with a general revamp of dpkg-buildpackage. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732937: dpkg: fails somewhat regularly on kfreebsd-amd64
On Mon, 23 Dec 2013, Guillem Jover wrote: > The problem is that something messes with dpkg's standard output and > error, and it fails when doing the fflush() and ferror() check on it > in m_output() I think. But this seems to be coming from something > lower than dpkg or apt, perhaps a change in glibc or the kernel. As > I've tried with downgraded versions matching the ones in stable, and > it still fails. I've not tested further. > > The last thing reported from dpkg to apt through the status-fd channel > is: > > status: git : error : error writing to '': No such file or > directory This is not without reminding me of this years old bug on launchpad (with hundreds of duplicates) that we never clearly understood: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/545790 I don't know if they are related but if that's the case, then it's good to finally have a way to reproduce it more reliably. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732835: Provide build tools with more information
On Mon, 23 Dec 2013, Guillem Jover wrote: > > Doing this via a status fd would be nice[1] since we could then > > implement more nice things like progress information (we'd then be able > > to detect easily which dpkg-buildpackage's steps failed) without parsing > > the full build output. > > > [1] The status fd has the disadvantage that we need to pass it through > > tools like pbuilder and sbuild as well so a file at a well known > > location might be simpler. > > How do you see that progress information being used? Or to report > what? Being able to programmatically detect in what step the failure happened is cleary useful, in particular for mass rebuilds. Differentiating failures in the source rebuild or the binary rebuild is already significant. > I'm not saying a --status-fd kind of option might not be useful, just > interested to know, if maybe there's something else that needs fixing > instead in dpkg-buildpackage, now that I'm reworking it. For example > if its error reporting leaves to be desired, then I'd rather improve > that, rather than adding support for wrappers to workaround it. :) > > For example for 1.17.6 I'm adding hooks support, which can be useful > for wrappers. Hooks are certainly useful but when dpkg-buildpackage is really wrapped in something much larger then it's somewhat counter-intuitive to have to include all the post-build processing in the final dpkg-buildpackage hook. I really believe that we ought to communicate back the generated changes file. > For the problem described in the bug report, I think a better way to > solve this is to run lintian directly from dpkg-buildpackage, which > will be possible with dpkg 1.17.6, by using the new check-command > support. See the following commit for further details: This is not so clear cut. Letting dpkg-buildpackage call lintian means that lintian must be installed in the build environment and that might not be the case in minimal build environment. You might want to call lintian outside of it (and thus outside of dpkg-buildpackage). > Or do you need the .changes file for something else? There a lots of things that you might want to do with a built package besides checking it: installing it for tests, uploading it, installing it in a repository, modifying it (in the case of dgit), etc. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731484: dpkg-shlibdeps: error: no dependency information found for /usr/lib/libstdc++.so.6
Hi, On Thu, 05 Dec 2013, Daniel Kahn Gillmor wrote: >dh_shlibdeps > dpkg-shlibdeps: error: no dependency information found for > /usr/lib/libstdc++.so.6 (used by debian/wpagui/usr/sbin/wpa_gui) > dh_shlibdeps: dpkg-shlibdeps -Tdebian/wpagui.substvars > debian/wpagui/usr/sbin/wpa_gui returned exit code 2 > > (the above is from a rebuild of the wpa package, but it happens with > other packages with C++ components as well, like enigmail). Your chroot is unclean then. Because libstdc++6 contains the library in the multiarch path, aka /usr/lib/x86_64-linux-gnu/libstdc++.so.6. And the reason why it can't find any dependency information is because /usr/lib/libstdc++.so.6 is not part of any known package (check with dpkg -S). I suggest you retry with a newly built chroot, or you clean up your current chroot. Please close this bug if the above explanation is correct. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583585: Something like the following code snippet ?
Hi, On Mon, 26 Aug 2013, Guillem Jover wrote: > The files must not be moved from the old dir to the new symlink-to-dir, > otherwise dpkg will lose track of them wrt to their canonical path, and And what about files which are not managed by dpkg? And files of other packages which are not upgraded at the same time? I believe that the files which are left-over at the end (i.e. after dpkg has cleaned up the tree due to the temporary symlink) should be put back in place when there's no conflicting file (they could also have been installed by other packages wich were not yet updated to not use the symlinked directory). > I went ahead and implemented this command, because once having gone > over the failure modes, it was easier to just code it down. I'll be > doing some polishing and testing tomorrow, to be included in an > imminent push. Usual practice would be to attach the patch so that others can review too... Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583585: Fwd: Bug#583585: [dpkg] Any news ?
On Fri, 23 Aug 2013, Bastien ROUCARIES wrote: > Find -print0 > > And replacing read by read -r -d $'\0' is safer but I do not know if it is > portable. > > Or xargs but we need to fork for each file and we get the portability > problem of find print0. > > What do you prefer ? find -print0 is fine, dpkg-deb already uses it. read -d is likely a problem however (I believe it's bash specific). I don't think that I have any good answer if we want to support newlines in filenames. But it's probably not an important use case as dpkg itself doesn't cope very well with it. dpkg-deb builds it fine and it installs fine but when you do "dpkg -L" you get this back (with a single "hello\nworld" file): $ dpkg -L foo /. /hello /world (This is because the /var/lib/dpkg/info/*.list files are line based) So I would go ahead ignoring this specific problem. Otherwise you could write that specific part in perl but it would be a regression to reintroduce perl in dpkg itself. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583585: Fwd: Bug#583585: [dpkg] Any news ?
Hi,
On Tue, 20 Aug 2013, Bastien ROUCARIES wrote:
> > A possible way to do this could be:
> > * Move the directory away in preinst (.dpkg-backup), put in place a
> > symlink
> > pointing to the renamed directory
> ok this is easy
> > * In postinst, move remaining files from the temporary directory to
> > the directory pointed by the symlink (except if there's already a new
> > file at the expected location, in that case warn about the conflict
> > and leave the file).
>
> How can I do this ? mv -n is not portable, and if I use find how to
> handle symlink ?
mymove() {
local origin=$1
local target=$2
while read path; do
# do the work for each file here
done
}
find $origin | mymove $origin $target
You can use compute the relative path names by stripping $origin from the
stard and you can do whatever checks you want with "test".
> Should I check if md5sum are the same in case of conflicts and
> override in this case ?
I would not override but it's interesting to compare the files
yes. That way we can avoid complaining about a conflict when in fact
both files are identical. And we can silently drop our copy.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583585: [dpkg] Any news ?
Hi, On Tue, 20 Aug 2013, Bastien ROUCARIES wrote: > Now that symlink to dir is implemented, how can we implement the > reverse operation ? Note that you still have to update man/dpkg-maintscript-helper.1 AFAIK. We don't want to ship undocumented features. > I suppose checking that the: > - path is a directory, > - if LAST version is lesser We should clearly define the cases that we want to support (and have it fail when the pre-requisites are not satisfied). You have mutiple questions to answer: 1/ How do you want to handle non-packaged files present in the directory? 2/ How do you want to handle files from other packages in the directory? 3/ What do you do if the expected directory is not a directory? What if it's another symlink (probably setup by the admin)? My first answers would be: 1/ and 2/ try to reinstall those files at their expected place in the directory pointed by the symlink 3/ do nothing A possible way to do this could be: * Move the directory away in preinst (.dpkg-backup), put in place a symlink pointing to the renamed directory * In postinst, move remaining files from the temporary directory to the directory pointed by the symlink (except if there's already a new file at the expected location, in that case warn about the conflict and leave the file). Note we expect the file unpack to have updated the symlink to a new directory. If it's still pointing to ".dpkg-backup" then we should probably update the symlink ourselves (assuming it's given as parameter to the dpkg-maintscript-helper). > And what do you means by swap? Could you give some example ? That feature description was written by Lionel Elie Mamane (in copy). But swapping means something like this: Changing: directory "foo", symlink "bar" (pointing to "foo") Into: directory "bar", symlink "foo" (pointing to "bar") I'm not sure that this is a frequent case and we should consider whether 2 simultaneous calls to dpkg-maintscript-helper would do the right thing (one symlink2dir associated to one dir2symlink) Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583585: [dpkg] Any news ?
Hi, On Tue, 20 Aug 2013, Guillem Jover wrote: > > I could not test I get problem about > > pkg-tests/t-normal/../dpkgdb/info/format-new running pkg-test could > > not create file > > If you could send the output and how you run it, I could take a look. I have pushed a fix already. The issue is simply that a fresh clone is missing dpkgdb/updates and dpkgdb/info. Bastien, you can just mkdir those two directories and you'll be able to run the tests (or you can pull my changes and they will be auto-created by the Makefiles). Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583585: [dpkg] Any news ?
Hi, On Tue, 20 Aug 2013, Guillem Jover wrote: > Although, as I've said before, I consider dpkg-maintscript-helper a > dead-end and in a way a waste of time, I've also said I'd merge > patches for it if they look more or less ok. For reference, I'm happy to waste my time on dpkg-maintscript-helper so that you can work on fixing those issues properly at the dpkg level. > So I've merged it locally now after fixing some style and shell syntax > issues (did you test it?), made last-version optional and added it to > the usage output, and I'll try to do some minimal testing tomorrow. > But functional tests for pkg-tests.git would be nicer, and if you could > prepare an update to the man page so that this can be merged for one > of the 1.17.x uploads that'd be even better. I had a chat with Bastien on #debian-qa yesterday and I already asked him to submit functional tests for pkg-tests.git. Can you share your enhanced version so that we can finish the work? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#476221: jessie release goal: verbose build logs
On Wed, 14 Aug 2013, Guillem Jover wrote: > Definitely, and planned (#476221) to be fixed pretty soon. But the > problem is that this can not be enabled by default (only through an > option initially, until the upper layers rely on a dpkg-buildpackage > with such option and use it) because the different tools might fight > over the file and might either truncate it or write duplicate data, > etc. Using a different path might be an issue for builds producing > huge log files. Great to see that you want to take care of this, but can you let us know how you plan to let dpkg-buildpackage cooperate with the upper layer tools to have a full log file that can be added to .changes? If we don't care about adding it to .changes, then it's trivial, dpkg-buildpackage can just ignore the file, but otherwise we need some way to transfer the control of the log file or something similar. The requirements IMO is to have the start of the log from the upper layer (i.e. sbuild setup of build dependencies) but also have the log properly closed at the time dpkg-buildpackage runs dpkg-genchanges, because once it has been added to the .changes it should not be further modified obviously. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718984: dpkg-dev: dpkg-source ingores files in include-binaries that apply to the default -I excludes
Hi,
On Wed, 07 Aug 2013, Guillem Jover wrote:
> I've just tested, and dpkg-source 1.15.x shows the same behavior.
> Not saying it's desirable, just that I don't see how this breaks
> stuff that used to work in the past?
Which 1.15.x have you tested? Because commit
3525f79792cff51757d99d45f51c96a15e6fa779 might be relevant to the issue
at hand... and this was added between 1.15.0 and 1.15.1.
Possible patch (untested):
--- a/scripts/Dpkg/Source/Package/V2.pm
+++ b/scripts/Dpkg/Source/Package/V2.pm
@@ -468,7 +468,9 @@ sub do_build {
chdir($cwd) || syserr(_g("unable to chdir to `%s'"), $cwd);
my @result;
foreach my $fn (@_) {
-unless (exists $exclude{$fn} or exists $exclude{"$reldir/$fn"}) {
+if ($binaryfiles->binary_is_allowed($fn) or
+not (exists $exclude{$fn} or exists $exclude{"$reldir/$fn"}))
+{
push @result, $fn;
}
}
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718295: /usr/bin/dpkg-deb: dpkg-deb -Zgzip -z0 produces invalid debian packages
Hi,
On Mon, 29 Jul 2013, Guillem Jover wrote:
> > The linux maintainers chose to pass -Zgzip -z0 to dpkg-deb to retain
> > backwards compatibility.
>
> To retain compatibility they should either not have specified -z at all
> or used -z9. dpkg-deb(1) is pretty clear that -z0 for gzip is equivalent
> to no compression.
They want no compression but they want to work with old dpkg too:
# We don't want to recompress, but -Znone is not compatible with older
# tools and is currently rejected by dak. -Zgzip -z0 has almost the
# same effect.
> At this point I'm tempted to just deprecate -Zgzip -z0. I'll fix this
> in any way for 1.17.2.
Suggested patch (untested):
$ git diff
diff --git a/lib/dpkg/compress.c b/lib/dpkg/compress.c
index 12c694c..63df7af 100644
--- a/lib/dpkg/compress.c
+++ b/lib/dpkg/compress.c
@@ -771,6 +771,8 @@ compressor_get_strategy(const char *name)
bool
compressor_check_params(struct compress_params *params, struct dpkg_error *err)
{
+ compressor_fixup_params(params);
+
if (params->strategy == compressor_strategy_none)
return true;
The fixup function for gzip already switches the compression_type to none, but
it's only called in compress_filter() which happens in a sub-process. Calling
it when we validate the parameters seems a good way to have it happen in the
main process as well and avoid this problem.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716948: [Pkg-sysvinit-devel] Bug#716948: initscripts: Removes bootlogd conf files even if bootlogd is installed
Hi,
On Mon, 15 Jul 2013, Steve Langasek wrote:
> Attached is a tested patch for this. I'm not thrilled about invoking
> dpkg-query -S here, but I don't see any other way to get this information.
As suggested by Guillem, it's better to use "dpkg-query -L pkg | grep -q
-x /path" as you only have to load the file list of one package.
I also factorized the check in a single function and I merged the
resulting patch.
FWIW the pkg-tests test-suite still passes with those changes.
> It also still doesn't give perfect results; if a conffile moves from package
> x to package y, and package x is unpacked before package y, a modified
> conffile will be left behind as .dpkg-bak and the pristine
> conffile from the new package will be unpacked in its place. But I believe
> it is at least as good as the existing code in all cases.
Fixing this requires cooperation from the package taking it over so I
don't see it as a regression either.
There's a separate bug tracking this scenario anyway:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595112
> @@ -197,11 +231,23 @@ prepare_mv_conffile() {
> finish_mv_conffile() {
> local OLDCONFFILE="$1"
> local NEWCONFFILE="$2"
> + local PACKAGE="$2"
Here there was a small bug (caught by pkg-tests since I am calling
dpkg-query -L $PACKAGE).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#584185: dpkg-maintscript-helper: rm_conffile doesn't work when removing last file in directory
Hi, On Sun, 16 Jun 2013, Michael Biebl wrote: > If dpkg-maintscript-helper would move the file outside of /etc, this > issue would be solved. > Raphael, What's the reason you don't consider this a good > idea? Mainly because it means that we're more likely to move it between separate filesystems and thus increase the chances of problems. It also makes it more complicated to handle in dpkg-maintscript-helper (at least if we want to keep the intermediate storage place relatively cruft-free). But the downsides of not doing it are also important so I'm not set on it. I'd consider merging a patch which does it properly. > As for my case (gnome-keyring), I currently see three options: > a/ don't bother cleaning up /etc/pkcs11 > b/ don't use dpkg-maintscripts-helpers, clean up the obsolete conffiles > in preinst (using [2]) and let dpkg remove the empty dir > c/ use dpkg-maintscript-helpers and remove the directory in postinst, > while guarding the rmdir with a dpkg -S check > > Do you have another, better idea? What would be your recommendation? I don't have any better idea right now. Cheers, -- Raphaël Hertzog ◈ Debian Developer Liberate the French translation of the Debian Administrator's Handbook: → http://www.ulule.com/liberation-cahier-admin-debian/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#709064: dpkg: some packages missing metainformation after upgrading dpkg (squeeze->wheezy)
Hello, On Mon, 20 May 2013, Hans-Juergen Becker wrote: > The "missing" files are existing, but doesn't have the ":" in > there filenames: Somehow it means that you have "/var/lib/dpkg/info/format" with a content of "1" when you shouldn't have it yet (you certainly shouldn't have it before you upgraded dpkg). Did you try a first upgrade and then forcefully unpack an older version of dpkg at some point? In theory, when you upgrade to a multiarch dpkg, things keep working as usual (with the old layout) but as soon as you start dpkg on a operation that implies writing to the database, the database gets upgraded to the newer format for files and at that point it creates /var/lib/dpkg/info/format with a value of 1. Note that "dpkg -C" doesn't open the database in write mode so will not trigger the upgrade to a multiarch compatible database. > Now while wrinting this bug report i've noticed that dpkgs' configuration > files also weren't correctly upgraded: A removed conffile is never restored, that's normal behaviour. In any case, the problem is certainly not affecting everybody and if you don't have any idea of what you could have done wrong, it will be difficult to solve. Your log doesn't show the value of /var/lib/dpkg/info/format at the different points, so it's difficul to know where you started from and whether you see a real bug or the result of some bad operation of yours. > Attached is a log of the described problem, containing a -D dpkg > installation - perhaps you can figure something out of it. Nope, it doesn't help much. The new dpkg is installed by the old one. What's interesting is how the new one behaves after the initial installation. And the upgrade code doesn't generate any log message, so the strace output might be more interesting. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708607: Undefined subroutine &main::_ called at /usr/share/perl5/Dpkg/File.pm
Hi, On Thu, 16 May 2013, Lincoln Myers wrote: > Apparently, in this situation the build was being done in a filesystem > where flock() fails to lock. I believe libdpkg-perl was unable to > report the real error properly because it is translating the error > message using nonexistent subroutine "_". I assume it should be using > "_g" instead: Good catch! Committed the fix (along with another instance of the same problem) on the wheezy branch. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#707128: Actually warrant documented "--ignore-missing-info"
Hi Yaroslav, On Tue, 07 May 2013, Yaroslav Halchenko wrote: > now the same "couldn't find library" message could be warning or error, > e.g. > > dpkg-shlibdeps: warning: couldn't find library libmat.so needed by > debian/matlab-psychtoolbox-3-nonfree/usr/lib/matlab/site/psychtoolbox-3/WaitSecs.mexa64 > (ELF format: 'elf64-x86-64'; RPATH: '') > dpkg-shlibdeps: error: couldn't find library libeyelink_core-1.9.so.58 needed > by > debian/matlab-psychtoolbox-3-nonfree/usr/lib/matlab/site/psychtoolbox-3/Eyelink.mexa64 > (ELF format: 'elf64-x86-64'; RPATH: '') The difference between both is that libmat.so is not versioned while libeyelink_core-1.9.so.58 is versioned. The former can't have a shlibs file while the latter can have one (thus a warning in one case and an error in the other). > and in case of the error the whole run of dpkg-shlibdeps fails without > generating substvars. The situation persists even if I use documented: > >--ignore-missing-info > Do not fail if dependency information can't be found for a shared > library. Usage of this option > is discouraged, all libraries should provide dependency information > (either with shlibs files, > or with symbols files) even if they are not yet used by other > packages. > > which from the description sounds precisely what I need, but in the code is > not > influencing decision to exit with error upon $error_count. It does what it says. But it needs to find the library to be able to know that there's no association dependency information. So fix your build depends so that those libraries are available and/or set LD_LIBRARY_PATH to help dpkg-shlibdeps find the library. Honestly, I don't see the purpose of this bug report. What do you believe can be improved? Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#703092: dpkg --set-selections ignores available packages never installed or removed by dpkg
On Wed, 10 Apr 2013, Raphael Hertzog wrote: > The impact was perfectly known. I was also concerned by the change but > Guillem did not want to change his mind. > > See https://lists.debian.org/debian-dpkg/2012/03/msg00065.html and > Guillem's reply in > https://lists.debian.org/debian-dpkg/2012/03/msg00067.html To be a bit more constructive, and assuming that we won't change this at this point of the release, it would be worth to document this change in the release notes to give it a bit more visibility and to make people aware that they have to update the available file first. I'll let Guillem decide, he can reassign or clone the bug. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#703092: dpkg --set-selections ignores available packages never installed or removed by dpkg
Hi, On Wed, 10 Apr 2013, Jonathan Nieder wrote: > > It might look harmless, but we do *NOT* want to release Debian > > with a dpkg that is broken with respect to all the descriptions > > floating around how to clone a system. > > I agree that this is a problem, but I cannot convince myself it breaks > the entire system. Therefore I'm lowering the severity. > > Presumably this is due to > > 1.16.2~15 dpkg: Only allow setting selections for known packages, > 2012-03-17 > > It is a shame the impact of that commit on existing workflows was not > noticed until a year later. Guillem, can you say a little about the > motivation behind the change? Would it be safe to revert it? The impact was perfectly known. I was also concerned by the change but Guillem did not want to change his mind. See https://lists.debian.org/debian-dpkg/2012/03/msg00065.html and Guillem's reply in https://lists.debian.org/debian-dpkg/2012/03/msg00067.html Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700978: libdpkg-perl: perl -w + Dpkg::Source::Package + Dpkg::Source::Archive causes redefine error
Control: tag -1 patch
On Tue, 19 Feb 2013, Niels Thykier wrote:
> """
> $ perl -w -MDpkg::Source::Package -MDpkg::Source::Archive -e ''
> Subroutine Dpkg::Source::Archive::getcwd redefined at
> /usr/share/perl/5.14/Exporter.pm line 67.
> at /usr/share/perl5/Dpkg/Source/Archive.pm line 32
> """
In fact loading Dpkg::Source::Archive is enough to trigger it. This is
due to POSIX and Cwd both exporting getcwd().
The attached patch should fix the issue. I'll let Guillem commit it
on his private 1.17.x branch unless he believes that it should be fixed
in wheezy, which might not be a bad idea. I wonder why we didn't detect
it sooner, did something changes the perl level recently ?
I have modified the getcwd into Cwd::getcwd because that's the copy we
have been using up to now and because Cwd is still needed for
Cwd::realpath but it's not really required.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
>From 9b428318889529530920cdfd0f382841e7ad05d9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?=
Date: Wed, 20 Feb 2013 08:45:02 +0100
Subject: [PATCH] Dpkg::Source::Archive: do not import anything from Cwd.pm
Both POSIX and Cwd export "getcwd" by default so we ended up with
this annoying warning:
Subroutine Dpkg::Source::Archive::getcwd redefined at /usr/share/perl/5.14/Exporter.pm line 67.
at /usr/share/perl5/Dpkg/Source/Archive.pm line 32
Reported-by: Niels Thykier
Closes: #700978
---
scripts/Dpkg/Source/Archive.pm |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/Dpkg/Source/Archive.pm b/scripts/Dpkg/Source/Archive.pm
index 5e040ca..0257603 100644
--- a/scripts/Dpkg/Source/Archive.pm
+++ b/scripts/Dpkg/Source/Archive.pm
@@ -29,7 +29,7 @@ use POSIX;
use File::Temp qw(tempdir);
use File::Basename qw(basename);
use File::Spec;
-use Cwd;
+use Cwd qw();
use base 'Dpkg::Compression::FileHandle';
@@ -52,7 +52,7 @@ sub create {
'--owner', '0', '--group', '0',
@{$opts{"options"}}, '-cf', '-' ];
*$self->{"pid"} = spawn(%spawn_opts);
-*$self->{"cwd"} = getcwd();
+*$self->{"cwd"} = Cwd::getcwd();
}
sub _add_entry {
--
1.7.10.4
Bug#583585: dpkg-maintscript-helper: replace symlink with directory
Hi, sorry for the big delay in my answer. On Sat, 01 Dec 2012, Gregor Jasny wrote: > There are some open questions on my side: > 1) Do you see a demand to also require a LASTVERSION argument? Yes. We always want to restrict such code to be only executed when really needed. Think for example when you have an history where you switched a path back and forth between a directory and a symlink. You don't want to execute both commands for any upgrade... > 2) Shold I also check where $SYMLINK.dpkg-remove is pointing to in the > post* scripts? I don't see the need for this. > 3) Is there a testbed where I can add tests for this? We have a pkg-tests.git repository, see explanations in http://wiki.debian.org/Teams/Dpkg/Contribute There are already some tests for dpkg-maintscript-helper in it. > 4) What about downgrading packages? Would that be an use case, too? Yes. I always try to take it into account in dpkg-maintscript-helper. That said I would not make it a requirement to merge this new command. But this alone justifies the LASTVERSION parameter, so that downgrade support can at least be implemented... > + if [ "$1" = "install" -o "$1" = "upgrade" ] && [ -n "$2" ] && [ > -L "$SYMLINK" ] && [ "$(readlink "$SYMLINK")" = "$SYMLINK_TARGET" ]; then > + mv -f "$SYMLINK" "$SYMLINK.dpkg-remove" Please do not use "-L" but "-h" (-L is non-standard). Otherwise it looks like a good start. Thanks for trying to tackle this! Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700177: dpkg-dev: please reject native/non-native version when building native/non-native source packages
Hi, On Sat, 09 Feb 2013, Bernhard R. Link wrote: > Please ensure that the package version matches its nativity state > in 3.0 (quilt/native) packages. Having dpkg-source allow to create > native packages with non-native versions and non-native packages with > native versions can be quite confusing, so better reject them directly. Right, but we have quite a few packages with such versions: http://lintian.debian.org/tags/native-package-with-dash-version.html And I'm pretty sure that some people are using native packages on purpose for packages where they are not upstream. I would not apply this change without a prior discussion on debian-devel resulting in some consensus about this change. Non-native packages with native versions are much less common so this part of the change is certainly less problematic. http://lintian.debian.org/tags/non-native-package-with-native-version.html > (Attached patch does this for 3.0 (quilt) and 3.0 (native) packages, > where this change should be safe to be done and does not touch any legacy > source package formats). Why do you consider it safer for 3.0 formats than for 1.0? Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699111: dpkg-gensymbols: Add option for generating c++ demangled symbols
Hi, On Sun, 27 Jan 2013, Nick Andrik wrote: > I am packaging a library implemented in C++ . > During my effort to generate sane symbol files for it, I saw that C++ symbols > differ among architectures. > > One way to avoid having different symbols files for each architecture is to > use > the demangled names for C++ methods. This doesn't cover all the problems of differing files between architectures. You might want to look into some of the KDE tools to deal with C++ libraries. Modestas Vainius has developed some useful helper tools (in pkg-kde-tools). > Would it be possible to have dpkg-gensymbols generate c++ demangled names > automatically? > This could be specified by an argument, e.g. dpkg-gensymbols -x Maybe. It's easier to tell if we can judge a patch. Up to now I refused to integrate partial solutions but this feature could be useful and might not require cloberring the code with hacks all over the place. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#696853: "dpkg-checkbuilddeps -C somedir", please?
Hi, On Fri, 28 Dec 2012, Harald Dunkel wrote: > Would it be possible to support a command line argument > "-C somedir" to run dpkg-checkbuilddeps in another > directory without pushd and popd and a temporary variable > to safe the exit value? > > This would be very similar to "make -C somedir". dpkg-checkbuilddeps accepts the path to the "control" file that it should use. So "dpkg-checkbuilddeps -C somedir" is actually the same as "dpkg-checkbuilddeps somedir/debian/control" and there's no need to introduce a new option. Let me know if this matches your need. If yes, I shall close this bug. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695800: dpkg --print-multiarch needed
Control: forcemerge 636352 -1 On Wed, 12 Dec 2012, Matthias Klose wrote: > dpkg --print-architecture currently can be used to get the name of the current > architecture, however nothing does exist for getting the current multiarch. I guess you mean the multiarch tuple exported as DEB_HOST_MULTIARCH by dpkg-architecture. There's already a bug about this (#636352). You might want to read the corresponding discussion and see if you can provide another valid use case for this information. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692966: dpkg: Same trigger is run several times during 1 install / upgrade
Control: reassign -1 apt Control: forcemerge 626599 -1 On Sun, 11 Nov 2012, Kurt Roeckx wrote: > dpkg processes the same trigger several times during 1 upgrade or > install. > > I mostly see for triggers on the man-db and initramfs-tools > package. I would like to avoid all those processed triggers, > since the point of the triggers was that those would only > need to be done once in the first place. The issue is not on the dpkg side but on the APT side. See #626599. APT should use --no-triggers during unpack. We should poke the APT team at the start of the jessie cycle to make sure that nobody forgets about it. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681474: Dpkg::Vendor: should support /etc/os-release and /etc/os-release.d/*
On Mon, 29 Oct 2012, Jonathan Nieder wrote: > Raphael Hertzog wrote: > > > In both cases the purpose of the file is to provide identification > > information about the OS. > > Identification for what purpose? So I know which programmer to > complain to when running into compatibility bugs, like the HTTP > User-Agent field? For display and theming? To distinguish between > package managers? To help automatic bug reporting tools? To make > sure my programs present subtly different bugs on each system, like > the ACPI _OSI method? Surely you don't have to invent X ways to identify the OS just because you want to identify it in different contexts? Using a single source is just a better design that avoids mistakes where /etc/dpkg/origins/default says Debian and /etc/os-release says Mint (or similar, it's just an example). > os-release is a very nice way to make sure vendor scripts that want to > rely on details about an OS (or even to just collect statistics) do > not need to separately check for /etc/debian_version, > /etc/redhat_release, etc, but I don't see what it has to do with dpkg. dpkg uses /etc/dpkg/origins/default to find out the name of the current vendor (and possibily embed it in the generated .deb at some point) and to adjust dpkg-dev's behaviour at build-time. It also uses the parent relationship for the latter purpose. Both information are already available in /etc/os-release as ID and ID_LIKE. Guillem said that it was counter-productive in case like Fink where we would not want to use ID=macosx. This could be dealt with a new DPKG_VENDOR variable that would override ID for the specific usage of dpkg when there's such a conflict. The other remaining information (Vendor-URL, Bugs) are provided by HOME_URL and BUG_REPORT_URL. Why duplicate the information at the dpkg level when this is clearly system-wide vendor information? Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681474: Dpkg::Vendor: should support /etc/os-release and /etc/os-release.d/*
On Sun, 28 Oct 2012, Jonathan Nieder wrote: > Raphael Hertzog wrote: > > > Why would it be better to deploy a > > dpkg-specific file over a generic file even if dpkg is the only software > > making use of that generic file? > > Because it makes the purpose of the file clearer, and if other > programs make use of files with similar but distinct purposes then > those files can have different content. In both cases the purpose of the file is to provide identification information about the OS. In both cases, we have an extendable field oriented structure to cater for possible extensions (for tightly related purpose not yet imagined). So while I can understand the theorical objection, I don't see how it could apply to this specific case. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681474: Dpkg::Vendor: should support /etc/os-release and /etc/os-release.d/*
Hi, On Sat, 27 Oct 2012, Guillem Jover wrote: > Control: tag -1 wontfix *shrug* I filed it because I did not found the time to implement it in a reasonable delay. But I might still want to implement it at some point. > On Fri, 2012-07-13 at 15:44:22 +0200, Raphael Hertzog wrote: > > To be able to retrieve information from all the parents, the various > > os-release files can be stored in /etc/os-release.d/ and /etc/os-release > > could become a symlink. > > I doubt this will be done by other distributions anyway. Our derivatives did it for /etc/dpkg/origins and I don't see why they would not follow this as well. > > Dpkg::Vendor should thus be updated to be able to use those (cross-distro > > standardized) > > I guess by “cross-distro standardized” you mean unilateral systemd-Linux > specific “standard”, because I don't see non-Linux systems adopting this, > not even all GNU/Linux distros, and certainly not for something like > dpkg, which would imply deploying a generic file only for dpkg use. And > in that case the dpkg origin files would need to be suppored anyway, > which means that supporting os-release is pointless. I don't see why dpkg origin files would have to be supported indefinitely. We can deprecate them just like any other feature and ask people to use /etc/os-release & /etc/os-release.d/. You argumentation does not hold. Why would it be better to deploy a dpkg-specific file over a generic file even if dpkg is the only software making use of that generic file? You're free to not like systemd, Loennart Poettering, or both. But in this specific case, I find this standardization effort a good idea and I don't see much downsides in adopting it. > This is the equivalent of wanting to add support for lsb_release... Except lsb_release is a command line interface and it's not always installed. /etc/os-release is a file with a defined format that's always going to be there on Debian systems since base-files installs it. > > files when they exist so that we can deprecate the > > debian-specific /etc/dpkg/origins/*. > > I guess you mean dpkg-specific, because there's nothing Debian-specific > about those, but in any case I strongly disagree with deprecating them. Right, dpkg-specific. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689508: dpkg: taking over a conffile via Breaks/Replaces leaves the entry in the Conffiles: entry in the status file of the old package
Control: reassign -1 debsums Control: retitle -1 ignore obsolete conffiles which are not owned by the package On Wed, 03 Oct 2012, Andreas Beckmann wrote: > seems to work, also if the conffile gets replaced by an updated version > on the way, but it leaves an old md5sum entry in the Conffiles entry of > old-pkg in the status file. > > This causes subsequent debsums runs to report modified files (for a > package which no longer owns the file). That entry in Conffiles is marked "obsolete" and as you point out, the package is no longer owning the conffile (i.e. the file is no longer listed in the output of dpkg -L). I believe that debsums should just ignore those entries. dpkg probably ought to drop the entry in Conffiles as you suggest but that's already requested in #645849. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#685863: dpkg: The auto complete fail, for dpkg --print-foreign-architecture, end to unknown option.
Control: submitter -1 guillaumese...@gmail.com On Mon, 03 Sep 2012, Guillaume Seren wrote: > I just released that my mail, was misspelled, in my .reportbugrc, the > good one is : guillaumese...@gmail.com . Fixing in the BTS. > I patch the source, (from the git diff) and install it again, > but, the completion, seems to behave the same, > do you have a specific process, after, installing, the patched dpkg, > to get to right completion ? No, there's nothing special to do. You can try to install the packages which are auto-built from git: http://jenkins.grml.org/view/Debian/job/dpkg-binaries/ Here's the current .deb for dpkg on amd64: http://jenkins.grml.org/view/Debian/job/dpkg-binaries/architecture=amd64/116/artifact/dpkg_1.16.9%7E1345993535.132_amd64.deb Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#685863: dpkg: The auto complete fail, for dpkg --print-foreign-architecture, end to unknown option.
On Sat, 25 Aug 2012, Guillem Jover wrote: > I'm not sure I understand what the problem being reported here is, but > from the mail subject I'd guess you typed: > > $ dpkg --print-foreign-architecture > > and that didn't work (due to missing trailing ‘s‘)? > > If so then you just need to type the correct option name, if this was > due to command-line auto-completion then this should get reassigned to > whatever package is handling your shell auto-completion (depending on > your shell used). I just checked here and I have the same problem with bash-completion but bash-completion apparently parses the output of dpkg --help. The error is really in dpkg's French usage string: po/fr.po:" --print-foreign-architecture Afficher les architectures inconnues\n" Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671711: Assumptions when processing triggers (was [pkg-mono-group] Bug#671711: monodoc-browser: fails to upgrade) from 'testing'
Hi, On Fri, 08 Jun 2012, Guillem Jover wrote: > Hmmm, so I had prepared a patch which basically checks if the package > has its dependencies fulfilled before calling the postinst script with > "triggered", and otherwise defers the trigger processing for later (but > only as long as it is not running from inside the deferred trigproc run). Since #680626 showed that this is a recurring problem, it would be nice if we could do supplementary tests with the fixed dpkg to get a better idea of the amount of problems that it creates. Can you push your fix somewhere so that we can make tests? > This fixes this specific case just fine (t-triggers-depends test > case in dpkg/pkg-tests.git), but this in turn creates problems with > packages with pending triggers depending on packages awaiting them, > as it forces breaking trigger cycles, which is not really a nice > upgrade path. Because of the trigger cycles, you opted to change nothing. What about enforcing some requirements which are less strong that the one desired? (Probably only as a temporary stop-gap measure until we're able to switch back to the full requirement) The problematic fix is to ensure the same requirements for "postinst triggered" as for "postinst configure". But we could enforce some requirements that would probably solve the issues we saw without introducing cycles. Indeed, I believe it's relatively safe to run "postinst triggered" when: - the dependencies are at least in status triggers-awaited (this would go counter the logic that triggers-awaited package are not really configured, but it would acknowledge the fact that most packages should use "interest-noawait" instead) - the dependency was already configured in a version (Config-Version field) which satisfies the dependency What do you think? Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683547: dpkg-source fails on a patch series deleting a file after patching
Control: tag 683547 + patch
On Wed, 01 Aug 2012, Thomas Koch wrote:
> It might not be a good idea in the first place to have such a patch series.
> But
> dpkg-source --after-build fails on it. It can not copy the original file
> because
> the parent directory of the original file does not exist anymore.
>
> I suspect, that the patch command deleted all empty parent directories as
> described for the -remove-empty-files option. I tried to provide a fix that
> calls make_path($target_dir) in scripts/Dpkg/Source/Quilt.pm but I failed
> perl.
You diagnosed the problem correctly. This is effectively a regression
because we had no such problem when we used "patch -R" to unapply the
patches. Now that we use the quilt backup files instead, we're affected by
this issue.
I attach my suggested patch. Please try it.
I will certainly push this to master for inclusion in wheezy since
it's a regression introduced by my changes in dpkg 1.16.5.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
>From 135833c9fe7c6c2f4dc90fd9eb41d75165fb4daa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?=
Date: Wed, 1 Aug 2012 21:18:07 +0200
Subject: [PATCH] Dpkg::Source::Quilt: ensure the target directory exist
before copying files
When we restore files in the pop operation, the target directory is
usually pre-existing, but in the case where the patch is removing all the
files in the directory, the usage of patch's --remove-empty-files lead to
the removal of the parent directories which are empty.
This caused a regression in dpkg-source's handling of "3.0 (quilt)" source
package since this case was not causing any problem when the patch
were unapplied with "patch -R" (patch creates the required directories).
Reported-by: Thomas Koch
Closes: #683547
---
debian/changelog |4
scripts/Dpkg/Source/Quilt.pm |3 +++
2 files changed, 7 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index 5e4245c..cf28bb5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,9 @@
dpkg (1.16.9) UNRELEASED; urgency=low
+ [ Raphaël Hertzog ]
+ * Fix dpkg-source regression in "3.0 (quilt)" source packages while
+unapplying patches that remove all files in a directory. Closes: #683547
+
[ Updated programs translations ]
* Czech (Miroslav Kure).
diff --git a/scripts/Dpkg/Source/Quilt.pm b/scripts/Dpkg/Source/Quilt.pm
index 25819df..5ca9fb7 100644
--- a/scripts/Dpkg/Source/Quilt.pm
+++ b/scripts/Dpkg/Source/Quilt.pm
@@ -29,6 +29,8 @@ use Dpkg::Vendor qw(get_current_vendor);
use File::Spec;
use File::Copy;
use File::Find;
+use File::Path qw(make_path);
+use File::Basename;
sub new {
my ($this, $dir, %opts) = @_;
@@ -287,6 +289,7 @@ sub restore_quilt_backup_files {
my $target = File::Spec->catfile($self->{'dir'}, $relpath_in_srcpkg);
if (-s $_) {
unlink($target);
+make_path(dirname($target));
unless (link($_, $target)) {
copy($_, $target) ||
syserr(_g("failed to copy %s to %s"), $_, $target);
--
1.7.10.4
Bug#595112: /usr/bin/dpkg-maintscript-helper: Please provide helper for moving a conffile between packages
On Tue, 31 Jul 2012, Josh Triplett wrote: > Consider the original motivation for this. You have a package A, which > contains a daemon B and an init script /etc/init.d/B. You split B and > its init script (and any other configuration files for it) into its own > package, which A does not depend on. If installing B, you want to > preserve the configuration of B. B didn't exist beforehand, so no > package exists for A to declare a Breaks against. However, nothing > guarantees that the user will install B at the same time as upgrading A. > In particular, it seems highly likely that a user who wants B will > upgrade A, read the NEWS.Debian file, and then choose whether to install > B. OK so we really need a "recover_conffile" which would be used in package2 and would move a .dpkg-bak copy in its original place. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595112: /usr/bin/dpkg-maintscript-helper: Please provide helper for moving a conffile between packages
Hi, On Fri, 13 Jul 2012, Josh Triplett wrote: > On Fri, Jul 13, 2012 at 05:26:28PM +0200, Raphael Hertzog wrote: > > Michael Biebl reported in the thread at > > http://lists.debian.org/4f31c323.9090...@debian.org > > that the difficulty was to handle the case where the target > > package has no guaranty to be installed. In that case, we > > might keep the old conffile around when we don't really > > want. > > > > In http://lists.debian.org/20120209095814.ga3...@rivendell.home.ouaza.com > > I suggested to create a rm_conffile_if_owner helper > > function to deal with this case. > > > > Would this fit your needs too? > > I *think* that would work. I don't need support for moving conffiles > between arbitrary packages, just support for allowing package2 to take > over a conffile from package1, and allowing package1 to drop the > conffile if not installing package2. How would rm_conffile_if_owner > behave with a modified conffile? Just like rm_conffile. It would keep a ".dpkg-bak" copy of the file. > Would it keep the conffile around in a way that allows the new package > to take it over with the old contents still intact? Hum, not sure. At least I was not intending it that way. I was rather imagining that the dependencies would force the upgrade of the target package at the same time. That is package1 would break the versions of package2 that don't have the conffile. That way, in package1's postinst we can be sure that: - either package2 has taken the file over - or package2 is not installed > And, would this also ensure that the conffile (even if modified) gets > removed when purging package1, if not yet taken over by package2? Yes, that should be part of the contract of rm_conffile_if_owner. But it will only have to deal with this in the case of a modified conffile (since the non-modified conffile would be pruned before-hand in the postinst). Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#316521: dpkg: stale directories are not removed after 'postrm purge'
Hi, On Mon, 16 Jul 2012, Andreas Beckmann wrote: > Would there be a chance to get this applied in wheezy if it doesn't show > problems? First off, Guillem need to ack the patch. Then it's somewhat unlikely to be accepted by the release managers. You can always ask them though. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595112: /usr/bin/dpkg-maintscript-helper: Please provide helper for moving a conffile between packages
retitle 595112 dpkg-maintscript-helper: new helper for moving a conffile between packages thanks On Tue, 31 Aug 2010, Josh Triplett wrote: > Moving a conffile from one package to another seems to prove even more > difficult than renaming it or removing it. Please consider providing > support for this case in dpkg-maintscript-helper. What kind of problems are you referring to? Michael Biebl reported in the thread at http://lists.debian.org/4f31c323.9090...@debian.org that the difficulty was to handle the case where the target package has no guaranty to be installed. In that case, we might keep the old conffile around when we don't really want. In http://lists.debian.org/20120209095814.ga3...@rivendell.home.ouaza.com I suggested to create a rm_conffile_if_owner helper function to deal with this case. Would this fit your needs too? Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681477: dpkg-vendor: implement --select-closest command versions
Package: dpkg-dev Version: 1.16.7 Severity: wishlist User: d...@packages.debian.org Usertags: dpkg-vendor The --derives-from command works but when you have multiple levels of derivatives, it imposes you to order your checks in the correct order to have the expected behaviour. It's also not reliable in the case where the derivative relationships are symmetric (i.e. like RedHat and Fedora which are evolving in parallel but building on each another). This symmetric relationship is explicitely allowed in the ID_LIKE field of /etc/os-release. Therefore I suggest to implement a "dpkg-vendor --select-closest ..." command that would compare all the listed distributions and that would return the distribution which is closest to the current distribution. This enables us to do: TARGET_VENDOR := $(shell dpkg-vendor --select-closest debian ubuntu mint) ifeq($(TARGET_VENDOR),mint) # Mint specific options else ifeq($(TARGET_VENDOR),ubuntu) # Ubuntu specific options else ifeq($(TARGET_VENDOR),debian) # Debian specific options endif This command can be reliably implemented with /etc/dpkg/origin/* and with /etc/os-release since the latter orders the derivatives listed in ID_LIKE from the closest to the furthest. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681474: Dpkg::Vendor: should support /etc/os-release and /etc/os-release.d/*
Package: libdpkg-perl Version: 1.16.7 Severity: wishlist Debian is now shipping an /etc/os-release file and this file can provide all the information that /etc/dpkg/origins/* files can provide. See http://www.freedesktop.org/software/systemd/man/os-release.html for the various fields that are supported and in particular ID_LIKE, HOME_URL and BUG_REPORT_URL. To be able to retrieve information from all the parents, the various os-release files can be stored in /etc/os-release.d/ and /etc/os-release could become a symlink. Dpkg::Vendor should thus be updated to be able to use those (cross-distro standardized) files when they exist so that we can deprecate the debian-specific /etc/dpkg/origins/*. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681470: dpkg-shlibdeps: should also scan Build-Depends-Arch for minimal versions
Package: dpkg-dev Version: 1.16.4 Severity: normal User: d...@packages.debian.org Usertags: dpkg-shlibdeps dpkg 1.16.4 introduced the Build-Depends-Arch field but dpkg-shlibdeps has not been updated to deal with this field. Build dependencies are sometimes scanned to find out minimal versions to inject in binary package dependencies. Build-Depends-Indep are not scanned because by definition a library dependency required to build an executable can not be put there. However Build-Depends-Arch can perfectly host such build dependencies and thus dpkg-shlibdeps should be updated to scan them too. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#316521: dpkg: stale directories are not removed after 'postrm purge'
Hi,
On Thu, 08 Mar 2012, Andreas Beckmann wrote:
> (regarding the original problem:)
> I'm seeing a lot of owned directories remaining in the piuparts tests for sid
> (they are treated as error for sid and warning for other distributions):
> http://piuparts.debian.org/sid/owned_files_by_many_packages_error.html
> http://piuparts.debian.org/sid/owned_files_after_purge_error.html
>
> I tried to create a minimal package that triggers the behaviour. Looks
> like it is related to directories owned by multiple packages and their
> removal order.
Basically, this is a variant of the test case "t-dir-leftover-deadlock":
http://anonscm.debian.org/gitweb/?p=dpkg/pkg-tests.git;a=tree;f=t-dir-leftover-deadlock;h=604270fa0caa72f31e5e1d73ec0f6fa02bd84f91;hb=master
And your analysis is correct.
We know a solution to the problem which is basically to not forget about
directories shared with other packages. But this approach leads us to
keep ownership of lots of directories which are not really needed.
But the more I think about it, the more I'm convinced that it's
the least evil solution until we have a way to register arbitrary files in
dpkg. (I don't really like the complexity of the dpkg-maintscript-helper
snippet we discussed)
I would suggest to go with the attached patch which imposes just a
supplementary restriction. It will only remember shared directories
if the package has a postrm script (and thus has a chance to do something
during purge).
I believe this would make a good enough compromise. The number of useless
directory ownerships is much less problematic than the failure to properly
cleanup.
Another restriction which I did not implement but that we could implement
is that we can safely forget about directories which are shared but which
are empty. (But it would not make a huge difference because I don't know
of many shared directories that stay empty)
Cheers,
PS: In the attached patch, I wondered whether it was best to duplicate
foundpostrm or to modify the prototype of removal_bulk_remove_files()
so that removal_bulk() could forward it (since it already computes it).
Since boolean parameter are best avoided I opted to duplicate it.
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
>From 0c28f55065c671572849f2cbc1f8cf37f9946c31 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?=
Date: Fri, 13 Jul 2012 10:45:33 +0200
Subject: [PATCH] dpkg: do not forget about shared directories if we have a
postrm script
This is meant to fix the case where the postrm purge is responsible of
removing a file that might be in those directories.
Closes: #316521
---
src/remove.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/remove.c b/src/remove.c
index 95ea98f..a1c0a2e 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -240,12 +240,15 @@ static void
removal_bulk_remove_files(struct pkginfo *pkg)
{
int before;
+ bool foundpostrm;
struct reversefilelistiter rlistit;
struct fileinlist *leftover;
struct filenamenode *namenode;
static struct varbuf fnvb;
struct stat stab;
+foundpostrm = pkg_infodb_has_file(pkg, &pkg->installed, POSTRMFILE);
+
pkg_set_status(pkg, stat_halfinstalled);
modstatdb_note(pkg);
push_checkpoint(~ehflag_bombout, ehflag_normaltidy);
@@ -301,8 +304,9 @@ removal_bulk_remove_files(struct pkginfo *pkg)
if (is_dir) {
debug(dbg_eachfiledetail, "removal_bulk is a directory");
/* Only delete a directory or a link to one if we're the only
- * package which uses it. Other files should only be listed
- * in this package (but we don't check). */
+ * package which uses it. Ensure we don't forget about it
+ * in all the cases where we might have to retry its removal
+ * during purge. */
if (dir_has_conffiles(namenode, pkg)) {
push_leftover(&leftover,namenode);
continue;
@@ -311,8 +315,11 @@ removal_bulk_remove_files(struct pkginfo *pkg)
push_leftover(&leftover, namenode);
continue;
}
-if (dir_is_used_by_others(namenode, pkg))
+if (dir_is_used_by_others(namenode, pkg)) {
+ if (foundpostrm)
+push_leftover(&leftover, namenode);
continue;
+}
}
debug(dbg_eachfiledetail, "removal_bulk removing '%s'", fnvb.buf);
if (!rmdir(fnvb.buf) || errno == ENOENT || errno == ELOOP) continue;
--
1.7.10.4
Bug#680155: dpkg-source: detection of applied patches fails if first patch is reverted
Hi, On Tue, 03 Jul 2012, David Bremner wrote: > If the first patch in a 3.0 (quilt) series is reverted by later > patches in the series, then the heuristic used by dpkg-source to > detect if patches are applied fails. This might sound contrived, but > it can arise if e.g. patches are generated from a version control > system. > > A workaround is to add "no-preparation" to options or local-options; > I'm not sure if a nicer solution is possible. Just to confirm that we speak of the same thing... you have all patches applied but you don't have the corresponding quilt metadata in ".pc". When you build the source package, dpkg-source tries to apply all the patches because it detected that the first patch could be applied but it fails on the second patch because it's already applied. Is that right? I'm also not sure that there's any nicer solution... this "feature" has been there to ease the transition between 1.0 and 3.0 (quilt) mainly. I was not expecting that people would continue to create new packages where patches would be pre-applied without the corresponding quilt metadata. What's your use case? Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671074: dpkg-buildpackage: option for building multiple times in a row
Hi, On Mon, 02 Jul 2012, Jakub Wilk wrote: > In any case, arguing other this is not a productive use of my time. > dpkg developers: if you are are not interested in the patch I > proposed, please tell me as soon as possible, so that I can close > the bug and work on another (inferior) solution to my problem. I would like to provide something to help you build a clean solution but I believe that the current patch isn't that thing. That said it's not clear to me what the proper solution would be. It probably involves abstracting the work of dpkg-buildpackage in a dedicated perl module and making it possible to use alternate implementation at the same time. That alternate implementation could reuse the default implementation and call it in a loop. But maybe others have better ideas. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'
Hi, On Sun, 17 Jun 2012, Julien Cristau wrote: > On Sun, Jun 17, 2012 at 19:46:50 +0200, Guillem Jover wrote: > > But you can silence it yourself, by installing libfile-fcntllock-perl, > > or is that a problem? > > I'm not installing anything I don't have to in any build chroot, no. The only reason why it's not a Depends is to avoid a bootstrapping issue when a new upstream version of Perl comes out. See #675947. So the goal was clearly to get it installed by default. OTOH, having it installed might forbid the chroot to be upgraded to the new perl so it might create problems of its own when we want to switch to a new Perl. :-| Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676442: dpkg-vendor is slow
Hi, On Sat, 16 Jun 2012, Benjamin Drung wrote: > debchange uses dpkg-vendor to query the vendor. «dch -e ''» takes 1.3 s > with the query to dpkg-vendor and 1.1 s without that query. That's 15 % > of the total execution time. Having a slow debchange is annoying. The > time is accumulating if debchange is run multiple times (like in the > test suite of devscripts). Then debchange could use Dpkg::Vendor directly. It would avoid forking and doing IPC... > dpkg-vendor should be fast to use in it bashrc or in bash completion > code. I'm not sure why that should be the case? Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661538: Patch generalization and field to mark staged packages
On Wed, 13 Jun 2012, P. J. McDermott wrote:
> Fair enough. I think a separate hash could address both of these points:
>
> sub field_get($) {
> my ($field) = @_;
> return $FIELDS{$field} if exists $FIELDS{$field};
> foreach my $key (keys %FIELDS_RE) {
> return $FIELDS_RE{$key} if $field =~ m/^$key$/;
> }
> return undef;
> }
>
> Would this be acceptable?
Yes.
> Do you have a preference between the supplementary attribute and the
> separate hash?
I tend to prefer the separate hash currently. If I change my mind during
the review, it's easy to convert to the other way.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661538: Patch generalization and field to mark staged packages
On Tue, 12 Jun 2012, P. J. McDermott wrote:
> And the subroutines in Dpkg::Control::Fields that get values from
> %FIELDS can call the following new subroutine to do so:
>
> sub field_get($) {
> my ($field) = @_;
> foreach my $key (keys %FIELDS) {
> return $FIELDS{$key} if $field =~ m/^$key$/;
> }
> return undef;
> }
>
> This should be fairly unintrusive. I'll test this further and check to
> see if I've overlooked any complications before adding this to Wookey's
> patch. Does this solution look obviously wrong in any way?
It's sub-optimal. If we go that way, I would like:
1/ that you try direct access first, and fallback to use pattern matching
only if the direct access failed
2/ use pattern matching only on fields that actually are patterns (i.e.
you should tag them with a supplementary attribute, or you should put them
in a separate hash)
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661538: Patch generalization and field to mark staged packages
Hi,
On Thu, 07 Jun 2012, P. J. McDermott wrote:
> Generalization
> ==
[...]
> Rather than modifying a lot of dpkg code to handle field "patterns" or
> the like, I propose a simple dynamic definition of "Build-Depends-
> StageN" and "Build-Depends-Indep-StageN" hash elements in %FIELDS:
>
> 'Build-Depends-Stage'.$buildstage => {
> allowed => ALL_SRC,
> dependency => 'normal',
> dep_order => 3,
> },
>
> Then $buildstage could be defined by parsing DEB_BUILD_OPTIONS in
> Dpkg::Control::Fields.
This is not OK. It means that those fields would be basically unknown
when you're not doing a staged build. Yet they are always present
in debian/control (and probably the .dsc) and thus they need to exist
in that hash to avoid warnings, and to be able to output them in the
correct order, etc.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675947: Circular build-dependency between libfile-fcntllock-perl and dpkg-dev
On Mon, 04 Jun 2012, Dominic Hargreaves wrote: > I wasn't sure if the small amount of code which could be factored out > justified a new file (and couldn't see an exisiting one), so I left it > in the scripts. Happy to refactor into a new or existing file if you > let me know your preference. I think it's better to factor it out in a Dpkg::Lock module. Mark the interface of that module as unstable ($VERSION = "0.1") though, because it will require some further thoughts before becoming part of the public API. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675947: Circular build-dependency between libfile-fcntllock-perl and dpkg-dev
Hi, On Mon, 04 Jun 2012, Dominic Hargreaves wrote: > The attached patch solves this by using flock() which is built into > perl, rather than an external library. My understanding is that this > should be adequate for the purpose, but please let me know if I've missed > something and there is a strong reason to use File::FcntlLock instead > (if so, maybe we could make the relationship to libfile-fcntllock-perl a > recommends, and abort if we detect that a parallel build is being invoked > without File::FcntlLock being installed). There was a reason, reviewing http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642608 tells you that we wanted locking to work on NFS too, so we wanted to use fcntl()-based locking instead of flock()-based locking. And using fcntl() directly from Perl is difficult. Quoting Guillem: | to lock using fcntl(2) the function needs a struct flock which would | need to be packed from the perl code, but the order of its members is not | standardized anywhere, and sizeof(off_t) might vary, that's what seems | tricky to me. I think that we probably want to abstract the locking code and use File::FcntlLock when available and fallback to flock() otherwise so that we can demote it to Recommends. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664058: dpkg-dev: please add action to dpkg-buildflags to get an overview of the settings
Hi, On Mon, 19 Mar 2012, Raphael Hertzog wrote: > On Mon, 19 Mar 2012, Bernhard R. Link wrote: > > I undestand that since 1.16.2 was released in between, I need > > to change the version? Attached are new versions of this patches > > with the version changed. > > Yes, thank you. > > Guillem, what's your opinion on the output of the --status command? > > Bernhard and I seem to have different preference for it (start/end marker > vs fixed prefix on all lines). Guillem, any opinion? Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#644193: Processed: Re: Bug#644193 closed by Jelmer Vernooij (Not a bug in bzr-builddeb)
Hello, On Thu, 31 May 2012, Debian Bug Tracking System wrote: > > reopen 644193 If you reopen a bug, the least you can do is to give some justification of why you're doing this... The behaviour change has been made on purpose. If your packages fails to build due to this, then your package is broken and needs to be fixed to properly cleanup (or ignore) auto-generated files (or whatever else modifies upstream files). Without further information, this bug should be closed. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674981: dpkg-dev: support uncompressed .orig.tar
Hi, On Mon, 28 May 2012, shawn wrote: > I was working on a ftbfs on armel/armhf > and b/c bzip2 is so slow on a slow armel I decompressed the .orig.bz2, > only to learn that I had to recompress it .gz in order for dpkg-source to > recognize it. As Guillem said, do your test builds with "debuild -b" (or -B). That way you don't generate the source package and you avoid this cost... This bug should be closed IMO. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671460: possibly wrong debug output in rm_conffile
Hi, On Fri, 04 May 2012, Marc Haber wrote: > in dpkg-maintscript-helper's rm_conffile function, the code goes to > lengths to set the PACKAGE variable correctly, but the debug output > "Executing $0 rm_conffile ..." still refers to > DPKG_MAINTSCRIPT_PACKAGE which may not be set. PACKAGE, however, seems > to be correct in more cases. Well, we already require DPKG_MAINTSCRIPT_NAME and it's rather unlikely that one would manually set DPKG_MAINTSCRIPT_NAME but not DPKG_MAINTSCRIPT_PACKAGE. Even debconf, which used to not set those variables at all, is now correctly setting them. So I really don't see in what situation DPKG_MAINTSCRIPT_PACKAGE would not be set. DPKG_MAINTSCRIPT_PACKAGE provides a fallback value for PACKAGE and not the other way around. It might be possible that one would use rm_conffile to remove a file owned by another binary package of the same source (although I don't see the use case for this, maybe cleaning up for a removed but not purged binary package that got dropped) in which case the debug message would become misleading. > I am therefore wondering whether the debug output shouldn't be > referring to PACKAGE instead of DPKG_MAINTSCRIPT_PACKAGE. I don't think so. Furthermore the value of PACKAGE is output on the line afterwards anyway. If you agree with my answer, please close the bug. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670805: dpkg: patch apply problem: line after --- isn't as expected in diff
reassign 670805 dpkg-dev forcemerge 485330 670805 thanks On Sun, 29 Apr 2012, Jari Aalto wrote: > These patches work fine with quilt(1) and patch(1). Any patch that "patch" can apply will be automatically supported by quilt. But "3.0 (quilt)" requires "unified patch" and what you attached is a "context patch" (generated with "diff -c") There's already a bug about this, merging them. But it's unlikely to be supported any time soon. Refresh your patch with quilt to transform it into a unified diff. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670081: dpkg: dpkg-source: expected [ +-] at start of line
On Mon, 23 Apr 2012, jaalto wrote: > | Hmm, well quilt just makes use of patch. And yes, patch seems to > | assume that when there's a '\t' or '\n' on the first line character > | the space got eaten, in pch.c (another_hunk():1646), so given this I > | guess I'll be adding support for these kinds of patches, Up to now, we closed those reports because the patch files are bogus and we want to ensure that what is shipped in a Debian source package is clean. > | but it seems > | to me those are just somewhat bogus anyway, did you manually create > | that patch or maybe it was extracted from a mail client that mangles > | the body (evolution for example)? > > It was straight diff from git 1.7.10: > >git COMMIT COMMIT -- FILE > output.patch I doubt it. I bet that you have some editor hook that cleans up mixes of spaces and tabs at the start of a line... or something similar. But I have never seen git generate this kind of patch. On the contrary, I often see some red highlight in my git log/show commands when I stumble upon such patches. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#578864: dpkg-source -b in 3.0 (quilt) package modifies timestamp of, manually changed files
Hi, On Wed, 18 Apr 2012, Guo Yixuan wrote: > This bug seems to be fixed, as I tried what Timo has done: > > $ dget http://people.debian.org/~hertzog/packages/debsrc3.0/sample7_1.0-1.dsc > $ dpkg-source -x sample*.dsc > $ cd sample7-1.0 Here you need to modify upstream/README to actually match the case described in this bug report: $ echo "foo" >>upstream/README > $ touch -d 1970-01-01 upstream/README > $ dpkg-buildpackage -rfakeroot -us -uc And here, nowadays, you have to allow the change to be automatically recorded: $ dpkg-buildpackage -us -uc --source-option=--auto-commit > $ ls -l upstream/ > total 4 > -rw-r--r-- 1 gyx gyx 437 Jan 1 1970 README And then you can see that it's not fixed: $ ls -l upstream/ total 4 -rw-r--r-- 1 rhertzog rhertzog 441 avril 19 00:07 README Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#667438: Support file triggers on /usr/local, manually triggered by administrator after "make install"
On Wed, 04 Apr 2012, Josh Triplett wrote:
> > In some way we already do:
> > $ sudo dpkg-trigger --no-await /usr/local/man
> > $ sudo dpkg --configure -a
> > Processing triggers for man-db ...
> >
> > But there's easy way to find out all the file triggers that match
> > /usr/local/something.
I meant "there's no easy way".
> running spuriously, triggering *everything* seems acceptable for a first
> pass. A quick (untested) prototype version:
>
> find /usr/local -exec dpkg-trigger --no-await '{}' \;
dpkg-trigger will only accept names of existing triggers. That's why I was
telling that you would need a way to extract a list of file triggers.
Then you can easily match file triggers with files installed in
/usr/local/.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#667438: Support file triggers on /usr/local, manually triggered by administrator after "make install"
On Tue, 03 Apr 2012, Josh Triplett wrote: > As a more optimal solution, packages could register file triggers on > appropriate paths in /usr/local Some packages already do (man-db for example). > and dpkg could provide a means for an > administrator to manually trigger those triggers after running "make > install" or similar. In some way we already do: $ sudo dpkg-trigger --no-await /usr/local/man $ sudo dpkg --configure -a Processing triggers for man-db ... But there's easy way to find out all the file triggers that match /usr/local/something. > This way, rather than the administrator needing to manually run mandb, > ldconfig, fc-cache, and various other things, they could run a single > command to update all interested packages. I'm not sure that this command should be part of dpkg. But it seems reasonable to improve dpkg so that such a tool can be written on top of dpkg. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#667008: dpkg-dev: dpkg-gencontrol does use the control file specified with optin -c for the lock-file
retitle 667008 dpkg-dev: dpkg-gencontrol does not use the control file specified with option -c for the lock-file thanks Hi, On Tue, 03 Apr 2012, Mats Danielsson wrote: > Dear Maintainer, > > The solution to Bug #642608 introduced another problem. The lock on the > control > file always uses the file "debian/control". Why is this a problem? It's actually a feature because we want to protect the access to debian/files. And we don't want two concurrents dpkg-gencontrol using different -c options to stomp on each other. It might be a problem if debian/control does not exist at all, is that the problem in your case? Maybe in that case we should fallback to the file indicated by -c. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666987: dpkg-buildflags: DEB_*_MAINT_* overrides user options.
On Tue, 03 Apr 2012, Miguel Colon wrote: > Well any flag not only optimization levels are affected but -OX is > probably the most common case. Any flag that allow overriding a previous value of the same flag and that maintainers are likely to change... wich doesn't make many. > Also some packages do > export DEB_CFLAGS_MAINT_SET=$(dpkg-buildflags --get CFLAGS) > which makes the -02 and the other flags permanent. This is a pretty stupid thing to do. What package is doing this? Is there a reason given? In any case, feel free to open a bug against the affected packages. > Anyway I just wanted to be able to be sure that the flags I wanted to > use for testing or building a local package for my system where > actually used without having to manually check each source to see if > there is a DEB_*_MAINT_* now or in the future that disables those > flags. I think the user should have the last say when building locally > since the user is willingly trying to use a flag locally but the > current method just adds the annoyance of either having to modify the > rules file, modify the BuildFlags.pm file or creating a gcc/g++ > wrapper. Well, I took the conservative approach in letting maintainers have the possibility to override/strip flags that are known to break the package. That way even if the user puts some dangerous flags in his default configuration, we maximize the set of packages that will continue to build. But obviously if you put yourself not as a user who needs the resulting package, but as a developer who is doing tests to see how many packages break with a given flag, then this decision might annoy you. We can invert the order between the maintainer environment variable and the user environment variable but I'd like the input of others because I can't really make up my mind on whether it's right and a realy useful thing to do. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666987: dpkg-buildflags: DEB_*_MAINT_* overrides user options.
Hello, On Tue, 03 Apr 2012, Miguel Colon wrote: > I would guess the DEB_BUILD_OPTIONS="noopt" problem should be reported > against the package that suffer from this case Yes, definitely. > but should not the user options in DEB_flag_* (or > $XDG_CONFIG_HOME/dpkg/buildflags.conf) override the > DEB_flag_MAINT_* equivalent? No. DEB_*_MAINT_* were designed to have precedence over the other variables. I agree it's unfortunate when they are used to change default values... I did not think of this when I replied to the bug report that you quoted. Package can use the STRIP + PREPEND commands to set defaults but it's not a really nice interface either. I'm not sure what the proper approach would be. On the other hand, I'm not entirely convinced that it's important to let the user have the last word in cases where maintainers have opted for a specific optimization level: - building with -Os is typically made for udeb and I don't see a compelling reason to have the possibility to change the maintainer choice via the environment variable - building with -O3 is often picked as a work-around when -O2 doesn't give the expected result, why would you want to pick another optimization level? if you want -O0, then it's the noopt option that you should be using Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666147: set UCF_FORCE_CONFFMISS when force-confmiss option is set
On Thu, 29 Mar 2012, Matus UHLAR - fantomas wrote: > >What could be done is for dpkg to export its command line options > >in a new environment variable DPKG_CMDLINE_OPTS, and then ucf could > >inspect that new variable and verify if --force-confmiss is there. > > what if someone puts the option to dpkg config file? Those should also be exported. They are command line options from dpkg's point of view. > >In the end, as long as ucf is external to dpkg, you can't really expect > >to have UCF-generated config files handled like dpkg conffiles. So I'm not > >convinced that finding a solution to this specific problem is important > >given the other differences that will continue to remain. > > what I want it to have single way to reenable package's config > file... not something (force-confmiss) that everyone describes and > documents, but someone other (ucf) simply ignores. This may be a UCF > problem, but in this case also dpkg should announce what user > requires. Solving this problem properly (most certainly) requires changes to ucf and to dpkg. So please file a bug against ucf and mark it blocked by this dpkg bug. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666147: set UCF_FORCE_CONFFMISS when force-confmiss option is set
Hi, On Thu, 29 Mar 2012, Matus UHLAR - fantomas wrote: > the dpkg's force-confmiss option, given as commandline parameter, or > as an config option, has no effect when configuration file is > maintained by ucf. that requires users to dig about the reason their > config file is missing. > > The ucf supports UCF_FORCE_CONFFMISS environment variable that > instruct it to recreate config file. > > Please, when user sets this opsion, set the UCF_FORCE_CONFFMISS > variable prior to running external programs/scripts, so dpkg will > pass the option to ucf. This would a layer violation. dpkg should not have to care about UCF. What could be done is for dpkg to export its command line options in a new environment variable DPKG_CMDLINE_OPTS, and then ucf could inspect that new variable and verify if --force-confmiss is there. In the end, as long as ucf is external to dpkg, you can't really expect to have UCF-generated config files handled like dpkg conffiles. So I'm not convinced that finding a solution to this specific problem is important given the other differences that will continue to remain. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664058: dpkg-dev: please add action to dpkg-buildflags to get an overview of the settings
On Mon, 19 Mar 2012, Bernhard R. Link wrote: > I undestand that since 1.16.2 was released in between, I need > to change the version? Attached are new versions of this patches > with the version changed. Yes, thank you. Guillem, what's your opinion on the output of the --status command? Bernhard and I seem to have different preference for it (start/end marker vs fixed prefix on all lines). Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664058: dpkg-dev: please add action to dpkg-buildflags to get an overview of the settings
On Fri, 16 Mar 2012, Bernhard R. Link wrote:
> > IMO this is not the proper way to extract it automatically. If you want
> > this feature, you should add a unique (and fixed) start/end marker.
> >
> > Maybe something like this ?
> >
> > --- BEGIN DPKG-BUILDFLAGS STATUS ---
> > […]
> > --- END DPKG-BUILDFLAGS STATUS ---
>
> Things requiring context like that are no fun to parse at all. You
> cannot grep them, a line parser needs additional context.
┏rivendell:~/x/c-a
┗(582)$ cat ~/tmp/test.txt
before
START
1
2
3
END
after
┏rivendell:~/x/c-a
┗(583)$ sed -ne '/^START/,/^END/ p' ~/tmp/test.txt
START
1
2
3
END
Really it's not difficult.
> > If you really want to keep the "dpkg-builflags: " prefix, then you should
> > use one of the functions exported by Dpkg::ErrorHandling. But I don't
> > think it's required.
>
> That seems to always want to output some extra (at least a colon) and
> most even seem to have localized messages, so do not look very
> suiteable.
Well, dpkg-buildflags can output additional errors/warnings during the
build so your grep would catch those too. You're thus not able to extract
only the output of the status command.
So if you don't want to go for the above, you should at least use
“print report("status", …)” so that the output ends up always starting
with "dpkg-buildflags: status: " and this can be reasonably extracted
too.
> I've split the first one into preparations to the infrastructure and
> the --status introduction. If you prefer them merged let me know...
It's ok.
> +=item $bf->environment_used($envvar)
> +
> +Records that the given environment variable had influenced
> +or could have influenced (if it had existed or had a different
> +value) the calculated flags.
> +
> +=cut
Please pick a name that start with an action. "mark_used_environment"
or "mark_used_envvar" maybe.
> +sub environment_used {
> +my ($self, $envvar) = @_;
> +$self->{'used_envs'}->{$envvar} = 1;
The second "->" is not needed. Drop it.
> +=item my @list = $bf->get_used_environment()
Be consistent with the former method, don't use once "environment_used" and
once "use_environment". Thus I suggest "get_used_environment" or
"get_used_envvar".
Also please return a sorted list to make the order non-random.
> +my @envvars = $build_flags->get_used_environment();
> +for my $envvar (@envvars) {
> + if (exists $ENV{$envvar}) {
> + printf "dpkg-buildflags: environment variable %s=%s\n",
> + $envvar, $ENV{$envvar};
> + }
> +}
BTW, I don't really like the usage of plain english in the output.
Plain english ought to be translated... maybe we can use somewhat
meaningful prefixes ?
E: for environment (or ENV:?)
V: for vendor (or VENDOR: ?)
F: for feature (or FEATURE:?)
R: for result or (or RES:? or FLAG:?)
It also makes it easier to reliably extract a sub-part of the output...
> From 6a600d3f9d2b438ca59d0e81f69b91249bd197b1 Mon Sep 17 00:00:00 2001
> From: "Bernhard R. Link"
> Date: Fri, 16 Mar 2012 11:05:17 +0100
> Subject: [PATCH 4/4] dpkg-buildflags: make --status output which flags are
> modified by maintainer
>
> As flags modified by DEB_*_MAINT_* are not reflected by its origin, add
> a new flag to describe flags modified that way.
Do you really see some value to this? You already have the *_MAINT_* variables
in the output.
I don't believe that this is required.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
