Bug#710769: dpkg-checkbuilddeps: unsatisfyable Multi-Arch: none cross build dependencies not listed as missing

[Johannes Schauer]

Package: dpkg-dev
Version: 1.16.10
Severity: normal
User: crossbu...@debian.org
Usertags: cross

There is an inconsistency between `dpkg-checkbuilddeps -a${arch}` and
`apt-get build-dep -a${arch}` behavior. Here we test on the source
package bash which Build-Depends on autoconf which is Multi-Arch: none.

$ dpkg-checkbuilddeps -aarmel
dpkg-checkbuilddeps: Unmet build dependencies: libncurses5-dev sharutils time


$ apt-get build-dep -aarmel bash
Reading package lists... Done
Building dependency tree   
Reading state information... Done
E: Build-Depends dependency for bash cannot be satisfied because the package 
autoconf cannot be found


The package autoconf is not listed as an unmet build dependency by
dpkg-checkbuilddeps. Apt-get lists it as being unsatisfiable. It is my
understanding that the apt behavior is the correct one as autoconf is
Multi-Arch: none and can therefore not be used to satisfy the cross
build dependencies of bash. Therefore, autoconf should also appear in
the list of unmet build dependencies as given by dpkg-checkbuilddeps.

Thanks, josch


-- 
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#710769: dpkg-checkbuilddeps: unsatisfyable Multi-Arch: none cross build dependencies not listed as missing

[Johannes Schauer]

Hi Guillem,

Quoting Guillem Jover (2013-06-02 16:45:04)
 autoconf is arch:all, so I don't see any reason why it should not be able to
 satisfy the Build-Depends.

In practice, autoconf does indeed satisfy this Build-Depends of bash and in
general should also be marked M-A:foreign. Another bug about that has to be
filed for that.

 The reason this does not apply to Depends, is to try to avoid switching
 architectures in dependency chains, as in «pkg-a:arch-a → pkg-b:all →
 pkg-c:arch-c».

Yes, but I can't find this different treatment of Depends and Build-Depends in
the multiarch spec.

 But arguably this might not have been a very good idea after all, given that
 I think that kind of dependency chain is IMO legitimate for arch:all
 packages, OTOH one reason I didn't have much of a problem with that is
 because we can always relax that restriction at any later point (and we
 probably should).

The question whether arch:all packages should implicitly be marked m-a:foreign
came up a number of times so far. For example bug#666772 for apt.

Right now, dpkg and apt behave differently so at least one has to be wrong.

cheers, josch


--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749044: dpkg: please do not produce a trailing space after the fieldname of multiline fields

[Johannes Schauer]

Package: dpkg
Version: 1.17.9
Severity: wishlist
Tags: patch

Hi,

dpkg produces an unnecessary whitespace after the fieldname of multiline
fields. Not having this extra whitespace would save 16kb of an
uncompressed Sources file.

Here is a simple patch and updated testcase:

diff --git a/scripts/Dpkg/Control/HashCore.pm b/scripts/Dpkg/Control/HashCore.pm
index 6d6f1c5..155c8ce 100644
--- a/scripts/Dpkg/Control/HashCore.pm
+++ b/scripts/Dpkg/Control/HashCore.pm
@@ -358,12 +358,18 @@ sub output {
$value .= \n $_;
}
}
+# do not print a trailing space if value starts with a newline
+if ($value =~ /^\n/) {
+$value = $key:$value\n;
+} else {
+$value = $key: $value\n;
+}
# Print it out
 if ($fh) {
-   print { $fh } $key: $value\n
+   print { $fh } $value
or syserr(_g('write error on control data'));
 }
-   $str .= $key: $value\n if defined wantarray;
+   $str .= $value if defined wantarray;
}
 }
 return $str;
diff --git a/scripts/t/Dpkg_Changelog.t b/scripts/t/Dpkg_Changelog.t
index 43bccea..d6372a2 100644
--- a/scripts/t/Dpkg_Changelog.t
+++ b/scripts/t/Dpkg_Changelog.t
@@ -173,7 +173,7 @@ Urgency: high
 Maintainer: Frank Lichtenheld fr...@lichtenheld.de
 Date: Sun, 13 Jan 2008 15:49:19 +0100
 Closes: 100 111 222
-Changes: 
+Changes:
  fields (2.0-0etch1) stable; urgency=low
  .
* Upload to stable (Closes: #111, #222)
@@ -214,7 +214,7 @@ Urgency: medium
 Maintainer: Frank Lichtenheld dj...@debian.org
 Date: Sun, 12 Jan 2008 15:49:19 +0100
 Closes: 111 222
-Changes: 
+Changes:
  fields (2.0-1) unstable  frozen; urgency=medium
  .
[ Frank Lichtenheld ]
@@ -244,7 +244,7 @@ Distribution: unstable
 Urgency: low
 Maintainer: Frank Lichtenheld fr...@lichtenheld.de
 Date: Sun, 11 Jan 2008 15:49:19 +0100
-Changes: 
+Changes:
  fields (2.0~b1-1) unstable; urgency=low,xc-userfield=foobar
  .
* Beta
@@ -257,7 +257,7 @@ Urgency: high
 Maintainer: Frank Lichtenheld dj...@debian.org
 Date: Sun, 10 Jan 2008 15:49:19 +0100
 Closes: 100
-Changes: 
+Changes:
  fields (1.0) experimental; urgency=high,xb-userfield2=foobar
  .
* First upload (Closes: #100)


-- 
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#749044: dpkg: please do not produce a trailing space after the fieldname of multiline fields

[Johannes Schauer]

Hi,

Quoting Guillem Jover (2014-05-23 15:57:08)
 Here's what I'm going to include in the next push. It also covers a case that
 was not handled in the supplied patch. :)

oh super! Thanks for handling this that fast :D

cheers, josch


--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#47214: parseversion still leaking memory

[Johannes Schauer]

Hi,

whether the reason is the same I can't say but parseversion is still leaking
memory somehow:

#define LIBDPKG_VOLATILE_API 1
#include dpkg/dpkg.h
#include dpkg/version.h

int main()
{
struct dpkg_version ver;
int i;
for (i = 0; i  1; ++i) {
parseversion(ver, 1.0.0, NULL);
}
return 0;
}

$ gcc leak.c -ldpkg  /usr/bin/time -v ./a.out 21 | grep Maximum
Maximum resident set size (kbytes): 1569096

Just as the original submitter I wanted to use parseversion to parse *LOTS* of
versions. My plans where thwarted when I discovered the memory leak.

cheers, josch


--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758191: dpkg-genchanges: should not warn if binary packages are not built due to build profiles

[Johannes Schauer]

Package: dpkg-dev
Version: 1.17.12
Severity: normal

Hi,

currently, when building a source package which does not build some of
its binary package due to build profiles as deduced from the
Build-Profiles field in the respective binary package stanza in
debian/control, then the following warning is issued:

dpkg-genchanges: warning: package builds-only-stage1 in control file but not in 
files list

Instead, dpkg-genchanges should take the activated build profiles into account
and decide from them whether or not a binary package should be in the files
list or not.

cheers, josch


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dpkg-dev depends on:
ii  base-files7.3
ii  binutils  2.24.51.20140617-1
ii  bzip2 1.0.6-5
ii  libdpkg-perl  1.17.12
ii  make  4.0-8
ii  patch 2.7.1-5
ii  xz-utils  5.1.1alpha+20120614-2

Versions of packages dpkg-dev recommends:
ii  build-essential  11.6
ii  fakeroot 1.18.4-2
ii  gcc [c-compiler] 4:4.9.0-4
ii  gcc-4.8 [c-compiler] 4.8.3-4
ii  gcc-4.9 [c-compiler] 4.9.0-7
ii  gnupg1.4.18-2
ii  gnupg2   2.0.25-1
ii  gpgv 1.4.18-2
ii  libalgorithm-merge-perl  0.08-2

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2014.04.25

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758191: propagating the value of the build-profiles field to Packages and Sources files

[Johannes Schauer]

Hi,

Quoting Johannes Schauer (2014-04-21 16:31:13)
 Quoting Guillem Jover (2014-04-21 16:04:17)
  Sorry for not mentioning before, I had already locally a very similar patch,
  which will be included in 1.17.7 to be uploaded in few minutes, but using a
  key=value1,value2 format instead, so that the new stuff can appear in any
  order and it's more clear what's it about. With «arch» and «profile» keys,
  both being in principle optional, although «arch» will always get generated,
  and «profile» will only be generated if the package contains a 
  Build-Profiles
  field; but I don't think defaulting to “all” would be future-proof, if a key
  with an empty value would really be desired we could always emit it, because
  that should be safe and unambiguous.
  
  I'm also using join and split instead of s/// because otherwise a
  comma might appear at the end with stuff like foo  bar quux   .
  
  I've added support for Build-Profiles too, but only to be accepted in
  the binary package stanzas on debian/control.
 
 thanks a lot! Sounds awesome :)
 
 Just in case you also already fixed that, I was currently preparing a patch
 which fixes the following two problems:
 
 dpkg-source: warning: unknown information field 'Build-Profiles' in 
 input data in package's section of control info file
 
 Where the fix seems to have been to simply allow the Build-Profiles field in
 CTRL_INFO_PKG and:
 
 dpkg-genchanges: warning: package builds-only-stage1 in control file 
 but not in files list
 
 Where the fix is a bit more involved because it requires checking if the
 currently active profiles lead to the binary package being built or not
 depending on the value of the Build-Profiles field. To that end I added a new
 function debprofile_is (as an equivalent to debarch_is) to
 scripts/Dpkg/BuildProfiles.pm and use it accordingly in
 scripts/dpkg-genchanges.pl. But there might be a more elegant solution because
 debprofile_is duplicates the logic of profile_is_concerned in
 scripts/Dpkg/Deps.pm with the difference that there is no profile. prefix to
 take care of.

