Bug#993066: ITP: python-certbot-dns-standalone -- Standalone (integrated DNS server) DNS plugin for Certbot
Package: wnpp Severity: wishlist Owner: Linus Vanas X-Debbugs-Cc: debian-devel@lists.debian.org, li...@vanas.fi * Package name: python-certbot-dns-standalone Version : 1.0.3 Upstream Author : Lauri Keel * URL : https://github.com/siilike/certbot-dns-standalone * License : Apache-2.0 Programming Lang: Python Description : Standalone (integrated DNS server) DNS plugin for Certbot This Certbot plugin enables automating DNS-validation (required for wildcard certificates) when the nameservers aren't supported by other plugins. I intend to maintain this package, presumably under the Debian Let's Encrypt Team. IANADD so I will need a sponsor.
next steps after usrunmess
On Thu, Aug 26, 2021 at 02:56:21AM +0200, Guillem Jover wrote: > On Sun, 2021-08-22 at 09:18:25 +0200, Andreas Metzler wrote: > > Afaict we have still no idea on how to move on. > > > > 1 I think you agree that there is a significant number of usrmerged Debian > > installations out there. > > My wish would be to indeed salvage those systems, > that's why I implemented dpkg-fsys-usrunmess. > > > 2 As you have stated there are known issues with dpkg and usrmerged > > systems. Some of them are are triggered by moving files from / to /usr. > > Well, in my mind the first and most immediate action that would be > done, is to stop the bleeding, by: > > - reverting the changes in deboostrap in sid, bullseye (and ideally > in buster too), > - reverting the notion that split-/usr is unsupported (which includes > the extremely confusing interpretation about this applying to > sid/testing too), and update documentation such as release-notes, This bullet point response confuses me - and then what? If I understand your position correctly, you don't want merged-/usr as an end-goal and you disagree with usrmerge transition as a hack. In order to achieve the result above without bypassing Debian processes, the formal method would to pass a GR overriding the tech-ctte minority. Is the only reason you haven't proposed that as a GR that you've already sunk too much energy into this? Or that you don't trust that process? Lets say you get your wish: to achieve technical excellence the Project backs your position and recommends running usrunmess to ensure everyone's systems are back to split-/usr for Debian 12. However, hypothetically, and against your better judgement, the Project still wants the end-goal to be merged-/usr. It seems to me that most commentators are deferring to your knowledge of dpkg internals. Whether you call it a feature request or a long-standing bug, what patchset would you be willing to merge into dpkg to support the new layout? This is a similar scenario to Russ' parallel email: On Wed, Aug 25, 2021 at 01:23:19PM -0700, Russ Allbery wrote: > I do not believe it will be possible at this point to > convince the project as a whole to unwind usrmerge and go back to doing > individual package migrations. > > Given that as a design constraint (we will not be doing this transition > via one-by-one changes to each package), what would you support as a good > architectural solution to this transition? What is the technically excellent thing everyone else should be working on, that you will support in dpkg despite personally disagreeing with the end-goal of merged-/usr? Presumably this feature could also be implemented in time for Debian 12. Would it then be possible to make everyone's systems merged-/usr upon release of Debian 13, in 2025? I'm sorry, you won't know me from adam, so I hope you don't interpret this as pro-merged-/usr, but as a chance to explain how you getting your way doesn't stand in the way of what others consider timely progress. signature.asc Description: PGP signature
Work-needing packages report for Aug 27, 2021
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1225 (new: 0) Total number of packages offered up for adoption: 206 (new: 0) Total number of packages requested help for: 61 (new: 1) Please refer to https://www.debian.org/devel/wnpp/ for more information. No new packages have been orphaned, but a total of 1225 packages are orphaned. See https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 206 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: [NEW] taglib (#992818), requested 3 days ago Description: audio meta-data library Reverse Depends: ardour ario auralquiz btag cantata clementine cowbell cynthiune.app deepin-music easytag (49 more omitted) Installations reported by Popcon: 97371 Bug Report URL: https://bugs.debian.org/992818 apache2 (#910917), requested 1048 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc bfh-container-server courier-webadmin cvsweb debbugs-web doc-central (139 more omitted) Installations reported by Popcon: 95710 Bug Report URL: https://bugs.debian.org/910917 asciio (#968843), requested 369 days ago Description: dynamically create ASCII charts and graphs with GTK+2 Installations reported by Popcon: 60 Bug Report URL: https://bugs.debian.org/968843 aufs (#963191), requested 432 days ago Description: driver for a union mount for Linux filesystems Reverse Depends: fsprotect Installations reported by Popcon: 10959 Bug Report URL: https://bugs.debian.org/963191 autopkgtest (#846328), requested 1730 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1206 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3623 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 838 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 1598 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 2360 Bug Report URL: https://bugs.debian.org/860116 courier (#978755), requested 238 days ago Description: Courier mail server Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-ldap courier-mlm courier-mta courier-pcp courier-pop courier-webadmin couriergrey (3 more omitted) Installations reported by Popcon: 951 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 172 days ago Description: new maintainer need Reverse Depends: apticron autolog backintime-common btrfsmaintenance buildd checksecurity clamtk cricket email-reminder exim4-base (20 more omitted) Installations reported by Popcon: 203014 Bug Report URL: https://bugs.debian.org/984736 cyrus-imapd (#921717), requested 930 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication Installations reported by Popcon: 425 Bug Report URL: https://bugs.debian.org/921717 cyrus-sasl2 (#799864), requested 2164 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base adcli autofs-ldap cyrus-caldav cyrus-clients cyrus-common cyrus-dev cyrus-imapd cyrus-imspd cyrus-murder (78 more omitted) Installations reported by Popcon: 202486 Bug Report URL: https://bugs.debian.org/799864 dbad (#947550), requested 607 days ago Description: dnsmasq-based ad-blocking using pixelserv Bug Report URL: https://bugs.debian.org/947550 debtags (#962579), requested 442 days ago Description: Debian Package Tags support tools Reverse Depends: packagesearch Installations reported by Popcon: 1543 Bug Report URL: https://bugs.debian.org/962579 dee (#831388), requested 1868 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 gir1.2-unity-7.0 libdee-dev libunity-dev libunity-protocol-private0 libunity-tools libunity9 zeitgeist-core Installations reported by Popcon: 31328 Bug Report URL: https://bugs.debian.org/831388
Re: BTS not archiving Bcc: mails? [was: Re: inconsistent mailgraph settings]
On Wed, 25 Aug 2021, Vincent Lefevre wrote: > Yes, but only the notification (and one needs to see the full message). > But what if the close message is sent when an empty From or with > a From containing the -cl...@bugs.debian.org address > of the bug[*] (such messages could come from spammers)? > > [*] That could yield a loop, and this may depend on how it is broken. On Mon, 23 Aug 2021, Andrey Rahmatullin wrote: > Yet the BTS says that the message with this Message-Id has closed the bug: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989734;msg=29 There some (understandable) confusion here. The BTS reports closures as "Reply sent to whoe...@example.com: You have taken responsibility. (Fri, 20 Aug 2021 13:33:06 GMT) (full text, mbox, link)." and has done so for about 20 years. The BTS (like all e-mail systems) totally ignores what is in To/Cc when processing e-mail, and only pays attention to the SMTP RCPT TO and MAIL FROM. Normally -done messages include the done address in the To: header, so it's pretty obvious which message actually caused a bug to be closed, but it is not required. -- Don Armstrong https://www.donarmstrong.com "The trouble with you, Ibid" he said, "is that you think you're the biggest bloody authority on everything" -- Terry Pratchet _Pyramids_ p146
Re: Debhelper and /lib/systemd vs /usr/lib/systemd
Sam Hartman: >> "Niels" == Niels Thykier writes: > > Niels> If the project consensus of this discussion is aligned with > Niels> the belief that we should block decentralized volunteer work > Niels> on the transition, I will respect the decision. > > I was really frustrated reading that, and I hope that my reading is more > loaded than you meant. Hi Sam, I am sorry that my email caused you frustration. That part was loaded with my own frustration over the situation and how we - as a project - are handling the transition, which I failed to weed out in my self-review of my outgoing email. Since I do not know to what extend you took it personally, I want you know that none of that frustration was aimed at you as an individual. Once again, if you in any way felt that, then I apologies for that part. > If what you're saying is that you'll respect it if the project consensus > is that individual package maintainers should not move paths around at > this time, then I think that's the key question. > That is what I wanted to say. > I'll point out that we get a lot of value even if we don't move paths > around in packages. > In particular, we get a uniform environment where we can depend on a > single directory layout. > That removes classes of bugs even if we don't get to update canonical > paths. > I believe we both agree on those statements being true (like many of the previous ones). Where we seem to disagree is what should have priority over other things. I sense that the timeliness of completion is of less importance to you compared to other values and I respect that. However, I will be considerably more demotivated by what I feel is a never-ending transition than I am motivated by all of the points you listed above. Which makes it a net-loss for me in years to come even if it is a net-win for many others if the transition is not resolved in a timely fashion. > > > What I originally heard in your statement was a consensus that volunteers > are not needed, > and I don't think anyone support that. > My frustration had a different direction than the one what you seemed to have understood it as, which is why I will not answer your extended follow up to that part in detail - nor do I intend to expand on my original words because I doubt it will make any of us happy. Once again, my sincerest apologies for frustration. Finally, I will retract myself from this debate for the time being. I do not feel I have anything additional of constructive value to add to it nor have enough spoons to invest to become a constructive participant. I will await the evaluation of the consensus. I kindly ask that you CC that to debhel...@packges.debian.org (or, at your choosing, report it as a bug if it involves reverting the change) as I am not sure I will keep track of this thread any more. ~Niels
Re: Debhelper and /lib/systemd vs /usr/lib/systemd
On 2021-08-25 Niels Thykier wrote:
[...]
> As I understand it, the "have usrmerge package patch the dpkg database"
> approach will only work if we ensure that each and every package stop
> using / in bookworm+1.
Hello,
you missed the second part of the "plan". Editing dpkg database syncs
the db with reality. In addition to that we need:
| if dpkg sees the top-level symlink, canonicalizes
| any files referenced in the packages to /usr/{bin,lib,sbin}/$1, with a
| fallback searching for /{bin,lib,sbin}/$1 in the file system, this
| would solve the problem.
A one-time rewrite does not solve the issue. We cannot guarantee that
dpkg never sees a file with /bin/foo because of local or third party
packages.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Re: merged /usr vs. symlink farms
On 2021-08-26 Timo Röhling wrote: [...] > However, Guillem also seems to think that dpkg can manage file > symlinks in a real directory better than an directory symlinks in /, > which is why he proposed symlink farms in the first place. Hello, Afaiui, the symlink farm would just work from dpkg's point of view, even with dpkg from oldoldoldoldstable. It can handle symlinks to files just fine. usrmerge is conceptually a lot harder because dpkg needs to get to handle the fact that /bin/foo and /usr/bin/foo conflict. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Debhelper and /lib/systemd vs /usr/lib/systemd
> "Niels" == Niels Thykier writes: Niels> If the project consensus of this discussion is aligned with Niels> the belief that we should block decentralized volunteer work Niels> on the transition, I will respect the decision. I was really frustrated reading that, and I hope that my reading is more loaded than you meant. If what you're saying is that you'll respect it if the project consensus is that individual package maintainers should not move paths around at this time, then I think that's the key question. I'll point out that we get a lot of value even if we don't move paths around in packages. In particular, we get a uniform environment where we can depend on a single directory layout. That removes classes of bugs even if we don't get to update canonical paths. What I originally heard in your statement was a consensus that volunteers are not needed, and I don't think anyone support that. I think there are several ways in which volunteers are needed: * Working on figuring out how to trigger the transition. Ideas included so far are to make usrmerge transitively essential, to include such code in dpkg, or to detect non usrmerged systems and force the administrator to do something manually. * Figure out whether we'll require build chroots to remain non-usr-merged in bookworm (thus requiring some way to generate such a system) or whether we'll somehow guarantee that usrmerge transition happens at the beginning of the upgrade. * Finish out the discussion Simon Richter and Ted Ts'o are having exploring changes in dpkg behavior. * Write patches for dpkg. I appreciate that getting those patches merged may be a challenge, but the situation is different with patches in hand. Yes, a lot more of these volunteer tasks are about talking to people than normal package maintenance. And some of them are kind of tricky. I don't even know who makes the decision about what the upgrade procedure is between releases in Debian. I mean I can guess to some extent the release team is involved and to some extent the release notes authors are involved. And I'd probably talk to the apt maintainers too. But I'm honestly not sure how we'd evaluate a proposed change to the upgrade procedure.
Re: merged /usr vs. symlink farms
Hi, * Sam Hartman [2021-08-26 08:56]: That may not matter so much for Debian (at least in some people's minds) but being compatible with the rest of the world has enough value in this instance that I consider the issue moot. I agree that this is a very convincing argument. A considerably weaker supportive argument would also be that these symlinks are here to stay for years, possibly even decades, which makes four or five static symlinks much simpler to maintain long-term. Still, I would prefer to know in advance if there are additional technical concerns which need to be fixed or worked around. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: merged /usr vs. symlink farms
> "Timo" == Timo Röhling writes: Timo> However, Guillem also seems to think that dpkg can manage file Timo> symlinks in a real directory better than an directory symlinks Timo> in /, which is why he proposed symlink farms in the first Timo> place. Assuming dpkg implements the proposed Timo> canonicalization, is there a scenario where the aliased dirs Timo> break, but would not break with a symlink farm? Quite possibly. However, I haven't been examining that part of the design space because the symlink farms approach misses key features that are important to some usrmerge use cases. In particular, if you're sharing a /usr between containers or similar, and moving toward the empty /etc at boot ostree style approach, symlink farms don't work and base level symlinks do work. That may not matter so much for Debian (at least in some people's minds) but being compatible with the rest of the world has enough value in this instance that I consider the issue moot. Symlink farms are a different thing, and that's not what we're trying to get here.
Re: Debian choice of upstream tarballs for packaging
Hi Thomas, On 8/26/21 4:16 PM, Thomas Goirand wrote: "git archive" is reproducible, for simplicity I wouldn't use a prefix though. xz has some issues with reproducibility, AFAIK "-T2" makes it disable some internal heuristics that are based on the machine it is running on, and generates consistent output. Excuse me, but -T in xz looks like to be the number of threads. Did you mistake it with something else? No, enabling multithreading with a number of threads > 1 disables a heuristic that optimizes memory usage based on memory available on the machine it is running on, and uses fixed-size buffers. Simon OpenPGP_signature Description: OpenPGP digital signature
Re: Debian choice of upstream tarballs for packaging
On 8/25/21 4:35 PM, Simon Richter wrote: > Hi, > >> I wrote this many times, but I don't see why we should use any "upstream >> tarball" when the Git repository itself contains the tarball with: > >> git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \ >> | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz > >> (which leads to a .xz, which is nicer) > > "git archive" is reproducible, for simplicity I wouldn't use a prefix > though. xz has some issues with reproducibility, AFAIK "-T2" makes it > disable some internal heuristics that are based on the machine it is > running on, and generates consistent output. > > Simon > Excuse me, but -T in xz looks like to be the number of threads. Did you mistake it with something else? Cheers, Thomas Goirand (zigo)
Re: merged /usr vs. symlink farms
On Thu, 2021-08-26 at 14:51 +0200, Simon Richter wrote: > Hi, > > On 8/26/21 1:17 PM, Luca Boccassi wrote: > > > > Ideally the question whether a system works correctly would be a > > > technical, not a political one that is based on a majority vote of > > > people who do not look behind the facade. > > > Precisely - and the correct technical question is, how many bug reports > > were opened by users? > > That is the majority vote by people who do not look behind the facade. A vote is a conscious decision and arbitrary act. Your system breaking is not. > > Strawmen can always be constructed, for example > > you can completely brick a system by running 'apt install bash:armhf' > > but that doesn't mean multiarch should be scrapped and reverted, it > > would be silly to suggest that - and yet here we are. > > This is precisely the debate we would be having if there was a package > that enables armhf as a foreign architecture whenever it is installed: > it would not break systems on its own, but we'd have to be a lot more > careful in other packages about expressing dependencies. > > I have armhf enabled on my laptop, and the resolver has suggested > replacing bash:amd64 with bash:armhf a few times -- but I know that my > setup is unusual. It's exactly the same. This dpkg bug manifests itself via a carefully crafted sequence of package upgrades/downgrades with a specific set of metadata between them. If I uploaded a new version of iproute2 which enabled armhf and installed bash:armhf the suggestion wouldn't be to revert the debian multiarch implementation. > > Conversely this > > doesn't mean the dpkg database bug shouldn't be fixed, > > Keep in mind that this isn't a dpkg bug, because dpkg never created a > filesystem layout that was inconsistent with its database; usrmerge did. > > What we are talking about is adding a workaround for the usrmerge > package to dpkg, and how to make sure that it works, regardless of > whether the system has already been converted or not, if it has, which > version of usrmerge was used, whether the package is currently installed > or not, whether it will be installed as part of an upgrade and if so, > which state the dpkg package is in at the time it is installed. > > For example, a possible scenario could be that the system was converted > with usrmerge version 9 (which modified dpkg.cfg), then the usrmerge > package was deinstalled as a later version declared a conflict that the > user resolved in favour of the other package, usrmerge hasn't been > installed since, then during the upgrade to bookworm, a new version of > dpkg is unpacked (but not configured yet), then a new version of > usrmerge is unpacked, and then dpkg --configure -a is run. > > So we need a list of things that need to happen to get back into a > consistent state and a way of sequencing that inside the package > dependency DAG. This is 100% a dpkg bug. rpm doesn't have it. Other package managers don't have it. And it's fine - all software has bugs. > > so that the > > replace+move bug can't happen in the future, but it simply makes > > overblown and hyperbolic ideas such as "all systems are broken, revert > > everything" and "let's cancel the TC decision" appear counter- > > productive and deeply unhelpful toward finding an actual, realistic > > solution. > > The TC decision does not specify technical details, which was a grave > mistake because the implementation was so shoddy that I doubt the TC > would have signed off on that, had they been consulted on the details. You are missing a gigantic 'IMHO'. For me the implementation was great - simple, to the point, matching other distros so that we don't get yet-another-incompatibility for the sake of being 'special', and working just fine across millions of installations for 2+ years and counting with hardly a hiccup. Of course it has bugs, because it's software, or more precisely yet it makes old bugs in other packages (dpkg) come to light, which happens and it's not the end of the world - we'll fix them or work around them, like the tens of thousands of other bugs affecting debian. Also, from what we have heard "unofficially" here and elsewhere, it appears that the TC has always indeed preferred the current approach of matching other distros and symlinking the top dirs, rather than the objectively failed symlinks farm approach. > Pretty much no one is interested in rolling this back, but a lot of > people, me included, are indifferent and cannot see the benefits, > especially as they consist mainly of things that used to work in the > past, were broken during the systemd rollout and subsequently declared > out of scope when people complained, so all users of these features have > already left anyway. > > An actual, realistic solution will work for all users, including those > who have now installed or upgraded to buster from DVD, run offline and > will upgrade to bookworm from DVD when it comes out. You say
Re: merged /usr vs. symlink farms
* Simon Richter [2021-08-26 14:51]: It makes a lot more sense to have a dpkg-internal tool that can investigate the differences between the file system and the dpkg database, resolve conflicts (possibly in an interactive process when required by a corner case like the one I mentioned earlier -- luckily, these should be really rare) and then leave a consistent state again that allows package maintainers to use all dpkg features again after the bookworm release. Agreed. Having yet another tool messing with dpkg "behind its back" will only exacerbate the problems we're trying to solve. Also, I wouldn't say it is the *only* possible way to move forward, but it is *a* possible way. I am also still trying to understand Guillem position and his objections better. This proposal addresses one half on Guillem's objections by making dpkg's point of view consistent with the actual filesystem reality. However, Guillem also seems to think that dpkg can manage file symlinks in a real directory better than an directory symlinks in /, which is why he proposed symlink farms in the first place. Assuming dpkg implements the proposed canonicalization, is there a scenario where the aliased dirs break, but would not break with a symlink farm? My apologies if this has been answered already. Just point me to the relevant emails/wiki pages then. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: merged /usr vs. symlink farms
Hi, On 8/26/21 1:17 PM, Luca Boccassi wrote: Ideally the question whether a system works correctly would be a technical, not a political one that is based on a majority vote of people who do not look behind the facade. Precisely - and the correct technical question is, how many bug reports were opened by users? That is the majority vote by people who do not look behind the facade. Strawmen can always be constructed, for example you can completely brick a system by running 'apt install bash:armhf' but that doesn't mean multiarch should be scrapped and reverted, it would be silly to suggest that - and yet here we are. This is precisely the debate we would be having if there was a package that enables armhf as a foreign architecture whenever it is installed: it would not break systems on its own, but we'd have to be a lot more careful in other packages about expressing dependencies. I have armhf enabled on my laptop, and the resolver has suggested replacing bash:amd64 with bash:armhf a few times -- but I know that my setup is unusual. Conversely this doesn't mean the dpkg database bug shouldn't be fixed, Keep in mind that this isn't a dpkg bug, because dpkg never created a filesystem layout that was inconsistent with its database; usrmerge did. What we are talking about is adding a workaround for the usrmerge package to dpkg, and how to make sure that it works, regardless of whether the system has already been converted or not, if it has, which version of usrmerge was used, whether the package is currently installed or not, whether it will be installed as part of an upgrade and if so, which state the dpkg package is in at the time it is installed. For example, a possible scenario could be that the system was converted with usrmerge version 9 (which modified dpkg.cfg), then the usrmerge package was deinstalled as a later version declared a conflict that the user resolved in favour of the other package, usrmerge hasn't been installed since, then during the upgrade to bookworm, a new version of dpkg is unpacked (but not configured yet), then a new version of usrmerge is unpacked, and then dpkg --configure -a is run. So we need a list of things that need to happen to get back into a consistent state and a way of sequencing that inside the package dependency DAG. so that the replace+move bug can't happen in the future, but it simply makes overblown and hyperbolic ideas such as "all systems are broken, revert everything" and "let's cancel the TC decision" appear counter- productive and deeply unhelpful toward finding an actual, realistic solution. The TC decision does not specify technical details, which was a grave mistake because the implementation was so shoddy that I doubt the TC would have signed off on that, had they been consulted on the details. Pretty much no one is interested in rolling this back, but a lot of people, me included, are indifferent and cannot see the benefits, especially as they consist mainly of things that used to work in the past, were broken during the systemd rollout and subsequently declared out of scope when people complained, so all users of these features have already left anyway. An actual, realistic solution will work for all users, including those who have now installed or upgraded to buster from DVD, run offline and will upgrade to bookworm from DVD when it comes out. Given this and the last few mails, it seems to me at this point the only possible way forward is what Timo and Ted suggested the other day, namely to have an external tool, possibly part of src:usrmerge, scan the dpkg database and fix it? Possibly on a trigger? No. We couldn't sequence that correctly, we'd have to somehow make installation of the usrmerge package mandatory, and that tool would need to touch the dpkg database at a point where dpkg is active in the background. It makes a lot more sense to have a dpkg-internal tool that can investigate the differences between the file system and the dpkg database, resolve conflicts (possibly in an interactive process when required by a corner case like the one I mentioned earlier -- luckily, these should be really rare) and then leave a consistent state again that allows package maintainers to use all dpkg features again after the bookworm release. That will be a lot of work, and we cannot speed it up anyway because we're tied to the release cycle here, so I'd rather do this properly than deploy another paper mâché thing that then turns out to have another weird bug that will delay the transition to bookworm+2. Simon OpenPGP_signature Description: OpenPGP digital signature
Re: merged /usr vs. symlink farms
On Thu, 2021-08-26 at 13:50 +0200, Philip Hands wrote: > Luca Boccassi writes: > > > On Thu, 2021-08-26 at 12:16 +0200, Simon Richter wrote: > > > Hi, > > > > > > On 8/26/21 8:38 AM, Marco d'Itri wrote: > > > > > > > > By my definition, these have never been working correctly, but > > > > > semantics I guess. > > > > > > > It is not semantics. You keep saying that countless Debian and Ubuntu > > > > systems are not working correctly, but since this obviously does not > > > > reflect the experience of the owners of these systems then just about > > > > everybody will believe that you are wrong about merged-/usr. > > > > > > Ideally the question whether a system works correctly would be a > > > technical, not a political one that is based on a majority vote of > > > people who do not look behind the facade. > > > > > > Simon > > > > Precisely - and the correct technical question is, how many bug reports > > were opened by users? > > While I'm sympathetic with the argument that a lack of bug reports > suggests that the theoretical problems (that I hope we all agree, do > exist) seem not to be exhibiting themselves in the wild, it is very far > from proof. > > If some random file disappears on your system one day, what happens? > > Most likely, nothing, and you never notice. > > Possibly, your system starts to misbehave. What do you do then? > > If you're a naive user, such as a recent arrival from Windows, then > misbehaviour is something that you've been trained to expect and you > install from scratch. The idea of reporting a bug never enters your > head. > > If you're aware that this sort of thing really should not happen, then > what happens next is probably down to how busy you are. If you're > busy, you probably check your SMART stats, and having convinced > yourself that the disks are OK, either restore from backup and check > for what ealse is missing, or use debsums to see the extent of the > damage and reinstall a package or two. Again, since you're only > trying to get back to work, and didn't track down the cause, no bug > report. > > The only bug reports you're going to get about this are either going to > be the useless "Something didn't work" bugs, that I doubt would ever get > tied to this cause, or the ones submitted by experienced, diligent, and > time-rich bug reporters (which is a rather rare combination). > > The fact that we don't see bug reports should surprise no one. > > Cheers, Phil. Actually in unstable (not in a release) this bug was observed, caught, properly reported and fixed: https://bugs.debian.org/953562 which would suggest these instances can and have been indeed detected when they happened - but anyway, that's why the full quote without the cut is: > Precisely - and the correct technical question is, how many bug > reports > were opened by users? Strawmen can always be constructed, for example > you can completely brick a system by running 'apt install bash:armhf' > but that doesn't mean multiarch should be scrapped and reverted, it > would be silly to suggest that - and yet here we are. Conversely this > doesn't mean the dpkg database bug shouldn't be fixed, so that the > replace+move bug can't happen in the future, but it simply makes > overblown and hyperbolic ideas such as "all systems are broken, > revert > everything" and "let's cancel the TC decision" appear counter- > productive and deeply unhelpful toward finding an actual, realistic > solution. IE, it's fine to think about all the possible ways things can go wrong, but the solutions need to be proportionate. So proposing to trash everything and going against the TC decision in absence of any user report and any knowledge from anybody of an actual breakage in buster/bullseye/19.10/20.04/20.10/21.04 is as far from proportionate as one can possibly be, just as suggesting to revert multiarch because 'apt install bash:ppc64el' breaks an amd64 machine beyond repair would be completely unreasonable. Am I suggesting the replaces+move issue should be ignored? No, hence the second part of the quote that was cut: > Given this and the last few mails, it seems to me at this point the > only possible way forward is what Timo and Ted suggested the other > day, > namely to have an external tool, possibly part of src:usrmerge, scan > the dpkg database and fix it? Possibly on a trigger? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: merged /usr vs. symlink farms
Luca Boccassi writes: > On Thu, 2021-08-26 at 12:16 +0200, Simon Richter wrote: >> Hi, >> >> On 8/26/21 8:38 AM, Marco d'Itri wrote: >> >> > > By my definition, these have never been working correctly, but >> > > semantics I guess. >> >> > It is not semantics. You keep saying that countless Debian and Ubuntu >> > systems are not working correctly, but since this obviously does not >> > reflect the experience of the owners of these systems then just about >> > everybody will believe that you are wrong about merged-/usr. >> >> Ideally the question whether a system works correctly would be a >> technical, not a political one that is based on a majority vote of >> people who do not look behind the facade. >> >> Simon > > Precisely - and the correct technical question is, how many bug reports > were opened by users? While I'm sympathetic with the argument that a lack of bug reports suggests that the theoretical problems (that I hope we all agree, do exist) seem not to be exhibiting themselves in the wild, it is very far from proof. If some random file disappears on your system one day, what happens? Most likely, nothing, and you never notice. Possibly, your system starts to misbehave. What do you do then? If you're a naive user, such as a recent arrival from Windows, then misbehaviour is something that you've been trained to expect and you install from scratch. The idea of reporting a bug never enters your head. If you're aware that this sort of thing really should not happen, then what happens next is probably down to how busy you are. If you're busy, you probably check your SMART stats, and having convinced yourself that the disks are OK, either restore from backup and check for what ealse is missing, or use debsums to see the extent of the damage and reinstall a package or two. Again, since you're only trying to get back to work, and didn't track down the cause, no bug report. The only bug reports you're going to get about this are either going to be the useless "Something didn't work" bugs, that I doubt would ever get tied to this cause, or the ones submitted by experienced, diligent, and time-rich bug reporters (which is a rather rare combination). The fact that we don't see bug reports should surprise no one. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: merged /usr vs. symlink farms
On Thu, 2021-08-26 at 12:16 +0200, Simon Richter wrote: > Hi, > > On 8/26/21 8:38 AM, Marco d'Itri wrote: > > > > By my definition, these have never been working correctly, but > > > semantics I guess. > > > It is not semantics. You keep saying that countless Debian and Ubuntu > > systems are not working correctly, but since this obviously does not > > reflect the experience of the owners of these systems then just about > > everybody will believe that you are wrong about merged-/usr. > > Ideally the question whether a system works correctly would be a > technical, not a political one that is based on a majority vote of > people who do not look behind the facade. > > Simon Precisely - and the correct technical question is, how many bug reports were opened by users? Strawmen can always be constructed, for example you can completely brick a system by running 'apt install bash:armhf' but that doesn't mean multiarch should be scrapped and reverted, it would be silly to suggest that - and yet here we are. Conversely this doesn't mean the dpkg database bug shouldn't be fixed, so that the replace+move bug can't happen in the future, but it simply makes overblown and hyperbolic ideas such as "all systems are broken, revert everything" and "let's cancel the TC decision" appear counter- productive and deeply unhelpful toward finding an actual, realistic solution. Given this and the last few mails, it seems to me at this point the only possible way forward is what Timo and Ted suggested the other day, namely to have an external tool, possibly part of src:usrmerge, scan the dpkg database and fix it? Possibly on a trigger? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: merged /usr vs. symlink farms
Hi, On 8/26/21 8:38 AM, Marco d'Itri wrote: By my definition, these have never been working correctly, but semantics I guess. It is not semantics. You keep saying that countless Debian and Ubuntu systems are not working correctly, but since this obviously does not reflect the experience of the owners of these systems then just about everybody will believe that you are wrong about merged-/usr. Ideally the question whether a system works correctly would be a technical, not a political one that is based on a majority vote of people who do not look behind the facade. Simon OpenPGP_signature Description: OpenPGP digital signature
Automated backports based on Janitor work?
Hi, I'm really amazed by all the great work done around the Debian Janitor project. It's great to see how it focuses the maintainer's work on where there's some actual value with having humans in the loop. Watching the talk[0] on automatically providing packages for new upstream releases and new upstream git snapshots, I wondered if the same tooling could be used to automatically provide stable backports for packages in unstable/testing. There's probably a large number of packages that just require a rebuild (+ test with autopkgtest) to be backported. Additionally, one could imagine a DSL to: - make minor changes to the source package before building (adjust dependencies, apply an additional patch, etc.) - tell sbuild that some build-dependencies must be pulled from backported packages Jelmer, did you already think about that? Is there a way one could help you? Lucas [0] https://debconf21.debconf.org/talks/7-fresh-upstreams-daily-builds/ https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/debconf21-110-fresh-upstreams-daily-builds.webm
Bug#993007: ITP: ovn -- Open Virtual Network (OVN)
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: ovn Version : 21.06.0+ds1 Upstream Author : Nicira, Inc. * URL : https://github.com/ovn-org/ovn * License : Apache-2.0 Programming Lang: C Description : Open Virtual Network (OVN) OVN, the Open Virtual Network, is a system to support virtual network abstraction. OVN complements the existing capabilities of OVS to add native support for virtual network abstractions, such as virtual L2 and L3 overlays and security groups. Note: this used to be part of OVS (OpenVSwitch), but upstream decided to separate it into multiple Git repository. Bullseye was shipped without OVN, this is an atempt to get OVN back into Debian.
Re: merged /usr vs. symlink farms
On Aug 26, Guillem Jover wrote: > By my definition, these have never been working correctly, but > semantics I guess. It is not semantics. You keep saying that countless Debian and Ubuntu systems are not working correctly, but since this obviously does not reflect the experience of the owners of these systems then just about everybody will believe that you are wrong about merged-/usr. -- ciao, Marco signature.asc Description: PGP signature
