Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
Hello Release Team, If we were to do a MBF against packages that in _Bookworm_ have introduced new files in /bin, /sbin or /lib*, would you accept the consequent mass unblock request? I am asking beforehand as there's no point in going through the effort if you don't, the advantage is only if we can sort it before Bookworm ships, and the bugs would become invalid and be closed as soon as it does as per moratorium otherwise. By Helmut's count, there's around 178 such files to move. The project should probably have added this as a distro-wide rule as part of the moratorium, but that ship has sailed. Thanks! Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
Re: Luca Boccassi > If we were to do a MBF against packages that in _Bookworm_ have > introduced new files in /bin, /sbin or /lib*, would you accept the > consequent mass unblock request? Fwiw, I would restrict that to packages that didn't have files in these directories before. Telling a maintainer that they should continue install foo.service to /lib/systemd, but the newly introduced bar.service needs to got to /usr/lib/systemd seems like a lot of extra work and asking for bugs to happen. Christoph
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Sun, 21 May 2023 at 20:29, Christoph Berg wrote: > > Re: Luca Boccassi > > If we were to do a MBF against packages that in _Bookworm_ have > > introduced new files in /bin, /sbin or /lib*, would you accept the > > consequent mass unblock request? > > Fwiw, I would restrict that to packages that didn't have files in > these directories before. Telling a maintainer that they should > continue install foo.service to /lib/systemd, but the newly introduced > bar.service needs to got to /usr/lib/systemd seems like a lot of extra > work and asking for bugs to happen. Yes, this (the number of files mentioned) already excludes things that are installed by dh addons and so, such as unit files. Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Sun, 21 May 2023 at 20:31, Luca Boccassi wrote: > > On Sun, 21 May 2023 at 20:29, Christoph Berg wrote: > > > > Re: Luca Boccassi > > > If we were to do a MBF against packages that in _Bookworm_ have > > > introduced new files in /bin, /sbin or /lib*, would you accept the > > > consequent mass unblock request? > > > > Fwiw, I would restrict that to packages that didn't have files in > > these directories before. Telling a maintainer that they should > > continue install foo.service to /lib/systemd, but the newly introduced > > bar.service needs to got to /usr/lib/systemd seems like a lot of extra > > work and asking for bugs to happen. > > Yes, this (the number of files mentioned) already excludes things that > are installed by dh addons and so, such as unit files. Here's the list of affected packages for binaries: abpoa eprover coq-hierarchy-builder intel-cmt-cat nbd-server systemd toybox drbd-utils finit finit-plugins multipath-tools runit nut-modbus nut-i2c nut-server open-iscsi openrc resolvconf iproute2 f2fs-tools ifupdown-ng multipath-tools libpam-modules-bin PAM modules: cockpit-tests libpam-python libpam-alreadyloggedin libpam-chroot google-compute-engine-oslogin systemd-homed Library new ABI or minor versions: libbrlapi0.8 libc6 libcap2 libcgroup2 libdbus-1-3 libdmraid1.0.0.rc16 libcap-ng0 libexpat1 libfuse3-3 libgpg-error0 xfsprogs libreadline8 libkeyutils1 liblzma5 libncurses6 libncursesw6 libntfs-3g89 libnutclient2 libnutscan2 libparted-fs-resize0 libparted2 libproc2-0 libsepol2 libtinfo6 libupsclient6 zlib1g The libraries are just minor version increase in most cases, so the symlinks are often unchanged and cannot be moved, so I'd leave them where they are. So that's 23 packages for binaries and 5 for PAM modules moving from un-triplet to triplet location. Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
Hi Luca, On Mon, 22 May 2023 00:03:46 +0100 Luca Boccassi wrote: > On Sun, 21 May 2023 at 20:31, Luca Boccassi wrote: > > > > On Sun, 21 May 2023 at 20:29, Christoph Berg > > wrote: > > > > > > Re: Luca Boccassi > > > > If we were to do a MBF against packages that in _Bookworm_ have > > > > introduced new files in /bin, /sbin or /lib*, would you accept > > > > the consequent mass unblock request? > > > > > > Fwiw, I would restrict that to packages that didn't have files in > > > these directories before. Telling a maintainer that they should > > > continue install foo.service to /lib/systemd, but the newly > > > introduced bar.service needs to got to /usr/lib/systemd seems > > > like a lot of extra work and asking for bugs to happen. > > > > Yes, this (the number of files mentioned) already excludes things > > that are installed by dh addons and so, such as unit files. > > Here's the list of affected packages for binaries: > > abpoa > eprover > coq-hierarchy-builder > intel-cmt-cat > nbd-server > systemd > toybox > drbd-utils > finit > finit-plugins > multipath-tools > runit Please exclude runit from the list as /lib/runit/ was not empty in Bullseye. Regards, Lorenzo > nut-modbus > nut-i2c > nut-server > open-iscsi > openrc > resolvconf > iproute2 > f2fs-tools > ifupdown-ng > multipath-tools > libpam-modules-bin > > PAM modules: > > cockpit-tests > libpam-python > libpam-alreadyloggedin > libpam-chroot > google-compute-engine-oslogin > systemd-homed > > Library new ABI or minor versions: > > libbrlapi0.8 > libc6 > libcap2 > libcgroup2 > libdbus-1-3 > libdmraid1.0.0.rc16 > libcap-ng0 > libexpat1 > libfuse3-3 > libgpg-error0 > xfsprogs > libreadline8 > libkeyutils1 > liblzma5 > libncurses6 > libncursesw6 > libntfs-3g89 > libnutclient2 > libnutscan2 > libparted-fs-resize0 > libparted2 > libproc2-0 > libsepol2 > libtinfo6 > libupsclient6 > zlib1g > > The libraries are just minor version increase in most cases, so the > symlinks are often unchanged and cannot be moved, so I'd leave them > where they are. So that's 23 packages for binaries and 5 for PAM > modules moving from un-triplet to triplet location. > > Kind regards, > Luca Boccassi >
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
Hi Luca, Luca Boccassi, on 2023-05-22: > On Sun, 21 May 2023 at 20:31, Luca Boccassi wrote: > > > > On Sun, 21 May 2023 at 20:29, Christoph Berg wrote: > > > > > > Re: Luca Boccassi > > > > If we were to do a MBF against packages that in _Bookworm_ have > > > > introduced new files in /bin, /sbin or /lib*, would you accept the > > > > consequent mass unblock request? > > > > > > Fwiw, I would restrict that to packages that didn't have files in > > > these directories before. Telling a maintainer that they should > > > continue install foo.service to /lib/systemd, but the newly introduced > > > bar.service needs to got to /usr/lib/systemd seems like a lot of extra > > > work and asking for bugs to happen. > > > > Yes, this (the number of files mentioned) already excludes things that > > are installed by dh addons and so, such as unit files. > > Here's the list of affected packages for binaries: > > abpoa I happen to have abpoa on my radar, and its presence here is due to a screwup of mine. Fix is one patch away, assuming I guess that an exception to the moratorium will be granted to these particular situations (abpoa didn't exist in bullseye and prior, and I understand other affected packages in the list are more or less similar situations to avoid risks of triggering aliasing bugs during major upgrade): --- a/debian/install +++ b/debian/install @@ -1 +1 @@ -bin/abpoa* +bin/abpoa* /usr/bin About the timing, even from a maintainer's perspective, it is becoming short indeed. In any case, thanks for raising that problem! -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Black Bonzo - The Well signature.asc Description: PGP signature
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
> "Luca" == Luca Boccassi writes: Luca> Hello Release Team, If we were to do a MBF against packages Luca> that in _Bookworm_ have introduced new files in /bin, /sbin or Luca> /lib*, would you accept the consequent mass unblock request? Luca> I am asking beforehand as there's no point in going through Luca> the effort if you don't, the advantage is only if we can sort Luca> it before Bookworm ships, and the bugs would become invalid Luca> and be closed as soon as it does as per moratorium otherwise. This sounds like a really bad idea. While technically this is consistent with the TC's advice, what you are proposing to do increases the chance that you're going to trigger the dpkg disappearing file bug. Consider: * User installs version from testing with file in /bin * Maintainer quickly moves the file to /usr/bin per your MBF * Bookworm releases; user does not upgrade at this point * Package reorganization; file moves between packages * User upgrades; file disappears I suspect the reason you want to make this MBF is that you believe it will somehow make the transition easier if there are fewer files in /bin or /usr/bin. I don't think that's obvious to me from the debian-devel discussions, and so i don't think there is a significant benefit in this MBF. Without a significant benefit and with the risk of files disappearing for people tracking testing/unstable, I think that this is a bad idea.
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Mon, 22 May 2023 at 20:22, Sam Hartman wrote: > > > "Luca" == Luca Boccassi writes: > > Luca> Hello Release Team, If we were to do a MBF against packages > Luca> that in _Bookworm_ have introduced new files in /bin, /sbin or > Luca> /lib*, would you accept the consequent mass unblock request? > Luca> I am asking beforehand as there's no point in going through > Luca> the effort if you don't, the advantage is only if we can sort > Luca> it before Bookworm ships, and the bugs would become invalid > Luca> and be closed as soon as it does as per moratorium otherwise. > > This sounds like a really bad idea. > While technically this is consistent with the TC's advice, what you are > proposing to do increases the chance that you're going to trigger the > dpkg disappearing file bug. > > Consider: > > * User installs version from testing with file in /bin > * Maintainer quickly moves the file to /usr/bin per your MBF > * Bookworm releases; user does not upgrade at this point > * Package reorganization; file moves between packages > * User upgrades; file disappears What "package reorganization" would that be? Are you aware of any such thing happening in the next couple of weeks before release? > I suspect the reason you want to make this MBF is that you believe it > will somehow make the transition easier if there are fewer files in /bin > or /usr/bin. No, the main reason is that Helmut asked for this. And the ask makes sense: it's something that should have been part of the TC guidance, introducing new files in the wrong locations makes little sense. Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
> "Luca" == Luca Boccassi writes: Luca> On Mon, 22 May 2023 at 20:22, Sam Hartman wrote: >> >> > "Luca" == Luca Boccassi writes: >> Luca> Hello Release Team, If we were to do a MBF against packages Luca> that in _Bookworm_ have introduced new files in /bin, /sbin or Luca> /lib*, would you accept the consequent mass unblock request? Luca> I am asking beforehand as there's no point in going through Luca> the effort if you don't, the advantage is only if we can sort Luca> it before Bookworm ships, and the bugs would become invalid Luca> and be closed as soon as it does as per moratorium otherwise. >> >> This sounds like a really bad idea. While technically this is >> consistent with the TC's advice, what you are proposing to do >> increases the chance that you're going to trigger the dpkg >> disappearing file bug. >> >> Consider: >> >> * User installs version from testing with file in /bin * >> Maintainer quickly moves the file to /usr/bin per your MBF * >> Bookworm releases; user does not upgrade at this point * Package >> reorganization; file moves between packages * User upgrades; file >> disappears Luca> What "package reorganization" would that be? Are you aware of Luca> any such thing happening in the next couple of weeks before Luca> release? Who said anything about next couple of weeks. This affects testing and unstable users *after the release*. It is my experience of Debian that outside of freezes package reorganizations happen regularly. I think your plan is safe for stable users if we actually find a solution to canonicalize paths during the next cycle. I do not think your plan is safe for people who track testing, and for me there's not enough benefit to justify breaking testing.
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Mon, 22 May 2023 at 20:34, Sam Hartman wrote: > > > "Luca" == Luca Boccassi writes: > > Luca> On Mon, 22 May 2023 at 20:22, Sam Hartman > wrote: > >> > >> > "Luca" == Luca Boccassi writes: > >> > Luca> Hello Release Team, If we were to do a MBF against packages > Luca> that in _Bookworm_ have introduced new files in /bin, /sbin or > Luca> /lib*, would you accept the consequent mass unblock request? > Luca> I am asking beforehand as there's no point in going through > Luca> the effort if you don't, the advantage is only if we can sort > Luca> it before Bookworm ships, and the bugs would become invalid > Luca> and be closed as soon as it does as per moratorium otherwise. > >> > >> This sounds like a really bad idea. While technically this is > >> consistent with the TC's advice, what you are proposing to do > >> increases the chance that you're going to trigger the dpkg > >> disappearing file bug. > >> > >> Consider: > >> > >> * User installs version from testing with file in /bin * > >> Maintainer quickly moves the file to /usr/bin per your MBF * > >> Bookworm releases; user does not upgrade at this point * Package > >> reorganization; file moves between packages * User upgrades; file > >> disappears > > Luca> What "package reorganization" would that be? Are you aware of > Luca> any such thing happening in the next couple of weeks before > Luca> release? > > Who said anything about next couple of weeks. This affects testing and > unstable users *after the release*. It is my experience of Debian that > outside of freezes package reorganizations happen regularly. So what you are worried is the combination of a testing installation from~one year ago, that is otherwise never touched for say another year, and also that has one of those 23 packages installed in the old version, and also that same package of those 23 gets rearranged? That seems vanishingly unlikely, and I am not sure how supported it is to upgrade from "testing as bookworm" to "testing as trixie" without passing from bookworm stable, given we don't support skipping releases I'd have imagined that would not be supported either, but what do I know. Anyway, this is Helmut's request, so I'll leave the decision to him. > I think your plan is safe for stable users if we actually find a > solution to canonicalize paths during the next cycle. I do not think > your plan is safe for people who track testing, and for me there's not > enough benefit to justify breaking testing. Please stop saying "your plan", as I have already mentioned it was someone else's request: Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
Luca Boccassi, on 2023-05-22: > On Mon, 22 May 2023 at 20:34, Sam Hartman wrote: > > > > > "Luca" == Luca Boccassi writes: > > > > Luca> On Mon, 22 May 2023 at 20:22, Sam Hartman > > wrote: > > >> > > >> > "Luca" == Luca Boccassi writes: > > >> > > Luca> Hello Release Team, If we were to do a MBF against packages > > Luca> that in _Bookworm_ have introduced new files in /bin, /sbin or > > Luca> /lib*, would you accept the consequent mass unblock request? > > Luca> I am asking beforehand as there's no point in going through > > Luca> the effort if you don't, the advantage is only if we can sort > > Luca> it before Bookworm ships, and the bugs would become invalid > > Luca> and be closed as soon as it does as per moratorium otherwise. > > >> > > >> This sounds like a really bad idea. While technically this is > > >> consistent with the TC's advice, what you are proposing to do > > >> increases the chance that you're going to trigger the dpkg > > >> disappearing file bug. > > >> > > >> Consider: > > >> > > >> * User installs version from testing with file in /bin * > > >> Maintainer quickly moves the file to /usr/bin per your MBF * > > >> Bookworm releases; user does not upgrade at this point * Package > > >> reorganization; file moves between packages * User upgrades; file > > >> disappears > > > > Luca> What "package reorganization" would that be? Are you aware of > > Luca> any such thing happening in the next couple of weeks before > > Luca> release? > > > > Who said anything about next couple of weeks. This affects testing and > > unstable users *after the release*. It is my experience of Debian that > > outside of freezes package reorganizations happen regularly. > > So what you are worried is the combination of a testing installation > from~one year ago, that is otherwise never touched for say another > year, and also that has one of those 23 packages installed in the old > version, and also that same package of those 23 gets rearranged? That > seems vanishingly unlikely, Against all odds, I can see very well this happening, so I guess it shouldn't hurt to flag somehow packages having had to proceed per the MBF. Big "warning" comments at a few strategic points in d/control and install files might probably be a bare minimum, so team fellows or future self won't trip on the carpet when tempted to reorganize files. -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/tty1, please excuse my verbosity `-on air: The Flower Kings - Bavarian Skies signature.asc Description: PGP signature
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Mon, 22 May 2023 at 22:13, Étienne Mollier wrote: > > Luca Boccassi, on 2023-05-22: > > On Mon, 22 May 2023 at 20:34, Sam Hartman wrote: > > > > > > > "Luca" == Luca Boccassi writes: > > > > > > Luca> On Mon, 22 May 2023 at 20:22, Sam Hartman > > > wrote: > > > >> > > > >> > "Luca" == Luca Boccassi writes: > > > >> > > > Luca> Hello Release Team, If we were to do a MBF against packages > > > Luca> that in _Bookworm_ have introduced new files in /bin, /sbin or > > > Luca> /lib*, would you accept the consequent mass unblock request? > > > Luca> I am asking beforehand as there's no point in going through > > > Luca> the effort if you don't, the advantage is only if we can sort > > > Luca> it before Bookworm ships, and the bugs would become invalid > > > Luca> and be closed as soon as it does as per moratorium otherwise. > > > >> > > > >> This sounds like a really bad idea. While technically this is > > > >> consistent with the TC's advice, what you are proposing to do > > > >> increases the chance that you're going to trigger the dpkg > > > >> disappearing file bug. > > > >> > > > >> Consider: > > > >> > > > >> * User installs version from testing with file in /bin * > > > >> Maintainer quickly moves the file to /usr/bin per your MBF * > > > >> Bookworm releases; user does not upgrade at this point * Package > > > >> reorganization; file moves between packages * User upgrades; file > > > >> disappears > > > > > > Luca> What "package reorganization" would that be? Are you aware of > > > Luca> any such thing happening in the next couple of weeks before > > > Luca> release? > > > > > > Who said anything about next couple of weeks. This affects testing and > > > unstable users *after the release*. It is my experience of Debian that > > > outside of freezes package reorganizations happen regularly. > > > > So what you are worried is the combination of a testing installation > > from~one year ago, that is otherwise never touched for say another > > year, and also that has one of those 23 packages installed in the old > > version, and also that same package of those 23 gets rearranged? That > > seems vanishingly unlikely, > > Against all odds, I can see very well this happening, so I guess > it shouldn't hurt to flag somehow packages having had to proceed > per the MBF. Big "warning" comments at a few strategic points > in d/control and install files might probably be a bare minimum, > so team fellows or future self won't trip on the carpet when > tempted to reorganize files. In case such an update is a supported use case, then yes, adding a comment to the install file where the change is applied would make perfect sense, as that's where it would be hypothetically removed from in that example. Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
;> "Luca" == Luca Boccassi writes: Luca> So what you are worried is the combination of a testing Luca> installation from~one year ago, that is otherwise never Luca> touched for say another year, and also that has one of those Luca> 23 packages installed in the old version, and also that same Luca> package of those 23 gets rearranged? I find I'm joining the growing number of people who cannot assume good faith. I'm disappointed that you choose to diminish others arguments, working to find the quickest way to dismiss the contributions of people who are interacting with you rather than to explore what they are saying and see if there is something you can learn from their contributions. So, let's rephrase this, trying to make the situation I'm talking about likely rather than working to dismiss it: > So what you are worried is the combination of a testing > installation from just before the unblocks migrate into testing, that > is next upgraded a few months after bookworm releases, which that has one of > those Luca> 23 packages installed, and one of those packages gets rearranged? Yes, that's the situation I'm considering. The difference in how I presented things and how you presented things are: * You chose a much older initial testing image than was necessary. * In the phrases where I edited your language, you chose to emphasize what you see as a small number of packages, and to amplify what you see as improbabilities. Instead, you could have presented my argument in a neutral manner, working to confirm understanding, and actually treated my contribution with respect.
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Mon, 22 May 2023 at 22:40, Sam Hartman wrote: > > ;> "Luca" == Luca Boccassi writes: > Luca> So what you are worried is the combination of a testing > Luca> installation from~one year ago, that is otherwise never > Luca> touched for say another year, and also that has one of those > Luca> 23 packages installed in the old version, and also that same > Luca> package of those 23 gets rearranged? > > I find I'm joining the growing number of people who cannot assume good > faith. > I'm disappointed that you choose to diminish others arguments, working > to find the quickest way to dismiss the contributions of people who are > interacting with you rather than to explore what they are saying and > see if there is something you can learn from their contributions. This is how you started your "contribution" to an otherwise normal and tension-less thread: > This sounds like a really bad idea. ... > I suspect the reason you want to make this MBF is that you believe it will somehow make the transition easier if there are fewer files in /bin or /usr/bin. IE, you immediately escalated it with aggressiveness followed by baseless accusations verging on the conspiratorial. So next time you might want to consider getting off that high horse first, before giving others lessons in how to approach a thread. Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
> "Luca" == Luca Boccassi writes: >> I suspect the reason you want to make this MBF is that you >> believe it Luca> will somehow make the transition easier if there are fewer Luca> files in /bin or /usr/bin. Luca> IE, you immediately escalated it with aggressiveness followed Luca> by baseless accusations verging on the conspiratorial. I regret that my second statement came across as an accusation and certainly that you heard it as a conspiracy. I'd like to be heard differently. My understanding at the time (which you have since corrected) is that you were making the proposal because you believed it would make a transition to canonical paths easier. In my mind that would be a good reason for advocating for such a transition. That is the spirit in which I made the assumption about your reasoning. Again, I regret that you heard things in a different tone. I read your original message as a valuable contribution that in my analysis I thought was a bad idea because of the dpkg disappearing file bug. --Sam
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Mon, 22 May 2023 at 23:07, Sam Hartman wrote: > > > "Luca" == Luca Boccassi writes: > > >> I suspect the reason you want to make this MBF is that you > >> believe it > Luca> will somehow make the transition easier if there are fewer > Luca> files in /bin or /usr/bin. > > Luca> IE, you immediately escalated it with aggressiveness followed > Luca> by baseless accusations verging on the conspiratorial. > > I regret that my second statement came across as an accusation and > certainly that you heard it as a conspiracy. > I'd like to be heard differently. > My understanding at the time (which you have since corrected) is that > you were making the proposal because you believed it would make a > transition to canonical paths easier. > In my mind that would be a good reason for advocating for such a > transition. > That is the spirit in which I made the assumption about your reasoning. > Again, I regret that you heard things in a different tone. > > I read your original message as a valuable contribution that in my > analysis I thought was a bad idea because of the dpkg disappearing file > bug. Thank you for your clarification, I think the example you brought up is worth considering. Do you feel that Étienne's suggestion of documenting it in the place where such a change would necessarily have to take place so that it can't be missed (e.g.: the install file) would be an adequate safeguard? Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
Hi, On 21-05-2023 21:22, Luca Boccassi wrote: If we were to do a MBF against packages that in _Bookworm_ have introduced new files in /bin, /sbin or /lib*, would you accept the consequent mass unblock request? Short answer is no, it's too late. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Tue, 23 May 2023 at 17:48, Paul Gevers wrote: > > Hi, > > On 21-05-2023 21:22, Luca Boccassi wrote: > > If we were to do a MBF against packages that in _Bookworm_ have > > introduced new files in /bin, /sbin or /lib*, would you accept the > > consequent mass unblock request? > > Short answer is no, it's too late. Understandable, thanks for checking. Kind regards, Luca Boccassi