I have not managed to solve this issue in a satisfactory manner and am too
embarrassed to show what I came up with to people who actually know how to
write perl :D

Thus I created bug#758191 to keep track of this issue.

cheers, josch


--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#760158: dpkg: please implement the new build profiles syntax

[Johannes Schauer]

Package: dpkg
Version: 1.17.13
Severity: wishlist
Tags: patch
Control: block 744246 by -1

Hi,

please find attached a patch which implements the recent changes to the
build profile spec [1] as agreed during the bootstrap sprint in paris.

The patch contains a summary of the changes.

Thanks!

cheers, josch

[1] https://wiki.debian.org/BuildProfileSpec
From f24a1286ae17fc1b2884255089dc3f3553d526e0 Mon Sep 17 00:00:00 2001
From: josch j.scha...@email.de
Date: Tue, 19 Aug 2014 07:57:03 +0200
Subject: [PATCH] update restriction formula syntax

 - the restriction list parsing now reflects the changes at
   https://wiki.debian.org/BuildProfileSpec which were agreed upon
   in the bootstrap sprint 2014 in Paris
 - restriction lists are now restriction formulas
 - restriction formulas are given in disjunctive normal form expression
foo bar baz blub
 - removal of the prefix/namespace mechanic
 - since there can be more than one  block, the regex in parse_string
   in scripts/Dpkg/Deps.pm is now greedy
 - properly handle the absence of packages in DEBIAN/control depending
   on build profiles - Closes: #758191
 - construct the profiles entry of the Packages-List field by
   converting the bar baz blub syntax into bar,baz+blub
 - include a compatibility function with the old way to write the
   Build-Profiles field in binary packages which can be removed once
   all affected source packages moved to the new syntax
 - adjusted testcases
---
 man/deb-src-control.5 | 17 +--
 man/dpkg-buildpackage.1   | 14 ++--
 man/dpkg-checkbuilddeps.1 |  7 +++---
 scripts/Dpkg/BuildProfiles.pm | 35 --
 scripts/Dpkg/Deps.pm  | 46 ++-
 scripts/dpkg-genchanges.pl| 15 +++--
 scripts/dpkg-source.pl| 19 ++--
 scripts/t/Dpkg_Deps.t | 50 +--
 8 files changed, 123 insertions(+), 80 deletions(-)

diff --git a/man/deb-src-control.5 b/man/deb-src-control.5
index 407172a..7a17d1a 100644
--- a/man/deb-src-control.5
+++ b/man/deb-src-control.5
@@ -187,8 +187,8 @@ of packages separated by vertical bar (or pipe) symbols, |. The
 groups are separated by commas. Commas are to be read as AND, and pipes
 as OR, with pipes binding more tightly. Each package name is
 optionally followed by a version number specification in parentheses, an
-architecture specification in square brackets, and a profile specification
-in angle brackets.
+architecture specification in square brackets, and a restriction formula
+consisting of one or more lists of profile names in angle brackets.
 
 The syntax of the
 .BR Build\-Conflicts ,
@@ -198,8 +198,9 @@ and
 fields is a list of comma-separated package names, where the comma is read
 as an AND. Specifying alternative packages using a pipe is not supported.
 Each package name is optionally followed by a version number specification in
