[PATCH] no longer allower upper case or unterscore characters in package names
Without this patch The C function pkg_name_is_illegal still allows
upper case characters und underscores in packages names.
This especially causes dpkg-deb to still be able to create packages
with upper case characters in them. (underscores are already impossible
because check_control_file checks the lowercased packagename).
This change also makes it impossible to install .deb files with
upper case characters in their control file. As the /var/lib/dpkg/status
file gets the lowercased names (both for package names and dependencies)
this could only break a system which has packages installed with
underscores in their names, which is extremely unlikely as dpkg-deb
could not build them.
---
Different sets of characters being allowed at different places has
caused a lot of confusion and some bugs over the years and
especially the handling of upper case characters has a (low) chance
of allowing to circumventing some security measures somewhere.
As the only commercial .deb files with upper case characters are already
fixed since some years, I think it is preferable to fix it at once
instead of only fixing dpkg-deb now.
---
lib/dpkg/parsehelp.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/lib/dpkg/parsehelp.c b/lib/dpkg/parsehelp.c
index a999b5e78..1a041b133 100644
--- a/lib/dpkg/parsehelp.c
+++ b/lib/dpkg/parsehelp.c
@@ -139,8 +139,7 @@ find_arbfield_info(const struct arbitraryfield *arbs, const
char *fieldname)
const char *
pkg_name_is_illegal(const char *p)
{
- /* TODO: _ is deprecated, remove sometime. */
- static const char alsoallowed[] = "-+._";
+ static const char allowed[] = "-+.abcdefghijklmnopqrstuvwxyz0123456789";
static char buf[150];
int c;
@@ -148,13 +147,13 @@ pkg_name_is_illegal(const char *p)
if (!c_isalnum(*p))
return _("must start with an alphanumeric character");
while ((c = *p++) != '\0')
-if (!c_isalnum(c) && !strchr(alsoallowed, c))
+if (!strchr(allowed, c))
break;
if (!c) return NULL;
snprintf(buf, sizeof(buf), _(
"character '%c' not allowed (only letters, digits and characters
'%s')"),
- c, alsoallowed);
+ c, "-+.");
return buf;
}
--
2.39.2
Re: Idea: sbuild/pbuilder "--dgit" option
* Ian Jackson [161231 01:57]:
> What I was suggesting was that users should, as an alternative, be
> able to do the build themselves rather than via dgit, and still get
> the .gitignore included.
To highlight a point that I think is quite important here: adding
-i.git/ instead of the default is at least for 3.0 (quilt) packages
is not about including the .gitignore.
The effect it has (and what I understand the thing you want), is that it
will make a build *fail* if there is a .git-ignore file that has a
different content than the .orig.tar.* (or is not included in the form
of a debian/patches/ file). Because when it is no longer an ignored
derivation between unpacked source and current clean working directory,
it is by definition an fatal error. (Unless one was to reintroduce the
annoying, error-hiding, error-introducing 'generate new patches at build'
time behaviour).
Bernhard R. Link
--
F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Re: Idea: sbuild/pbuilder "--dgit" option
* Mattia Rizzolo [161229 18:56]: > On Thu, Dec 15, 2016 at 08:25:53PM +, Ian Jackson wrote: > > This is because the default ignore rules (in dpkg-source) ignore > > .gitignore, but dgit needs the source package to contain (any changes > > to) .gitignore. So dgit arranges that (if you use dgit to do the > > build-for-upload) dpkg-source gets passed -i\.git/ -I.git. > > Oh, I've never realized that... > > > What would you think (particularly, sbuild and pbuilder folks) about a > > supporting a --dgit option ? The effect would be to pass -i\.git/ > > -I.git to dpkg-source. (Possibly there might be other effects which > > would be desirable, but this is the only essential one for those two > > tools I think.) > > In general, I'm open to that for pbuilder (as I also expressed > elsewhere), as long as it's not going to be documented in the "user > manpage" and we manage changes to that interfaces only between us (i.e., > I don't want anybody else to start relying on the behavior of that > flag). > > > I'm mailing you both at once, with a big CC list, because ISTM that a > > conventional option name would be better than having each tool do its > > own thing. > > Much appreciated, thank you. > > > Anyway, thanks to everyone for your opinions, whatever they may be. > > Here is pbuilder's maintainer view on this dpkg-source "problem": > pbuilder never calls `dpkg-source -b` itself. The only `dpkg-source` > invocation I found by grepping the source is > dpkg-source -x $(basename "$PACKAGENAME") > so, not affected by that. > For pbuilder the only thing you can do is to pass > --debbuildopts --source-option=-i.git/ --debbuildopts > --source-option=-I.git > or > --debbuildopts "--source-option=-i.git/ --source-option=-I.git" > whichever fits you better. > >From my point of view (and thus from a git-dpm workflow), ignoring .gitignore as dpkg-source does by default is the only sane thing to do. (I only wished it would by default also ignore debian/.git* and thus include the debian/.git-dpm in the default ignore list). I might be wrong, but having issues with .gitignore in the generated source package is a dgit-only thing (and from what I understand from DebConf2015) also not a technical but rather an ideological dgit thing. Thus I guess naming such an option --dgit would only be natural. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC
Re: dpkg-source --commit fails to find local changes
* Guillem Jover [140815 17:50]: > On Fri, 2014-08-15 at 15:34:09 +0100, Neil Williams wrote: > > I'm unable to get dpkg-source to see that I have changed files in a > > python source package format 3.0 (quilt): > > > > dpkg-source: info: there are no local changes to record > > > > No matter what I seem to do inside the json-schema-validator package, > > dpkg refuses to spot the change, even renaming the package in setup.py > > or changing the .py files. I get no warning on building and I have to > > create the patch manually. > > > > Is this a regression or is there something different about the > > json-schema-validator and versiontools packages? > > > > This happened with 1.17.11 and 1.17.12. > > This looks like it might be a regression yes, I'm checking the obvious > culprits now. This also effects the normal dpkg-source --build run: It silently ignores unrecorded changes and just creates a source package without them. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140817112230.ga3...@client.brlink.eu
Re: Bug#748936: apt doesnt understand architecture wildcards
* Guillem Jover [140604 03:42]: > * Other programs could “easily” use dpkg-architecture to check for >identity or a match. (This poses problems for programs that do not >want to either require dpkg around or to fork its tables.) That assumes that dpkg knows the arechitecture already on the system you need the information. Take for example something looking at build dependency information to queue builds on other systems. Or something creating a partial mirror of a repository containing what is needed to build specific packages on some architectures. If the only way is "call dpkg-architecture" then this host needs to run the newest dpkg in order to be able to also be able to handle new architectures. And on infrastructure hosts you usually prefer to just run unmodified stable. > * We need a unique 1:1 bi-directional mapping from GNU triplets to >Debian architectures, some of the properties are hidden and need >to be internally expanded. > * Because those hidden properties are implicit, they require a table >which might not be known by other programs anyway. > * Matching on cpu instead of arch name, was the logical route once >the architectures had been expanded into their normalized forms >(the Debian triplets). The question is: Why should the wildcards be able to match about details only visible in the triplets. A wildcard that just matches "Debian architecture without the kernel" would be much easier to implement and not need additional knowledge (except some easy to builtin "if there is no - then it is an implicit "linux-*"). > * Matching on cpu instead of arch name, supposedly made adding support >distribution-wide for things like armel or lpia way easier. (This >might not have been worth it though.) Indeed, while it makes adding architectures similar to existing ones a bit easier, it might make creating new architectures that much harder in return (due to needing a patched dpkg even on other architectures first). And is one even able to express things like "only build depend on this on armhf but not on armel"? > But, I agree this might seem confusing, and that's why I left #694630 > open, because I want to deal with it some way or another. I'd have to > check if it would be feasible to match against the arch name instead of > cpu name, but even if there was no fundamental blocker there, changing > that now would imply a backward incompabitble change, and would require > at least someone going over the archive and taking care of any fallout > beforehand, and that does not cover out-of-archive packaging and > infrastructure, etc. So I'm not sure this seems appealing… but I'll > make a note of at least checking it. At least I'd suggest to not allow it in the Debian archive yet. Not everything dpkg supports must be allowed by policy. (Like upper case letters in package names). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140606155617.ga2...@client.brlink.eu
Re: Bug#748936: apt doesnt understand architecture wildcards
* Russ Allbery [140525 22:58]: > > and having such important fields a meaning that you cannot calculate > > without knowing what architectures the system finally using the package > > uses makes it unhandable). > > I'm not completely sure what you mean by this, but if you mean that you > can't know what architecture strings are valid without knowing which > architectures are supported by dpkg, I think that's a feature in Policy, > not a bug. I wouldn't want to update Policy every time a new architecture > was added. That happens quite frequently. I mean that no tool can give meaning to those strings without having the full architecture table of the dpkg on the machine where this is to be finally interpreted. (Which especially means that any tools trying to interprete anything with those wildcards needs something from a dpkg that already knows those architectures.). Something like a "any-FOO" matching any debian architecture "*-FOO" and "FOO" would be something simple. Having magic like any-arm also matching armhf means it cannot be processed without having special knowledge of the architectures. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140603220205.gb3...@client.brlink.eu
Re: Bug#748936: apt doesnt understand architecture wildcards
* Johannes Schauer [140522 13:30]: > Debian policy 11.1.1 [1] and the associated footnote [2] allow > architecture wildcards of the form os-any and any-cpu. Apt seems to > equal "cpu" with "debian architecture" which is not correct. Here is an > example of correct matching: > > dpkg-architecture -aarmhf -iany-arm && echo "any-arm matches armhf" > > Apt would instead only match the deprecated "arm" architecture with > "any-arm". This doesnt seem to be a problem in practice though because: > > 1) apt does not check whether a source package can be compiled on the > current host architecture (it ignores the Architecture field of > source packages) > 2) all packages that have any-arm in their build dependency > architecture restrictions also include any-armel, any-armeb and > any-armhf > > Nevertheless, apt behaviour should reflect dpkg behaviour and naturally > policy. The correct behaviour is encoded in dpkg scripts/Dpkg/Arch.pm > and needs the files /usr/share/dpkg/triplettable and > /usr/share/dpkg/cputable to work correctly. Urgh. Really? This is far too complicated for most programs to implement properly. I'd suggest to rather fix dpkg (and also fix policy. The footnote describes absolutely nothing currently, and having such important fields a meaning that you cannot calculate without knowing what architectures the system finally using the package uses makes it unhandable). Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140525200448.ga21...@client.brlink.eu
[PATCH v2] Dpkg::Version, Dpkg::Source::Package: move version-without-epoch outputting to the Version module
Instead of doing the magic of generating a version string without epoch
and revision and a version string without epoch in
Dpkg::Source::Package, extend Dpkg::Version's as_string function to
support generating that string.
---
scripts/Dpkg/Source/Package.pm |6 +-
scripts/Dpkg/Version.pm| 14 +-
2 files changed, 10 insertions(+), 10 deletions(-)
* Guillem Jover [130209 18:43]:
> On Sat, 2013-02-09 at 15:18:04 +0100, Guillem Jover wrote:
> > On Sat, 2013-02-09 at 15:03:31 +0100, Bernhard R. Link wrote:
> > > Instead of doing the magic of generating a version string without epoch
> > > and revision and a version string without epoch in
> > > Dpkg::Source::Package, extend Dpkg::Version's as_string function to
> > > support generating that string.
> >
> > I like the idea, but I'd prefer the function to take a bitwise single
> > flag argument instead, with proper constants.
>
> Err, being this perl, an options hash argument would do even better.
how about this one?
diff --git a/scripts/Dpkg/Source/Package.pm b/scripts/Dpkg/Source/Package.pm
index 47ea319..aff0eed 100644
--- a/scripts/Dpkg/Source/Package.pm
+++ b/scripts/Dpkg/Source/Package.pm
@@ -289,11 +289,7 @@ sub get_basename {
error(_g("source and version are required to compute the source
basename"));
}
my $v = Dpkg::Version->new($f->{'Version'});
-my $basename = $f->{'Source'} . "_" . $v->version();
-if ($with_revision and $f->{'Version'} =~ /-/) {
-$basename .= "-" . $v->revision();
-}
-return $basename;
+return $f->{'Source'} . "_" . $v->as_string({no_epoch=>1,
no_revision=>!$with_revision});
}
sub find_original_tarballs {
diff --git a/scripts/Dpkg/Version.pm b/scripts/Dpkg/Version.pm
index 7c1c0f6..19c4509 100644
--- a/scripts/Dpkg/Version.pm
+++ b/scripts/Dpkg/Version.pm
@@ -21,7 +21,7 @@ package Dpkg::Version;
use strict;
use warnings;
-our $VERSION = "1.00";
+our $VERSION = "1.01";
use Dpkg::ErrorHandling;
use Dpkg::Gettext;
@@ -177,18 +177,22 @@ sub comparison {
return version_compare_part($a->revision(), $b->revision());
}
-=item "$v", $v->as_string()
+=item "$v", $v->as_string(), $v->as_string({no_epoch=>1, no_revision=>1})
Returns the string representation of the version number.
=cut
sub as_string {
-my ($self) = @_;
+my ($self, $arg_ref) = @_;
+my $no_epoch = $arg_ref->{no_epoch} || '';
+$no_epoch ||= $self->{no_epoch};
+my $no_revision = $arg_ref->{no_revision} || '';
+$no_revision ||= $self->{no_revision};
my $str = "";
-$str .= $self->{epoch} . ":" unless $self->{no_epoch};
+$str .= $self->{epoch} . ":" unless $no_epoch;
$str .= $self->{version};
-$str .= "-" . $self->{revision} unless $self->{no_revision};
+$str .= "-" . $self->{revision} unless $no_revision;
return $str;
}
--
1.7.10.4
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130210121828.ga3...@client.brlink.eu
[PATCH] Dpkg::Version, Dpkg::Source::Package: move version-without-epoch outputting to the Version module
Instead of doing the magic of generating a version string without epoch
and revision and a version string without epoch in
Dpkg::Source::Package, extend Dpkg::Version's as_string function to
support generating that string.
---
scripts/Dpkg/Source/Package.pm |6 +-
scripts/Dpkg/Version.pm| 14 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/scripts/Dpkg/Source/Package.pm b/scripts/Dpkg/Source/Package.pm
index 47ea319..e60995d 100644
--- a/scripts/Dpkg/Source/Package.pm
+++ b/scripts/Dpkg/Source/Package.pm
@@ -289,11 +289,7 @@ sub get_basename {
error(_g("source and version are required to compute the source
basename"));
}
my $v = Dpkg::Version->new($f->{'Version'});
-my $basename = $f->{'Source'} . "_" . $v->version();
-if ($with_revision and $f->{'Version'} =~ /-/) {
-$basename .= "-" . $v->revision();
-}
-return $basename;
+return $f->{'Source'} . "_" . $v->as_string(1, !$with_revision);
}
sub find_original_tarballs {
diff --git a/scripts/Dpkg/Version.pm b/scripts/Dpkg/Version.pm
index a113c58..26ee154 100644
--- a/scripts/Dpkg/Version.pm
+++ b/scripts/Dpkg/Version.pm
@@ -21,7 +21,7 @@ package Dpkg::Version;
use strict;
use warnings;
-our $VERSION = "1.00";
+our $VERSION = "1.01";
use Dpkg::ErrorHandling;
use Dpkg::Gettext;
@@ -166,18 +166,22 @@ sub comparison {
return version_compare_part($a->revision(), $b->revision());
}
-=item "$v", $v->as_string()
+=item "$v", $v->as_string(), $v->as_string($no_epoch),
$v->as_string($no_epoch, $no_revision)
Returns the string representation of the version number.
=cut
sub as_string {
-my ($self) = @_;
+my $self = shift @_;
+my $no_epoch = shift @_ || '';
+$no_epoch ||= $self->{no_epoch};
+my $no_revision = shift @_ || '';
+$no_revision ||= $self->{no_revision};
my $str = "";
-$str .= $self->{epoch} . ":" unless $self->{no_epoch};
+$str .= $self->{epoch} . ":" unless $no_epoch;
$str .= $self->{version};
-$str .= "-" . $self->{revision} unless $self->{no_revision};
+$str .= "-" . $self->{revision} unless $no_revision;
return $str;
}
--
1.7.10.4
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130209140331.ga4...@client.brlink.eu
Re: Bug#571776: document symbols
* Russ Allbery [120317 19:17]: > These two mechanisms differ in the degree of detail that they > provide. A symbols file documents every symbol > that is part of the library ABI and, for each, the version of > the package in which it was introduced. [...] This is misleading. It's about when the symbol with its current meaning was introduced but could be easily misunderstood to mean the first introduction (and some people might not read the later explanations). How about something like | [...] A symbols file documents for each symbol | exported by a library the minimal version of the package any | binary using this symbol will need. [...] > shlibs files also have a flawed representation of > library SONAMEs, making it difficult to use shlibs > files in some unusual corner cases. Only stylistics: How about not using "flawed"? Something like "Also the way library SONAMEs are represented in shlibs files makes it difficult to use them in some unusual corner cases."? Bernhard R. Link -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120324152733.ga20...@client.brlink.eu
Re: Some upcoming dpkg changes, test and feedback welcome
* Raphael Hertzog [110922 13:59]: > We can imagine more use cases in the context of other distributions than > Debian. Ubuntu for example could want to adjust the behaviour when > targetting a source packages for an older release (since they always use > the codename in that field). > > > Currently I can only see possible abuses but no proper uses for it, so > > unless there is something I miss, I'd rather request that variable to > > be removed, as it can only harm. > > What kind of abuses do you see? Anything that does not error out but changes behaviour. In your second example above for example, you get a package that would silently change behaviour if doing a locally modified version. Or imagine someone having the 'bright idea' to have something that behaves differently if that field is 'stable-proposed-updates', so that a following upload (once the package reached testing) of that package targeting a point release would not show differences but the changelog. Then if that package gets in there and someone later wants to do a security upload, the source package from stable will suddenly behave differently, because not the distribution field is different. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110922150745.ga26...@server.brlink.eu
Re: Some upcoming dpkg changes, test and feedback welcome
* Raphael Hertzog [110921 22:52]:
>>> [...] DEB_DISTRIBUTION [...]
> But this is all wishful thinking at this point given that I have no use
> case where some analysis of the distributions returned needs to be
> portable across several derivatives and Debian itself.
Sorry for again joining in late in the distribution, but what is the use
case of this field exactly?
Currently I can only see possible abuses but no proper uses for it, so
unless there is something I miss, I'd rather request that variable to
be removed, as it can only harm.
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110922091432.ga23...@server.brlink.eu
Re: dpkg-buildflags and makefile snippet
* Raphael Hertzog [110801 08:58]: > On Sun, 31 Jul 2011, Bernhard R. Link wrote: > > While I wholeheartly welcome adding such a script, I am surprised why > > it is made so complicated and hard to read. > > > > Is there a reason for dpkg_late_eval? > > Performance. If the variables are not used, there's no subprocess > executed. Is that tiny constant amount worth having files not readable by the majority of people, even of DDs. > And once it has been executed, the value is kept (i.e. no > multiple executions either). := is already doing that. > > And why all the ?= in scripts/mk/architecture.mk? > > Because we need to respect the value in the environment if they are set. > dpkg-builpackage does set them to non-standard values if you pass it the > -a and/or -t option. dpkg-architecture already respects the environment, make does not override values given on the command line. So the only thing this should protect against is if they are not in the environment but set in debian/rules as makefile variables before including this snipped. (Something I see no value in and if someone wants something like that they can just set it after including it). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110801083940.ga28...@pcpool00.mathematik.uni-freiburg.de
Re: dpkg-buildflags and makefile snippet
On Wed, Jul 27, 2011 at 12:55:04AM +0200, Raphael Hertzog wrote:
> Just for reference, in the discussion I mentionned that dpkg would start
> providing a makefile snippet that helps retrieving the correct value of
> all the build flags, you can see it here:
> http://anonscm.debian.org/gitweb/?p=dpkg/dpkg.git;a=commitdiff;h=b858e07bddec28c5b86c39d425a02f08d9bd205a
While I wholeheartly welcome adding such a script, I am surprised why
it is made so complicated and hard to read.
Is there a reason for dpkg_late_eval? And why all the ?= in
scripts/mk/architecture.mk?
Why not simply
CFLAGS := $(shell dpkg-buildflags --get CFLAGS)
and so on in buildflags.mk and
DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
and so on in architecture.mk?
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110731115549.ga21...@pcpool00.mathematik.uni-freiburg.de
Re: [PATCH/RFC] dpkg-shlibdeps: ignore shell scripts
* Raphael Hertzog [100423 07:58]: > > Yes, I wonder the same thing. What would be the harm in making > > dpkg-shlibdeps always ignore files starting with a #! line? > > If we go down that path, then I would have no reason to refuse patches to > ignore images, known document formats, any textual file, etc. This is > useless bloat. Except those things should not appear in a binary directory. So there is still reason to refuse those without refusing script checking. (That's not an argument for or against checking for scripts, just an argument against the argument at hand. I personally would prefer to at least have an option to error out when getting something without symbols) Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100423090502.ga14...@pcpool00.mathematik.uni-freiburg.de
Re: problems with 3.0 format
* Peter Krefting [100330 21:35]: >> Not having that information also means that when you want to look for >> what was changed for some bugfix, one has to look at the whole history >> and collect the initial change and all the adoptions to newer upstream >> versions. > > That's the entire point of having it in a version control system, though, > that you can trace changes. Well, being able to trace changes does not mean that you do not want to be able to see the actual changes. As Debian packages should not be forks, but only modifications that we always hope upstream will accept or that they are at least useable by other people or clear enough someone else can spot problems with it. And having one commit per upstream version with the actual and complete modification for some issue relative to that upstream version makes it in my eyes much easier to trace the changes, than having some changeset no longer applying to the current upstream with conflict resolution being hidden in same merge together with resolution for all the other changes. >> The information about what is changed is burried in the information >> when it was changed. It also means one cannot tell upstream or some >> other project to just cherry-pick a specific commit to get the fix. > > True. But fixes generally apply anyway, until made redundant by upstream, > so this is probably not a big problem in most cases. In my experience that is often the case, but far too often: - patches need to be updated to some upstream code changes - patches change over time and get amended with more complete fixes - patches get replaced by other patches, even partially > git://git.debian.org/users/peterk/lyskom-server.git - > http://git.debian.org/?p=users/peterk/lyskom-server.git;a=shortlog;h=refs/heads/debian > > git://git.debian.org/crashmail/crashmail.git - > http://git.debian.org/?p=crashmail/crashmail.git;a=shortlog;h=refs/heads/debian I think the suitability of such an approach is like the suitability of only having a single .diff.gz in a source package. The most practical point to see what is changed in those trees is comparing the "New upstream release: ..." merges with their upstream side parent, which is about equivalent to looking at the .diff.gz files of the Debian packages generated (once one has one change, one can try to find the commits introducing some change to get some context, but first one has to look what changes there are and try to locate the different changes in there). As in those packages the non-"debian/" changes are so little, looking at the .diff.gz gives enough information, as it is not hard to see what belongs together and what changes there are. Once those collects more than 1 or 2 different modifications that may also be in the same files I do not think that scales very well. (Just as having only a single .diff.gz would not scale that well). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331090045.ga19...@pcpool00.mathematik.uni-freiburg.de
Re: problems with 3.0 format
* Peter Krefting [100328 18:25]: >> Up to know I was rather thinking of designing a new tool >> "vcs-buildpackage" but maybe I simply want to create new source >> formats "3.0 (git2quilt)" or "3.0 (bzr2quilt)" and extend the dpkg-source >> integration in dpkg-buildpackage. > > That only works if you use a rebase workflow in the VCS, not if you use a > merge workflow. Personally, I find merge workflows easier to follow, > since you can track the branch back through history properly. History with rebased branches is indeed the tricky point. I know of two possibilities: - Either rebase and merge that one (possibly with -s ours). The problem with that is that git's format patch (and all the rebase operations) have problems coping with that. - don't publish the patched branch but only tag when released and include in the history of some debian branch. (That is what git-dpm does). (Try to clone git://git.debian.org/users/brlink/xwit.git and take a look at the history. I've tried to import the old history in a way like it would be created when using git-dpm workflow.) I think it is relatively easy to follow such a history. (And pointing someone to the specific tag in git.debian.org's web-view is as useable for someone to look at the actual changes as viewing the patches with patch-tracker.debian.org is). > Unfortunately, such a workflow can't easily be translated back into a set > of patches to apply on top of the current upstream. I think it is a worse problem than only the impossiblity to create the patches. That is only a consequence of the version control system missing information about what the changes are. Not having that information also means that when you want to look for what was changed for some bugfix, one has to look at the whole history and collect the initial change and all the adoptions to newer upstream versions. The information about what is changed is burried in the information when it was changed. It also means one cannot tell upstream or some other project to just cherry-pick a specific commit to get the fix. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100329115521.ga...@pcpool00.mathematik.uni-freiburg.de
Re: problems with 3.0 format
* Raphael Hertzog [100328 11:44]: > On Sat, 27 Mar 2010, Bernhard R. Link wrote: > > I'm guess this discussiong is slowly leaving debian-dpkg@ topic, > > though... > > Definitely not. I plan to integrate VCS knowledge in dpkg-dev at some > point and I like those discussions so that I can make up my mind on what's > best. I don't think that this would be very useful. VCS usage can vary quite a bit and more often then not will not contain any usefull information. (like some branch just always merged with the upstreams has not much information except the diff to the unmodified version). Back to how dpkg-source can help: What I'm missing (don't know if this is a feature request or a request for better documentation) is some option to tell dpkg-source (ideally in a way that is already passed down from dpkg-buildpackage) that in case of a "3.0 (quilt)" package no new patch should be created but if there are changes not yet recorded in debian/patches it should abort with an error. And it would be nice if .gitattributes would be ignored like .gitignore. And if it would not include debian/.git-dpm into the debian.tar.gz by default, too. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100328111059.ga6...@pcpool00.mathematik.uni-freiburg.de
Re: problems with 3.0 format
* Colin Watson [100327 17:00]: > > I think what quilt is missing here, is some reverse-setup: A command > > to create a .pc file from a patched tree and a series of patches. > > Are you suggesting specifically here that this should go in quilt? I > wouldn't be opposed to that; I'd been thinking of dpkg-dev, but either > would work. I've missed that functionality already in quilt before the 3.0 format came, so I personally would suggest to have it in quilt. > > Another way to work around that is not using quilt if you are using > > a vcs, but use the vcs to manage the differences and export that > > information into debian/patches/. > > For git I wrote git-dpm[1] as some way[2] to do this. I guess with bzr > > something similar should be possible. > > I know some people have been looking at this, and I recognise that in > many ways it would be better to regard the patches as exports from a VCS > (indeed, I mentioned this in my blog article). However, for me, I'd > foresee many more warts than the mere management of branches and > extraction of patches from them. For instance, I would want to commit > debian/changelog at the same time as the patch (I don't like > autogenerating debian/changelog; the results tend to be terrible), which > means I'd have to either tolerate lots of conflicts or else put up with > auto-merging tools, which I never really trust very much. I like to have the patch without the debian/ related changes (so upstream or other users can cherry-pick it). In git-dpm workflow: git-dpm checkout-patched apply patch/modify files git commit git-dpm update-patches dch "description" # possible other debian/ changes git commit -a --amend so the commit that has the changed debian/patches (and the virtual branch with the actual changes as parent) also has the debian/changelog changes. > Also there's > the issue of DEP-3 metadata in patch files, which I'd often want to > change along with the commit to their contents. Probably all soluble > but all the tools I've seen are very definitely in their early stages as > yet. I try to just have them in the git commit description. I'm not using them very consistently yet, though. > > When using git, moving the patches to a new upstream is just a rebase > > of a patched branch to a new upstream. That means if the patches are > > stored as commits those commits can be rebased and one has the changes > > and information to create the updated patches from created by the same > > resolution. Perhaps something like that is possible with bzr, too. > > Well, firstly, I strongly disapprove of rebasing published branches, so > I'll mentally s/rebase/merge/g (though either is of course perfectly > possible with bzr). I'd prefer if the commits are usable to be reused by upstream. Rebased stuff usually is, while something merged and merged again is usually nothing upstream will want to pull. My solution against the "rebasing published branches" is thus to not publish it as branch, but only as tag and as part of the history of the debian branch (and of course as temporary branch for the user doing the modification). I'm guess this discussiong is slowly leaving debian-dpkg@ topic, though... Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100327190305.ga2...@pcpool00.mathematik.uni-freiburg.de
Re: problems with 3.0 format
* Benjamin Drung [100326 01:54]: > as requested in the Lintian tag, here comes an email describing some > problems with 3.0 format. I encounter the same problems like Colin > Watson [1]. Quote: > > 1. It's a bit awkward to set things up when checking out from > revision control; I didn't really want to check in the .pc > directory, and the tree checks out in the patched state (as it > should), so I needed some way for developers to get quilt > working easily after a checkout. This is sort of the reverse of > the previous problem, where users had to do something special > after dpkg-source -x, and I consider it less serious so I'm > willing to put up with it. I ended up a rune in debian/rules > that ought to live somewhere more common. I think what quilt is missing here, is some reverse-setup: A command to create a .pc file from a patched tree and a series of patches. Another way to work around that is not using quilt if you are using a vcs, but use the vcs to manage the differences and export that information into debian/patches/. For git I wrote git-dpm[1] as some way[2] to do this. I guess with bzr something similar should be possible. > 2. Although I haven't had to do it yet, I expect that merging new > upstream releases will be a bit harder. bzr will deal with > resolving conflicts in the patched files themselves, and that's > why I use a revision control system after all, but then I'll > have to go and refresh all the patches and will probably end up > doing some of the same conflict resolution a second time. When using git, moving the patches to a new upstream is just a rebase of a patched branch to a new upstream. That means if the patches are stored as commits those commits can be rebased and one has the changes and information to create the updated patches from created by the same resolution. Perhaps something like that is possible with bzr, too. Hochachtungsvoll, Bernhard R. Link [1] http://git-dpm.alioth.debian.org/ [2] The biggest problem with storing the patches as commits is that patches should not describe the history but the changes. While this can be done in git nicely via usage of git rebase -i, git has some problems storing[3] the history of rebased branches in the history of some branch, so git-dpm is mostly some magic to have the patched branch only as temporary git branch but otherwise only as virtual branch contained in the history of some debian branch. [3] well, storing is possible, but only in a way hard to deal with... -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100326105040.ga21...@pcpool00.mathematik.uni-freiburg.de
Re: DEB_BUILD_OPTIONS=parallel=n work not as expected
* Erik Schanze [091206 10:36]: > > /usr/bin/make --jobserver-fds=3,4 -j > > ... > > > > I don't know who changed $(MAKEFLAGS) from "-j3" to "--jobserver-fds=3,4 > > -j" and > > why the number "3" was not used after "-j". > > > > Could anybody please give an explanation? > > Is there something broken or did I miss something? > > >[...] > Because this will end in a build run with unlimited jobs, or did I miss smth.? If make was just passing -j3 down, you could not limit the number of jobs. Because if your top level makefile calls again submakes in - say - src/, doc/ and data/ (at the same time) and src/, doc/ and data/ would have 3 subdirectories, then there were already 9 subsubmakes processed at the same time. if they had been given a -j3, too, each would process 3 files at the same time, causing 27 processes running simultanously. That's why submakes do not get -j3, but instead get told to interact with the parent make, so that all possible submakes together process 3 things at the same time, but still being able to do so in multiple subdirectories (if there are for example subdirectories with only 1 file). Hochachtungsvoll, Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Debian-l10n-devel] Removing long descriptions / english from Packages files
* Nicolas François [090813 10:14]: > > Think like s/md5/sha256/ or so :) > > That should be doable;) > > Note that the probability of a collision (Description are controlled by > trusted people), and the consequences of a collision (a wrong long > description is displayed), do not make me too afraid of using MD5. Actually I think that might even rather be a job for something like crc32, md5 already looks like overhead, and sha256 feels like being longer than the description itself. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Draft spec for new dpkg "triggers" feature
* Ian Jackson <[EMAIL PROTECTED]> [070201 14:00]: > We don't have any triggers yet, so I don't understand how you can say > that they "can become quite a hassle". Bad memories from (mostly looking at others) use of Yast (I don't know where those functionality lives, could also be some levels under it), where whenever something is changed or installed, one has to wait some time for some triggers to run. It might not be that long, and not that often, but if you don't know what is going on (I think on Suse systems I can include myself in that group easily), it gets extremly annoying. > > And allowing packages to just listen for some file or directory feels > > like encouraging half-backed solutions. > > It reduces the amount of stuff that needs to be precisely coordinated > between different packages; explicit triggers need the trigger names > to be coordinated as well as everything else. Well, everything else should need to be coordinated as well. Just setting a trigger name is then the least of the problems. > > > A file trigger is guaranteed to be activated before the file in > > > question is modified by dpkg; on the other hand, a file trigger might > > > be activated even though no file was actually modified. > > > > What does that garantee? That no modification can be missed if dpkg > > is interupted before finishing? > > Yes. > > > What's the advantage in doing so? > > It will avoid situations where the interested package is broken > because (for example) some data it previously registered has > disappeared. How? Would it suffice to garantee it triggered before the package comes from the working to the non-working state or vice versa? This way the trigger might be run unnecessarily when the files it runs on are in a inconsistent state, causing error messages and warnings without need. > Since triggering is idempotent, the concept "too often" seems > irrelevant, really. Well, I strongly disagree. Especially if it encouraged to act the same to all triggers, I need no crystal ball to foresee packages doing a full reconfigure when any directory they are remotely involved in gets any action. > > I'd also prefer a way so that if programs get better they can avoid > > work in the future, if only some updated have to be done depending on > > what changed. Like when only a new menu-provider appears for > > update-menu, there is no reason to recreate all menus, but only the > > one that is new. Or some other program could detect that only some file > > vanished and could just remove all information for that package without > > reparsing and reprocessing all information. > > This can be done using file timestamps. Time stamps means second-guessing. Getting that work portably is not that easy. (Especially as dpkg sets the most visible timestamp to be that from the package for normal files). > > To avoid being something like that impossible by design, having a way > > to specify a trigger happened and the names of the packages (or other > > free-form data given to a explicit trigger call) handed to the trigger > > processor. > > I thought about something like this. But it makes activating a > trigger no longer idempotent (because of this additional data which > needs to be carried about), and it will also be quite cumbersome to > constantly have to record and pass about the ancilliary data. I think the idempotency is not that much of a trouble (if a package cannot guarantee to have it idempotent if only stuff in the specified packages changed, it can just ignore the information). The storage of the information might be a bit more of a hassle. (Especially as it might more easily be more than a command line length than the number of triggers triggered). Hochachtungsvoll, Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Draft spec for new dpkg "triggers" feature
* Ian Jackson <[EMAIL PROTECTED]> [070130 18:26]: > Concepts > > > Each trigger is named, and at any time zero or more packages may be > interested in it. > > We currently envisage three kinds of triggers: > * Explicit triggers. These can be activated by any program >by running dpkg-trigger (at any time, but ideally from a maintainer >script). > * File triggers. These are activated automatically by dpkg >when a matching file is installed, upgraded or removed as part >of a package. They may also be explicitly activated by running >dpkg-trigger. I'm a bit fearfull about those type of triggers. Triggers can be become quite a hassle when they are triggered too general and run when they are not needed. And allowing packages to just listen for some file or directory feels like encouraging half-backed solutions. > File triggers > - > File triggers should not generally be used without mutual consent. > The use of a file trigger, and the name of the trigger used, should be > stated in policy, so that a package which creates a relevant file in a > maintainer script can activate the trigger explictly. I'd almost suggest that official packages should not listen for file triggers at all and always rely on explicit triggers. (If a package adds or modifies a file, it should know that and thus can trigger explicitly, and things like lintian/linda can easily make sure that cases a automatic trigger would help anything have no real chance to exist). > A file trigger is guaranteed to be activated before the file in > question is modified by dpkg; on the other hand, a file trigger might > be activated even though no file was actually modified. What does that garantee? That no modification can be missed if dpkg is interupted before finishing? What's the advantage in doing so? (I could imagine a garantee that a trigger is not activated before the package triggering it is configured properly could be useful, but what is the use for this garantee?) > Package declarations regarding triggers > --- > [...] > activate > > Arranges that any change of the package's state will activate the > specified trigger. The trigger will be activated just before the > package state changes. Isn't that a bit often to trigger? I definitly think there should be some limit, like only if passing the workable/non-workable border. I'd also prefer a way so that if programs get better they can avoid work in the future, if only some updated have to be done depending on what changed. Like when only a new menu-provider appears for update-menu, there is no reason to recreate all menus, but only the one that is new. Or some other program could detect that only some file vanished and could just remove all information for that package without reparsing and reprocessing all information. To avoid being something like that impossible by design, having a way to specify a trigger happened and the names of the packages (or other free-form data given to a explicit trigger call) handed to the trigger processor. Hochachtungsvoll, Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: additions to dpkg-architecture
* Goswin von Brederlow <[EMAIL PROTECTED]> [060629 12:31]: > Baurzhan Ismagulov <[EMAIL PROTECTED]> writes: > > for generic SPARC and running painfully slowly on SPARC v8 systems. > > Rebuilding with v8 enabled helped dramatically (virtually instant > > connection instead of 10+ seconds depending on the CPU model, measured > > with a wrist watch). > > Sparc is the most extrem case that I know of though giving the biggest > speedup for crypto code. This example has come up in the past and I > thought someone would have added an ssh-sparc8 package with optimized > ssh by now. This is one of the cases that are worth it. | You have searched for the contents of libssl0.9.7 in stable, | architecture sparc. Package contains 9 files, displaying files 1 to 9. | | usr/lib/libcrypto.so.0.9.7 | usr/lib/libssl.so.0.9.7 | usr/lib/v8/libcrypto.so.0.9.7 | usr/lib/v8/libssl.so.0.9.7 | usr/lib/v9/libcrypto.so.0.9.7 | usr/lib/v9/libssl.so.0.9.7 | usr/share/doc/libssl0.9.7/changelog.Debian.gz | usr/share/doc/libssl0.9.7/changelog.gz | usr/share/doc/libssl0.9.7/copyright In other words: Problem solved since sarge. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian package installation
* Rajasekaran J. <[EMAIL PROTECTED]> [060329 07:13]:
> i am not looking for Graphical packet manager.when we double click rpm
> package
>
> it is installing same as i need for debian package.
Take a look at /usr/lib/mime/debian-view from the mime-support package.
Every mailcap aware application is already able to install a .deb when
executing it. (Like many do when you double click on them).
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Apt problem
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [050929 12:43]: > Hello, all, > I was trying to do apt-get install gnome, but am getting the following > error: > E: Unmet dependencies. Try 'apt-get -f install' with no packages (or > specify a solution). > > So, I follow the above instructions, and get: > > (Reading database ... 100268 files and directories currently > installed.) > Unpacking initscripts (from .../initscripts_2.86.ds1-1.1_i386.deb) ... > dpkg: error processing > /var/cache/apt/archives/initscripts_2.86.ds1-1.1_i386.deb > (--unpack): > trying to overwrite `/etc/init.d/checkroot.sh', which is also in > package sysvinit > dpkg-deb: subprocess paste killed by signal (Broken pipe) > Errors were encountered while processing: > /var/cache/apt/archives/initscripts_2.86.ds1-1.1_i386.deb > E: Sub-process /usr/bin/dpkg returned an error code (1) > > My first reaction when this happened was to try to reinstall > initscripts, but the same thing has happened ever since, no matter > *what* I may try to do with apt. Can I fix this or do I have to > reinstall the whole system? I'm using Oralux, which is made from Debian > by way of Knoppix. That's some nuisance within apt-get, which poorly copes with errors. Where do you have this initscripts 2.86.ds1-1.1 from? Debian stable (sarge) seems to have 2.86.ds1-1 and testing already 2.86.ds1-2. It looks like this 1.1 version seem to miss the replace to allow upgrading from woody's sysvinit. I'd suggest to try to get a sysvinit version fitting to you system, and install that with dpkg -i. Perhaps you need to also get initscripts 2.86.ds1-1 from woody before that. (Or installing both at once). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /etc/alternatives master list
* Brian Sammon <[EMAIL PROTECTED]> [031117 06:37]: > I'd like to create a /etc/alternatives/x-image-viewer for my favorite image > viewer (its package doesn't create an alternatives entry), but I'm wondering > if other image viewers are using some other /etc/alternatives name. > How do maintainers keep coordinated on this sort of thing? I think image-viewers are preferably handled by the mime database, i.e. registering there and calling it by see(1). Hochachtungsvoll, Bernhard R. Link -- The man who trades freedom for security does not deserve nor will he ever receive either. (Benjamin Franklin) pgpzsoDVApMR8.pgp Description: PGP signature
Bug#200351: dpkg-issue then...
* Adam Heath <[EMAIL PROTECTED]> [030912 17:50]:
> > wrong. The following patch resolves the problem for me:
>
> Please regenerate this patch, using -u, and attach it to the email, instead of
> including it inline.
Hmpf, I guess there has to be something I forget with anything...
diff -r -u dpkg-1.10.10.old/dpkg-deb/main.c dpkg-1.10.10/dpkg-deb/main.c
--- dpkg-1.10.10.old/dpkg-deb/main.c2002-09-01 06:47:03.0 +0200
+++ dpkg-1.10.10/dpkg-deb/main.c2003-09-12 13:48:39.0 +0200
@@ -165,7 +165,12 @@
jmp_buf ejbuf;
setlocale(LC_NUMERIC, "POSIX");
- standard_startup(&ejbuf, argc, &argv, NULL, 0, cmdinfos);
+ if (setjmp(ejbuf)) { /* expect warning about possible clobbering of argv */
+error_unwind(ehflag_bombout); exit(2);
+ }
+ push_error_handler(&ejbuf,print_error_fatal,0);
+
+ standard_startup(argc, &argv, NULL, 0, cmdinfos);
if (!cipaction) badusage(_("need an action option"));
unsetenv("GZIP");
diff -r -u dpkg-1.10.10.old/include/dpkg.h.in dpkg-1.10.10/include/dpkg.h.in
--- dpkg-1.10.10.old/include/dpkg.h.in 2002-09-01 06:47:05.0 +0200
+++ dpkg-1.10.10/include/dpkg.h.in 2003-09-12 13:50:14.0 +0200
@@ -167,7 +167,7 @@
/*** from startup.c ***/
-void standard_startup(jmp_buf *ejbuf, int argc, const char *const **argv,
const char *prog, int loadcfg, const struct cmdinfo cmdinfos[]);
+void standard_startup(int argc, const char *const **argv, const char *prog,
int loadcfg, const struct cmdinfo cmdinfos[]);
void standard_shutdown(int freemem);
/*** from ehandle.c ***/
diff -r -u dpkg-1.10.10.old/lib/startup.c dpkg-1.10.10/lib/startup.c
--- dpkg-1.10.10.old/lib/startup.c 2002-09-01 06:47:05.0 +0200
+++ dpkg-1.10.10/lib/startup.c 2003-09-12 13:44:17.0 +0200
@@ -38,17 +38,12 @@
#include
#include
-void standard_startup(jmp_buf *ejbuf, int argc, const char *const **argv,
const char *prog, int loadcfg, const struct cmdinfo cmdinfos[]) {
+void standard_startup(int argc, const char *const **argv, const char *prog,
int loadcfg, const struct cmdinfo cmdinfos[]) {
setlocale(LC_ALL, "");
bindtextdomain(PACKAGE, LOCALEDIR);
textdomain(PACKAGE);
- if (setjmp(*ejbuf)) { /* expect warning about possible clobbering of argv */
-error_unwind(ehflag_bombout); exit(2);
- }
- push_error_handler(ejbuf,print_error_fatal,0);
-
umask(022); /* Make sure all our status databases are readable. */
if (loadcfg)
diff -r -u dpkg-1.10.10.old/main/main.c dpkg-1.10.10/main/main.c
--- dpkg-1.10.10.old/main/main.c2002-09-01 06:47:05.0 +0200
+++ dpkg-1.10.10/main/main.c2003-09-12 13:45:04.0 +0200
@@ -548,7 +548,12 @@
jmp_buf ejbuf;
static void (*actionfunction)(const char *const *argv);
- standard_startup(&ejbuf, argc, &argv, DPKG, 1, cmdinfos);
+ if (setjmp(ejbuf)) { /* expect warning about possible clobbering of argv */
+error_unwind(ehflag_bombout); exit(2);
+ }
+ push_error_handler(&ejbuf,print_error_fatal,0);
+
+ standard_startup(argc, &argv, DPKG, 1, cmdinfos);
if (!cipaction) badusage(_("need an action option"));
setvbuf(stdout,0,_IONBF,0);
diff -r -u dpkg-1.10.10.old/main/query.c dpkg-1.10.10/main/query.c
--- dpkg-1.10.10.old/main/query.c 2002-09-01 06:47:05.0 +0200
+++ dpkg-1.10.10/main/query.c 2003-09-12 13:47:43.0 +0200
@@ -537,7 +537,12 @@
jmp_buf ejbuf;
static void (*actionfunction)(const char *const *argv);
- standard_startup(&ejbuf, argc, &argv, NULL, 0, cmdinfos);
+ if (setjmp(ejbuf)) { /* expect warning about possible clobbering of argv */
+error_unwind(ehflag_bombout); exit(2);
+ }
+ push_error_handler(&ejbuf,print_error_fatal,0);
+
+ standard_startup(argc, &argv, NULL, 0, cmdinfos);
if (!cipaction) badusage(_("need an action option"));
setvbuf(stdout,0,_IONBF,0);
Only in dpkg-1.10.10: mylog
Only in dpkg-1.10.10: mylog2
diff -r -u dpkg-1.10.10.old/split/main.c dpkg-1.10.10/split/main.c
--- dpkg-1.10.10.old/split/main.c 2002-09-01 06:47:05.0 +0200
+++ dpkg-1.10.10/split/main.c 2003-09-12 13:49:45.0 +0200
@@ -153,7 +153,12 @@
int l;
char *p;
- standard_startup(&ejbuf, argc, &argv, NULL, 0, cmdinfos);
+ if (setjmp(ejbuf)) { /* expect warning about possible clobbering of argv */
+error_unwind(ehflag_bombout); exit(2);
+ }
+ push_error_handler(&ejbuf,print_error_fatal,0);
+
+ standard_startup(argc, &argv, NULL, 0, cmdinfos);
if (!cipaction) badusage(_("need an action option"));
l= strlen(depotdir);
Bug#200351: dpkg-issue then...
* Falk Hueffner <[EMAIL PROTECTED]> [030912 13:52]:
> and longjmp must not jump into a function which has been
> terminated after the call to setjmp (which is likely the cause for the
> crash).
Thanks. I guessed that if dpkg does this so explicitly, it would not be
wrong. The following patch resolves the problem for me:
diff -r dpkg-1.10.10.old/debian/changelog dpkg-1.10.10/debian/changelog
0a1,6
> dpkg (1.10.10-0.1) local; urgency=low
>
> * Fix setjmp bug in standard_startup
>
> -- Bernhard R. Link <[EMAIL PROTECTED]> Fry, 12 Sep 2003 14:09:00 +0200
>
diff -r dpkg-1.10.10.old/dpkg-deb/main.c dpkg-1.10.10/dpkg-deb/main.c
168c168,173
< standard_startup(&ejbuf, argc, &argv, NULL, 0, cmdinfos);
---
> if (setjmp(ejbuf)) { /* expect warning about possible clobbering of argv */
> error_unwind(ehflag_bombout); exit(2);
> }
> push_error_handler(&ejbuf,print_error_fatal,0);
>
> standard_startup(argc, &argv, NULL, 0, cmdinfos);
diff -r dpkg-1.10.10.old/include/dpkg.h.in dpkg-1.10.10/include/dpkg.h.in
170c170
< void standard_startup(jmp_buf *ejbuf, int argc, const char *const **argv,
const char *prog, int loadcfg, const struct cmdinfo cmdinfos[]);
---
> void standard_startup(int argc, const char *const **argv, const char *prog,
> int loadcfg, const struct cmdinfo cmdinfos[]);
diff -r dpkg-1.10.10.old/lib/startup.c dpkg-1.10.10/lib/startup.c
41c41
< void standard_startup(jmp_buf *ejbuf, int argc, const char *const **argv,
const char *prog, int loadcfg, const struct cmdinfo cmdinfos[]) {
---
> void standard_startup(int argc, const char *const **argv, const char *prog,
> int loadcfg, const struct cmdinfo cmdinfos[]) {
47,51d46
< if (setjmp(*ejbuf)) { /* expect warning about possible clobbering of argv */
< error_unwind(ehflag_bombout); exit(2);
< }
< push_error_handler(ejbuf,print_error_fatal,0);
<
diff -r dpkg-1.10.10.old/main/main.c dpkg-1.10.10/main/main.c
551c551,556
< standard_startup(&ejbuf, argc, &argv, DPKG, 1, cmdinfos);
---
> if (setjmp(ejbuf)) { /* expect warning about possible clobbering of argv */
> error_unwind(ehflag_bombout); exit(2);
> }
> push_error_handler(&ejbuf,print_error_fatal,0);
>
> standard_startup(argc, &argv, DPKG, 1, cmdinfos);
diff -r dpkg-1.10.10.old/main/query.c dpkg-1.10.10/main/query.c
540c540,545
< standard_startup(&ejbuf, argc, &argv, NULL, 0, cmdinfos);
---
> if (setjmp(ejbuf)) { /* expect warning about possible clobbering of argv */
> error_unwind(ehflag_bombout); exit(2);
> }
> push_error_handler(&ejbuf,print_error_fatal,0);
>
> standard_startup(argc, &argv, NULL, 0, cmdinfos);
diff -r dpkg-1.10.10.old/split/main.c dpkg-1.10.10/split/main.c
156c156,161
< standard_startup(&ejbuf, argc, &argv, NULL, 0, cmdinfos);
---
> if (setjmp(ejbuf)) { /* expect warning about possible clobbering of argv */
> error_unwind(ehflag_bombout); exit(2);
> }
> push_error_handler(&ejbuf,print_error_fatal,0);
>
> standard_startup(argc, &argv, NULL, 0, cmdinfos);
Bug#200351: set/longjump issue?
I never looked into set/longjmp and am not able to read
mips-assembler, but I guess the following means that
set/longjmp is broken. Branden, could you test the program
on necrotic to verify this might be the cause there, too?
The following is what I think dpkg is doing there without
anything unrelated (A is standard_startup and B is badusage):
---test.c
#include
#include
void A(jmp_buf *j) {
int v;
printf("[A\n");
v = setjmp(*j);
printf("A: setjmp returned %d\n",v);
printf("A]\n");
}
void B(jmp_buf *j) {
printf("[B\n");
longjmp(*j,1);
printf("B]\n");
}
int main() {
jmp_buf j;
printf("[main\n");
A(&j);
printf("...main...\n");
B(&j);
printf("main]\n");
return 0;
}
-
---output of this is-
[main
[A
A: setjmp returned 0
A]
...main...
[B
Segmentation fault
-
An gdb session---
GNU gdb 5.3.90_2003-08-24-cvs-debian
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "mips-linux"...
(gdb) b main
Breakpoint 1 at 0x400a3c: file test.c, line 22.
(gdb) r
Starting program: /home/chroot/dpkg/test
Breakpoint 1, main () at test.c:22
22 printf("[main\n");
(gdb) n
23 A(&j);
(gdb) s
A (j=0x7fff7cf8) at test.c:7
7 printf("[A\n");
(gdb) n
8 v = setjmp(*j);
(gdb) n
9 printf("A: setjmp returned %d\n",v);
(gdb) bt
#0 A (j=0x7fff7cf8) at test.c:9
#1 0x00400a70 in main () at test.c:23
(gdb) p *j
$1 = {{__jmpbuf = {{__pc = 0x4008fc, __sp = 0x7fff7c60, __regs = {4197264,
2147450452, 4197104, 1, 4196888, 2147447412, -4, 2147443240},
__fp = 0x7fff7c60, __gp = 0x2ad09610, __fpc_csr = 4, __fpregs = {
-nan(0xf), -nan(0xf), -nan(0xf),
-nan(0xf), -nan(0xf),
-nan(0xf)}}}, __mask_was_saved = 0, __saved_mask = {
__val = {0, 0, 0, 718312976, 0, 1, 718312976, 716524848, 716524824, 0,
0, 268468272, 0, 4197264, 2147450452, 268468272, 4195888, 716282944,
718312976, 718312976, 0, 268468272, 4197264, 268468272, 4197160,
716313760, 0, 0, 0, 268468272, 716282968, 4197264
(gdb) n
10 printf("A]\n");
(gdb) n
11 }
(gdb) n
main () at test.c:24
24 printf("...main...\n");
(gdb) n
25 B(&j);
(gdb) s
B (j=0x7fff7cf8) at test.c:14
14 printf("[B\n");
(gdb) n
15 longjmp(*j,1);
(gdb) bt
#0 B (j=0x7fff7cf8) at test.c:15
#1 0x00400aac in main () at test.c:25
(gdb) p *j
$2 = {{__jmpbuf = {{__pc = 0x4008fc, __sp = 0x7fff7c60, __regs = {4197264,
2147450452, 4197104, 1, 4196888, 2147447412, -4, 2147443240},
__fp = 0x7fff7c60, __gp = 0x2ad09610, __fpc_csr = 4, __fpregs = {
-nan(0xf), -nan(0xf), -nan(0xf),
-nan(0xf), -nan(0xf),
-nan(0xf)}}}, __mask_was_saved = 0, __saved_mask = {
__val = {0, 0, 0, 718312976, 0, 1, 718312976, 716524848, 716524824, 0,
0, 268468272, 0, 4197264, 2147450452, 268468272, 4195888, 716282944,
718312976, 718312976, 0, 268468272, 4197264, 268468272, 4197160,
716313760, 0, 0, 0, 268468272, 716282968, 4197264
(gdb) s
A (j=0x7fff7cf8) at test.c:9
9 printf("A: setjmp returned %d\n",v);
(gdb) bt
#0 A (j=0x7fff7cf8) at test.c:9
#1 0x00400b90 in __libc_csu_init ()
(gdb) p *j
$3 = {{__jmpbuf = {{__pc = 0x4008fc, __sp = 0x7fff7c60, __regs = {4197264,
2147450452, 4197104, 1, 4196888, 2147447412, -4, 2147443240},
__fp = 0x7fff7c60, __gp = 0x2ad09610, __fpc_csr = 4, __fpregs = {
-nan(0xf), -nan(0xf), -nan(0xf),
-nan(0xf), -nan(0xf),
-nan(0xf)}}}, __mask_was_saved = 0, __saved_mask = {
__val = {0, 0, 0, 718312976, 0, 1, 718312976, 716524848, 716524824, 0,
0, 268468272, 0, 4197264, 2147450452, 268468272, 4195888, 716282944,
718312976, 718312976, 0, 268468272, 4197264, 268468272, 4197160,
716313760, 0, 0, 0, 268468272, 716282968, 4197264
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
A (j=0x7fff7cf8) at test.c:9
9 printf("A: setjmp returned %d\n",v);
(gdb) bt
#0 A (j=0x7fff7cf8) at test.c:9
#1 0x00400b90 in __libc_csu_init ()
(gdb) c
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The
Bug#200351: This bug is also triggered by no command-line options at all.
This bug is also triggered by just calling "dpkg" with no options
at all. (Though correct options work like expected, when there are
no user errors.)
Following a gdb session on my mips machine:
GNU gdb 5.3.90_2003-08-24-cvs-debian
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "mips-linux"...
(gdb) b main
Breakpoint 1 at 0x4054ac: file /home/chroot/dpkg/dpkg-1.10.10/main/main.c, line
551.
(gdb) r
Starting program: /home/chroot/dpkg/dpkg-1.10.10/build/main/dpkg
Breakpoint 1, main (argc=1, argv=0x0)
at /home/chroot/dpkg/dpkg-1.10.10/main/main.c:551
551 standard_startup(&ejbuf, argc, &argv, DPKG, 1, cmdinfos);
(gdb) n
547 int main(int argc, const char *const *argv) {
(gdb) n
551 standard_startup(&ejbuf, argc, &argv, DPKG, 1, cmdinfos);
(gdb) n
547 int main(int argc, const char *const *argv) {
(gdb) n
551 standard_startup(&ejbuf, argc, &argv, DPKG, 1, cmdinfos);
(gdb) n
552 if (!cipaction) badusage(_("need an action option"));
(gdb) n
551 standard_startup(&ejbuf, argc, &argv, DPKG, 1, cmdinfos);
(gdb) n
552 if (!cipaction) badusage(_("need an action option"));
(gdb) n
0x004055cc 563 return reportbroken_retexitstatus();
(gdb) s
badusage (fmt=0x7fff7890 "")
at /home/chroot/dpkg/dpkg-1.10.10/lib/ehandle.c:259
259 void badusage(const char *fmt, ...) {
(gdb) n
265 snprintf(errmsgbuf,sizeof(errmsgbuf),"%s\n\n%s", buf,
gettext(printforhelp));
(gdb) n
263 vsnprintf(buf,sizeof(buf), fmt,al);
(gdb) n
265 snprintf(errmsgbuf,sizeof(errmsgbuf),"%s\n\n%s", buf,
gettext(printforhelp));
(gdb) n
267 longjmp(*econtext->jbufp,1);
(gdb) n
266 errmsg= errmsgbuf;
(gdb) n
267 longjmp(*econtext->jbufp,1);
(gdb) p econtext
$1 = (struct errorcontext * volatile) 0x1000d320
(gdb) p *econtext
$2 = {next = 0x0, jbufp = 0x7fff7cc0, cleanups = 0x0,
printerror = 0x423320 , contextstring = 0x0}
(gdb) bt
#0 badusage (fmt=0x7fff7cc0 "")
at /home/chroot/dpkg/dpkg-1.10.10/lib/ehandle.c:267
#1 0x00405608 in main (argc=2147450048, argv=0x7fff7e18)
at /home/chroot/dpkg/dpkg-1.10.10/main/main.c:563
(gdb) s
Program received signal SIGBUS, Bus error.
0x0042aebc in standard_startup (ejbuf=0x7fff7cc0, argc=1, argv=0x42f650,
prog=0x2 , loadcfg=1, cmdinfos=0x10e0)
at /home/chroot/dpkg/dpkg-1.10.10/lib/startup.c:47
47if (setjmp(*ejbuf)) { /* expect warning about possible clobbering of
argv */
(gdb) bt
#0 0x0042aebc in standard_startup (ejbuf=0x7fff7cc0, argc=1, argv=0x42f650,
prog=0x2 , loadcfg=1, cmdinfos=0x10e0)
at /home/chroot/dpkg/dpkg-1.10.10/lib/startup.c:47
GDB is unable to find the start of the function at 0x2ad09570
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
This problem is most likely caused by an invalid program counter or
stack pointer.
However, if you think GDB should simply search farther back
from 0x2ad09570 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
(gdb) c
Continuing.
Program terminated with signal SIGBUS, Bus error.
The program no longer exists.
(gdb) q
Hochachtungsvoll,
Bernhard R. Link
P.S: I'm also experiencing a bus error or segmentation fault with
things like:
echo "foo wrongword" | dpkg --set-selections
while things like
echo "foo install" | dpkg --set-selections
works, but only within an chroot and not in the hosting system.
This may or not may be an different error, but this bug here makes
debuging the other one quite difficult.
