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

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

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

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

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

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

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

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

Bug#47214: parseversion still leaking memory

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,

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

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

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

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

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

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!

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

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

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

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,

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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,

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

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

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

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

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

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

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

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 > &g

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

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 > >

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

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

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

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:

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

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

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

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

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

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

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

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

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

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 >

Bug#989602: dpkg-deb overwrites symlinks with directories

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

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

ers, 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-genbuil

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

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 > >

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

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

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

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

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

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