-parentheses, an architecture specification in square brackets, and a profile
-specification in angle brackets.
+parentheses, an architecture specification in square brackets, and a
+restriction formula consisting of one or more lists of profile names in angle
+brackets.
 
 A version number may start with a , in which case any later version
 will match, and may specify or omit the Debian packaging revision (separated
@@ -211,9 +212,11 @@ An architecture specification consists of one or more architecture names,
 separated by whitespace. Exclamation marks may be prepended to each of the
 names, meaning NOT.
 
-A profile specification consists of one or more profile names, prefixed
-with the \fBprofile.\fP namespace, separated by whitespace. Exclamation
-marks may be prepended to each of the names, meaning NOT.
+A restriction formula consists of one or more restriction lists, separated by
+whitespace. Each restriction list is enclosed in angle brackets. Items in the
+restriction list are build profile names, separated by whitespace and can be
+prefixed with an exclamation mark, meaning NOT. A restriction formula
+represents a disjunctive normal form expression.
 
 Note that dependencies on packages in the
 .B build\-essential
diff --git a/man/dpkg-buildpackage.1 b/man/dpkg-buildpackage.1
index b96c25f..631ebdb 100644
--- a/man/dpkg-buildpackage.1
+++ b/man/dpkg-buildpackage.1
@@ -150,11 +150,11 @@ of \-a or as a complement to override the default GNU system type
 of the target Debian architecture.
 .TP
 .BR \-P \fIprofile\fP[ , ...]
-Specify the profile(s) we build, as a comma-separated list, without the
-\fBprofile.\fP namespace prefix. The default behavior is to build for
-no specific profile. Also adds them (as a space separated list) to the
-\fBDEB_BUILD_PROFILES\fP environment variable which allows, for example,
-\fBdebian/rules\fP files to use this information for conditional builds.
+Specify the profile(s) we build, as a comma-separated list. The default
+behavior is to build for no specific 

Bug#760158: dpkg: please implement the new build profiles syntax

[Johannes Schauer]

Hi,

Quoting Guillem Jover (2014-09-02 01:07:08)
 Thanks for the patch! I'm preemtively merging this locally, and will be doing
 some testing. At a first glance I see some very minor issues that I'll be
 fixing (because it's going to be faster that way :) and posting a diff for
 your peruse. I think I might have comments on some of the design decisions
 made that AFAIR we left hanging in Paris, but nothing dramatic. :)

Thanks!

I also have a minor addendum that I found while I implemented the same logic in
OCaml for dose3:

The not (A xor B) in evaluate_restriction_formula could be better done by
doing (A == B). I don't know how well that works in perl because of its types
but assuming A and B are booleans, this expresses the same and looks better
than xor.

cheers, josch


--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764236: dpkg-checkbuilddeps: satisfyable Multi-Arch: foreign build dependency is listed as missing

[Johannes Schauer]

Package: dpkg-dev
Version: 1.17.15
Severity: normal

Hi,

I'm running amd64 and have symlinks:i386 installed. Now I'm trying to
build glibc which build depends on symlinks. Since symlinks is
M-A:foreign it should satisfy the build dependency of glibc built on
amd64. Nonetheless, dpkg-checkbuilddeps will throw an error.

Additionally, I cannot reproduce the same problem after having installed
symlinks:amd64 and then again symlinks:i386. After having done that,
dpkg-checkbuilddeps behaves properly even with only symlinks:i386
installed.

This might be related to #710769 but that bug affected M-A:no packages
which were wrongly classified as M-A: foreign while this bug is about a
M-A:foreign package being treated as if it was M-A:no.

cheers, josch

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dpkg-dev depends on:
ii  base-files7.3
ii  binutils  2.24.51.20140918-1
ii  bzip2 1.0.6-5
ii  libdpkg-perl  1.17.15
ii  make  4.0-8
ii  patch 2.7.1-5
ii  xz-utils  5.1.1alpha+20120614-2

Versions of packages dpkg-dev recommends:
ii  build-essential  11.6
ii  clang-3.3 [c-compiler]   1:3.3-16
ii  fakeroot 1.18.4-2
ii  gcc [c-compiler] 4:4.9.0-4
ii  gcc-4.8 [c-compiler] 4.8.3-11
ii  gcc-4.9 [c-compiler] 4.9.1-16
ii  gnupg1.4.18-2
ii  gnupg2   2.0.25-1
ii  gpgv 1.4.18-2
ii  libalgorithm-merge-perl  0.08-2

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2014.08.31

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768842: dpkg: please document the dependency:arch syntax for architecture qualifiers

[Johannes Schauer]

Package: dpkg
Severity: normal

Hi,

dpkg allows dependencies like packagename:any, packagename:native and
packagname:${debarch} where ${debarch} is any Debian architecture. But
this does not seem to be documented. It should at least show up in the
man page of deb-control(5).

Thanks!

cheers, josch


-- 
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#768842: dpkg: please document the dependency:arch syntax for architecture qualifiers

[Johannes Schauer]

Hi!

Quoting Guillem Jover (2014-11-11 01:14:29)
 I've done the change now, just changing the order of the architecture
 qualifier values list.
[...]
 I've also updated the Multi-Arch field description. New patch attached.

I think this version is good now. Thanks!

cheers, josch


--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#770301: dpkg: fails to install second arch of Multi-Arch:same packages with Provides/Conflicts/Replaces:virtualpackage

[Johannes Schauer]

Hi,

On Thu, 20 Nov 2014 17:00:06 +0100 Andreas Beckmann a...@debian.org wrote:
 On 2014-11-20 16:51, Guillem Jover wrote:
  This is expected behavior in dpkg. Conflics/Breaks/Replaces get an
  implicit any arch qualifier, so those make the dependency
  unsatisfiable due to the Provides.

thanks for making me aware of this. It turns out that dose3 does this wrong as
well.

  So if there's no other issue besides this, I'm just going to be closing
  this report.
 
 Should this rather be reassigned to apt/aptitude to not resolve these
 packages as co-installable at the first place?

Sorry, I already filed this bug with apt without considering to reassign this
one. The new bug is #770345

Thanks!

cheers, josch


--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#616614: /usr/bin/dpkg-deb: Please support --fsys-tarfile - to mean stdin

[Johannes Schauer]

Control: tag -1 patch

Hi,

please find attached a simple patch which enables this functionality by
assigning STDIN_FILENO to the file descriptor instead of trying to open it if
the filename is equal to -.

The tricky part is, that the archive filename is not an argument to the
--ctrl-tarfile or --fsys-tarfile argument as it could be interpreted from the
dpkg-deb man page. Instead, the archive filename is a positional argument and
since there can be no positional argument starting with a minus character, it
must be given after a -- like this:

dpkg-deb --ctrl-tarfile -- -

I added a note about this into the man page.

Thanks!

cheers, josch
diff --git a/dpkg-deb/extract.c b/dpkg-deb/extract.c
index 2c92940..00683f9 100644
--- a/dpkg-deb/extract.c
+++ b/dpkg-deb/extract.c
@@ -124,7 +124,10 @@ extracthalf(const char *debar, const char *dir,
   bool header_done;
   enum compressor_type decompressor = COMPRESSOR_TYPE_GZIP;
 
-  arfd = open(debar, O_RDONLY);
+  if (strcmp(debar, -) == 0)
+arfd = STDIN_FILENO;
+  else
+arfd = open(debar, O_RDONLY);
   if (arfd  0)
 ohshite(_(failed to read archive `%.255s'), debar);
   if (fstat(arfd, stab))
diff --git a/man/dpkg-deb.1 b/man/dpkg-deb.1
index c5038ec..9fa2aea 100644
--- a/man/dpkg-deb.1
+++ b/man/dpkg-deb.1
@@ -43,6 +43,12 @@ with whatever options you want to pass to
 will spot that you wanted
 .B dpkg\-deb
 and run it for you.
+.PP
+.B dpkg\-deb
+can also read the archive from standard input if the archive name is given as
+single minus character. Note, that this argument must be interpreted as a
+positional argument and must thus be specified after a separating \-\-
+(without the quotes).
 .
 .SH COMMANDS
 .TP

Bug#774129: should dpkg-buildpackage set the cross build profile automatically?

[Johannes Schauer]

Hi,

Quoting Wookey (2014-12-29 13:14:20)
 I have a feeling that dpkg-buildpackage should do 'policy' level build things
 so if the above became policy then dpkg-buildpackage should probably make
 sure it gets done. Perhaps the biggest disadvantage is indeed that if even
 the low-level build tool does this automatically then how do you turn it off?
 Is there is fact no good reason to ever want to?

on the topic of who should automatically set a certain build profile and how to
deactivate it (if desired for whatever reason), my message to d-devel might be
of interest:

http://lists.debian.org/20141212114840.15300.27739@hoothoot

It explores the idea of allowing an architecture or distribution dependent set
of profiles which are activated by default to remove the architecture lists
currently attached to many dependencies as well as to minimize the diff between
packaging of different vendors.

I don't want to conflate these two discussions, but maybe it is worth keeping
this possible future use case of build profiles in mind when discussing who
should activate the cross profile in particular and how it could be
deactivated if desired.

So just my 2 cents.

cheers, josch


--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#765662: dpkg: please consider adding support for the :target qualifier in build dependencies

[Johannes Schauer]

Hi,

(second try sending this email. I just discovered that the one I sent in
october 2014 does not show up in the bts)

Quoting Guillem Jover (2014-10-20 17:21:00)
  diff --git a/scripts/dpkg-checkbuilddeps.pl b/scripts/dpkg-checkbuilddeps.pl
  index 3feba3a..47accc9 100755
  --- a/scripts/dpkg-checkbuilddeps.pl
  +++ b/scripts/dpkg-checkbuilddeps.pl
  @@ -52,6 +52,8 @@ sub usage {
 -c build-conf  use given string for build conflicts instead of
retrieving them from control file
 -a archassume given host architecture
  +  --target-arch=arch
  + assume given host architecture
 
 This should be target not host.

ah yes, a copy-paste error.

 Also, wouldn't dpkg-buildpackage need to pass this option to
 dpkg-checkbuilddeps?

well, I wondered the same thing about the host architecture option which is
also not explicitly passed to dpkg-checkbuilddeps by dpkg-buildpackage. When I
tested whether my patch works it did, so I guess dpkg-checkbuilddeps gets the
host- (and with this patch also target-) architecture through the environment
set by the dpkg-architecture call earlier in dpkg-buildpackage?

 The rest looks good (as long as it behaves correctly that is :). But it would
 be nice to add some unit tests to Dpkg_Deps.t, I've just enabled very minimal
 ones for :native.

I fixed the s/host/target/ error and added a test case.

cheers, josch
From 77aff816f9aa894844b9a4bdc9959177467c2971 Mon Sep 17 00:00:00 2001
From: josch j.scha...@email.de
Date: Fri, 17 Oct 2014 08:39:30 +0200
Subject: [PATCH] =?UTF-8?q?scripts:=20Accept=20=E2=80=9C:target=E2=80=9D?=
 =?UTF-8?q?=20arch-qualified=20Build-Dependencies?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 debian/changelog   |  6 +-
 scripts/Dpkg/Arch.pm   | 19 +++
 scripts/Dpkg/Deps.pm   | 27 ---
 scripts/dpkg-checkbuilddeps.pl | 10 +++---
 scripts/t/Dpkg_Deps.t  |  5 -
 5 files changed, 59 insertions(+), 8 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index bf93b1f..833d319 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,10 @@
 dpkg (1.17.20) UNRELEASED; urgency=low
 
-  * 
+  [ Johannes Schauer ]
+  * dpkg-checkbuilddeps:
+- Add the --target-arch option to specify the target architecture for
+  building compilers
+- Accept “:target” arch-qualified Build-Dependencies.
 
  -- Guillem Jover guil...@debian.org  Mon, 20 Oct 2014 16:06:38 +0200
 
diff --git a/scripts/Dpkg/Arch.pm b/scripts/Dpkg/Arch.pm
index f561b66..e5bc67a 100644
--- a/scripts/Dpkg/Arch.pm
+++ b/scripts/Dpkg/Arch.pm
@@ -23,6 +23,7 @@ our $VERSION = '0.01';
 use Exporter qw(import);
 our @EXPORT_OK = qw(get_raw_build_arch get_raw_host_arch
 get_build_arch get_host_arch get_gcc_host_gnu_type
+get_target_arch
 get_valid_arches debarch_eq debarch_is debarch_is_wildcard
 debarch_to_cpuattrs
 debarch_to_gnutriplet gnutriplet_to_debarch
@@ -50,6 +51,7 @@ my %debarch_to_debtriplet;
 my $build_arch;
 my $host_arch;
 my $gcc_host_gnu_type;
+my $target_arch;
 
 sub get_raw_build_arch()
 {
@@ -120,6 +122,23 @@ my %debarch_to_debtriplet;
 {
 	return Dpkg::BuildEnv::get('DEB_HOST_ARCH') || get_raw_host_arch();
 }
+
+sub get_raw_target_arch()
+{
+	return $target_arch if defined $target_arch;
+
+	if (!defined($target_arch)) {
+	# Fall back to building a compiler for the host arch.
+	$host_arch = get_raw_host_arch();
+	}
+
+	return $target_arch;
+}
+
+sub get_target_arch()
+{
+	return Dpkg::BuildEnv::get('DEB_TARGET_ARCH') || get_raw_target_arch();
+}
 }
 
 sub get_valid_arches()
diff --git a/scripts/Dpkg/Deps.pm b/scripts/Dpkg/Deps.pm
index 5e9728b..0aa186a 100644
--- a/scripts/Dpkg/Deps.pm
+++ b/scripts/Dpkg/Deps.pm
@@ -49,10 +49,10 @@ All the deps_* functions are exported by default.
 use strict;
 use warnings;
 
-our $VERSION = '1.05';
+our $VERSION = '1.06';
 
 use Dpkg::Version;
-use Dpkg::Arch qw(get_host_arch get_build_arch);
+use Dpkg::Arch qw(get_host_arch get_build_arch get_target_arch);
 use Dpkg::BuildProfiles qw(get_build_profiles);
 use Dpkg::ErrorHandling;
 use Dpkg::Gettext;
@@ -190,6 +190,11 @@ Dpkg::Arch::get_host_arch() to identify the proper architecture.
 Define the build architecture. By default it uses
 Dpkg::Arch::get_build_arch() to identify the proper architecture.
 
+=item target_arch (defaults to the current architecture)
+
+Define the target architecture. By default it uses
+Dpkg::Arch::get_target_arch() to identify the proper architecture.
+
 =item reduce_arch (defaults to 0)
 
 If set to 1, ignore dependencies that do not concern the current host
@@ -243,6 +248,7 @@ sub deps_parse {
 $options{reduce_arch} //= 0;
 $options{host_arch} //= get_host_arch();
 $options{build_arch

Bug#797879: dpkg: please add support for extracting the debian packaging directory only from a source package

[Johannes Schauer]

Package: dpkg
Version: 1.18.2
Severity: wishlist

Hi,

it would be great if one could access Debian packaging information from
source packages of all formats in a unified way. My main motivation is
sbuild which could then just extract debian/changelog from a source
package to check in which chroot to build the package without having
first to extract the whole source package (an operation which might take
considerable time and disk space for large packages).

Attached you find a partly working proposal for how such a functionality
could look like.

It introduces the new --debian-tarfile option to dpkg-source which will
work similarly to `dpkg-deb --ctrl-tarfile` in that it would write a
tarball representation of the Debian packaging directory to standard
output independent of the source package format.

With the attached patch this already nearly works for the trivial case
(format 2.0 and format 3.0 (quilt)). It does not *fully* work because
dpkg info messages are *also* printed to standard output. Hence, the
resulting combined output on standard output is not a proper tar file as
it has dpkg-source messages in the beginning (but removing it in an
editor will recover a working tarball).

Maybe dpkg info and warning messages could be written to standard error
instead?

In ./scripts/dpkg-source.pl I found that the new option could share some
code with the --extract option, so I did.

In scripts/Dpkg/Source/Package/V2.pm there also seems to be lots of
opportunity for sharing the sanity checks of the do_extract method with
the new do_debian_tarfile method. If the --debian-tarfile option should
do the same checks as the --extract option (it probably should) then I
could move these sanity checks into a third function that would then be
used by do_extract as well as by do_debian_tarfile.

Now some thoughts about the interface I chose. Here is an excerpt from
man/dpkg-source.1:

> .TP
> .RI "\fB\-\-debian-tarfile\fP \fIfilename\fP.dsc [\fIpath\fP]"
> Extracts the \fB./debian\fP packaging directory of a given source package and
> sends it to standard output in
> .B tar
> format. The \fB./debian\fP directory component will be part of all files in 
> the
> output. Together with
> .BR tar (1)
> this can be used to extract a particular packaging file from the source 
> package
> without unpacking the whole source package first.
> For source formats >= 2.0, this action never requires the upstream source.
> For source format 1.0, this action always requires the upstream source.

1. Since the output of --debian-tarfile always contains the content of
   the ./debian directory one might think that it would make sense to
   strip off the ./debian directory prefix and have the content of the
   ./debian directory in the root of the created tarball. I decided
   against this for two reasons:

- the *.debian.tar.gz file of source formats >= 2.0 also contains
  the debian directory, so I think one would expect the same layout
  of the tarball produced by --debian-tarfile

- it is easier to strip off a leading directory with tar than to add
  one if one so desires

2. For source format 1.0, the upstream tarball is *always* required.
   Even if no hunks in the diff.gz patch an existing file, the upstream
   tarball might still contain a file ./debian/foo but we can only know
   this if we have the upstream tarball as well. Without the upstream
   tarball, the output of this option would otherwise be unreliable.

3. I thought about the option of an optional wildcard path so that by
   selecting only a subset of files in the ./debian directory, the
   upstream tarball would only be required if the requested file is
   patching an existing one.  But this also fails for the same reason as
   the last point: the wildcard path might match a file in the upstream
   tarball and we can only check for this if the upstream tarball is
   present.

4. If an option were added that is not a wildcard but a precise path,
   then it would be possible to not require the upstream tarball if that
   path in the diff is not patching an existing file. The resulting
   created tarball would then only carry a single file in it (which also
   looks strange).  I thought this option to be very limited and since
   source format 1.0 packages are in the minority and since I currently
   do not have a good use case where the upstream tarball would not be
   present as well, I decided to not make this kind of feature part of
   the initial implementation of this proposal. Should the use for it
   arise, it can always be added later without breaking the interface.

What do you think?

Thanks!

cheers, josch
>From 5f12e7d29e7741d67443379db0ea50307abc00bd Mon Sep 17 00:00:00 2001
From: Johannes 'josch' Schauer 
Date: Thu, 3 Sep 2015 12:15:38 +0200
Subject: [PATCH] proposal for dpkg-source --debian-tarfile

---
 man/dpkg-source.1| 13 ++
 scripts/Dpkg/Source/Package.pm   | 33 

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Johannes Schauer]

Hi,

Quoting Jérémy Bobbio (2016-02-04 12:23:05)
> We have to educate them about .buildinfo file and what the various fields
> mean. We have to aim at field names that are as unambigious as possible to
> avoid laying traps on users.
> 
> For the particular case of “Installed-Transitive-Build-Depends”, it's easy
> enough to explain “these are the name and version of all packages which made
> building these binary packages possible”. Math geeks can get a more formal
> definition.

since we probably never want to record the explicitly non-transitive build
dependencies in the .buildinfo (because those are already recorded elsewhere),
adding "transitive" to the name is probably not necessary. On IRC I agreed with
Holger that using your original proposal and calling it Installed-Build-Depends
should be enough. I think even an uneducated reader would quickly figure out
that this field is not listing the direct but also the indirect (transitive)
depends.

Thanks and sorry for bikeshedding!

cheers, josch


signature.asc
Description: signature

Bug#138409: [Reproducible-builds] Bug#138409: Bug#138409: Bug#138409: dpkg-dev: please add support for .buildinfo files

[Johannes Schauer]

Hi,

Quoting Guillem Jover (2016-02-04 09:44:13)
> On Sun, 2016-01-31 at 14:43:08 +0100, Jérémy Bobbio wrote:
> > and “Installed-Build-Depends” for the list of packages?
> 
> I asked for more suggestions on #debian-dpkg, and Johannes Schauer
> suggested Transitive-Build-Depends, which is something I had in mind
> too (that or «Recursive-»), but kind of softly discarded in trying to
> have a consistently namespaced «Build-» field name. :) Some of the
> reasons Johannes put forward are that this name is better because it
> clearly describes what's the exact purpose of the field, and gives
> no room for misinterpretation. And if we had to change the algorithm
> we could just use a new name. All of which I concur with.

maybe we can merge Lunar's original suggestion Installed-Build-Depends (a name
which is missing the transitive/recursive-ness) with the new suggestion and
make it:

Installed-Transitive-Build-Depends

This way it would not be confused with the *actual* transitive build depends
which would also include non-installed ones or even non-installable ones
because parts of the transitive build depends set might conflict with each
other.

One could also argue that the recorded build dependencies being the installed
as well as transitive ones is quite implicit and thus neither needs to be
mentioned as part of the field.

just my 2 cents

cheers, josch


signature.asc
Description: signature

Bug#818618: dpkg-genchanges: Please exclude packages disabled in unstaged builds

[Johannes Schauer]

Hi,

On Fri, 18 Mar 2016 20:11:19 +0100 Samuel Thibault  wrote:
> A solution would be that dpkg-genchanges is added a -P parameter, and by
> default (unstaged) not include staged-only binary packages in Binary.
> 
> [...]
> 
> We then had to pass NEW due to this addition, because the .changes
> file had it in the Binary: field.  And then we had to pass NEW again
> in the latest upload, for the same reason: apparently between the two
> uploads some cleaning process in ftp-master had dropped the knowledge
> of the package, probably because it's not actually uploaded in the
> archive. Perhaps ftp-master should be more cautious about this, but I'd
> say dpkg-genchanges should just not even mention this package, what do
> you think?

Policy §5.6.19 [1] says the following about the Binary field:

| When it appears in the .dsc file, it lists binary packages which a source
| package can produce, separated by commas[43]. The source package does not
| necessarily produce all of these binary packages for every architecture. The
| source control file doesn't contain details of which architectures are
| appropriate for which of the binary packages.
|
| When it appears in a .changes file, it lists the names of the binary packages
| being uploaded, separated by whitespace (not commas).

I think the above can easily be made compliant with the concept of build
profiles. In a .dsc file, the Binary field will list all binary packages the
source package can possible produce irrespective of architecture (as above) and
irrespective of build profiles (analogues to architectures).

When it appears in a .changes file, the meaning of the Binary field is a
different one and means "I'm hereby uploading these binary packages". So I
think it's reasonable to let this field reflect that a package built without
any build profiles active will also not upload any binary packages specific to
a certain build profile.

I thus think it's reasonable for dpkg-genchanges to only include the binary
packages in the Binary field of the .changes file which were actually produced
depending on the currently active profiles.

Thanks!

cheers, josch

[1] https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Binary


signature.asc
Description: signature

Bug#854438: dpkg: please allow Architecture:all packages to satisfy :native build dependencies

[Johannes Schauer]

Source: dpkg
Severity: wishlist

Hi,

I want to make the case that it makes sense to let Architecture:all
packages satisfy :native build dependencies. We talked about this on IRC
but having a bug lets us not forget about all the arguments for either
side. Here are some reasons:

1. It is pointed out in multiple sources that Architecture:all packages
   are treated as of the native architecture. With the current
   behaviour, this is a lie. Instead one would always have to say:
   "Architecture:all packages are treated as of the native architecture
   expect that...". By removing this special casing we end up with less
   exceptions and thus less surprises which I'd argue is a good thing.

2. The MultiarchCross spec [1] never forbids that Architecture:all
   packages are able to satisfy :native build dependencies. In fact it
   says:

  ":native" is appended to a build-dep to signify that it should be
  installed for the build (i.e 'native') architecture rather than
  the host architecture.

   The ambiguity here is whether when it talks about "build" and "host"
   architectures above, it means explicit architectures or also the
   implicit architecture that Architecture:all packages provide. From
   the MultiarchSpec [2] we read:

  Architecture: all packages will, at least initially, be treated as
  equivalent to packages of the native architecture for all
  dependency resolution

   What I want to show here is not that the multiarch spec mandates that
   Architecture:all packages should satisfy :native build dependencies
   (I can see the ambiguity in the texts above) but that making
   Architecture:all packages satisfy :native dependencies does not
   violate the spec.

3. Without allowing :native on Architecture:all packages, the affected
   packages have to be converted to Architecture:any/Multi-Arch:same if
   they cannot be marked as Multi-Arch:foreign.

4. dose3 and apt already allow Architecture:all packages to satisfy
   :native build dependencies. To verify the claim, clone this git
   repository:

  https://gitlab.mister-muffin.de/josch/deb-m-a-dep-check.git

   and test the appropriate dependency situation like this:

  $ ./check.sh source none any all none no depends pkgb:native
  #A  AA   A   AA  A   A
  #|  ||   |   ||  |   |
  #|  ||   |   ||  |   +-- dependency on 
pkgb:native
  #|  ||   |   ||  +-- dependency not conflict 
relationship
  #|  ||   |   |+-- multiarch value of pkgb
  #|  ||   |   +-- multiarch value of pkga (none 
because it's a source package)
  #|  ||   +-- architecture of pkgb
  #|  |+-- architecture of pkga
  #|  +-- what pkgb provides (none because it provides 
nothing)
  #+-- type of pkga (source because it's a source package with 
build-depends)

   the output will be:

  source none any all none no depends pkgb:native 0 0 1

   the last three numbers indicate that dose3 finds it satisfiable, apt
   finds it satisfiable and dpkg finds it unsatisfiable (in that order).
   Thus, if we decide that Architecture:all packages should satisfy
   :native build dependencies, then only dpkg would have to change.


I'm looking forward to any arguments against this change. Guillem
pointed out that the arguments against :native being satisfied by
M-A:foreign [3] would apply here. But I do not see how this would be a
non-sensical relationship because for a package being Architecture:all
says nothing about whether their interface is architecture independent
or not. The field only says that the package has the same content across
all architectures and that the implicit architecture of the package
depends on the native architecture it is installed on.

Thanks!

cheers, josch


[1] https://wiki.ubuntu.com/MultiarchCross
[2] 
https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages
[3] 
https://wiki.debian.org/Multiarch/MissingRationale#Why_do_M-A:foreign_packages_not_satisfy_:native_qualified_dependencies_in_build-dependencies.3F

Bug#849944: dpkg-genbuildinfo: Can't use an undefined value as an ARRAY reference

[Johannes Schauer]

Hi,

On Mon, 2 Jan 2017 14:53:07 +0100 Botond Botyanszki 
 wrote:
> Some recent changes in dpkg-dev are causing a regression building a deb
> package.  The error I get is as follows:
> 
> dpkg-deb: building package 'x' in '../x.deb'.
>  dpkg-genbuildinfo --build=binary
> Can't use an undefined value as an ARRAY reference at 
> /usr/bin/dpkg-genbuildinfo line 212.
> dpkg-buildpackage: error: dpkg-genbuildinfo --build=binary gave error exit 
> status 255
> 
> The package builds fine on wheezy and jessie, only stretch is affected.  I
> see that dpkg-genbuildinfo is new code which was not available before.

based on guillem's testcase, I reduced the problem to the following:

Build-Depends: genbuildinfo-archqual-bug:i386

Package: genbuildinfo-archqual-bug
Version: 1.equivs-dummy
Depends: genbuildinfo-archqual-bug-virtual
Architecture: i386

Package: genbuildinfo-archqual-bug-provider
Version: 1.equivs-dummy
Provides: genbuildinfo-archqual-bug-virtual
Architecture: i386

I build the latter two packages via equivs.

My native architecture is amd64. The bug is *not* triggered if the packages are
amd64 or if the source package directly depends on the virtual one.

cheers, josch


signature.asc
Description: signature

Bug#836211: dpkg: Cannot upgrade some packages on overlayfs: Invalid cross-device link

[Johannes Schauer]

Hi,

On Wed, 31 Aug 2016 12:16:10 -0300 Felipe Sateler  wrote:
> overlayfs does not support renaming directories when the directories
> live in the lower filesystem:
> 
>  * Directory renames only allowed on "pure upper" (already created on
>  * upper filesystem, never copied up).  Directories which are on lower or
>  * are merged may not be renamed.  For these -EXDEV is returned and
>  * userspace has to deal with it.  This means, when copying up a
>  * directory we can rely on it and ancestors being stable.
> 
> https://github.com/torvalds/linux/blob/v4.8-rc2/fs/overlayfs/copy_up.c#L318-L322
> 
> Unfortunately this means that dpkg fails at least in the case where a
> directory is converted into a file: apt 1.3~rc2 moves
> /usr/share/bug/apt/script to /usr/share/bug/apt . This causes dpkg to
> fail when running in an overlayfs with the following error:
> 
> # dpkg -i /var/cache/apt/archives/apt_1.3~rc3_amd64.deb 
> (Reading database ... 11401 files and directories currently installed.)
> Preparing to unpack .../archives/apt_1.3~rc3_amd64.deb ...
> Unpacking apt (1.3~rc3) over (1.3~rc2) ...
> dpkg: error processing archive
> /var/cache/apt/archives/apt_1.3~rc3_amd64.deb (--install):
>  unable to move aside './usr/share/bug/apt' to install new version: Invalid 
> cross-device link
> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> Processing triggers for libc-bin (2.23-5) ...
> Errors were encountered while processing:
>  /var/cache/apt/archives/apt_1.3~rc3_amd64.deb
> 
> I don't know what the correct workaround should be.
> 
> This can break pre-build upgrades in sbuild when the schroot is of
> overlayfs type.

thanks for the analysis!

I just stumbled across the exact same problem with sbuild in a directory type
overlayfs schroot. My workaround: destroy the chroot (you can now use
sbuild-destroychroot) and then recreate it with sbuild-createchroot. :(

cheers, josch


signature.asc
Description: signature

Bug#818618: dpkg-genchanges: Please exclude packages disabled in unstaged builds

[Johannes Schauer]

Hi,

Quoting Guillem Jover (2016-03-29 00:39:01)
> On Fri, 2016-03-18 at 23:05:26 +0100, Johannes Schauer wrote:
> > I thus think it's reasonable for dpkg-genchanges to only include the binary
> > packages in the Binary field of the .changes file which were actually
> > produced depending on the currently active profiles.
> 
> While that's all true, it unfortunately does not match reality. The
> Binary field in the .changes file has always listed all packages
> regardless of restrictions, including architectures ones.
> 
> So the bug report seems reasonable, but I hesitate to do the change as
> it might break things expecting the field to list more packages than it
> should. I'll bring it up on d-d to canvas possible problems.

I just made three uploads of src:botch to unstable:

 1. An upload of source and Arch:all but the Binary field only listing the
Arch:all package botch-doc

 2. A source-only upload but the Binary field being empty

 3. A source-only upload without the Binary field

It seems that the first two instances resulted in successful uploads as one can
see here:

 1. https://tracker.debian.org/news/799443

 2. https://tracker.debian.org/news/799448

The third one resulted in:

Subject: botch_0.18-6_source.changes REJECTED

botch_0.18-6_source.changes: misses mandatory field Binary

Thus, I do not think that following policy and only putting package names of
packages that are actually produced into the Binary field of the .changes file
should pose any problem. Just take care to not remove the Binary field but
leave it empty if no binary packages are being uploaded.

This finding is also backed up by the dak source code which seems to only check
if the Binary field does *not* list some of the packages that are being
uploaded. See the class BinaryCheck in daklib/checks.py.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#818618: dpkg-genchanges: Please exclude packages disabled in unstaged builds

[Johannes Schauer]

Hi,

Quoting Samuel Thibault (2016-09-22 13:39:06)
> Johannes Schauer, on Thu 22 Sep 2016 13:35:23 +0200, wrote:
> > Thus, I do not think that following policy and only putting package names of
> > packages that are actually produced into the Binary field of the .changes 
> > file
> > should pose any problem.
> 
> AIUI it does problem with packages built on some archs and not others:
> say I have a packages foo which produces only the foo binary package on
> amd64, but on arm it also produces a foo-arm package. When I make my
> initial upload, ftp master will be notified about the foo binary package
> only. When the arm build gets uploaded, the foo-arm package gets in the
> way.
> 
> That's why I was proposing to still include all potential packages, just
> not the staged packages which don't appear in the unstaged build, and are
> thus never to reach ftpmaster.

okay, then indeed, the first step should be to just include all packages that
would build on any arch with no build profile active.

At least we now know that doing so should not break anything, so we can go
ahead and put such a change in dpkg-genchanges. This at least will fix this
particular problem.

For a check whether a new upload adds any packages that should go to NEW, the
existing Package-List field should be considered instead of the Binaries field.
As we see through this bug, the Binaries field is not expressive enough.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#860932: dpkg-shlibdeps should throw an error when generating unsatisfiable dependencies

[Johannes Schauer]

Package: dpkg
Version: 1.18.23
Severity: wishlist

Hi,

I recently hacked on a series of packages when I noticed that
dpkg-shlibdeps emitted the following dependency for my new packaging of
src:linphone:

libbellesip0 (>= 1.6.1), libbellesip0 (<< 1.6.0)

The reason for that was probably that the source package libbellesip0
came from had debian/libbellesip0.symbols file which enforced the
"libbellesip0 (<< 1.6.0)" version restriction while at the same time the
symbols indicated that "libbellesip0 (>= 1.6.1)" was needed. From
debian/libbellesip0.symbols:

libbellesip.so.0 libbellesip0 #MINVER#, libbellesip0 (<< 1.6.0)
[...]
belle_sip_body_handler_begin_recv_transfer@Base 1.6.1
belle_sip_body_handler_begin_send_transfer@Base 1.6.1
[...]

I think there are several places here that could emit some sort of error
message. One is when building src:linphone, dpkg-shlibdeps could
probably check whether the final dependency string it puts into the
substitution variable is satisfiable at all and emit a warning or throw
an error if that's not the case.

Maybe another thing that could be done would be to warn if a *.symbols
file is seen with such a dependency restriction as showcased above. But
I don't know if it's possible to do this reliable or if there are cases
where this will lead to false positives.

Thanks!

cheers, josch

Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it

[Johannes Schauer]

Quoting Holger Levsen (2018-06-09 22:12:33)
> As it sounds, I now believe this script would better live in src:devscripts
> and as such I would like to reassign #774415 to devscripts - or do you see
> any issue with that?

I see no issues with that from my side.


signature.asc
Description: signature

Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it

[Johannes Schauer]

Hi,

Quoting Guillem Jover (2018-06-08 04:30:45)
> Having reread the blocking bug, and the specific message where josch
> says this one is a blocker (https://bugs.debian.org/774415#44), I
> think this is actually an artificial blocker!
>
> [...]
>
> I say it's an artificial blocker, because it is based on the problem
> faced while implementing the srebuild script to use the current
> snapshot.d.o API. And I think that's your actual blocker. Fixing that
> API would also mean you can use it right away independently of what's
> already installed on the system and might be useful for other users
> too. I think the fix would imply adding an API entry point based on
> the name-version-arch tuple.

yes, that would also solve the problem.

I unblocked the bug, because it's not a hard blocker but just an inconvenience.
The bigger blocker of #774415 is, that the script needs somebody who feels
responsible for it and who is willing to maintain it. I only wrote it but I
have no intention of being its maintainer.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it

[Johannes Schauer]

Hi Holger,

Quoting Holger Levsen (2018-06-08 17:47:47)
> as I'm not an sbuild user (yet) myself, I was hesistant to try this
> myself, so I'm confused now: does it work as it is now? (or does it need
> changes to snapshot.d.o?)

yes, it does work as it is now.

Just supply the script with a buildinfo file to see it in action.

It does not require superuser privileges.

The script will query snapshot.debian.org to retrieve the right snapshot
timestamp that contains all the package versions specified in the buildinfo
file.

At the end of execution the script will print how to either reproduce the
buildinfo manually via dpkg-buildpackage or how to run sbuild such that it does
it for you.

People who know how to use pbuilder could easily add a section that outputs how
to run pbuilder to do the same.

Naturally, instead of just printing how to use sbuild or pbuilder, the script
could also be made actually run either.

The main two limitations of the script are:

 1. it will fail if there is not a single snapshot that contains all the right
package versions

 2. it will instruct sbuild/pbuilder to use the last stable release as the base
which might not allow upgrading to the right package versions

Both issues can be fixed by manually downloading exactly the required binary
package set and creating a completely new chroot with exactly the required
packages. But I didn't get around to doing that yet.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#914515: dpkg: please provide an interface to bootstrap dpkg from zero

[Johannes Schauer]

Hi Guillem,

Quoting Guillem Jover (2019-03-15 05:22:32)
> On Sat, 2018-11-24 at 10:24:09 +0100, Johannes 'josch' Schauer wrote:
> > lintian recently tagged mmdebstrap with uses-dpkg-database-directly because
> > mmdebstrap contains the string "/var/lib/dpkg" in several places. Instead
> > of overwriting the lintian tag in mmdebstrap, dpkg could also gain an
> > interface which avoids mmdebstrap having to do anything with /var/lib/dpkg
> > inside the chroot. Specifically, what mmdebstrap does is the following:
> > 
> >  - create /var/lib/dpkg, /var/lib/dpkg/triggers, /var/lib/dpkg/info,
> >/var/lib/dpkg/alternatives and /var/lib/dpkg/updates because dpkg
> >throws an error if these directories are not present
> Right, will handle those.
> 
> >  - an empty /var/lib/dpkg/status because dpkg refuses to work without
> >the file being present
> I've fixed this one now in a local next/bootstrap branch which I'll push out
> tomorrow-

Cool! But I'll only follow up on this in mmdebstrap once we release Buster. :)

Another file that I found is required is /var/lib/dpkg/available. If this file
does not exist (it can even be empty) then package removals will fail.

> >  - adds architectures to /var/lib/dpkg/arch because $(dpkg
> >--add-architecture) doesn't work without any packages inside the
> >chroot
> This sould already work when passing --root= or --admindir=, it should even
> work w/o being root. :)

How then are the foreign architectures communicated to dpkg if not via
/var/lib/dpkg/arch?

> >  - cleans up leftover /var/lib/dpkg/lock-frontend and /var/lib/dpkg/lock
> As mentioned on IRC, this should not be necessary, these are range-locks, and
> they work not based on their presence, but whether they process has acquired
> locks within them.

Agreed. mmdebstrap already does not remove them anymore.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#902856: Bug#884428: sbuild fails to include orig tarball in _source.changes

[Johannes Schauer]

Hi,

Quoting tony mancill (2019-08-06 15:49:06)
> After reviewing #902856 and the recent thread, it doesn't feel like a
> fix on the dpkg side is in sight, but perhaps I'm just being
> pessimistic.  This behavior (ignoring -sa and -v$version) has been
> driving me crazy, so thank you to Pierre-Elliot for contributing a
> patch.
> 
> In my opinion, the options to dpkg-buildpackage are stable enough to
> warrant accepting the patch as a work-around until dpkg has been
> changed.  After all, sbuild doesn't have to support every possible use
> case.  Here we are talking about some primary use cases.  
> 
> In the meantime, could we bump the severity of this bug to
> important?  Or at least update the manpage to document the limitations
> of --force-orig-source and --dpkg-source-opts and --debbuildopts?

I guess we should just apply the temporary (famous last word) patch to sbuild
to close the issue for now.

> By the way, one of the suggestions in that thread is to use
> "dpkg-buildpackage -S" - but that requires that build-deps are installed,
> which is one of the key reasons I am using a chroot in the first place.

You don't need Build-Depends installed for creating a source package. Use:

$ dpkg-source -b .

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#902856: Bug#884428: sbuild fails to include orig tarball in _source.changes

[Johannes Schauer]

Hi Guillem,

Quoting Mathias Behrle (2019-07-23 17:18:08)
> > Indeed, it's a fragile patch, and it's probably a better idea to have a
> > clean and more durable fix. :)
> I just ran into this issue with [1].
> 
> Applying the patch from Pierre-Elliot worked for me and saved me a lot of work
> otherwise needed for workarounds.
> 
> I understand the intention to produce a more sustainable solution with 
> #902856.
> Unfortunately the resonance to that wishlist bug is zero for one year now.
> 
> With source-only uploads now being mandatory for bullseye I want to ask to
> reconsider the inclusion of the patch. It can be replaced as soon as
> there is a result on #902856, but until then can can be of high value for
> maintainers needing this feature.
> 
> [1] https://lists.debian.org/debian-devel/2019/07/msg00463.html

what are your thoughts about #902856?

I would like to avoid having to implement a workaround if the proper solution
from the dpkg side is in sight.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#989602: dpkg-deb overwrites symlinks with directories

[Johannes Schauer Marin Rodrigues]

On Tue, 08 Jun 2021 14:08:46 +0200 Marc Haber  
wrote:
> dpkg-deb -x package.deb happily overwrites symlinks on the filesystems
> with directories. I don't know whether this is desired behavior.
> 
> tl;dr:
> For some reason, a system of mine ended up without
> /sbin/start-stop-daemon. Not knowing about dpkg --force-bad-path, I was
> unable to use dpkg to repair dpkg because dpkg refuses work if there is
> no /sbin/start-stop-daemon.
> 
> dpkg-deb -x /var/cache/apt/archives/dpkg*.deb / happily replaced the
> /sbin => /usr/sbin with an /sbin directory containing only
> /sbin/start-stop-daemon.
> 
> Wouldn't it be nicer to have dpkg follow symlinks before creating
> directories in the times of usrmerge?
> 
> Severity: minor because dpkg --force-bad-path --install dpkg*.deb works.

you can also use:

dpkg-deb --fsys-tarfile dpkg*.deb | tar -C / --keep-directory-symlink --extract 
--file -

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1011191: dpkg: let buildinfo record whether host architecture binaries can be executed when cross-compiling

[Johannes Schauer Marin Rodrigues]

Package: dpkg
Version: 1.21.7
Severity: wishlist
Tags: patch
X-Debbugs-Cc: jo...@debian.org

Hi,

when cross compiling, one property of the build system that can
influence the contents of the generate binary packages is whether or not
the host architecture can be executed. While some platforms can natively
execute others (like amd64 can execute i386), other combinations are
more surprising. When installing the qemu-user-static package on a
system with binfmt-support, then foreign architecture binaries for all
architectures qemu supports will suddenly become executable. This is
especially tricky because this will also transparently affect chroot
builds with sbuild and neither schroot nor unshare isolation can prevent
the emulation from happening. The only ways to stop automatic emulation
are uninstalling qemu-user-static on the outside of the build chroot,
writing 0 to /proc/sys/fs/binfmt_misc/qemu-$arch or running the build
with QEMU_VERSION=1 (unreliable). Since transparent foreign architecture
emulation is easily present on a developer's machine and thus
influencing the build (even when done inside a chroot) it would be
useful to record whether or not foreign architecture binaries can be
executed in the buildinfo file.

I attached a proof-of-concept patch that does exactly that. Since we
cannot rely on arch-test being installed in the build environment, this
approach cross compiles a small true.c executable for the host
architecture. This should always work because gcc is build-essential.
The binary outputs a small string instead of just relying on the exit
code to guard against QEMU_VERSION=1 "disabling" of emulation. The field
'Can-Execute-Host-Architecture is only added when cross-compiling, i.e
when host and build architectures mismatch.

Thanks!

cheers, josch
>From 62179358b57d09fc8c6bb7a59deb128c67cbe522 Mon Sep 17 00:00:00 2001
From: Johannes Schauer Marin Rodrigues 
Date: Wed, 18 May 2022 07:11:39 +0200
Subject: [PATCH] dpkg-genbuildinfo: when cross-compiling add
 Can-Execute-Host-Architecture field

---
 scripts/dpkg-genbuildinfo.pl | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/scripts/dpkg-genbuildinfo.pl b/scripts/dpkg-genbuildinfo.pl
index e05fce048..a296a7314 100755
--- a/scripts/dpkg-genbuildinfo.pl
+++ b/scripts/dpkg-genbuildinfo.pl
@@ -28,13 +28,14 @@ use warnings;
 use List::Util qw(any);
 use Cwd;
 use File::Basename;
+use File::Temp qw(tmpnam);
 use POSIX qw(:fcntl_h :locale_h strftime);
 
 use Dpkg ();
 use Dpkg::Gettext;
 use Dpkg::Checksums;
 use Dpkg::ErrorHandling;
-use Dpkg::Arch qw(get_build_arch get_host_arch debarch_eq);
+use Dpkg::Arch qw(get_build_arch get_host_arch debarch_eq 
debarch_to_gnutriplet);
 use Dpkg::Build::Types;
 use Dpkg::Build::Info qw(get_build_env_allowed);
 use Dpkg::BuildOptions;
@@ -46,6 +47,8 @@ use Dpkg::Control;
 use Dpkg::Changelog::Parse;
 use Dpkg::Deps;
 use Dpkg::Dist::Files;
+use Dpkg::Exit qw(push_exit_handler);
+use Dpkg::IPC;
 use Dpkg::Lock;
 use Dpkg::Version;
 use Dpkg::Vendor qw(get_current_vendor run_vendor_hook);
@@ -455,6 +458,33 @@ $fields->{'Installed-Build-Depends'} = 
collect_installed_builddeps($control);
 
 $fields->{'Environment'} = "\n" . cleansed_environment();
 
+if (get_host_arch() ne $fields->{'Build-Architecture'}) {
+# if we are cross-compiling, record whether it was possible to execute the
+# host architecture by cross-compiling and executing a small host-arch
+# binary
+
+my $tmpname = tmpnam();
+push_exit_handler(sub { unlink($tmpname) });
+my ($stdout, $stderr) = ('', '');
+my $testprog = 'int main(){write(1,"ok",2);return 0;}';
+spawn(exec => [ debarch_to_gnutriplet(get_host_arch()) . '-gcc', '-x', 
'c', '-o', $tmpname, '-' ],
+   wait_child => 1, nocheck => 1,
+   to_string => \$stdout,
+   error_to_string => \$stderr,
+   from_string => \$testprog);
+if ($?) {
+   print { *STDOUT } $stdout;
+   print { *STDERR } $stderr;
+   subprocerr("gcc -x c -");
+}
+spawn(exec => [ $tmpname ], error_to_file => '/dev/null', 'to_string' => 
\$stdout, wait_child => 1, nocheck => 1);
+if ($? == 0 && $stdout eq "ok") {
+   $fields->{'Can-Execute-Host-Architecture'} = "true";
+} else {
+   $fields->{'Can-Execute-Host-Architecture'} = "false";
+}
+}
+
 # Generate the buildinfo filename.
 if ($stdout) {
 # Nothing to do.
-- 
2.35.1

Bug#1011191: dpkg: let buildinfo record whether host architecture binaries can be executed when cross-compiling

[Johannes Schauer Marin Rodrigues]

Hi,

let me put the two relevant lists back into the CC because the members of those
lists can probably give better input than I.

Quoting Guillem Jover (2022-05-28 19:09:10)
> On Wed, 2022-05-18 at 07:26:02 +0200, Johannes Schauer Marin Rodrigues wrote:
> > Package: dpkg
> > Version: 1.21.7
> > Severity: wishlist
> > Tags: patch
> > X-Debbugs-Cc: jo...@debian.org
> 
> > when cross compiling, one property of the build system that can
> > influence the contents of the generate binary packages is whether or not
> > the host architecture can be executed. While some platforms can natively
> > execute others (like amd64 can execute i386), other combinations are
> > more surprising. When installing the qemu-user-static package on a
> > system with binfmt-support, then foreign architecture binaries for all
> > architectures qemu supports will suddenly become executable. This is
> > especially tricky because this will also transparently affect chroot
> > builds with sbuild and neither schroot nor unshare isolation can prevent
> > the emulation from happening. The only ways to stop automatic emulation
> > are uninstalling qemu-user-static on the outside of the build chroot,
> > writing 0 to /proc/sys/fs/binfmt_misc/qemu-$arch or running the build
> > with QEMU_VERSION=1 (unreliable). Since transparent foreign architecture
> > emulation is easily present on a developer's machine and thus
> > influencing the build (even when done inside a chroot) it would be
> > useful to record whether or not foreign architecture binaries can be
> > executed in the buildinfo file.
> 
> Hmm right. To me it feels more like a taint flag though. The
> compilation and execution of the host program feels a bit meh, but
> there's certainly no other way to fetch that information otherwise.
> 
> > I attached a proof-of-concept patch that does exactly that. Since we
> > cannot rely on arch-test being installed in the build environment, this
> > approach cross compiles a small true.c executable for the host
> > architecture. This should always work because gcc is build-essential.
> > The binary outputs a small string instead of just relying on the exit
> > code to guard against QEMU_VERSION=1 "disabling" of emulation. The field
> > 'Can-Execute-Host-Architecture is only added when cross-compiling, i.e
> > when host and build architectures mismatch.
> 
> I'm attaching the slightly revised version with few fixes/changes.

Thanks!

> > >From 62179358b57d09fc8c6bb7a59deb128c67cbe522 Mon Sep 17 00:00:00 2001
> > From: Johannes Schauer Marin Rodrigues 
> > Date: Wed, 18 May 2022 07:11:39 +0200
> > Subject: [PATCH] dpkg-genbuildinfo: when cross-compiling add
> >  Can-Execute-Host-Architecture field
> 
> > +use File::Temp qw(tmpnam);
> 
> This function is marked as obsolete by POSIX, the File::Temp object
> provides a nice interface that can be used instead, perhaps you used
> it but were hit by ETXTBSY errors? (If so closing the descriptor fixes
> the issue, which is what I've done now.) This also means we do not
> need to cleanup the file as the object will do it on its destructor
> when going out of scope.

Yes, I used tmpnam because I got an error that we cannot execute the file as it
was still being written to. While tmpnam might be obsoleted by POSIX, I think
File::Temp uses its own implementation -- at least the docs suggest that it
does. Anyway, this is not really of any importance.

> > +spawn(exec => [ debarch_to_gnutriplet(get_host_arch()) . '-gcc', '-x', 
> > 'c', '-o', $tmpname, '-' ],
> 
> I added honoring the CC envvar, but can potentially result in building
> for the build instead of host arch, as unfortunately we cannot rely on
> an "external build driver" setting a coherent build environment. So
> should probably go back to hardcoding it, but I'm thinking I should
> move all gcc hardcoding into a new vendor-hook that gets the default
> compiler name.

Yes, by ignoring CC I wanted to make sure that a d/rules cannot choose the
wrong compiler.

> > +if ($? == 0 && $stdout eq "ok") {
> > +   $fields->{'Can-Execute-Host-Architecture'} = "true";
> > +} else {
> > +   $fields->{'Can-Execute-Host-Architecture'} = "false";
> 
> I think a taint flag makes more sense. But it has the problem that
> then you might need to check the dpkg version used to see whether
> the check might have been performed, but I'm not sure whether that'd
> be a concern at all? (If its own field would be strongly favored then
> I think it should use the usual "yes"/"no" values used elsewhere.)

I don't have any strong opinion about this. I think I'd be fine with a taint
flag. If any tool wants to read this out in the future, I don't think that
checking the dpkg version is too much to ask for.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1020533: dpkg should use /var/lib/dpkg/arch to determine native arch when running chrootless

[Johannes Schauer Marin Rodrigues]

Package: dpkg
Version: 1.21.8
Severity: normal
X-Debbugs-Cc: jo...@debian.org

Hi,

steps to reproduce on amd64:

#!/bin/sh
set -exu
mkdir -p dpkgroot/var/lib/dpkg
echo "arm64" > dpkgroot/var/lib/dpkg/arch
cat << 'END' > dpkgroot/var/lib/dpkg/status
Package: perl-base
Status: install ok installed
Architecture: arm64
Version: 1
END
mkdir -p pkg/DEBIAN
cat << 'END' > pkg/DEBIAN/control
Package: perl-modules-5.34
Version: 1
Architecture: all
Depends: perl-base
END
dpkg-deb --build pkg pkg.deb
PATH=/usr/sbin:/usr/bin:/sbin:/bin dpkg \
--log=/dev/null \
--force-not-root \
--force-script-chrootless \
--root=dpkgroot \
--install pkg.deb

result:

Preparing to unpack pkg.deb ...
Unpacking perl-modules-5.34 (1) ...
dpkg: dependency problems prevent configuration of perl-modules-5.34:
 perl-modules-5.34 depends on perl-base.
dpkg: error processing package perl-modules-5.34 (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 perl-modules-5.34

If one changes "Architecture: arm64" to "Architecture: amd64" (the
architecture of my native dpkg) it works.

Maybe the prolbem is, that dpkg treats perl-modules-5.34 (it being
arch:all) implicitly as the native arch which is (wrongly) chosen to be
amd64 instead of arm64. And in that case, perl-base:arm64 cannot satisfy
its dependency.

Thanks!

cheers, josch

Bug#1023922: dpkg-checkbuilddeps: please add an option to print the list of packages

[Johannes Schauer Marin Rodrigues]

Hello everybody! :)

Quoting Guillem Jover (2022-11-14 13:17:34)
> [ CCing devscripts, pbuilder and sbuild, as this is about some
>   potential functionality refactoring. ]

thank you!

> On Sun, 2022-11-13 at 11:22:50 +0100, Enrico Zini wrote:
> > On Sat, Nov 12, 2022 at 09:30:43PM +0100, Guillem Jover wrote:
> > > There was a bug filed requesting adding custom output format support
> > > (#214566) but it was closed “recently”. I think there might be some
> > > value in that, but not for the intended use the submitters seemed
> > > to want it.
> > > 
> > > I'd be interested to know how you'd want to use this new output/option
> > > as from the PoC script you provide it is not obvious to me, as it
> > > prints both build-depends and build-conflicts in an indistinguishable
> > > way, and it includes version constraints and alternative dependencies.
> > 
> > My specific use case at the moment is setting up a container
> > *description* (not a container) with all the dependencies I need to do
> > development on a package[1].
> > 
> > I could run apt-get build-dep inside the container and get the
> > development environment installed, but then I lose the ability of being
> > able to describe it in a terse way, and I can only do something along
> > the lines of listing all installed packages in the container and their
> > versions, which is too noisy for an average bug report.
> 
> Ok, so basing this description on .buildinfo would not seem to be
> satisfactory then.
> 
> > The way I chopped dpkg-checkbuilddeps was a first approximation. Given
> > that now we have `apt-get satisfy`, my next step would be to have my
> > hacked version print a list of arguments for it, which can include
> > "Conflicts:", but which can already be preprocessed to reduce some noise
> > like packages required or not required from the target architecture.
> 
> Ah, so from this I gather that in essence what we need is a way to map
> from build-dependencies into run-time dependencies, removing/filtering
> them from anything that is not accepted in the latter. That makes
> sense and does not seem to have the concerns of the previously filed
> bug request, as that required performing decisions in a layer too low
> where that required information was not available.
> 
> I could see gathering any build-dependency fields as restricted by
> (-A/-B/-I), remapping them based on current arch/profile, then
> outputting them as a pair of Depends/Conflicts fields (perhaps even
> an Architecture field if there was arch-restrictions applied?). For
> «apt satisfy» you might need to trim the «Depends: » part though.
> 
> Would that work for you? I think it would work for pbuilder.
> 
> > More generally, I'd like Debian to have, as a standard, something
> > similar to `rpmspec --parse filename.spec | grep BuildRequires`
> > because I see it reimplemented so many times (pbuilder, sbuild, and so
> > on) that my instincts screams invoking the rule of three and
> > refactor[2].
> 
> I think the above would solve your problem, and potentially could
> substantially reduce the code in pbuilder-satisfydepends. For sbuild
> and mk-build-deps (devscripts), which are already in perl, that would
> only potentially help if this is included as part of a public module.
> So I'll be going that way in case they want to (eventually) switch.

As far as I can see, this additional feature will not break anything in sbuild,
so I think I was CC-ed because the question is whether sbuild can use this? In
an earlier mail, Enrico writes:

> More generally, I'd like Debian to have, as a standard, something
> similar to `rpmspec --parse filename.spec | grep BuildRequires`
> because I see it reimplemented so many times (pbuilder, sbuild, and so
> on) that my instincts screams invoking the rule of three and
> refactor[2].

I like to remove code so that I don't have to care about it anymore. But I
don't understand which part of sbuild can be replaced by this. Enrico, can you
explain?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#825385: Bug#1020533: dpkg should use /var/lib/dpkg/arch to determine native arch when running chrootless

[Johannes Schauer Marin Rodrigues]

Hi Guillem,

Quoting Guillem Jover (2022-10-10 12:23:58)
> On Thu, 2022-09-22 at 22:13:34 +0200, Johannes Schauer Marin Rodrigues wrote:
> As mentioned on IRC, the problem here (and on #825385) is indeed that dpkg
> considers its own arch the native one, and when operating on a cross-arch
> chroot, that goes wrong, both in dependency resolution and when outputting
> arch-qualified package names for example.
> 
> Fixing this properly is tricky though, because there are multiple
> requirements in tension here:
> 
>   * The external dpkg should be able to tell what's the arch for the
> internal one w/o having to execute anything (that it might not be
> able to run anyway).
>   * Setting a file on the database means either requiring a dpkg
> maintscript (for the bootstrap phase) which we are trying to get
> rid of, or offloading this to the bootstrappers (even worse), it
> also means it could be modified w/o dpkg noticing, which can break
> dependency resolution from an existing system.
>   * Shipping a file with the arch would seem like the best option (as
> that is checksummed) and not in the db, but that means then, that
> pathname under /usr needs to be selectable too at run-time, as
> that encodes configure-time vendor-specific fsys layout.
>   * Setting that directory from the config file is currently
> problematic as dpkg does not have a way to specify a different
> config directory.
>   * Perhaps just adding a new --foodir option to dpkg could be enough
> for now, if the inner dpkg uses a different pathname, in the
> same way if it uses a different database pathname.
>   * But then only specifying the db pathname would no longer be
> enough, and dependency resolution and arch-qualifying would still
> be wrong. :/
>   * But then if the file does not exist (or cannot be found in the
> «right» place) it could still fallback to the currently running
> native arch, but that looks flaky (not worse than now, though,
> but not ideal). :/
> 
> I guess I can prototype something with the --foodir idea though, but that's
> still rather meh.

once you have a prototype (even if it's not release-ready) feel free to share
it, because our CI setup is able to apply patches to source packages. So if you
have something that we can test, just send it over and we'll build a patched
dpkg to run this with our scripts.

Thanks!

cheers, josch

signature.asc
Description: signature