Bug#467470: setting package to dselect dpkg-dev dpkg, tagging 467470
# Automatically generated email from bts, devscripts version 2.10.17 # # dpkg (1.14.17) UNRELEASED; urgency=low # # * Forward port a patch from the old changelog parser to the new #one that got lost during the transition. '+' and '.' can now #be used in distribution names yet again. Reported by dann frazier. #Closes: #467470 # package dselect dpkg-dev dpkg tags 467470 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#452806: [debchange] dch -a shouldn't modify existing entries
On Thu, Feb 21, 2008 at 09:47:21PM +, Adam D. Barratt wrote: > debchange simply parses the output of dpkg-parsechangelog(1) in order to > derive the changes. dpkg-pc is stripping the whitespace before debchange > begins processing it; I'm therefore reassigning the bug. I really fail to see a good reason why it shouldn't. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466321: output of dselect broken with german UTF-8
On Mon, Feb 18, 2008 at 08:33:06PM -0500, Thomas Dickey wrote: > On Mon, Feb 18, 2008 at 03:30:31PM +0100, Frank Lichtenheld wrote: > > reassign 466321 libncurses5 5.6+20080203-1 > > severity 466321 important > > thanks > > > > Downgrading to libncurses5 5.6+20080119-1 fixes the problem. > > Assign it back to dselect. As noted in the dependencies, it's linked > with libncurses rather than libncursesw. > > > On Sun, Feb 17, 2008 at 11:53:19PM +0100, Berthold Cogel wrote: > > > Output of dselect is broken with german UTF-8: > > ...it's behaving as expected. Any idea why it works with the older libncurses? Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466321: output of dselect broken with german UTF-8
reassign 466321 libncurses5 5.6+20080203-1 severity 466321 important thanks Downgrading to libncurses5 5.6+20080119-1 fixes the problem. On Sun, Feb 17, 2008 at 11:53:19PM +0100, Berthold Cogel wrote: > Output of dselect is broken with german UTF-8: > > Debian M-BM-;dselectM-BM-+ Paketverwaltungs-Frontend Version 1.14.16.6 > (i386). [...] > Versions of packages dselect depends on: > ii dpkg1.14.16.6package maintenance system > for Deb > ii libc6 2.7-8GNU C Library: Shared libraries > ii libgcc1 1:4.3-20080202-1 GCC support library > ii libncurses5 5.6+20080203-1 Shared libraries for > terminal hand > ii libstdc++6 4.3-20080202-1 The GNU Standard C++ Library v3 Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466321: output of dselect broken with german UTF-8
On Sun, Feb 17, 2008 at 11:53:19PM +0100, Berthold Cogel wrote: > Output of dselect is broken with german UTF-8: > > Debian M-BM-;dselectM-BM-+ Paketverwaltungs-Frontend Version 1.14.16.6 > (i386). Sid dselect doesn't work etch dselect on etch works etch dselect on sid doesn't work I would suspect that the ncurses library is a more likely suspect than dselect itself. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#466135: dpkg-dev: improvements to deb-shlibs(5)
On Sat, Feb 16, 2008 at 02:41:07PM -0500, Zack Weinberg wrote: > The deb-shlibs(5) manpage is brief and not very helpful. I had to read > through the source to dpkg-shlibdeps to figure out that yes, there was a > comment syntax for these files. > > I attach a suggested revision. It still defers to the Policy Manual for > most of the details, but it clarifies the basic syntax and provides an > example. Thanks. I've applied your patch (with some formatting changes). Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465282: dpkg-dev: Set a set of compiler flags for a build
On Wed, Feb 13, 2008 at 09:52:37PM +0100, Moritz Muehlenhoff wrote: > On Tue, Feb 12, 2008 at 04:45:01PM +0100, Matthias Klose wrote: > > Frank Lichtenheld writes: > > > On Mon, Feb 11, 2008 at 05:39:10PM +0100, Matthias Klose wrote: > > > > Please find attached a patch which implements setting a set of > > > > compiler flags for a build; this was first announced in > > > > http://lists.debian.org/debian-devel/2007/12/msg00090.html > > > > Now simpliefied to just use the CFLAGS/CFLAGS_APPEND naming by Colin > > > > Watson. > > > > > > Maybe more like this (still missing l10n, but a lot less code > > > duplication): > > > > thanks for the cleanup! > > dpkg developers, can you already estimate, if/when this will be > available in unstable? It's currently in my "procrastinate a bit about it before committing" queue ;) But I see no real problem with having it in .17 Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465282: Proposalto introduce compiler options passed from dpkg-buildpackage
On Wed, Feb 13, 2008 at 10:01:00PM +0100, Moritz Muehlenhoff wrote: > On Mon, Feb 11, 2008 at 05:44:33PM +0100, Matthias Klose wrote: > > Moritz Muehlenhoff writes: > > > [This message has also been posted to gmane.linux.debian.devel.general.] > > > On 2007-12-25, Moritz Muehlenhoff <[EMAIL PROTECTED]> wrote: > > > > Matthias Klose wrote: > > > >> This is a proposal to introduce a common set of compiler options which > > > >> can be set independently from the package, and passed/injected to the > > > >> package build process. It was first discussed at the last UDS; a > > > >> corresponding wiki page can be found at [1]. > > > > > > > > A change like that is more or less required for the planned introduction > > > > of security hardening features. Since noone really objected to the > > > > change > > > > outlined, I'd be interested in the way forward from here and what > > > > timeline > > > > is planned to set the changes into effect. > > > > > > Matthias, what's the status? > > > > thanks for the reminder; I did update the proposal and renamed the > > environment variables to what Colin Watson did suggest. Bug #465282 > > now has a patch for dpkg-architecture attached. > > That looks good to me. Maybe we should have individual default flags > per architecture, so that features, which are buggy or not fully > implemented on a given arch can be disabled so that the workarounds > don't need to be done by the maintainers across several rules files? Hmm, I doubt that dpkg-dev should be the place to keep track of that. I mean, that probably depends on the version of gcc/g++/whatever used, so it's quite meaningless to make it dependent on the version of dpkg-dev you use. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465340: dpkg: Broken call to open in Dpkg/Control.pm
On Tue, Feb 12, 2008 at 05:44:31PM +0100, Raphael Hertzog wrote: > On Tue, 12 Feb 2008, Frank Lichtenheld wrote: > > On Tue, Feb 12, 2008 at 12:39:21AM +0100, Soren Hansen wrote: > > > On Tue, Feb 12, 2008 at 12:25:13AM +0100, Frank Lichtenheld wrote: > > > Granted my perl-fu is not that strong, and looking at the documentation, > > > I might have exaggerated the extent of this bug somewhat. > > > > > > > Could you please go into more detail what you tried to fix? > > > > > > The particular bug I was fixing was when called with "-c-", i.e. read > > > the control file from stdin. From perldoc: > > > > > > In the 2-arguments (and 1-argument) form opening '-' opens STDIN > > > and opening '>-' opens STDOUT. > > > > > > Without my patch, it's the 3-argument version of open, so opening "-" > > > fails (as there is no such file). > > > > Ok, thanks. Now I understand :) > > Even if we understand it, I don't think it's a change that we really want. > > The documentation doesn't mention the possibility of using "-" as filename > for standard input and I'd rather that you fix the Ubuntu package that is > doing that instead of changing dpkg. > > The precise point the 3 arg syntax is to be able to use weird filenames > without encountering problems due to the various syntax of the open call. Fully agreed. This doesn't mean we couldn't support using STDIN there, I just wouldn't do it implictly. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465340: dpkg: Broken call to open in Dpkg/Control.pm
On Tue, Feb 12, 2008 at 12:39:21AM +0100, Soren Hansen wrote: > On Tue, Feb 12, 2008 at 12:25:13AM +0100, Frank Lichtenheld wrote: > Granted my perl-fu is not that strong, and looking at the documentation, > I might have exaggerated the extent of this bug somewhat. > > > Could you please go into more detail what you tried to fix? > > The particular bug I was fixing was when called with "-c-", i.e. read > the control file from stdin. From perldoc: > > In the 2-arguments (and 1-argument) form opening '-' opens STDIN > and opening '>-' opens STDOUT. > > Without my patch, it's the 3-argument version of open, so opening "-" > fails (as there is no such file). Ok, thanks. Now I understand :) Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465340: dpkg: Broken call to open in Dpkg/Control.pm
On Mon, Feb 11, 2008 at 11:47:13PM +0100, Soren Hansen wrote:
> diff -Nru /tmp/63ah7FRjAl/dpkg-1.14.16.6ubuntu1/scripts/Dpkg/Control.pm
> /tmp/fQCCS9NM6H/dpkg-1.14.16.6ubuntu2/scripts/Dpkg/Control.pm
> --- dpkg-1.14.16.6ubuntu1/scripts/Dpkg/Control.pm 2008-01-18
> 11:12:53.0 +0100
> +++ dpkg-1.14.16.6ubuntu2/scripts/Dpkg/Control.pm 2008-02-11
> 23:20:11.0 +0100
> @@ -78,7 +78,7 @@
> my ($self, $file) = @_;
> $self->reset();
> # Parse
> -open(CDATA, "<", $file) || syserr(_g("cannot read %s"), $file);
> +open(CDATA, "< $file") || syserr(_g("cannot read %s"), $file);
Hmm, whatever problem you saw, this most certainly is not the right fix!
Both lines are semantically identical... (barring any serious Perl
bugs).
Could you please go into more detail what you tried to fix?
Error messages? Launchpad bug number?
Gruesse,
--
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465282: dpkg-dev: Set a set of compiler flags for a build
On Mon, Feb 11, 2008 at 05:39:10PM +0100, Matthias Klose wrote:
Content-Description: message body text
> Package: dpkg-dev
> Severity: wishlist
>
> Please find attached a patch which implements setting a set of
> compiler flags for a build; this was first announced in
> http://lists.debian.org/debian-devel/2007/12/msg00090.html
> Now simpliefied to just use the CFLAGS/CFLAGS_APPEND naming by Colin
> Watson.
Maybe more like this (still missing l10n, but a lot less code
duplication):
diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index 72854dd..a550f4c 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -242,9 +242,8 @@ if ($signcommand) {
}
}
+my $build_opts = Dpkg::BuildOptions::parse();
if ($parallel) {
-my $build_opts = Dpkg::BuildOptions::parse();
-
$parallel = $build_opts->{parallel} if (defined $build_opts->{parallel});
$ENV{MAKEFLAGS} ||= '';
if ($parallel eq '-1') {
@@ -256,6 +255,26 @@ if ($parallel) {
Dpkg::BuildOptions::set($build_opts);
}
+my $default_flags = defined $build_opts->{noopt} ? "-g -O0" : "-g -O2";
+my %flags = ( CPPFLAGS => '',
+ CFLAGS => $default_flags,
+ CXXFLAGS => $default_flags,
+ FFLAGS => $default_flags,
+ LDFLAGS => "-Wl,-Bsymbolic-functions",
+);
+
+foreach my $flag (keys %flags) {
+if ($ENV{${flag}}) {
+ print "$progname: use ${flag} from environment: $ENV{${flag}}\n";
+} else {
+ $ENV{${flag}} = $flags{$flag};
+ print "$progname: set ${flag} to default value: $ENV{${flag}}\n";
+}
+if ($ENV{"${flag}_APPEND"}) {
+ $ENV{${flag}} .= " ".$ENV{"${flag}_APPEND"};
+}
+}
+
my $cwd = cwd();
my $dir = basename($cwd);
Gruesse,
--
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355654: dpkg-buildpackage to be able to override /usr/bin/make -f in debian/rules
On Tue, Jan 29, 2008 at 08:58:25AM +0100, Raphael Hertzog wrote: > On Sun, 20 Jan 2008, Frank Lichtenheld wrote: > > Hrm, the whole split(/\s+/) is somewhat ugly (and BTW not documented for the > > -R option). Please do not commit before the upcoming upload, to give > > us a chance to think that over. > > I updated my patch to document better the option parsing (patch attached). > I'll push the change if nobody has any better idea. Fine by me. Haven't had any better ideas during the last week. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462677: dpkg fails to install on arm
On Sun, Jan 27, 2008 at 06:29:27AM +0200, Guillem Jover wrote: > It could be related to the OABI compat layer. Which kernel version are > you guys using? I have a Debian etch arm system here (2.6.18-5-ixp4xx) with a sid chroot. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445552: dpkg-buildpackage should systematically check build-deps before calling clean
On Fri, Jan 18, 2008 at 04:02:56PM +0100, Raphael Hertzog wrote:
> Alternatively, we could make it display a warning and not actually exit.
> And this warning can itself warn that in the future it might fail at that
> point if -d is not passed.
At some point I would like to introduce a configuration file for
dpkg-buildpackage so that one can define his own preferred behaviour
(no more -uc -us, looking forward to that...)
For now how about this patch that implements that compromise solution
you described:
diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index 8865299..48db1c8 100755
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -177,7 +177,7 @@ while (@ARGV) {
}
} elsif (/^-S$/) {
$sourceonly = '-S';
- $checkbuilddep = 0;
+ @checkbuilddep_args = ('-B');
if ($binaryonly) {
usageerr(_g("cannot combine %s and %s"), $binaryonly, '-S');
}
@@ -297,7 +297,13 @@ if ($checkbuilddep) {
if (system('dpkg-checkbuilddeps', @checkbuilddep_args)) {
warning(_g("Build dependencies/conflicts unsatisfied; aborting."));
warning(_g("(Use -d flag to override.)"));
- exit 3;
+
+ if ($sourceonly) {
+ warning(_g("This is currently a non-fatal warning with -S, but"));
+ warning(_g("will probably become fatal in the future."));
+ } else {
+ exit 3;
+ }
}
}
Gruesse,
--
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462677: dpkg fails to install on arm
On Sat, Jan 26, 2008 at 10:03:18PM +0100, Matthias Klose wrote: > > On Sat, 2008-01-26 at 20:59:15 +0100, Matthias Klose wrote: > > > $ sudo dpkg -i /var/cache/apt/archives/dpkg_1.14.16.5_arm.deb > > > (Reading database ... 31489 files and directories currently installed.) > > > Preparing to replace dpkg 1.14.16.5 (using .../dpkg_1.14.16.5_arm.deb) ... > > > Unpacking replacement dpkg ... > > > rm: rm.c:371: main: Assertion `((status) == RM_OK || (status) == > > > RM_USER_DECLINED || (status) == RM_ERROR)' failed. > > > dpkg: error while cleaning up: > > > subprocess rm cleanup killed by signal (Aborted) > > > > This assert is comin from the rm binary, and seems quite fishy. Is that > > system ok otherwise, fs, kernel, memory etc? > > yes, a thecus running armel, with an arm chroot. Can't reproduce this on my slug. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462677: dpkg fails to install on arm
On Sat, Jan 26, 2008 at 08:59:15PM +0100, Matthias Klose wrote: > $ sudo dpkg -i /var/cache/apt/archives/dpkg_1.14.16.5_arm.deb > (Reading database ... 31489 files and directories currently installed.) > Preparing to replace dpkg 1.14.16.5 (using .../dpkg_1.14.16.5_arm.deb) ... > Unpacking replacement dpkg ... > rm: rm.c:371: main: Assertion `((status) == RM_OK || (status) == > RM_USER_DECLINED || (status) == RM_ERROR)' failed. > dpkg: error while cleaning up: > subprocess rm cleanup killed by signal (Aborted) > Setting up dpkg (1.14.16.5) ... > chown: changing ownership of `0\323\022': No such file or directory > dpkg: error processing dpkg (--install): > subprocess post-installation script returned error exit status 1 > Errors were encountered while processing: > dpkg Hmm, the first problem looks more like a coreutils problem, doesn't it? Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#4655: dpkg-buildpackage should do sanity checks on version number
On Tue, Jan 22, 2008 at 12:12:03PM +0100, Raphael Hertzog wrote: > On Thu, 11 May 2006, Frank Lichtenheld wrote: > > I would leave the bug open. While I have no intentions to hack something > > like this into the current version of dpkg-parsechangelog, I would not > > say that it is a thing not ever worth thinking about. > > We could add this warning to dpkg-genchanges. We already have the code > that extracts the two last version numbers... it's a trivial 2 line > patch. Fine with me. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284664: tagging 284664
# Automatically generated email from bts, devscripts version 2.10.13 # note my intend to close this tags 284664 wontfix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284664: Workarounds
On Tue, Oct 04, 2005 at 07:05:29PM +0200, Frank Lichtenheld wrote: > I'm not sure yet if I will make a patch for this bug but one can work > around the limitations of dpkg-parsechangelog by using grep-dctrl: > > dpkg-parsechangelog | grep-dctrl -ensVersion -FSource . > > With the --format rfc822 option of parsechangelog from > libparse-debianchangelog-perl and the other tools from > dctrl-tools (only in experimental) you can do even more > fancy things. Little example: > > parsechangelog --all --format rfc822 | grep-dctrl -esVersion,Maintainer > -FSource . | tbl-dctrl -cVersion -cMaintainer With the upcoming upload the latter command will be possible with dpkg-parsechangelog, too. I don't actually plan to do more to fix this bug but to close it then as wontfix. Objections? Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#114774: dpkg-checkbuilddeps: patch for new features
On Sat, Jan 19, 2008 at 11:07:20PM +0100, Raphael Hertzog wrote: > Though I think that -d and -c can be interesting, so I wrote a new patch > to support them (it's attached). I'll apply it for dpkg 1.14.17. You really should add a option to set Build-Depends-Indep then, too. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#355654: dpkg-buildpackage to be able to override /usr/bin/make -f in debian/rules
On Sat, Jan 19, 2008 at 10:00:37PM +0100, Raphael Hertzog wrote: > On Tue, 07 Mar 2006, Davor Ocelic wrote: > > A simple patch to allow this behavior is attached. It adds the -M > > option which should be used like say: > > > > dpkg-buildpackage -M'/usr/local/bin/make -f' > > I didn't like this intermediary command. What you really wanted to do is > not use "debian/rules" as build command but a custom command that is > "/usr/local/bin/make -f debian/rules". That is indeed better than the original proposal, IMHO. > On Sun, 26 Aug 2007, Robert Millan wrote: > > I'm attaching an updated version of Davor's patch (against 1.14.5). > > Note that this allows to do very useful things such as: > > dpkg-buildpackage -B -rfakeroot -M"make -j `getconf _NPROCESSORS_ONLN` -f" > > We have the -j command now, so it's much less useful. Still I have created > another patch that implements what I explained above: it offers a -R > option to replace "debian/rules" by whatever you want. > > (the other patches were meant for the old shell version of > dpkg-buildpackage anyway) > > Frank, any comments or is it safe to commit? Hrm, the whole split(/\s+/) is somewhat ugly (and BTW not documented for the -R option). Please do not commit before the upcoming upload, to give us a chance to think that over. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445552: dpkg-buildpackage should systematically check build-deps before calling clean
On Fri, Jan 18, 2008 at 04:02:56PM +0100, Raphael Hertzog wrote: > Do we have any idea of how many packages/services actually use > dpkg-buildpackage -S ? pbuilder is probably one of the most prominent. As a matter of fact it checks the build-deps before that though and warns if they aren't satisfied. > I'm leaning towards correctness if it doesn't break too many stuff. > > Alternatively, we could make it display a warning and not actually exit. > And this warning can itself warn that in the future it might fail at that > point if -d is not passed. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455841: dpkg: [INTL:ja] updated Japanese program translation
On Wed, Dec 12, 2007 at 12:02:56PM +0900, Kenshi Muto wrote: > I think I can do it by myself if you add my account (kmuto) to the Alioth > dpkg project. I've added you. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454666: MD5 signatures provide no security
reassign 454666 apt thanks On Thu, Dec 06, 2007 at 02:33:06PM -0800, [EMAIL PROTECTED] wrote: > Exploitation of this flaw would allow an attacker to > substitute arbitrary code for any legitimate Debian package > using a "man in the middle" attack undetected whenever a > user is installing new software, or to put up a debian > mirror site or repository containing arbitrary code > disguised as legitimate Debian software and having the same > checksums. dpkg does at no time verify anything about the origin of packages. Only apt does. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454379: Processed: Re: Bug#454379: libzvbi0 -- Doesn't purge all files after piuparts Install+Upgrade+Purge test
On Thu, Dec 06, 2007 at 07:28:03AM +0530, Kumar Appaiah wrote: > On Wed, Dec 05, 2007 at 08:47:51PM +0100, Raphael Hertzog wrote: > > As far as I understand, the file /etc/default/libzvbi0 was in the sarge > > package but it's no more in the sid version of the package but the conf > > files stays even after the purge because: > > - dpkg doesn't remove conffiles on upgrade, it just mark them as obsolete > > (can be seen on "dpkg -s package" in the Conffiles field) > > - apparently even during purge it doesn't remove conffiles which are > > obsolete > > > > Can you confirm ? > > From my observation, if the conffile is present in the Etch package[1], > but not in the Sid package[2], dpkg leaves the conffile during upgrade > and forgets about them on subsequent purge. I think Christian feels > that this is to be handled by dpkg. Yeah, that is a known limitation of dpkg. See also http://www.dpkg.org/dpkg/ConffileHandling Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453267: tested patch
On Tue, Dec 04, 2007 at 05:58:01PM +, Neil Williams wrote: > Do you want a new patch with that final line amended? Nah, just making sure whether this was a typo or not. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453267: tested patch
On Tue, Dec 04, 2007 at 10:27:35AM +, Neil Williams wrote:
> use constant DEFAULT_LIBRARY_PATH =>
> qw(/lib /usr/lib /lib32 /usr/lib32 /lib64 /usr/lib64
> /emul/ia32-linux/lib /emul/ia32-linux/usr/lib);
[...]
> +if ($crossprefix)
> +{
> +@shlibdeps = ( "${crossprefix}/lib", "/usr/${crossprefix}/lib",
> +"/${crossprefix}/lib32", "/usr/${crossprefix}/lib32",
> +"/${crossprefix}/lib64", "/usr/${crossprefix}/lib64",
> +"/emul/ia32-linux/lib", "/emul/ia32-linux/usr/lib" );
> +}
Why do you add "/emul/ia32-linux/lib", "/emul/ia32-linux/usr/lib" again?
Gruesse,
--
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#452730: found 452730 in 1.14.7
# Automatically generated email from bts, devscripts version 2.10.10 # note that this bug is also found in the version in testing found 452730 1.14.7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#229357: Can we require build-arch/indep targets for lenny?
On Fri, Oct 12, 2007 at 02:13:49PM -0700, Steve Langasek wrote: > On Fri, Oct 12, 2007 at 10:49:13PM +0200, Frank Lichtenheld wrote: > > No answer? I would like to work on this, but someone would need to > > answer my questions about it... > > > (explicetly sending to vorlon, too, ignoring the M-F-T) > > I have no answers for you about whether there are defined semantics for this > use of make. :) > > Anyway, I thought this patch was ruled out in later discussion in the > thread. Hmm, it was opposed by some but I don't see a consensus reached anywhere. Let's try to give a summary of the discussion. So far the proposed solutions for this problem are: 1) Build-Options field As pointed out this doesn't scale very well and there is no real way to make it default behaviour one day. This would be the way to go though if it only needs to be specified for few packages (either because we think that few packages actually need build-arch support or because of the solution I propose below, combining it with autodetection). I'm not particulary impressed with this. 2) Standards-Version, i.e. make it 'must' in policy This should work but it completly contradicts the past Debian standards process (according to Lucas' numbers, the new policy would currently only be satisfied by < 2000 packages, i.e. somewhere in the 20% region) and would make a solution dependant on the policy team, which is currently somewhat MIA... It would be really nice to have a policy someday that acutally matches reality, though. 3) Autodetection Would be clearly the easiest solution if it works reliably. There are some problems: - Works only with GNU make - depends on a _should_ in policy, not a _must_ (error code) On the other hand, according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229357#172 it mostly works, and most of the cases where it doesn't work seem to be the packages fault (i.e. the binary-arch target seems to depend on the build-indep target without actually declaring that dependency). BTW, the "correct" solution in any case would be to run checkbuilddeps again if we don't find build-arch support, since we need b-d-i, too. And *poof*, there go our buildds ;) which brings me to the last solution which I think wasn't actually proposed: 4) Adapt policy to sbuilds behaviour I.e. don't require b-d-i on build, but only on binary and binary-indep. Conclusion: I would be interested to gather some input from the interested persons regarding their exact position. I think the following questions should give us a good understanding or their position: (want == 'I want it and I also think it would be possible to do') 1) Do you want to change sbuild to actually respect policy? 1a) (SKIP if 'no' to 1) Before lenny's release? 2) (SKIP if 'yes' to 1) Do you want to change policy to declare sbuild's behaviour official? 3) Do you want for all packages to support build-arch in the nearer future (longest lenny+1) [== policy 'must']? 4) (SKIP if 'yes' to 3) In the farer future? 5) Do you think autodetection can work and should be used? 6) (SKIP if 'yes' to 5) Do you think that autodetection can work and should be used, if packages would have the ability to override it if they know they get detected wrong? My answers are: YN-NNNY After considering all the arguments I believe that the best solution would be to try to implement autodetection _and_ support Build-Options to give maintainers the ability to override it. Build-Options is simply the easiest and best-working possibility, but for good behaving packages it should not be neccessary. And I strongly believe that after lenny's release dpkg-buildpackage should start to check the 'correct' build-dependencies according to policy (i.e. requiring b-d-i if build-arch is not supported). I would volunteer to implement the solution I propose (in the near future) if there are enough supporters. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#229357: Can we require build-arch/indep targets for lenny?
On Sat, Sep 29, 2007 at 10:09:19PM +0200, Frank Lichtenheld wrote: > On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote: > > Attached is a patch to dpkg which implements a check for a 'build-arch' > > target using 'make -f debian/rules -qn build-arch'. > > Is there actually a defined semantic for make -qn ? The make info manual > states: > > "It is an error to use more than one of these three flags [-q, -t, -n] in the > same > invocation of `make'." No answer? I would like to work on this, but someone would need to answer my questions about it... (explicetly sending to vorlon, too, ignoring the M-F-T) Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445858: dpkg: Minor errors in man pages
On Mon, Oct 08, 2007 at 06:43:57PM +0200, Helge Kreutzmann wrote: > While updating the German man pages translation, I noticed the > following minor errors, given as patch respective to the pot files. The whitespace issues are po4a's fault, but the rest should be fixed now. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446119: dpkg-buildpackage: Not passing DEB_BUILD_OPTIONS from -j as claimed in man page
tag 446119 confirmed thanks On Wed, Oct 10, 2007 at 11:39:21AM -0400, Daniel Schepler wrote: > As the subject says: confirmed. Silly bug, really. Thanks for catching. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445852: dpkg-buildpackage: fails with perl errors
On Tue, Oct 09, 2007 at 07:14:52PM +0200, Raphael Hertzog wrote: > On Tue, 09 Oct 2007, Giovanni Mascellani wrote: > > All'incirca Mon, 8 Oct 2007 22:16:21 +0200, Frank Lichtenheld > > <[EMAIL PROTECTED]> sembrerebbe aver scritto: > > > > > These don't look like perl errors, but like shell errors. Somehow the > > > perl script gets executed as shell script. Do you have dpkg-cross > > > installed? > > > > Hmm, but why does it happens? I have dpkg-cross installed, but I can't > > see what does this mean. Sorry, I'm not very expert with Perl! > > It means that dpkg-cross diverted /usr/bin/dpkg-buildpackage and installed > its own copy of that file. That copy reuses the original dpkg-buildpackage > by sourcing it, and thus making the assumption that's it's written in shell. > That assumption has been broken by the latest upload. > > So this is really a dpkg-cross bug. dpkg-dev should probably declare a conflict (or a breaks) on the affected versions of dpkg-cross, though. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445858: dpkg: Minor errors in man pages
On Tue, Oct 09, 2007 at 06:24:48PM +0200, Helge Kreutzmann wrote: > On Mon, Oct 08, 2007 at 10:28:05PM +0200, Frank Lichtenheld wrote: > > On Mon, Oct 08, 2007 at 06:43:57PM +0200, Helge Kreutzmann wrote: > > > Here I am unsure, please verify: > > > -"shlibs.local>, B, the B control area > > > file " > > > +"shlibs.local>, B, the B area in the > > > controle file " > > > > "shlibs control file" is correct I think > > The word I had really problems with is "area". For me "area" implies > some space which is separated. "shlibs control file area" is still > unclear to me. Could "area" may be dropped? That was what I meant. Sorry if that was unclear. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445858: dpkg: Minor errors in man pages
On Mon, Oct 08, 2007 at 06:43:57PM +0200, Helge Kreutzmann wrote: > Here I am unsure, please verify: > -"shlibs.local>, B, the B control area > file " > +"shlibs.local>, B, the B area in the > controle file " "shlibs control file" is correct I think > > -"of the package containing the file which B reports as satisfying " > +"of the package containing the file which B(1) reports as > satisfying " looks sensible. objdump should probably added to SEE ALSO as well. > -"tarfile. If will use the directory to create the diff, but the tarfile to " > +"tarfile. It will use the directory to create the diff, but the tarfile to " "It" is more correct. Just writing "dpkg-source" is probably better. > -"should be the exact entry name to be removed (i.e. \"emacs-20/emacs\" or " > +"should be the exact entry name to be removed (e.g. \"emacs-20/emacs\" or " > > -"(1) option of the same name. Will add itself to the MAKEFLAGS environment " > +"(1) option of the same name. Will add itself to the MAKEFLAGS environment " Looks like a po4a bug. > -"can only be one active regexp, of multiple -i options only the last one > will " > +"can only be one active regexp, of multiple B<-i> options only the last one > will " Yeah, change looks good. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445852: dpkg-buildpackage: fails with perl errors
On Mon, Oct 08, 2007 at 05:47:39PM +0200, Giovanni Mascellani wrote: > --- Please enter the report below this line. --- > When compiling a package with dpkg-buildpackage I receive these Perl > errors: > > $ dpkg-buildpackage -rfakeroot > /usr/bin/dpkg-buildpackage.orig: line 3: use: command not found > /usr/bin/dpkg-buildpackage.orig: line 4: use: command not found > /usr/bin/dpkg-buildpackage.orig: line 6: use: command not found > /usr/bin/dpkg-buildpackage.orig: line 7: use: command not found > /usr/bin/dpkg-buildpackage.orig: line 9: use: command not found > /usr/bin/dpkg-buildpackage.orig: line 10: use: command not found > /usr/bin/dpkg-buildpackage.orig: line 11: use: command not found > /usr/bin/dpkg-buildpackage.orig: line 13: syntax error near unexpected > token [EMAIL PROTECTED],' /usr/bin/dpkg-buildpackage.orig: line 13: `push > (@INC, > $dpkglibdir);' > $ > > I tried to downgrade, and with version 1.14.6 it is all ok. I have the > latest version of Perl present in unstable. These don't look like perl errors, but like shell errors. Somehow the perl script gets executed as shell script. Do you have dpkg-cross installed? Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430367: found 41907 in 1.14.1.6, found 395942 in 1.13.24, found 109954 in 1.19.17, found 430367 in 1.14.4
# Automatically generated email from bts, devscripts version 2.10.9 # make the BTS display more sensible found 41907 1.14.1.6 found 395942 1.13.24 found 109954 1.19.17 found 430367 1.14.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445552: dpkg-buildpackage should systematically check build-deps before calling clean
On Sat, Oct 06, 2007 at 09:17:21PM +0200, Loïc Minier wrote: > Per policy 7.6, build-deps must be available for "clean"; pbuilder > calls dpkg-buildpackage -S to generate a source suitable to be copied > into the build environment; by default, this involves cleaning before > building the source, but dpkg-checkbuilddeps isn't run before cleaning. > > I think dpkg-builcpackage should run dpkg-checkbuilddeps and fail at > this point when called with -S. Currently, clean might fail if > build-deps are unavailable (such as missing patch system package), but > this should really be an error detected earlier on. This behaviour is as old as dpkg-checkbuilddeps itself (see cf5d2919f686a15e8e623130b74af3ba2428fbeb in git). Changing the behaviour would obviously be "correct", the question is whether it would actually be "better". Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/
Bug#382673: [PATCH/RFC] dpkg-source.pl: Support a subset of wig&pen on build
On Sat, Oct 06, 2007 at 11:09:21PM +0200, Frank Lichtenheld wrote: > Use .orig.tar.(bz2|lzma) if they are available > and no .gz can be found. Also let the user specify > via -C(gz|bz2|lzma) how files that need to be > generated should be compressed. Hmm, I just noticed that dpkg-genchanges already uses -C, so it would be difficult to pass this option down from dpkg-buildpackage. Anyway, the name of the option is not really important at this point, yet. (-z perhaps? Seems to be free) Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382673: [PATCH/RFC] dpkg-source.pl: Support a subset of wig&pen on build
Use .orig.tar.(bz2|lzma) if they are available
and no .gz can be found. Also let the user specify
via -C(gz|bz2|lzma) how files that need to be
generated should be compressed.
I think this is about the maximum support for wig&pen we can add in
dpkg-source -b without big code changes. But it might be a useful one,
especially for big packages. Such packages could maybe allowed for
lenny (buildds still running sarge might pose a problem, though).
Gruesse,
Frank
---
ChangeLog |9
debian/changelog |3 +
scripts/dpkg-source.pl | 121 ++-
3 files changed, 89 insertions(+), 44 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b1eafab..8ad0186 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2007-10-06 Frank Lichtenheld <[EMAIL PROTECTED]>
+
+ * scripts/dpkg-source.pl: Support a subset of
+ wig&pen (aka Format: 2.0) on build:
+ Use .orig.tar.(bz2|lzma) if they are available
+ and no .gz can be found. Also let the user specify
+ via -C(gz|bz2|lzma) how files that need to be
+ generated should be compressed.
+
2007-09-29 Frank Lichtenheld <[EMAIL PROTECTED]>
* scripts/dpkg-buildpackage.pl: Call checkversion()
diff --git a/debian/changelog b/debian/changelog
index 6c33f1c..3ea39e0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -35,6 +35,9 @@ dpkg (1.14.7) UNRELEASED; urgency=low
Closes: #379418
* Let dpkg-buildpackage error out early if the version number from
the changelog is not a valid Debian version. Closes: #216075
+ * Allow to use other compressions than gzip on dpkg-source -b
+(NOTE: this will result in a Format: 2.0 source package!).
+Closes: #382673
[ Updated dpkg translations ]
* Basque (Piarres Beobide). Closes: #440859
diff --git a/scripts/dpkg-source.pl b/scripts/dpkg-source.pl
index c036478..e45f560 100755
--- a/scripts/dpkg-source.pl
+++ b/scripts/dpkg-source.pl
@@ -75,6 +75,10 @@ my $max_dscformat = 2;
my $def_dscformat = "1.0"; # default format for -b
my $expectprefix;
+my $compression = 'gz';
+my @comp_supported = qw(gz bz2 lzma);
+my %comp_supported = map { $_ => 1 } @comp_supported;
+my $comp_regex = '(?:gz|bz2|lzma)';
# Packages
my %remove;
@@ -171,6 +175,8 @@ Build options:
-ss trust packed & unpacked orig src are same.
-sn there is no diff, do main tarfile only.
-sA,-sK,-sP,-sU,-sR like -sa,-sk,-sp,-su,-sr but may overwrite.
+ -C select compression to use (defaults to 'gz',
+ supported are: %s).
Extract options:
-sp (default)leave orig source packed in current dir.
@@ -182,7 +188,8 @@ General options:
--versionshow the version.
"), $progname,
$diff_ignore_default_regexp,
-join('', map { " -I$_" } @tar_ignore_default_pattern);
+join('', map { " -I$_" } @tar_ignore_default_pattern),
+"@comp_supported" ;
}
sub handleformat {
@@ -201,6 +208,10 @@ while (@ARGV && $ARGV[0] =~ m/^-/) {
&setopmode('build');
} elsif (m/^-x$/) {
&setopmode('extract');
+} elsif (m/^-C/) {
+ $compression = $POSTMATCH;
+ usageerr(sprintf(_g("%s is not a supported compression"), $compression))
+ unless $comp_supported{$compression};
} elsif (m/^-s([akpursnAKPUR])$/) {
warning(sprintf(_g("-s%s option overrides earlier -s%s option"), $1,
$sourcestyle))
if $sourcestyle ne 'X';
@@ -269,7 +280,7 @@ if ($opmode eq 'build') {
parsechangelog($changelogfile, $changelogformat);
parsecontrolfile($controlfile);
-$f{"Format"}=$def_dscformat;
+$f{"Format"}= $compression eq 'gz' ? $def_dscformat : '2.0';
&init_substvars;
my @sourcearch;
@@ -381,7 +392,7 @@ if ($opmode eq 'build') {
$basedirname =~ s/_/-/;
my $origdir = "$dir.orig";
-my $origtargz = "$basename.orig.tar.gz";
+my $origtargz;
if (@ARGV) {
my $origarg = shift(@ARGV);
if (length($origarg)) {
@@ -392,7 +403,7 @@ if ($opmode eq 'build') {
$sourcestyle =~ y/aA/rR/;
$sourcestyle =~ m/[ursURS]/ ||
&error(sprintf(_g("orig argument is unpacked but source
handling style".
- " -s%s calls for packed (.orig.tar.gz)"),
$sourcestyle));
+ " -s%s calls for packed (.orig.tar.)"),
$sourcestyle));
} elsif (-f _) {
$origtargz= $origarg;
$sourcestyle =~ y/aA/pP/;
@@ -408,22 +419,28 @@ if ($opmode eq 'build') {
Bug#373003: [PATCH/RFC] deb-version.5: Add an own manpage for Dpkg's version format
I was looking for a way to really close #373003 (dpkg-dev: deb-control.5
old rule for Version hyphenation). In the end it lead me to the
conclusion that Dpkg should contain a full description of its Version
format, which in turn lead to completly copying the section from Policy
since this is probably the best description available. This of course
again leads to a few followup questions:
1) If I would copy this text, who to credit for it? For now I just
copied the copyright notice from Policy but I suspect that might not be
the whole truth given how old it is.
2) Should we really try to include more documentation of dpkg's
behaviour in dpkg itself? (My answer is a clear "yes" to that)
If yes, how do we avoid duplication with policy? After all we probably
can't just delete such stuff from policy since there might be
differences what dpkg supports and what policy allows. But not
documenting dpkg features until they are allowed by Policy is not
a good way either.
3) What do people think of this specific case of copying?
Worth it? Should I try to condense the information more?
What should we do with the text is policy?
Comments welcome.
Gruesse,
Frank
---
debian/changelog |2 +
man/ChangeLog |9
man/deb-control.5 |7 ++-
man/deb-version.5 | 124 +
4 files changed, 139 insertions(+), 3 deletions(-)
create mode 100644 man/deb-version.5
diff --git a/debian/changelog b/debian/changelog
index 6c33f1c..9facda3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -35,6 +35,8 @@ dpkg (1.14.7) UNRELEASED; urgency=low
Closes: #379418
* Let dpkg-buildpackage error out early if the version number from
the changelog is not a valid Debian version. Closes: #216075
+ * Add an own manpage for Dpkg's version format. Mostly stolen
+from policy. Closes: #373003
[ Updated dpkg translations ]
* Basque (Piarres Beobide). Closes: #440859
diff --git a/man/ChangeLog b/man/ChangeLog
index fcc2e1a..42bdc37 100644
--- a/man/ChangeLog
+++ b/man/ChangeLog
@@ -1,3 +1,12 @@
+2007-10-06 Frank Lichtenheld <[EMAIL PROTECTED]>
+
+ * deb-control.5: Move description of
+ version format to...
+ * deb-version.5: Take the section from
+ policy describing version format and
+ sorting since this is probably as good
+ as it gets for describing these.
+
2007-09-30 Frank Lichtenheld <[EMAIL PROTECTED]>
* deb-control.5: Remove obsolete sentence regarding
diff --git a/man/deb-control.5 b/man/deb-control.5
index efc40c7..7043ef6 100644
--- a/man/deb-control.5
+++ b/man/deb-control.5
@@ -31,9 +31,9 @@ generate file names by most installation tools.
.BR Version: " "
Typically, this is the original package's version number in whatever form
the program's author uses. It may also include a Debian revision number
-(for non-native packages). If both version and revision are supplied,
-they are separated by a hyphen, `-'. For this reason, the original version
-may not have a hyphen in its version number.
+(for non-native packages). The exact format and sorting algorithm
+are described in
+.BR deb-version (5).
.TP
.BR Maintainer: " "
Should be in the format `Joe Bloggs <[EMAIL PROTECTED]>', and is typically
@@ -219,6 +219,7 @@ Description: GNU grep, egrep and fgrep.
.
.SH SEE ALSO
.BR deb (5),
+.BR deb-version (5),
.BR debtags (1),
.BR dpkg (1),
.BR dpkg-deb (1).
diff --git a/man/deb-version.5 b/man/deb-version.5
new file mode 100644
index 000..ea273ec
--- /dev/null
+++ b/man/deb-version.5
@@ -0,0 +1,124 @@
+.\" Author: ??
+.\" Includes text from the Debian Policy by ??
+.TH deb\-version 5 "2007-10-06" "Debian Project" "Debian"
+.SH NAME
+deb\-version \- Debian package version number format
+.
+.SH SYNOPSIS
+.RI "[ " epoch ":] " upstream_version " [\-" debian_revision " ]"
+.SH DESCRIPTION
+Version numbers as used for Debian binary and source packages
+consist of three components. These are:
+.TP
+.I epoch
+This is a single (generally small) unsigned integer. It
+may be omitted, in which case zero is assumed. If it is
+omitted then the \fIupstream_version\fP may not
+contain any colons.
+.IP
+It is provided to allow mistakes in the version numbers
+of older versions of a package, and also a package's
+previous version numbering schemes, to be left behind.
+.TP
+.I upstream_version
+This is the main part of the version number. It is
+usually the version number of the original ("upstream")
+package from which the \fI.deb\fP file has been made,
+if this is applicable. Usually this will be in the same
+format as that specified by the upstream author(s);
+however, it may need to be reformatted to fit into the
+package management system's format and comparison
+scheme.
+.IP
+The comparison behavi
Bug#445380: dpkg-dev: dpkg-source cannot handle diff with space in file name
tags 445380 confirmed thanks > Cause of the Problem > > To support file names with spaces, the 'diff' and 'patch' commands use a > trailing tab character (\t) > after the filenames. Dpkg-source uses a manual diff on all files, when > creating the diff.gz. In doing > doing this, it manually assigns labels to be used for the files inside the > diff (using the -L option), > this circumvents diff's own undocumented trailing tab-character behaviour, > causing the above described > problem. I haven't yet verified that the patch has no ill side-effects, but I have reproduced the problem and verified diff's behaviour. > Solution of the Problem > === > The attached patch solves the problem, by appending a tab character (\t) to > the labels that dpkg-source > assigns using the -L option. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445095: Processed: Re: [Pkg-openssl-devel] Bug#445095: openssl: Package upgrade removes /etc/ssl if it is a symbolic link
reassign 445095 openssl thanks On Wed, Oct 03, 2007 at 05:36:04PM +, Debian Bug Tracking System wrote: > > reassign 445095 dpkg > Bug#445095: openssl: Package upgrade removes /etc/ssl if it is a symbolic link > Bug reassigned from package `openssl' to `dpkg'. Just a wild guess, but the following code in openssl.preinst if [ -L /etc/ssl ] then echo Removing obsolete link /etc/ssl rm /etc/ssl fi _might_ have something to do with that behaviour... Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435126: dpkg-source please ignore vcs dirs for native packages too
On Wed, Sep 26, 2007 at 09:54:26AM +0200, Raphael Hertzog wrote: > On Tue, 25 Sep 2007, Brendan O'Dea wrote: > > So, while dpkg-source needs to be able to parse W&P format, the task > > of creating it should fall to tools better suited to the job: think > > git-buildpackage and other such tools which should have knowledge of a > > discrete set of patches/changesets. > > I'm not sure I like this idea... I'd rather have those tools generate the > debian/source file (or more generally interface with a dpkg API to define > how the package should be built). I would agree with this. This should avoid too much doubled code in all tools that might want to use the new format. Plus a working reference implementation (that doesn't need to be very user friendly, just as complete as possible) would probably do wonders for testing and advertising of the new format. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#229357: Can we require build-arch/indep targets for lenny?
On Mon, Jul 02, 2007 at 09:26:23PM -0700, Steve Langasek wrote: > Attached is a patch to dpkg which implements a check for a 'build-arch' > target using 'make -f debian/rules -qn build-arch'. Is there actually a defined semantic for make -qn ? The make info manual states: "It is an error to use more than one of these three flags [-q, -t, -n] in the same invocation of `make'." Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#229357: tagging 229357
# Automatically generated email from bts, devscripts version 2.10.8 # non-trivial patch against old shell version tags 229357 - patch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#229357: tagging 229357
# Automatically generated email from bts, devscripts version 2.10.8 # wrong bugnumber tags 229357 + patch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#247824: tagging 247824
# Automatically generated email from bts, devscripts version 2.10.8 # non-trivial patch against old shell version tags 247824 - patch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#109794: [PATCH] dpkg-genchanges: Add new -A option
Logical opposite of -B, will include only arch-indep
packages into the upload.
Signed-off-by: Frank Lichtenheld <[EMAIL PROTECTED]>
---
ChangeLog|8
scripts/dpkg-buildpackage.pl | 20 ++--
scripts/dpkg-genchanges.pl | 25 +
3 files changed, 39 insertions(+), 14 deletions(-)
I'm not entirely certain I see this as a must-have feature but I was
curious how much changes it would need to be implemented. So here is a
patch that does this.
diff --git a/ChangeLog b/ChangeLog
index b1eafab..b8e9bb7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
2007-09-29 Frank Lichtenheld <[EMAIL PROTECTED]>
+ * scripts/dpkg-buildpackage.pl: Add new
+ -A option (passed to dpkg-genchanges).
+ * scripts/dpkg-genchanges.pl: Add new -A
+ option that will include only arch-indep
+ packages into the upload.
+
+2007-09-29 Frank Lichtenheld <[EMAIL PROTECTED]>
+
* scripts/dpkg-buildpackage.pl: Call checkversion()
on version extracted from changelog. Since other
program we call later will do the same there is
diff --git a/scripts/dpkg-buildpackage.pl b/scripts/dpkg-buildpackage.pl
index f34a8c6..b036d19 100644
--- a/scripts/dpkg-buildpackage.pl
+++ b/scripts/dpkg-buildpackage.pl
@@ -49,8 +49,9 @@ Options:
-usunsigned source.
-ucunsigned changes.
-a Debian architecture we build for (implies -d).
- -b binary-only, do not build source. } also passed to
- -B binary-only, no arch-indep files. } dpkg-genchanges
+ -b binary-only, do not build source. } also passed to
+ -B binary-only, no arch-indep files. } dpkg-genchanges
+ -A binary-only, only arch-indep files. }
-S source only, no binary files. }
-t set GNU system type. } passed to dpkg-architecture
-vchanges since version . }
@@ -157,7 +158,7 @@ while (@ARGV) {
} elsif (/^-nc$/) {
$noclean = 1;
if ($sourceonly) {
- usageerr(sprintf(_g("cannot combine %s and %s"), '-nc', '-S'));
+ usageerr(sprintf(_g("cannot combine %s and -S"), '-nc'));
}
unless ($binaryonly) {
$binaryonly = '-b';
@@ -167,20 +168,27 @@ while (@ARGV) {
@checkbuilddep_args = ();
$binarytarget = 'binary';
if ($sourceonly) {
- usageerr(sprintf(_g("cannot combine %s and %s"), '-b', '-S'));
+ usageerr(sprintf(_g("cannot combine %s and -S"), '-b'));
}
} elsif (/^-B$/) {
$binaryonly = '-B';
@checkbuilddep_args = ('-B');
$binarytarget = 'binary-arch';
if ($sourceonly) {
- usageerr(sprintf(_g("cannot combine %s and %s"), '-B', '-S'));
+ usageerr(sprintf(_g("cannot combine %s and -S"), '-B'));
+ }
+} elsif (/^-A$/) {
+ $binaryonly = '-A';
+ @checkbuilddep_args = ();
+ $binarytarget = 'binary-indep';
+ if ($sourceonly) {
+ usageerr(sprintf(_g("cannot combine %s and -S"), '-A'));
}
} elsif (/^-S$/) {
$sourceonly = '-S';
$checkbuilddep = 0;
if ($binaryonly) {
- usageerr(sprintf(_g("cannot combine %s and %s"), $binaryonly,
'-S'));
+ usageerr(sprintf(_g("cannot combine %s and -S"), $binaryonly));
}
} elsif (/^-v(.*)$/) {
$since = $1;
diff --git a/scripts/dpkg-genchanges.pl b/scripts/dpkg-genchanges.pl
index d17700b..720266a 100755
--- a/scripts/dpkg-genchanges.pl
+++ b/scripts/dpkg-genchanges.pl
@@ -56,7 +56,7 @@ my $dsc;
my $changesdescription;
my $sourceonly;
my $binaryonly;
-my $archspecific;
+my $archspecific = 0;
my $forcemaint;
my $forcechangedby;
my $since;
@@ -82,6 +82,7 @@ sub usage {
Options:
-b binary-only build - no source files.
-B arch-specific - no source or arch-indep files.
+ -A only arch-indep - no source or arch-specific files.
-S source-only upload.
-c get control info from this file.
-lget per-version info from this file.
@@ -109,15 +110,20 @@ Options:
while (@ARGV) {
$_=shift(@ARGV);
if (m/^-b$/) {
- $sourceonly && &usageerr(_g("cannot combine -b or -B and -S"));
+ $sourceonly && &usageerr(sprintf(_g("cannot combine %s and -S"), $_));
$binaryonly= 1;
} elsif (m/^-B$/) {
- $sourceonly && &usageerr(_g("cannot combine -b or -B and -S"));
+ $sourceonly && &usageerr(sprintf(_
Bug#427210: dpkg-gencontrol: confusing error message when using inofficial architecture
On Fri, Sep 28, 2007 at 06:33:21AM +0300, Guillem Jover wrote: > At the time of writting those functions, I made them more strict, and > not allowing unknown architectures was on purpose. But I suppose I > don't have such a strong position on this, and could just apply this > patch... what do you think, Frank? I don't find it unreasonable to somehow warn about unknown architectures but the current code errors out completly and gives a very misleading error message. So in my opinion the patch is an improvement. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379418: dpkg-buildpackage: signing .dsc and .changes fails with UTF-8 encoded uid
On Thu, Sep 27, 2007 at 11:55:56PM +0200, Székelyi Szabolcs wrote: > Frank Lichtenheld wrote: > > On Sun, Jul 23, 2006 at 02:46:26PM +0200, Székelyi Szabolcs wrote: > >> Lintian (and Policy?) requires the Debian changelog to be UTF-8 > >> encoded. But if -- for example, -- the maintainer name is encoded this > >> way, then gpg fails to find the secret key because assumes by default > >> that the command line parameters are not UTF-8 encoded. Passing > >> - --utf8-strings to gpg solves the problem. > >> > >> Patch attached. > > > > Can you give me a quick example that demonstrates the difference? > > I can't seem to find one. > > Just try building libvrb. Can it be a locale problem? > > My $LANG is unset by default, this way I get: Weird, now I can reproduce it too (And yeah, if LANG is set to a UTF-8 locale the error doesn't occour). Adding --utf8-strings seems indeed to be the best solution. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/
Bug#444362: dpkg-dev: dpkg-buildpackage fails in experimental chroot
On Fri, Sep 28, 2007 at 12:18:54AM +, peter green wrote: > debian:/gfire-trunk# LANG=C linux32 dpkg-buildpackage > dpkg-buildpackage: source package gaim-xfire > dpkg-buildpackage: source version 0.7.0-trunk0 > dpkg-buildpackage: source changed by Peter Green <[EMAIL PROTECTED]> > dpkg-buildpackage: host architecture i386 > debian/rules clean > Can't exec "": No such file or directory at /usr/bin/dpkg-buildpackage line > 324. > dpkg-buildpackage: failure: debian/rules clean failed with unknown exit code > -1 > debian:/gfire-trunk# > > downgrading dpkg-dev to unstable's version makes the package build fine. > > Running debian/rules clean manually also works fine. Hmm, seems to new dpkg-buildpackage doesn't like an empty rootcommand. Will be fixed in the next upload. If you need a workaround, using fakeroot or sudo should work. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427210: dpkg-gencontrol: confusing error message when using inofficial architecture
tag 427210 patch
thanks
On Sat, Jun 02, 2007 at 01:43:21PM +0200, Bernhard R. Link wrote:
> dpkg-gencontol does:
>
> grep(debarch_is($host_arch, $_), @archlist) ||
> &error(sprintf(_g("current build architecture %s does not".
> " appear in package's list (%s)"),
> $host_arch, "@archlist"));
>
> which in current unstable results in a confusing error message like:
> dpkg-gencontrol: error: current build architecture abacus does not appear in
> package's list (abacus)
I suggest this patch to fix the issue:
>From 16a119732007d5922f383a144c0d9137008aeedd Mon Sep 17 00:00:00 2001
From: Frank Lichtenheld <[EMAIL PROTECTED]>
Date: Tue, 25 Sep 2007 01:01:30 +0200
Subject: [PATCH] controllib.pl: debarch_is(foo, 'any') should always be true
Currently this will not return true if foo has no defined
triplet.
Signed-off-by: Frank Lichtenheld <[EMAIL PROTECTED]>
---
scripts/controllib.pl |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/scripts/controllib.pl b/scripts/controllib.pl
index 1b7c52d..d5d1716 100755
--- a/scripts/controllib.pl
+++ b/scripts/controllib.pl
@@ -299,6 +299,9 @@ sub debarch_eq($$)
sub debarch_is($$)
{
my ($real, $alias) = @_;
+
+return 1 if $alias eq 'any';
+
my @real = debarch_to_debtriplet($real);
my @alias = debwildcard_to_debtriplet($alias);
--
1.5.2.5
Gruesse,
--
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439979: reversed patches
On Tue, Aug 28, 2007 at 09:39:40PM +0100, Neil Williams wrote:
> The /usr/share/dpkg-cross/buildcross file is part of dpkg-cross 1.99
> +2.0.0pre2 which is due to be uploaded to experimental just after pre1
> leaves NEW.
[...]
> --- dpkg.old/scripts/dpkg-buildpackage.sh 2007-08-27 23:23:28.0
> +0100
> +++ dpkg-1.14.5/scripts/dpkg-buildpackage.sh 2007-08-28 20:06:39.0
> +0100
> @@ -84,6 +84,18 @@
> passopts=''
> admindir=''
>
> +DPKGCROSSENABLE=0
> +if [ -f /usr/share/dpkg-cross/buildcross ]; then
> + . /usr/share/dpkg-cross/buildcross
> + DPKGCROSSENABLE=1
> +fi
> +
> +function enhance_cross {
> + if [ $DPKGCROSSENABLE -gt 0 ]; then
> + setup_cross
> + fi
> +}
> +
Just to make your life harder ;) I've now decided to convert
dpkg-buildpackage to a Perl script (see head of master branch
in git). Therefor this part of the patch doesn't apply anymore.
Gruesse,
--
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334998: dpkg-dev: Should include .orig also with 0something debian version.
On Fri, Oct 21, 2005 at 01:40:18PM +0200, Sven Luther wrote: > Well, subjects says it all, when making experimental uploads, with debian > version of -0experimental.n or similar, in order to be older than the -1 > version which will go to unstable, dpkg-buildpackage does not include the > .orig, and thus often builds are uploaded by mistake without the .orig, which > is a pain. And yes, i know about -sa or whatever it was, but it is so easy to > forget. > > I think it would be reasonable to include the .orig with -0experimental.1 or > something such uploads, or at least issue a warning about this if such a > version is detected and -sa not provided. Since we have '~' nowadays for problems like these and everything aside from the obvious stuff we currently catch (i.e. 0|1|0.1) is just pure guesswork I would suggest closing this bug. (The only somewhat sane way to improve automatic -sa handling is requested by #28701 "dpkg-genchanges should compare the version numbers", IMHO) Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440972: ADV: Bug#440972: dpkg-dev: [PATHC] dpkg-source: Default value for standalone -I
On Sun, Sep 23, 2007 at 12:25:54PM +0300, Jari Aalto wrote:
> * Sun 2007-09-23 Frank Lichtenheld INBOX
> Below new patch according to comment.
Looks much better.
> +my $ignore_tar_default_regexp = "
> +.[#~]*
> +*[#~]
> +'{arch}'
the quotes don't belong here.
> +.a
This should be *.a, shouldn't it?
Similar for .la, .o, .so, and .swp
> +.arch-ids
> +.arch-inventory
> +.bzr
> +.bzr.backup
> +.bzr.tags
> +.bzrignore
> +.cvsignore
> +.deps
> +.git
> +.gitignore
> +.hg
> +.la
> +.o
> +.shelf
> +.so
> +.svn
> +.swp
> +CVS
> +DEADJOE
> +RCS
> +_MTN
> +_darcs
> +";
What are the reasons for differences to the diff ignore default? I
understand the addition of .a, .o, and .so since these will cause errors
in diffs anyway but not for tars. But you at least left out the
tla/bazaar style temp directories (i.e. ',,*'). Any reason?
> +# Remove possible leading and trailing whitespace
> +$ignore_tar_default_regexp =~ s/\A\s+//;
> +$ignore_tar_default_regexp =~ s/\s+\Z//;
> +
> +# Remove possible comment lines; remove newllines to spaces
> +$ignore_tar_default_regexp =~ s/#*\s*[\r\n]+/ /gm;
I think if we use an array for the default, the rest of the code gets
much, much easier. I.e. @tar_ignore_default_regexp = qw'...';
Gruesse,
--
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435126: dpkg-source please ignore vcs dirs for native packages too
On Thu, Aug 02, 2007 at 08:33:05PM +0200, Raphael Hertzog wrote: > I agree with maks that it would be nice if dpkg-source excluded those > directories by default. Thus I made this small patch. > > If Guillem or Frank are OK with this patch, I can apply it myself. > I tested it here and it works fine at least in the case of dpkg's git > repository. Apart from the fact that the patch looks more like a proof-of-concept than a real patch (e.g. no documentation updates, default list is not overridable) I'm a bit wary about changing the default behaviour of dpkg-source about this. A good opportunity to change the default behaviour of dpkg-source would be the addition of wig&pen build support, BTW ;) Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440972: dpkg: [PATCH] dpkg-source - Additional fixes (e.g. treat -I only once)
On Thu, Sep 06, 2007 at 12:13:18AM +0300, Jari Aalto wrote:
> +++ b/scripts/dpkg-source.pl
> @@ -190,6 +190,7 @@ sub handleformat {
>
>
> my $opmode;
> +my $flag_I_opt_done;
>
> while (@ARGV && $ARGV[0] =~ m/^-/) {
> $_=shift(@ARGV);
> @@ -216,7 +217,9 @@ while (@ARGV && $ARGV[0] =~ m/^-/) {
> } elsif (m/^-I(.+)$/) {
> push @tar_ignore, "--exclude=$1";
> } elsif (m/^-I$/) {
> -push @tar_ignore, $diff_I_opt_default_regexp;
> +push @tar_ignore, $diff_I_opt_default_regexp unless
> $$flag_I_opt_done;
> + # Prevent adding multiple times
> + $flag_I_opt_done = "done";
> } elsif (m/^-V(\w[-:0-9A-Za-z]*)[=:]/) {
> $substvar{$1}= "$'";
> } elsif (m/^-T/) {
looks like inconsistent whitespace.
Gruesse,
--
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440972: dpkg-dev: [PATHC] dpkg-source: Default value for standalone -I
On Wed, Sep 05, 2007 at 11:22:38PM +0300, Jari Aalto wrote:
> Here is patch to make -I behave like -i, that is to supply default option
> of given standalone.
I like the general idea, but there are some issues with the patch.
> --- a/scripts/dpkg-source.pl
> +++ b/scripts/dpkg-source.pl
> @@ -31,9 +31,40 @@ my $diff_ignore_default_regexp = '
> (?:^|/)(?:DEADJOE|\.cvsignore|\.arch-inventory|\.bzrignore|\.gitignore)$|
> # File or directory names that should be ignored
> (?:^|/)(?:CVS|RCS|\.deps|\{arch\}|\.arch-ids|\.svn|\.hg|_darcs|\.git|
> -\.shelf|\.bzr(?:\.backup|tags)?)(?:$|/.*$)
> +_MTN|\.shelf|\.bzr(?:\.backup|tags)?)(?:$|/.*$)
> ';
This hunk clearly doesn't belongs to this patch. I will add it myself.
> +my $diff_I_opt_default_regexp = "
> +--exclude=.[#~]*
> +--exclude=*[#~]
> +--exclude='{arch}'
> +--exclude=.a
> +--exclude=.arch-ids
> +--exclude=.arch-inventory
> +--exclude=.bzr
> +--exclude=.bzr.backup
> +--exclude=.bzr.tags
> +--exclude=.bzrignore
> +--exclude=.cvsignore
> +--exclude=.deps
> +--exclude=.git
> +--exclude=.gitignore
> +--exclude=.hg
> +--exclude=.la
> +--exclude=.o
> +--exclude=.shelf
> +--exclude=.so
> +--exclude=.svn
> +--exclude=.swp
> +--exclude=CVS
> +--exclude=DEADJOE
> +--exclude=RCS
> +--exclude=_MTN
> +--exclude=_darcs
> +";
> +
> +$diff_I_opt_default_regexp =~ s/#*\s*[\r\n]+//gm;
It would probably be better to add the --exclude after the fact since
that is just redundant here and will bloat the usage message. Also
the variable is wrongly named since -I has nothing to do with the
diff...
> --- a/man/dpkg-source.1
> +++ b/man/dpkg-source.1
> @@ -126,12 +126,19 @@ from the ones in your working directory, thus causing
> them to be
> unnecessarily included in every .diff.gz, unless you use the \fB\-i\fR
> switch.
> .TP
> -.BI \-I filename
> -If this option is specified, the filename will be passed to tar's \-\-exclude
> -option when it is called to generate a .orig.tar.gz or .tar.gz file. For
> -example, \-ICVS will make tar skip over CVS directories when generating
> -a .tar.gz file. The option may be repeated multiple times to list multiple
> -filenames to exclude.
> +.BI \-I[\fIfile-pattern\fP]
> +
> +If this option is specified, the filename pattern will be passed to
> +tar's \-\-exclude option when it is called to generate a .orig.tar.gz
> +or .tar.gz file. For example, \-ICVS will make tar skip over CVS
> +directories when generating a .tar.gz file. The option may be repeated
> +multiple times to list multiple filenames to exclude. If this option
> +is givel
Looks broken.
> +
> +\fB\-I\fR by itself adds default tar(1) \-\-exclude options that will
> +filter out control files and directories of the most common revision
> +control systems, backup and swap files and Libtool build output
> +directories.
> .PP
> All the
> .BI \-s X
(If you want to provide a fixed patch, please provide a complete one,
not incremental ones on the last version.
Gruesse,
--
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435126: unmerging 435126
# Automatically generated email from bts, devscripts version 2.10.8 # on second thought they are not exactly the same unmerge 435126 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440636: support for parallel builds (dpkg-buildpackage -j N)
On Mon, Sep 03, 2007 at 12:28:05PM +0200, Robert Millan wrote: > Attached patch adds support for parallel builds (dpkg-buildpackage -j N). > > It is based on the one from bug #355654. I like the general idea. But why do you use $makecommand? Wouldn't "debian/rules $makeoptions build" work just as well? > if [ x$sourceonly = x ]; then > - withecho debian/rules build > - withecho $rootcommand debian/rules $binarytarget > + withecho $makecommand -f debian/rules build > + withecho $rootcommand $makecommand -f debian/rules $binarytarget > fi > if [ "$usepause" = "true" ] && \ > ( [ "$signchanges" != ":" ] || ( [ -z "$binaryonly" ] && [ "$signsource" > != ":" ] ) ) ; then > @@ -281,7 +284,7 @@ > fi > > if $cleansource; then > - withecho $rootcommand debian/rules clean > + withecho $rootcommand $makecommand -f debian/rules clean > fi > > echo "dpkg-buildpackage: $srcmsg" Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440973: dpkg-scanpackages.1.gz: bzip2 vs. gzip
On Wed, Sep 05, 2007 at 06:27:17AM -0700, Jack Bates wrote: > The dpkg-scanpackages manpage notes: > >Note: If you want to access the generated Packages file with apt you >will probably need to compress the file with gzip(1) (generating a >Packages.gz file). apt ignores uncompressed Packages files except on >local access (i.e. file:// sources). > > However APT now seems to require a Packages.bz2 file. Thanks, Jack It prefers a Packages.bz2 file but it will happily use a Packages.gz file, too. So the above is not false. Maybe we want to mention both gzip and bzip, though. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#379418: dpkg-buildpackage: signing .dsc and .changes fails with UTF-8 encoded uid
On Sun, Jul 23, 2006 at 02:46:26PM +0200, Székelyi Szabolcs wrote: > Lintian (and Policy?) requires the Debian changelog to be UTF-8 > encoded. But if -- for example, -- the maintainer name is encoded this > way, then gpg fails to find the secret key because assumes by default > that the command line parameters are not UTF-8 encoded. Passing > - --utf8-strings to gpg solves the problem. > > Patch attached. Can you give me a quick example that demonstrates the difference? I can't seem to find one. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/
Bug#430463: Directory /usr/share/doc/dpkg-dev is empty
On Tue, Jul 10, 2007 at 08:22:28PM -0400, Frédéric Brière wrote: > On Wed, Jul 11, 2007 at 01:08:02AM +0200, Frank Lichtenheld wrote: > > dpkg-dev. On the other hand the current maintainer scripts handle > > upgrade issues for even more ancient versions. So I'm a bit reluctant > > Forgive my ignorance, but are you saying that dpkg-dev comes with > maintainer scripts? Nah, I was using dpkg in the sense of "source package". dpkg-dev has no maintainer scripts currently. dpkg itself has very extensive ones, though. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/
Bug#430463: Directory /usr/share/doc/dpkg-dev is empty
severity 430463 wishlist tag 430463 - moreinfo unreproducible thanks On Tue, Jul 10, 2007 at 06:41:25PM -0400, Frédéric Brière wrote: > On Wed, Jul 11, 2007 at 12:17:39AM +0200, Frank Lichtenheld wrote: > > Since nobody so far seems to have encountered the same problem I'm > > inclined to close the bug report. If you still think there is really > > As Raphaël pointed out, dpkg-dev probably contained a real directory > eons ago (I'm sure I must have done at least one full re-install since > bo, but I couldn't say when was the last one), and dpkg doesn't cope > well with that. Removing and installing worked out fine, obviously. > > Do feel free to either close this bug (on account that it is documented > deep in the bowels of the policy), or merge it with #156463, whichever > is best. On the one hand this is a upgrade issue for some ancient version of dpkg-dev. On the other hand the current maintainer scripts handle upgrade issues for even more ancient versions. So I'm a bit reluctant to close this outright. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/
Bug#430463: Directory /usr/share/doc/dpkg-dev is empty
On Sun, Jun 24, 2007 at 03:58:20PM -0400, Frédéric Brière wrote: > Package: dpkg-dev > Version: 1.14.4 > Severity: serious > Justification: Policy 12.5 > > dpkg-dev only comes with an empty /usr/share/doc subdir, without any > changelog or copyright. Was this meant to be a symlink to dpkg? Hi. Since nobody so far seems to have encountered the same problem I'm inclined to close the bug report. If you still think there is really a bug here please provide the output of "dpkg -s dpkg-dev" and "dpkg -L dpkg-dev" Also it would be interesting if the symlink is still missing after a reinstall of 1.14.4 or an upgrade 1.14.5 Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/
Bug#353040: reassign 353040 to dpkg
# Automatically generated email from bts, devscripts version 2.10.6 # sorry, don't know what I was smoking reassign 353040 dpkg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375506: dpkg --search needs more escaping
On Mon, Jul 02, 2007 at 12:23:33PM -0400, Justin Pryzby wrote: > On Mon, Jul 02, 2007 at 06:16:31PM +0200, Frank Lichtenheld wrote: > > Just for the record, I would opose both patches on the ground of very > > confusing and undefined behaviour. > Also, if this is not intended to work, it's okay to close this.. It is probably not intended to work, which doesn't mean it can't be made to work if someone is really interested in it :) Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426752: Ubuntu-specific Maintainer: field processing, safety check
On Wed, May 30, 2007 at 03:32:59PM -0600, Bruce Sass wrote: > On Wed May 30 2007 12:42:07 pm you wrote: > > If you have any comments regarding our approach we'd of course be > > happy to hear about them. > > I don't think it is a good idea to hard-code "downstream" specific bits > into the source... I tend to agree. There are also already packages in the archive like update-manager that use the string "ubuntu" in their version. > How about creating a framework for hooking code into the build process. > Perhaps running/sourcing scripts out of a dir, trigerred by a setting > in the environment---anyone could use it (mitigates any `why should > Ubuntu get special treatment' arguments), everyone using it can work at > their own pace (never be out-of-sync or behind), couldn't lead to > source bloat disease. In this specific case, adding a check to Ubuntu's version of lintian might be way easier... Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375506: dpkg --search needs more escaping
tag 375506 - patch thanks On Wed, Jul 05, 2006 at 05:41:54PM +1000, Brendan O'Dea wrote: > On Sat, Jul 01, 2006 at 07:07:11PM +0200, Nicolas François wrote: > >On Thu, Jun 29, 2006 at 05:43:48PM +1000, Brendan O'Dea wrote: > >> We could do something similar for --search (see patch following), > >> although note that while this means that '-S /usr/bin/[' now works, > >> '-S [' will not. > > > >Just a variation of your patch with strstr instead of strcmp, '-S [' works. > > It also changes the behaviour a little. Consider > 'dpkg -S /usr/share/man/man1/\[', which now matches the man page. > > Probably not a huge issue given the number of paths which actually do > contain metacharacters, but the intent was simply to make > 'dpkg -S /full/path' work reliably (i.e. where did that file come from?). Just for the record, I would opose both patches on the ground of very confusing and undefined behaviour. A more complete and less confusing patch would probably have to store the original string before the leading and trailing '*' are inserted, escape all wildcards in it, then conditionally add the '*'s and make every match twice, one time with the escaped string. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/
Bug#430367: Integrate support of a newer dpkg-shlibdeps working at the symbol level
On Sun, Jul 01, 2007 at 12:45:56PM +0200, Frank Lichtenheld wrote: > 1) Apply the part of the patch that adds the modules. Since that doesn't >add anything useful to dpkg in its own right, we should probably make >this in a branch > 2) Do some code clean-up > 3) Add a minimal test suite (no excuse not to do this for entirely new code!) >Something simple with Test::More should suffice, but if someone >prefers a more sophisticated framework, I will not stand in his way. > 4) when satisfied with the result, apply the rest of the patch > 5) Merge to trunk/ On second thought: as we don't apply the patch in trunk/, I will apply it completly and not in separate steps Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430367: Integrate support of a newer dpkg-shlibdeps working at the symbol level
On Sat, Jun 23, 2007 at 09:17:24PM +0100, Raphael Hertzog wrote: > It creates a set of modules in /usr/lib/dpkg/Dpkg/ as I need some shared > code between dpkg-gensymbols and dpkg-shlibdeps. > > There's no documentation update yet, but I shall work on that once the > code is integrated. I'll maintain that code over time and do any possible > bugfixes and enhancements that may appear. > > I expect at least some enhancements in the way we handle the symbols files > over the set of architectures (ie to share some information instead of > having simply debian/package.symbols.arch). Ok. I would be willing to start integrating this into dpkg. I don't like the overall quality of the code, though. It might not be bad compared to the code that can currently be found in dpkg-dev, but it doesn't really measure up to any objective standards (e.g. there are too many open calls that use the older, much more insecure and somwhat slower syntax). My proposed plan would be to: 1) Apply the part of the patch that adds the modules. Since that doesn't add anything useful to dpkg in its own right, we should probably make this in a branch 2) Do some code clean-up 3) Add a minimal test suite (no excuse not to do this for entirely new code!) Something simple with Test::More should suffice, but if someone prefers a more sophisticated framework, I will not stand in his way. 4) when satisfied with the result, apply the rest of the patch 5) Merge to trunk/ I would give Raphael commit rights to the repository with the understanding that he limits himself to the branch integrating his work for now (I really see no need for technical measures enforcing that, we are all grown-ups, right?) Objections? Comments? Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390915: Revised patch
On Wed, May 30, 2007 at 08:47:02PM +0100, Ian Jackson wrote: > +# Unfortunately tar insists on applying our umask _to the original > +# permissions_ rather than mostly-ignoring the original > +# permissions. We fix it up with chmod -R (which saves us some > +# work) but we have to construct a u+/- string which is a bit > +# of a palaver. (Numeric doesn't work because we need [ugo]+X > +# and [ugo]= doesn't work because that unsets sgid on dirs.) This would probably fix #207289 on the side because it makes all read-only files in the tar ball writable, right? (At least for all remotely practical umask settings...) Will apply the patch. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430463: Directory /usr/share/doc/dpkg-dev is empty
On Mon, Jun 25, 2007 at 07:49:19PM +0200, Frank Lichtenheld wrote: > On Mon, Jun 25, 2007 at 06:39:25PM +0200, Raphael Hertzog wrote: > > It is a symlink to dpkg... but dpkg doesn't replace existing directories > > by a symlink so you ended up that way. I don't know which version of the > > package provided a real directory. In any case, the proper fix is likely to > > remove the (real) empty directory in preinst IIRC. > > While that might be true, at least in the history recorded by SVN there > is no point where this was a real directory... to be more specific: dpkg (1.4.1.14) unstable; urgency=low [...] * Make /usr/share/doc/dpkg-dev a symlink to /usr/share/doc/dpkg -- Wichert Akkerman <[EMAIL PROTECTED]> Tue, 5 Oct 1999 19:19:05 +0200 Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430463: Directory /usr/share/doc/dpkg-dev is empty
On Mon, Jun 25, 2007 at 06:39:25PM +0200, Raphael Hertzog wrote: > It is a symlink to dpkg... but dpkg doesn't replace existing directories > by a symlink so you ended up that way. I don't know which version of the > package provided a real directory. In any case, the proper fix is likely to > remove the (real) empty directory in preinst IIRC. While that might be true, at least in the history recorded by SVN there is no point where this was a real directory... Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430463: Directory /usr/share/doc/dpkg-dev is empty
On Sun, Jun 24, 2007 at 03:58:20PM -0400, Frédéric Brière wrote: > dpkg-dev only comes with an empty /usr/share/doc subdir, without any > changelog or copyright. Was this meant to be a symlink to dpkg? The .deb file contains a symlink. So you're saying this wasn't installed correctly on your system? Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/
Bug#199651: dpkg: Purging instead of removing if no conffiles would be great
On Sat, Jan 20, 2007 at 02:26:31AM +0100, Eric Estievenart wrote: > => at least 130 could have been purged, with all corresponding files > in var/lib/dpkg/info Please note that the difference between remove/purge is one of all configuration of a package, not just its conffiles. dpkg can't know wether a package does delete additional data (like e.g. debconf or ucf data) in case of a purge or not. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404850: closed by Frank Lichtenheld <[EMAIL PROTECTED]> (Re: Bug#404850: dpkg -i fails to replace directory with symlink while upgrading package)
On Thu, Dec 28, 2006 at 03:48:38PM -0500, Jay Berkenbilt wrote: > In any case, the fact that it's documented doesn't make it right. I > think empty directories should be allowed to be replaced. Otherwise, > how do you handle situations such as the one I described? Right now, > people upgrading from sarge to etch will end up with several empty > directories in /usr/share/doc. You can rmdir the directory in the postinst (because it should be empty then) and then create the symlink manually. This is the most common solution I've found in existing packages and it looks reasonably sane and safe. > Do you know the motivation or history for this feature? My guess would be: The reason why dpkg doesn't replace symlinks with directories is probably to allow the local user/admin to relocate a directory tree and symlink it without breaking dpkg usage. The reason why dpkg doesn't replace directories with symlinks is probably because this would effectively require a rm -fr on the directory (or the creation of potentially very big backups) which is not a very good thing to do non-interactively. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374503: dpkg: md5sum doesn't exist upgrading to sid dpkg
On Mon, Jun 19, 2006 at 02:27:30PM -0400, Michael Stone wrote: > At this point I have no idea how a system could get into this state. > Could someone run some upgrades to try to duplicate? (I can't.) I'm pretty sure I tested all upgrade paths from sarge to sid when removing that diversions stuff from dpkg's postinst and I found no scenario in which this error still could happen. But I'm not sure about all possible etch -> sid upgrades. Maybe if we get some more information about the state of the system before the upgrade we can find out what the cause was. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#374503: dpkg: md5sum doesn't exist upgrading to sid dpkg
On Mon, Jun 19, 2006 at 01:44:46PM -0400, Justin Pryzby wrote: > dpkg: xserver-xorg: dependency problems, but removing anyway as you request: > x-window-system-core depends on xserver-xorg. > Removing xserver-xorg ... > /var/lib/dpkg/info/xserver-xorg.prerm: line 909: md5sum: command not found > > Unpacking xserver-xorg (from .../xserver-xorg_1%3a7.0.22_all.deb) ... > Server symlink checksum doesn't exist. We need to make it > Re-adding lost server symlink checksum > /var/lib/dpkg/tmp.ci/preinst: line 932: md5sum: command not found > dpkg: error processing > /var/cache/apt/archives/xserver-xorg_1%3a7.0.22_all.deb (--unpack): > subprocess pre-installation script returned error exit status 127 > > Setting up xserver-xorg (7.0.22) ... > /var/lib/dpkg/info/xserver-xorg.postinst: line 1628: md5sum: command not found > /var/lib/dpkg/info/xserver-xorg.postinst: line 1673: md5sum: command not found > cat: /var/lib/x11/xorg.conf.md5sum: No such file or directory > /var/lib/dpkg/info/xserver-xorg.postinst: line 1697: md5sum: command not found > > > lrwxrwxrwx 1 root root 6 Apr 10 19:57 /usr/bin/md5sum.textutils -> md5sum > > $ apt-cache policy dpkg > dpkg: > Installed: 1.13.21 > Candidate: 1.13.21 > Version table: > *** 1.13.21 0 > 10 http://ftp.us.debian.org sid/main Packages > > $ apt-cache policy coreutils > coreutils: > Installed: 5.94-1 > Candidate: 5.94-1 > Version table: > 5.96-3 0 > 10 http://ftp.us.debian.org sid/main Packages > *** 5.94-1 0 > > See also #315784, #313605. > > Reinstalling coreutils (5.94-1) fixes the glitch. Do you know which versions of coreutils and dpkg you had installed before the upgrade? Do you have the full upgrade log available? Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373003: dpkg-dev: deb-control.5 old rule for Version hyphenation
On Mon, Jun 12, 2006 at 12:52:19PM -0400, Justin Pryzby wrote: > deb-control.5: >Version: > Typically, this is the original package's version number in > whatever form the program's author uses. It may also include a > Debian revision number (for non-native packages). If both ver- > sion and revision are supplied, they are separated by a hyphen, > `-'. For this reason, the original version may not have a hyphen > in its version number. > > This differs from the description given in current policy, which says > that the upstream version can contain a hyphen, unless there is no > Debian revision. I guess there is a new relaxed requirement? This is really only the symptom of a bigger problem. I was going to fix this bug but then I realised that if we want to make this description really accurate we need to add epochs as well and list the allowed chars etc. The whole deb-control man page is very inaccurate and has few details. So I will ask some questions first as a request for comments: - How accurate should this man page really be? Should have the same level of detail as policy? - What kind of fields should it contain? Should it make a clear distinction between fields used by dpkg and fields ignored by it? Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#192273: Closing this bug?
Hi. This is a very old bug about dpkg-scanpackages. I'm honestly not sure what the exact problem is the submitter has with dpkg-scanpackages behaviour and wether it is just a misinterpretation of the documentation or really a bug. Unless someone (e.g. the submitter) can shed some light on this, this bug should probably be closed as unreproducible. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#221668: Old, unreproducible bug
tag 221668 unreproducible thanks Hi. This is an old bug against dpkg-source titled "/usr/bin/dpkg-source: dpkg-source fails with internal error: unknown line from diff -u" However, the information in this bug seems no sufficient to reproduce it and no similar bugs where reported since then. If noone can provide more information about it (best with an example how to reproduce it) it will need to be closed. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#258192: Close bug?
Hi Colin. This bug still needs some more information what exactly it is about. Without this information it doesn't really make sense to keep it open. [also CCed the submitter this time] Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367052: I'm seeing this too all-of-a-sudden
On Sat, Jun 17, 2006 at 05:00:36PM +0200, Frank Lichtenheld wrote:
> Certainly. But I can't see any way how negating a simple int
> (i.e. the type pid_t is defined to) with an (according to strace)
> well defined value could cause an error like that.
But I have now found a way to reproduce this bug (although I'm not
sure it is really fully the same situation as with the submitters).
Normally aptitude uses libapt-pkg to call dpkg which sets
DPKG_NO_TSTP. If dpkg fails with an error, aptitude calls dpkg
--configure -a directly ("A package failed to install. Trying to
recover:") without setting DPKG_NO_TSTP which leads to the situation
described in the bug report.
Unless someone convinces me that dpkg should do something about this
(e.g. by changing the default behaviour of 'Z') or that there are
other situations where this bug occours I will reassign it to aptitude
and ask for setting DPKG_NO_TSTP before the dpkg --configure -a
call.
Gruesse,
--
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367052: I'm seeing this too all-of-a-sudden
On Fri, Jun 02, 2006 at 11:09:33PM -0400, Anthony DeRobertis wrote: > And a decided simple strace of me pressing Z: > > Process 3743 attached - interrupt to quit > read(0, "Z\n", 1024)= 2 > write(2, "Don\'t forget to foreground (`fg\'"..., 66) = 66 > getpgid(0) = 3685 > kill(4294963611, SIGTSTP) = 0 > - --- SIGTSTP (Stopped) @ 0 (0) --- > write(2, "\nConfiguration file `/etc/X11/fs"..., 40) = 40 > write(2, "\n ==> Modified (by you or by a s"..., 59) = 59 > write(2, " ==> Package distributor has shi"..., 57) = 57 > write(2, " What would you like to do abo"..., 285) = 285 > write(2, " The default action is to keep y"..., 53) = 53 > write(2, "*** config (Y/I/N/O/D/Z) [defaul"..., 39) = 39 > read(0, > Process 3743 detached > > Might just be me, but that PID being killed looks, ummm, a tad bit > funny. Certainly. But I can't see any way how negating a simple int (i.e. the type pid_t is defined to) with an (according to strace) well defined value could cause an error like that. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349442: dpkg dependtry assertion is due to broken cycle breaking
On Fri, Jun 02, 2006 at 07:08:26PM +0100, Ian Jackson wrote: > The patch provided by Frank Lichtenfeld in #349442 is also wrong and > might lead to infinite recursion. findbreakcyclerecursive is not > allowed to recurse except via foundcyclebroken because > foundcyclebroken is the thing which detects the cycle and breaks it. I guess that shows two things: 1) I really shouldn't do patches for the dependency handling code in dpkg 2) Uploading broken patches can sometimes trigger correct ones even when the broken ones lingered a long time in the BTS ;) Gruesse and thanks for correcting my stupid mistakes, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323909: Debian bug#323909: Please ignore Revision Control directories by default
On Wed, Jun 14, 2006 at 11:04:11AM +0300, Jari Aalto wrote: > Hi, this bug has been tagged moreinfo for some time. I'd like to > resove it. Please advice. Please note that the moreinfo is not really about what the request is or how to implement it. It mostly means "we need to decide wether changing this behaviour really is a good idea". And as long as noone from the dpkg maintainers steps forward and says so, it will not be changed. Personally I'm not convinced that changing it is indeed a good idea as the current behaviour is very predictable and simple and can easily be tweaked by the maintainer to get what he wants. Sorry and Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348133: Bug#318825/348133: dpkg: don't forget to delete directories
On Wed, May 17, 2006 at 08:31:48AM +0200, Bart Martens wrote: > On Tue, May 16, 2006 at 11:17:16PM -0500, Frank Lichtenheld wrote: > > Unfortunatly I also discovered that your patch isn't really applicable > > because of a simple fact: It violates the semantics of Conflicts > > relations. If a package conflicts with another one it can expect that > > the other package was removed completly, except for configuration files > > and the directories that hold them. And your patch violates that > > assumption. > > No. That assumption is wrong. A "remove"d package may still have > configuration files to be deleted at "purge" by the postrm. I don't > think my patch violates anything about "Conflicts" relations. Yeah, it can have conffiles and configuration files, but not some random directories somewhere (e.g. /usr/share/*). You're probably right that this is a corner case which is unlikely to cause problems but I still oppose applying it because IMHO side-effects are possible and I rather leave some configuration directories behind like it did the 10 years before... > So, for now, I still think that my patch of 16 Jan 2006 00:45:40 +0100 > posted on bug 318825 is good to fix the problem for both conffiles and > configuration files. I disagree. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#165843: Please localize perl programs as well.
On Fri, May 12, 2006 at 10:40:04AM +0300, Guillem Jover wrote: > On Thu, 2006-05-11 at 22:54:50 -0500, Frank Lichtenheld wrote: > > On Fri, May 12, 2006 at 01:35:21AM +0300, Guillem Jover wrote: > > > I'd like to unify the help output format for all the scripts before > > > translators have a chance to start working on them, though. > > > > ACK. > > I'll do that this weekend probably... Any news on that? Can I help you in any way there. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368000: [S-S-D] --chuid doesn't do the same as --chuid
Package: dpkg
Version: 1.13.19
Severity: minor
[EMAIL PROTECTED]:~$ /sbin/start-stop-daemon --test --chuid 1000 --exec
/bin/true --start
Would start /bin/true (as user 1000[1000]).
[EMAIL PROTECTED]:~$ /sbin/start-stop-daemon --test --chuid djpig --exec
/bin/true --start
Would start /bin/true (as user djpig[1000], and group [1000]).
The default group isn't used when specifying the chuid numerically.
Because probably noone should ever actually use numeric uids here,
I chose severity minor.
Gruesse,
Frank Lichtenheld
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-powerpc
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages dpkg depends on:
ii coreutils [textutils] 5.94-1 The GNU core utilities
ii libc6 2.3.6-7GNU C Library: Shared libraries
dpkg recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367998: [S-S-D] --quiet should also silence --test
Package: dpkg
Version: 1.13.19
Severity: minor
If with --quiet, s-s-d --test shouldn't output anything to stdout. Instead,
--test is ignoring --quiet completly.
Gruesse,
Frank Lichtenheld
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-powerpc
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages dpkg depends on:
ii coreutils [textutils] 5.94-1 The GNU core utilities
ii libc6 2.3.6-7GNU C Library: Shared libraries
dpkg recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367052: conffile prompt background option doesn't work
On Thu, May 18, 2006 at 02:46:20PM -0700, Josh Triplett wrote: > Frank Lichtenheld wrote: > > On Sun, May 14, 2006 at 04:43:31AM -0700, Josh Triplett wrote: > >> I can't think of any reason. When I hit Z and press enter, the message > >> gets printed and then the conffile prompt comes right back up. > > > > Can you please try out the pkg at > > http://people.debian.org/~djpig/dpkg_1.13.19.0djpig1_powerpc.deb > > > > It should at least give you a useful error message. > > I don't run powerpc, but I grabbed the source from > http://people.debian.org/~djpig/dpkg_1.13.19.0djpig1.tar.gz and built an > i386 package to test. Ehmm, yeah, sorry for that... > I extensively tested installing, upgrading, downgrading, and conffile > modification, using a local test package, and couldn't seem to reproduce > the problem with either 1.13.19 or 1.13.19.0djpig1 . (By the way, out > of curiosity, what did you add? The only change in .0djpig1 looks > unrelated to conffiles or backgrounding.) Ehhmm, yeah, sorry for that, too. I indeed applied the wrong patch... > This can only occur along the path leading to a SIGTSTP rather than a > shell, which shouldn't occur when running under aptitude since > libapt-pkg sets DPKG_NO_TSTP when invoking dpkg. The only reason for that to go wrong that I could think of out of my head are either something cleaning the environment, like sudo. But it would new to me that aptitude runs "sudo dpkg". Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367052: conffile prompt background option doesn't work
On Sun, May 14, 2006 at 04:43:31AM -0700, Josh Triplett wrote: > I can't think of any reason. When I hit Z and press enter, the message > gets printed and then the conffile prompt comes right back up. Can you please try out the pkg at http://people.debian.org/~djpig/dpkg_1.13.19.0djpig1_powerpc.deb It should at least give you a useful error message. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ signature.asc Description: Digital signature
Bug#318825: dpkg: fix erranous "directory not empty" warnings (other patch)
(moving the discussion over to a bug that acutally isn't fixed by my patch.) On Sat, May 13, 2006 at 01:26:04PM +0200, Bart Martens wrote: > I have read and tested your patch of Fri, 12 May 2006 22:38:56 -0500. I > confirm that it fixes the problem for defoma/ttf-bitstream-vera and that > it does not fix the problem for openssl/ca-certificates. I don't see > this patch cause regression. > > To fix openssl/ca-certificates the only way I see is to keep > /etc/ssl/certs and /etc/ssl in /var/lib/dpkg/info/ca-certificates.list > until ca-certificates is "purge"d, because I see no sensible way to make > dpkg know what happens in scripts like postrm. > > I suggest to use my patch of Mon, 16 Jan 2006 00:45:40 +0100. That > patch fixes all known cases so far, including defoma/ttf-bitstream-vera > and openssl/ca-certificates. That patch does make some directories to > be deleted a bit later (discussed before), but I see no way to avoid > that, see above about postrm. Ok. I discussed this today with liw. I now understand that your patch is the only working solution for the problem aside from teaching dpkg about configuration files (so that it actually has a list of them, too). Unfortunatly I also discovered that your patch isn't really applicable because of a simple fact: It violates the semantics of Conflicts relations. If a package conflicts with another one it can expect that the other package was removed completly, except for configuration files and the directories that hold them. And your patch violates that assumption. So in the end I'm now convinced that there is only one solution that will both fix the problem and be according to policy (see above). Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#354999: dpkg: s-s-d documentation wrongly implies that --name only is disallowed
On Thu, Mar 02, 2006 at 11:49:51AM -0500, Justin Pryzby wrote: > So I wonder if the code should be changed, instead of the > documentation. I think if a user wants to shoot himself in the foot we should let him. The man page probably could mention more clearly the advantages and disadvantages of the different methods, though. I think I will clone that bug to be able to differentiate between these two fixes. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367329: /usr/share/dpkg/archtable outdated
On Mon, May 15, 2006 at 07:29:19AM +0200, Jeroen van Wolffelaar wrote: > /usr/share/dpkg/archtable doesn't list amd64 yet (and does list sh which > is no longer in Debian at all). I'm not sure what (if anything) uses the > file, because if it was used, amd64 probably would've been added to it > long time ago. It isn't used anymore anywhere in dpkg but I will add amd64 none-the-less since it explicetly states that it lists the architectures that are in the official archive for sid. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367297: dpkg --merge-avail /dev/stdin doesn't work
On Mon, May 15, 2006 at 05:46:13AM +0800, Dan Jacobson wrote: > # ssh ...|dpkg --merge-avail /dev/stdin > Updating available packages info, using /dev/stdin. > Information about 0 package(s) was updated. I guess this happens because we open the file with mmap. Support for reading the available data from stdin would probably have to be added seperatly. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367052: conffile prompt background option doesn't work
On Sat, May 13, 2006 at 12:16:32AM -0700, Josh Triplett wrote: > The dpkg prompt for a changed conffile offers the option to "background > this process to examine the situation"; however, choosing this option no > longer has any effect, other than printing a message: Works perfectly well for me. Directly after the message the following commands gets executed: kill(-getpgid(0),SIGTSTP); Do you know of any reason why this might fail in your case? If not I can prepare a patch that adds actual error checking to that peace of code. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
