Re: Bits from the Release Team: ride like the wind, Bullseye!
On Sun, Aug 18, 2019 at 08:54:21AM +0100, Ian Jackson wrote: > > On 19/08/08 09:46, Paul Gevers wrote: > > > I think we should also try to improve the visibility towards reverse > > > dependencies that their autopkgtest is blocking other packages. I would > > > love tracker (and the old pts) to show this on their page. (Working on > > > such a patch is on my TODO list, except not at the top). > > I already made grep-excuses print this information. It has been very > helpful to me. Maybe we should make --autopkgtests the default ? I think no: --autopkgtests requires quite a bit more computation and connecting to udd and whatnot, I don't think that should be the default. Especially because udd-mirror is starting to be under-dimensioned so it's sometimes quite slow to serve responses (like in the times when its importing a new dump). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On Sun, 18 Aug 2019 at 13:57:58 +0200, Marc Haber wrote: > On Tue, 13 Aug 2019 18:30:51 +0100, Simon McVittie > >bubblewrap and other container-runners often use this when setting > >up containers - for example if you have a Flatpak app installed, try > >something like > > > >flatpak run --command=mount org.gnome.Recipes > > > >and you'll see that the container's /etc is a mixture of read-only > >bind-mounts from the host system and read-only bind-mounts from the > >runtime, some of which are individual files. > > That must be a horrible clutter in mtab though. There are a lot of lines in /proc/$pid/mounts for $pid inside the container, yes. However, bubblewrap and other unprivileged container-runners do not (cannot!) alter the mount table outside the container (they operate in a private mount namespace owned by a private user namespace), so /proc/$pid/mounts for $pid outside the container remains uncluttered. /etc/mtab is recommended to be a symlink to /proc/self/mounts, so it reflects the mount table that is active for the process reading it. In older installations where it was still a regular file, it was updated by mount(8), so in practice it will reflect the mount table that is active for the "init namespace" (the namespaces to which pid 1 belongs). bubblewrap uses mount(2) directly, not mount(8), so it will not alter /etc/mtab if that is a regular file. In any case, I think avoiding "clutter" in the mount table is quite a long way down the list of the most important properties of a system. I would prefer Flatpak to bind-mount in the correct mixture of the runtime's /etc and the host system's /etc to make the app work correctly, however much clutter that might result in. If this clutter offends you, one good way to reduce it is to encourage packages to work correctly with fewer "boilerplate" files in /etc (the same category of changes that results in non-sysadmin-modified D-Bus policy fragments migrating from /etc/dbus-1/system.d to /usr/share/dbus-1/system.d, for example). > We should also have a document containing what we want to have in the > future, such as a comprehensive roadmap. Sorry, I do not have enough Debian time available to write down a comprehensive road map for the teams and packages I'm involved with, never mind the whole project. Any time I spend on writing a road map advocating good ideas is time that I am not spending on implementing those good ideas. For goals confined to a group of closely cooperating packages and maintainers, the way to achieve changes is to just make them. For goals with a wider scope, I think the closest tool we have is release goals. If you want to propose release goals around new technologies in Debian, please do! Debian is mostly a do-ocracy - the people who do the work decide what the work will be - so I don't think anyone really has the authority to write down a road map for the project as a whole and expect developers to follow it. The DPL, release team and technical committee are probably the closest to the positions that could meaningfully define a road map, but even those cannot assign or require developers to work on its contents. smcv
Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On Tue, 13 Aug 2019 18:30:51 +0100, Simon McVittie wrote: >On Tue, 13 Aug 2019 at 14:22:31 +0200, Marc Haber wrote: >> On Tue, 13 Aug 2019 12:01:13 +0100, Simon McVittie >> wrote: >> >(systemd cannot create a mount point that doesn't exist yet on a read-only >> >file system, which is why a zero-byte file is preferred. >> >> but you can bind-mount over a file? I wasn't aware of that. > >Yes, you can bind-mount a directory over another directory, or a >non-directory non-symlink over another non-directory non-symlink. I wasn't aware of that. How neat. >bubblewrap and other container-runners often use this when setting >up containers - for example if you have a Flatpak app installed, try >something like > >flatpak run --command=mount org.gnome.Recipes > >and you'll see that the container's /etc is a mixture of read-only >bind-mounts from the host system and read-only bind-mounts from the >runtime, some of which are individual files. That must be a horrible clutter in mtab though. >> >> >Maybe /etc/machine-id should be part of the "API" of a Debian system in >> >> >general (systemd or not)? >> >> So /etc/machine-id should be in Policy? > >Probably yes, if that proposal has consensus, although a prerequisite >for it being in Policy would be to have an implementation of making it >exist even on systems with neither systemd nor dbus installed (Policy >is meant to document what's true, not what we hope will become true). We should also have a document containing what we want to have in the future, such as a comprehensive roadmap. The absence of leadership in this regard is probably one of the reasons why we have lost so much momentum in adopting new technology. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)
On Sun, 11 Aug 2019 10:49:57 +0200, Vincent Bernat wrote: >systemd cannot guess if a SysV init script should leave a daemon behind >or not. Therefore, they are converted as "Type=forking", "Restart=no" >"GuessMainPID=no" and "RemainAfterExit=yes". So, when a daemon stops >unexpectedly, it is not restarted and "restart" doesn't work because the >unit is still active. Since we have made providing a native systemd service unit optional, did we document this non-negligible shortcoming for both package maintainers and our users? Shouldn't we ask our package maintainers to provide native systemd units to make systemd more useful for our systemd users? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Bits from the Release Team: ride like the wind, Bullseye!
Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team:
ride like the wind, Bullseye!"):
> My personal point of view (and because of this it might be biased)
> is that the maintainers of the packages that ship autopkgtest should
> be the reponsibles for any breackage it might occur on them because:
>
> - They added autopkgtests, so they are showing an intent on
> reviewing them when they fail.
> - They will certainly know their packages better than the library
> maintainer, and thus they have more chances to get the root of the
> issue sooner. Of course that might mean finding a bug in the
> library, but that's just ok.
In the general case the proper investigation of a bug might need
involvement from both people, collaboratively. That involves a kind
of ping pong on a technical level.
> On 19/08/08 09:46, Paul Gevers wrote:
> > I think we should also try to improve the visibility towards reverse
> > dependencies that their autopkgtest is blocking other packages. I would
> > love tracker (and the old pts) to show this on their page. (Working on
> > such a patch is on my TODO list, except not at the top).
I already made grep-excuses print this information. It has been very
helpful to me. Maybe we should make --autopkgtests the default ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
