Re: [MBF] Moving mountnfs.sh script to runlevel 2
Dmitry Bogatov writes: > During resolving issue #551555 of bin:initscripts, I discovered that > solution would be move `mountnfs.sh' initscript into runlevels (2 3 4 5). > > Historically, `mountnfs.sh' was present in runlevel S due the fact, that > bin:initscripts were responsible to mounting /usr. Nowdays, /usr is > mounted by initramfs, so many scripts could be moved from runlevel S to > runlevels (2 3 4 5). > > Issue is that there is number of initscripts in runlevel S, that depends > on $remove_fs, which means /all/ file systems are mounted, not just / > and /usr. > > I ask corresponding maintainers (list at bottom of email) to either > * move their scripts to runlevel (2 3 4 5) [preferred] > * remove dependency on $remote_fs, if all they need is /usr > * replace with dependency on `mountall', if they need >one of (/run /dev/shm /tmp) What will happen on systems where users changed the configuration files and these changes are not applied automatically? Ansgar
Re: Potentially insecure Perl scripts
Russ Allbery writes: > Ben Hutchings writes: >> People have said this about ASLR, protected symlinks, and many other >> kinds of security hardening changes. We made them anyway and took the >> temporary pain for a long-term security gain. > > Well, Perl has a deprecation mechanism with warnings and so forth, > although I don't think Perl has ever actively broken a feature outside of > "use " with a later version, except for features marked as > experimental. But I suppose it's possible. '.' was eventually removed from @INC by default. It also wasn't seen as a security problem when I reported it as such (or not worth fixing at the time), but only years later when someone else reported it again. So maybe awareness changed a bit. But "<>" isn't the only problem, there are way too many uses of the two-argument form of Perl's "open" too... Ansgar
Re: package management symlink
Sören Reinecke writes: >> I'm not convinced that having to remember different package manager >> names is a significant problem for new people adopting a Linux >> distribution. The name is a very small part of the >> differences between >> the package managers (they have very different >> behaviour models, not >> just names), and the package managers are a small part of all the >> differences between distributions. > > Many developers don't provide their software via a repository instead > they provide the source code with an INSTALL file. They depend on > dependencies they resolve through the repositories. Approving "nimue" > just as symlink that points to the package management system across > linux systems would enable them to write just one install script for > debian and red hat systems for example. No, that already stops working when package are named differently which is frequently the case. There is no readline-devel package in Debian and no libreadline-dev in Red Had or Gentoo. Also what you suggest already exists, for example in the form of "pacapt" (but there are alternatives too!). What is the benefit of adding yet another version of these scripts? Ansgar
Re: Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?
On Thu, 2019-02-07 at 09:59 -0500, Michael Stone wrote: > On Thu, Feb 07, 2019 at 02:40:06PM +, Simon McVittie wrote: > > How would this locale differ from C.UTF-8? Is the only difference > > that C.UTF-8 has strict lexicographical sorting, whereas "en" would > > have > > case-insensitive sorting like en_GB.utf8 does? (If that's the only > > difference, then perhaps something like "LANG=C.utf8 > > LC_COLLATE=en_US.utf8" > > is enough.) > > POSIX specifies the output format for various utilities in the C locale, > which defeats my understanding of the purpose of this proposal. So, for > example, in ls -l: I don't think the "C.UTF-8" locale covered by any promises POSIX might make for "C". (Nor is what happens when no LC_*, LANG vairables are set at all.) Ansgar
Re: Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?
Michael Stone writes: > On Thu, Feb 07, 2019 at 09:20:07PM +0100, Ondřej Surý wrote: >>en_DK.UTF-8 is a good default locale? > > I think the suggestion of just "en" made the most sense--specify the > language and an arbitrary set of rules that aren't tied to a specific > country. C.UTF-8 has the default of already existing and always being available. Other locales are not guaranteed to be around (well, except "C"). FWIW systemd will set LANG=C.UTF-8 if no other locale is specified since systemd 240: * When no /etc/locale.conf file exists (and hence no locale settings are in place), systemd will now use the "C.UTF-8" locale by default, and set LANG= to it. This locale is supported by various distributions including Fedora, with clear indications that upstream glibc is going to make it available too. This locale enables UTF-8 mode by default, which appears appropriate for 2018. That seems a reasonable choice and d-i could just use that by not specifying any locale if the user wishes so. (There is a small problem that getty@.service unsets LANG again.) (And you get 24-hour time, but very strange Endian in C.UTF-8: WEEKDAY MMM DD HH:MM:SS TZ while en_US.UTF-8 has at least DD MMM ... Having -MM-DD HH:MM:SS[+] instead would be much nicer if we were to create an arbitrary set of new rules for a new universal "en" locale ;-) ) Ansgar
Re: Removal of linux-base from jessie-backports broke Xen upstream CI
On Wed, 2019-02-13 at 12:46 +, Ian Jackson wrote:
> Alexander Wirt writes ("Re: Removal of linux-base from jessie-backports broke
> Xen upstream CI"):
> > Jessie backports doesn't exist anymore. For some time now. It is already on
> > its way to archive.d.o.
>
> Thanks are due to to folks on #debian-uk who pointed out this
> announcement (from June!) that I missed;
> https://lists.debian.org/debian-backports-announce/2018/07/msg0.html
>
> I have to say I'm not sure this removal is very helpful but then I'm
> not helping maintain -backports so I guess my opinion doesn't carry
> much weight.
More importantly Jessie has reached end-of-life[1]. Please do not
expect related suites (such as -security, -backports, -proposed-
updates, -updates) to continue working after this.
(Related to that: arm64 is gone from jessie-security; arm64 wasn't
removed from -backports as there is no LTS for backports and jessie-
backports will eventually be archived as is.)
Ansgar
[1] https://www.debian.org/News/2018/20180623
Re: Bug#922155: [Pkg-matrix-maintainers] ITP: matrix-archive-keyring -- OpenPGP archive key for the Matrix.org package repository
On Wed, 2019-02-13 at 15:41 +, Linda Lapinlampi wrote: > Template: matrix-archive-keyring/sources.list > Type: boolean > Default: false > _Description: Use APT data sources from Matrix.org? > The Matrix.org Debian package repository distributes supplemental Matrix.org > related packages intended to work with the Debian distribution, but require > software software outside of the distribution to either build or function. > These packages are digitally signed with keys from matrix-archive-keyring. > . > The Debian Project will be unable to directly support issues faced from using > supplemental packages from this third-party repository. Packages from these > APT sources may be non-conforming to the technical requirements set in the > Debian Policy for the Debian distribution. More important is the question if the system should /trust/ the keys. IMHO installing a non-Debian keyring should *not* make the keys trusted by APT by default (i.e. with the default answer if debconf is used). ubuntu-keyring does that; most other keyrings sadly do not follow this. Ansgar
Re: Use of the Build-Conflicts field
Sean Whitton writes: > Use of the Build-Conflicts field is currently mostly optional, but Ian > Jackson and I have been working on text for Debian Policy that would > require its use in certain cases. See #824495 for the discussion. > > There are two cases which we think that everyone would agree that there > is a bug, but we are not sure that the bug would be considered to be RC. > We are posting to -devel to see if, in fact, we do have a consensus that > these bugs would be RC, or not. > > (1) a package FTBFSs when: another package that is part of a "reasonable > standard development workstation install" is present, but the first > package does not declare a Build-Conflicts against the second > > (2) a package FTBFSs when: a package that is NOT part of a "reasonable > standard development workstation install" is present, but the first > package does not declare a Build-Conflicts against the second > > Is (1) an RC-severity bug in the package that FTBFSs? Is (2)? How many packages would be affected by (1) or (2)? I think both are less problematic than the case where the maintainer uploaded a package which has different features than a rebuild on a buildd. That would result in a rebuild (NMUs, next regular upload by someone else or a changed build environment, binNMUs) to change the features available to users. Something we really don't want; note that this could also happen in security or stable updates. (Having Build-Conflicts for the additional features case is probably not implementable with reasonable effort given how autotools and others enable automatic feature-detection by default which isn't really what one wants...) Failing to build in non-standard environments is in contrast a fairly friendly failure mode. So it should not be a serious bug (whether RC or not is something for the release team). > For the purposes of this e-mail, let's assume that we have a good grasp > on what a "reasonable standard development workstation install" means. I doubt we have, but let's ignore that. Ansgar
Re: merged-/usr-via-symlinks vs a-different-layout
Guillem Jover writes:
> 3) Switching packages to the merged-/usr layout could have been
>accomplished automatically via debhelper for a coverage of around
>99% (?) of the archive. With something along the lines of:
>
> ,---
> D=debian/tmp
> for d in /bin /sbin /lib; do
>for p in $(find $D/$d ! -type d); do
> b="${p##$D/}"
> m="$D/usr$b"
> if [ ! -e "$m" ]; then
>mkdir -p "$(dirname $m)"
>mv "$p" "$m"
>ln -s "${m##$D}" "$p"
> fi
>done
> done
> `---
>
>With the property that it would handle gracefully all cases were the
>maintainer has checked that no compat symlinks are required and has
>then progressively moved the pathname installation to their final
>destination under /usr.
That is not merged-/usr, but a different filesystem layout.
So, no, it is not possible to switch packages to merged-/usr this way.
> 4) Due to having to support the broken merged-/usr-via-symlinks
>deployment, when we want to move the contents of the binary
>packages to the merged-/usr layout, we require now to include tons
>of logic in (probably new) maintainer scripts, when we have been
>trying to remove them altogether. :( With even more files untracked
>by dpkg itself, bypassing the packaging system even more, when the
>compat symlinks could have been shipped in the binary packages.
As far as I know maintainer scripts are only required for moving files
from / to /usr when (a) a compat symlink is required, and (b) only when
both merged-/usr and non-merged-/usr is supported.
Ansgar
Re: merged-/usr-via-symlinks vs a-different-layout
Guillem Jover writes:
> On Tue, 2019-02-19 at 08:54:12 +0100, Ansgar wrote:
>> Guillem Jover writes:
>> > 3) Switching packages to the merged-/usr layout could have been
>> >accomplished automatically via debhelper for a coverage of around
>> >99% (?) of the archive. With something along the lines of:
>> >
>> > ,---
>> > D=debian/tmp
>> > for d in /bin /sbin /lib; do
>> >for p in $(find $D/$d ! -type d); do
>> > b="${p##$D/}"
>> > m="$D/usr$b"
>> > if [ ! -e "$m" ]; then
>> >mkdir -p "$(dirname $m)"
>> >mv "$p" "$m"
>> >ln -s "${m##$D}" "$p"
>> > fi
>> >done
>> > done
>> > `---
>> >
>> >With the property that it would handle gracefully all cases were the
>> >maintainer has checked that no compat symlinks are required and has
>> >then progressively moved the pathname installation to their final
>> >destination under /usr.
>>
>> That is not merged-/usr, but a different filesystem layout.
>>
>> So, no, it is not possible to switch packages to merged-/usr this way.
>
> You are still conflating the concept with the deployment. The
> underlaying properties of merging /usr is that the contents for
> directories that are present in both / and /usr get merged into
> /usr.
No, I'm saying that you are proposing yet another different file system
layout. Which is quite simple to see: the file system would differ.
You just claim it follows similar "ideas" in some way.
I can come up with other variations that move files to /usr too: have
/bin a symlink to /usr/root/bin (some for other directories). That
would also be a different file system layout which shouldn't be called
"merged-/usr" either.
(That would have no filesystem aliasing between /bin and /usr/bin;
policy has special rules to allow replacing top-level directories with
symlinks; but besides that it is different for no good reason so I don't
think it would be a good idea.)
> See for example OpenSUSE which did this transition correctly:
>
> <https://en.opensuse.org/openSUSE:Usr_merge>
"The special comments #UsrMerge, #EndUsrMerge will help us to clean up
the spec files once everything has been moved and we can create a
general link from /bin to /usr/bin for example. "
So they want a /bin -> /usr/bin symlink (and the same for the other
directories) just as in the proposal you call broken...
Maybe you have misunderstood what SuSE plans to do?
Having dpkg track a symlink /bin/${something} and a file
/usr/bin/${something} will break should /bin be turned into a symlink
happen. So there is no nice way to finish the transition. I'm not sure
how that would work on RPM; maybe SuSE got stuck with that? That would
be another good reason to not follow that way...
I wouldn't be surprised if that took about as long as the /usr/doc ->
/usr/share/doc transition. (If the change process for most simple
changes like file locations takes 10+ years then I say the process is
broken...)
Ansgar
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
Paul Wise writes: > On Mon, Apr 8, 2019 at 3:34 PM Mo Zhou wrote: > >> However, the translator itself is not trivial, as it might need >> it's own shell parser or something alike to be reliable enough. > > Couldn't you just run makepkg (with some hooks) and dpkg-deb to > convert the results to Debian packages? How should this handle dependencies (probably named differently in Debian) or maintainer scripts? Tools like `alien` to convert RPM and Debian packages have similar limitations and I don't remember them working that well. Ansgar
Re: Discussion on eventual transition away from source packages
Daniel Kahn Gillmor writes: > On Fri 2019-03-22 09:32:55 +0100, Lucas Nussbaum wrote: >> I'm probably missing something, but it doesn't sound like a lot of work >> to me? It's "just" a service that: >> - gets notified of the existence of a git repo + tag to upload >> - fetches that git repo + tag >> - checks signature / confirm that the GPG key owner is allowed to upload >> that package > > In case anyone is considering trying to do this, please be aware that > there are several non-obvious subtleties involved in "verifying a git > tag". Doesn't Git also only use hash algorithms that are no longer recommended for cryptographic applications? Or have they finished moving to stronger algorithms? I don't think we should downgrade to SHA-1 for new services. Ansgar
Re: Preferred git branch structure when upstream moves from tarballs to git
Russell Stuart writes: > On Tue, 2019-04-30 at 09:25 +0800, Paul Wise wrote: >> I like this option because it still works well if we ever decide to >> fix a fundamental flaw in the Debian source package layout. > > I suspect whether that's a fundamentally is a matter or personal taste. > On this point my taste aligns with yours. > > I've used both rpm source format and the Debian one, and IMO the rpm > one is mostly better. The primary reason is the one you've mention > here: they maintain the separation between the source, rpm spec, and > build areas's far more cleanly than Debian does. This makes some > common flaws one often flaws in Debian packages just disappear: like > cleaning up the source directory after a build. I also agree with this. It is also not only RPM, but for example also Gentoo, Arch and others which contain only the distro-specific parts in their repositories. This also makes things easier as developers do not have to know about branch management, merging, rebasing, ... to start with. Many people using Git don't know how to do this. As an example: to update to a new upstream release, I ideally just have to drop the new upstream tarball, update d/changelog and am done. Compare with [1] which is much more complicated, even ignoring the extra complexity using dgit adds compared to just using git. Ansgar [1] https://manpages.debian.org/stretch-backports/dgit/dgit-maint-merge.7.en.html#NEW_UPSTREAM_RELEASES
Re: Preferred git branch structure when upstream moves from tarballs to git
On Thu, 2019-05-02 at 13:45 +0100, Ian Jackson wrote:
> Ansgar Burchardt writes ("Re: Preferred git branch structure when
> upstream moves from tarballs to git"):
> > On Tue, 2019-04-30 at 16:00 -0700, Sean Whitton wrote:
> > > As a package maintainer, if you don't keep the whole source package in
> > > git, you're giving up on a lot of the power of git.
> >
> > I think keeping entry barriers low is more important than being able to
> > use all the power of Git. That's sadly one of the main problems with
> > Dgit: it raises entry barriers by making packaging more complicated.
>
> A source-only upload with dgit is fewer commands, and more reliable,
> than doing so with sbuild/dput.
Complexity is not the number of commands to use.
Having to know about branches, merging, dealing with multiple remotes,
... *is* an entry barrier compared to not having to know about it. Now
you have to teach people that before you even get to how to write a
build recipe.
(Also for source-only uploads you don't need sbuild at all.)
> Doing an NMU campaign with dgit is massively easier than doing so with
> .dsc-based tools.
Why should that be "massively easier" with dgit? Without dgit you get
source, change the source package, build the source package, upload the
modified source package. No matter what workflow/VCS/* the maintainer
uses.
Ansgar
Re: Preferred git branch structure when upstream moves from tarballs to git
On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
> Ansgar writes:
>
> > Having to know about branches, merging, dealing with multiple remotes,
> > ... *is* an entry barrier compared to not having to know about it. Now
> > you have to teach people that before you even get to how to write a
> > build recipe.
>
> I'm confused. I'm a happy user of dgit and don't have to think about any
> of those things as part of using dgit. I choose to use branches, but I
> certainly wouldn't have to, and merging, multiple remotes, and so forth
> don't seem related to using dgit at all.
How do you update the package to a new upstream release?
The "dgit" repository is also separate from the "real" repository; if
you just use "dgit clone ${something}" you won't get the current
"master" branch (unless it happens to be identical to the last
release), or totally different if the maintainer doesn't use dgit.
The history is also strange if you "dgit clone" a repository where the
maintainer used dgit in the past, but no longer does. Now you have a
commit tree with multiple roots which is also confusing for people.
All of this is very uncommon outside the dgit world.
Ansgar
Re: Preferred git branch structure when upstream moves from tarballs to git
On Fri, 2019-05-03 at 15:59 +0100, Ian Jackson wrote:
> Ansgar writes ("Re: Preferred git branch structure when upstream moves from
> tarballs to git"):
> > On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
> > > Ansgar writes:
> > > > Having to know about branches, merging, dealing with multiple remotes,
> > > > ... *is* an entry barrier compared to not having to know about it. Now
> > > > you have to teach people that before you even get to how to write a
> > > > build recipe.
> > >
> > > I'm confused. I'm a happy user of dgit and don't have to think about any
> > > of those things as part of using dgit. I choose to use branches, but I
> > > certainly wouldn't have to, and merging, multiple remotes, and so forth
> > > don't seem related to using dgit at all.
> >
> > How do you update the package to a new upstream release?
>
> The same way you would with whatever tools you are currently using for
> that task. dgit is not a git delta management tool. For the
> maintainer, dgit replaces dput, not gbp pq or git-dpm or quilt.
The question was to illustrate that dgit forces you to learn about
branches, merging, ... There is no workflow with dgit that doesn't
require this; when not using dgit, this isn't required.
Using dgit is a significantly higher entry barrier than not using it; I
wouldn't recommend using it for that reason.
> The "dgit" repository is also separate from the "real" repository;
> > if
> > you just use "dgit clone ${something}" you won't get the current
> > "master" branch (unless it happens to be identical to the last
> > release), or totally different if the maintainer doesn't use dgit.
> >
> > The history is also strange if you "dgit clone" a repository where
> > the
> > maintainer used dgit in the past, but no longer does. Now you have
> > a
> > commit tree with multiple roots which is also confusing for people.
> >
> > All of this is very uncommon outside the dgit world.
>
> If you are trying to get the source code, there is a choice to be
> made.
>
> You can choose to
>
> (1) Get a predictable standardised tree format, which can directly be
> built, cherry-picked, etc.,
>
> And, always have what is actually in the archive.
>
> But maybe an unhelpful history. Especially, if the maintainer
> does not use dgit push.
>
> (dgit clone)
This doesn't give you the real source according to people who state
that "source code" nowadays means the Git repository used by the
maintainer. dgit doesn't differ from apt-get source & gbp import-dsc
there, at least I don't see one.
(This might be different for packages where the maintainer is using
dgit, didn't forget to push and didn't make any changes since the last
upload, i.e. when debcheckout would give the same result.)
> (2) Have an unpredictable (and usually not even specified) tree
> format, which may (and usually will) require use of
> git-workflow-specific tools to even build it.
>
> Have to understand the maintainer's branch structure to try to
> figure out which version corresponds to what is in the archive.
>
> Have the maintainer's history. This is usually in a format
> useful to the maintainer, but it is not standardised. It may be
> the packaging history for a whole packaging ecosystem. It may be
> a linear history of a gbp pq branch. It may be a git-dpm history
> containing multiple rebases of the same patch series.
>
> (debcheckout)
It has the advantage of having the history if one cares about it. Why
would one not prefer that over the result of importing the .dsc
somewhere?
Maybe dgit is useful for some people to maintain their packages in Git;
but it's not helpful for packages where the maintainer is using it and
some complications are just not a good idea IMHO (like using a separate
Git repository with potentially different contents and not warning
users when fabricating history different from the real VCS history).
Ansgar
Re: Preferred git branch structure when upstream moves from tarballs to git
On Fri, 2019-05-03 at 17:39 +0100, Ian Jackson wrote:
> Ansgar writes ("Re: Preferred git branch structure when upstream
> moves from tarballs to git"):
> > On Fri, 2019-05-03 at 15:59 +0100, Ian Jackson wrote:
> > > Ansgar writes ("Re: Preferred git branch structure when upstream
> > > moves from tarballs to git"):
> > > > How do you update the package to a new upstream release?
> > >
> > > The same way you would with whatever tools you are currently
> > > using for
> > > that task. dgit is not a git delta management tool. For the
> > > maintainer, dgit replaces dput, not gbp pq or git-dpm or quilt.
> >
> > The question was to illustrate that dgit forces you to learn about
> > branches, merging, ... There is no workflow with dgit that doesn't
> > require this; when not using dgit, this isn't required.
>
> This is so wrong it is very perplexing to me.
Yet you confirm exactly what I am saying...
> This does not work right now with dgit because I have not taught dgit
> how to convert such a thing into a git tree that contains the actual
> source code.
I'm not talking about a hypothetical, different version of dgit which
might have a different set of features. Anything is possible for such
a hypothetical version.
> Using dgit is a significantly higher entry barrier than not using
> > it;
>
> Using dgit is a much lower entry barrier if you already know git, and
> don't know about Debian source packages. Like most people nowadays.
I know plenty of people who more or less only know git commit, push and
pull. Nothing more advanced.
> Using dgit is only a higher entry barrier if (i) you aren't
> comfortable with "intermediate" use of git (ii) you are already an
> expert on dpkg-source, quilt, etc.
Thank you for confirming that dgit raises entry barriers. I still
believe that is opposite of what distributions should do, see the
popularity of AUR or similar projects.
> Any maintainer who feels (as I often do) that the preferred form for
> modification of their package includes the full git history, should
> already be using dgit, since how else can they always discoverably
> publish the complete corresponding source ?
There is this fancy Vcs-Git field. Simple to discover.
Now, if dgit could just use that repository...
> [1] Possibly the user will get the maintainer's git history plus some
> autogenerated dgit conversion commits. For example, for a package
> whose maintainer uses gbp pq, the user gets a thing that has many
> similarities to the gbp pq patch queue branch. In particular, the
> patches are applied, each as a git commit in the user's history.
And then has to take care to not push those artificial commits
somewhere if that is not the preferred workflow... That seems rather
backwards to me.
Ansgar
Re: Preferred git branch structure when upstream moves from tarballs to git
Sam Hartman writes: > I'm having a bit of trouble here and am hoping you can help us out. > Ian asked what git workflow it is that you're talking about where people > can deal with commit push and pull and don't need to know more. > > I didn't see a clear answer to that. > Which debian packaging workflow do you believe has that property? There is no need for a vendor branch if only the packaging information is kept in the repository, i.e. only debian/. In particular there is no need for branches or merges for regular updates (i.e. not based on an older release). This is also what pretty much every other distribution seems to be doing, for example Fedora, Gentoo, Ports (BSD), Arch Linux, Void Linux. It would be easier if there was even more separation between packaging and upstream source, e.g. base/src (upstream source), base/debian (packaging information), and possibly other directories below base for build artifacts (instead of unpredictable locations under base/debian). Which leads back to the beginning of the subthread[1]. [1] https://lists.debian.org/debian-devel/2019/04/msg00462.html Ansgar
Re: Preferred git branch structure when upstream moves from tarballs to git
On Tue, 2019-05-07 at 12:51 +0100, Ian Jackson wrote:
> Ansgar Burchardt writes ("Re: Preferred git branch structure when
> upstream moves from tarballs to git"):
> > Sam Hartman writes:
> > > OK, I didn't hear that as an answer but think I'm coming to the
> > > same
> > > conclusion that Ian did after reading your mail.
> > > It sounds like you are talking about having the Debian packaging
> > > in a
> > > separate repository from upstream.
> > > Do I correctly understand the model you are talking about?
> ...
> > I'll point to [1] for what complexity this avoids. Try explaining
> > that
> > to someone without advanced Git knowledge...
> >
> > [1]
> > https://manpages.debian.org/unstable/git-debrebase/git-debrebase.5.en.html
[...]
> In this message you are using the fact that I have written a
> comprehensive data model specification, against me. This is a
> seriously bad thing to do.
>
I think you underestimate how much knowledge you require from users
right from the beginning...
So in a way the problem is that the documentation needs to exist. git-
debrebase or dgit (to a lesser extend) implement a Debian-specific
version control system on top of Git. git-debrebase makes this most
obvious: the Git history it generates is pretty much unlike anything
you would ever get from regular Git usage (counterexamples welcome), it
mangles your Git commits into a specific format it expects
(laundering), mangles rebased branches into fast-forward merges with
pseudomerges; all this does not happen in regular Git usage.
dgit has less of these problems, but still does things different from
regular git usage (again pseudomerges to make rebases fast-forward for
example); there are other issues as well such as its suggested use for
NMUs feeling rather unfriendly as it moves the packaging to another VCS
than the maintainer uses with a disjoint history...
Sure, dealing with patch series is not nice either way, but I don't
think the added complexity of git-debrebase (or dgit) is worth what it
provides. Alternatives require less intimiate knowledge of git and
provide a gentler learning curve; some basic patch queue manipulation
even doesn't require special tools at all (adding/removing patches that
already exist in the right format and apply).
Other distributions have intentionally be trying to move to less
distro-specific tools to reduce barrier of entry; dgit and git-
debrebase both move in the opposite direction (more highly distro-
specific tools).
> You should be applauding me for providing serious documentation for
> advanced users.
According to git-debrebase(1) the documentation I referred to is basic
documentation:
> You should read this manpage in cojnunction with "TERMINOLOGY" in
> git-debrebase(5), which defines many important terms used here.
"TERMINOLOGY" then refers to most other sections.
> The obvious counter is the (still comprehensive, but user-facing)
> tutorial manpage. For example,
>
> https://manpages.debian.org/stretch-backports/dgit/dgit-maint-debrebase.7.en.html#EDITING_THE_DEBIAN_PACKAGING
> et seq.
It illustrates my other main gripe with dgit/git-debrebase: it makes it
harder to share in-progress work, in fact git-debrebase discourages
people from doing so:
| Note that each time you conclude a debrebase you introduce a
| pseudomerge into your git history, which may make it harder to read.
| A simple convention you can use to minimise the number of
| pseudomerges is to git debrebase conclude only right before you
| upload or push to salsa.debian.org.
Yes, one can avoid some of the problems by pushing a non-fast-forward,
non-interchange branch. But that differs from the regular workflow
and, again, requires more advanced Git knowledge.
> An equivalently detailed and frank document about dpkg-source would
> be a nightmare.
The concept behind 3.0 (quilt) is much easier to explain: extract
tarballs, optionally apply some patches provided. With the bonus that
users who have used other distributions before might already know about
most of this which lowers barrier of entry. Implementation details
like constructing a .dsc are indeed messy.
With most other Debian packaging workflows one can also limit oneself
to more basic Git commands for regular usage, in the most minimalistic
case only commit/push/pull (not even merge); these also match what
users will know if they have used Git at all (be it for packaging in
other distribution, upstream projects, or even just writing their
thesis).
You might say that git-debrebase is not required, but what about users
that want to contribute to a package maintained using it? They will
have to deal with the complexity... This also differs from other
packaging workflows that usually don't make specific tools mandatory.
(Not all tools can always be made optional of course, but one should do
some consideration if one makes new tools mandatory.)
Ansgar
Re: .deb format: let's use 0.939, zstd, drop bzip2
Adam Borowski writes: > I've recently did some research on how can we improve the speed of unpacking > packages. There's a lot of other stages that can be improved, but let's > talk about the .deb format. > > First, the 0.939 format, as described in "man deb-old". While still being > accepted by dpkg, it had been superseded before even the very first stable > release. Why? It has at least two upsides over 2.0: Switching to a different binary format will break various tools. If we want to do this, I wonder if we shouldn't take the chance to move away from tar? We have various applications that only want to extract single members of the package (changelog, NEWS, copyright, ...); tar is a really bad format for such an operation. Other formats (zip, 7z, ...) are more suited for them. Ansgar
Re: .deb format: let's use 0.939, zstd, drop bzip2
Jeremy Stanley writes: > On 2019-05-08 22:35:58 +0200 (+0200), Ansgar wrote: >> Switching to a different binary format will break various tools. If we >> want to do this, I wonder if we shouldn't take the chance to move away >> from tar? >> >> We have various applications that only want to extract single members of >> the package (changelog, NEWS, copyright, ...); tar is a really bad >> format for such an operation. Other formats (zip, 7z, ...) are more >> suited for them. > > Are you talking about source packages or binary packages here? The > latter use ar, not tar. I'm talking about binary packages (*.deb). They currently use tar archives (control.tar.*, data.tar.*) packed in an ar archive. Ansgar
Re: .deb format: let's use 0.939, zstd, drop bzip2
Adam Borowski writes: > On Wed, May 08, 2019 at 10:35:58PM +0200, Ansgar wrote: >> Adam Borowski writes: >> > I've recently did some research on how can we improve the speed of >> > unpacking >> > packages. There's a lot of other stages that can be improved, but let's >> > talk about the .deb format. >> > >> > First, the 0.939 format, as described in "man deb-old". While still being >> > accepted by dpkg, it had been superseded before even the very first stable >> > release. Why? It has at least two upsides over 2.0: >> >> Switching to a different binary format will break various tools. > > The 0.939 format is already supported by most tools. > > No one sane digs into insides of the format, using a small number of > low-level tools, thus we can reuse it with little effort. > > Of course, adding a new compressor _does_ break compat, but we added four > compressors to 2.0 over the years already, and the sky didn't fall. Well, it causes minor breakage which is fairly easy to fix. A different container format instead of tar would require more involved changes in tools, so I'm not 100% convinced of my idea myself ;-) The thread just looked like the right time to consider such changes. >> If we want to do this, I wonder if we shouldn't take the chance to move >> away from tar? > > Any seekable format significantly reduces compression, although this can > be reduced by managing split points. Well, depending on how much splitting you do, the loss in compression should be small enough to not care about? >> We have various applications that only want to extract single members of >> the package (changelog, NEWS, copyright, ...); tar is a really bad >> format for such an operation. Other formats (zip, 7z, ...) are more >> suited for them. > > Perhaps such files could be considered metadata and moved to the control > tarball? Or merely just moved forward -- remember that tarballs are > unordered. I don't think that is a good idea: if someone wants to use another file in a similar way, he couldn't and would have to fall back to the worse solution. As an example: I have a config-diff script which compares conffiles with the pristine version included in the *.deb; it wants to access /etc/*. (Though ideally dpkg would keep the pristine version accessible below /usr; that would also be useful for other uses.) Also dpkg keeps metadata in /var, but changelogs, NEWS, copyright documentation isn't variable state data and should be below /usr... The same is really true for lists of files and maintainer scripts though. Ansgar
Re: Preferred git branch structure when upstream moves from tarballs to git
On Thu, 2019-05-09 at 10:33 +0100, Ian Campbell wrote:
> On Thu, 2019-05-09 at 11:19 +1000, Ben Finney wrote:
> > What I remain unconvinced of is the worth of abandoning the clean
> > separation between an upstream source repository (whether Git repository
> > or not) and a VCS repository for Debian packaging (typically in Git).
>
> I think there's a common misconception here which has cropped up
> several times in this thread. (NB: I've not used dgit in anger yet, but
> I hope what follows is correct).
>
> That misconception is that "dgit repo" == "maintainer's repo", which is
> not actually the case. As a maintainer you can (if you want) just use
> "dgit push" (instead of dput) while only caring about (and interacting
> with) the "maintainer's repo", never touching or looking at dgit's view
> of the world (apart from perhaps noticing and ignoring some `dgit/*`
> branches in your _local_ repo, I don't beleive you are required to push
> those to anywhere, including your maintainer repo).
I think that is very confusing, yes.
By now I have come to understand that whatever "dgit" produces should
be just regarded as a build artifact, just like binary packages or for
some people the .dsc or for some workflows debian/patches/*.
Though directing users to build artifacts when they request the source
seems counterproductive to me...
I wonder why not the "maintainer view" is published (for the part
making Git repositories "reliably locatable") and any mangling is
applied by "dgit clone" (instead of "dgit push")? ("dgit push" can
check that the mangling works.)
Then whatever is published is what is the actual preferred form of
modification (as it is what the maintainer uses), but if so desired one
can still get a "dgit view". (Though for contributing changes to the
maintainer, one should probably base them on the maintainer view...)
In this case the published history also matches the "git histories we
are actually using ourselves", a design goal not met currently; one
could also apply the mangling feature to repositories not published on
the dgit server.
Ansgar
Re: .deb format: let's use 0.939, zstd, drop bzip2
On Thu, 2019-05-09 at 12:32 +, Jeremy Stanley wrote: > On 2019-05-09 06:27:36 +0900 (+0900), Mike Hommey wrote: > > On Wed, May 08, 2019 at 09:04:49PM +, Jeremy Stanley wrote: > [...] > > > Are you talking about source packages or binary packages here? > > > The > > > latter use ar, not tar. > > > > Binary packages use both. > > > > $ ar t /var/cache/apt/archives/libgcc-9-dev_9.1.0-1_amd64.deb > > debian-binary > > control.tar.xz > > data.tar.xz > > Ahh, yes, thanks I should have remembered that... so then my > question becomes: is the suggestion to replace *both* ar and tar in > the binary package format with a single flat archive, or to switch > out the tarballs inside the ar archive but continue using ar to > aggregate them? `ar` needs to be replaced for the file size limitation mentioned in the initial mail: ar represents file size as a 10 digit decimal number[1] which limits the members (control.tar.*, data.tar.*) to ~10G. [1] https://en.wikipedia.org/wiki/Ar_(Unix)#File_header Replacing `ar` is an incompatible format change. So if we already do an incompatible change, it is an appropriate time to bundle any other incompatible changes (if there are any). That is why I suggested that it might be useful to also replace the `tar` archives with another format. Ansgar
Re: .deb format: let's use 0.939, zstd, drop bzip2
On Fri, 2019-05-10 at 11:04 +0200, Thomas Goirand wrote:
> On 5/9/19 6:25 PM, Andrej Shadura wrote:
> > How about the format opkg used for some time, which is a .deb file
> > but
> > with tar as the outer container format instead of ar?
>
> This is a very bad idea. When installing a large amount of packages,
> apt
> needs to uncompress all control.tar.gz files so it can get the config
> and templates of debconf. With tar, meaning without an index, one may
> need to uncompress the whole of the .deb file in order to extract
> just a
> tiny portion of it. This could potentially be super long (think: a
> dist-upgrade with so many packages...).
The outer container would probably be uncompressed; as it has only very
few members (dummy file, control.tar.*, data.tar.*, ${something-new}),
accessing any of these few members is fast (as you can just seek from
one header to the next and only need to do so few times).
Ansgar
Re: .deb format: let's use 0.939, zstd, drop bzip2
Hi Adam, On Fri, 2019-05-10 at 16:11 +0200, Adam Borowski wrote: > /usr on the box I'm sitting at: > * zip the program: dies horribly due to /usr/lib/llvm-7/build/ > symlink > loops. > * zip: > 1891345142 bytes > * zip-the-concept (individually compressed files), xz > 1516943024 bytes > * tar.xz > 1092591508 bytes > > Linux source: > * zip: > 213820843 bytes > * individually compressed files, xz > 180997203 bytes > * tar.xz: > 104318396 bytes > > So no, I don't want zip, nor even a randomly accessible format. Could you also try 7z? It supports solid compression[1] which compresses multiple files into one block like tar.xz, but unlike tar.xz can use more than one block: "Later versions of 7-zip use a variable solid block size, so that only a limited amount of data must be processed in order to extract one file". So it would provide somewhat random access and still offer better compression than zip or other forms of individually compressed files. It would be interesting if you could also include the access time for extracting only the last member of the archive; though for 7z one would need to check if it does the right thing first... Ansgar [1] https://en.wikipedia.org/wiki/Solid_compression
Re: .deb format: let's use 0.939, zstd, drop bzip2
Adam Borowski writes: > On Mon, May 13, 2019 at 11:25:11AM +0200, Ansgar wrote: >> It supports solid compression[1] which >> compresses multiple files into one block like tar.xz, but unlike tar.xz >> can use more than one block: "Later versions of 7-zip use a variable >> solid block size, so that only a limited amount of data must be >> processed in order to extract one file". > > Yeah but the default block size is 2GB, which would make every single .deb > in the archive effectively fully solid. You can fine-tune the values, but > example numbers don't appear like they'd help much. > > And just tested, -ms=on vs -ms=16m: > -rw-r--r-- 1 kilobyte kilobyte 1087957645 May 13 14:37 u.7z > -rw-r--r-- 1 kilobyte kilobyte 1253369019 May 13 14:50 u16m.7z > > So the space loss is massive. That indeed looks like it likely not worth switching to a different format to allow better random access (which is more of a special-use case anyway). Thank you for your experiments! Ansgar
Re: ZFS in Buster
Ian Jackson writes: >> > Would it be possible to provide an alternative patched linux kernel >> > that works with ZFS? > > I think this would be both unwise legally (without seeking additional > legal advice) and rather rude to the kernel upstream whose code is > then being reused without permission - indeed, contrary to their > explicitly stated intent. At least one commercial distribution (Ubuntu) has been distributing ZFS binary modules as part of their Linux packages for some years and didn't have any problems. Debian doesn't provide prebuilt binary modules for out-of-tree modules mostly to not have to care about them when the Linux ABI changes as happens in many updates (including security/stable updates). (Ubuntu avoids that by using `wget` to get the source for out-of-tree modules like ZFS when building their src:linux package, something Debian would probably not like that much...) Ansgar
Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices)
On Wed, 2019-05-29 at 10:38 +0200, Raphael Hertzog wrote:
> On Wed, 29 May 2019, Andrey Rahmatullin wrote:
> > One of the popular answers to this and some other problems is "nobody sat
> > down and wrote the code". Not sure what can we do about this class of
> > reasons.
>
> Use the $300,000 on our bank accounts?
I heard that this didn't work out well the last time ("dunc tank"),
though that was before the time I followed Debian development.
Ansgar
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
Aurelien Jarno writes: > kfreebsd-amd64 and kfreebsd-i386 have now been moved to debian-ports. As > hurd-i386 has been moved earlier, it means that all the 3 architectures > have now been moved. I removed kfreebsd-* and hurd-i386 from ftp-master's unstable and experimental suites yesterday. The move should be completed with this. Ansgar
getting rid of "testing"
Hi,
what do people think about getting rid of current suite names ("stable",
"testing", "unstable") for most purposes? We already recommend using
codenames instead as those don't change their meaning when a new release
happens.
Related to that I would like to be able to write something like
deb http://deb.debian.org/debian debian11 main
deb http://security.debian.org/debian-security debian11-security main
in sources.list as codenames confuse people.
Ubuntu already has no suite names, only codenames, but having to map
"Ubuntu 18.04" to "bionic" instead of just writing the version in
sources.list is annoying (I always have to look up the codename to be
sure as I don't use Ubuntu that much).
Ansgar
Re: Content Rating System in Debian
Hi, On Tue, 2019-06-25 at 11:40 +0700, Bagas Sanjaya wrote: > Based on above, what are your opinions/thoughts/positions about > Content Rating System in Debian? is this related to your other proposal involving giving "sudo" permissions to teenagers to handle this age recommendation stuff for TV programs? | In fact, many television stations have most programs written for | teens (age 13 and older), so sysadmins there configure sudoers which | allows teens to behave like sysadmins themselves (by giving them full | administrator privileges) on their production systems. Also, parental | monitoring and guidance can reduce likehood of teens breaking such | systems. Maybe because teens are largest marketshare for TVs. Ansgar - rating "kill -KILL" X-rated for extreme violence
Re: getting rid of "testing"
On Tue, 2019-06-25 at 16:39 +0800, Paul Wise wrote:
> On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote:
> > what do people think about getting rid of current suite names ("stable",
> > "testing", "unstable") for most purposes? We already recommend using
> > codenames instead as those don't change their meaning when a new release
> > happens.
>
> I use these (testing, etc) so getting rid of them would be annoying.
The "stable" suite names are more annoying than
unstable/testing/experimental as they require updates to suites at
release time that are not related to the release. That shouldn't be
necessary.
For "testing", "unstable" one could probably introduce some `Alias`
field in Release, but I also like minimalist solutions (which already
seem to work well for Ubuntu).
> > Related to that I would like to be able to write something like
> >
> > deb http://deb.debian.org/debian debian11 main
>
> Already kind of possible:
>
> deb http://deb.debian.org/debian Debian9.9 main
Yes, but it gives warnings for issues that I believe should be an error
instead. (And currently a good reason for TLS to talk to mirros so a
MitM that is not a mirror operator cannot give you oldstable when you
want to use unstable.)
debootstrap gives an error for this:
+---
| $ /sbin/debootstrap --print-debs Debian9.9 . http://ftp.de.debian.org/debian
unstable
| [...]
| E: Asked to install suite Debian9.9, but got stable (codename: stretch) from
mirror
+---
As Adam already pointed out having the point release in there also
makes "Debian9.9" rather unhelpful.
> > Ubuntu already has no suite names, only codenames, but having to map
> > "Ubuntu 18.04" to "bionic" instead of just writing the version in
> > sources.list is annoying (I always have to look up the codename to be
> > sure as I don't use Ubuntu that much).
>
> They do have the 'devel' suite, but it is not a proper one:
>
> https://bugs.launchpad.net/ubuntu/+bug/1821272
That is what Debian9.9 (and similar) are currently as well.
Ansgar
Re: git & Debian packaging sprint report
Sean Whitton writes: > On Fri 12 Jul 2019 at 02:06PM +02, Ansgar wrote: >> Depends on a lot of things. As far as I understand this work is in a >> very early stage and a first brainstorming session on what problem this >> is intended to solve, why one should consider doing it, and possible >> requirements is planned for DebConf[1]. >> >> Without having any of these, it is hard to comment on anything. > > Figuring out how this is going to be deployed as Debian infrastructure > is indeed at an early stage. > > I don't think it is accurate to think of the whole project as being at > an early stage. From my perspective, the hardest problem to solve was > conversion of git trees to uploads, on the server side, in a way that is > user friendly. We take ourselves to have solved that problem, which to > my mind renders this project beyond the early stages of development. What is the DebConf BOF then for? It says it is "a requirements collecting BOF for that [git push] discussion"? Ansgar
Re: Debian and our frenemies of containers and userland repos
Marc Haber writes: > Compared to a full VM, a container _is_ smaller. I am not sure whether > the difference is as huge in times where we have kernel same-page > merging though. > > Do we have a build technology that uses containers instead of chroots > yet? I haven't used it so far, but at least "whalebuilder" exists. The gitlab-ci used on salsa.d.o also uses Docker containers; people also build packages using this (mostly for testing though, see for example [1]). Ansgar [1] https://salsa.debian.org/salsa-ci-team/pipeline
Re: tag2upload (git-debpush) service architecture - draft
Bernd Zeimetz writes: > On 7/27/19 8:16 PM, Rebecca N. Palmer wrote:> As a way to avoid relying > on SHA-1, would it work to have git-debpush >> include a longer hash in the tag message, and tag2upload also verify >> that hash? >> > The other idea would be to convince git upstream to use something > better than sha1 - and after a bit of searching, I found [...] > So I think the best thing to do is to get sha256 working in git and > force the usage of sha256 if you want to sign a tag for upload. That will take quite a while; we would probably need a version of git supporting that in stable. There are also other issues, for example: - Such a service would bypass various sanity checks on the archive side, including various permission checks. - Such a service would need to properly validate the PGP signature. The archive really shouldn't rely on a third-party service for this. (In particular the service in question here doesn't do that as far as I can tell.) Ansgar
Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)
Alf Gaida writes: > We need sysvinit for some non-linux things No: Hurd existed for a long time without using sysvinit/sysv-rc. I think sysvinit was only ported to Hurd in 2013 or 2014 (I didn't search much, but found a Summer of Code application from 2013 for this). Having sysvinit might make things a bit easier for Hurd/kFreeBSD, but it's not an absolute requirement for such a port to exist. Ansgar
Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports
"Theodore Y. Ts'o" writes: > On Wed, Aug 21, 2019 at 10:03:01AM +0100, Luke Kenneth Casson Leighton wrote: >> so i hope that list gives a bit more context as to how serious the >> consequences of dropping 32 bit support really is. > > I very much doubt we are any where near "dropping 32-bit support". > There's a lot of "all or nothing thinking" in your argumentation > style. The topic of this very thread is how to avoid dropping support for 32bit architectures. So people clearly want to continue supporting it. > As Sam has said multiple times, what's much more likely is that the > set of packages that can't be built on native packages on 32-bit > platforms will grow over time. The question is when will that > actually *matter*? There are many of these packages which no one > would want to run on a 32-bit platform, especially if we're focusing > on the embedded use case. It might matter pretty soon: for generic-purpose systems one almost always want to be able to use a web browser; even various embedded systems do. However web browsers are one of the most heavy packages to build. > At least initially, the simplest way of dealing with the problem is > that maintainers will simply not build their package on 32-bit > platforms. I don't think we want this to happen if we want to continue supporting 32bit systems. But using a 64bit toolchain in an otherwise 32bit userland as the thread suggests we now really should start looking at will avoid this. It will probably take a few more years until we have to worry about being able to run browsers in 32bit... But I would hope that most people understand that using 32bit for new generic-purpose systems is not future-proof (and hasn't been for a while); even phones have started to move to 64bit systems a while ago. Ansgar
Re: Proposed build profile: noinsttests
Simon McVittie writes:
> The name of the profile
> ---
>
> The "noinsttests" name is inspired by previous discussion (on a bug
> asking for more in some package, if I remember correctly?),
> and by ginsttest-runner in the gnome-desktop-testing package[1], which
> is a test-runner for GNOME's installed-tests initiative.
>
> If people strongly prefer build profiles to be singular, then "noinsttest"
> would also be fine.
>
> The conventional names for the build-time options that enable/disable
> GNOME installed-tests are --{en,dis}able-installed-tests (Autotools) and
> -Dinstalled_tests={true,false} (Meson), but I think "no-installed-tests"
> or "no-as-installed-tests", or a version of one of those names with
> words run together, would be inconveniently long for a build-profile.
I think a name without abbreviations like "no-installed-tests" is
better. While it is clear what the name means for people working with
build profiles all the time, a more expressive name might be easier on
people only dealing with them occasionally.
Ansgar
Re: Git Packaging: Native source formats
Sam Hartman writes: > * One is that you're not using upstream tarballs. If upstream has > tarballs they produce, we're not using them. I guess we may end up > having that part of the conversation now rather than later. > > It's clear that we value integrity of upstream source. That is we > want to make it easy for people to start from some upstream source > that is trusted because upstream has produced it and audit just our > changes. > One way to do this is with an upstream tarball and a diff (or set of > diffs or a debian directory). There are a few other projects consuming upstream tarballs from Debian's archive. I've seen source-based distributions (portage, pkgsrc) using tarballs from there. It would be friendly to not break this for them if we can avoid doing so without too much cost. Upstream tarballs are probably also the easiest way for upstream to provide a signed version of their software which we have tried to encourage (for example by including such signatures in Debian's archive). Ansgar
Re: Git Packaging Round 2: When to Salsa mirror
Geert Stappers writes: > On Sun, Sep 08, 2019 at 10:05:17PM -0700, Russ Allbery wrote: >> Higher chance that the repository won't go away. > > Where is Alioth? As retoric question. The repositories on Alioth weren't lost and can still be found archived on https://alioth-archive.debian.org/ > What about Vcs-Mirror-* for actual telling where a mirror is. > In case of `git` is "mirror" a "clone" Arguably in Git everything but the maintainer's local repository might be a mirror. This was even called a security feature as hash collisions might need to be sneaked in there to get included in release tarballs[1]. Ansgar [1] https://public-inbox.org/git/pine.lnx.4.58.0504291221250.18...@ppc970.osdl.org/
Re: Git Packaging Round 2: When to Salsa
Sam Hartman writes: > If you are a Debian Developer packaging a package for inclusion in > Debian, you should store your packaging information in one repository > per package on salsa.debian.org in the debian group. That is you should > create a repository under https://salsa.debian.org/debian . This allows everyone to do arbitrary changes and presumably upload the package. That is quite a large change that I'm not sure everyone likes. +--- | Direct commits to repositories in the Debian group by any Debian | developer are implicitly welcome. No pre-commit coordination | (e.g. merge-request or mail) is expected. +---[ https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group ] Ansgar
Re: Git Packaging Round 2: When to Salsa
On Thu, 2019-09-12 at 08:14 -0400, Sam Hartman wrote: > Ian> 1. The maintainer's git repository branch format must be > Ian> documented. Otherwise another contributor has to guess. This > Ian> could be done either by doing maintainer uploads with dgit > Ian> (since recent versions of dgit include the maintainer branch > Ian> format information in the git tags), or perhaps by writing > Ian> something in README.source. > > Makes sense. > My take is discussion on debian-devel strongly supports making it easier > to figure out what branch format people are using. I don't see much value in this requirement (besides additional work). One should look at the repository anyway whan planning to do changes (to match the existing style used); one would naturally see how files are organized. We already had tons of packages shipping a README.source stating "this packages uses quilt, ..." before which I also didn't find very valuable; this seems pretty similar. If dgit provides a program to figure this out, people interested in obtaining the information automatically can just extract and use that. (Using dgit to upload packages is sadly incompatible with best practices around packaging.) Ansgar
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
Adam Borowski writes: > On Tue, Sep 10, 2019 at 07:46:57PM +0200, Marco d'Itri wrote: >> Well, no. They cannot without significantly more expensive hardware to >> do DPI and a *totally different* legislative framework. >> (Source: I have been dealing with government-mandated censorship in >> Italy for ~15 years, both at technical and policy levels.) > > I don't understand how blocking by IP would be any more expensive than > blocking by DNS. It's _cheaper_: you read a field in the IP header instead > of doing it in a higher level DNS server. >From the top of my head I can think of several reasons: - For IP-level blocking you need to implement blocking in more places instead of a central place (DNS); also more data needs to be processed in total. Block lists are generally not public and access to them might need different restrictions (for legal reasons). - IP-level blocking leads to more overblocking (anything sharing the same IP); this causes legal problems. So Marco's arguments seem reasonable. >> > * Cloudflare can falsify DNS¹ >> You can use DNSSEC over DoH. > > If implemented. It's probably easier to use DNSSEC with DoH as you avoid broken resolvers at ISP or customer routers that don't speak DNSSEC or not even proper DNS. I've encountered customer routers that knew only about `A` RRs and lied about `PTR` which breaks stuff in interesting ways... Ansgar
Re: Git Packaging Round 2: When to Salsa
Anthony DeRobertis writes: > On 9/12/19 8:57 AM, Ansgar wrote: >> I don't see much value in this requirement (besides additional work). >> One should look at the repository anyway whan planning to do changes >> (to match the existing style used); one would naturally see how files >> are organized. We already had tons of packages shipping a >> README.source stating "this packages uses quilt, ..." before which I >> also didn't find very valuable; this seems pretty similar. > > Working with packages downstream it's nice to have that > documented. E.g., needing to patch something for a weird site > requirement, or backport a fix that isn't a big deal for anyone else > (so likely wouldn't qualify for a stable update), etc. Not everyone > who wants to modify a package is familiar with the multitude of ways > of maintaining packages. As long as you only need to touch the more trivial parts of the package and not the upstream source. There are many more ways to organize upstream sources; more conventions (for different programming languages); more workflows; code style conventions; ... Most of the variance in Debian packaging is much less than what one would encounter outside of the packaging-specific bits. Ansgar
Re: Debian 9/stretch moved to archive.debian.org
On Mon, 2023-03-27 at 00:40 +0200, Ansgar wrote: > the stretch, stretch-debug and stretch-proposed-updates suites have now > also been imported on archive.debian.org. People still interested in > these should update their sources.list. > > I plan to remove the suites from the main archive in about a month > (2023-04-23 or later). > > The stretch-backports, stretch-backports-sloppy and related debug suites > will likely move soon as well and might be removed from the main archive > around the same time. This has happened now, just according to 計画[1]. It might take a moment to reach mirrors. Ansgar [1]: Translator's note: 計画 means plan.
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi, On Sun, 2023-05-07 at 07:50 +0200, Helmut Grohne wrote: > But then, you only capture diversions inside Debian's ecosystem and miss > out on other kinds of diversions such as local diversions. We currently > support imposing local diversions on pretty much arbitrary files > including unit files. No, we do not really support diversions. Once you are divert a file, it is luck whether this works or not. Once you divert files, maintainer scripts and other parts would have to be aware of this and chose whether to use the original file included in the file or the diverted file. Not handling diversions can lead to files disappearing, data loss or other breakage, but it's very rare a package considers this. Ansgar
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi,
On Sun, 2023-05-07 at 07:50 +0200, Helmut Grohne wrote:
> But then, you only capture diversions inside Debian's ecosystem
It's unreasonable to support stuff outside Debian's ecosystem: even
basic dependency relations do not work for this.
Debian's dependency system requires to explicitly declare
Depends/Conflicts/Replaces/Breaks, but for obvious reasons we cannot do
that for packages outside Debian's ecosystem.
The same is true for diversions/alternatives/* or anything else
requiring coordination among all users: the dpkg ecosystem has too many
practical limitations to support non-Debian packages on anything but a
"it might work" basis (which is usually "good enough"). (This is even
true for packages within the Debian ecosystem, especially when one
considers partially implemented features like multi-arch.)
Is there any specific reason why specifically diversions are a problem
where "it might work" is not sufficient? That is, why should we divert
from the usual standard for dealing with packages outside the Debian
ecosystem here?
> I also caution that we've started from a very simple approach and tried
> fixing it up to address the problems that we recognized in analyzing it.
> My impression is that we are not finished with our discovery here and
> won't be for quite some time.
Well, we find limitations in dpkg that we in all other contexts usually
ignore. If we used similar expectations in other cases, we would need
to very much restrict when Breaks/Conflicts/Replaces might be used at
all: it's totally unrealistic to list all (possibly local) packages
that ship conflicting files, possibly only created by maintainer
scripts. Or to explicitly list all reverse dependencies that might be
broken by a particular change. We also would not have multi-arch yet as
the dependency system doesn't support it fully (some of which is
already known, but probably discovery isn't finished yet).
(Of course in some cases explicitly listing reverse dependencies can be
avoided: just always introduce something like
Provides: ${foo}-compat (= 1)
for *all* dependencies and forbid `>=` in `Depends`; this allows to
stop providing that in cases where one would have to declare explicit
`Breaks` before. But only the direct provider can use this, so it's
already too limited... Alternatively forbid *all* changes that would
require this, i.e., require stable interfaces. However we do not do
this.)
But for all these issues we just say "meh, you are out of luck".
Ansgar
Re: DEP 17: Improve support for directory aliasing in dpkg
On Wed, 2023-05-10 at 08:35 -0700, Sean Whitton wrote: > On Sun 07 May 2023 at 11:14AM +02, Ansgar wrote: > > Debian's dependency system requires to explicitly declare > > Depends/Conflicts/Replaces/Breaks, but for obvious reasons we > > cannot do > > that for packages outside Debian's ecosystem. > > > > The same is true for diversions/alternatives/* or anything else > > requiring coordination among all users: the dpkg ecosystem has too > > many > > practical limitations to support non-Debian packages on anything > > but a > > "it might work" basis (which is usually "good enough"). (This is > > even > > true for packages within the Debian ecosystem, especially when one > > considers partially implemented features like multi-arch.) > > I don't think this is the consensus view. So why do we allow changes that require listing all reverse dependencies in Breaks then? This is known to be wrong for all non- listed packages, e.g., all local/vendor/derivative-specific packages. > Our derivatives are among our users, for example, and we care about > them being able to add packages in appropriate ways. As far as I understand, we do explicitly *not* care about our derivatives with regard to merged-/usr as some packages in Debian recommend users to move *away* from merged-/usr to split-/usr on derivatives, i.e., to an unsupported fs layout. AFAIR the ctte felt that doing so on derivatives is fine for packages in Debian (w/o an explicit formal ruling). Ansgar
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi Russ, On Wed, 2023-05-10 at 13:50 -0700, Russ Allbery wrote: > Ansgar writes: > > As far as I understand, we do explicitly *not* care about our > > derivatives with regard to merged-/usr as some packages in Debian > > recommend users to move *away* from merged-/usr to split-/usr on > > derivatives, i.e., to an unsupported fs layout. > > Caring about them isn't the same thing as doing everything they want. We > can both try to make things as smooth for them as possible and still make > design decisions about Debian that they may disagree with or that may make > some property they want to maintain difficult or impossible. It's the > sort of decision we have to make on a case-by-case basis. Debian going out of its way to tell derivative users to switch back from merged-/usr to split-/usr is the *opposite* of trying to make things as smooth for them as possible. I asked the ctte to consider not telling derivative users to revert from merged-/usr and was told me that "we [ctte] would not consider this [change] to be in line with our existing decisions" (informally). I take that as explicitly not caring that we break derivative users' systems. Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
Package: tech-ctte X-Debbugs-Cc: Russ Allbery , Sean Whitton , Helmut Grohne , Luca Boccassi , debian-d...@lists.debian.org, debian-devel@lists.debian.org On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote: > Ansgar writes: > > Debian going out of its way to tell derivative users to switch back from > > merged-/usr to split-/usr is the *opposite* of trying to make things as > > smooth for them as possible. > > Yes, I agree with that part and I think I objected to that at the time. > Nonetheless, one bad decision doesn't mean that it is Debian policy that > we don't care about derivatives or their users. I think we made a mistake > there which is not in alignment with our ideals or our goals. We should > try to reverse that mistake, not double down on it. Cool, then let's ask tech-ctte. Dear ctte, please consider overruling the dpkg maintainer to include the patch from #994388[1]. Thanks, Ansgar [1]: https://bugs.debian.org/994388#397
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Wed, 2023-05-10 at 19:01 -0700, Sean Whitton wrote: > On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote: > > Cool, then let's ask tech-ctte. > > > > Dear ctte, please consider overruling the dpkg maintainer to > > include > > the patch from #994388[1]. > > > > Thanks, > > Ansgar > > > > [1]: https://bugs.debian.org/994388#397 > > This would require a new, maintainer-overruling vote. > Our existing decisions do not apply, so far as I can tell. Yes, I agree. > I have written a separate message to the bug and to debian-dpkg with > a proposal to avoid having to have such a vote. That seems to be about an implementation detail on how to apply the patch. I don't think that is the core of the issue? The core issue as I see it is as follows: - Debian has decided to support only merged-/usr, including possibly moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 as the interpreter in binaries. - This change breaks on non-merged-/usr systems, including derivatives that do not revert *all* relevant changes. (Do you know one that does this or plans to do so?) - dpkg recommends derivative users to move to non-merged-/usr. I think this contradiction is not good and the core conflict. For me a distribution should have some coherence. It is not just a distribution of unrelated parts (like linux, libc, dpkg, dash, ...), but also integrates them to work together. And this also means not one package telling users to do X which breaks other packages. Or (if other packages would do similar things as dpkg) one package asking users to do X and the other asking users to do the opposite of X. Just imagine dpkg asking users to move to split-/usr and then another package starting to warn users to move back to merged- /usr. Would that be a good state? I think not which is why this bug exists. Do you think this summary of the issue is right? Is there some consensus about how this issue should be solved or do we need a longer discussion to explore the solution space? Ansgar
dropping Priority field from binary packages for most packages
Hi, could we drop the Priority field from most packages? Most packages use "Priority: optional" and this is just noise in d/control (source package). Tools should just assume "optional" when no other value is set. Currently Policy documents Priority to be mandatory in 2.5: +--- | Each package must have a priority value, which is set in the | metadata for the Debian archive and is also included in the | package’s control files (see Priority). +---[ https://www.debian.org/doc/debian-policy/ch-archive.html#priorities ] As well as only recommended: +--- | The fields in this file are: | [...] | - Priority (recommended) +---[ https://www.debian.org/doc/debian-policy/ch-controlfields.html#binary-package-control-files-debian-control ] I would like to drop it pretty much everywhere, most importantly debian/control in source packages (as often humans edit these). But it could be dropped in other places (CONTROL in .deb and Packages indices) as well. Regards, Ansgar PS: Please note the following disclaimer: I might or might not be payed for this change and refuse to disclose financial incentives or other conflicts of interest; I might or might not suggest to revert this if my sponsors' (should they exist) priorities shift elsewhere. -- Certified Software Terrorist (Crime of File Relocation)
Bug#1036358: release-notes: Debian 12 expected to be last release w/ installer for i386
Package: release-notes X-Debbugs-Cc: Steve McIntyre , debian-devel@lists.debian.org On Fri, 2023-05-19 at 15:03 +0100, Steve McIntyre wrote: > I had been thinking about doing similar for installer images too, but > with other work going on too I think it got too late in the cycle to > make that change. My plan is therefore to ship i386 installer images > for bookworm as normal (including bookworm point releases going > forwards), but to disable those builds for testing/trixie > ~immediately after the release. I suggest to already document this in the release notes for bookworm, possibly in Section 2.1 (Supported architectures) or a subsection in Section 5 (Issues to be aware of for bookworm). Maybe something along these lines: +--- | Debian 12 is expected to be the last Debian release providing | full support for i386. Debian 13 will only partially support | i386 and no longer provide installation media for i386. | | We recommend hosts still running the i386 port to be upgraded | to amd64. Legacy i386 software can be run using multi-arch, | chroot environments or containers. +--- Ansgar
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On Fri, 2023-05-19 at 20:57 +0200, Bjørn Mork wrote: > Hmm. I find the netboot installer archives very useful for rescue > purposes. This sometimes involves PC hardware too old for amd64. I PXE > booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo N410c - CD > drive was part of the optional docking station) using a bullseye > netboot.tar not long ago. You can keep using the bullseye netboot.tar for the next 20+ years to rescue boot an ancient system, copy the data off of it, and then responsibly dispose the system. I don't think this is a good argument to keep generating i386 install media. > Not a major thing, but if you're going to keep most of i386 anyway... I would hope we could eventually drop some expensive, useless packages from i386 like src:linux. Ansgar
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On Fri, 2023-05-19 at 19:40 +0100, James Addison wrote: > Do we know how often the i386 installer is downloaded compared to > amd64, and could/should we start with updated messaging where those > are provided before removing users' ability to install on their > systems? > > (i386 remains the second-most-popular architecture behind amd64 today > going by popcon[1] stats - perhaps a lot of that is people using i386 > as a compatibility architecture only, but it'd be nice to be > reasonably confident about that) One of the problems with popcon is that it draws too much attention to old releases which isn't really interesting when talking about future developments. If one looks at arch usage per release (as reported to popcon) one gets this table: | Architecture | jessie | stretch | buster | bullseye | bookworm/sid | |++-++--+--| | alpha | 1 | || |4 | | amd64 | 9090 | 17156 | 41137 | 108145 |14800 | | arm64 || 1 | 93 | 937 | 203 | | armel | 21 | 47 | 67 | 68 | 10 | | armhf | 7 | 18 |216 | 429 | 49 | | hppa || || |8 | | hurd-i386 || ||4 |6 | | i386 | 1318 |1231 | 1495 | 3042 | 168 | | ia64 || || |3 | | kfreebsd-amd64 | 2 | || | | | m68k || 1 || |4 | | mips | 2 | | 6 | | | | mips64el || | 6 |4 | | | mipsel | 2 | 1 | 7 | | | | powerpc| 13 | 1 | 1 |1 | 18 | | ppc64 || ||1 | 28 | | ppc64el|| 5 | 16 | | 12 | | riscv64|| || | 15 | | s390x || ||8 |3 | | sh4|| || |1 | | sparc64|| || | 11 | | x32|| || |2 | |++-++--+--| | ∑ | 10456 | 18461 | 43044 | 112639 |15345 | #+TBLFM: @>$2..@>$>=vsum(@I..II) where i386 has dropped from 13% to 7% to 3% to 3% and finally to 1%. Also interesting is that arm64 has taken over i386 on bookwork/sid. We don't know how many people downloaded i386 instead of amd64 as they have an Intel CPU. What is also not clear is the bias of systems having popcon enabled at all (it seems to be mostly desktop systems) and how it looks on the total population. Ansgar
Re: i386 in the future
On Sat, 2023-05-20 at 04:25 +0100, Wookey wrote: > On 2023-05-19 12:42 +0100, Steve McIntyre wrote: > > If they're still running > > i386 *hardware*, then they should be replacing that hardware with more > > modern, more capable, more *efficient* stuff. > > I'm still using an i386 early acer netbook. (I even just upgraded it 4 > releases from Wheezy to Bookworm to get a newer Alfa wifi card working > with a mdern kernel). It's only used for ~1 month/year, primarily as a > fancy long-range wifi router and it's reasonably low power. An rPI > would not be a useful replacement as it's not the same form factor > (robust clamshell, with screen/mouse). [...] > Removing the installer to stop supporting _new_ installs is probably > fair enough but I don't think we can yet say there are no reasonable > use cases for old i386 hardware. I don't think that is a good use case to keep i386 installations on i386 hardware alive beyond 2028 (which is what we are talking about): just grab a slightly newer amd64 netbook out of the junk by the time LTS support for Debian bookworm ends. Ansgar
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi Russ, On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote: > Ansgar writes: > > Debian going out of its way to tell derivative users to switch back from > > merged-/usr to split-/usr is the *opposite* of trying to make things as > > smooth for them as possible. > > Yes, I agree with that part and I think I objected to that at the time. > Nonetheless, one bad decision doesn't mean that it is Debian policy that > we don't care about derivatives or their users. I think we made a mistake > there which is not in alignment with our ideals or our goals. We should > try to reverse that mistake, not double down on it. My impression is that the tech-ctte disagrees on this point and would not want to reverse the mistake, but double down on it (in your words). Or rather my impression is that they would like to avoid any decision on the dpkg mess situation. (Though not making a decision when asked is of course also an explicit decision.) So let me summarize Debian's "official" position as I understand it: we do *NOT* care how dpkg's recommendations will break derivative installations at all; if systems become unbootable, cause data loss, ... now or in the future that is explicitly fine. Ansgar
Re: DEP 17: Improve support for directory aliasing in dpkg
On Fri, 2023-05-26 at 08:39 +0100, Matthew Vernon wrote: > > So let me summarize Debian's "official" position as I understand it: we > > do *NOT* care how dpkg's recommendations will break derivative > > installations at all; if systems become unbootable, cause data loss, > > ... now or in the future that is explicitly fine. > > This is also unhelpful (and incorrect). No, it is correct. We allow boot-critical parts to refer to files using either the path in / or /usr; on systems following the recommendations from dpkg's warning this might result in non-booting systems. That is what we sign up to accept by having the warning in dpkg. Ansgar
Re: Dynamic linker support for FPC.
On Sun, 2023-05-28 at 20:23 +0200, Andrey Rakhmatullin wrote: > On Sun, May 28, 2023 at 06:53:51PM +0200, Abou Al Montacir wrote: > > One year ago, glibc 2.32 > 2.32 was released in 2020 though? Unless you mean some Debian-specific > changes, happened in 2021, in which case please be more specific? > > > introduced a change in the dynamic linker removing the functions > > calloc/malloc/realloc/free. > What do you mean by this? I think this entry from the changelog is meant: +--- | 2020-02-15 Florian Weimer | | COMMIT: 3a0ecccb599a6b1ad4b149dc569c0080e92d057b | ld.so: Do not export free/calloc/malloc/realloc functions [BZ #25486] +--- Which is an incompatible ABI change. Ansgar
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
On Wed, 2023-05-31 at 19:48 +0100, Wookey wrote: > On 2023-05-31 07:29 -0500, John Goerzen wrote: > > > > Hanging on to systems using power-hungry chips from 20 years ago instead > > > of > > > intercepting a system such as this is not reducing the number of computers > > > that end up in the waste stream, it just keeps you stuck with a more > > > power-hungry system. > > a) That's not necessarily a problem if the machine is running from a > renewable supply. The issue is emissions, not power consumption per > se. Thankfully I have a spiritual power filter[1] based on anthroposophic principles that makes my computers consume only renewable energy ;-) > and b) as both John and I have pointed out there are low-power i386 > systems still in use. > > c) it's not our choice to make. If people insist on using more > electricity than they need to for their computing, that's on them. > (we > enable enormous amounts of this already - old i386 systems probably > barely register at this point) > > Debian should be supporting people using whatever suits them where > that effort is reasonably proportionate. We are not driven by the > 'sell new stuff' goals of hardware manufactuers so we should IMHO be > erring on the side of keeping stuff going as long as there is > sufficient community support. I doubt we have that, see some of the issues listed for i386 on https://release.debian.org/testing/arch_qualify.html I would not be surprised if we consider dropping leaf software where builds start to hit the address space limit (I expect browsers & such). Plus the broken FPU implementation as we don't require SSE. And it *is* our choice to make to not spend time on dead architectures. Ansgar [1]: It also works for other carbon emissions!
Re: 64-bit time_t transition for 32-bit archs: a proposal
On Fri, 2023-06-09 at 09:22 +, Holger Levsen wrote: > On Fri, Jun 09, 2023 at 11:49:21AM +0800, Paul Wise wrote: > > > You mean by somehow refreshing the signatures there? > > Some ideas for that are here: > > https://bugs.debian.org/763419 > > https://bugs.debian.org/820423 > > interesting. thanks for those pointers! I did write a prototype once, but haven't touched it for some time. For example: https://defi.43-1.org/debian-defi-archive/debian/dists/stretch-backports/InRelease (It should also work for other things.) The test key is available from https://defi.43-1.org/defibrillator-test-key.asc Ansgar
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, 2023-06-19 at 13:35 +0200, Michael Biebl wrote: > Why does isc-dhcp-client have priority:important to begin with? > I don't think users care so much about a dhcp client but rather a > network configuration system and each network configuration system > has its own preferred dhcp implementation e.g NetworkManager no > longer uses isc-dhcp-client by default and systemd-networkd doesn't > use isc-dhcp-client either. > > So maybe simply demoting the priority of isc-dhcp-client to normal is > a better route. > ifupdown already recommends isc-dhcp-client and if ifupdown want's to > use dhcpcd in the future it could change this recommends. The priority question isn't the important one. The real question is: What network configuration system should users end up with (by default)? I think this should be NetworkManager for desktop environments and I personally like systemd-networkd for other environments. In both cases these replace both ifupdown and isc-dhcp-client. I also think that installing both ifupdown and NetworkManager on desktop environments is worse than only NM. Ansgar
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Tue, 2023-06-20 at 05:03 -0400, nick black wrote: > Simon McVittie left as an exercise for the reader: > > At the moment I believe the status quo for d-i is that networking is > > managed by NetworkManager if a desktop task happens to have pulled it in, > > or ifupdown otherwise? And that seems reasonable (although I personally > > prefer to set up systemd-networkd on servers). > > i don't wish to start an argument, but just to ask: everyone has > recommended NetworkManager for workstations. i've been running > systemd-networkd on everything (servers, laptops, and > workstations) for several years now, usually in conjunction with > dnsmasq and wpa_supplicant, and it's been pretty great. what > does NetworkManager offer that makes it superior to > systemd-networkd on the desktop (which i'm interpreting to mean > "for interactive use")? Managing VPN connections or 802.1X authentication for ethernet connections is nicer with NetworkManager for desktop computers too. For computers with static networking (where static might still mean DHCP) systemd-networkd might be sufficient as well. This might also include a subset of desktop computers, but I think the better default is still NM and it is up to the administrator to configure an alternative. Ansgar
Re: Policy consensus on transition when removing initscripts.
On Sun, 2023-06-25 at 11:15 -0700, Russ Allbery wrote: > Bastian Blank writes: > > Sorry no. Please add a conversion layer that adopts service and > > maybe other systemd units to initrc if you care about it. This is > > what systemd does to adopt existing init scripts, so you can do the > > opposite. > > I don't think it's useful to tell people who are working on sysvinit > support how best to do that work. We decided to not require support > in packages and put the maintenance burden on the sysvinit > maintainers. It feels rude to me to do that and then try to second- > guess how they choose to do that. I think sysvinit maintainers looked at such ideas in the past, but weren't capable to get it to work. That might be a blocker for such approaches. There was also a GSoC project in 2012 and some other work. > [...] we should respect it. But not necessarily much more than the community the thread starter works with shows towards others. > > And it can detect easily if no init script exists for a given unit, > > so no coordination necessary. > > Replaces and Conflicts are required at the very least so that > upgrades work properly, and I don't see any reason why we shouldn't > provide instructions to package maintainers to do that smoothly, > rather than having the init script disappear and then reappear and > break users who are using unstable. It's not that difficult to slow > down a little bit and follow a process. Neither orphan-sysvinit-scripts now! nor the packages it ships legacy startup scripts for seem to have Replaces or Conflicts though? I also don't think we should put anything here on the critical path: that lead to problems with, for example, systemd-shim which was promised to get maintained and timely updated... Less prone to errors than a manual process might be to watch automatically where legacy startup scripts disappear anyway; it's not that complicated to do. People tend to forget things. Ansgar
Re: Developer Workload and Sustainability
Hi Simon, On Thu, 2023-06-29 at 00:32 +0900, Simon Richter wrote: > According to Policy as currently published, systemd units are > encouraged, and init scripts are mandatory. Please stop lying: +--- | Packages that include system services should include systemd service | units to start or stop those services. [...] | | If the package does not include a service unit (if, for example, no | one has yet written one), including an init script, as described | below, to start the service is encouraged. | | Packages including a service unit may optionally include an init | script to support other init systems. +---[ Policy 9.3.1 ] And no, this isn't exactly new. Except apparently for you. The real exhausting thing is people lying, FUD, spreading conspiracy theories (ominous commercial sponsors (Rothschilds? Soros?)), endless revisiting of decisions (should we prepare to revert usrmerge because the attention of ominous commercial sponsors might shift elsewhere?), claiming systemd is rot/cancer/an infection/the Windows registry and so on. I agree that this isn't a technical issue though. > That's the thing: few people want init scripts. I don't want init > scripts either. This very thread only exists because people want init scripts. I agree that this is very few people though. > What I want is an init system that can be maintained inside a community > project like Debian without burning out people and endangering the long > term viability of the project. And claiming this isn't possible with systemd is one thing: FUD. > That is where systemd fails us as a community project, because the > environment in which most of development is happening is not > hospitable to community building efforts, and the complexity of the > project constitutes a high barrier to entry, which acts as a further > selection filter for contributors. More FUD. > I don't yet see a clear path out of this. The only thing that is > obvious to me is that this is not a technical problem[3]. I think we should consider removing sysvinit and init scripts from Debian. The non-technical cost of having them is too high. Ansgar
Re: Second take at DEP17 - consensus call on /usr-merge matters
Hi, On Wed, 2023-06-28 at 21:37 +0200, Helmut Grohne wrote: > Among these options, the first has a working prototype (debootstrap), > but it is unclear how that extends to use of snapshot.d.o and how to > make it work with debootsnap and debbisect as those tend to use a > suite name rather than a codename. debootstrap allows using suite names as well. As their meaning changed over time, the changes for conditional merged-usr also made debootstrap extract the Codename from the Release file in case a user specified a suite name. These days there are a few other changes that might depend on the release (identified by the codename). As pointed out on IRC, this might not work for the combination of "unstable" and using snapshot.d.o, but in principle that could be handled by looking at the Release's Date field as well (but, meh, not sure if we need that). > * It becomes a whack-a-mole, since we need to add codenames of every >derivative to every bootstrapping implementation. Well, shouldn't it already have become whack-a-mole then? debootstrap has the code for many years and is widely used after all... It doesn't seem to have been a problem in practice as there haven't been complaints since this was implemented AFAIK. (Possibly users just specify --no-merged-usr manually if needed; no idea.) > Introduction > [...] > Regardless of what strategy we end up choosing here, we will likely > keep some of the temporary changes even in the `forky` release to > accommodate external repositories and derivatives. There should be no additional work for derivatives. merged-/usr is not really something a Debian-based derivative can opt-out of and if some distribution did so (say because of warnings in dpkg or for other reasons), it's their own problem... Ansgar
Re: Developer Workload and Sustainability
On Fri, 2023-06-30 at 11:10 +0100, Sean Whitton wrote: > On Wed 28 Jun 2023 at 06:20PM +02, Ansgar wrote: > > > On Thu, 2023-06-29 at 00:32 +0900, Simon Richter wrote: > > > According to Policy as currently published, systemd units are > > > encouraged, and init scripts are mandatory. > > > > Please stop lying: > > Please assume good faith. There is no reason to think Simon would be > lying about what he thinks is in Policy. It's a mistake, not a lie. It's not only about this sentence, but the entire mail. And it's also not the first instance. > > The real exhausting thing is people lying, FUD, spreading conspiracy > > theories (ominous commercial sponsors (Rothschilds? Soros?)), endless > > revisiting of decisions (should we prepare to revert usrmerge because > > the attention of ominous commercial sponsors might shift elsewhere?), > > claiming systemd is rot/cancer/an infection/the Windows registry and so > > on. > > Perhaps people are spreading conspiracy theories like this about systemd > outside of Debian. But people are not doing that on Debian lists, so > the quoted text from your message seems entirely off-topic. People, including DDs, do several of the things I listed, including in this thread. So it seems entirely on-topic. Ansgar
Re: Developer Workload and Sustainability
Hi Sean,
On Fri, 2023-06-30 at 11:14 +0100, Sean Whitton wrote:
> It's understandable that you'd feel frustrated by what seems like a
> misrepresentation of your project's organisation and ethos, but
> please try to avoid this sort of rhetoric.
Fancy idea: how about we ask people to *stop* grossly misrepresenting
other projects instead?
We've had a decade of that about systemd, probably more if one looks at
Pulseaudio, GNOME and other things. Eventually we might reach a point
where we might want to stop that. Sadly I don't see you asking for that
to happen, rather the opposite.
> You can just as well present the git statistics without hiding the
> author's names for rhetorical effect, or asking rhetorical questions,
> and it would keep the temperature of the discussion lower.
Okay, then let's just note that sysvinit has an extreme barrier of
entry, driving most contributors away. A property it seems to share
with dpkg.
Thus both aren't a sustainable base to build a community distribution
on and we should look at solving that problem, possibly by using
community-friendly alternatives instead.
Does that help? I tried to write in the helpful style the mail I
replied to uses. I skipped stating {sysvinit,dpkg} proponents haven't
done their homework, using {sysvinit,dpkg} incurs technical debt, they
failed us as community projects, it's impossible to onboard people to
them[1], and possibly some other minor points.
Ansgar
[1]: Of course stating this is fine even when I'm not involved with
dpkg or sysvinit, as per the mail I replied to.
Bug#1049462: dpkg-source: Ignore __pycache__ by default (was: Re: __pycache__ directories)
Package: dpkg Severity: wishlist X-Debbugs-Cc: Michael Biebl , debian-devel@lists.debian.org On Mon, 2023-08-14 at 22:09 +0200, Michael Biebl wrote: > I received a couple of bug reports against packages I (co) maintain > regarding this issue and having a quick look, quite a few fail due to > python scripts being run during the build and creating a __pycache__ > directory. dpkg-source already ignores various paths for the diff when building source packages, for example ".git", ".svn", "CVS", "*~", ... Maybe $diff_ignore_default_regex should just be extended to include "__pycache__" as well and these would be non-issues. Ansgar
Re: Linking coreutils against OpenSSL
Hi, On Fri, 2023-11-10 at 14:45 +0100, Bjørn Mork wrote: > I guess those 0.61% are run bt the most valuable Debian users out > there. I'm sorry to not be one of them, but that's the way things > have become. Do you have any data to back up this claim? Or is it just a totally made up guess and one could just as well claim that those are the least valuable 0.61%? Ansgar
Re: Linking coreutils against OpenSSL
On Fri, 2023-11-10 at 08:48 -0500, Michael Stone wrote: > On Fri, Nov 10, 2023 at 10:38:13AM +, Luca Boccassi wrote: > > Per-architecture dependencies are possible though, so maybe starting > > to add the libssl dependency only on amd64 is a good starting point, > > and then users of other architectures can request to be added too if > > it is beneficial for them. > > I haven't seen any objections to the basic idea, so I'm starting here: > coreutils 9.4-2 will link to libcrypto if there's a gpl-compatible > version available at build time, but I've added the build-dependency as > linux-amd64 only for now. That should make it fairly straightforward for > people to control the linking on other architectures by controlling > their build environment. Going forward, depending on feedback, I can > roll this back, expand the build-dep, and/or make the configure option > also depend on the arch. Please avoid producing different results depending on the build environment. That just results in non-reproducible issues in unclean environments (suddenly different dependencies, different features, ...). Please consider to just use openssl everywhere or also explicitly disable/enable build options per arch. (Personally I would in this case probably just enable openssl everywhere and recommend people to improve openssl in case it is slower than the built-in implementation; openssl is probably use widely enough to warrant that.) Ansgar
Changing supermajority requirements
Hi, the Constitution has several supermajority requirements that seem excessive to me: Constitution changes: +--- | 4.1.2: Amend this constitution, provided they agree with a 3:1 majority. | [...] | 5.1.5.3: A Foundation Document requires a 3:1 majority for its supersession. [...] +--- Constitutional changes to my country's constitution only require a 2:1 majority. A 3:1 majority seems excessive for that reason and I would suggest to change both of these to 2:1 for that reason. I think a supermajority is fine for changing fundamental rules, so more than a simple majority is okay. Developer overriding tech ctte: +--- | 4.1.4: Make or override any decision authorised by the powers of the | Technical Committee, provided they agree with a 2:1 majority. +--- I think this is excessive: if a (simple) majority of developers is unhappy about some technical decisions, we should probably not do them. So in my opinion this should be a simple 1:1 majority. Tech ctte overriding a developer: +--- | 6.1.4: Overrule a Developer (requires a 3:1 majority). | | The Technical Committee may ask a Developer to take a particular technical | course of action even if the Developer does not wish to; this requires | a 3:1 majority. For example, the Committee may determine that a complaint | made by the submitter of a bug is justified and that the submitter's | proposed solution should be implemented. +--- I think this should only require a simple majority as well. Or at most 2:1, but I don't think there is a reason for it to be higher than a simple majority. Should we look at changing these? Ansgar
Re: Deprecation of /etc/alternatives?
On Mon, 2023-12-25 at 09:29 +0200, Teemu Likonen wrote: > * 2023-12-23 15:34:49+0100, Gioele Barabucci wrote: > > While we are on the topic of alternatives, I hope to see the > > maintscript-based /etc/alternatives paradigm deprecated in favor of > > the package-based X-is-X paradigm introduced by `python-is- > > python3`. > > I hope not. For example, as a user it is nice to execute a single > command (update-alternatives) to get a high priority alternative for > "editor". I use my locally built /usr/local/bin/emacs as the editor. > > /etc/alternatives/editor -> /usr/local/bin/emacs Users should just set the VISUAL environment variable. Alternatives are the wrong tool to set user preferences as they can only be set globally and only by root. (editor-is-emacs has the same problem of course...) Ansgar
Re: Bug#1059745: ITP: cryptsetup-2fa -- 2FA plugin for cryptsetup
On Sun, 2023-12-31 at 18:49 +0800, YunQiang Su wrote: > * Package name : cryptsetup-2fa > Version : 0.1 > Upstream Contact: YunQiang Su > * URL : https://github.com/wzssyqa/cryptsetup-2fa/ > * License : BSD-2 > Programming Lang: SHELL > Description : 2FA plugin for cryptsetup > > 2 mthods are supported for 2 FA: > - Yubikey Challenge > - TPM2 Keypair > PIN-less is also supported, if the PINs are present in > /etc/cryptsetup/2fa.conf. > > Since I am not expert of security and encrypt: > CODE Review is requested here, too. Is there any reason to not just use systemd-cryptenroll? It seems to be a more featureful implementation and also doesn't require storing PINs in plain text in configuration files like /etc/cryptsetup/2fa/2fa.conf as README instructs users to do here. Nor does it store plain text credentials in /var/cache. Ansgar PS: I also don't understand why cryptsetup-2fa-enroll(1) references privacyIDEA.
Re: Bug#1060034: ITP: python-openai -- OpenAI Python API library
On Thu, 2024-01-04 at 21:30 -0500, Mo Zhou wrote: > Dependency of DebGPT. Will be maintained by deep learning team. > It will go to the contrib section based on policy section 2.2.2, > because this API client requires either > (1) paied access to the proprietary backend > (2) compatible open-source backend implementations are not yet > available in the archive. I'm confused. Will this package have a "Depends: some-proprietary- openai-thing"? Can't it talk to a web service providing the API? Does OpenAI even offer this "some-proprietary-openai-thing" package to the general public? Ansgar
Re: Bug#1060034: ITP: python-openai -- OpenAI Python API library
On Fri, 2024-01-05 at 08:50 -0500, Mo Zhou wrote: > > On 1/5/24 03:48, Ansgar wrote: > > On Thu, 2024-01-04 at 21:30 -0500, Mo Zhou wrote: > > > Dependency of DebGPT. Will be maintained by deep learning team. > > > It will go to the contrib section based on policy section 2.2.2, > > > because this API client requires either > > > (1) paied access to the proprietary backend > > > (2) compatible open-source backend implementations are not yet > > > available in the archive. > > > > > > I'm confused. Will this package have a "Depends: some- > > > proprietary- > > > openai-thing"? Can't it talk to a web service providing the API? > No. All the dependencies are: python3-anyio,python3-distro, > python3-httpx,python3-pydantic,python3-sniffio,python3-tqdm, > python3-typing-extensions,python3:any. > Can be satisfied using packages from main section. > > That said, this package does not work at all without (1) paid > access token from OpenAI (2) open-source alternative Then the package should be in main. We do not require external software to be free as well, be that Web APIs provided by Github, Twitter, or the NVidia firmware required for Nouveau, microcode or storage/keyboard/sound/printer firmware required for Linux, ... We would have to move pretty much everything to contrib if that was the case. Ansgar
Policy: should libraries depend on services (daemons) that they can speak to?
Hi, I would like to extend Debian Policy on libraries depending on services (daemons) that they can speak to. Let me bring to examples, one made up,, one for which I filed a bug recently. But as far as I can tell this question comes up from time to time: 1. libpulse0 & friends -- libpulse0 is a client library for the Pulseaudio server. It doesn't do much without pulseaudio. Q: Should libpulse0 have Depends: pulseaudio? There a similar libraries like libjack0 to talk to Jackd. Q: Should libjack0 have Depends: jackd1? The answer should probably be the same for both questions. If the answer is "yes", this would result in an application that can output audio via Pulseaudio or Jackd and linking the respective liubraries pulling in *both* Pulseaudio and Jackd (and possibly other sound servers as well). 2. python3-secretstorage python3-secretstorage is a library to talk to a Dbus Secret Store API implemented by several programs (gnome-keyring, libkf5wallet-bin, keepassxc). Q: Should python3-secretstorage Depends: default-dbus-session-bus | dbus-session-bus? Q: Should python3-secretstorage Depends: gnome-keyring | ...? If the answer is "yes", this would result in an application that can manage credentials via Secret Store to pull in DBus, systemd-sysv, gnome-keyring, and lots of other stuff, even when one just wants to, for example, install (public) packages from PyPI (#1058945). (There is a practical different between Python and C in that Python makes it easier to handle optional linkage: just try `import foobar` and handle the import error; proper plugin handling in C is significantly more work.) 3. The general case --- Many Debian packages build with a large set of optional features enabled, thus linking many libraries. I believe that if all libraries implementing support to talk to some service would mandate installing said service, then this would result in many installations getting many more packages, especially when also considering use of software in containers. Some service might even conflict with each other, e.g., one would probably only want to use a single sound server. I therefore think that libraries (be it classic C shared object libraries or Python modules or others) should in general *not* have Depends: or Recommends: relations on services (DBus services, DBus itself, daemons, ...). A quick poll on IRC in #-devel seemed to show a majority of people who responded agreeing with this. (This does not have to apply to libnss-* or libpam-* which are not actually libraries, but plugins.) Ansgar
Re: 64-bit time_t transition in progress
Hi, On Fri, 2024-02-02 at 08:21 -0800, Steve Langasek wrote: > Once all of these packages have built in experimental and we have identified > and addressed all adverse interactions with the usrmerge transition, the > plan is: > > - dpkg uploaded to unstable with abi=time64 enabled by default[5] How does this work when a user builds their own software using any library build with abi=time64? They will still get a 32bit time_t & others unless they use dpkg-buildflags as well, won't they? If we already change ABI, why not change this in the toolchain (glibc, gcc) so also user-build packages use the correct ABI? That was what happened for other ABI changes like the C++ ABI change as far as I remember. Ansgar
Re: Changes to abi=+time64 behavior (was Re: 64-bit time_t transition in progress)
Hi, On Fri, 2024-02-09 at 15:24 +, Bill Allombert wrote: > when introducing a new soname (no just a new package name), then one > should move to time64 even on i386 ? If you know all consumers of the package will be using appropriate compiler flags to get 64-bit time_t, then this is fine. Otherwise provider and consumer would disagree about ABI and likely not work fully correct. > But fundamentally, how do we know how third-party binaries are > compiled ? They have to use `dpkg-buildflags` with equivalent ABI settings. Ansgar
move to merged-usr-only?
Hi, I would like to propose to plan to move to support merged-usr-only over the following releases. The motivation is bugs like [1] where upstream developers just use `/usr/bin/rm` (or other binaries, or user scripts using /usr/bin/bash, or ...) unconditionally; this was already a motivation to adopt merged-/usr as a default for me. As far as I know nothing broke catastrophically over the last releases with merged-/usr. Alternatively, a team could form that preemptively looks at such issues and fixes them, ideally upstream. So a possible idea would be to: - For Debian 12 (bookworm): make it mandatory to migrate old systems to merged-/usr on upgrade. Possibly by allowing the existing usrmerge program to run from the initramfs. - For Debian 13 (trixie): packages should no longer install to /bin, /sbin, /lib, but to the respective locations under /usr. Ansgar [1]: https://bugs.debian.org/973853
Re: move to merged-usr-only?
On Fri, 2020-11-20 at 10:19 +0100, Adam Borowski wrote:
> On Fri, Nov 20, 2020 at 09:35:42AM +0100, Ansgar wrote:
> > I would like to propose to plan to move to support merged-usr-only over
> > the following releases. The motivation is bugs like [1] where upstream
> > developers just use `/usr/bin/rm` (or other binaries, or user scripts
> > using /usr/bin/bash, or ...) unconditionally; this was already a
> > motivation to adopt merged-/usr as a default for me.
> >
> > As far as I know nothing broke catastrophically over the last releases
> > with merged-/usr.
>
> Unless you look at dpkg or attempts at speeding up bootstrap.
>
> See
> https://salsa.debian.org/glibc-team/glibc/-/commit/49d137c4392cb1144f2313f78f31466aaa169b75
> for an example.
>
> As far as I know, dpkg maintainers consider usrmerge to be unsupported,
> and trying to make my own NIH deb installer I see why.
The good news here is that shipping bash as /usr/bin/bash (instead of
/bin/bash) solves that problems as dpkg will just install it under
/usr/bin/bash. No aliasing over symlinks involved.
You also don't need any special handling for anything in /bin, /sbin as
nothing would be installed there (all packages ship the files in /usr).
> > So a possible idea would be to:
> >
> > - For Debian 12 (bookworm): make it mandatory to migrate old systems to
> >merged-/usr on upgrade. Possibly by allowing the existing usrmerge
> >program to run from the initramfs.
>
> Counterproposal: replace debootstrap with mmdebstrap, which is many times
> faster -- and doesn't support usrmerge at all, or at least disable usrmerge
> in debootstrap in default.
That is unrelated. Also you don't need special usrmerge support once
all packages ship files under /usr.
If you care about speed: not calling sync() way too often would
probably make dpkg significantly faster and possibly reduce the total
time the system is in an incinsistent state (of half-updated packages),
reducing the chance of system crashes breaking stuff ;-)
If you see the aliasing problem as a large issue, we could also try to
ship files in /usr already for bookworm.
> > - For Debian 13 (trixie): packages should no longer install to /bin,
> >/sbin, /lib, but to the respective locations under /usr.
>
> Moving stuff with no mandated path is a good idea, yes. Alas, it's been
> massively complicated by usrmerge being a thing, and thus you can't just
> ship the file in a new location as you risk a path conflict.
You can just ship /usr/bin/bash instead of /bin/bash in an updated
package.
> So let's make it so a canonical path to a file never includes a directory
> symlink; if you insist on /usr/bin/rm then /bin/rm should be
> /bin/{rm->/usr/bin/rm} not /{bin->usr/bin}/rm
Why ship /bin/rm at all? Seems too complicated and just ends in the
half-migrated state that SuSE was in last I checked.
> > [1]: https://bugs.debian.org/973853
>
> That's a piece of software for which upstream is Red Hat. The number of
> people developing on RPM distros is rapidly falling, so this is less and
> less of an issue.
Well, other distributions like Debian, Ubuntu, ... also use merged-/usr
these days.
Ansgar
Re: move to merged-usr-only?
On Fri, 2020-11-20 at 11:12 +0100, Ansgar wrote:
> On Fri, 2020-11-20 at 10:19 +0100, Adam Borowski wrote:
> > So let's make it so a canonical path to a file never includes a directory
> > symlink; if you insist on /usr/bin/rm then /bin/rm should be
> > /bin/{rm->/usr/bin/rm} not /{bin->usr/bin}/rm
>
> Why ship /bin/rm at all? Seems too complicated and just ends in the
> half-migrated state that SuSE was in last I checked.
Oh, and I forgot: I don't think adding new /bin/python3 ->
/usr/bin/python3 symlinks (repeat for everything else in
/usr/{bin,sbin} and possibly some parts of lib) to all packages is a
desirable goal.
One point is *not* having / to know about the contents /usr. That was
discussed many times in the past and I don't think we need to revisit
it.
Ansgar
Re: move to merged-usr-only?
On Sat, 2020-11-21 at 02:01 +, Paul Wise wrote: > On Fri, Nov 20, 2020 at 7:35 PM Simon McVittie wrote: > > > Package-by-package migration touches a large number of packages > > By my count there are 1712 binary packages from X source packages > installing things outside /etc /usr /var The goal is to have /bin and /usr/bin to have identical contents. If one wishes to achieve that via symlinks for every single binaries, you not only need symlinks in /bin for binaries previously there, but moved to /usr/bin, but also for binaries that already are in /usr/bin. So one would need a new /bin/python3 -> /usr/bin/python3 symlinks in addition to the /bin/bash -> /usr/bin/bash symlink discussed here. This affects many more packages. Starting a 10-year[1] migration for the small part (move bash to /usr/bin, add /bin/bash -> /usr/bin/bash) symlink, then maybe[2] start *another* *multi-year) migration after that, and then getting there isn't a great outlook for me. (At that time migration to merged-/usr for the remaining systems would no longer be a worry either way as presumably only very few installations without merged-/usr would exist anyway and no migration would be needed, i.e., like the i386 -> amd64 cross-upgrade nobody really worries about any more.) Ansgar [1]: https://lists.debian.org/debian-devel/2018/11/msg00354.html [2]: cf. OpenSuSE or suggestions to never do that and instead wait until nobody uses /bin/sh any longer. If you suggest to do package-by-package migrations, please at least argue why Debian wouldn't end in the same in-between state as SuSE.
Re: move to merged-usr-only?
On Sat, 2020-11-21 at 11:07 +, Paul Wise wrote: > On Sat, Nov 21, 2020 at 10:33 AM Ansgar wrote: > > > The goal is to have /bin and /usr/bin to have identical contents. > > So one would need a new /bin/python3 -> /usr/bin/python3 symlinks > > Those seem unnecessary to me, since we have $PATH and nothing should > be using /bin/python3 at this stage. We have $PATH, yet there are bugs that come from using `/usr/bin/rm` as mentioned in my inital mail. There is no reason to assume that the same doesn't happen in the other direction. I've already seen people using `#!/bin/python` as interpreter a long time ago (before Debian had merged-/usr by default). One can try to educate people that this is wrong because some binaries were historically only available in /usr (due to too small root disk, but a larger disk for /home), but why bother when we can just get rid of the problem and even already have done so partly? Or you can say we ignore that error class for a few more years and only address half of it and then the other half in X years. Ansgar
Re: apt ignoring check-valid-until flag
On Thu, 2020-12-17 at 00:47 +0100, John Paul Adrian Glaubitz wrote: > On 12/17/20 12:36 AM, Paul Wise wrote: > > * snapshot could gain a re-signing service (#763419) > > That would be absolutely awesome. Whom do I throw my money at? It doesn't seem too complicated to implement and could be developed independent from snapshot.d.o: If any Release.gpg/InRelease file is requested: - Retrieve the original Release+Release.gpg/InRelease files. - If there is a valid signature from any previous archive key: - Generate new signature (Release.gpg/InRelease) and store it in some cache. (Bonus points if this keeps the original signature if possible.) - Return the generated Release.gpg/InRelease. - Otherwise: - Return some HTTP error? Or the unmodified Release.gpg/InRelease? Any other files: - Redirect to normal snapshot.d.o Only some storage for recently-requested Release.gpg/InRelease files would be needed. The service could run independent from snapshot.d.o and redirect most requests there. Maybe the same could be done for archive.d.o? I might be interested to experiment with this as it seems reasonably small project to implement. :-) Ansgar
Re: apt ignoring check-valid-until flag
On Fri, 2020-12-18 at 01:15 +, Paul Wise wrote: > On Thu, Dec 17, 2020 at 10:03 AM Ansgar wrote: > > (Bonus points if this keeps the original signature if > > possible.) > > Two separate signatures is possible for Release+Release.gpg, just > rename the latter to .old, but what can you do for InRelease? Is it > possible to have multiple signatures in one blob of signing data? Is > it possible to take an existing signature and add a second one to it? > Can the same thing be done for Release.gpg? Do apt, gpg and gpgv cope > with this sort of thing? We do that for stable's InRelease and Release.gpg: it is signed by keys held by ftp-master and stable release team and we merge the signatures. For detached signatures you can even just concatenate two ascii-armored signatures and GnuPG will find all signatures (we did that for older releases). InRelease requires merging them. For GnuPG to check multiple signatures they must all use the same message digest (i.e. all signatures must use SHA-256, not one SHA-256 and another SHA-512 or similar), but for a signature-refreshing service we probably don't want new signatures for old Release files to use MD5 or SHA-1 even when the old signature did. For our use case consumers must accept when /any/ signature is valid for this (not /all/!); this doesn't make it less secure as we just require a single signature anyway so an attacker having one could drop additional signatures. Other applications might want to explicitly require more than one valid signature. Ansgar
Bug#978636: move to merged-usr-only?
Package: tech-ctte X-Debbugs-Cc: debian-devel@lists.debian.org Hi, as suggested in [1], I would like to see Debian to move to support only the merged-usr filesystem layout. This would simplfy things for the future and also address the problem with installing files under aliased trees that dpkg has to do for both variants to be supported. merged-usr has been the default for new installations since the last release and (as far as I am aware) no world-breaking bugs have happened since; some environments such as buildd chroots still do not use merged-usr. I would like to ask the technical committee to decide whether we want to move to merged-usr-only. It seems to be a case of overlapping jurisdiction (6.1.2 in the constitution). I'm not asking the committee to decide on a concrete technical implementation for this. Obviously we would need to also implement a migration path for legacy installations for a move to merged-usr-only to be implemented. This also isn't relevant for Debian 11 (bullseye), but I would like to have enough time in the Debian 12 (bookworm) cycle. Ansgar [1]: https://lists.debian.org/debian-devel/2020/11/#00232 continued in December: https://lists.debian.org/debian-devel/2020/12/#00386
Re: Making Debian available, non-free promotor
On Tue, 2021-01-12 at 19:30 +0100, Geert Stappers wrote: > Ah, yes I also wonder how much the world will improve > if non-free would be split in non-free and non-free-firmware. > Currently is non free firmware a hugh promoter of non-free in > /etc/apt/sources.list I proposed moving non-free firmware to a new non-free-firmware some time ago[1], but then it seemed like there was no consensus on this which I though we had before. Some people wanted non-free/firmware instead (different name), wanted packages to start appearing in multiple components (non-free and non-free[/-]firmware), wanted additional categories (e.g. non-free/doc for Free Software Foundation stuff), wanted non-free drivers as well, wanted major changes how components work (which might imply incompatible changes for mirroring tools and so on), ... As I wasn't motivated for a new topic for long discussions in addition to systemd and usrmerge nor for spending much time on implementing more support for (mostly?) non-free stuff I left things as they are. (Nor would I be too motivated to then read "but it's wrong" for many years later as with the other topics...) Ansgar [1]: https://lists.debian.org/msgid-search/87ziwfauw3@deep-thought.43-1.org
Re: Making Debian available
On Fri, 2021-01-15 at 15:30 +, Jeremy Stanley wrote: > On 2021-01-15 12:11:06 +0100 (+0100), Emanuele Rocca wrote: > [...] > > So the current situation is that we make an active effort to > > produce two different types of installation media: one that works > > for all users, and one broken for most laptops. > [...] > > The one you say "works for all users" doesn't "work" for me because > it contains proprietary closed-source software I don't want. Then don't install them? Debian's Social Contract states "We encourage CD manufacturers to read the licenses of the packages in these areas [non-free & contrib] and determine if they can distribute the packages on their CDs." Maybe we should do that for the CD images we manufacture? :) Ansgar
Re: Making Debian available, non-free promotor
Yao Wei writes: > At then, we can let users download the missing drivers from the > generated webpage, like the following: > >> Additional packages for the network interface >> == >> >> As Debian is the universal operating system, we consider both users >> and free software important. However, the network device of the >> computer requires firmware that is not available in the installation >> media, because these are considered non-free according to our >> guideline. >> >> We encourage you to get devices that respects your freedom. Should this message also be shown when non-free firmware is preinstalled in the system for educational purposes? Or do devices that have pre-installed non-free firmware respect the user's freedom? As long as the users doesn't look and doesn't hear about it, it's not there after all (two-wise-monkey-free / FSF-free?). The best example probably are TiVo devices which don't have user-upgradable firmware and thus should be called "freedom respecting" ;-) We could also recommend users to just install Debian in a VM which abstracts away the hardware, e.g., in a VM under Windows. This also respects user freedom in the same sense as above as Windows is usually preinstalled. (And AFAIU on modern systems Debian will usually run in some partition anyway and not have full hardware access, so it already runs in a "VM" of sorts.) >> Meanwhile, you can either try another device that's known good using >> only free software, or download the .deb package(s) linked below and >> put into the same place this file resides: >> >> --- >> >> firmware-iwlwifi >> - for: Network Controller: Intel Corporation Wireless 8265 / 8275 >> - https://packages.debian.org/bullseye/firmware-iwlwifi iwlwifi does work fine with just free software just like hard disks and similar? Ansgar
Re: Which package is responsible for setting rlimits?
Simon Richter writes: > On Mon, Feb 01, 2021 at 12:30:30PM -0500, Sam Hartman wrote: > >> It sounded like you were proposing that pam detect if systemd was pid1 >> and if so, then do what it does today otherwise inherit limits by >> default. > > PAM itself doesn't need to detect anything, the individual modules are > responsible for checking whether their requirements are met, and do > something safe if not. > > The way I see it, we want a pam_systemd module that is responsible for > applying *all* settings configured in systemd units, and that is kept in > sync with the unit file parser, and the pam_limits module to handle the > non-systemd setups. Systemd doesn't manage much of the "process forked from ssh that is the user's process", so there is no place to configure such limit. Also: +--- | To raise the user's limits further, the available configuration | mechanisms differ between operating systems, but typically require | privileges. In most cases it is possible to configure higher per-user | resource limits via PAM or by setting limits on the system service | encapsulating the user's service manager, i.e. the user's instance of | user@.service. +---[ man:systemd.exec(5) ] So changing this limit for user sessions is currently out-of-scope for systemd and handled by pam_limits on Debian (or whatever else). Ansgar
Re: Which package is responsible for setting rlimits?
Hi Simon, I think there are three aspects in your mail: the behavior of pam_limits, defaults for resource limits on legacy init systems and some discussion of sysvinit scripts that seems unrelated: 1. Resources limits set for a system service (e.g. sshd) might not be appropriate for a user session opened by the system service. Debian's PAM patch seems to be targeted at dealing with this by defaulting to restore the "original" values (taken from a process assumed to be unconstrained, here pid 1): sshd might have resource limits enforced, but the user session calls PAM which lifts the limits by default. You argue this might not be a good idea as pid-1's limits are somewhat arbitrary (in particular when systemd is pid-1) and it might be a good idea to consider using some other default. Possibilities seem to include: (a) Continue as is. The limits applied by pam_limit by default might not be reasonable as they are intended for systemd's pid-1, not arbitrary other processes. (b) Have pam_limit query some other source for default values, for example get the DefaultLimit*= values systemd uses by default for system services or having pam_limit use some default values (i.e., duplicating the logic that sets DefaultLimit*= in systemd). (c) Have some way to query the kernel's initial resource limits and use that as default (but doing so would just imply (2.) below as this happens on sysvinit systems as far as I understand). (d) Have pam_limit default to just inheriting resource limits, that is revert the Debian-specific patch. If an admin configures resource limits for system services that provide login services, but are not appropriate for user sessions, then the admin is responsible for increasing those by explicitly configuring pam_limits to raise them. As long as sshd, getty, gdm, ... have no explicit (lower) resource limits configured, the inherited limits would be reasonable by default. If sshd, getty, gdm, ... have similar resource limits on non-systemd systems, inheriting limits would also be reasonable to do there. I think (b) or (d) would be better than (a) which might still be better than (c). 2. The defaults for resource limits on non-systemd systems are no longer a good default and should be changed. This is probably true for both for system services and user processes, so somewhat independent from the behavior of pam_limits. 3. Init scripts cannot safely be called in arbitrary environments which can have arbitrary resource limits not appropriate for the service. To be safe, init scripts would need to explicitly set resource limits when invoked. This is also just another bit of the environment that would need to be explicitly sanitized, but usally isn't. But this is unrelated to what pam_limits does: even when an admin *explicitly* configures lower limits for user session, these limits *shouldn't* be applied to system services that just happen to be (re)started in a user session. Ansgar
Re: Which package is responsible for setting rlimits?
Hi, Simon, Simon Richter writes: > For systemd, resource limits should not be set by pam_limits, because > pam_limits reads /etc/security/limits.conf, while the systemd ecosystem > stores resource limits in the unit files. Please read [1]. [1]: https://lists.debian.org/debian-devel/2021/02/msg00014.html > Teaching pam_limits to interrogate systemd would create a functional > dependency between the PAM and systemd packages where we could only update > them in lock step, so that would be a maintenance nightmare. This is wrong. Just like we don't have to update consumers and producers of other things like /etc/resolv.conf in lock step. Or users and providers of libc. >> 2. The defaults for resource limits on non-systemd systems are no longer >>a good default and should be changed. > >>This is probably true for both for system services and user >>processes, so somewhat independent from the behavior of pam_limits. > > My expectation for a non-systemd system is that I have to explicitly > configure anything but "unlimited", and I will do so if necessary. So sysvinit should set the resource limits as high as possible? Seems like a reasonable change to sysvinit (as it doesn't do so currently as far as I know; the thread came from those limits too low on sysvinit systems after all). > tl;dr: pam_limits is for non-systemd setups, and only gets in the way of > users configuring limits according to systemd.resource-limits(5).It should > not do anything if pid 1 is systemd so it doesn't interfere, and be split > off into a separate package along with its configuration file to reduce > confusion. This doesn't seem correct. > The behaviour of copying rlimits from pid 1 in the absence of > explicit configuration is hacky but good enough for the other init > systems. And neither this as then we wouldn't have gotten this thread at all which is about those defaults being too low for some applications. Ansgar
Re: Proposal: plocate as standard for bookworm
"Steinar H. Gunderson" writes: > On Sat, Feb 06, 2021 at 10:16:29PM -0800, Josh Triplett wrote: >> Furthermore, any mechanism they use to configure one of them >> (e.g. for privacy or performance reasons) will not control the other, >> and again they may well be unaware of the existence of the other one. > > I'm not sure what privacy reasons you're referring to? I'm not aware that > neither mlocate/plocate nor e.g. tracker will leak data across users. If you have an encrypted /home (or /home/), but unencrypted /var/lib/plocate, you leak information about the encrypted files. File indexing services run as a user would at least write only to /home/ which would be encrypted. Admittedly Debian's other defaults like making every file in $HOME world-readable by default are very unfriendly too on both multi-user systems (obviously) and single-user systems where suddenly even the "nobody" user has access to lots of interesting files... Ansgar
Re: a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)
On Wed, 2021-02-10 at 13:38 +0100, Adam Borowski wrote: > Define "proper Unix"... A system including Emacs. So we would need emacs at Priority: standard or even important or required :] Ansgar
Re: Questioning debian/upstream/signing-key.asc
On Fri, 2021-03-26 at 09:06 -0700, Russ Allbery wrote: > I'm not all that familiar with the intended semantics of OpenPGP key > expirations, but intuitively I think a signature made before the > expiration should be considered valid, even if the key has now > expired and thus shouldn't be used to make new signatures. How would you know that the signature was made before the key expired? Other systems (e.g. signed executables on Windows) have a trusted third party sign the timestamp for that, but OpenPGP doesn't do so. Ansgar
Re: Tone policing by a member of the community team [Was, Re: Statement regarding Richard Stallman's readmission to the FSF board]
Hi Steve, On Tue, 2021-04-06 at 11:15 -0700, Steve Langasek wrote: > the rules of civilized discourse do not apply when dealing with > individuals who are external to your civilization. Please take your imperialist ideology elsewhere. Thanks, Ansgar
Re: Tone policing by a member of the community team [Was, Re: Statement regarding Richard Stallman's readmission to the FSF board]
On Tue, 2021-04-06 at 22:07 +0200, Pierre-Elliott Bécue wrote: > On this point I disagree because Steve never posted that publicly, So if I sent a private mail "fuck off you piece of shit" as a reply to a message that is okay as long as I don't send it to the public mailing list? Either it's acceptable or it's not acceptable, both as a private and public reply. Ansgar
Re: Thanks and Decision making working group
Philipp Kern writes:
> On 2021-04-20 10:59, Adrian Bunk wrote:
>> I would suggest to replace the option of shortening the discussion
>> period with the possibility of early calling for a vote after a week
>> that can be vetoed by any developer within 24 hours. This would ensure
>> that shorter discussion periods would only happen when there is
>> consensus that nothing is left to be discussed.
>
> But K developers could have stopped this, right? (Per 4.2.2.3.) Now
> the constitution feels quite heavyweight on that ("sponsoring a
> resolution"), but I'd be surprised if the DPL would not have taken
> back the decision in that case (4.2.2.5).
How does that even work? The next clause is:
+---
| If the decision is put on hold, an immediate vote is held to determine
| whether the decision will stand until the full vote on the decision is
| made or whether the implementation of the original decision will be
| delayed until then.
+---[ Debian Constitution, 4.2.2.4 ]
Which leaves open quite a bit, e.g, how long would the voting period for
the immediate vote be? The regular voting period is two weeks after
all...
Ansgar
