Re: Proposed MBF: Removal of libfreetype6-dev (causing FTBFS)
[please CC me as I'm not subscribed to debian-devel] On Mon, 17 Jul 2023 at 21:45:13 +1000, Hugh McMaster wrote: > On Mon, 17 Jul 2023 at 00:07, Simon McVittie wrote: > > On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote: > > > Currently, there are 219 build-dependencies and 29 (direct) > > > dependencies on libfreetype6-dev, which has been released with > > > bullseye and bookworm. > > > > Lintian diagnoses this as "[build-]depends-on-obsolete-package" since > > 2.116.0 (MR at [1], instances of the relevant tags listed at [2] and > > [3]) which will hopefully help progress towards dropping the transitional > > package. > > Thanks for pointing this out. I wasn't aware Lintian had started > flagging dependencies on obsolete packages some 10 months ago. > > Having Lintian issue a warning or error instead of bug filing is preferable. While it's true that lintian did issue an error, now that src:freetype has been updated and libfreetype6-dev has been dropped, there are a number of packages which hadn't been updated and now FTBFS. AFAIUI there are people and/or tools which periodically rebuild packages to see if a 'sudden' change has caused a FTBFS and that then gets followed up by a MBF effort. As the FTBFS wrt libfreetype6-dev was predicted and announced [1], wouldn't it have been better if the MBF had taken place? What is the recommended/appropriate way to deal with such issues? [1] https://lists.debian.org/debian-devel/2023/07/msg00193.html signature.asc Description: This is a digitally signed message part.
Re: Proposed MBF: Removal of libfreetype6-dev (causing FTBFS)
On 2023-08-19 10:03 +0200, Diederik de Haas wrote: > [please CC me as I'm not subscribed to debian-devel] > > On Mon, 17 Jul 2023 at 21:45:13 +1000, Hugh McMaster wrote: >> On Mon, 17 Jul 2023 at 00:07, Simon McVittie wrote: >> > On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote: >> > > Currently, there are 219 build-dependencies and 29 (direct) >> > > dependencies on libfreetype6-dev, which has been released with >> > > bullseye and bookworm. >> > >> > Lintian diagnoses this as "[build-]depends-on-obsolete-package" since >> > 2.116.0 (MR at [1], instances of the relevant tags listed at [2] and >> > [3]) which will hopefully help progress towards dropping the transitional >> > package. >> >> Thanks for pointing this out. I wasn't aware Lintian had started >> flagging dependencies on obsolete packages some 10 months ago. >> >> Having Lintian issue a warning or error instead of bug filing is preferable. > > While it's true that lintian did issue an error, now that src:freetype has > been updated and libfreetype6-dev has been dropped, there are a number of > packages which hadn't been updated and now FTBFS. Could you please name an example? > AFAIUI there are people and/or tools which periodically rebuild packages to > see if a 'sudden' change has caused a FTBFS and that then gets followed up by > a MBF effort. > As the FTBFS wrt libfreetype6-dev was predicted and announced [1], wouldn't it > have been better if the MBF had taken place? At the time I recommended just removing the libfreetype6-dev package[2], based on my experience with the transitional -dev packages in ncurses, where this approach worked without a hitch. What is different in freetype? > [1] https://lists.debian.org/debian-devel/2023/07/msg00193.html Cheers, Sven 2. https://lists.debian.org/debian-devel/2023/07/msg00195.html
Re: Proposed MBF: Removal of libfreetype6-dev (causing FTBFS)
On 2023-08-19 Diederik de Haas wrote: > [please CC me as I'm not subscribed to debian-devel] > On Mon, 17 Jul 2023 at 21:45:13 +1000, Hugh McMaster wrote: > > On Mon, 17 Jul 2023 at 00:07, Simon McVittie wrote: > > > On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote: > > > > Currently, there are 219 build-dependencies and 29 (direct) > > > > dependencies on libfreetype6-dev, which has been released with > > > > bullseye and bookworm. [...] > > > Lintian diagnoses this as "[build-]depends-on-obsolete-package" since [...] > > Thanks for pointing this out. I wasn't aware Lintian had started > > flagging dependencies on obsolete packages some 10 months ago. > > Having Lintian issue a warning or error instead of bug filing is preferable. > While it's true that lintian did issue an error, now that src:freetype has > been updated and libfreetype6-dev has been dropped, there are a number of > packages which hadn't been updated and now FTBFS. [...] > As the FTBFS wrt libfreetype6-dev was predicted and announced [1], wouldn't > it > have been better if the MBF had taken place? > What is the recommended/appropriate way to deal with such issues? The agreed reached was not "let's ignore it, lintian has been warning about it". Instead a way forward that /should/ have avoided any breakage (versioned provides) was proposed and chosen. https://lists.debian.org/debian-devel/2023/07/msg00193.html cu Andreas
Re: Activity of the libvirt team?
Hi, On Mon, Aug 14, 2023 at 05:03:19PM +0200, Andrea Bolognani wrote: > On Mon, Aug 14, 2023 at 01:37:23PM +0200, Lee Garrett wrote: > > Hi, > > > > I've packaged rhsrvany [0], which I'd like to maintain under the umbrella of > > the libvirt team. I've tried to join the salsa team on salsa [1]. But so far > > my request has been ignored. I checked the wiki page of team libvirt [2], > > however it seems mostly outdated as it still references alioth. I've asked > > on the mailing list [3], however the last activity there is two years ago, > > and my message is awaiting moderator approval. I've also poked Guido Günther > > directly, who seemed to have done some of the more recent uploads for > > libvirt. > > > > So what would be the process to join the libvirt team? I'd like to push the > > source repo of rhsrvany to a team-maintained space. > > I think you've done the right thing by asking to be added to the > libvirt-team group on Salsa. Unfortunately I don't have admin > privilege to the group, so you'll have to wait for Guido to act on > the request. Same thing for the pkg-libvirt-discuss, which I believe > Guido is the moderator for. Please hold on tight, I'm sure he'll get > around to it :) Andrea, I've bumped your privileges so things don't block on me. Cheers, -- Guido > The wiki page looks pretty outdated, yes. If you have time to change > it so that it points to up-to-date resources, that would be very much > appreciated! Just as you taking the time to package rhsrvany is :)
Re: Proposed MBF: Removal of libfreetype6-dev (causing FTBFS)
On Saturday, 19 August 2023 10:54:20 CEST Sven Joachim wrote: > On 2023-08-19 10:03 +0200, Diederik de Haas wrote: > > [please CC me as I'm not subscribed to debian-devel] > > > > On Mon, 17 Jul 2023 at 21:45:13 +1000, Hugh McMaster wrote: > >> On Mon, 17 Jul 2023 at 00:07, Simon McVittie wrote: > >> > On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote: > >> > > Currently, there are 219 build-dependencies and 29 (direct) > >> > > dependencies on libfreetype6-dev, which has been released with > >> > > bullseye and bookworm. > >> > > >> > Lintian diagnoses this as "[build-]depends-on-obsolete-package" since > >> > 2.116.0 (MR at [1], instances of the relevant tags listed at [2] and > >> > [3]) which will hopefully help progress towards dropping the > >> > transitional > >> > package. > >> > >> Thanks for pointing this out. I wasn't aware Lintian had started > >> flagging dependencies on obsolete packages some 10 months ago. > >> > >> Having Lintian issue a warning or error instead of bug filing is > >> preferable.> > > While it's true that lintian did issue an error, now that src:freetype has > > been updated and libfreetype6-dev has been dropped, there are a number of > > packages which hadn't been updated and now FTBFS. > > Could you please name an example? Hmm. It appears there is something wrong in my reasoning. I first looked at https://tracker.debian.org/pkg/xft, so that would be my example. It Build-Depends on libfreetype6-dev (and libfontconfig1-dev), so I assumed that when that B-D no longer exists, it would thus FTBFS. So I made https://salsa.debian.org/xorg-team/lib/xft/-/merge_requests/3 to fix that, but while it did make the CI pipeline succeed, it was only after your message that I realized that the 'before' pipeline *did* succeed in the 'build' job ... which indicates it does NOT FTBFS. But I still don't understand why. Can you point out where my reasoning is incorrect and that a 'disappearing' B-D does not (automatically) cause a FTBFS? > At the time I recommended just removing the libfreetype6-dev package[2], > based on my experience with the transitional -dev packages in ncurses, > where this approach worked without a hitch. What is different in > freetype? I did see your message, but as described above I didn't/don't understand why that apparently does work. Cheers, Diederik signature.asc Description: This is a digitally signed message part.
Re: Proposed MBF: Removal of libfreetype6-dev (causing FTBFS)
On Saturday, 19 August 2023 11:14:02 CEST Andreas Metzler wrote: > > What is the recommended/appropriate way to deal with such issues? > > The agreed reached was not "let's ignore it, lintian has been warning > about it". Instead a way forward that /should/ have avoided any breakage > (versioned provides) was proposed and chosen. Ah, the versioned provides is what makes it *not* FTBFS! I missed that as had been added on 2021-12-28 already (bug #1002049) and I didn't look back in the history far enough. (I may also not have made the connection though) Thanks :-) signature.asc Description: This is a digitally signed message part.
Re: Activity of the libvirt team?
On Sat, Aug 19, 2023 at 11:25:42AM +0200, Guido Günther wrote: > On Mon, Aug 14, 2023 at 05:03:19PM +0200, Andrea Bolognani wrote: > > On Mon, Aug 14, 2023 at 01:37:23PM +0200, Lee Garrett wrote: > > > Hi, > > > > > > I've packaged rhsrvany [0], which I'd like to maintain under the umbrella > > > of > > > the libvirt team. I've tried to join the salsa team on salsa [1]. But so > > > far > > > my request has been ignored. I checked the wiki page of team libvirt [2], > > > however it seems mostly outdated as it still references alioth. I've asked > > > on the mailing list [3], however the last activity there is two years ago, > > > and my message is awaiting moderator approval. I've also poked Guido > > > Günther > > > directly, who seemed to have done some of the more recent uploads for > > > libvirt. > > > > > > So what would be the process to join the libvirt team? I'd like to push > > > the > > > source repo of rhsrvany to a team-maintained space. > > > > I think you've done the right thing by asking to be added to the > > libvirt-team group on Salsa. Unfortunately I don't have admin > > privilege to the group, so you'll have to wait for Guido to act on > > the request. Same thing for the pkg-libvirt-discuss, which I believe > > Guido is the moderator for. Please hold on tight, I'm sure he'll get > > around to it :) > > Andrea, I've bumped your privileges so things don't block on me. Looks like you've made me Owner of the libvirt-team/libvirt project, but my role in the libvirt-team group is still Developer so I remain powerless when it comes to accepting Lee's request to join the group. Creating new repositories once you're in the group apparently requires no additional privileges, so I believe that Lee would be able to create the rhsrvany repository himself once he's been added. -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Re: Activity of the libvirt team?
Hi, On Sat, Aug 19, 2023 at 04:17:11PM +0200, Andrea Bolognani wrote: > On Sat, Aug 19, 2023 at 11:25:42AM +0200, Guido Günther wrote: > > On Mon, Aug 14, 2023 at 05:03:19PM +0200, Andrea Bolognani wrote: > > > On Mon, Aug 14, 2023 at 01:37:23PM +0200, Lee Garrett wrote: > > > > Hi, > > > > > > > > I've packaged rhsrvany [0], which I'd like to maintain under the > > > > umbrella of > > > > the libvirt team. I've tried to join the salsa team on salsa [1]. But > > > > so far > > > > my request has been ignored. I checked the wiki page of team libvirt > > > > [2], > > > > however it seems mostly outdated as it still references alioth. I've > > > > asked > > > > on the mailing list [3], however the last activity there is two years > > > > ago, > > > > and my message is awaiting moderator approval. I've also poked Guido > > > > Günther > > > > directly, who seemed to have done some of the more recent uploads for > > > > libvirt. > > > > > > > > So what would be the process to join the libvirt team? I'd like to push > > > > the > > > > source repo of rhsrvany to a team-maintained space. > > > > > > I think you've done the right thing by asking to be added to the > > > libvirt-team group on Salsa. Unfortunately I don't have admin > > > privilege to the group, so you'll have to wait for Guido to act on > > > the request. Same thing for the pkg-libvirt-discuss, which I believe > > > Guido is the moderator for. Please hold on tight, I'm sure he'll get > > > around to it :) > > > > Andrea, I've bumped your privileges so things don't block on me. > > Looks like you've made me Owner of the libvirt-team/libvirt project, > but my role in the libvirt-team group is still Developer so I remain > powerless when it comes to accepting Lee's request to join the group. Argh, just ended up in the wrong folder. Bumped it for the whole group now. Cheers, -- Guido > > Creating new repositories once you're in the group apparently > requires no additional privileges, so I believe that Lee would be > able to create the rhsrvany repository himself once he's been added. > > -- > Andrea Bolognani > Resistance is futile, you will be garbage collected.
Re: Activity of the libvirt team?
On Sat, Aug 19, 2023 at 05:54:11PM +0200, Guido Günther wrote: > On Sat, Aug 19, 2023 at 04:17:11PM +0200, Andrea Bolognani wrote: > > On Sat, Aug 19, 2023 at 11:25:42AM +0200, Guido Günther wrote: > > > Andrea, I've bumped your privileges so things don't block on me. > > > > Looks like you've made me Owner of the libvirt-team/libvirt project, > > but my role in the libvirt-team group is still Developer so I remain > > powerless when it comes to accepting Lee's request to join the group. > > Argh, just ended up in the wrong folder. Bumped it for the whole group > now. Excellent, thanks! I've approved the pending membership request now. Lee, please get in touch if it turns out that your current level of privilege is not high enough to properly set up the rhsrvany repository and we'll figure something out :) -- Andrea Bolognani Resistance is futile, you will be garbage collected. signature.asc Description: PGP signature
Re: Questionable Package Present in Debian: fortune-mod
>The mission you have chosen for yourself, then, is to identify all those >things in the Debian distribution that are not constitutive of an >operating system. That is a major part of the work of a Debian Developer, and the ftp-master team. Packages are evaluated for eligibility to enter the distribution all the time, we had times where every new binary package was frowned upon due to resource constraints on the archive. If I uploaded fortunes-natureshadow because I think my favourite quotes are worth being shipped with an operating system, I am pretty sure it would get rejected. There is no reason to handle fortunes-off any different. -nik
Re: Questionable Package Present in Debian: fortune-mod
On Sat, Aug 19, 2023 at 07:11:11PM +0200, Dominik George wrote: > >The mission you have chosen for yourself, then, is to identify all those > >things in the Debian distribution that are not constitutive of an > >operating system. > > That is a major part of the work of a Debian Developer, and the ftp-master > team. > But we have established criteria, so perhaps we should focus on ensuring existing and new packages meet the established criteria and, where needed, we update the critieria via the appropriate mechanism. > Packages are evaluated for eligibility to enter the distribution all the > time, we had times where every new binary package was frowned upon due to > resource constraints on the archive. > And "our infrastructure must be able to host everything we intend to distribute" is one of our established, and very sensible, criteria. > If I uploaded fortunes-natureshadow because I think my favourite quotes are > worth being shipped with an operating system, I am pretty sure it would get > rejected. > I am pretty sure that you would be wrong. In my experience, the FTP masters take their jobs very seriously and they have a well established practice of clearly communicating the reasons for rejecting packages. Again, these reasons are not arbitrary, but rather they are governed by established criteria (e.g., license suitability, package name collisions, archive space constraints, etc). At the same time, removals also are governed by existing criteria. Things like lack of maintainer attention, causing disruption to other packages in the distribution, and similar, are TTBOMK valid reasons for removing a package. The reasons why the FTP masters might reject a package from the archive are public [0]. Nowhere on the list is there an entry that says "somebody doesn't like this package" or "it has stuff that might offend someone" as a valid reason to either prevent a package entering Debian or to precipitate its removal. > There is no reason to handle fortunes-off any different. > Agreed, if you mean "there is no reason to handle fortunes-off any differently from any other package". While a great deal of the content in fortunes-off is personally offensive to me (as is the case with content in the other packages I noted elsewhere in this thread), using the Code of Conduct as a justification for its removal is absolutely wrong. The content in those packages cannot, by any reasonable stretch, be considered to fall within the scope of the Code of Conduct. So, if there is a valid technical or policy reason for excluding the package, then by all means go ahead (and good riddance to the package). But if there is not, let's not abuse the Code of Conduct or any other unrelated policy just because it makes a few people feel good. If you really want to see those packages gone because they give you or someone the wrong feels then it is necessary to first establish the policy under which such can be done, because there is currently no such policy. If, instead, the Code of Conduct is successfully weaponized in order to force the removal of any package from the project, then it will simply be proof that the fears of those who warned that the existence of the Code of Conduct would eventually lead to its abuse and weaponization may have in fact been well founded. Regards, -Roberto [0] https://ftp-master.debian.org/REJECT-FAQ.html -- Roberto C. Sánchez
Re: Questionable Package Present in Debian: fortune-mod
On Sat, Aug 19, 2023 at 2:29 PM Roberto C. Sánchez wrote: > The reasons why the FTP masters might reject a package from the archive > are public [0]. Nowhere on the list is there an entry that says > "somebody doesn't like this package" or "it has stuff that might offend > someone" as a valid reason to either prevent a package entering Debian > or to precipitate its removal. This list is not complete nor authoritative. Without an ftpteam hat on, but my point of view -- I believe the team would absolutely reject a package only based on its name (see: #914179). FWIW, I've tried hard not to provide input on this thread, since it doesn't seem like I have anything to add, but I will note we wouldn't allow a source package in sid with DFSG non-free contents, even if they're not in the .deb. The question is do we treat content in violation of project norms as seriously as we treat nonfree? Paul -- :wq
Re: Questionable Package Present in Debian: fortune-mod
On Sat, Aug 19, 2023 at 02:35:18PM -0400, Paul R. Tagliamonte wrote: > On Sat, Aug 19, 2023 at 2:29 PM Roberto C. Sánchez wrote: > > The reasons why the FTP masters might reject a package from the archive > > are public [0]. Nowhere on the list is there an entry that says > > "somebody doesn't like this package" or "it has stuff that might offend > > someone" as a valid reason to either prevent a package entering Debian > > or to precipitate its removal. > > This list is not complete nor authoritative. > Ah, that's good to know. I perhaps should have phrased my statement a little differently, so as to not give the impression that I was assuming some level of authority. > Without an ftpteam hat on, but my point of view -- I believe the team > would absolutely reject a package only based on its name (see: > #914179). > That's precisely the sort of Code of Conduct abuse that is at issue here. It was wrong then, and it is wrong now. > FWIW, I've tried hard not to provide input on this thread, since it > doesn't seem like I have anything to add, but I will note we wouldn't > allow a source package in sid with DFSG non-free contents, even if > they're not in the .deb. This makes sense and it is consistent with a sensible view of what it means to "distribute" a package (in binary and in source forms). I am fairly certain that this has been discussed on the various mailing lists a few times since I've been in the project, so it is not at all surprising. > The question is do we treat content in > violation of project norms as seriously as we treat nonfree? > That would seem to be the sort of question that needs to be resolved adequately, so that we can stop abusing the Code of Conduct in this way. There are technical reasons for packages to be rejected or removed, and there are non-technical reasons (currently, things like license, abandoned, etc). It would be necessary to add a new non-technical criteria that described the boundaries with sufficient clarity to allow the responsible parties to evaluate the various situations against those criteria/boundaries. Even something as simple as "a package may be rejected and/or removed if its contents or some subset thereof would reasonably be considered a violation of the Code of Conduct if directed at an individual or group via a means otherwise subject to the Code of Conduct." Regards, -Roberto -- Roberto C. Sánchez
Re: Questionable Package Present in Debian: fortune-mod
* Dominik George [230818 17:52]: > Debian is not ..., it is an operating system. This is simply and blatantly incorrect. Debian is a distribution. It includes an operating system and many, many application packages that different people find useful or interesting. The vast majority of packages are not part of the OS. The vast majority of users will only be interested in a small portion of the applications. I would go as far as saying that the applications are the most important part of the distribution, and that the OS is included as a necessity so that the applications can be run. I will certainly agree that the OS can, itself, be considered an application, useful for doing things independently of other packaged applications. As others have said, the CoC is specifically intended to be applied to communications and interactions within the Debian community, not the content of the distribution. The only document that I can think of that describes what is appropriate content for the distribution is the DFSG. Other than paragraph 2, which states that the program must include its source code, the DFSG talks entirely about the license. However, if we extrapolate paragraphs 5 and 6 of the DFSG, which talk about discrimination against persons, groups, and fields of endeavor, along with the Diversity Statement, to how we decide what packages are allowed, I think it is clear that we should be very accepting of packages with content that we don't agree with, as long as someone finds it useful or interesting enough to go to the effort of packaging it. Not doing so is equivalent to saying, "We accept you but not your contribution." The whole point of the Diversity Statement is that we accept people into the Debian community who have ideas and values that are different than, and even contradictory to, our own. How can we not accept the packages that they would like to include? The point is to make them available to those who want to use them; we are not forcing anyone who does not want to use them to do so. ...Marvin
/usr-merge status update + next steps
Hi, Yeah, I know we have too many /usr-merge discussions. Still, there is reason to continue posting. My last summary/status was https://lists.debian.org/20230712133438.ga935...@subdivi.de from July 12th and I'm giving an update of what happened since then here and explain how I want to move forward. # DEP17 I've updated the DEP17 MR at https://salsa.debian.org/dep-team/deps/-/merge_requests/5 and continue to provide a rendered version at https://subdivi.de/~helmut/dep17.html. Notable changes: * We learned that in bookworm and beyond, the rootfs of the debian-installer is not /usr-merged. If we start moving files in packages, we'd likely break the installer. (This is DEP17-P10.) The kinda obvious mitigation is performing the merge there (DEP17-M22) and I've submitted a MR to that end. https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/39 * The heated discussion around debootstrap and the bootstrap protocol was tracked down to be rooted in a misunderstanding. The proposal changing debootstrap (DEP17-M19) has gained consensus and has been uploaded to unstable as debootstrap/1.0.130 by Luca Boccassi. Thanks. Please test this version of debootstrap and report bugs as we intend to backport this change and the change merging --variant=buildd in trixie and beyond to bookworm and bullseye. * The issue of loosing empty directories (DEP17-P6) has been clarified to also loose such directories in plain upgrades when they are canonicalized. Therefore all empty directories in aliased locations are affected regardless of whether other packages ship files within. * The issue of loosing empty directories (DEP17-P6) has formalized two known mitigations. M20: Restore empty directories in maintainer scripts M21: Add placeholder files * I have recorded the perceived consensus in a new "Proposal" section. # Archive work * I currently manually file RC bugs for file conflict bugs that affect the /usr-merge. If you also file such bugs, please add the debian...@lists.debian.org usertag "fileconflict" and ensure that you set appropriate affects or assign the bug to multiple packages. * I have filed bugs with patches and MRs for deleting empty directories (DEP17-P6) that I was as unused. After all, a directory that is not installed, cannot be lost. In case of lib32lsan0 and libx32lsan0, this resulted in deletion of the entire package (thanks Matthias). * I have filed bugs for trigger interests on aliased locations (DEP17-P2) and asked maintainers to duplicate them (DEP17-M12). # Continuous monitoring of problems The dumat service introduced earlier continues to detect problems related to /usr-merge. Its detection has been slightly improved and it also associates reported bugs now. If bugs are correctly assigned, usertagged and have the right affects, dumat associates them and displays them in the output file https://subdivi.de/~helmut/dumat.yaml. At the time of this writing 40 of 111 issues are associated with bug reports. MRs are not associated. # Next steps ## Continuous MBF I intend to implement automatic bug filing in dumat for some classes of bugs. The bug association mentioned above has been implemented to avoid filing duplicates. I intend to extend the service to automatically (with no human intervention) file bugs for issues that are not yet associated with a bug number. If you close such a bug without fixing the cause, a new one will be filed. I intend to implement this one category at a time and most of these categories will result in bugs of severity serious. In general, no bugs will be filed for "risky" issues (52 at the time of this writing) and bugs will only be filed for versions in unstable or experimental. In order to limit possible damage, I intend to limit the service to filing one bug per run (i.e. maximum 4 bugs per day). The categories that shall receive automatic rc bugs are: * undeclared file conflicts (all existing ones filed manually) * P1: ineffective replaces (none at present due to the moratorium) * P2: ineffective trigger interest (all existing ones filed manually) * P3: ineffective diversions (none at present due to the moratorium) * P6: loss of empty directories (some filed) * P7: loss of m-a:same shared files (none at present due to the moratorium) The first is usertagged under the qa umbrella: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-qa%40lists.debian.org&tag=fileconflict The others will be usertagged with my email helm...@debian.org and tag name dep17pN. Why are undeclared file conflicts on this list? They typically are mitigated with Breaks+Replaces or diversions. Both of these mechanisms have potential breakage with aliasing. Therefore, an undeclared file conflict may hide a problem related to /usr-merge. The empty directory loss issues are currently not filed at RC severity even though they tend to be reproducible on bookworm. The moratorium does not pre
