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 readi

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

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 capab

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

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 em

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 t

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 lin

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 levels

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 a

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 i

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 pro

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 files

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 instan

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

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 an

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

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 v

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

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

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 o

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 be

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 o

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

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 behavio

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

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

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 l

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 th

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

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 lik

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 c

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 furt

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 s

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 mos

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 i

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 don

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 include

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

wild speculations about build profile specification changes

On Tue, Jul 12, 2016 at 05:31:51PM +0200, Johannes Schauer wrote: > Quoting Javier Serrano Polo (2016-07-10 19:25:59) > > Binary packages should be exactly the same as if built without active > > profiles. This helps making and checking a subset of reproducible > > packages. > > This problem is al

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

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 th

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.

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 fa

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

reassign 675613 dpkg affects 675613 + debiandoc-sgml docbook docbook-dsssl docbook-ebnf docbook-html-forms docbook-mathml docbook-simple docbook-slides docbook-website docbook-xml dtd-ead libcommons-validator-java python-docutils sgml-data sgml2x w3c-dtd-xhtml xml-core thanks Hi Osamu, Thanks