Re: librust-bitflags-1-dev: fails to co-install

Hi Matthias, On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote: > This is the same situation as in #1040477. This is an issue wrt how we > generate the semvers. I image rust-proc-macro-crate-1 would pose the same > problem. Quoting you from 1040477: Right! > Is the only workaround

Re: Another usrmerge complication

Hi Simon and Simon, On Sun, Mar 17, 2024 at 12:08:21PM +, Simon McVittie wrote: > On Sun, 17 Mar 2024 at 11:23:28 +0900, Simon Richter wrote: > > When /bin is a symlink to usr/bin, > > and I install two packages, where one installs /bin/foo and the other > > installs /usr/bin/foo > > My

Bug#1065439: dpkg-buildflags: add HIPFLAGS to supported flags

On Thu, Mar 07, 2024 at 04:00:22AM +0100, Guillem Jover wrote: > > When packaging the AMD ROCm GPU libraries for Debian, we are currently > > using CXX=hipcc or CXX=clang++ to build libraries written in HIP as if > > they were written in C++. > > I guess we should also add HIPCXX (defaulting to

Bug#1059982: dpkg: move start-stop-daemon to /usr for DEP17

) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * DEP17: Move start-stop-daemon to /usr/sbin. (Closes: #-1) + + -- Helmut Grohne Thu, 04 Jan 2024 11:55:32 +0100 + dpkg (1.22.2) unstable; urgency=medium [ Guillem Jover ] diff --minimal -Nru dpkg-1.22.2/debian/dpkg.install dpkg-1.22.2

Bug#1057199: debian-policy: express more clearly that Conflicts to not reliably prevent concurrent unpacks

Package: debian-policy Version: 4.6.2.0 X-Debbugs-Cc: debian-d...@lists.debian.org, de...@lists.debian.org Hi, first of all huge thanks to David, Guillem and Julian for all of their explanations. In large parts, this bug report is yours and I'm just the one writing it down. §7.4 currently

Re: RFC: Reworking build flags — «*_FOR_BUILD» flags handling

Hi Guillem, On Thu, Nov 30, 2023 at 01:17:37PM +0100, Guillem Jover wrote: > [ See . ] > > This problem is related to the *_FOR_BUILD support (to specify flags for > the build instead of host system during cross-building), which got >

Re: RFC: Reworking build flags — Multiple toolchains support

On Thu, Nov 30, 2023 at 01:35:17PM +0100, Guillem Jover wrote: > This problem is related to the current (dpkg) policy where flags target > the current default compiler and version for the specific vendor, but > some of the flags emitted are toolchain specific and can break when > used with another

Re: Proper way to do setcap in maintscript

Hi Niels, thanks for reaching out. On Sat, Nov 18, 2023 at 05:13:44PM +0100, Niels Thykier wrote: > * Should the snippet use dpkg-statoverride instead of a chmod? >(If dpkg-statoverride is used, how will this interact with the next > bullet?) I don't think dpkg-statoverride can do

Bug#1021292: Enabling branch protection on amd64 and arm64

Hi Guillem, On Thu, Aug 31, 2023 at 02:12:51AM +0200, Guillem Jover wrote: > So this happened, and Johannes reported that this seems to be breaking > cross-building. :( > > The problem, which is in fact not new, but is made way more evident > now, is that the flags used are accepted only per

Re: booststrapping /usr-merged systems

Hi Sven, On Sat, Jun 10, 2023 at 08:35:44AM +0200, Sven Joachim wrote: > > Unfortunately, any > > external package that still ships stuff in /bin breaks this. In effect, > > any addon repository or old package can break your system. > > You lost me. We have converted /bin to a symlink already,

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

Hi, On Fri, Jun 09, 2023 at 09:57:21PM +0200, HW42 wrote: > Did you consider just having one package keep one dummy file in /bin? > While this isn't elegant it sounds much less complex than diversions and > tricky pre-depend loops, etc. The dummy file is not necessary. Debian packages can ship

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

Hi Johannes, On Fri, Jun 09, 2023 at 05:47:56PM +0200, Johannes Schauer Marin Rodrigues wrote: > if I understand that plan correctly, the usrmerge-support package setting up > diversions is only necessary because you want to avoid having to do the move > to > /usr of *all* affected packages in

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

Hi Raphaël, On Thu, Jun 08, 2023 at 10:46:24AM +0200, Raphael Hertzog wrote: > In the same spirit, I'd like to throw an idea... could we decide that > base-files is the first package to be configured as part of the bootstrap > protocol and change base-files maintainer's scripts into statically

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

Hi Ansgar, I'm speaking with a CTTE hat here, but not representing CTTE consensus. On Wed, May 10, 2023 at 11:47:42PM +0200, Ansgar wrote: > Dear ctte, please consider overruling the dpkg maintainer to include > the patch from #994388[1]. I think we need to reject this request on multiple

booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

Hi, This bootstrap aspect got me and I discussed this with a number of people and did some research. On Sun, May 07, 2023 at 12:51:21PM +0100, Luca Boccassi wrote: > I don't think this is true? At least not in the broader sense: if you > compile something on Debian, it will obviously get linked

Bug#1036021: cadabra2,python3-notebook: undeclared file conflict on /usr/lib/python3/dist-packages/notebook/static/components/codemirror

Package: cadabra2,python3-notebook Severity: serious X-Debbugs-Cc: a...@debian.org, debian-d...@lists.debian.org Hi, I noticed a suprising undeclared file conflict. While Andreas' tooling finds most of these, it missed this one. It's about

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Luca, On Tue, May 09, 2023 at 01:56:53AM +0100, Luca Boccassi wrote: > On Mon, 8 May 2023 at 19:06, Sean Whitton wrote: > > It's designed to stop as-yet-unknown problems happening, too. > > Well, sure, but we've been at this for years, any such problems should > really be known by now. This

Re: DEP 17: Improve support for directory aliasing in dpkg

On Mon, May 08, 2023 at 02:07:08AM +0100, Luca Boccassi wrote: > I can see we don't agree on this matter, of course, that is clear. And > I hope we can find common ground. But let me provocatively ask this > first: is the same rule going to be enforced for all other changes > that happen in the

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Luca, On Sun, May 07, 2023 at 12:51:21PM +0100, Luca Boccassi wrote: > The local/external aspect is already covered in Ansgar's reply and subthread. I hope that we can at least agree that we don't have consensus on this view. And the more I think about it, the more it becomes clear to me that

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Luca, On Sat, May 06, 2023 at 09:47:15PM +0100, Luca Boccassi wrote: > Sure, there are some things that need special handling, as you have > pointed out. What I meant is that I don't think we need special > handling for _all_ affected packages. AFAIK nothing is using > diversions for unit

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Luca, On Sat, May 06, 2023 at 04:52:30PM +0100, Luca Boccassi wrote: > To have a working system you need several more steps that are > performed by the instantiator/image builder, such as providing working > and populated proc/sys/dev, writable tmp/var, possibly etc. And it > needs to be

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Simon, On Thu, May 04, 2023 at 03:37:49AM +0900, Simon Richter wrote: > For aliasing support in dpkg, that means we need a safe policy of dealing > with diversions that conflict through aliasing that isn't "reject with > error", because the magic dpkg-divert would always generate conflicts. I

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Raphaël, On Wed, May 03, 2023 at 10:31:14AM +0200, Raphael Hertzog wrote: > I don't know APT well enough to answer that question but from my point of > view it's perfectly acceptable to document in the release notes that you > need to upgrade dpkg first. Yes, this issue seems vaguely solvable

Re: DEP 17: Improve support for directory aliasing in dpkg

On Tue, May 02, 2023 at 02:09:32PM +0200, Helmut Grohne wrote: > This is problems we know about now, but it likely is not an exhaustive > list. This list was mostly guided by Guillem's intuition of what could > break at https://wiki.debian.org/Teams/Dpkg/MergedUsr and I have to say &

Re: DEP 17: Improve support for directory aliasing in dpkg

On Tue, May 02, 2023 at 02:09:32PM +0200, Helmut Grohne wrote: > I noticed that the number of packages shipping non-canonical files is > relatively small. It's less than 2000 binary packages in unstable and > their total size is about 2GB. So I looked into binary-patching them and

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Luca, On Fri, Apr 21, 2023 at 03:29:33PM +0100, Luca Boccassi wrote: > After Bookworm ships I plan to propose a policy change to the CTTE and > policy maintainers to forbid shipping files in the legacy directories > altogether, followed by a debhelper change to adjust any stragglers >

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Raphaël, On Tue, May 02, 2023 at 12:30:21PM +0200, Raphael Hertzog wrote: > We don't want to stat all the files in all packages but we could do better: > if we are about to remove an old file that is available through a > symlinked directory, we could check the new name of the file and see if

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Marvin, On Sat, Apr 29, 2023 at 02:08:37PM -0400, Marvin Renich wrote: > My understanding from following this thread (and others) is that dpkg > has a bug that can easily be triggered by a sysadmin replacing a > directory with a symlink (and some other necessary conditions that don't > happen

Re: DEP 17: Improve support for directory aliasing in dpkg

Please excuse the volume of mails I am producing at this time, but I still think this adds to the discussion. On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote: > I have a bad feeling about this. I think some dpkg maintainer warned us > that diversions would break. Let's peek

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Simon, On Fri, Apr 28, 2023 at 02:07:33PM +0200, Simon Richter wrote: > Transforming existing diversions: yes, if you can find out about them > without looking at dpkg internal files. It may very well be necessary to > update the file format on one of these, and if that would cause your >

Re: DEP 17: Improve support for directory aliasing in dpkg

On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote: > Ok, let's move on. I've proposed diversions as a cure, but in reality > diversions are a problem themselves. Consider that > cryptsetup-nuke-password diverts /lib/cryptsetup/askpass, which is > usually owned b

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Simon, On Sat, Apr 22, 2023 at 11:41:29AM +0100, Simon McVittie wrote: > You might reasonably say that "the maintainer of bar didn't add the > correct Breaks/Replaces on foo" is a RC bug in bar - and it is! - but > judging by the number of "missing Breaks/Replaces" bug reports that have > to

Re: DEP 17: Improve support for directory aliasing in dpkg

On Wed, Apr 26, 2023 at 07:11:10AM -0600, Sam Hartman wrote: > > "Simon" == Simon McVittie writes: > > Simon> You might reasonably say that "the maintainer of bar didn't > Simon> add the correct Breaks/Replaces on foo" is a RC bug in bar - > Simon> and it is! - but judging by the

Re: DEP 17: Improve support for directory aliasing in dpkg

On Tue, Apr 25, 2023 at 09:07:28PM +0200, Helmut Grohne wrote: > In sincerely hope that this fixed-up plan doesn't have any serious > issues. If you find any please tell. Thanks for the praise, but problems I found and I'm pretty sure this is only the tip of the iceberg. So for one thing,

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Luca, On Sat, Apr 22, 2023 at 01:06:18PM +0100, Luca Boccassi wrote: > On Sat, 22 Apr 2023 at 11:50, Helmut Grohne wrote: > > On Fri, Apr 21, 2023 at 03:29:33PM +0100, Luca Boccassi wrote: > > > After Bookworm ships I plan to propose a policy change to the CTTE and > &

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Guillem, On Sat, Apr 08, 2023 at 04:35:25AM +0200, Guillem Jover wrote: > I thought my reply was rather clear, and that we had further clarified > that privately, that at the time I thought there was no other answer > required as (AFAIR) you stated you'd be digging further on it. And I >

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Simon, On Sat, Apr 08, 2023 at 04:06:54PM +0200, Simon Richter wrote: > Yes, I am quite busy, but it's not forgotten. I keep adding new test cases. Thank you for taking the time to follow up. I discarded many of your arguments in this reply due to agreement. > Dpkg already has defined

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Raphaël, On Fri, Apr 21, 2023 at 03:03:10PM +0200, Raphael Hertzog wrote: > Here you are considering all files, but for the purpose of our issue, > we can restrict ourselves to the directories known by dpkg. We really > only care about directories that have been turned into symlinks (or >

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Simon, On Fri, Apr 21, 2023 at 06:05:27PM +0200, Simon Richter wrote: > The first thing we need consensus on, IMO, is the definition of "complete". I honestly had hoped that we did have consensus on this point. > The maintainers of the usrmerge package consider the status quo an > acceptable

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Luca, On Fri, Apr 21, 2023 at 03:29:33PM +0100, Luca Boccassi wrote: > After Bookworm ships I plan to propose a policy change to the CTTE and > policy maintainers to forbid shipping files in the legacy directories > altogether, followed by a debhelper change to adjust any stragglers >

DEP 17: Improve support for directory aliasing in dpkg

Hi, I have been looking into the aliasing problems in dpkg on behalf of Freexian's Debian funding. To that end I proposed a possible way forward last year (https://lists.debian.org/debian-dpkg/2022/11/msg7.html), but the feedback I got was not particularly helpful in determining consensus. A

Bug#1023438: dpkg-checkbuilddeps: allow satisfying :native Build-Depends with Multi-Arch: foreign packages

Hi Andreas, On Tue, Jan 24, 2023 at 03:13:29PM +0100, Andreas Beckmann wrote: > One package affected by this is src:reprepro in experimental where > dpkg-checkbuilddeps now rejects db-util:native (which gained > M-A: foreign in bookworm). The reason to allow :native on M-A:foreign is to ease

Bug#892664: dpkg with zstd support (was Re: dpkg with threaded xz decompression.)

Hi Guillem, On Thu, Sep 29, 2022 at 10:20:51AM +0200, Guillem Jover wrote: > So I'm still not certain how this will be added, but certainly before > the Debian freeze. I'm though not planning on adding zstd support for > source packages. Thank you for proposing this compromise. I think we can

Bug#1027716: dpkg: consider trimming changelog.gz

Package: dpkg Version: 1.21.12 Severity: wishlist Hi Guillem, dpkg's changelog.gz keeps growing. For the changelog.Debian.gz, debhelper has started pruning old entries. At this time, the changelog contributes one 7th of dpkg's Installed-Size and a third of its .deb size. For development systems,

Re: another usrmerge branch

Hi Simon, On Thu, Dec 08, 2022 at 05:20:20PM +0100, Simon Richter wrote: > I've also started work on getting usrmerge back into a sensible state, > current progress is at > > https://salsa.debian.org/sjr/dpkg/-/tree/wip-canonical-paths Thank you. I've looked into this approach and I don't

Bug#1025273: dpkg-genbuildinfo: fails when no cross compiler is available

Package: dpkg-dev Version: 1.21.10 Severity: important File: /usr/bin/dpkg-genbuildinfo User: helm...@debian.org Usertags: rebootstrap Hi Guillem, thanks for implementing the taint flag for cross compilation. Unfortunately, this breaks architecture bootstrap. We need to cross build linux kernel

Bug#1024421: buildtools.mk: triplet-f77 does not exist

Package: dpkg-dev Version: 1.21.9 File: /usr/share/dpkg/buildtools.mk X-Debbugs-Cc: Enrico Zini Hi Guillem, Enrico discovered, that the FC variable initialized by dpkg's buildtools.mk points at f77. During native builds this works, but during cross builds it becomes triplet-f77, which doesn't

Re: supporting merged-/usr-via-aliased-dirs in dpkg

Hi Guillem, On Fri, Nov 11, 2022 at 01:21:32PM +0100, Guillem Jover wrote: > I'm doing a shallow reply over this, can expand further during the > weekend probably if necessary. Thank you for taking the time to reply. > > https://lists.debian.org/20181223030614.ga8...@gaara.hadrons.org and > >

Bug#1023486: Please add loong64 support to dpkg

ian package. Reviewed-by: Helmut Grohne Please do merge it with the other two bugs you created earlier though. Please be patient about this. However simple this patch may look, it usually takes significant time to make it appear in dpkg. Guillem, please try merging it before the bookworm release

Bug#1023438: dpkg-checkbuilddeps: allow satisfying :native Build-Depends with Multi-Arch: foreign packages

Package: dpkg Version: 1.21.9+b1 X-Debbugs-Cc: debian-cr...@lists.debian.org Hi Guillem, I think dpkg-checkbuildeps should not reject a Multi-Arch: foreign package satisfying a build dependency annotated :native. The internal resolver of sbuild definitely considers this valid and iirc, apt and

supporting merged-/usr-via-aliased-dirs in dpkg

Hi Guillem, please Cc me in replies. Disclaimer: I'm doing this on Freexian capacity. I'm trying to figure out a way to make dpkg better support the aliasing approach chosen by the CTTE to implement merged /usr (aka merged-/usr-via-aliased-dirs). In order to avoid doing unnecessary work, I'd

Bug#873138: Installed-Build-Depends lack architecture qualification

Control: tags -1 + patch Hi Guillem, cross folks and reproducible folks, On Thu, Aug 24, 2017 at 09:45:39PM +0200, Helmut Grohne wrote: > while looking into a .buildinfo file, I noticed that > Installed-Build-Depends are useless beyond #871494: They lack > architecture qualificat

Re: Bug#1007717: Updated draft resolution

Hi, On Wed, Jun 15, 2022 at 04:06:55PM +0200, Lucas Nussbaum wrote: > If you look at Debian 'testing' only, I think that the only remaining > way to do that is 1.0 + quilt (packages that were using dpatch have all > been converted or removed from testing). That's good. I wasn't able to locate a

Re: Bug#1007717: Updated draft resolution

Hi, On Tue, Jun 07, 2022 at 10:31:18PM -0700, Sean Whitton wrote: > Here's an updated ballot in light of our upcoming meeting. I've left > space to add a 4b, if, when our current discussion is concluded, someone > would like that in addition to 4c. After the meeting, Simon, Sean and myself

Re: Bug#1007717: Draft resolution for "Native source package format with non-native version"

Hi Sean, On Tue, Jun 07, 2022 at 04:35:24PM -0700, Sean Whitton wrote: > I disagree with you that this is primarily about package ownership, and > I think that we agree on more than you realise we do :) Hmm. It's not that obvious. While it would be possible to remove the choice of workflow from

Re: Bug#1007717: Draft resolution for "Native source package format with non-native version"

Hi Sean, On Mon, Jun 06, 2022 at 11:08:48PM -0700, Sean Whitton wrote: > I think this argument needs to be made more precise -- we should be > clearer about why this particular un-uniformity is bad. I don't think > the issue for new contributors is persuasive enough, as new contributors > can

Re: Bug#1007717: Draft resolution for "Native source package format with non-native version"

Hallo, On Tue, May 10, 2022 at 05:29:57PM -0700, Sean Whitton wrote: > DRAFT > > Using its powers under constitution 6.1.5, the Technical Committee > issues the following advice: I've given this some thought and feel uneasy about one item. > 4. We believe that there are indeed circumstances

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

Hi Guillem, would you maybe reconsider adding zstd decompression support at this time? On Sun, Mar 18, 2018 at 04:38:15AM +0100, Guillem Jover wrote: > So, the items that come to mind (most from the dpkg FAQ [F]: > > * Availability in general Unix systems would be one. I think the code >

Bug#1003814: dpkg-repack: build profile with a slash breaks dose-builddebcheck

Source: dpkg-repack Version: 1.49 Severity: important Control: affects -1 + dose-builddebcheck Hi Guillem, dose-repack's Build-Depends now contain a Build-Profile with a slash. That's possibly an experiment for a dpkg time travel fix and possibly an accident. Please clarify. The most direct

Bug#990712: dpkg: triggers database contains architecture qualifiers in a non-reproducible way when changing the dpkg architecture

Package: dpkg Version: 1.20.9 X-Debbugs-Cc: jo...@debian.org Hi Guillem, this issue is co-reported by josch. While working on DPKG_ROOT reproducibility, we observed that the trigger database differs for the foreign and native case. In the foreign case, packages would carry an architecture

Bug#980963: dpkg: Please add ARC architecture

Hi Alexey, On Wed, Mar 03, 2021 at 07:35:39PM +, Alexey Brodkin wrote: > Well not sure why there's a dependency on glibc as w/o ARC target support > in dpkg nothing could be built for ARC. For example I did built Binutils > with fixed dpkg. There is no hard dependency in that direction. Just

Bug#980963: dpkg: Please add ARC architecture

On Sat, Feb 06, 2021 at 07:25:35PM +, Alexey Brodkin wrote: > Any chances to get updates on this one some time soon? No. The triplet cannot be changed once added. Therefore, the addition is often deferred. The absence of the triplet can easily be worked around. A bootstrap can be prototyped

Bug#983565: coreutils should support DPKG_ROOT

-8.32/debian/changelog 2021-02-26 10:52:22.0 +0100 @@ -1,3 +1,10 @@ +coreutils (8.32-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Support DPKG_ROOT in maintainer scripts. (Closes: #-1) + + -- Helmut Grohne Fri, 26 Feb 2021 10:52:22 +0100 + coreutils (8.32-4

Bug#970545: dpkg FTBFS: KEY_EVENT undeclared

Source: dpkg Version: 1.20.5 Severity: serious Tags: ftbfs dpkg FTBFS as of today: | g++ -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -DADMINDIR=\"/var/lib/dpkg\" -DLIBDIR=\"/usr/lib/dpkg\" -DLOCALLIBDIR=\"/usr/local/lib/dpkg\" -idirafter ../../lib/compat -iquote . -I.. -I../../lib

Re: review of guillem/next/d-m-h-root

Hi Guillem, On Wed, Apr 29, 2020 at 11:28:08AM +0200, Guillem Jover wrote: > Thanks! I notice this is susceptible to directory traversals. I've > amended it and added comments in the attached version. I'm thinking > I'll need to add unit tests to cover for this among other similar > issues. I

Resuming discussion on Runtime-Depends [Was: Bug#804624: please improve support for installing foreign packages to chroots and add DPKG_ROOT]

016-03-30 at 08:48:45 +0200, Helmut Grohne wrote: > > I do have an answer to the absence of Maint-Depends now: Also add > > Runtime-Depends. Then Depends would simply beam both Maint-Depends and > > Runtime-Depends like Build-Depends means both Build-Depends-Arch and > >

review of guillem/next/d-m-h-root

Hi Guillem, you asked me to review your next/d-m-h-root branch. Thanks to all who've worked on this! I've looked at the two commits as one diff (12961967a563..6aa3bf8f98b8) without attributing individual hunks to the respective authors. This is what I found: * Diagnostic messages tend to

Bug#918030: please provide DEB_HOST_UNAME_MACHINE

Hi Guillem, On Fri, Feb 15, 2019 at 02:28:32AM +0100, Guillem Jover wrote: > [ Sending out this which I had sitting here on a terminal since it was > filed. :) ] Thank you for no longer deferring your insightful reply. > On Wed, 2019-01-02 at 15:23:03 +0100, Helmut Grohne wrote: >

Bug#918030: please provide DEB_HOST_UNAME_MACHINE

Hi Jonathan, On Wed, Jan 02, 2019 at 05:49:48PM -0800, Jonathan Nieder wrote: > Interesting. Can you give an example of a package that would benefit > from this? https://sources.debian.org/src/klibc/2.0.4-14/Makefile/?hl=33#L33

Bug#918030: please provide DEB_HOST_UNAME_MACHINE

Package: dpkg-dev Version: 1.19.2 Severity: wishlist User: helm...@debian.org Usertags: rebootstrap Hi, I find myself repeating a mapping from Debian architectures to the typical output of uname -m (and occasionally -s) in various packages. Copying such code is going to be a maintenance

Bug#894965: dpkg-architecture should stop warning about unset CC

On Thu, Apr 12, 2018 at 01:18:57PM +0200, Guillem Jover wrote: > So the intention here has been, AFAICT, to try to make detecting > cross-building: > > 1) kind of automatic, something just needs to set CC to the correct > cross-toolchain and then dpkg would figure out the host arch. That

Bug#894965: dpkg-architecture should stop warning about unset CC

Package: dpkg-dev On Thu, Apr 05, 2018 at 04:28:48PM +0200, to...@tuxteam.de wrote: > - Need to set CC > > Yes, the warning was clear enough, but I was a bit surprised > I had to set CC like so: The warning you are talking about likely is this one: | dpkg-architecture: warning: specified GNU

Bug#891435: dpkg-genbuildinfo: does not arch qualify Installed-Build-Depends

Package: dpkg-dev Version: 1.18.11 File: /usr/bin/dpkg-genbuildinfo User: reproducible-bui...@lists.alioth.debian.org Usertags: toolchain X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org When building packages with foreign architecture packages installed, the recorded

Bug#873138: Installed-Build-Depends lack architecture qualification

Package: dpkg-dev Version: 1.18.24 File: /usr/bin/dpkg-genbuildinfo User: helm...@debian.org Usertags: rebootstrap Hi Guillem, while looking into a .buildinfo file, I noticed that Installed-Build-Depends are useless beyond #871494: They lack architecture qualification. Thus there is no way to

Bug#861217: dpkg fails to unpack m-a:same instance with conffiles over removed but not purged instance

Package: dpkg Version: 1.18.23 User: helm...@debian.org Usertags: rebootstrap Hi Guillem, it seems that dpkg exhibits a strange behaviour with Multi-Arch: same and conffiles. If you have one instance removed, but not purged, and try to install another instance, dpkg errors out with an unpack

Bug#849913: dpkg-shlibdeps: searches wrong architecture libraries

Hi Raphaël, On Mon, Jan 02, 2017 at 05:37:06PM +0100, Raphael Hertzog wrote: > Can't you just install "binutils-multiarch" when you build such cross > compilers? No, because using binutils-multiarch is broken. Whenever a new architecture is brought up, binutils-multiarch lacks support for it.

Bug#849913: dpkg-shlibdeps: searches wrong architecture libraries

Package: dpkg-dev Version: 1.18.17 Severity: important File: /usr/bin/dpkg-shlibdeps Tags: patch User: helm...@debian.org Usertags: rebootstrap Hi Guillem and Raphaël, while working on #843073, we agreed to merge Raphaël's patch on the provision that we would revert it if it causes breakage.

Bug#843073: Debian Installer Stretch Alpha 8 release

Control: tags -1 - patch On Mon, Nov 14, 2016 at 12:22:58PM +0100, Raphael Hertzog wrote: > Please find two patches attached. > > I checked that the command below was failing with the current dpkg-dev > and it did no longer fail with the updated one. > > $ sbuild -d sid --add-depends=usrmerge

Re: Bug#843910: cups-pdf FTCBFS: uses build architecture compiler

On Wed, Nov 16, 2016 at 04:58:52PM +0200, Martin-Éric Racine wrote: > Fair enough. I'm wondering if the enclosed patch would accomplish the > same thing. I mean, the goal always is to set CC for the target host, > right? >From a cross builder's perspective, yes. From a clang user's perspective,

Re: Bug#843910: cups-pdf FTCBFS: uses build architecture compiler

On Wed, Nov 16, 2016 at 01:59:50PM +0200, Martin-Éric Racine wrote: > I cannot help but wonder if setting CC for cross-build would be best > handled by the build tools themselves, rather than compensated for by > individual packages' debian/rules. I'm inclined to agree, but you don't have a build

Bug#843073: dpkg-shlibdeps: broken on i386 with merged /usr

On Sat, Nov 05, 2016 at 10:40:30PM +0100, Marco d'Itri wrote: > This is a more complex issue, since it does not happen on my i386 > system. > It has been discussed in #810499 but I am not sure about the best way to > fix this. It depends on the search order for library directories.

Bug#838392: dpkg: should build-depend on hurd-dev

Hi Samuel, On Wed, Sep 21, 2016 at 12:26:16AM +0200, Samuel Thibault wrote: > Sure, but dpkg is part of build-essential too, and so AIUI it thus > needs to explain how it is supposed to build within the build-essential > bootstrap. I think Guillem is right here: With our current tools, it is not

Bug#825002: sgml-base: broken super catalog after removing docutils-common

pkg 1.17.0. (Closes: #-1) ++ Declare trigger interest on /usr/share/sgml, /usr/share/xml and + update-catalog (for pending debhelper change). + + -- Helmut Grohne <hel...@subdivi.de> Sat, 21 May 2016 23:46:45 +0200 + sgml-base (1.27) unstable; urgency=medium * QA upload. dif

Re: Bug#824594: please support DPKG_ROOT in base-files' postinst

Hi Santiago, On Wed, May 18, 2016 at 12:05:28PM +0200, Santiago Vila wrote: > A few comments about this: Thanks for your quick reply! > * The idea is certainly interesting, but I would try to use a better > rationale for this project. In the current rationale I see in the wiki > page you

Bug#804624: please improve support for installing foreign packages to chroots and add DPKG_ROOT

s. I am attaching updated patches that address all of these points except for the renaming. Helmut >From 1d6cfda8e2a7ab5dfac3ea32b3ed6d957677fdda Mon Sep 17 00:00:00 2001 From: Helmut Grohne <hel...@subdivi.de> Date: Mon, 9 Nov 2015 22:07:52 +0100 Subject: [PATCH 1/2] export a variable DPK

Bug#804624: please improve support for installing foreign packages to chroots and add DPKG_ROOT

Hi Guillem, Thanks for taking the time to process this crazy idea! On Wed, Mar 30, 2016 at 01:29:15AM +0200, Guillem Jover wrote: > > b) Packages that do not "set -u" (nounset), can now prepend $DPKG_ROOT > >to any file they operate on. With old versions $DPKG_ROOT will be > >unset and

Bug#804624: please improve support for installing foreign packages to chroots and add DPKG_ROOT

ght to avoid creating a situation that is hard to fix up. Yet it seems pretty round to me already. Despite there being open questions, we can handle at least a) today. Helmut >From b10ba1186394ae880a5c1421ddb07afa1f3c9d20 Mon Sep 17 00:00:00 2001 From: Helmut Grohne <hel...@subdivi.de> Date:

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

Package: dpkg-dev Version: 1.17.23 Severity: wishlist User: helm...@debian.org Usertags: rebootstrap Some packages need extra Build-Depends when they are cross compiled. Here are some examples: * src:guile-2.0 needs guile-2.0 to cross-build * src:glib2.0 needs libglib2.0-dev:any to cross-build

Bug#772184: library path order differs from ld.so

-1.17.22/debian/changelog +++ dpkg-1.17.22+nmu1/debian/changelog @@ -1,3 +1,10 @@ +dpkg (1.17.22+nmu1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Fix dpkg-shlibdeps to use same search order as ld.so. (Closes: #-1) + + -- Helmut Grohne hel...@subdivi.de Fri, 05 Dec 2014 21:11:43 +0100

Bug#764929: dpkg-shlibdeps: error: is not a valid version

Package: dpkg-dev Version: 1.17.17 Severity: serious File: /usr/bin/dpkg-shlibdeps User: helm...@debian.org Usertags: rebootstrap Hi Guillem, I am not yet certain that this is a bug in dpkg, but I am filing it prematurely due to the severity of the breakage observed. jenkins.d.n did run into the

Bug#753052: dpkg,binutils: please agree on mips64el ABI

Control: reassign -1 src:binutils Control: retitle -1 mips64el-linux-gnuabi64-as defaults to N32 abi Control: tags -1 + upstream On Sat, Jun 28, 2014 at 08:32:42PM +0200, Helmut Grohne wrote: dpkg-architecture -amips64el -qDEB_HOST_GNU_TYPE gives mips64el-linux-gnuabi64, but binutils sets

Bug#753052: dpkg,binutils: please agree on mips64el ABI

Package: dpkg,src:binutils Severity: normal User: helm...@debian.org Usertags: rebootstrap X-Debbugs-Cc: aure...@debian.org Dear dpkg and binutils maintainers and Aurelien, dpkg-architecture -amips64el -qDEB_HOST_GNU_TYPE gives mips64el-linux-gnuabi64, but binutils sets the gnu type to

Bug#751363: dpkg: change gnu-triplet for i386 to i586-linux-gnu

Package: dpkg Version: 1.17.10 Severity: normal User: helm...@debian.org Usertags: rebootstrap Dear dpkg maintainers, Packages built with gcc-4.9 on i386 no longer work with actual i386 or i486 processors. Consequently, gcc has already moved on and changed the triplet from i486-linux-gnu to

Bug#751437: dpkg-dev: support ${source:Version} substvar in Build-Depends

+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Support interpolating ${source:Version} in Build-Depends. Closes: #-1 + + -- Helmut Grohne hel...@subdivi.de Thu, 12 Jun 2014 22:25:43 +0200 + dpkg (1.17.10) unstable; urgency=medium [ Guillem Jover ] diff -Nru dpkg-1.17.10

Bug#744780: dpkg: allows breaking dependencies on a:foo M-A:same by replacing it with a:bar M-A:none

Package: dpkg Version: 1.17.6 Severity: normal User: helm...@debian.org Usertags: rebootstrap Dear maintainer, Please imagine the following obscure scenario. (Yes, I actually managed to reproduce it in a real world example.) Package b:amd64 depends on a:amd64 M-A:same. Both are installed, all

Bug#718295: /usr/bin/dpkg-deb: dpkg-deb -Zgzip -z0 produces invalid debian packages

Package: dpkg Version: 1.17.0 Severity: important File: /usr/bin/dpkg-deb The linux maintainers chose to pass -Zgzip -z0 to dpkg-deb to retain backwards compatibility. Unfortunately the resulting binary package does not conform to the format documented at man 5 deb. It contains a data.tar.gz

Re: Temporary solution for changelog problem in binNMUs

Small side note on this interesting idea: On Tue, May 14, 2013 at 09:59:31AM +0200, Raphael Hertzog wrote: The other points are more difficult to solve but would be useful in their own to avoid the problem of small packages considered too heavy due to their meta-data. It might be worth to

Re: proposed sgml-base 1.16+nmu4 fixing #676717 and #678902

Dear dpkg maintainers, On Thu, Jun 28, 2012 at 02:05:56AM +0100, Ian Jackson wrote: I'm not convinced that a Pre-Depends is the best answer here. I think a better answer would be for the new dpkg to activate all file triggers when it first starts, and for sgml-base to simply use Depends.

Bug#675613: merging FTBFS bugs into dpkg-trigger bug

# processing 676062 reassign 676062 dpkg forcemerge 675613 676062 affects 675613 + src:debiandoc-sgml-doc-pt-br # processing 676061 affects 675613 + src:doc-base # processing 676107 affects 675613 + src:debian-faq # processing 676122 affects 675613 + src:debian-history # processing 676118 reassign

Re: Bug#675613: debiandoc-sgml: Does not register itself in /etc/sgml/catalog

Hi Guillem, Thanks for your quick and helpful response. On Sat, Jun 02, 2012 at 11:55:48PM +0200, Guillem Jover wrote: So on first thought, I think the solution would be to make dpkg activate file triggers for the parent directories on configure so that this case is handled correctly. In fact

  1   2   >