From stefanor at debian.org Tue Apr 1 00:01:24 2025 From: stefanor at debian.org (Stefano Rivera) Date: Mon, 31 Mar 2025 23:01:24 +0000 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> Message-ID: <2vetxhe55kzyozb36reyqfwooefyegpu3hs2glpawlgvdaqrrw@xo4t5wte4zpd> Hi Luca (2025.03.31_21:30:41_+0000) Speaking for myself, as a technical committee member, I haven't run any of this by the rest of the committee. >There are several issues. First and most importantly, the TC wants half >of resolved (mdns) gone, but there seems to be some misunderstanding >going around that it can just be compiled out, but that's not true, at >most you can flip a boolean entry in a config file. They will never >accept something like that. For clarity, what you describe as being never acceptable is roughly what helmut's PR proposed: Flipping the default configuration from enabled to disabled. Not compiling it out. It could be re-enabled by configuration. You were not required to compile it out. The goal here is not to remove mDNS from systemd-resolved, but to disable it by default, as avahi is (currently) the default mDNS implementation in Debian (for trixie). This is expected to change in the future, as systemd-resolved matures. Avahi is an ageing codebase, and I'd imagine that systemd-resolved will probably replace it for most users in the future. > I already tried to propose some alternatives that are less disruptive > but with much stronger guarantees that ensure avahi always wins, and > their answer was escalating to DAM. It's hard to discuss alternatives after we've already concluded our discussion and voted. Engaging with the committee early helps us to make better decisions. We're here to work together, not to burn each other out. But, again, for clarity: The escalation to DAM was for summarily reverting the NMU implementing the TC's decision, without leaving any indication that other implementations were being pursued. >Secondly, even if there was a way to just carve out half of it, that >still leaves every single host relying on it for reachability dead in >the water on a simple in-place upgrade, requiring physical access to >fix. At least if the package is completely removed, chances it gets >noticed in time are _much_ higher, as you need to dist-upgrade, and >acknowledge that it gets removed - autoupdaters largely will refuse to >do so automatically. So the choice is, drop it and get shit for it now, >or leave it nerfed and get shit for it later. Lovely. There are other ways of approaching this, like release notes and NEWS entries. This feels like the more nuclear option... >Finally, and I understand you can't possibly care, but the only things >I am getting out of working on this are burnout and grief, a constant >barrage. Getting hate from random anonymous trolls is one thing and >pretty much comes with the job description of systemd maintainer, but >for some reason pile-ons from fellow project members just hit >differently. My problem, of course. Hate from anonymous trolls is unacceptable. I guess it's going to be an unavoidable part of the job description for the systemd maintainer. But that doesn't mean we're all against you. systemd solves real problems, and I personally appreciate it upstream, and the work that's gone into it in Debian. You've been doing great technical work. But there's also a social side to this. You've run into conflicts with other package maintainers and decisions had to be made about how to solve technical issues. We're trying to help make systemd in Debian better for everyone. Please let us help. Still hoping we can find a path through this. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 From noahm at debian.org Tue Apr 1 00:31:10 2025 From: noahm at debian.org (Noah Meyerhans) Date: Mon, 31 Mar 2025 19:31:10 -0400 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> Message-ID: On Mon, Mar 31, 2025 at 10:30:41PM +0100, Luca Boccassi wrote: > > Please try to find a less disruptive way to handle the resolved > situation. > > I am really sorry for the disruption, but unfortunately when features > need to be dropped, there's bound to be some of that. Let's keep in > mind though, that we are talking about an optional 2% popcon package. Popcon undercounts, that is well known. In this case, it undercounts significantly. Systemd-resolved is active on approximately ever single cloud VM based on the cloud team's images, and those number in the millions. > There are several issues. First and most importantly, the TC wants half > of resolved (mdns) gone, but there seems to be some misunderstanding > going around that it can just be compiled out, but that's not true, at > most you can flip a boolean entry in a config file. They will never > accept something like that. I already tried to propose some > alternatives that are less disruptive but with much stronger guarantees > that ensure avahi always wins, and their answer was escalating to DAM. > > Secondly, even if there was a way to just carve out half of it, that > still leaves every single host relying on it for reachability dead in > the water on a simple in-place upgrade, requiring physical access to > fix. At least if the package is completely removed, chances it gets > noticed in time are _much_ higher, as you need to dist-upgrade, and > acknowledge that it gets removed - autoupdaters largely will refuse to > do so automatically. So the choice is, drop it and get shit for it now, > or leave it nerfed and get shit for it later. Lovely. These are legitimately nontrivial problems to solve. But from a practical point of view, unless some bespoke user process is managing resolv.conf, systemd-resolved is the best solution to DNS client management when systemd-networkd is operating as the DHCP client. This is why we use it in the cloud images. Ripping out systemd-resolved entirely leaves gap in functionality that is not filled by available alternatives. I'd very much prefer to work constructively toward a solution that addresses the TC's requirements without giving up on providing systemd-resolved altogether. I'm sure such a thing exists. In the interest of trying to contribute potential solutions, one possibility that comes to mind is to use a generator to avoid conflicting with avahi. If the generator determines that avahi is installed (I don't think it's possible to determine if it's actually enabled at that phase), we can disable MDNS support with a drop-in fragment in /run/systemd/resolved.conf.d/. Have you considered such an approach? > Finally, and I understand you can't possibly care, but the only things > I am getting out of working on this are burnout and grief, a constant > barrage. Getting hate from random anonymous trolls is one thing and > pretty much comes with the job description of systemd maintainer, but > for some reason pile-ons from fellow project members just hit > differently. My problem, of course. This is also a legitimate problem. Have you considered recruiting additional maintainers to help deal with this? Please consider this an offer to help. Dropping the resolved package altogether won't make this problem go away. The cloud team and our users have been quietly happy with the state of the systemd network management stack for some time. The fact that the unhappy people are the ones making noise is unfortunate. > Besides, the generic feedback from random Debian users seems to be > largely positive, joyous even: > > https://fosstodon.org/@daltux at snac.daltux.net/114241049303960781 > https://fosstodon.org/@dwardoric at chaos.social/114241412595005926 > https://fosstodon.org/@eugenio at snac.eutampieri.eu/114241396099978535 > https://fosstodon.org/@nafmo at vivaldi.net/114242626006732520 > https://fosstodon.org/@asl at mastodon.launay.org/114245405068810570 > https://fosstodon.org/@TheGingerDog/114245701525734541 > https://fosstodon.org/@ttyS1 at bsd.network/114242208525201480 > https://fosstodon.org/@ParadeGrotesque at mastodon.sdf.org/114242559527495102 > > So, just one simple question: why the **** should I even bother > anymore? Please try to ignore them; they're not contributing anything of value to the conversation. I assert that they also represent a tiny minority. Within the cloud team, I certainly can't recall any users complaining about our choice to enable systemd-resolved, and there are a lot of them. noah From noahm at debian.org Tue Apr 1 00:38:54 2025 From: noahm at debian.org (Noah Meyerhans) Date: Mon, 31 Mar 2025 19:38:54 -0400 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> Message-ID: On Mon, Mar 31, 2025 at 11:47:07PM +0200, Marco d'Itri wrote: > > I am really sorry for the disruption, but unfortunately when features > > need to be dropped, there's bound to be some of that. Let's keep in > > mind though, that we are talking about an optional 2% popcon package. > Considering all the quality issues with systemd-resolved I think that Red > Hat made the right call when they classified it as "Technology Preview", > i.e. "totally unsupported if it breaks you keep both pieces". > Upstream has always been clear in explaining that it was still somehow > experimental software and so it should not have been used by the cloud > images, but maybe there is still time to correct this mistake and stop for > trixie. Maybe so, but the reality is that, if systemd-networkd is the dhcp client and the DNS server list is distributed via the DHCP leases, then there's currently no good alternative. Even if parts of it are horribly buggy (I have no idea if that's the case), systemd-resolved can be configured to operate in a number of different ways. In its most minimal configuration, it just manages the contents of /etc/resolv.conf and is not directly involved in the name resolution process at all. That's how we use it in the bookworm cloud images, and it has proven reliable. So I don't consider our usage of systemd-resolved to be a mistake any more than I consider our usage of systemd-networkd to be one. Removing it would not benefit our users in any way. noah From scott at smlx.dev Tue Apr 1 08:45:21 2025 From: scott at smlx.dev (Scott Leggett) Date: Tue, 01 Apr 2025 15:45:21 +0800 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> References: Message-ID: On Mon, 31 Mar 2025 22:30:41 +0100 Luca Boccassi wrote: > Finally, and I understand you can't possibly care, but the only things > I am getting out of working on this are burnout and grief, a constant > barrage. Getting hate from random anonymous trolls is one thing and > pretty much comes with the job description of systemd maintainer, but > for some reason pile-ons from fellow project members just hit > differently. My problem, of course. > > Besides, the generic feedback from random Debian users seems to be > largely positive, joyous even: > > https://fosstodon.org/@daltux at snac.daltux.net/114241049303960781 > https://fosstodon.org/@dwardoric at chaos.social/114241412595005926 > https://fosstodon.org/@eugenio at snac.eutampieri.eu/114241396099978535 > https://fosstodon.org/@nafmo at vivaldi.net/114242626006732520 > https://fosstodon.org/@asl at mastodon.launay.org/114245405068810570 > https://fosstodon.org/@TheGingerDog/114245701525734541 > https://fosstodon.org/@ttyS1 at bsd.network/114242208525201480 > https://fosstodon.org/@ParadeGrotesque at mastodon.sdf.org/114242559527495102 > > So, just one simple question: why the **** should I even bother > anymore? I'm sorry you have to deal with that kind of negativity from people who are likely not even Debian users. Unfortunately Mastodon is not free of social media toxicity - it just has a different flavour. However every Debian admin I know sincerely appreciates your sustained efforts on systemd in Debian, as I posted when I saw this news: https://fosstodon.org/@smlx/114240374851185610 Leaving the cloud images aside for a moment, even on the desktop systemd-resolved has been the _only_ DNS tool that actually works reliably for complex DNS setups. There's a blog post from Tailscale way back in 2021, explaining the shortcomings of every other DNS solution, and why only systemd-resolved actually handles complex requirements the right way: https://tailscale.com/blog/sisyphean-dns-client-linux If Trixie really ships without systemd-resolved it will be almost unusable for Tailscale (and similar VPNs), DNS over TLS/HTTPS, and other modern DNS configuration combinations common in 2025. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hertzog at debian.org Tue Apr 1 09:59:57 2025 From: hertzog at debian.org (Raphael Hertzog) Date: Tue, 1 Apr 2025 10:59:57 +0200 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: <2vetxhe55kzyozb36reyqfwooefyegpu3hs2glpawlgvdaqrrw@xo4t5wte4zpd> <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> References: Message-ID: Hello, On Mon, 31 Mar 2025, Luca Boccassi wrote: > Paul, could you please confirm whether resolved is a key package and > thus cannot be removed anymore, or isn't and can? Thanks. We don't care. Nobody wants to see systemd-resolved removed from Debian. > So, just one simple question: why the **** should I even bother > anymore? I can't answer that question for you. But if you are no longer enjoying working on systemd, then you should consider to step back and let other co-maintainers handle it for a while at least. That's healthier than this current fight. BTW, did you run your decision to remove the package with them or was that an unilateral decision? I'm explicitly ccing all the co-maintainers so that they can chime in and share their sentiments on what happened. On Mon, 31 Mar 2025, Stefano Rivera wrote: > Speaking for myself, as a technical committee member, I haven't run any of > this by the rest of the committee. I wanted to reply roughly what Stefano said. So I'm not repeating but just +1 his reply. The two main points are: - the patch for mdns only changed the default value of the setting, nothing else, and that's just what was asked - dealing with the regression compared to bookworm can be done with release notes and debian/NEWS entries Cheers, -- ??????? Rapha?l Hertzog ??????? ?????? The Debian Handbook: https://debian-handbook.info/get/ ??????? Debian Long Term Support: https://deb.li/LTS From helmut at subdivi.de Tue Apr 1 07:24:37 2025 From: helmut at subdivi.de (Helmut Grohne) Date: Tue, 1 Apr 2025 08:24:37 +0200 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> Message-ID: <20250401062437.GA2656140@subdivi.de> Hi Noah, Allow me to give background on the resolved matter without addressing any other aspects of this. I've been managing the relevant ctte discussion on that report. On Mon, Mar 31, 2025 at 07:31:10PM -0400, Noah Meyerhans wrote: > In the interest of trying to contribute potential solutions, one > possibility that comes to mind is to use a generator to avoid > conflicting with avahi. If the generator determines that avahi is > installed (I don't think it's possible to determine if it's actually > enabled at that phase), we can disable MDNS support with a drop-in > fragment in /run/systemd/resolved.conf.d/. Have you considered such an > approach? A solution to this end was considered during the discussion phase. There are various variants of it such as avahi-daemon installing the fragment. The gist is the same. Avahi should be the default implementation and resolved should only act as a mDNS resolver when avahi does not. The option did not make it to the ballot that was voted on. The rough consensus reached was that having resolved disable its mDNS functionality on installing Avahi or enable mDNS on uninstalling Avahi would be more confusing to users than simply leaving mDNS disabled in resolved while letting users opt back in by changing the configuration file or dropping a fragment. The expectation is that few users would be depending on mDNS as implemented by resolved, because it additionally needs to be enabled per interface in networkd and no present component would perform such entablement in Debian. In other words, using the mDNS functionality already requires user changes. At that point we were back at simply changing the default state aligning Debian's defaults with Fedora and Ubuntu. Do you actually see that behavior of having resolved automatically disable mDNS when Avahi gets installed as better? Few spoke up for that option during the discussion phase, so I'd be interested in reasons still. Maybe we moved too quickly there? In any case, a decision has been made. We may consider doing another decision if new information emerges, but time is running out and I am not seeing that new information just yet. Helmut From noahm at debian.org Tue Apr 1 17:48:39 2025 From: noahm at debian.org (Noah Meyerhans) Date: Tue, 1 Apr 2025 12:48:39 -0400 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: <20250401062437.GA2656140@subdivi.de> References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <20250401062437.GA2656140@subdivi.de> Message-ID: On Tue, Apr 01, 2025 at 08:24:37AM +0200, Helmut Grohne wrote: > > In the interest of trying to contribute potential solutions, one > > possibility that comes to mind is to use a generator to avoid > > conflicting with avahi. If the generator determines that avahi is > > installed (I don't think it's possible to determine if it's actually > > enabled at that phase), we can disable MDNS support with a drop-in > > fragment in /run/systemd/resolved.conf.d/. Have you considered such an > > approach? > > A solution to this end was considered during the discussion phase. There > are various variants of it such as avahi-daemon installing the fragment. > The gist is the same. Avahi should be the default implementation and > resolved should only act as a mDNS resolver when avahi does not. That makes sense. > The option did not make it to the ballot that was voted on. The rough > consensus reached was that having resolved disable its mDNS > functionality on installing Avahi or enable mDNS on uninstalling Avahi > would be more confusing to users than simply leaving mDNS disabled in > resolved while letting users opt back in by changing the configuration > file or dropping a fragment. The expectation is that few users would be > depending on mDNS as implemented by resolved, because it additionally > needs to be enabled per interface in networkd and no present component > would perform such entablement in Debian. In other words, using the mDNS > functionality already requires user changes. At that point we were back > at simply changing the default state aligning Debian's defaults with > Fedora and Ubuntu. This also makes sense, and I can see how it's potentially confusing for users to have systemd-resolved's behavior change depending on the installation or removal of another package. This does seem like something that could be clearly explained in the release notes, though. As you note, there are likely few users configuring mdns in systemd-resolved today. The people who are doing so are performing specific actions to do so, and should be similarly able to resolve the interaction with avahi in whatever way makes the most sense for their use case. > Do you actually see that behavior of having resolved automatically > disable mDNS when Avahi gets installed as better? Few spoke up for that > option during the discussion phase, so I'd be interested in reasons > still. Maybe we moved too quickly there? In any case, a decision has > been made. We may consider doing another decision if new information > emerges, but time is running out and I am not seeing that new > information just yet. So, to be clear, I'll point out that I don't use mdns myself at all, so I can't claim to speak for mdns users. What I'm mostly concerned about right now is avoiding the collateral damage that may follow the TCs decision. The TC decision of changing the systemd-resolved default mdns behavior to "off" for trixie was rejected by the maintainer as it would potentially break users upgrading from bookworm. This is a legitimate concern and we know that many users won't read the release notes, so people would be surprised by it. The TC seems to have disliked the precident set by the drop-in option based on a precident that it sets, but I'm not sure I agree with the concerns. We already have the ability for one package to modify the behavior of another, e.g. with dpkg-divert, which has existed approximately forever. There's an expectation that such behavior is coordinated between the maintainers of the involved packages, just as would be the case here. So I don't think this would have set a precident that hasn't already been established. So, to answer your question, yes, I do think that automatically disabling systemd-resolved's mdns support is likely a safer behavior than flipping systemd-resolved's default. This specifically concerns the upgrade scenario. However, as you note, the decision has already been made, so it's too late to change any minds there. I don't know what to suggest to the TC at this point, but the current situation risks leaving a fairly large subset of our users without a clear path forward. I don't agree with Luca's decision to drop systemd-resolved altogether in response to the TC's decision, but I do recognize that he's the one who's going to be on the receiving end of the hate mail from user's when their DNS breaks when upgrading from bookworm, so I'm somewhat sympathetic to his position. noah From debian-reportbug at lassnig.net Tue Apr 1 18:43:18 2025 From: debian-reportbug at lassnig.net (Mario Lassnig) Date: Tue, 01 Apr 2025 19:43:18 +0200 Subject: Bug#1101875: systemd-resolved: Unable to satisfy dependencies, none of the choices are installable Message-ID: <174352939824.412595.8174951278877514422.reportbug@wraith.lassnig.net> Package: systemd-resolved Version: 257.4-3 Severity: grave Justification: renders package unusable X-Debbugs-Cc: debian-reportbug at lassnig.net Dear Maintainer, in it's current state systemd-resolved can't be installed, as it depends on a version that's not available: Unsatisfied dependencies: systemd-resolved : Depends: libsystemd-shared (= 257.4-3) but 257.4-7 is to be installed Depends: systemd (= 257.4-3) Recommends: libnss-myhostname but it is not going to be installed Recommends: libnss-resolve but it is not going to be installed I'm not entirely sure why/when it was removed in the first place, I definitely had it running not so long ago. Thanks for having a look, Mario -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.12.20-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd-resolved depends on: ii dbus [default-dbus-system-bus] 1.16.2-2 ii libc6 2.41-6 ii libssl3t64 3.4.1-1 ii libsystemd-shared 257.4-7 ii systemd 257.4-7 Versions of packages systemd-resolved recommends: ii libidn2-0 2.3.8-2 pn libnss-myhostname pn libnss-resolve Versions of packages systemd-resolved suggests: ii polkitd 126-2 From bluca at debian.org Tue Apr 1 19:06:38 2025 From: bluca at debian.org (Luca Boccassi) Date: Tue, 01 Apr 2025 19:06:38 +0100 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> Message-ID: <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> On Mon, 31 Mar 2025 19:31:10 -0400 Noah Meyerhans wrote: > On Mon, Mar 31, 2025 at 10:30:41PM +0100, Luca Boccassi wrote: > > There are several issues. First and most importantly, the TC wants half > > of resolved (mdns) gone, but there seems to be some misunderstanding > > going around that it can just be compiled out, but that's not true, at > > most you can flip a boolean entry in a config file. They will never > > accept something like that. I already tried to propose some > > alternatives that are less disruptive but with much stronger guarantees > > that ensure avahi always wins, and their answer was escalating to DAM. > > > > Secondly, even if there was a way to just carve out half of it, that > > still leaves every single host relying on it for reachability dead in > > the water on a simple in-place upgrade, requiring physical access to > > fix. At least if the package is completely removed, chances it gets > > noticed in time are _much_ higher, as you need to dist-upgrade, and > > acknowledge that it gets removed - autoupdaters largely will refuse to > > do so automatically. So the choice is, drop it and get shit for it now, > > or leave it nerfed and get shit for it later. Lovely. > > These are legitimately nontrivial problems to solve.? But from a > practical point of view, unless some bespoke user process is managing > resolv.conf, systemd-resolved is the best solution to DNS client > management when systemd-networkd is operating as the DHCP client.? This > is why we use it in the cloud images. > > Ripping out systemd-resolved entirely leaves gap in functionality that > is not filled by available alternatives.? I'd very much prefer to work > constructively toward a solution that addresses the TC's requirements > without giving up on providing systemd-resolved altogether.? I'm sure > such a thing exists. > > In the interest of trying to contribute potential solutions, one > possibility that comes to mind is to use a generator to avoid > conflicting with avahi.? If the generator determines that avahi is > installed (I don't think it's possible to determine if it's actually > enabled at that phase), we can disable MDNS support with a drop-in > fragment in /run/systemd/resolved.conf.d/.? Have you considered such an > approach? Thanks for the suggestion. On the specifics, a generator can generate units, but not config files - ie, it has access to /run/systemd/generator* but not where a config file would be looked at. More generically, if you haven't seen on the MR, I had proposed several alternatives to the submitter that are much safer and clearer, such as a package conflict. The MR submitter's answer to the _mere suggestion_ was escalating to DAM. Do the cloud images use avahi at all? Assuming I'm looking at the right manifest: https://cdimage.debian.org/images/cloud/trixie/daily/20250324-2061/debian-13-generic-amd64-daily-20250324-2061.json it seems not, so how about this: I'll take a personal risk and we can try once more with the pkg conflict. I'll reinstate the package, with an added "Conflicts: avahi-daemon" so that users have to choose one or the other, and avahi is the default so it always wins unless someone has very specific and customized use cases like yours. If everything goes fine, then all good. If instead the TC escalates again to DAM, then I'll remove the package again, and work to find an alternative that you can use with networkd in the cloud images, and try and find time to implement it. How does this sound? From bluca at debian.org Tue Apr 1 19:08:35 2025 From: bluca at debian.org (Luca Boccassi) Date: Tue, 01 Apr 2025 19:08:35 +0100 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: Message-ID: <721663dc354a22345afb4df73a298a027d369b53.camel@debian.org> On Tue, 1 Apr 2025 10:59:57 +0200 Raphael Hertzog wrote: > Hello, > > On Mon, 31 Mar 2025, Luca Boccassi wrote: > > Paul, could you please confirm whether resolved is a key package and > > thus cannot be removed anymore, or isn't and can? Thanks. > > We don't care. Nobody wants to see systemd-resolved removed from Debian. Excuse me, but could you please clarify who is "we" in this statement? Are you speaking for the Release Team here? From noahm at debian.org Tue Apr 1 19:50:39 2025 From: noahm at debian.org (Noah Meyerhans) Date: Tue, 1 Apr 2025 14:50:39 -0400 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: On Tue, Apr 01, 2025 at 07:06:38PM +0100, Luca Boccassi wrote: > Do the cloud images use avahi at all? Assuming I'm looking at the right > manifest: > > https://cdimage.debian.org/images/cloud/trixie/daily/20250324-2061/debian-13-generic-amd64-daily-20250324-2061.json No, in fact most cloud environments don't support multicast networking at all, so disabling it is entirely safe. > it seems not, so how about this: I'll take a personal risk and we can > try once more with the pkg conflict. I'll reinstate the package, with > an added "Conflicts: avahi-daemon" so that users have to choose one or > the other, and avahi is the default so it always wins unless someone > has very specific and customized use cases like yours. That works for me. > If everything goes fine, then all good. If instead the TC escalates > again to DAM, then I'll remove the package again, and work to find an > alternative that you can use with networkd in the cloud images, and try > and find time to implement it. > > How does this sound? Well, we obviously would prefer to find a solution that doesn't involve removing networkd altogether, should it come to that, but I'd hope we don't get to that point. noah From stefanor at debian.org Tue Apr 1 21:47:25 2025 From: stefanor at debian.org (Stefano Rivera) Date: Tue, 1 Apr 2025 20:47:25 +0000 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: Hi Luca (2025.04.01_18:06:38_+0000) >More generically, if you haven't seen on the MR, I had proposed several >alternatives to the submitter that are much safer and clearer, such as >a package conflict. The MR submitter's answer to the _mere suggestion_ >was escalating to DAM. Again, let me clarify: The matter had already been escalated to DAM, when the NMU was canceled without any obvious sign that the CTTE's decision was going to be followed. DAM's involvement is not the result of any discussion on any MR. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 From bluca at debian.org Tue Apr 1 21:59:44 2025 From: bluca at debian.org (Luca Boccassi) Date: Tue, 1 Apr 2025 20:59:44 +0000 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: On Tue, 1 Apr 2025 at 19:50, Noah Meyerhans wrote: > > On Tue, Apr 01, 2025 at 07:06:38PM +0100, Luca Boccassi wrote: > > Do the cloud images use avahi at all? Assuming I'm looking at the right > > manifest: > > > > https://cdimage.debian.org/images/cloud/trixie/daily/20250324-2061/debian-13-generic-amd64-daily-20250324-2061.json > > No, in fact most cloud environments don't support multicast networking > at all, so disabling it is entirely safe. > > > it seems not, so how about this: I'll take a personal risk and we can > > try once more with the pkg conflict. I'll reinstate the package, with > > an added "Conflicts: avahi-daemon" so that users have to choose one or > > the other, and avahi is the default so it always wins unless someone > > has very specific and customized use cases like yours. > > That works for me. > > > If everything goes fine, then all good. If instead the TC escalates > > again to DAM, then I'll remove the package again, and work to find an > > alternative that you can use with networkd in the cloud images, and try > > and find time to implement it. > > > > How does this sound? > > Well, we obviously would prefer to find a solution that doesn't involve > removing networkd altogether, should it come to that, but I'd hope we > don't get to that point. LOL, he already escalated, not even had time to rinse the changes through the CI and he already got them to send a warning. Guess he had the complaint ready to send to DAM in the draft folder. That answers the question of whether it's safe to add back resolved then - you mentioned you don't need the stub resolver, but just something to manage dhcp -> networkd -> resolve.conf, right? I think I can cook something up, I'll get on that next, who needs sleep anyway From noahm at debian.org Tue Apr 1 22:04:53 2025 From: noahm at debian.org (Noah Meyerhans) Date: Tue, 1 Apr 2025 17:04:53 -0400 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: On Tue, Apr 01, 2025 at 08:47:25PM +0000, Stefano Rivera wrote: > Hi Luca (2025.04.01_18:06:38_+0000) > > More generically, if you haven't seen on the MR, I had proposed several > > alternatives to the submitter that are much safer and clearer, such as > > a package conflict. The MR submitter's answer to the _mere suggestion_ > > was escalating to DAM. > > Again, let me clarify: The matter had already been escalated to DAM, when > the NMU was canceled without any obvious sign that the CTTE's decision was > going to be followed. > > DAM's involvement is not the result of any discussion on any MR. Is the TC opposed to Luca's earlier proposal to add back systemd-resolved with a Conflicts relationship on avahi-daemon? noah From noahm at debian.org Tue Apr 1 22:06:59 2025 From: noahm at debian.org (Noah Meyerhans) Date: Tue, 1 Apr 2025 17:06:59 -0400 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: On Tue, Apr 01, 2025 at 08:59:44PM +0000, Luca Boccassi wrote: > > > Do the cloud images use avahi at all? Assuming I'm looking at the right > > > manifest: > > > > > > https://cdimage.debian.org/images/cloud/trixie/daily/20250324-2061/debian-13-generic-amd64-daily-20250324-2061.json > > > > No, in fact most cloud environments don't support multicast networking > > at all, so disabling it is entirely safe. > > > > > it seems not, so how about this: I'll take a personal risk and we can > > > try once more with the pkg conflict. I'll reinstate the package, with > > > an added "Conflicts: avahi-daemon" so that users have to choose one or > > > the other, and avahi is the default so it always wins unless someone > > > has very specific and customized use cases like yours. > > > > That works for me. > > > > > If everything goes fine, then all good. If instead the TC escalates > > > again to DAM, then I'll remove the package again, and work to find an > > > alternative that you can use with networkd in the cloud images, and try > > > and find time to implement it. > > > > > > How does this sound? > > > > Well, we obviously would prefer to find a solution that doesn't involve > > removing networkd altogether, should it come to that, but I'd hope we > > don't get to that point. > > LOL, he already escalated, not even had time to rinse the changes > through the CI and he already got them to send a warning. Guess he had > the complaint ready to send to DAM in the draft folder. > > That answers the question of whether it's safe to add back resolved > then - you mentioned you don't need the stub resolver, but just > something to manage dhcp -> networkd -> resolve.conf, right? I think I > can cook something up, I'll get on that next, who needs sleep anyway Please let's not get ahead of ourselves. I think Stefano was simply pointing out something that had happned in the past, not any new DAM involvement. Keeping systemd-resolved in place is vastly preferable to any cloud-specific workaround. We used to have such a thing, before moving to systemd-networkd/resolved, and are not excited about the prospect of going back thered. noah From bluca at debian.org Tue Apr 1 22:10:20 2025 From: bluca at debian.org (Luca Boccassi) Date: Tue, 1 Apr 2025 21:10:20 +0000 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: On Tue, 1 Apr 2025 at 22:07, Noah Meyerhans wrote: > > On Tue, Apr 01, 2025 at 08:59:44PM +0000, Luca Boccassi wrote: > > > > Do the cloud images use avahi at all? Assuming I'm looking at the right > > > > manifest: > > > > > > > > https://cdimage.debian.org/images/cloud/trixie/daily/20250324-2061/debian-13-generic-amd64-daily-20250324-2061.json > > > > > > No, in fact most cloud environments don't support multicast networking > > > at all, so disabling it is entirely safe. > > > > > > > it seems not, so how about this: I'll take a personal risk and we can > > > > try once more with the pkg conflict. I'll reinstate the package, with > > > > an added "Conflicts: avahi-daemon" so that users have to choose one or > > > > the other, and avahi is the default so it always wins unless someone > > > > has very specific and customized use cases like yours. > > > > > > That works for me. > > > > > > > If everything goes fine, then all good. If instead the TC escalates > > > > again to DAM, then I'll remove the package again, and work to find an > > > > alternative that you can use with networkd in the cloud images, and try > > > > and find time to implement it. > > > > > > > > How does this sound? > > > > > > Well, we obviously would prefer to find a solution that doesn't involve > > > removing networkd altogether, should it come to that, but I'd hope we > > > don't get to that point. > > > > LOL, he already escalated, not even had time to rinse the changes > > through the CI and he already got them to send a warning. Guess he had > > the complaint ready to send to DAM in the draft folder. > > > > That answers the question of whether it's safe to add back resolved > > then - you mentioned you don't need the stub resolver, but just > > something to manage dhcp -> networkd -> resolve.conf, right? I think I > > can cook something up, I'll get on that next, who needs sleep anyway > > Please let's not get ahead of ourselves. I think Stefano was simply > pointing out something that had happned in the past, not any new DAM > involvement. Sorry I should have been clearer: when I said warning, I literally meant it, and I was not talking about Stefano. An hour after sending the previous message, and while I was already working to add the package back (proof: https://salsa.debian.org/bluca/systemd/-/commit/5067878f3a691fb7a1dd1df30ca9c78935c50479 ), this loveliness popped up in my inbox: date: 1 Apr 2025, 21:46 subject: DAM warning for continuing to ignore Technical Committee decisions From noahm at debian.org Tue Apr 1 22:22:49 2025 From: noahm at debian.org (Noah Meyerhans) Date: Tue, 1 Apr 2025 17:22:49 -0400 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: On Tue, Apr 01, 2025 at 09:10:20PM +0000, Luca Boccassi wrote: > > Please let's not get ahead of ourselves. I think Stefano was simply > > pointing out something that had happned in the past, not any new DAM > > involvement. > > Sorry I should have been clearer: when I said warning, I literally > meant it, and I was not talking about Stefano. An hour after sending > the previous message, and while I was already working to add the > package back (proof: > https://salsa.debian.org/bluca/systemd/-/commit/5067878f3a691fb7a1dd1df30ca9c78935c50479 > ), this loveliness popped up in my inbox: > > date: 1 Apr 2025, 21:46 > subject: DAM warning for continuing to ignore Technical Committee decisions Understood. I'm still trying to work out how to process this, but me reiterate my position that the removal of systemd-networkd from trixie is the worst possible outcome of this discussion so far. noah From bluca at debian.org Tue Apr 1 22:35:02 2025 From: bluca at debian.org (Luca Boccassi) Date: Tue, 1 Apr 2025 21:35:02 +0000 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: On Tue, 1 Apr 2025 at 22:22, Noah Meyerhans wrote: > > On Tue, Apr 01, 2025 at 09:10:20PM +0000, Luca Boccassi wrote: > > > Please let's not get ahead of ourselves. I think Stefano was simply > > > pointing out something that had happned in the past, not any new DAM > > > involvement. > > > > Sorry I should have been clearer: when I said warning, I literally > > meant it, and I was not talking about Stefano. An hour after sending > > the previous message, and while I was already working to add the > > package back (proof: > > https://salsa.debian.org/bluca/systemd/-/commit/5067878f3a691fb7a1dd1df30ca9c78935c50479 > > ), this loveliness popped up in my inbox: > > > > date: 1 Apr 2025, 21:46 > > subject: DAM warning for continuing to ignore Technical Committee decisions > > Understood. I'm still trying to work out how to process this, but me > reiterate my position that the removal of systemd-networkd from trixie > is the worst possible outcome of this discussion so far. I don't think we need to rework networkd's integration, I just meant the use of resolved to manage resolv.conf. From hertzog at debian.org Tue Apr 1 22:36:52 2025 From: hertzog at debian.org (Raphael Hertzog) Date: Tue, 1 Apr 2025 23:36:52 +0200 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: <721663dc354a22345afb4df73a298a027d369b53.camel@debian.org> References: <721663dc354a22345afb4df73a298a027d369b53.camel@debian.org> Message-ID: Hi, On Tue, 01 Apr 2025, Luca Boccassi wrote: > > We don't care. Nobody wants to see systemd-resolved removed from Debian. > > Excuse me, but could you please clarify who is "we" in this statement? > Are you speaking for the Release Team here? No, I'm not part of the release team. But besides you, I have seen no other DD that was asking for the removal of systemd-resolved (including nobody in the tech-ctte). So while I can't officially speak for the vast majority of DD, and while that "we" was meant as "we the Debian project", I wanted you to realize that it were to come to a GR, the vast majority of DD would prefer to keep systemd-resolved (with or without the patch that you are objecting to) over removing it from the archive. Cheers, -- ??????? Rapha?l Hertzog ??????? ?????? The Debian Handbook: https://debian-handbook.info/get/ ??????? Debian Long Term Support: https://deb.li/LTS From noahm at debian.org Tue Apr 1 22:42:20 2025 From: noahm at debian.org (Noah Meyerhans) Date: Tue, 1 Apr 2025 17:42:20 -0400 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: On Tue, Apr 01, 2025 at 09:35:02PM +0000, Luca Boccassi wrote: > > > > Please let's not get ahead of ourselves. I think Stefano was simply > > > > pointing out something that had happned in the past, not any new DAM > > > > involvement. > > > > > > Sorry I should have been clearer: when I said warning, I literally > > > meant it, and I was not talking about Stefano. An hour after sending > > > the previous message, and while I was already working to add the > > > package back (proof: > > > https://salsa.debian.org/bluca/systemd/-/commit/5067878f3a691fb7a1dd1df30ca9c78935c50479 > > > ), this loveliness popped up in my inbox: > > > > > > date: 1 Apr 2025, 21:46 > > > subject: DAM warning for continuing to ignore Technical Committee decisions > > > > Understood. I'm still trying to work out how to process this, but me > > reiterate my position that the removal of systemd-networkd from trixie > > is the worst possible outcome of this discussion so far. > > I don't think we need to rework networkd's integration, I just meant > the use of resolved to manage resolv.conf. I know, and I'm sure we can extract the DHCP lease's DNS info from networkd over dbus and craft a resolv.conf... but it's still a bespoke solution that exists nowhere else. And in trixie we have enabled libnss-resolve (we didn't in bookworm), which we'd lose with this change. So it's still not ideal. From bluca at debian.org Tue Apr 1 23:32:45 2025 From: bluca at debian.org (Luca Boccassi) Date: Tue, 1 Apr 2025 22:32:45 +0000 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: On Tue, 1 Apr 2025 at 21:47, Stefano Rivera wrote: > > Hi Luca (2025.04.01_18:06:38_+0000) > >More generically, if you haven't seen on the MR, I had proposed several > >alternatives to the submitter that are much safer and clearer, such as > >a package conflict. The MR submitter's answer to the _mere suggestion_ > >was escalating to DAM. > > Again, let me clarify: The matter had already been escalated to DAM, > when the NMU was canceled without any obvious sign that the CTTE's > decision was going to be followed. > > DAM's involvement is not the result of any discussion on any MR. I'll leave timestamps here just for completeness, whoever reads can make up their own minds about what the sequence of events is. Times in UTC: - Mar 4 11:58: TC is asked to open MRs, not do NMUs - Mar 24 13:42: hostile NMU from TC - Mar 24 13:47: hostile NMU cancelled - Mar 24 13:59: first of several suggestions for implementation details and improvements on MR - Mar 27 14:07: last suggestion on MR - Mar 27 22:32: TC escalates to DAM - Apr 1 19:06: proposal to reintroduce resolved on ML - Apr 1 21:46: TC escalates to DAM From owner at bugs.debian.org Wed Apr 2 00:39:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Tue, 01 Apr 2025 23:39:02 +0000 Subject: Processed (with 1 error): 1101764 1101875 References: Message-ID: Processing commands for control at bugs.debian.org: > tags 1101764 wontfix Bug #1101764 [systemd] systemd: networkd largely useless without resolved Added tag(s) wontfix. > close 1101764 Bug #1101764 [systemd] systemd: networkd largely useless without resolved Marked Bug as done > forcemerge 1101532 1101875 Bug #1101532 [src:systemd] systemd: unable to migrate to Testing because of removed packages Bug #1101762 [src:systemd] systemd - uncoordinated removal of systemd-resolved Unable to merge bugs because: package of #1101875 is 'systemd-resolved' not 'src:systemd' Failed to forcibly merge 1101532: Did not alter merged bugs. > End of message, stopping processing here. Please contact me if you need assistance. -- 1101532: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101532 1101762: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101762 1101764: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101764 1101875: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101875 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Wed Apr 2 00:42:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Tue, 01 Apr 2025 23:42:02 +0000 Subject: Processed: close 1084023 References: Message-ID: Processing commands for control at bugs.debian.org: > close 1084023 257.4-4 Bug #1084023 [src:systemd] systemd: please stop conflicting with opensysusers 0.7.3-4 and newer Marked as fixed in versions systemd/257.4-4. Bug #1084023 [src:systemd] systemd: please stop conflicting with opensysusers 0.7.3-4 and newer Marked Bug as done > End of message, stopping processing here. Please contact me if you need assistance. -- 1084023: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084023 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From stefanor at debian.org Wed Apr 2 00:42:26 2025 From: stefanor at debian.org (Stefano Rivera) Date: Tue, 1 Apr 2025 23:42:26 +0000 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: Hi Luca (2025.04.01_22:32:45_+0000) I don't think getting into the timeline nitty gritty is the most productive thing we can do, but let me give you the context that you're missing. Skip over this part of my email, if you want to get onto productive bits. >- Mar 4 11:58: TC is asked to open MRs, not do NMUs I think you mean March 14. I know that some TC members had some personal contact with you, but I don't have any email from you sent on that date. I have seen a message you sent Matthew (our chair) on March 14, that says that you will not accept NMUs. However, I don't think it's really OK for any project members to say that their packages are not NMUable. NMUs are always an option available to the project when package maintainers are MIA and something needs to be done. I imagine the rest of the project thinks similarly. As a committee member, I never want to have to rule to override a package maintainer. That's a heavy responsibility, and not a great option to have to take. If the package maintainer doesn't accept the ruling, then the project is having to lose the maintainer. But in this case, the options in front of the committee were ruling to override one or another set of package maintainers, that's where we found ourselves. When you think about the TC rulings in that context, a refusal to accept an NMU to implement the TC ruling reads as an unwillingness to allow the TC to overrule the maintainer. How else are we going to get a TC ruling implemented, when overriding a maintainer. We can't expect them to do the work themselves, and we can't expect them to approve of the changes in code review. That's going to blow up (like this did). I'm afraid our constitution doesn't allow leeway here. These are situations that get DAM involved. >- Mar 27 22:32: TC escalates to DAM That timestamp is when DAM contacted you, not when the matter was escalated to them. That had come a day and a half earlier, impressively quick action, if you ask me. The decision to make that escalation had come from discussion over the previous several days. The discussions we were having in the MR were in parallel to this escalation process. Obviously, if we'd been making progress in the MR, DAM may have stood back, or we may have paused the escalation process a little longer. But the wheels were in motion as soon as the NMU was cancelled (and comments were posted in the MR that made it clear that the changes in the NMU weren't acceptable to you). I reached out to you on IRC when I could see that this process was getting under way and I was looking for a way to de-escalate. It was a long shot, but sadly we didn't get there. I think it was interpreted as a threat, instead. >- Apr 1 21:46: TC escalates to DAM There was no second escalation. I think that was just DAM cogs turning. They issued a warning today. Let's try to get back onto productive threads of discussion: Speaking for myself, but I imagine the rest of the committee thinks similarly, we did not want to see the removal of systemd-resolved or systemd-nspawn. These options were never even on the table to vote, as nobody requested them. They're radical and seem reactionary, I'm assuming we'll be able to find a better way. From my PoV the patches Helmut posted still seem like the most reasonable solution to the issues at hand, but if there are better options that weren't considered, we can consider them. The constitution doesn't (to my reading) block us from taking a second bite at a problem, *but* that's going to be an exceptional process. There'd have to be some significant change in the problem space to make that happen. I don't think it's OK for maintainers who have been overridden by the TC to blackmail the project into forcing TC decisions to be overturned (or DAM to remove the maintainer). Bad TC decisions can be overridden by GR (wit ha high cost in process). And you can work with the TC to help find a workable solution. Really, that should have happened before we voted, but better late than never. We're here, and we can discuss options forward. I think Helmut's proposed patches are worth considering seriously. I know you don't, but I don't know exactly why. Explaining your reasoning would *really* help us to understand your position. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 From owner at bugs.debian.org Wed Apr 2 00:45:03 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Tue, 01 Apr 2025 23:45:03 +0000 Subject: Processed: 1101875 References: <02346f69db3f401bec2247e8d97cc50b3ded3e4a.camel@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > reassign 1101875 src:systemd Bug #1101875 [systemd-resolved] systemd-resolved: Unable to satisfy dependencies, none of the choices are installable Bug reassigned from package 'systemd-resolved' to 'src:systemd'. No longer marked as found in versions systemd/257.4-3. Ignoring request to alter fixed versions of bug #1101875 to the same values previously set > forcemerge 1101532 1101875 Bug #1101532 [src:systemd] systemd: unable to migrate to Testing because of removed packages Bug #1101762 [src:systemd] systemd - uncoordinated removal of systemd-resolved Bug #1101875 [src:systemd] systemd-resolved: Unable to satisfy dependencies, none of the choices are installable Severity set to 'serious' from 'grave' Marked as found in versions systemd/257.4-7 and systemd/257.4-5. Bug #1101762 [src:systemd] systemd - uncoordinated removal of systemd-resolved Merged 1101532 1101762 1101875 > End of message, stopping processing here. Please contact me if you need assistance. -- 1101532: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101532 1101762: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101762 1101875: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101875 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From bluca at debian.org Wed Apr 2 00:56:44 2025 From: bluca at debian.org (Luca Boccassi) Date: Tue, 1 Apr 2025 23:56:44 +0000 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: On Tue, 1 Apr 2025 at 22:42, Noah Meyerhans wrote: > > On Tue, Apr 01, 2025 at 09:35:02PM +0000, Luca Boccassi wrote: > > > > > Please let's not get ahead of ourselves. I think Stefano was simply > > > > > pointing out something that had happned in the past, not any new DAM > > > > > involvement. > > > > > > > > Sorry I should have been clearer: when I said warning, I literally > > > > meant it, and I was not talking about Stefano. An hour after sending > > > > the previous message, and while I was already working to add the > > > > package back (proof: > > > > https://salsa.debian.org/bluca/systemd/-/commit/5067878f3a691fb7a1dd1df30ca9c78935c50479 > > > > ), this loveliness popped up in my inbox: > > > > > > > > date: 1 Apr 2025, 21:46 > > > > subject: DAM warning for continuing to ignore Technical Committee decisions > > > > > > Understood. I'm still trying to work out how to process this, but me > > > reiterate my position that the removal of systemd-networkd from trixie > > > is the worst possible outcome of this discussion so far. > > > > I don't think we need to rework networkd's integration, I just meant > > the use of resolved to manage resolv.conf. > > I know, and I'm sure we can extract the DHCP lease's DNS info from > networkd over dbus and craft a resolv.conf... but it's still a bespoke > solution that exists nowhere else. And in trixie we have enabled > libnss-resolve (we didn't in bookworm), which we'd lose with this > change. So it's still not ideal. I hear you. You know what, I'll upload it anyway, given I've prepped it. It's not like it's going to _really_ make any difference anyway, it's pretty obvious they have already made their minds up many months ago, when we rejected that nonsensical upstream PR back in October. Might as well fix your use case while I can. Once again, I never intended to break your image builds, sorry for the disruption. From owner at bugs.debian.org Wed Apr 2 01:03:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Wed, 02 Apr 2025 00:03:02 +0000 Subject: Processed: Bug#1101532 marked as pending in systemd References: <67ec7d9bd74ea_1180c5102c207d9@godard.mail> Message-ID: Processing control commands: > tag -1 pending Bug #1101532 [src:systemd] systemd: unable to migrate to Testing because of removed packages Bug #1101762 [src:systemd] systemd - uncoordinated removal of systemd-resolved Bug #1101875 [src:systemd] systemd-resolved: Unable to satisfy dependencies, none of the choices are installable Added tag(s) pending. Added tag(s) pending. Added tag(s) pending. -- 1101532: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101532 1101762: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101762 1101875: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101875 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From ftpmaster at ftp-master.debian.org Wed Apr 2 01:08:29 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Wed, 02 Apr 2025 00:08:29 +0000 Subject: Processing of systemd_257.4-8_source.changes Message-ID: systemd_257.4-8_source.changes uploaded successfully to localhost along with the files: systemd_257.4-8.dsc systemd_257.4-8.debian.tar.xz systemd_257.4-8_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org) From ftpmaster at ftp-master.debian.org Wed Apr 2 01:21:33 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Wed, 02 Apr 2025 00:21:33 +0000 Subject: systemd_257.4-8_source.changes ACCEPTED into unstable Message-ID: Thank you for your contribution to Debian. Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Tue, 01 Apr 2025 21:43:18 +0100 Source: systemd Architecture: source Version: 257.4-8 Distribution: unstable Urgency: medium Maintainer: Debian systemd Maintainers Changed-By: Luca Boccassi Closes: 1101532 1101698 Changes: systemd (257.4-8) unstable; urgency=medium . [ Luca Boccassi ] * systemd.preinst: do not use systemctl libsystemd-shared might not be unpacked yet, so check things manually (Closes: #1101698) * systemd.preinst: fix shellcheck warnings * d/t/boot-and-services: skip gdm3 test in nested LXD run. It is flaky and fails half the times, not much value in checking a desktop session inside a nested container * reintroduce systemd-resolved, with conflict on avahi-daemon. It turns out the cloud images have a hard dependency on resolved. In order to avoid having to change them, reintroduce the package, with a hard conflict on avahi-daemon to avoid reintroducing #1098914 (Closes: #1101532) . [ Yu Watanabe ] * d/rules: drop nscd meson option. The meson option was deprecated by 28f1f1a5e652508d6e61ace8918e8b831e4b62b4 (v257). Checksums-Sha1: fc89661f8d6a3e0628bd63f57720d0338748d9aa 8615 systemd_257.4-8.dsc 87b6d69fc7997939d346a50393ac357a353197d3 181968 systemd_257.4-8.debian.tar.xz f387baa21d593276f8f29f79155551288e336a7a 13950 systemd_257.4-8_source.buildinfo Checksums-Sha256: da981a464067b56d4a79db136d6eb0b8fe7f2d40891f781fa0a09c80f4d3ba84 8615 systemd_257.4-8.dsc 7da3abe112127f0bda9ca8679179dc2fe36d27f3c15789c30d15b5e7534a3674 181968 systemd_257.4-8.debian.tar.xz a41124e725fa2218efc9d2cf57550ae4d0786ab8ba6c8e73add1a5ce3050b38d 13950 systemd_257.4-8_source.buildinfo Files: 885d5a412f5ec0ea4aea94a97609e5b6 8615 admin optional systemd_257.4-8.dsc 6709aaa4ba46cb0cbda9ea473661d859 181968 admin optional systemd_257.4-8.debian.tar.xz f47f0a6e420e1edd22c6b95ca54579e3 13950 admin optional systemd_257.4-8_source.buildinfo -----BEGIN PGP SIGNATURE----- iQJFBAEBCgAvFiEErCSqx93EIPGOymuRKGv37813JB4FAmfsfbYRHGJsdWNhQGRl Ymlhbi5vcmcACgkQKGv37813JB6lHBAAin8pBQyX0dWEx1h+v0X4LWeMi5jnHLmS FKFT8uYRcBFdmAGucB0U4Ufts41KEqwpNCymJW6ueW/GXe5U1wmYKbrwkp5kbIGt vJePfleNOIAWojcCrH/PE3vZ1c2MLbPJwbGEsHbMAfqbF2P/0dq0W+nyno6BI9x0 IcN2chF+oVLnP8NCwGwUXnere9RZ98crb9U02wVnL3oQrkOKt3gj3lbuqXHMrGHl FVO7N5uGythNOWDblwUnk07LEQayxkn6UzHFcpRTYZ4fgpwynXjKclTL9KRxOhuZ XBrRLq6+MigGeFbUCuRD0jlaIBZfSocGYbDEEuFESeTdQvQ//zxwqvomIbMLISLI 4dDSN+GyQIlG1Zv+mVDkWmkbJNig+gSLOz6GNKAxLT9Rn0pmGQuiBAM1eNs/ls9M qgpRytOzIGoxvkdQzZ2z2pwTyZPAI+Fwpwsx2HI0qVuax6Na0LiSTNdqy+PW9Gpj i1Kt9aut3yDaegL1dZNtGtMZqNvch7zXCbDfX3oAc8TpqwDytrsW6y0zQm0nd1p7 A8v6r9jwUxWL4buqgF2Q9wcfrzl65gUZNyFWMu8femcn2CZPjnytoLeAEsZ7Vv1D GDxH8NHC28nF5f3b9L0v76A9rGilQC4h6J3AFPvKDmtZ/yHa/FYZ7gnzHHsavM2o NUwQhO6N1zQ= =b7Vu -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From owner at bugs.debian.org Wed Apr 2 01:24:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Wed, 02 Apr 2025 00:24:02 +0000 Subject: Bug#1101875: marked as done (systemd-resolved: Unable to satisfy dependencies, none of the choices are installable) References: <174352939824.412595.8174951278877514422.reportbug@wraith.lassnig.net> Message-ID: Your message dated Wed, 02 Apr 2025 00:21:33 +0000 with message-id and subject line Bug#1101532: fixed in systemd 257.4-8 has caused the Debian Bug report #1101532, regarding systemd-resolved: Unable to satisfy dependencies, none of the choices are installable to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner at bugs.debian.org immediately.) -- 1101532: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101532 Debian Bug Tracking System Contact owner at bugs.debian.org with problems -------------- next part -------------- An embedded message was scrubbed... From: Mario Lassnig Subject: systemd-resolved: Unable to satisfy dependencies, none of the choices are installable Date: Tue, 01 Apr 2025 19:43:18 +0200 Size: 3094 URL: -------------- next part -------------- An embedded message was scrubbed... From: Debian FTP Masters Subject: Bug#1101532: fixed in systemd 257.4-8 Date: Wed, 02 Apr 2025 00:21:33 +0000 Size: 7531 URL: From owner at bugs.debian.org Wed Apr 2 01:24:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Wed, 02 Apr 2025 00:24:02 +0000 Subject: Bug#1101762: marked as done (systemd - uncoordinated removal of systemd-resolved) References: <20250331160202.r3664tzpvpu37sv3@shell.thinkmo.de> Message-ID: Your message dated Wed, 02 Apr 2025 00:21:33 +0000 with message-id and subject line Bug#1101532: fixed in systemd 257.4-8 has caused the Debian Bug report #1101532, regarding systemd - uncoordinated removal of systemd-resolved to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner at bugs.debian.org immediately.) -- 1101532: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101532 Debian Bug Tracking System Contact owner at bugs.debian.org with problems -------------- next part -------------- An embedded message was scrubbed... From: Bastian Blank Subject: systemd - uncoordinated removal of systemd-resolved Date: Mon, 31 Mar 2025 18:02:02 +0200 Size: 3431 URL: -------------- next part -------------- An embedded message was scrubbed... From: Debian FTP Masters Subject: Bug#1101532: fixed in systemd 257.4-8 Date: Wed, 02 Apr 2025 00:21:33 +0000 Size: 7531 URL: From owner at bugs.debian.org Wed Apr 2 01:24:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Wed, 02 Apr 2025 00:24:02 +0000 Subject: Bug#1101532: marked as done (systemd: unable to migrate to Testing because of removed packages) References: Message-ID: Your message dated Wed, 02 Apr 2025 00:21:33 +0000 with message-id and subject line Bug#1101532: fixed in systemd 257.4-8 has caused the Debian Bug report #1101532, regarding systemd: unable to migrate to Testing because of removed packages to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner at bugs.debian.org immediately.) -- 1101532: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101532 Debian Bug Tracking System Contact owner at bugs.debian.org with problems -------------- next part -------------- An embedded message was scrubbed... From: =?UTF-8?Q?Jeremy_B=C3=ADcha?= Subject: systemd: unable to migrate to Testing because of removed packages Date: Fri, 28 Mar 2025 18:35:41 -0400 Size: 4895 URL: -------------- next part -------------- An embedded message was scrubbed... From: Debian FTP Masters Subject: Bug#1101532: fixed in systemd 257.4-8 Date: Wed, 02 Apr 2025 00:21:33 +0000 Size: 7531 URL: From owner at bugs.debian.org Wed Apr 2 01:24:03 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Wed, 02 Apr 2025 00:24:03 +0000 Subject: Bug#1101698: marked as done (Execution of systemctl in preinstall script can cause problems if libsystemd-shared is already upgraded) References: <174333919703.29953.16441207011133895284.reportbug@ezri> Message-ID: Your message dated Wed, 02 Apr 2025 00:21:33 +0000 with message-id and subject line Bug#1101698: fixed in systemd 257.4-8 has caused the Debian Bug report #1101698, regarding Execution of systemctl in preinstall script can cause problems if libsystemd-shared is already upgraded to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner at bugs.debian.org immediately.) -- 1101698: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101698 Debian Bug Tracking System Contact owner at bugs.debian.org with problems -------------- next part -------------- An embedded message was scrubbed... From: Jan Naumann Subject: Execution of systemctl in preinstall script can cause problems if libsystemd-shared is already upgraded Date: Sun, 30 Mar 2025 14:53:17 +0200 Size: 32290 URL: -------------- next part -------------- An embedded message was scrubbed... From: Debian FTP Masters Subject: Bug#1101698: fixed in systemd 257.4-8 Date: Wed, 02 Apr 2025 00:21:33 +0000 Size: 7573 URL: From i at evsio0n.com Wed Apr 2 01:22:26 2025 From: i at evsio0n.com (Zed Lucas) Date: Wed, 2 Apr 2025 00:22:26 +0000 Subject: Bug#1098914: systemd-resolved removal breaks modern DNS workflows and VPN tools like Tailscale References: <173575466468.4118.5643167462038206714.reportbug@eriador.bigon.be> Message-ID: This is my first time submitting a bug, please let me know if have any questions :) The recent removal of systemd-resolved (Bug#1098914) has caused significant disruption to modern DNS management workflows, particularly for applications like Tailscale that rely on advanced DNS features. This decision contradicts Linux ecosystem best practices outlined in technical analyses such as [The Sisyphean Task Of DNS Client Config on Linux](https://tailscale.com/blog/sisyphean-dns-client-linux/). The main issue here is that there is no alternative/ Ready to use like `systemd-resolved` Debian?s alternatives fail to meet parity: Feature systemd-resolved resolvconf NetworkManager dnsmasq Split DNS ? ? Partial? ? DNSSEC ? ? ? ? DNS-over-TLS ? ? ? ? Per-Interface Config ? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mh+debian-packages at zugschlus.de Wed Apr 2 05:51:10 2025 From: mh+debian-packages at zugschlus.de (Marc Haber) Date: Wed, 2 Apr 2025 06:51:10 +0200 Subject: Bug#1101532: marked as done (systemd: unable to migrate to Testing because of removed packages) In-Reply-To: References: Message-ID: On Wed, Apr 02, 2025 at 12:24:02AM +0000, Debian Bug Tracking System wrote: > * reintroduce systemd-resolved, with conflict on avahi-daemon. It turns > out the cloud images have a hard dependency on resolved. In order to > avoid having to change them, reintroduce the package, with a hard > conflict on avahi-daemon to avoid reintroducing #1098914 (Closes: > #1101532) How would I configure my system when I want resolved to handle unicast DNS resolving (its features are rather nice, for example it handles gracefully when the first of the full service resolvers is down), but need avahi-daemon for service announcements? I might be stupid, but in my understanding the hard conflict forces me to have a local full service resolver running since I can't have systemd-resolved sans mDNS AND avahi-daemon. If my assumption is correct, the current solution breaks existing systems in a worse way than the solution proposed by the TC breaks other systems. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 From mh+debian-packages at zugschlus.de Wed Apr 2 05:52:07 2025 From: mh+debian-packages at zugschlus.de (Marc Haber) Date: Wed, 2 Apr 2025 06:52:07 +0200 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: On Tue, Apr 01, 2025 at 10:32:45PM +0000, Luca Boccassi wrote: >- Mar 24 13:59: first of several suggestions for implementation >details and improvements on MR Which MR are we talking about here? I'd like to read up on that. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 From konomikitten at gmail.com Wed Apr 2 06:11:03 2025 From: konomikitten at gmail.com (Konomi) Date: Wed, 2 Apr 2025 16:11:03 +1100 Subject: Bug#1101532: marked as done (systemd: unable to migrate to Testing because of removed packages) In-Reply-To: References: Message-ID: > How would I configure my system when I want resolved to handle unicast > DNS resolving (its features are rather nice, for example it handles > gracefully when the first of the full service resolvers is down), but > need avahi-daemon for service announcements? I have a similar problem, I have multiple desktops set up to use systemd-resolved as the resolver for dns over tls. I believe gnome depends on avahi which means I would be left unable to use systemd-resolved for dns over tls anymore. I've also convinced multiple people to use systemd-resolved for dns over tls as well, so I believe this would be really disruptive for me and those users as well. As always I appreciate all the effort maintainers put into Debian but I would plead that a different solution is used that doesn't involve removing the option to use systemd-resolved for every gnome user. Konomi From ftpmaster at ftp-master.debian.org Wed Apr 2 06:31:14 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Wed, 02 Apr 2025 05:31:14 +0000 Subject: Processing of systemd-boot-efi-amd64-signed_257.4+8_source.changes Message-ID: systemd-boot-efi-amd64-signed_257.4+8_source.changes uploaded successfully to localhost along with the files: systemd-boot-efi-amd64-signed_257.4+8.dsc systemd-boot-efi-amd64-signed_257.4+8.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org) From ftpmaster at ftp-master.debian.org Wed Apr 2 06:31:14 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Wed, 02 Apr 2025 05:31:14 +0000 Subject: Processing of systemd-boot-efi-arm64-signed_257.4+8_source.changes Message-ID: systemd-boot-efi-arm64-signed_257.4+8_source.changes uploaded successfully to localhost along with the files: systemd-boot-efi-arm64-signed_257.4+8.dsc systemd-boot-efi-arm64-signed_257.4+8.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org) From hertzog at debian.org Wed Apr 2 06:47:03 2025 From: hertzog at debian.org (Raphael Hertzog) Date: Wed, 2 Apr 2025 07:47:03 +0200 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: On Wed, 2 Apr 2025 06:52:07 +0200 Marc Haber wrote: > On Tue, Apr 01, 2025 at 10:32:45PM +0000, Luca Boccassi wrote: > >- Mar 24 13:59: first of several suggestions for implementation > >details and improvements on MR > > Which MR are we talking about here? I'd like to read up on that. I assume this one: https://salsa.debian.org/systemd-team/systemd/-/merge_requests/289 Cheers, -- ??????? Rapha?l Hertzog ??????? ?????? The Debian Handbook: https://debian-handbook.info/get/ ??????? Debian Long Term Support: https://deb.li/LTS From mh+debian-packages at zugschlus.de Wed Apr 2 07:12:25 2025 From: mh+debian-packages at zugschlus.de (Marc Haber) Date: Wed, 2 Apr 2025 08:12:25 +0200 Subject: Bug#1101532: systemd: unable to migrate to Testing because of removed packages In-Reply-To: References: <2827ea6c099f7bb0ae17868b5e9a27de1d07381a.camel@debian.org> <0b57c3478d214ebff9c03c4ac474df276729b8dc.camel@debian.org> Message-ID: On Wed, Apr 02, 2025 at 07:47:03AM +0200, Raphael Hertzog wrote: >On Wed, 2 Apr 2025 06:52:07 +0200 Marc Haber wrote: >> On Tue, Apr 01, 2025 at 10:32:45PM +0000, Luca Boccassi wrote: >> >- Mar 24 13:59: first of several suggestions for implementation >> >details and improvements on MR >> >> Which MR are we talking about here? I'd like to read up on that. > >I assume this one: >https://salsa.debian.org/systemd-team/systemd/-/merge_requests/289 This leaves me speechless. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 From ftpmaster at ftp-master.debian.org Wed Apr 2 07:24:29 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Wed, 02 Apr 2025 06:24:29 +0000 Subject: systemd-boot-efi-arm64-signed_257.4+8_source.changes ACCEPTED into unstable Message-ID: Thank you for your contribution to Debian. Mapping sid to unstable. Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Tue, 01 Apr 2025 21:43:18 +0100 Source: systemd-boot-efi-arm64-signed Architecture: source Version: 257.4+8 Distribution: sid Urgency: high Maintainer: Debian systemd Maintainers Changed-By: Luca Boccassi Changes: systemd-boot-efi-arm64-signed (257.4+8) unstable; urgency=high . * Sign EFI binaries from systemd-boot-efi 257.4-8 . [ Luca Boccassi ] * systemd.preinst: do not use systemctl libsystemd-shared might not be unpacked yet, so check things manually (Closes: #1101698) * systemd.preinst: fix shellcheck warnings * d/t/boot-and-services: skip gdm3 test in nested LXD run. It is flaky and fails half the times, not much value in checking a desktop session inside a nested container * reintroduce systemd-resolved, with conflict on avahi-daemon. It turns out the cloud images have a hard dependency on resolved. In order to avoid having to change them, reintroduce the package, with a hard conflict on avahi-daemon to avoid reintroducing #1098914 (Closes: #1101532) . [ Yu Watanabe ] * d/rules: drop nscd meson option. The meson option was deprecated by 28f1f1a5e652508d6e61ace8918e8b831e4b62b4 (v257). Checksums-Sha1: 691e6177c28042ca6dee3403e6893791f075ae7a 1783 systemd-boot-efi-arm64-signed_257.4+8.dsc 62587d870fc6bdfafef85215ef98b7fe6b56214d 3924 systemd-boot-efi-arm64-signed_257.4+8.tar.xz Checksums-Sha256: c09d96e8948fe876fbac42046d246262451e285a1f5397852b063f5841a81106 1783 systemd-boot-efi-arm64-signed_257.4+8.dsc 2328827cb85c40604a9f2c670f94fb7d98f42ebf808e936ab8c42bd8987298bb 3924 systemd-boot-efi-arm64-signed_257.4+8.tar.xz Files: 0a4f863f7cfd091795477b67b2c0975a 1783 admin optional systemd-boot-efi-arm64-signed_257.4+8.dsc ff3f7aea99f25fde71f55faebbc02ff6 3924 admin optional systemd-boot-efi-arm64-signed_257.4+8.tar.xz -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEfKFfvHEI+gkU+E+di0FRiLdONzYFAmfsyRcACgkQi0FRiLdO NzZTXQ/9EYdNwJScaxZ/1EmdIU/BD2fnoiWOuATiNWlww1i7R5yT+00AiVU0ZhuC ROOIcLV8NmRPSbQhWrLqGfhlYusQQAQbVelWiE0OX0GjQj0MCL7iesrDoGF0zi6H PIrxskU+72FpnFMu3oQeNoM4Ogj9i146juh/yre+f+23V+0T/MOyVZkuVN0ytxJs UUG2d9TAWAnDcbaDIFQMuIgcalZfAepWuDXGWwMYolxtwvnP+KqHgMLcoxGMBph3 asyGCeuJX4cWuTYNFALU/B2GP7AVtnEDE29soEQOIQ88GvU789ldV0NLJ9QBcNbF t34JKgW11m2yu+q6nMWK336rzybc20mEuGjUXJdrhNtF+m8K1WUeqIxUILddeJNz 8cbFFZSYpN0XTUuJ0AfbqMedf+/tZwCAUd4LCXV6GRsHtN1/p3X6xJTc2OdJccks 4P2tntT4mCY11qYnCPdczqT6JPBfbvrWUd5S95pmrhkE3SXMNDYjlWk69E73wFUq DmD8A/3lP0oC3ZNiiCLHIC42+FrCybCp/exuT4gIct+1OX4VD5MxDv8H0HzY2D1d HdUIRiKa0q9ADWuuqsl8sN1HPucm7onK+//jYiAZObXuSsxgQRJd4sAOQCDHfQpF mIN5HrUFsJYiMtC9nmdg3C91fd0ljHgTgIspoaxEAZi2QV+L9H4= =T4T1 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From ftpmaster at ftp-master.debian.org Wed Apr 2 07:24:25 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Wed, 02 Apr 2025 06:24:25 +0000 Subject: systemd-boot-efi-amd64-signed_257.4+8_source.changes ACCEPTED into unstable Message-ID: Thank you for your contribution to Debian. Mapping sid to unstable. Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Tue, 01 Apr 2025 21:43:18 +0100 Source: systemd-boot-efi-amd64-signed Architecture: source Version: 257.4+8 Distribution: sid Urgency: high Maintainer: Debian systemd Maintainers Changed-By: Luca Boccassi Changes: systemd-boot-efi-amd64-signed (257.4+8) unstable; urgency=high . * Sign EFI binaries from systemd-boot-efi 257.4-8 . [ Luca Boccassi ] * systemd.preinst: do not use systemctl libsystemd-shared might not be unpacked yet, so check things manually (Closes: #1101698) * systemd.preinst: fix shellcheck warnings * d/t/boot-and-services: skip gdm3 test in nested LXD run. It is flaky and fails half the times, not much value in checking a desktop session inside a nested container * reintroduce systemd-resolved, with conflict on avahi-daemon. It turns out the cloud images have a hard dependency on resolved. In order to avoid having to change them, reintroduce the package, with a hard conflict on avahi-daemon to avoid reintroducing #1098914 (Closes: #1101532) . [ Yu Watanabe ] * d/rules: drop nscd meson option. The meson option was deprecated by 28f1f1a5e652508d6e61ace8918e8b831e4b62b4 (v257). Checksums-Sha1: ac8aff58669908425f9162064379348a731786fe 1783 systemd-boot-efi-amd64-signed_257.4+8.dsc d592f4539b531b8dfce7be185dcdd0cce2a46c63 3920 systemd-boot-efi-amd64-signed_257.4+8.tar.xz Checksums-Sha256: d07eb8af298426718922f2b043ac24904590810526c3a605598ea8581d685ee3 1783 systemd-boot-efi-amd64-signed_257.4+8.dsc 74a45c2fb51c3bb96cdd6f8f9f18b00e82410e88af4bf031859fdf6ccf46d84b 3920 systemd-boot-efi-amd64-signed_257.4+8.tar.xz Files: 5e5ac02290ce8349acb94d90c6407100 1783 admin optional systemd-boot-efi-amd64-signed_257.4+8.dsc 4b3dfbaa9dad56831fc1592f93b3ae83 3920 admin optional systemd-boot-efi-amd64-signed_257.4+8.tar.xz -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEfKFfvHEI+gkU+E+di0FRiLdONzYFAmfsyQwACgkQi0FRiLdO NzamXQ/+OHtW848xGOQZZxWC+lDJv1xn4Hr1YDAS83OGRlO6/BGy+DOofccjd4kU Apx13APA6ggeeMhigLsEk58iPFA5YOm4uONtcYv0aLE+/gqz+yuH0Xh8d6RW0eKg t/UxbNYh772vJDrXlQx8nwqyoSVBQlu9qlmxW5Wa2PsXE+atSZ0MutGxRgqpuZzD wul3zasCU/T8S7rVDleiz6ottYn+/wxxJDdfDRTBDxAWGFRZc1TuXYUd4+1bCPpa Sg+5UW3rCnIgC+mTdVV3fjFVLJBfPChQS+BfYO1Gv788UmD0t4XbbbuOXSu27fyt WcBQXLwVpIbottXu2bWC0H2mk8E2rH17nt31S/CDkXlcDHIwHtCT3HgrFvb/FjGU SGJf4G1OTH84+HuOfYmhYKWsudVVN5Ps65qbp7G9n6CcBdwHF98iFznL3V8V9Lct y4Swzkb4akdf+w9vZJjHhknL0GXzkzMq2oSPYDscqtwM2orNoVb4Jy7Dn40QeBcg V0G0gZxygWrJgnHGMSNAhEO1xp+b9JTwRavcJHkyPuRDrPOeKeYxa3HvGhSvG0EA b3JiJpc085oL/By7c+PFoDk+RDZueqe4oxXi9ueNsSSbRXn4GAFcuGz0glOtTqU6 tM4AjwxOHbi8meOFTRX8U2SiPchPAFUozYkwOHvO2m3oZ3Kai7w= =d8/H -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From waldi at debian.org Wed Apr 2 07:21:59 2025 From: waldi at debian.org (Bastian Blank) Date: Wed, 2 Apr 2025 08:21:59 +0200 Subject: Bug#1101762: closed by Debian FTP Masters (reply to Luca Boccassi ) (Bug#1101532: fixed in systemd 257.4-8) In-Reply-To: References: <20250331160202.r3664tzpvpu37sv3@shell.thinkmo.de> <20250331160202.r3664tzpvpu37sv3@shell.thinkmo.de> Message-ID: <20250402062159.n4xcb5qn5xu46vmc@shell.thinkmo.de> Control: reopen -1 On Wed, Apr 02, 2025 at 12:24:02AM +0000, Debian Bug Tracking System wrote: > * reintroduce systemd-resolved, with conflict on avahi-daemon. It turns > out the cloud images have a hard dependency on resolved. In order to > avoid having to change them, reintroduce the package, with a hard > conflict on avahi-daemon to avoid reintroducing #1098914 (Closes: > #1101532) Are you out of your mind? Anyway, I will not longer wait with just NMUing this change away completely. You have been officialy warned. Bastian -- The face of war has never changed. Surely it is more logical to heal than to kill. -- Surak of Vulcan, "The Savage Curtain", stardate 5906.5 From owner at bugs.debian.org Wed Apr 2 07:27:03 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Wed, 02 Apr 2025 06:27:03 +0000 Subject: Processed: Re: Bug#1101762 closed by Debian FTP Masters (reply to Luca Boccassi ) (Bug#1101532: fixed in systemd 257.4-8) References: <20250402062159.n4xcb5qn5xu46vmc@shell.thinkmo.de> <20250331160202.r3664tzpvpu37sv3@shell.thinkmo.de> Message-ID: Processing control commands: > reopen -1 Bug #1101762 {Done: Luca Boccassi } [src:systemd] systemd - uncoordinated removal of systemd-resolved Bug #1101532 {Done: Luca Boccassi } [src:systemd] systemd: unable to migrate to Testing because of removed packages Bug #1101875 {Done: Luca Boccassi } [src:systemd] systemd-resolved: Unable to satisfy dependencies, none of the choices are installable 'reopen' may be inappropriate when a bug has been closed with a version; all fixed versions will be cleared, and you may need to re-add them. Bug reopened No longer marked as fixed in versions systemd/257.4-8. No longer marked as fixed in versions systemd/257.4-8. No longer marked as fixed in versions systemd/257.4-8. -- 1101532: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101532 1101762: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101762 1101875: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101875 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From bluca at debian.org Wed Apr 2 10:08:06 2025 From: bluca at debian.org (Luca Boccassi) Date: Wed, 02 Apr 2025 10:08:06 +0100 Subject: Bug#1101532: marked as done (systemd: unable to migrate to Testing because of removed packages) In-Reply-To: References: Message-ID: <39ee24ef00e39f9d404c437b68084fd017b57a21.camel@debian.org> On Wed, 2 Apr 2025 06:51:10 +0200 Marc Haber wrote: > On Wed, Apr 02, 2025 at 12:24:02AM +0000, Debian Bug Tracking System wrote: > >?? * reintroduce systemd-resolved, with conflict on avahi-daemon. It turns > >???? out the cloud images have a hard dependency on resolved. In order to > >???? avoid having to change them, reintroduce the package, with a hard > >???? conflict on avahi-daemon to avoid reintroducing #1098914 (Closes: > >???? #1101532) > > How would I configure my system when I want resolved to handle unicast > DNS resolving (its features are rather nice, for example it handles > gracefully when the first of the full service resolvers is down), but > need avahi-daemon for service announcements? > > I might be stupid, but in my understanding the hard conflict forces me > to have a local full service resolver running since I can't have > systemd-resolved sans mDNS AND avahi-daemon. If my assumption is > correct, the current solution breaks existing systems in a worse way > than the solution proposed by the TC breaks other systems. > > Greetings > Marc The problem is that, again, _something_ has to break. If it's not your use case, it's someone else's. Both are currently in use, in stable. One has to go. What am I supposed to do, exactly? I can't square a circle, I'm afraid From bluca at debian.org Wed Apr 2 10:14:46 2025 From: bluca at debian.org (Luca Boccassi) Date: Wed, 02 Apr 2025 10:14:46 +0100 Subject: Bug#1101762: closed by Debian FTP Masters (reply to Luca Boccassi ) (Bug#1101532: fixed in systemd 257.4-8) In-Reply-To: <20250402062159.n4xcb5qn5xu46vmc@shell.thinkmo.de> References: <20250331160202.r3664tzpvpu37sv3@shell.thinkmo.de> <20250402062159.n4xcb5qn5xu46vmc@shell.thinkmo.de> <20250331160202.r3664tzpvpu37sv3@shell.thinkmo.de> Message-ID: Control: close -1 257.4-8 On Wed, 2 Apr 2025 08:21:59 +0200 Bastian Blank wrote: > Control: reopen -1 > > On Wed, Apr 02, 2025 at 12:24:02AM +0000, Debian Bug Tracking System wrote: > >??? * reintroduce systemd-resolved, with conflict on avahi-daemon. It turns > >????? out the cloud images have a hard dependency on resolved. In order to > >????? avoid having to change them, reintroduce the package, with a hard > >????? conflict on avahi-daemon to avoid reintroducing #1098914 (Closes: > >????? #1101532) > > Are you out of your mind?? Anyway, I will not longer wait with just > NMUing this change away completely.? You have been officialy warned. > > Bastian I'll remind you that insulting other people on a mailing list is against the CoC, given you seem to have forgotten. Also, please stop playing ping-pong with the BTS. This bug about the removal of a package from unstable is solved, as the package is back in unstable, so please do not reopen it. From owner at bugs.debian.org Wed Apr 2 10:18:03 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Wed, 02 Apr 2025 09:18:03 +0000 Subject: Processed: Re: Bug#1101762 closed by Debian FTP Masters (reply to Luca Boccassi ) (Bug#1101532: fixed in systemd 257.4-8) References: <20250331160202.r3664tzpvpu37sv3@shell.thinkmo.de> Message-ID: Processing control commands: > close -1 257.4-8 Bug #1101762 [src:systemd] systemd - uncoordinated removal of systemd-resolved Bug #1101532 [src:systemd] systemd: unable to migrate to Testing because of removed packages Bug #1101875 [src:systemd] systemd-resolved: Unable to satisfy dependencies, none of the choices are installable Marked as fixed in versions systemd/257.4-8. Marked as fixed in versions systemd/257.4-8. Marked as fixed in versions systemd/257.4-8. Bug #1101762 [src:systemd] systemd - uncoordinated removal of systemd-resolved Bug #1101532 [src:systemd] systemd: unable to migrate to Testing because of removed packages Bug #1101875 [src:systemd] systemd-resolved: Unable to satisfy dependencies, none of the choices are installable Marked Bug as done Marked Bug as done Marked Bug as done -- 1101532: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101532 1101762: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101762 1101875: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101875 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From hertzog at debian.org Wed Apr 2 10:38:20 2025 From: hertzog at debian.org (Raphael Hertzog) Date: Wed, 2 Apr 2025 11:38:20 +0200 Subject: Bug#1101532: marked as done (systemd: unable to migrate to Testing because of removed packages) In-Reply-To: <39ee24ef00e39f9d404c437b68084fd017b57a21.camel@debian.org> References: <39ee24ef00e39f9d404c437b68084fd017b57a21.camel@debian.org> Message-ID: Hi, On Wed, 02 Apr 2025 10:08:06 +0100 Luca Boccassi wrote: > The problem is that, again, _something_ has to break. If it's not your > use case, it's someone else's. Both are currently in use, in stable. > One has to go. > > What am I supposed to do, exactly? I can't square a circle, I'm afraid I can answer that question: follow the decision of the technical committe which has already weighted the pros / cons of the various options. And then if you get blame from the persons experiencing the broken scenario, then you can say "sorry I just followed the decision of the tech-ctte" and not feel guilty. Cheers, -- ??????? Rapha?l Hertzog ??????? ?????? The Debian Handbook: https://debian-handbook.info/get/ ??????? Debian Long Term Support: https://deb.li/LTS From owner at bugs.debian.org Wed Apr 2 10:39:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Wed, 02 Apr 2025 09:39:02 +0000 Subject: Processed: reopening 1098914 References: <1743586593-3989-bts-biebl@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > reopen 1098914 Bug #1098914 {Done: Luca Boccassi } [systemd-resolved] systemd-resolved should disable mDNS in its default installation in Debian trixie 'reopen' may be inappropriate when a bug has been closed with a version; all fixed versions will be cleared, and you may need to re-add them. Bug reopened No longer marked as fixed in versions systemd/257.4-4. > thanks Stopping processing here. Please contact me if you need assistance. -- 1098914: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098914 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Wed Apr 2 10:39:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Wed, 02 Apr 2025 09:39:02 +0000 Subject: Processed: tagging 1098914 References: <1743586621-1124-bts-biebl@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > tags 1098914 - pending Bug #1098914 [systemd-resolved] systemd-resolved should disable mDNS in its default installation in Debian trixie Removed tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 1098914: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098914 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From helmut at subdivi.de Wed Apr 2 11:05:17 2025 From: helmut at subdivi.de (Helmut Grohne) Date: Wed, 2 Apr 2025 12:05:17 +0200 Subject: Bug#1079329: closed by Debian FTP Masters (reply to Luca Boccassi ) (Bug#1079329: fixed in systemd 257.4-6) In-Reply-To: References: <20240822132808.GA149473@subdivi.de> <20240822132808.GA149473@subdivi.de> Message-ID: <20250402100517.GA2023500@subdivi.de> Control: reopen -1 On Sat, Mar 29, 2025 at 01:39:02AM +0000, Debian Bug Tracking System wrote: > It has been closed by Debian FTP Masters (reply to Luca Boccassi ). I'm saddened that rather than addressing the root cause, you declare incompatibility with other components that happen to expose the faulty behavior. The actual problem resides in systemctl switch-root (or rather the implementation of the resulting ipc request). dracut is just one initramfs generator that happens to employ this functionality, but it is not the package causing the problem. I argue that your declared conflict is misdirected. We may easily reproduce the issue using mkosi. In order to make the exercise simple to reproduce locally, I demonstrate it inside a minimal virtual machine created using debvm. debvm-create -z 10G -- --architecture=arm64 --include=mkosi,firmware-linux-free debvm-run Note that mkosi-initrd is unhappy if /usr/lib/firmware does not exist and hence I add firmware-linux-free to populate it with something. That minor issue may be worth fixing in mkosi as well. Once booted, we may use mkosi to create a new initrd. mkosi-initrd -O /boot/ -o initrd.img-$(uname -r) Since debvm cannot notice initrd updates, the machine must be powered off and started again rather than rebooted to experience the problem. Once booted, /lib64 points to usr/lib. I am reproducing the problem with mkosi now, but again it is not mkosi which is at fault here. I ask you to refrain from declaring a conflict with it as well. Helmut From owner at bugs.debian.org Wed Apr 2 11:09:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Wed, 02 Apr 2025 10:09:02 +0000 Subject: Processed: Re: Bug#1079329 closed by Debian FTP Masters (reply to Luca Boccassi ) (Bug#1079329: fixed in systemd 257.4-6) References: <20250402100517.GA2023500@subdivi.de> <20240822132808.GA149473@subdivi.de> Message-ID: Processing control commands: > reopen -1 Bug #1079329 {Done: Luca Boccassi } [systemd] systemd(?) still creates /lib64 on arm64 'reopen' may be inappropriate when a bug has been closed with a version; all fixed versions will be cleared, and you may need to re-add them. Bug reopened No longer marked as fixed in versions systemd/257.4-6. -- 1079329: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079329 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From bluca at debian.org Wed Apr 2 11:06:47 2025 From: bluca at debian.org (Luca Boccassi) Date: Wed, 2 Apr 2025 10:06:47 +0000 Subject: Bug#1101532: marked as done (systemd: unable to migrate to Testing because of removed packages) In-Reply-To: References: <39ee24ef00e39f9d404c437b68084fd017b57a21.camel@debian.org> Message-ID: On Wed, 2 Apr 2025 at 10:38, Raphael Hertzog wrote: > > Hi, > > On Wed, 02 Apr 2025 10:08:06 +0100 Luca Boccassi wrote: > > The problem is that, again, _something_ has to break. If it's not your > > use case, it's someone else's. Both are currently in use, in stable. > > One has to go. > > > > What am I supposed to do, exactly? I can't square a circle, I'm afraid > > I can answer that question: follow the decision of the technical committe > which has already weighted the pros / cons of the various options. > > And then if you get blame from the persons experiencing the broken > scenario, then you can say "sorry I just followed the decision of > the tech-ctte" and not feel guilty. I am somewhat skeptical people suddenly having to deal with inaccessible remote machines will take much comfort in that. But ok, let's try that, at least that particular pleasantness is further down the road, rather than today. From owner at bugs.debian.org Wed Apr 2 11:24:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Wed, 02 Apr 2025 10:24:02 +0000 Subject: Processed: Bug#1098914 marked as pending in systemd References: <67ed0f91b4a6b_1180c5105421538@godard.mail> <173575466468.4118.5643167462038206714.reportbug@eriador.bigon.be> Message-ID: Processing control commands: > tag -1 pending Bug #1098914 [systemd-resolved] systemd-resolved should disable mDNS in its default installation in Debian trixie Added tag(s) pending. -- 1098914: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098914 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From ftpmaster at ftp-master.debian.org Wed Apr 2 11:30:28 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Wed, 02 Apr 2025 10:30:28 +0000 Subject: Processing of systemd_257.4-9_source.changes Message-ID: systemd_257.4-9_source.changes uploaded successfully to localhost along with the files: systemd_257.4-9.dsc systemd_257.4-9.debian.tar.xz systemd_257.4-9_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org) From ftpmaster at ftp-master.debian.org Wed Apr 2 11:35:32 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Wed, 02 Apr 2025 10:35:32 +0000 Subject: systemd_257.4-9_source.changes ACCEPTED into unstable Message-ID: Thank you for your contribution to Debian. Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Wed, 02 Apr 2025 11:19:09 +0100 Source: systemd Architecture: source Version: 257.4-9 Distribution: unstable Urgency: medium Maintainer: Debian systemd Maintainers Changed-By: Luca Boccassi Closes: 1098914 Changes: systemd (257.4-9) unstable; urgency=medium . * resolved: break mDNS, remove conflict with avahi. Feedback from users is to prefer breaking mDNS rather than avoiding avahi. Ship a drop-in to disable mDNS by default, so that users relying on mDNS for reachability can hopefully notice it and mask it before upgrading (Closes: #1098914) Checksums-Sha1: e7f738b7e28fcfd2b71114acb27ebf3a12752df8 8615 systemd_257.4-9.dsc 053b0109a0e2ef03cdd8e9d0f6b6f095fc2039b1 182088 systemd_257.4-9.debian.tar.xz 4d98f4615111773e26354d426d9f967317c8b92a 13950 systemd_257.4-9_source.buildinfo Checksums-Sha256: 7654d4f7acb049668386ae022e08f1b730f0a1f65a628ff4df6ad3e4b3af85ad 8615 systemd_257.4-9.dsc d1118ecea1476c275f3c2f5a85ca62ab1b61fd13ee21ac6f21a8b70b9984de7e 182088 systemd_257.4-9.debian.tar.xz beaa6ae531fd86047db9c7660d13f26a1f73d858f0948ac7e0350b02ff4b602d 13950 systemd_257.4-9_source.buildinfo Files: 4e2420d623150ea6b149a39f930853a8 8615 admin optional systemd_257.4-9.dsc 78e4f3b9144980af1320216b6e9a2e78 182088 admin optional systemd_257.4-9.debian.tar.xz 437855d1877e850c37c6cfb6b8c7c922 13950 admin optional systemd_257.4-9_source.buildinfo -----BEGIN PGP SIGNATURE----- iQJFBAEBCgAvFiEErCSqx93EIPGOymuRKGv37813JB4FAmftDzwRHGJsdWNhQGRl Ymlhbi5vcmcACgkQKGv37813JB45Lg//XSk4nY9CDsvUU33m+mKT0TQRFieotRHM SR5+bUflnUcc0+h5/e0jok7Wg/hUfv/hexUuZR4Esi1B1QqdCb/v6QxUnQlDPJ7s h/QJ3cdE0M7UsWl6OzZDk//xzPCCDID5nxihcXRuBLkCMZvqF6DltH/DPDbkEqkR 6pJIP7SL90dHlWJybMhYu5NuTFwSFckA7oqu/XMBF8cnglwOe6dlEWstCpLpeXLF 5hVzN2f7u4tI2K3Xk/CDcG9PBYmKFSaVsCQ6KIHHH8a27hj4WbKpTETI6zRX1L6k DGkFJwwm52Zq7v4TgdiS9m/NQXnSf17GvWtoh3Wfj342lrLVH6hxIL59XpDKN77e VYrKWHglOVvgstxaiLYB5MoxrlzAkQoaQOGotKPYyrW1fx9+Hyxed7Lhsi5pvLf2 EU1z5xTDlxW3TdTwO3arkZ2byaAQUiE0xbbLU0A4dIjhZYzSIJhjh1gZ70wTR3kp dGLK4tQpuv5UKuWifQO9TrbKyZOWMQJa6+IIXCgaaVPWscPcr2cCIoBtTqN0Y5Vi 8ZmgeNZ5LVdkUm1kFQAFnwv5Y7nU2bhbWPItMjWgI6BpbgyWHbyySySd0cjUldG/ HqBs8K+GbQxxA/OygjhcW6VbrM/LQksWBct+i8P3seSRTtgwzx6ik4kLNbgx4fIa QB2Ab9HwsrU= =6ZH6 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From owner at bugs.debian.org Wed Apr 2 11:39:02 2025 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Wed, 02 Apr 2025 10:39:02 +0000 Subject: Bug#1098914: marked as done (systemd-resolved should disable mDNS in its default installation in Debian trixie) References: <173575466468.4118.5643167462038206714.reportbug@eriador.bigon.be> Message-ID: Your message dated Wed, 02 Apr 2025 10:35:32 +0000 with message-id and subject line Bug#1098914: fixed in systemd 257.4-9 has caused the Debian Bug report #1098914, regarding systemd-resolved should disable mDNS in its default installation in Debian trixie to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner at bugs.debian.org immediately.) -- 1098914: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098914 Debian Bug Tracking System Contact owner at bugs.debian.org with problems -------------- next part -------------- An embedded message was scrubbed... From: Laurent Bigonville Subject: tech-ctte: Avahi and systemd-resolved cannot a run mDNS responder at the same time Date: Wed, 01 Jan 2025 19:04:24 +0100 Size: 4178 URL: -------------- next part -------------- An embedded message was scrubbed... From: Debian FTP Masters Subject: Bug#1098914: fixed in systemd 257.4-9 Date: Wed, 02 Apr 2025 10:35:32 +0000 Size: 6994 URL: From bluca at debian.org Wed Apr 2 12:09:13 2025 From: bluca at debian.org (Luca Boccassi) Date: Wed, 02 Apr 2025 12:09:13 +0100 Subject: Bug#1079329: closed by Debian FTP Masters (reply to Luca Boccassi ) (Bug#1079329: fixed in systemd 257.4-6) In-Reply-To: <20250402100517.GA2023500@subdivi.de> References: <20240822132808.GA149473@subdivi.de> <20250402100517.GA2023500@subdivi.de> <20240822132808.GA149473@subdivi.de> Message-ID: <1dcec63297e71bd0a0cf337c1e15930a70de913f.camel@debian.org> On Wed, 2 Apr 2025 12:05:17 +0200 Helmut Grohne wrote: > Control: reopen -1 > > On Sat, Mar 29, 2025 at 01:39:02AM +0000, Debian Bug Tracking System wrote: > > It has been closed by Debian FTP Masters (reply to Luca Boccassi ). > > I'm saddened that rather than addressing the root cause, you declare > incompatibility with other components that happen to expose the faulty > behavior. Sorry, but this is not a supported combination, and the intention was to make that explicit, in the simplest way possible (ie, so that's it's noticed at build time already). The default initrd generator in Debian is initramfs-tools, that's fully supported. If you wish to experiment with dracut, that's great! You can use it with many init systems (or no init system at all). The particular combination of arm64+dracut+systemd is known bad and unsupported, and any one of those 3 factors can be swapped with something else to get a working solution. You can expect support for defaults, but requiring volunteers to go out of their way and do a huge amount of extra work to support non- standard, non-default corner-case combinations is not ok, sorry. One can ask of course, but one can also say "sorry, but -ENOTIME". Do you have other suggestions on how to best encode this? If not, I could perhaps add an AssertArchitecture=!arm64 to the initrd-only switchroot unit? That is a runtime setting so less ideal as the feedback is not immediate, but it would allow tinkerers to break the warranty seal, mask it and do strange things on the other hand, which is nicer. From ftpmaster at ftp-master.debian.org Wed Apr 2 12:31:34 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Wed, 02 Apr 2025 11:31:34 +0000 Subject: Processing of systemd-boot-efi-amd64-signed_257.4+9_source.changes Message-ID: systemd-boot-efi-amd64-signed_257.4+9_source.changes uploaded successfully to localhost along with the files: systemd-boot-efi-amd64-signed_257.4+9.dsc systemd-boot-efi-amd64-signed_257.4+9.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org) From ftpmaster at ftp-master.debian.org Wed Apr 2 12:39:19 2025 From: ftpmaster at ftp-master.debian.org (Debian FTP Masters) Date: Wed, 02 Apr 2025 11:39:19 +0000 Subject: systemd-boot-efi-amd64-signed_257.4+9_source.changes ACCEPTED into unstable Message-ID: Thank you for your contribution to Debian. Mapping sid to unstable. Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Wed, 02 Apr 2025 11:19:09 +0100 Source: systemd-boot-efi-amd64-signed Architecture: source Version: 257.4+9 Distribution: sid Urgency: high Maintainer: Debian systemd Maintainers Changed-By: Luca Boccassi Changes: systemd-boot-efi-amd64-signed (257.4+9) unstable; urgency=high . * Sign EFI binaries from systemd-boot-efi 257.4-9 . * resolved: break mDNS, remove conflict with avahi. Feedback from users is to prefer breaking mDNS rather than avoiding avahi. Ship a drop-in to disable mDNS by default, so that users relying on mDNS for reachability can hopefully notice it and mask it before upgrading (Closes: #1098914) Checksums-Sha1: ce10f7de2620bec0001474f7bab20ec5f89d7e2a 1783 systemd-boot-efi-amd64-signed_257.4+9.dsc 00765840f2e00e81f9975671ab9063853ccfe3fd 3684 systemd-boot-efi-amd64-signed_257.4+9.tar.xz Checksums-Sha256: 6b7461a80a4e9c1751f169191001ef2b2027210ccf6e6dee4d8c2f103d09d889 1783 systemd-boot-efi-amd64-signed_257.4+9.dsc 40ca7f9ebb7ebed335e91d74104c7b0f5fcfbe541146053532685eb805f1ee01 3684 systemd-boot-efi-amd64-signed_257.4+9.tar.xz Files: 0beeda7b5dc627d7cade0a7820687824 1783 admin optional systemd-boot-efi-amd64-signed_257.4+9.dsc 80696b79282cda9dae278167074cf97e 3684 admin optional systemd-boot-efi-amd64-signed_257.4+9.tar.xz -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEfKFfvHEI+gkU+E+di0FRiLdONzYFAmftHY0ACgkQi0FRiLdO NzbZFg/9EjB/hCftOkDHH9ne52h2y8vcxuVfIBFcykslvEUyNfBXf4AyvgnSLz4C 5rnQ8JWOjLKkO5bnPvj4dynmH0RCUD+XKPoj/3hDjiXmd9xNO4x3JpF7Zd7iO9oe zeBFrXtSFzeTJMMojFZH1RrRufgf1F/xfwNwMBMvJ80KTnm+oJ08JIXLsmBw5onq xeSYHWRnRMf2FO98zyVD+TJbIbsBe2s5OQ+Gzd5dhFWYLnV1szHszZ1x+3DH8qIu ergsQEY1l7p+hnDK785UaPtvYKs7tP2GXaPXGijQWIEneOVqOMLbS6FCWuNWLp6v FgPItDrmhDgFES5CNDPmoy9cCqGiLlleN6PlUptbEWIFcn81qaBueDQmUMMlhmED HVKkXWB9CncvqC85yVyXeqMyKo+62nT09EjsWTBFDJTCj3yyLW0boLPScw2WEW2x Y7Exg0BOGcWS9BIk5SBlz141BXy1jwTjcCtNcEDNeUPcTJylVc6gjfsqV1Np8EBN E6PkXZDzBGSXDEgMoaG2EnhBBujlQ7oQDCJtyxrvXcHGY+Hs31SMZiIoYKEeAlWU YO566PHRfPAwueFFnt4eqoBcxi/Au8xiTwE32hSeCLTLP24j2ijegqlUptWU7Dmq /jS3SVZ0YWbY3qqSN+W7hbVm7tEPEQZW5I61iFfu7MZIjSjJABI= =kUfj -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: