Hi Simon,
On Thu, Apr 17, 2025 at 08:23:18PM +0200, Simon Josefsson wrote:
> I noticed that Fedora 42 was released and their docker images lack a
> 'awk' tool. Debian trixie images ship with 'mawk' pre-installed right
> now. While I'm not convinced the removal game is necessarily a good
> one, I
Hello fellow developers,
On Thu, Apr 10, 2025 at 07:37:32AM +0200, Helmut Grohne wrote:
> how about libc6-dev stops depending on libcrypt-dev?
with minor disagreement in details, I have received much positive
feedback and therefore moved forward.
> So far so good. That's 1 + 95 + 1
Hi Santiago,
On Sun, Apr 13, 2025 at 01:22:21PM +0200, Santiago Vila wrote:
> After building all the archive (trixie/sid) with nocheck, I only found 33 new
> packages which fail to build with nocheck that were not reported before.
> Admittedly
> a little bit more than I expected, but certainly no
Hi Marco,
On Thu, Apr 10, 2025 at 11:01:24AM +0200, Marco d'Itri wrote:
> On Apr 10, Helmut Grohne wrote:
> > how about libc6-dev stops depending on libcrypt-dev?
> Sure.
Thanks for the feedback.
> > material of course. Also libc6-dev would still "Recommends:
>
Hello fellow developers,
how about libc6-dev stops depending on libcrypt-dev?
I mean for real. We cannot do it right away. The proposal is forky
material of course. Also libc6-dev would still "Recommends:
libcrypt-dev", but libcrypt-dev would no longer be build-essential.
The obvious "why" que
On Sun, Apr 21, 2024 at 05:32:37PM +, Mathias Gibbens wrote:
> I like that idea, thanks! It would be easy enough to add that to
> Incus' $PATH while making it simple for an end user to modify their
> local environment to directly use `mc` if they wish.
Let me express a concern regarding this
On Fri, Mar 07, 2025 at 08:14:00AM -0500, Marvin Renich wrote:
> Are you saying that systemd creates the symlinks at runtime when it
> finds them missing, rather that when the systemd package is installed?
> To me, this is a clear violation of the policy quoted above. "...must
> not install..." sa
Hi Sean,
On Thu, Mar 06, 2025 at 05:39:06PM +0800, Sean Whitton wrote:
> Just to note that the most recent release of Policy sort-of defines
> ownership of this, though it is not as explicit as the TC decision:
>
> Packages must not install files to paths whose first component is a
> name
On Tue, Mar 04, 2025 at 08:39:43PM -0500, Helmut K. C. Tessarek wrote:
> This is my first mail in a Debian mailing list and I hope I've chosen the
> correct one. There are way too many lists thus please direct me to the
> correct one, in case I messed up.
As the matter is intersecting multiple pac
The Debian Technical Committee was asked to rule about a dispute between
the avahi and systemd maintainers in #1091864.
The following resolution was passed. The decision was reached
unanimously meeting the required 3:1 majority requirement for overruling
a maintainer.
=== Resolution ===
The CTTE
Hi Niels,
On Thu, Jan 16, 2025 at 06:36:24PM +0100, Niels Thykier wrote:
> Putting the scripts into `devscripts` package would imply that `devscripts`
> becomes part of the `bootstrap essential` set of packages. I am not sure the
> `devscripts` maintainers are interested in that, because it implie
ed)
* Fallback from nproc to os.cpucount(). (not convinced)
Did I miss anything?
I'm more inclined to drop --detect=python entirely as you say its use is
fairly limited.
> Additionally, the --ignore argument of nproc(1) might be of use for
> this script as well.
Can you give a
e of it and call OOM FTBFS a packaging bug eventually.
Helmut
#!/usr/bin/python3
# Copyright 2024 Helmut Grohne
# SPDX-License-Identifier: GPL-3
import argparse
import itertools
import os
import pathlib
import subprocess
import sys
import typing
def positive_integer(decstr: str) -> int:
Hi Sam,
On Wed, Jan 15, 2025 at 09:43:36AM -0700, Sam Hartman wrote:
> My proposal is to move the man pages into libpam-doc.
> I'm not actually convinced that normal Debian users need man pages for
> all the pam modules on all Debian systems, and a suggests relationship
> should be sufficient.
I'
On Wed, Jan 08, 2025 at 03:21:43PM +0100, Helmut Grohne wrote:
codesearching DEP17.*M18 (and a few other patterns) suggest the
> following packages needing an update:
> * bfh-metapackages
Open #1092955. I first got it wrong and then sent another update.
> * clonezilla
Open #109313
Hi Mo,
before going into criticizing things, I would like to thank you for your
continued work in the AI space. In particular, your way of classifying
models into different degrees of freedom demonstrates how much you care
about Debian's values. I see that your focus is on enabling users and
that'
On Wed, Jan 08, 2025 at 03:21:42PM +0100, Helmut Grohne wrote:
> Since I was failing to get this right earlier, I figured I could as well
> write some tests. As a result, I'm attaching a shell script. It
> constructs a few demo packages and attempts a hopefully exhaustive
> com
Hi Branden,
On Thu, Jan 09, 2025 at 01:41:16PM -0600, G. Branden Robinson wrote:
> > Fundamentally, I assumed that dpkg-divert --rename would only move a
> > file if it was considered installed according to the dpkg database.
> > What really happens is that --rename moves a file as long as it
> >
On Wed, Jan 08, 2025 at 03:21:43PM +0100, Helmut Grohne wrote:
> write some tests. As a result, I'm attaching a shell script. It
A kind soul reminded me of actually attaching something.
Helmut
m18_diversions.sh
Description: Bourne shell script
Hello fellow developers,
I have bad news about /usr-move. The primary mitigation (M18) for
aliased diversions (P3) as implemented by me in quite a few packages is
broken. This was brought to my attention by independent reports of Emil
Södergren and Colin Watson on live-build and debian-installer-u
Hi Adrian,
On Thu, Jan 02, 2025 at 12:03:17PM +0100, John Paul Adrian Glaubitz wrote:
> With both gccrs and rustc_codegen_gcc in the works, I am expecting that this
> problem will be eventually resolved and Rust can be deployed universally like
> C/C++ or other languages supported by GCC.
>
> The
Hi Julian,
On Sat, Dec 28, 2024 at 08:57:18AM +0100, Helmut Grohne wrote:
> As a result, my preliminary conclusion here is to NACK your request
> barring further insight.
I pondered your use case in my head a bit more and am less and less
convinced that build profiles are the right hamm
Hi Ansgar,
On Sun, Dec 29, 2024 at 01:08:49PM +0100, Ansgar 🐱 wrote:
> I'm wondering how we can clean up suites like experimental and
> unstable. They tend to slowly accumulate cruft that nobody cleans up,
> including no longer installable packages.
>
> As a very simple start, I would like to rem
Hi Julian,
On Fri, Dec 20, 2024 at 12:21:37PM +0100, Julian Andres Klode wrote:
> # norust build profile
>
> I propose we add a `norust` build profile such that packages
> building Rust parts or integrating with Rust parts can
> disable those parts.
Thanks for taking this to the appropriate plac
Control: tags -1 + wontfix
Control: close -1
Hi Michael,
On Thu, Dec 26, 2024 at 02:57:12PM -0500, Michael Stone wrote:
> On Thu, Dec 26, 2024 at 09:01:30AM +0100, Helmut Grohne wrote:
> > What other place would be suitable for including this functionality?
>
> As I suggeste
Hi Michael and Pádraig,
On Wed, Dec 25, 2024 at 06:59:28PM +, Pádraig Brady wrote:
> On 25/12/2024 15:24, Michael Stone wrote:
> > There's zero chance I'll carry this as a debian-specific fork of nproc.
> > (Because I don't want to carry any new forks of the core utilities as
> > doing so inev
e of their individual memory
requirements, but turning that into parallelism is presently
inconvenient. This is where I see nproc helping.
On Thu, Dec 05, 2024 at 09:23:24AM +0100, Helmut Grohne wrote:
> How about instead we try to extend coreutils' nproc? How about adding
> more opti
Hi Enrico,
On Fri, Dec 20, 2024 at 07:29:28PM +0100, Enrico Zini wrote:
> Hello,
>
> I'm trying to make a Debian package out of
> https://gitlab.eumetsat.int/open-source/data-tailor-plugins/fcidecomp
>
> I managed to build it this way:
>
> $ cd src/fcidecomp
>
> $ # Build and install fcicomp-j
Hi Michael and Simon,
On Wed, Dec 18, 2024 at 10:16:12PM +0900, Simon Richter wrote:
> Postfix's "master" process effectively implements an orchestrator for a
> microservice architecture, similar to what systemd does. This could be
> replaced by systemd by writing a generator that creates units fr
Hi Ted,
On Thu, Dec 05, 2024 at 01:28:11PM -0500, Theodore Ts'o wrote:
> In the case of e2fsprogs, server and container image *really* don't
> have any need of translations --- and in fact, from my perspective,
> it's often actively harmful, when users send me e2fsck logs in
> Vietnamese and I hav
Hi Guillem and others,
Thanks for your extensive reply and the followup clarifying the
inside-out and outside-in distinction.
On Wed, Dec 04, 2024 at 02:03:29PM +0100, Guillem Jover wrote:
> On Thu, 2024-11-28 at 10:54:37 +0100, Helmut Grohne wrote:
> > I think this demonstrates that we
Hi Paul,
On Thu, Nov 28, 2024 at 02:39:36PM +0100, Paul Gevers wrote:
> On 11/28/24 13:01, Chris Hofstaedtler wrote:
> > IMO it would be good to support dealing with this earlier than
> > later.
>
> And doing it in a way that can be reused by how autopkgtests are run would
> maybe be good too.
C
Hi Guillem and other developers,
I am one of those who builds a lot of different packages with different
requirements and found that picking a good parallel=... value in
DEB_BUILD_OPTIONS is hard. Go too low and your build takes very long. Go
too high and you swap until the OOM killer terminates y
Andrey has already said much of what I could add to the thread, but I
think I can slightly clarify the needs of NMUers.
On Fri, Oct 25, 2024 at 08:45:16AM +0200, Andreas Henriksson wrote:
> I would very much prefer if it was possible in Debian to not allow
> the archive to get out of sync with pac
Hi Sam and others,
On Fri, Jun 28, 2024 at 07:08:20AM -0600, Sam Hartman wrote:
> I'll be honest, I think building a new container backend makes no sense
> at all.
I looked hard at this as it was voiced by many. I have to say, I remain
unconvinced of the arguments brought forward.
> There's a lo
Hi Sebastian,
On Sat, Sep 07, 2024 at 12:12:58AM +0200, Sebastian Andrzej Siewior wrote:
> Is it okay for libssl3 do depend on libbrotli? It would increase minimal
> installs by ~900KiB on amd64.
Thanks for reaching out. From a purely architecture bootstrap centric
view, I approve your request. b
Hi Otto,
On Tue, Aug 20, 2024 at 06:35:52PM -0700, Otto Kekäläinen wrote:
> In short:
> I would very much like to see all top-150 packages run Salsa CI at
> least once before being uploaded to unstable. What people think is a
> reasonable way to proceed to reach this goal?
>
>
> Background:
> We
Hi Johannes and Bastian,
On Tue, Aug 20, 2024 at 10:35:47AM +0200, Bastian Venthur wrote:
> On 20.08.24 07:55, Johannes Schauer Marin Rodrigues wrote:
> > Hi,
> [...]
> > if I remember correctly, a package can also become a key package by having a
> > high-enough popcon value. If that is correct,
Hi fellow developers,
(modified resend, as first attempt didn't arrive)
please allow me to open a can of worms. Package removal from unstable.
Deciding when it is time to remove a package from unstable is difficult.
There may be users still and it is unclear whether keeping the package
imposes a
Hi Philipp,
Let me go into some detail that is tangential to the larger discussion.
On Mon, Jul 01, 2024 at 09:18:19AM +0200, Philipp Kern wrote:
> How well does this setup nest? I had a lot of trouble trying to run the
> unshare backend within an unprivileged container as setup by systemd-nspawn
Hi Simon,
Thanks for having taken the time to do another extensive writeup. Much
appreciated.
On Wed, Jun 26, 2024 at 06:11:09PM +0100, Simon McVittie wrote:
> On Tue, 25 Jun 2024 at 18:55:45 +0200, Helmut Grohne wrote:
> > The main difference to how everyone else does this is that in
Hi Simon,
On Tue, Jun 25, 2024 at 02:02:11PM +0100, Simon McVittie wrote:
> Could we use a container framework that is also used outside the Debian
> bubble, rather than writing our own from first principles every time, and
> ending up with a single-maintainer project being load-bearing for Debian
Hi,
sbuild is our primary tool for constructing a build environment to build
Debian packages. It is used on all buildds and for a long time, the
backend used with sbuild has always been schroot. More recently, a
number of buildds have been moved away from schroot towards
--chroot-mode=unshare than
Hi Laszlo and Yogeswaran,
I'm explicitly adding Laszlo to Cc to increase the chances of him
chiming in.
On Mon, Jun 10, 2024 at 06:40:02PM -0400, Yogeswaran Umasankar wrote:
> There is a file conflict between python3-proto-plus and nanopb. The
> conflict arises due to both packages has a file at
On Mon, Jun 10, 2024 at 04:06:13PM +0500, Andrey Rakhmatullin wrote:
> Do you think it makes sense to add this a flag that enables -Werror=format
> to dpkg-buildflags(1), before, or after a test rebuild, before, or after
> the MBF if we do one?
I think that a test rebuild and the MBF are reasonabl
As many were so happy with the upload of the debootstrap set, we want to
direct your attention to the long tail of the /usr-move transition that
we want to see fixed in trixie: Moving aliased files in all remaining
packages to /usr. More precisely, the transition should be fully
completed in trixie
On Fri, Jun 07, 2024 at 12:19:28AM +0500, Andrey Rakhmatullin wrote:
> We recently increased the time_t size on certain architectures and some
> packages started failing to build because they were using a format
> specifier too narrow for the wider time_t, e.g. #1067829.
> But the only reason those
Hello,
I have just uploaded
* base-files
* bash
* dash
* glibc
* util-linux
to unstable. These were the last remaining packages shipping aliased
files inside the package set relevant to debootstrap.
Once any of these packages has been built until the last of these has
been built, debootstrap
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
On Thu, Feb 29, 2024 at 06:53:56AM +0100, Paul Gevers wrote:
> Well, officially downgrading isn't supported (although it typically works)
> *and* losing files is one of the problems of our merged-/usr solution (see
> [1]). I *suspect* this might be the cause. We're working hard (well, helmut
> is)
Hi cacin,
I see that you are working on merging /bin and /sbin, for instance via
brltty bug #1064785. Again Fedora is pioneering this matter and their
documentation is at
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin.
Please allow me to push back on this one as well by raising a few
c
None of this is relevant to the substvars discussion, but the collectd
side is worth looking at on its own.
On Sat, Feb 24, 2024 at 01:36:33PM +0100, Gioele Barabucci wrote:
> On 24/02/24 11:26, Bernd Zeimetz wrote:
> > Absolutely. collectd for example - otherwise you would install *all*
> > plugi
Hi Andreas,
On Wed, Feb 07, 2024 at 03:47:37PM +0100, Andreas Metzler wrote:
> Package: libselinux1t64
> Replaces: libselinux1
> Provides: libselinux1 (= 3.5-2.1~exp1)
> Breaks: libselinux1 (<< 3.5-2.1~exp1)
>
> Afaiui libselinux1t64 must not fullfill dpkg 1.22.4's dependency on
> "libselinux1 (>
Hi Guillem,
On Wed, Feb 07, 2024 at 04:32:45AM +0100, Guillem Jover wrote:
> Yes, I'm not sure I understand either. This is what symbol versioning
> makes possible, even providing different variants for the same symbol,
> see for example glibc or libbsd.
I think symbol versioning is subtly differ
Package: libselinux1t64
Version: 3.5-2.1~exp1
Severity: grave
X-Debbugs-Cc: vor...@debian.org, debian-devel@lists.debian.org
Hi,
I was looking into performing an upgrade test of libselinux1 with
piuparts and that didn't go well. I spare you the piuparts stuff and go
into crafting a minimal reprod
On Wed, Jan 24, 2024 at 06:30:02PM +, Alberto Garcia wrote:
> - Are packages that ship gobject-introspection files supposed to have
>in the relevant build dependencies (gir1.2-*-dev,
> gobject-introspection ?), or is the build profile handling this
> automatically?
This is not automati
Hi Simon,
On Sun, Jan 21, 2024 at 03:24:25PM +, Simon McVittie wrote:
> > How annoying would it actually be to split this to a
> > different source package?
>
> Really quite annoying. [...]
You gave more than sufficient reason. I won't argue.
> If porters are interested in making bootstrap
On Wed, Jan 17, 2024 at 11:38:09PM +, Simon McVittie wrote:
> On Wed, 17 Jan 2024 at 23:15:03 +0100, Matthias Geiger wrote:
> > Does this mean we should should split out the .gir XML files from existing
> > source packages into a separate gir1.2-foo-dev (in the long run) ?
>
> That's a good qu
On Fri, Jan 05, 2024 at 12:23:00AM -0800, Steve Langasek wrote:
> I am also attaching here the dd-list output for the packages that will need
> to be sourcefully NMUed for the transition, for your review.
I could readily identify a number of packages (incomplete) also affected
by DEP17. Whenever y
On Wed, Jan 03, 2024 at 08:07:53PM +0100, Wouter Verhelst wrote:
> Presumably the reason for this requirement in policy is that without it,
> debootstrap cannot function. That is, debootstrap first unpacks all
> Essential packages, without running any preinst or postinst scripts, and
> *then* runs
Thanks for the feedback. Given the replies, I consider that most people
expect upgrades to be performed with apt (or some apt-using tool).
Upgrades using dpkg (directly) are at least partially unsupported. In
more detail:
On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote:
> ## Opti
Hi Matthew,
On Thu, Dec 21, 2023 at 02:42:56PM +, Matthew Vernon wrote:
> On 21/12/2023 09:41, Helmut Grohne wrote:
>
> > Is it ok to call upgrade scenarios failures that cannot be reproduced
> > using apt unsupported until we no longer deal with aliasing?
Let me thank Da
Hi,
this installment serves a dual purpose. Let me first give an update of
the status quo and then pose a consensus question on how we want to deal
with a particular problem.
I Cc d-release@l.d.o as upgrades are an integral part of releases.
I Cc d-ctte@l.d.o for advisory feedback with experience
Hi developers,
On Fri, Dec 01, 2023 at 10:04:12PM +0100, Helmut Grohne wrote:
> Before we go, let me express sincere thanks to so many people that
> helped me track this down. In particular, the input of David
> Kalnischkies, Guillem Jover and Julian Andres Klode was invaluable.
I
Hi developers,
I have unfortunate news regarding /usr-merge. I uncovered yet another
problem that we haven't seen mentioned earlier. We do not yet know how
to deal with it and it may take some time to come up with a good
compromise. As a result, please pause further moves from / to /usr.
Exception
at 11:27:36AM +0100, Helmut Grohne wrote:
> > I now change focus away from systemd units towards the essential set.
> > This is a tricky affair as it risks breaking bootstrap and the
> > debian-installer. As such, I intend to send patches for affected
> > packages and ha
Hello developers,
yeah, I know, this is annoying to many. Still I hope that we can close
this chapter by trixie with your help.
# What has happened?
Since the unstable buildds have been updated to be merged-/usr, the file
move moratorium has been officially delegated to
https://wiki.debian.org/U
Hi Craig,
On Tue, Nov 14, 2023 at 05:29:01PM +1100, Craig Small wrote:
> Hello,
> For quite some time (since 2006!) there has been a discussion at[1] about
> changing from the sysvinit-utils version of pidof to the procps one. A
> quick scan of the various distributions shows that only Debian an
Hi,
This also is part of the larger /usr-merge + DEP17 context, but it goes
more into the direction of brain storming and request for help, so if
you're short on time, you should probably skip this entirely.
To get us started, let me get some numbers. All of them concern
unstable.
* 1443 source p
Hi Andrea,
On Mon, Oct 09, 2023 at 02:10:27PM +0200, Andrea Bolognani wrote:
> For libvirt, the upstream build system actually installs systemd
> units under /usr/lib, and we move things around in debian/rules so
> that they end up under /lib in the Debian package:
>
> SRV_MONOLITHIC = libvirt-
Hi,
Quite a bit has happened and we're more and more moving from discussion
into action. I'd like to use this opportunity to thank all the invisible
voices who've given me useful feedback. Your private messages, BoF
feedback, and other forms have reached me even if I did not answer all
of them ind
The CTTE has ruled that from trixie onward, maintainers may rely on
systems being merged-/usr. This includes the build environment.
---
modules/schroot/files/setup-dchroot | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
Hi DSA,
would you consider applying the patch to dsa-pupp
Hi,
Quick followup given new insights.
On Sun, Sep 24, 2023 at 05:51:47PM +0200, Helmut Grohne wrote:
> Hi Johannes,
>
> On Sun, Sep 24, 2023 at 10:27:37AM +0200, Johannes Schauer Marin Rodrigues
> wrote:
> > There is really not much magic. The core of it is to pass this to y
Hi Johannes,
On Sun, Sep 24, 2023 at 10:27:37AM +0200, Johannes Schauer Marin Rodrigues
wrote:
> There is really not much magic. The core of it is to pass this to your
> mmdebstrap or debvm-create invocation:
>
> --setup-hook='for f in /etc/apt/sources.list /etc/apt/sources.list.d/*
> /etc/
Hi Ian,
On Sat, Sep 23, 2023 at 11:19:27AM +0100, Ian Jackson wrote:
> To summarise that discussion: at that time the best available solution
> that worked in ci.d.n seemed to be to write an ad-hoc script to run
> the tests in qemu; three packes had done that, each separately, with
> complex scrip
Hi,
On Sat, Sep 16, 2023 at 10:31:20AM +0530, Hideki Yamane wrote:
> Today I want to propose you to change default compression format in .deb,
> {data,control}.tar."xz" to ."zst".
>
> I want to hear your thought about this.
I am not very enthusiastic about this idea. I skip over those argumen
Hi Aurelien,
On Fri, Sep 15, 2023 at 12:02:35AM +0200, Aurelien Jarno wrote:
> Answering for the glibc package.
Thanks.
> On 2023-09-12 20:15, Helmut Grohne wrote:
> > Once the Priority:required set only has that exception set left
> > unconverted, I will prepare patc
Dear maintainers of relevant essential packages,
this /usr-merge transition covering multiple release has reached a point
where consensus has been reached about completing it by moving files
from / to /usr. The chosen approach also affects filesystem bootstrap
and an earlier discussion of this mat
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 arch
Control: forwarded -1
https://salsa.debian.org/debian/debhelper/-/merge_requests/108
Control: tags -1 + patch
On Sun, Aug 20, 2023 at 11:19:56PM +0200, Michael Biebl wrote:
> Related to that:
> dh_installsystemd (and the old, deprecated dh_systemd_enable) currently only
> consider systemd unit fi
Hi,
Yeah, I know we have too many /usr-merge discussions. Still, there is
reason to continue posting. My last summary/status was
https://lists.debian.org/20230712133438.ga935...@subdivi.de from July
12th and I'm giving an update of what happened since then here and
explain how I want to move forwa
Hi,
I fear we are not done with empty directory loss yet. This is a
technical update for future reference.
On Wed, May 31, 2023 at 11:59:58AM +0200, Helmut Grohne wrote:
> On Tue, May 30, 2023 at 11:53:00AM +0200, Helmut Grohne wrote:
> > In effect, this bug report is an instance of a
Hi Holger,
On Fri, Aug 11, 2023 at 09:28:51AM +, Holger Levsen wrote:
> On Fri, Aug 11, 2023 at 09:38:02AM +0100, Luca Boccassi wrote:
> > > This is implemented in
> > > https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/96
>
> what about cdebootstrap?
cdebootstrap (and mm
Hi,
This is picking up on the debootstrap matter and is kinda crucial.
On Thu, Jul 13, 2023 at 01:31:04AM +0100, Luca Boccassi wrote:
> > After having sorted this out, what part of your safety concerns with 3C
> > do remain?
>
> Nothing, as that stemmed from a misunderstanding of what the
> impl
Hi Andreas,
On Sun, Aug 06, 2023 at 06:44:47PM +0200, Andreas Metzler wrote:
> Somehow related: If I introduce a new systemd unit should I work
> around dh_installsystemd and ship it in /usr/lib/systemd/system/?
Doing this is extra work now. If done correctly, it is compatible with
the file move
Hi Wookey,
On Wed, Aug 09, 2023 at 02:30:43PM +0100, Wookey wrote:
> I have never tried Helmut's suggestion of removing this stuff in the
> clean target. It does seem to me that removing it from the tarball
> makes a lot more sense than cleaning it later.
I do see all the advantages of repacking
On Sat, Aug 05, 2023 at 05:29:34PM +0100, Simon McVittie wrote:
> I think it's somewhat inevitable that code paths that aren't frequently
> exercised don't work. If a majority of maintainers are doing all of
> their builds with git-buildpackage, or dgit --clean=git, or something
> basically equival
Hi Sune,
On Tue, Aug 08, 2023 at 06:46:38AM -, Sune Vuorela wrote:
> I don't think this is a important problem that some headers might have
> special conditions for use. I'd rather have our developers spend time
> fixing other issues than satisfying this script.
A while ago, I've performed a
Hi Alexandre,
On Mon, Jul 31, 2023 at 01:37:12PM +0200, Alexandre Detiste wrote:
> [systemd-cron]: after a carefull review, I took a third option:
> these scriptlets belong neither in /lib nor /usr/lib but in /usr/libexec .
>
> This is now implemented this way in the upstream repository.
>
> The
, Helmut Grohne wrote:
> Is this convincing enough to move forward with the generic
> debian...@lists.debian.org usertag fileconflict rather than something
> more detailed? Is this also convincing enough to extend it to cover
> non-file conflicts or do you want a different tag for that
Hi,
On Tue, Jul 25, 2023 at 09:37:35PM +0200, Paul Gevers wrote:
> For ci.d.n, the issue is not money, but the required work to integrate it
> into the infrastructure. We need volunteers (or pay people to do the work),
> but unless they can and want to figure out everything from source [1], the
>
Hi,
TL;DR: dpkg-statoverride detection cannot be automated, but there are
only 5 affected packages.
On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote:
> * DEP17-P5: dpkg-statoverrides not matching the files shipped.
>Possibly, I can extend dumat to cover uncondi
Hi Andreas and Ralf,
On Mon, Jul 17, 2023 at 04:08:48PM +0200, Ralf Treinen wrote:
> > Moving the usertag to the qa namespace sounds like a good idea.
>
> I agree
Thank you
> Sounds like a good idea. However, I do not think that usertags support
> a hierarchy of tags. So maybe different specif
Hi,
On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote:
> ## Usertagging bugs
>
> In order to avoid filing duplicates, I need a usertagging scheme for
> bugs. Are there opinions on what user I should use for this? In the
> simplest instance, I can use my DD login. R
Hi Ted,
On Wed, Jul 12, 2023 at 10:23:08PM -0400, Theodore Ts'o wrote:
> For those packages that are likely to be backported, would ti be
> possible provide some tools so that the package maintainers can make
> it easy to have the debian/rules file detect whetther it is being
> built on a distro v
Hi Luca,
On Thu, Jul 13, 2023 at 01:38:16AM +0100, Luca Boccassi wrote:
> On Wed, 12 Jul 2023 at 14:35, Helmut Grohne wrote:
> > "risky" ones from becoming practically relevant). There is one kind of
> > issue that may be actionable right now and that's the class o
Hi,
I'm doing yet another /usr-merge thread even though we already have too
many, I know.
The first one was about general discussion and problem analysis. In that
first thread, I posted a number of scripts for analyzing problems and
snapshot analysis data. In that second thread, we tried to gathe
Hi Luca,
On Tue, Jul 11, 2023 at 12:27:04AM +0100, Luca Boccassi wrote:
> You have said in the original mail and on the writeup that this option
> requires all the affected packages to be upgraded at the same time,
> and in the correct order, or things will break. What happens if any of
This defi
On Sun, Jul 09, 2023 at 05:58:07PM +0100, Luca Boccassi wrote:
> On top of that, a minimal installation chroot doesn't need a
> fully-featured dhcp client. As Simon said already, busybox is there
> for any reason for a minimal one. For the rest - installer and whatnot
> - the installer and tasklets
edium
+
+ * Non-maintainer upload.
+ * Implement merged-/usr by merging after initial extraction to allow
+shipping the aliasing symlinks in a binary package's data.tar.
+
+ -- Helmut Grohne Sun, 09 Jul 2023 22:13:37 +0200
+
debootstrap (1.0.128+nmu2) unstable; urgency=low
* Non-
1 - 100 of 377 matches
Mail list logo
