Bug#1035710: unblock: doc-debian/11.3
On Sat, May 20, 2023 at 04:21:47PM +0200, Sebastian Ramacher wrote: > On 2023-05-14 06:47:18 +0200, Joost van Baal-Ilić wrote: > > reopen 1035710 > > retitle 1035710 unblock: doc-debian/11.3 > > thanks > > > > Please unblock package doc-debian > > > > [ Reason ] > > The doc-debian package claims to ship the Constitution for the Debian > > Project, > > the Debian Social Contract and other Debian documents. The versions of > > those > > documents are obsolete [obsolete], which makes the package as now in testing > > very buggy. > > > > unblock doc-debian/11.3 > > Please go ahead with the upload to unstable. Remove the moreinfo tag > once the package is available. Thank you. Unfortunately I don't think I'll make it before the deadline / in the next couple of hours, real life currently doesn't allow me that. If anybody else has time to take a shot at it: here's the current issue's: I made a mistake in the upload to experimental: it says 'experimental' in the top of debian/changelog; should probably be 'unstable'. And the last commit on salsa is misguided. If nobody steps up I can probably prepare an upload for the first bookworm point release. Bye, Joost -- irc: joostvb @ OFTC / libera.chat / ...
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?
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 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?
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?
> "Michael" == Michael Biebl writes: Michael> Am 22.05.23 um 21:34 schrieb Sam Hartman: >> enough benefit to justify breaking testing. >> Michael> No-one is breaking testing, as files are not moved between Michael> packages. Files are moved between packages all the time *outside of a freeze*. After bookworm is released, I expect the freeze to end and testing to be unfrozen. At that point, I expect files to move between packages in testing. Going back to my original timeline: * 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 At this point in my timeline, bookworm is released, and the freeze ends. Users of stable are okay. But users of testing continue to track a now-ufrozen testing, and then * Package reorganization; file moves between packages * User upgrades; file disappears To clarify, we could add an item like "package migrates into unfrozen testing" between the above items. Again, I think this MBF would be safe if we only cared about bookworm users. But I think that tracking testing through a release and not ever actually upgrading to the released version, but instead upgrading from testing two weeks before the release to testing after the freeze thaws is generally considered a supported operation.
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
Am 22.05.23 um 21:34 schrieb Sam Hartman: enough benefit to justify breaking testing. No-one is breaking testing, as files are not moved between packages. OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1034824: tomcat9 should not be released with Bookworm
On Tue, May 16, 2023 at 05:28:11PM +0300, Timo Aaltonen wrote: > Timo Aaltonen kirjoitti 16.5.2023 klo 10.12: > > Markus Koschany kirjoitti 13.5.2023 klo 23.38: > > > Hi Salvatore, > > > > > > adding Timo Aaltonen, maintainer of dogtag-pki and tomcatjss, to CC > > > > > > Am Samstag, dem 13.05.2023 um 20:50 +0200 schrieb Salvatore Bonaccorso: > > > > Hi Markus, > > > > > > > > On Sat, May 13, 2023 at 06:27:49PM +0200, Markus Koschany wrote: > > > > > I have just pushed the necessary changes to our Git repository. > > > > > > > > > > https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993 > > > > > > > > Do we need to have done more here? When Paul asked on #debian-release > > > > I noted that pki-server depends on tomcat9-user, so reducing > > > > libtomcat9-java only would now cause a broken dpeends for pki-server: > > > > > > > > $ dak rm --suite=bookworm -n -R -b tomcat9-user > > > > Will remove the following packages from bookworm: > > > > > > > > tomcat9-user | 9.0.70-1 | all > > > > > > We could simply replace tomcat9-user with tomcat10-user because it > > > only ships a > > > script to create a standalone tomcat instance. We have to do > > > s/tomcat9/tomcat10/ in some debian service files as well. > > > > > > The question is: If we ship libtomcat9-java in Bookworm and change the > > > dependency from tomcat9-user to tomcat10-user, will a web > > > application like > > > dogtag-pki, which is designed for Tomcat 9, continue to work with > > > Tomcat 10? I > > > don't know yet and maybe Timo can chime in here. > > > > I don't know, dogtag uses the skel files from tomcat9-user, but I diffed > > them between tomcat9 and 10 and couldn't see why it would regress. > > Had a closer look at dogtag, and it's launching the tomcat instance from > CATALINA_HOME, so it's a one-way ticket to migrate an installed instance to > use tomcat10 in the configuration, so I don't think moving to tomcat10-user > would fly.. Does that mean the two bugs (in tomcat9 and tomcatjss) should be tagged "trixie sid" to no longer affect and bookworm will ship with two versions of tomcat, or what else is now supposed to happen? cu Adrian
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?
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?
> "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?
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
Bug#1036562: unblock: qtbase-opensource-src/5.15.8+dfsg-10
On Mon, May 22, 2023 at 01:58:03PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: qtbase-opensource-...@packages.debian.org, mity...@debian.org, > lisan...@debian.org > Control: affects -1 + src:qtbase-opensource-src > > Please unblock package qtbase-opensource-src > > [ Reason ] > > This upload: > - Fixes CVE-2023-32762 and CVE-2023-32763. One prevents a crash with SVG > (not related to the one in qtsvg-opensource-src) and the other one > related to a security heade parsing in the network module. > - Adds a Break/Replaces in order to allow proper handling of systems > that still had libqtcore4 around (#1035790). > - Backports a patch in order to solve an issue with KWin: > - https://bugreports.qt.io/browse/QTBUG-98048 > - https://lists.debian.org/debian-kde/2022/11/msg00019.html Actually, the fix for #1035790 has already migrated to testing. So just the first and third points are remaining. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1036564: unblock: qt6-base/6.4.2+dfsg-9
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: qt6-b...@packages.debian.org, delta...@debian.org,
lisan...@debian.org
Control: affects -1 + src:qt6-base
Please unblock package qt6-base
[ Reason ]
Fixes CVE-2023-32762 and CVE-2023-32763. One prevents a crash with SVG
(not related to the one in qtsvg-opensource-src) and the other one
related to a security heade parsing in the network module.
[ Impact ]
Lack of security fixes.
[ Tests ]
Tested by upstream, do not break API/ABI, seems safe.
[ Risks ]
None that I can think of.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock qt6-base/6.4.2+dfsg-9
diff --git a/debian/changelog b/debian/changelog
index b117abd..85ce31b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+qt6-base (6.4.2+dfsg-9) unstable; urgency=medium
+
+ * Team upload.
+ * Add a patch to fix CVE-2023-32762.
+
+ -- Lisandro Damián Nicanor Pérez Meyer Mon, 22 May
2023 11:40:45 -0300
+
+qt6-base (6.4.2+dfsg-8) unstable; urgency=medium
+
+ * Team upload.
+ * Add patch for solving CVE-2023-32763.
+ * Refresh patches.
+
+ -- Lisandro Damián Nicanor Pérez Meyer Mon, 22 May
2023 10:42:21 -0300
+
qt6-base (6.4.2+dfsg-7) unstable; urgency=medium
[ Patrick Franz ]
diff --git a/debian/patches/armel-noyield.patch
b/debian/patches/armel-noyield.patch
index 37061fb..74b1ae2 100644
--- a/debian/patches/armel-noyield.patch
+++ b/debian/patches/armel-noyield.patch
@@ -1,8 +1,12 @@
Description: Don't use yield on CPUs that might not support it
+---
+ src/corelib/global/qsimd_p.h |2 ++
+ 1 file changed, 2 insertions(+)
+
--- a/src/corelib/global/qsimd_p.h
+++ b/src/corelib/global/qsimd_p.h
-@@ -428,7 +428,9 @@ static inline void qYieldCpu()
+@@ -401,7 +401,9 @@ static inline void qYieldCpu()
https://stackoverflow.com/a/70076751/134841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105416
*/
diff --git
a/debian/patches/build_path_embedded_qtbuildinternalsextra_cmake.patch
b/debian/patches/build_path_embedded_qtbuildinternalsextra_cmake.patch
index 2ab0f5e..bf93bca 100644
--- a/debian/patches/build_path_embedded_qtbuildinternalsextra_cmake.patch
+++ b/debian/patches/build_path_embedded_qtbuildinternalsextra_cmake.patch
@@ -9,22 +9,18 @@ and causes reproducibility issues when built in different
paths.
https://reproducible-builds.org/docs/build-path/
---
- cmake/QtBuildInternalsExtra.cmake.in | 3 ---
+ cmake/QtBuildInternalsExtra.cmake.in |3 ---
1 file changed, 3 deletions(-)
-diff --git a/cmake/QtBuildInternalsExtra.cmake.in
b/cmake/QtBuildInternalsExtra.cmake.in
-index cbd70b1..23b2391 100644
--- a/cmake/QtBuildInternalsExtra.cmake.in
+++ b/cmake/QtBuildInternalsExtra.cmake.in
-@@ -53,9 +53,6 @@ endif()
+@@ -75,9 +75,6 @@ endif()
set(QT_WILL_INSTALL @QT_WILL_INSTALL@ CACHE BOOL
"Boolean indicating if doing a Qt prefix build (vs non-prefix build)."
FORCE)
-
+
-set(QT_SOURCE_TREE "@QT_SOURCE_TREE@" CACHE PATH
-"A path to the source tree of the previously configured QtBase project."
FORCE)
-
# Propagate decision of building tests and examples to other repositories.
set(QT_BUILD_TESTS @QT_BUILD_TESTS@ CACHE BOOL "Build the testing tree.")
set(QT_BUILD_EXAMPLES @QT_BUILD_EXAMPLES@ CACHE BOOL "Build Qt examples")
---
-2.35.1
diff --git a/debian/patches/cross.patch b/debian/patches/cross.patch
index 1a7ebd3..239c803 100644
--- a/debian/patches/cross.patch
+++ b/debian/patches/cross.patch
@@ -1,6 +1,11 @@
+---
+ cmake/QtBuildInternals/QtBuildInternalsConfig.cmake |2 --
+ src/tools/configure.cmake |2 +-
+ 2 files changed, 1 insertion(+), 3 deletions(-)
+
--- a/cmake/QtBuildInternals/QtBuildInternalsConfig.cmake
+++ b/cmake/QtBuildInternals/QtBuildInternalsConfig.cmake
-@@ -146,8 +146,6 @@
+@@ -151,8 +151,6 @@ function(qt_build_internals_disable_pkg_
set(FEATURE_pkg_config "${pkg_config_enabled}" CACHE STRING "Using
pkg-config")
if(NOT pkg_config_enabled)
qt_build_internals_disable_pkg_config()
@@ -11,7 +16,7 @@
--- a/src/tools/configure.cmake
+++ b/src/tools/configure.cmake
-@@ -2,7 +2,7 @@
+@@ -2,7 +2,7 @@ qt_feature("androiddeployqt" PRIVATE
SECTION "Deployment"
LABEL "Android deployment tool"
PURPOSE "The Android deployment tool automates the process of creating
Android packages."
diff --git a/debian/patches/cve-2023-32762.diff
b/debian/patches/cve-2023-32762.diff
new file mode 100644
index 000..92b76fa
--- /dev/null
+++ b/debian/patches/cve-2023-32762.diff
@@ -0,0 +1,15 @@
+---
+ src/network/access/qhsts.cpp |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/src/network/access/qhsts.cpp
b/src/network/access/qhsts.cpp
+@@ -328,7 +328,7 @@ bool QHstsHeaderParser::parse(const QLis
+ {
+ for (const
Processed: unblock: qt6-base/6.4.2+dfsg-9
Processing control commands: > affects -1 + src:qt6-base Bug #1036564 [release.debian.org] unblock: qt6-base/6.4.2+dfsg-9 Added indication that 1036564 affects src:qt6-base -- 1036564: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036564 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: unblock: qt6-svg/6.4.2-2
Processing control commands: > affects -1 + src:qt6-svg Bug #1036563 [release.debian.org] unblock: qt6-svg/6.4.2-2 Added indication that 1036563 affects src:qt6-svg -- 1036563: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036563 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1036563: unblock: qt6-svg/6.4.2-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: qt6-...@packages.debian.org, delta...@debian.org,
lisan...@debian.org
Control: affects -1 + src:qt6-svg
Please unblock package qt6-svg
[ Reason ]
Fixes CVE-2023-32573.
[ Impact ]
This patch avoids a crash when parsing malformed/crafted SVG files.
[ Tests ]
Done by upstream, it basically makes sures a variable has a default
value.
[ Risks ]
None that I can think of.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock qt6-svg/6.4.2-2
diff --git a/debian/changelog b/debian/changelog
index 41242b5..78f7594 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+qt6-svg (6.4.2-2) unstable; urgency=medium
+
+ * Team upload.
+ * Add patch to solve CVE-2023-32573.
+
+ -- Lisandro Damián Nicanor Pérez Meyer Mon, 22 May
2023 10:48:50 -0300
+
qt6-svg (6.4.2-1) unstable; urgency=medium
[ Patrick Franz ]
diff --git a/debian/patches/cve-2023-32573.diff
b/debian/patches/cve-2023-32573.diff
new file mode 100644
index 000..750f29e
--- /dev/null
+++ b/debian/patches/cve-2023-32573.diff
@@ -0,0 +1,37 @@
+---
+ src/svg/qsvgfont_p.h|5 ++---
+ src/svg/qsvghandler.cpp |2 +-
+ 2 files changed, 3 insertions(+), 4 deletions(-)
+
+--- a/src/svg/qsvgfont_p.h
b/src/svg/qsvgfont_p.h
+@@ -38,6 +38,7 @@ public:
+ class Q_SVG_PRIVATE_EXPORT QSvgFont : public QSvgRefCounted
+ {
+ public:
++static constexpr qreal DEFAULT_UNITS_PER_EM = 1000;
+ QSvgFont(qreal horizAdvX);
+
+ void setFamilyName(const QString );
+@@ -50,9 +51,7 @@ public:
+ void draw(QPainter *p, const QPointF , const QString , qreal
pixelSize, Qt::Alignment alignment) const;
+ public:
+ QString m_familyName;
+-qreal m_unitsPerEm;
+-qreal m_ascent;
+-qreal m_descent;
++qreal m_unitsPerEm = DEFAULT_UNITS_PER_EM;
+ qreal m_horizAdvX;
+ QHash m_glyphs;
+ };
+--- a/src/svg/qsvghandler.cpp
b/src/svg/qsvghandler.cpp
+@@ -2622,7 +2622,7 @@ static bool parseFontFaceNode(QSvgStyleP
+
+ qreal unitsPerEm = toDouble(unitsPerEmStr);
+ if (!unitsPerEm)
+-unitsPerEm = 1000;
++unitsPerEm = QSvgFont::DEFAULT_UNITS_PER_EM;
+
+ if (!name.isEmpty())
+ font->setFamilyName(name);
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..71efccf
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1,2 @@
+# Fixed in 6.5.
+cve-2023-32573.diff
Bug#1036562: unblock: qtbase-opensource-src/5.15.8+dfsg-10
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: qtbase-opensource-...@packages.debian.org, mity...@debian.org,
lisan...@debian.org
Control: affects -1 + src:qtbase-opensource-src
Please unblock package qtbase-opensource-src
[ Reason ]
This upload:
- Fixes CVE-2023-32762 and CVE-2023-32763. One prevents a crash with SVG
(not related to the one in qtsvg-opensource-src) and the other one
related to a security heade parsing in the network module.
- Adds a Break/Replaces in order to allow proper handling of systems
that still had libqtcore4 around (#1035790).
- Backports a patch in order to solve an issue with KWin:
- https://bugreports.qt.io/browse/QTBUG-98048
- https://lists.debian.org/debian-kde/2022/11/msg00019.html
[ Impact ]
- Lack of security fixes.
- Breaks the bullseye → bookworm update on some systems.
- Nasty visual effects while drag and dropping.
[ Tests ]
All the patches have been tested by upstream.
The security patches are quite straightforward.
The B/R issue is also straightforward, with a specific Qt4 version
allowing users to keep libqt4 around if necessary.
Drag and dropping just works as expected.
[ Risks ]
Sincerely I don't think there are risks here.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock qtbase-opensource-src/5.15.8+dfsg-10
diff --git a/debian/changelog b/debian/changelog
index 8c172cff..1f5b73f0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+qtbase-opensource-src (5.15.8+dfsg-10) unstable; urgency=medium
+
+ * Add patches to fix CVE-2023-32762 and CVE-2023-32763.
+
+ -- Lisandro Damián Nicanor Pérez Meyer Mon, 22 May
2023 11:31:55 -0300
+
+qtbase-opensource-src (5.15.8+dfsg-9) unstable; urgency=medium
+
+ * Backport upstream patch to fix laggy drag-and-drop with KWin. See:
+- https://bugreports.qt.io/browse/QTBUG-98048
+- https://lists.debian.org/debian-kde/2022/11/msg00019.html
+
+ -- Dmitry Shachnev Sun, 21 May 2023 12:19:31 +0300
+
qtbase-opensource-src (5.15.8+dfsg-8) unstable; urgency=medium
* Add back Breaks/Replaces for libqtcore4 (closes: #1035790).
diff --git a/debian/patches/CVE-2023-32762.patch
b/debian/patches/CVE-2023-32762.patch
new file mode 100644
index ..d0deff76
--- /dev/null
+++ b/debian/patches/CVE-2023-32762.patch
@@ -0,0 +1,17 @@
+---
+ src/network/access/qhsts.cpp |4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/src/network/access/qhsts.cpp
b/src/network/access/qhsts.cpp
+@@ -364,8 +364,8 @@ quoted-pair= "\" CHAR
+ bool QHstsHeaderParser::parse(const QList>
)
+ {
+ for (const auto : headers) {
+-// We use '==' since header name was already 'trimmed' for us:
+-if (h.first == "Strict-Transport-Security") {
++// We compare directly because header name was already 'trimmed' for
us:
++if (h.first.compare("Strict-Transport-Security", Qt::CaseInsensitive)
== 0) {
+ header = h.second;
+ // RFC6797, 8.1:
+ //
diff --git a/debian/patches/cve-2023-32763.diff
b/debian/patches/cve-2023-32763.diff
new file mode 100644
index ..b74413dc
--- /dev/null
+++ b/debian/patches/cve-2023-32763.diff
@@ -0,0 +1,50 @@
+---
+ src/gui/painting/qfixed_p.h |9 +
+ src/gui/text/qtextlayout.cpp |9 ++---
+ 2 files changed, 15 insertions(+), 3 deletions(-)
+
+--- a/src/gui/painting/qfixed_p.h
b/src/gui/painting/qfixed_p.h
+@@ -54,6 +54,7 @@
+ #include
+ #include "QtCore/qdebug.h"
+ #include "QtCore/qpoint.h"
++#include
+ #include "QtCore/qsize.h"
+
+ QT_BEGIN_NAMESPACE
+@@ -182,6 +183,14 @@ Q_DECL_CONSTEXPR inline bool operator<(i
+ Q_DECL_CONSTEXPR inline bool operator>(const QFixed , int i) { return
f.value() > i * 64; }
+ Q_DECL_CONSTEXPR inline bool operator>(int i, const QFixed ) { return i *
64 > f.value(); }
+
++inline bool qAddOverflow(QFixed v1, QFixed v2, QFixed *r)
++{
++int val;
++bool result = add_overflow(v1.value(), v2.value(), );
++r->setValue(val);
++return result;
++}
++
+ #ifndef QT_NO_DEBUG_STREAM
+ inline QDebug <<(QDebug , const QFixed )
+ { return dbg << f.toReal(); }
+--- a/src/gui/text/qtextlayout.cpp
b/src/gui/text/qtextlayout.cpp
+@@ -2150,11 +2150,14 @@ found:
+ eng->maxWidth = qMax(eng->maxWidth, line.textWidth);
+ } else {
+ eng->minWidth = qMax(eng->minWidth, lbh.minw);
+-eng->maxWidth += line.textWidth;
++if (qAddOverflow(eng->maxWidth, line.textWidth, >maxWidth))
++eng->maxWidth = QFIXED_MAX;
+ }
+
+-if (line.textWidth > 0 && item < eng->layoutData->items.size())
+-eng->maxWidth += lbh.spaceData.textWidth;
++if (line.textWidth > 0 && item < eng->layoutData->items.size()) {
++if (qAddOverflow(eng->maxWidth, lbh.spaceData.textWidth,
>maxWidth))
Processed: unblock: qtbase-opensource-src/5.15.8+dfsg-10
Processing control commands: > affects -1 + src:qtbase-opensource-src Bug #1036562 [release.debian.org] unblock: qtbase-opensource-src/5.15.8+dfsg-10 Added indication that 1036562 affects src:qtbase-opensource-src -- 1036562: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036562 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1036560: unblock: libraw/0.20.2-2.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: lib...@packages.debian.org, car...@debian.org
Control: affects -1 + src:libraw
Hi release team,
Please unblock package libraw
[ Reason ]
Fixing two CVEs CVE-2021-32142 (would be no-dsa considered), and
CVE-2023-1729. As we do plan to release a DSA for bullseye-security it
is wise to have the fixes as well in the upper suite.
[ Impact ]
libraw in bookworm affected by CVE-2021-32142 and CVE-2023-1729 until
the bookworm point releases or security update.
[ Tests ]
None specifically, autopkgtest with smoketest passes.
[ Risks ]
Two isolated fixes whith low risk I believe.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
None
unblock libraw/0.20.2-2.1
Regards,
Salvatore
diff -Nru libraw-0.20.2/debian/changelog libraw-0.20.2/debian/changelog
--- libraw-0.20.2/debian/changelog 2021-09-11 16:56:07.0 +0200
+++ libraw-0.20.2/debian/changelog 2023-05-20 21:44:42.0 +0200
@@ -1,3 +1,13 @@
+libraw (0.20.2-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * check for input buffer size on datastream::gets (CVE-2021-32142)
+(Closes: #1031790)
+ * do not set shrink flag for 3/4 component images (CVE-2023-1729)
+(Closes: #1036281)
+
+ -- Salvatore Bonaccorso Sat, 20 May 2023 21:44:42 +0200
+
libraw (0.20.2-2) unstable; urgency=medium
* debian/watch: bump version 3 -> 4
diff -Nru
libraw-0.20.2/debian/patches/check-for-input-buffer-size-on-datastream-gets.patch
libraw-0.20.2/debian/patches/check-for-input-buffer-size-on-datastream-gets.patch
---
libraw-0.20.2/debian/patches/check-for-input-buffer-size-on-datastream-gets.patch
1970-01-01 01:00:00.0 +0100
+++
libraw-0.20.2/debian/patches/check-for-input-buffer-size-on-datastream-gets.patch
2023-05-20 21:44:42.0 +0200
@@ -0,0 +1,43 @@
+From: Alex Tutubalin
+Date: Mon, 12 Apr 2021 13:21:52 +0300
+Subject: check for input buffer size on datastream::gets
+Origin:
https://github.com/LibRaw/LibRaw/commit/bc3aaf4223fdb70d52d470dae65c5a7923ea2a49
+Bug: https://github.com/LibRaw/LibRaw/issues/400
+Bug-Debian: https://bugs.debian.org/1031790
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-32142
+
+---
+ src/libraw_datastream.cpp | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/src/libraw_datastream.cpp b/src/libraw_datastream.cpp
+index a5c1a84a3a8c..a31ae9dd84db 100644
+--- a/src/libraw_datastream.cpp
b/src/libraw_datastream.cpp
+@@ -287,6 +287,7 @@ INT64 LibRaw_file_datastream::tell()
+
+ char *LibRaw_file_datastream::gets(char *str, int sz)
+ {
++ if(sz<1) return NULL;
+ LR_STREAM_CHK();
+ std::istream is(f.get());
+ is.getline(str, sz);
+@@ -421,6 +422,7 @@ INT64 LibRaw_buffer_datastream::tell()
+
+ char *LibRaw_buffer_datastream::gets(char *s, int sz)
+ {
++ if(sz<1) return NULL;
+ unsigned char *psrc, *pdest, *str;
+ str = (unsigned char *)s;
+ psrc = buf + streampos;
+@@ -618,6 +620,7 @@ INT64 LibRaw_bigfile_datastream::tell()
+
+ char *LibRaw_bigfile_datastream::gets(char *str, int sz)
+ {
++ if(sz<1) return NULL;
+ LR_BF_CHK();
+ return fgets(str, sz, f);
+ }
+--
+2.40.1
+
diff -Nru
libraw-0.20.2/debian/patches/do-not-set-shrink-flag-for-3-4-component-images.patch
libraw-0.20.2/debian/patches/do-not-set-shrink-flag-for-3-4-component-images.patch
---
libraw-0.20.2/debian/patches/do-not-set-shrink-flag-for-3-4-component-images.patch
1970-01-01 01:00:00.0 +0100
+++
libraw-0.20.2/debian/patches/do-not-set-shrink-flag-for-3-4-component-images.patch
2023-05-20 21:44:42.0 +0200
@@ -0,0 +1,28 @@
+From: Alex Tutubalin
+Date: Sat, 14 Jan 2023 18:32:59 +0300
+Subject: do not set shrink flag for 3/4 component images
+Origin:
https://github.com/LibRaw/LibRaw/commit/477e0719ffc07190c89b4f3d12d51b1292e75828
+Bug: https://github.com/LibRaw/LibRaw/issues/557
+Bug-Debian: https://bugs.debian.org/1036281
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-1729
+
+---
+ src/preprocessing/raw2image.cpp | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/preprocessing/raw2image.cpp b/src/preprocessing/raw2image.cpp
+index e65e2ad73b4a..702cf290213c 100644
+--- a/src/preprocessing/raw2image.cpp
b/src/preprocessing/raw2image.cpp
+@@ -43,6 +43,8 @@ void LibRaw::raw2image_start()
+
+ // adjust for half mode!
+ IO.shrink =
++!imgdata.rawdata.color4_image && !imgdata.rawdata.color3_image &&
++!imgdata.rawdata.float4_image && !imgdata.rawdata.float3_image &&
+ P1.filters &&
+ (O.half_size || ((O.threshold || O.aber[0] != 1 || O.aber[2] != 1)));
+
+--
+2.40.1
+
diff -Nru libraw-0.20.2/debian/patches/series
libraw-0.20.2/debian/patches/series
--- libraw-0.20.2/debian/patches/series 1970-01-01
Processed: unblock: libraw/0.20.2-2.1
Processing control commands: > affects -1 + src:libraw Bug #1036560 [release.debian.org] unblock: libraw/0.20.2-2.1 Added indication that 1036560 affects src:libraw -- 1036560: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036560 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: unblock: debian-med/3.8.1
Processing control commands: > affects -1 + src:debian-med Bug #1036557 [release.debian.org] unblock: debian-med/3.8.1 Added indication that 1036557 affects src:debian-med -- 1036557: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036557 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1036557: unblock: debian-med/3.8.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-...@packages.debian.org, debian-...@lists.debian.org Control: affects -1 + src:debian-med Please unblock package debian-med [ Reason ] This is the final update of the Debian Med metapackages after some changes in the package pool. Since some packages were removed from testing this had to be reflected in the dependencies of the metapackages Updating Blends metapackages in the final phase of a release cyclus to adapt to those changes is the usual thing we do in the release process. [ Impact ] The metapackages would recommend packages that are not available in the future stable release. [ Tests ] There is no test but the automatic generation of the dependencies was done as usual and has shown to be reliable in the past. The resulting changes make perfectly sense. [ Risks ] There is not even code and its a leaf package anyway. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] unblock debian-med/3.8.1 debian-med_3.8.1-3.8.debdiff.gz Description: application/gzip
Processed: unblock: python-apt/2.6.0
Processing control commands: > affects -1 + src:python-apt Bug #1036556 [release.debian.org] unblock: python-apt/2.6.0 Added indication that 1036556 affects src:python-apt -- 1036556: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036556 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1036554: unblock: iproute2/6.1.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear Release Team,
A small regression w.r.t. Bookworm has just been reported on iproute2.
It is a trivial fix so I'd like to have it in the release if possible.
debdiff attached.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036534
Thanks!
--
Kind regards,
Luca Boccassi
diff -Nru iproute2-6.1.0/debian/changelog iproute2-6.1.0/debian/changelog
--- iproute2-6.1.0/debian/changelog 2023-02-25 19:46:35.0 +
+++ iproute2-6.1.0/debian/changelog 2023-05-22 14:19:52.0 +0100
@@ -1,3 +1,9 @@
+iproute2 (6.1.0-3) unstable; urgency=medium
+
+ * Ensure 'ip mo' resolves to 'ip monitor' (Closes: #1036534)
+
+ -- Luca Boccassi Mon, 22 May 2023 14:19:52 +0100
+
iproute2 (6.1.0-2) unstable; urgency=medium
* Add Romanian language translation for debconf (Closes: #1031917)
diff -Nru iproute2-6.1.0/debian/patches/0001-Add-moo-feature.patch iproute2-6.1.0/debian/patches/0001-Add-moo-feature.patch
--- iproute2-6.1.0/debian/patches/0001-Add-moo-feature.patch 2023-02-25 19:04:02.0 +
+++ iproute2-6.1.0/debian/patches/0001-Add-moo-feature.patch 2023-05-22 14:19:19.0 +0100
@@ -3,7 +3,7 @@
Forwarded: no, critical value-add business feature for Debian
--- a/ip/ip.c
+++ b/ip/ip.c
-@@ -86,6 +86,19 @@
+@@ -87,6 +87,19 @@
return 0;
}
@@ -23,11 +23,11 @@
static const struct cmd {
const char *cmd;
int (*func)(int argc, char **argv);
-@@ -104,6 +117,7 @@
- { "fou", do_ipfou },
- { "ila", do_ipila },
- { "macsec", do_ipmacsec },
+@@ -125,6 +138,7 @@
+ { "ioam", do_ioam6 },
+ { "help", do_help },
+ { "stats", do_ipstats },
+ { "moo", do_moo },
- { "tunnel", do_iptunnel },
- { "tunl", do_iptunnel },
- { "tuntap", do_iptuntap },
+ { 0 }
+ };
+
signature.asc
Description: This is a digitally signed message part
Bug#1036459: marked as done (pre-unblock: palo/2.23)
Your message dated Mon, 22 May 2023 15:23:05 +0200 with message-id <52e6c244-c024-e843-bdfa-8df09e639...@gmx.de> and subject line pre-unblock: palo/2.23 has caused the Debian Bug report #1036459, regarding pre-unblock: palo/2.23 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 ow...@bugs.debian.org immediately.) -- 1036459: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036459 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Control: affects -1 src:palo This pre-unblock request is to get a decision from the Bookworm release team if I'm allowed to upload the palo 2.23 bug-fix version. - palo is a bootloader for the PA-RISC (hppa) architecture, comparable to lilo or grub on x86. - hppa is NOT a release architecture, and the palo package does NOT affect any of the release architectures (palo can be used on x86 to generate an ISO image for hppa though) - the new palo version has some important bootloader fixes for specific parisc machines - it would be nice to get OK here, as even if hppa is not a release architecture, we plan to build bookworm-install CD's for hppa in debian-ports and it would be nice to have latest palo bootloader available in the bookworm release, else people will install bookworm/parisc and have an old/buggy bootloader. Ok to upload/unblock palo/2.23 ? Thanks, Helge --- End Message --- --- Begin Message --- v2.23 was uploaded--- End Message ---
Bug#1036553: unblock: qtsvg-opensource-src/5.15.8-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: qtsvg-opensource-...@packages.debian.org
Control: affects -1 + src:qtsvg-opensource-src
Please unblock package qtsvg-opensource-src.
[ Reason ]
This fixes a security bug. See:
- https://security-tracker.debian.org/tracker/CVE-2023-32573
- https://www.qt.io/blog/security-advisory-qt-svg
[ Impact ]
Use of uninitialized variable which is undefined behavior, e.g. may lead to
division by zero.
[ Tests ]
The upstream test suite is run during build.
[ Risks ]
The change is quite trivial, it just initializes the variable and uses a
constant
to keep the value in one place.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock qtsvg-opensource-src/5.15.8-3
--
Dmitry Shachnev
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+qtsvg-opensource-src (5.15.8-3) unstable; urgency=medium
+
+ * Backport upstream commit to initialize QSvgFont::m_unitsPerEm
+(CVE-2023-32573).
+
+ -- Dmitry Shachnev Sun, 21 May 2023 19:06:01 +0300
+
qtsvg-opensource-src (5.15.8-2) unstable; urgency=medium
* Upload to unstable.
--- /dev/null
+++ b/debian/patches/CVE-2023-32573.diff
@@ -0,0 +1,34 @@
+Description: QSvgFont: initialize m_unitsPerEm to fix undefined behavior
+Origin: upstream, https://download.qt.io/official_releases/qt/5.15/CVE-2023-32573-qtsvg-5.15.diff
+Last-Update: 2023-05-21
+
+--- a/src/svg/qsvgfont_p.h
b/src/svg/qsvgfont_p.h
+@@ -74,6 +74,7 @@ public:
+ class Q_SVG_PRIVATE_EXPORT QSvgFont : public QSvgRefCounted
+ {
+ public:
++static constexpr qreal DEFAULT_UNITS_PER_EM = 1000;
+ QSvgFont(qreal horizAdvX);
+
+ void setFamilyName(const QString );
+@@ -86,7 +87,7 @@ public:
+ void draw(QPainter *p, const QPointF , const QString , qreal pixelSize, Qt::Alignment alignment) const;
+ public:
+ QString m_familyName;
+-qreal m_unitsPerEm;
++qreal m_unitsPerEm = DEFAULT_UNITS_PER_EM;
+ qreal m_ascent;
+ qreal m_descent;
+ qreal m_horizAdvX;
+--- a/src/svg/qsvghandler.cpp
b/src/svg/qsvghandler.cpp
+@@ -2666,7 +2666,7 @@ static bool parseFontFaceNode(QSvgStyleP
+
+ qreal unitsPerEm = toDouble(unitsPerEmStr);
+ if (!unitsPerEm)
+-unitsPerEm = 1000;
++unitsPerEm = QSvgFont::DEFAULT_UNITS_PER_EM;
+
+ if (!name.isEmpty())
+ font->setFamilyName(name);
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
reject_oversize_svgs.diff
+CVE-2023-32573.diff
signature.asc
Description: PGP signature
Processed: unblock: qtsvg-opensource-src/5.15.8-3
Processing control commands: > affects -1 + src:qtsvg-opensource-src Bug #1036553 [release.debian.org] unblock: qtsvg-opensource-src/5.15.8-3 Added indication that 1036553 affects src:qtsvg-opensource-src -- 1036553: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036553 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1036552: unblock: twinkle/1:1.10.2+dfsg-2
Package: release.debian.org
Control: affects -1 + src:twinkle
X-Debbugs-Cc: twin...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package twinkle.
[ Reason ]
Fix for RC bug #1034661.
[ Impact ]
User's browser might end up opening a spam (and maybe web exploiting) website.
[ Tests ]
Opening the About section's manual will open
https://mfnboer.home.xs4all.nl/twinkle/ instead of the spam website.
[ Risks ]
None.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock twinkle/1:1.10.2+dfsg-2diff -Nru twinkle-1.10.2+dfsg/debian/changelog
twinkle-1.10.2+dfsg/debian/changelog
--- twinkle-1.10.2+dfsg/debian/changelog2020-12-03 15:47:34.0
+0100
+++ twinkle-1.10.2+dfsg/debian/changelog2023-05-20 17:12:46.0
+0200
@@ -1,3 +1,10 @@
+twinkle (1:1.10.2+dfsg-2) unstable; urgency=medium
+
+ * Team upload.
+ * Change upstream URL taken over by hostile actors (Closes: #1034661)
+
+ -- Bernhard Schmidt Sat, 20 May 2023 17:12:46 +0200
+
twinkle (1:1.10.2+dfsg-1) unstable; urgency=medium
* New upstream version 1.10.2+dfsg
diff -Nru twinkle-1.10.2+dfsg/debian/patches/remove-malicious-homepage.patch
twinkle-1.10.2+dfsg/debian/patches/remove-malicious-homepage.patch
--- twinkle-1.10.2+dfsg/debian/patches/remove-malicious-homepage.patch
1970-01-01 01:00:00.0 +0100
+++ twinkle-1.10.2+dfsg/debian/patches/remove-malicious-homepage.patch
2023-05-20 17:12:46.0 +0200
@@ -0,0 +1,63 @@
+From da274607aa835a2735dcf9b9a7ba550910f9d03e Mon Sep 17 00:00:00 2001
+From: matchi
+Date: Wed, 1 Dec 2021 09:54:39 +0100
+Subject: [PATCH] changed references to http(s)://twinklephone.com to
+ https://mfnboer.home.xs4all.nl/twinkle/
+
+(cherry picked from commit 165c43d8a1574946e7704c639c56cea3d5264606)
+---
+ AUTHORS| 2 +-
+ src/gui/lang/twinkle_de.ts | 2 +-
+ src/gui/mphoneform.cpp | 2 +-
+ twinkle.spec.in| 2 +-
+ 4 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/AUTHORS b/AUTHORS
+index 88cbeadb..ec1ad55c 100644
+--- a/AUTHORS
b/AUTHORS
+@@ -33,4 +33,4 @@ Russian Michail Chodorenko
+ Swedish Daniel Nylander
+
+ Michel de Boer
+-www.twinklephone.com
++https://mfnboer.home.xs4all.nl/twinkle/
+diff --git a/src/gui/lang/twinkle_de.ts b/src/gui/lang/twinkle_de.ts
+index 8ab0b014..a5b38916 100644
+--- a/src/gui/lang/twinkle_de.ts
b/src/gui/lang/twinkle_de.ts
+@@ -5620,7 +5620,7 @@ The values of all SIP headers in the incoming INVITE
message are passed in envir
+ TWINKLE_TRIGGER=in_call. SIPREQUEST_METHOD=INVITE. The request-URI of the
INVITE will be passed in bSIPREQUEST_URI/b. The name of the
user profile will be passed in bTWINKLE_USER_PROFILE/b.
+ p
+ Dieses Script wird gerufen, wenn ein INVITE (Anruf) ankommt. br
+-Bitte lesen Sie im Handbuch unter
/usr/share/doc/packages/twinkle/... oder
http://twinklephone.com; die ausführliche Beschreibung!
++Bitte lesen Sie im Handbuch unter
/usr/share/doc/packages/twinkle/... oder
https://mfnboer.home.xs4all.nl/twinkle/; die ausführliche
Beschreibung!
+ /p
+ h3Rückgabewerte/h3 - print nach STDOUT (z.B. `echo
action=dnd`), ein Wert pro Zeile: br
+ ttaction=[ continue | reject | dnd | redirect | autoanswer
]br/tt
+diff --git a/src/gui/mphoneform.cpp b/src/gui/mphoneform.cpp
+index c4e3c1d9..abca70d0 100644
+--- a/src/gui/mphoneform.cpp
b/src/gui/mphoneform.cpp
+@@ -2290,7 +2290,7 @@ void MphoneForm::aboutQt()
+
+ void MphoneForm::manual()
+ {
+- ((t_gui *)ui)->open_url_in_browser("http://www.twinklephone.com;);
++ ((t_gui
*)ui)->open_url_in_browser("https://mfnboer.home.xs4all.nl/twinkle/;);
+ }
+
+ void MphoneForm::editUserProfile()
+diff --git a/twinkle.spec.in b/twinkle.spec.in
+index 989c4514..7c014167 100644
+--- a/twinkle.spec.in
b/twinkle.spec.in
+@@ -10,7 +10,7 @@ BuildArch: i586
+ #BuildArch: x86_64
+ BuildRoot:%{_tmppath}/making_of_%{name}_%{version}
+ Packager:
+-URL: http://www.twinklephone.com
++URL: https://mfnboer.home.xs4all.nl/twinkle/
+ Requires: alsa
+ Requires: ucommon
+ Requires: ccrtp >= 1.6.0
diff -Nru twinkle-1.10.2+dfsg/debian/patches/series
twinkle-1.10.2+dfsg/debian/patches/series
--- twinkle-1.10.2+dfsg/debian/patches/series 1970-01-01 01:00:00.0
+0100
+++ twinkle-1.10.2+dfsg/debian/patches/series 2023-05-20 17:12:46.0
+0200
@@ -0,0 +1 @@
+remove-malicious-homepage.patch
Processed: unblock: twinkle/1:1.10.2+dfsg-2
Processing control commands: > affects -1 + src:twinkle Bug #1036552 [release.debian.org] unblock: twinkle/1:1.10.2+dfsg-2 Added indication that 1036552 affects src:twinkle -- 1036552: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036552 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1036548: unblock: cups-filters/1.28.17-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock and age package cups-filters
[ Reason ]
CVE-2023-24805 (RCE due to missing input sanitising)
[ Impact ]
The user would be vulnerable to remote code execution.
[ Tests ]
There is no special test for this patch, only a POC that no
longer worked after applying the patch.
[ Risks ]
The patch was provided by upstream and approved by the security team
(upload to Bullseye already done).
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock cups-filters/1.28.17-3diff -Nru cups-filters-1.28.17/debian/changelog
cups-filters-1.28.17/debian/changelog
--- cups-filters-1.28.17/debian/changelog 2023-03-10 19:25:20.0
+0100
+++ cups-filters-1.28.17/debian/changelog 2023-05-19 18:25:20.0
+0200
@@ -1,3 +1,14 @@
+cups-filters (1.28.17-3) unstable; urgency=medium
+
+ * CVE-2023-24805
+prevent arbitrary command execution by escaping the quoting
+of the arguments in a job with a forged job title
+more information are available in the commit message at:
+https://github.com/OpenPrinting/cups-filters/commit/93e60d3df35
+(Closes: #1036224)
+
+ -- Thorsten Alteholz Fri, 19 May 2023 18:25:20 +0200
+
cups-filters (1.28.17-2) unstable; urgency=medium
* qpdf needs at least c++17
diff -Nru cups-filters-1.28.17/debian/patches/0003-fix-CVE-2023-24805.patch
cups-filters-1.28.17/debian/patches/0003-fix-CVE-2023-24805.patch
--- cups-filters-1.28.17/debian/patches/0003-fix-CVE-2023-24805.patch
1970-01-01 01:00:00.0 +0100
+++ cups-filters-1.28.17/debian/patches/0003-fix-CVE-2023-24805.patch
2023-05-19 10:50:03.0 +0200
@@ -0,0 +1,176 @@
+From: Thorsten Alteholz
+Date: Fri, 19 May 2023 10:49:35 +0200
+Subject: fix CVE-2023-24805
+
+---
+ backend/beh.c | 107 +-
+ 1 file changed, 84 insertions(+), 23 deletions(-)
+
+diff --git a/backend/beh.c b/backend/beh.c
+index 225fd27..8d51235 100644
+--- a/backend/beh.c
b/backend/beh.c
+@@ -22,12 +22,13 @@
+ #include "backend-private.h"
+ #include
+ #include
++#include
+
+ /*
+ * Local globals...
+ */
+
+-static intjob_canceled = 0; /* Set to 1 on SIGTERM */
++static volatile int job_canceled = 0; /* Set to 1 on SIGTERM */
+
+ /*
+ * Local functions...
+@@ -213,21 +214,40 @@ call_backend(char *uri, /* I - URI of
final destination */
+char **argv, /* I - Command-line arguments */
+char *filename) { /* I - File name of input data */
+ const char *cups_serverbin;/* Location of programs */
++ char *backend_argv[8]; /* Arguments for backend */
+ charscheme[1024], /* Scheme from URI */
+ *ptr, /* Pointer into scheme */
+- cmdline[65536]; /* Backend command line */
+- int retval;
++ backend_path[2048]; /* Backend path */
++ int pid = 0, /* Process ID of backend */
++wait_pid, /* Process ID from wait() */
++wait_status, /* Status from child */
++retval = 0;
++ int bytes;
+
+ /*
+ * Build the backend command line...
+ */
+
+- strncpy(scheme, uri, sizeof(scheme) - 1);
+- if (strlen(uri) > 1023)
+-scheme[1023] = '\0';
++ scheme[0] = '\0';
++ strncat(scheme, uri, sizeof(scheme) - 1);
+ if ((ptr = strchr(scheme, ':')) != NULL)
+ *ptr = '\0';
+-
++ else {
++fprintf(stderr,
++ "ERROR: beh: Invalid URI, no colon (':') to mark end of scheme
part.\n");
++exit (CUPS_BACKEND_FAILED);
++ }
++ if (strchr(scheme, '/')) {
++fprintf(stderr,
++ "ERROR: beh: Invalid URI, scheme contains a slash ('/').\n");
++exit (CUPS_BACKEND_FAILED);
++ }
++ if (!strcmp(scheme, ".") || !strcmp(scheme, "..")) {
++fprintf(stderr,
++ "ERROR: beh: Invalid URI, scheme (\"%s\") is a directory.\n",
++ scheme);
++exit (CUPS_BACKEND_FAILED);
++ }
+ if ((cups_serverbin = getenv("CUPS_SERVERBIN")) == NULL)
+ cups_serverbin = CUPS_SERVERBIN;
+
+@@ -235,16 +255,29 @@ call_backend(char *uri, /* I - URI of
final destination */
+ fprintf(stderr,
+ "ERROR: beh: Direct output into a file not supported.\n");
+ exit (CUPS_BACKEND_FAILED);
+- } else
+-snprintf(cmdline, sizeof(cmdline),
+- "%s/backend/%s '%s' '%s' '%s' '%s' '%s' %s",
+- cups_serverbin, scheme, argv[1], argv[2], argv[3],
+- /* Apply number of copies only if beh was called with a
+- file name and not with the print data in stdin, as
+- backends should handle copies only if they are called
+- with a
Re: non-essential adduser poses problems to purging packages
On 18/05/2023 21.05, Johannes Schauer Marin Rodrigues wrote: Hi, Quoting Nicolas Dandrimont (2023-05-18 20:51:04) On Thu, May 18, 2023, at 10:03, Marc Haber wrote: adduser probably needs an additional hint because the new upload makes piuparts fail now, as discussed yesterday. To work around this issue on the piuparts side, it sounds like we should make piuparts treat adduser as fake-essential for tests ending at bookworm or sid, so that we don't try to uninstall it; Andreas, what do you think? a more general solution would be to skip uninstallation on all packages marked with Protected:yes or to only uninstall with --allow-remove-essential. Such a solution would not only benefit adduser but also any future packages marked with Protected:yes. We have some scripts that enable --allow-remove-essential before removal on some upgrade paths if certain packages are installed, iirc we needed this for some *init* stuff in the past. I'd prefer this way over making adduser globally fake-essential (as that would introduce adduser into all upgrade paths. (Making it fake-essential for only a few packages would probably no longer work with Protected:yes). Skipping removal of Protected:yes packages is no option, as it does not restore the state of the refernece chroot. I'll think about it. Andreas
Bug#1036246: unblock: iptables-netflow/2.6-4
On 18/05/2023 02.32, Axel Beckert wrote: * Autopkgtest in Sid via autopkgtest-pkg-dkms: https://qa.debian.org/excuses.php?package=iptables-netflow says "No test results" for all tests. I'm not sure what this actually means. If I click on such a link I see: dkms-autopkgtest PASS (superficial) "No test results" is a an unlucky wording for a "neutral" test result (i.e. there are only superficial tests, but all these have passed). IIRC there is already a bug about the wording. All dkms-autopkgtest tests are marked as "superficial" since they only test compilation of the kernel module. There is no attempt to load it into a kernel (or even "use" it in some way). Andreas
Processed: pre-unblock: palo/2.23
Processing commands for cont...@bugs.debian.org: > fixed 1036459 2.23 Bug #1036459 [release.debian.org] pre-unblock: palo/2.23 There is no source info for the package 'release.debian.org' at version '2.23' with architecture '' Unable to make a source version for version '2.23' Marked as fixed in versions 2.23. > End of message, stopping processing here. Please contact me if you need assistance. -- 1036459: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036459 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1036542: unblock: ayatana-indicator-sound/22.9.2-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package ayatana-indicator-sound
[ Reason ]
This change/upload is part of a series of three uploads
(ayatana-indicator-sound, lomiri-session and tone-generator) that fixes
co-installability of Lomiri and GNOME.
[ Impact ]
When co-installing GNOME and Lomiri, pulseaudio will be removed and
Lomiri needs to tolerate running on top of pipewire with pipewire-pulse
compat layer for pulseaudio.
[ Tests ]
Co-installation tests. Sound in Lomiri is still operational.
[ Risks ]
Audio operations in Lomiri haven't all been tested in depth. So
regressions might pop up. These, however, should be considered as flaws
in pipewire-pulse not providing a 100% pulseaudio-compatible API.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
This unblock correlates with two other unblocks (lomiri-session,
tone-generator).
unblock ayatana-indicator-sound/22.9.2-3
+ * debian/control:
++ Add pipewire-pulse as alternative D for pulseaudio. (Closes: #1035093).
diff -Nru ayatana-indicator-sound-22.9.2/debian/changelog
ayatana-indicator-sound-22.9.2/debian/changelog
--- ayatana-indicator-sound-22.9.2/debian/changelog 2023-02-14
10:50:59.0 +0100
+++ ayatana-indicator-sound-22.9.2/debian/changelog 2023-05-22
09:51:00.0 +0200
@@ -1,3 +1,10 @@
+ayatana-indicator-sound (22.9.2-3) unstable; urgency=medium
+
+ * debian/control:
++ Add pipewire-pulse as alternative D for pulseaudio. (Closes: #1035093).
+
+ -- Mike Gabriel Mon, 22 May 2023 09:51:00 +0200
+
ayatana-indicator-sound (22.9.2-2) unstable; urgency=medium
* debian/control:
diff -Nru ayatana-indicator-sound-22.9.2/debian/control
ayatana-indicator-sound-22.9.2/debian/control
--- ayatana-indicator-sound-22.9.2/debian/control 2023-02-14
10:49:58.0 +0100
+++ ayatana-indicator-sound-22.9.2/debian/control 2023-05-22
09:40:22.0 +0200
@@ -49,7 +49,7 @@
Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends},
- pulseaudio,
+ pulseaudio | pipewire-pulse,
ayatana-indicator-common (>= 0.8.0),
libglib2.0-bin,
Recommends: unity-control-center | gnome-control-center | pavucontrol |
mate-media | lomiri-system-settings,
Bug#1036541: unblock: tone-generator/1.6.1-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package tone-generator
[ Reason ]
This change/upload is part of a series of three uploads
(ayatana-indicator-sound, lomiri-session and tone-generator) that fixes
co-installability of Lomiri and GNOME.
[ Impact ]
When co-installing GNOME and Lomiri, pulseaudio will be removed and
Lomiri needs to tolerated running on top of pipewire with pipewire-pulse
compat layer for pulseaudio.
[ Tests ]
Co-installation tests. Sound in Lomiri is still operational.
[ Risks ]
Audio operations in Lomiri haven't all been tested in depth. So
regressions might pop up. These, however, should be considered as flaws
in pipewire-pulse not providing a 100% pulseaudio-compatible API.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
This unblock correlates with two other unblocks (ayatana-indicator-sound,
tone-generator).
Furthermore, as part of this upload a URL change has been applied to the
watch URL (required these days by gitlab.com).
unblock tone-generator/1.6.1-3
+ * debian/watch: Amend watch URL.
+ * debian/control:
++ Add pipewire-pulse as alternative D for pulseaudio. Support parallel
+ installation of Lomiri and GNOME (relates to #1035093 and #1035095).
diff -Nru tone-generator-1.6.1/debian/changelog
tone-generator-1.6.1/debian/changelog
--- tone-generator-1.6.1/debian/changelog 2023-01-27 22:34:32.0
+0100
+++ tone-generator-1.6.1/debian/changelog 2023-05-22 10:06:16.0
+0200
@@ -1,3 +1,12 @@
+tone-generator (1.6.1-3) unstable; urgency=medium
+
+ * debian/watch: Amend watch URL.
+ * debian/control:
++ Add pipewire-pulse as alternative D for pulseaudio. Support parallel
+ installation of Lomiri and GNOME (relates to #1035093 and #1035095).
+
+ -- Mike Gabriel Mon, 22 May 2023 10:06:16 +0200
+
tone-generator (1.6.1-2) unstable; urgency=medium
* Re-upload as is source-only.
diff -Nru tone-generator-1.6.1/debian/control
tone-generator-1.6.1/debian/control
--- tone-generator-1.6.1/debian/control 2023-01-27 22:31:06.0 +0100
+++ tone-generator-1.6.1/debian/control 2023-05-22 10:06:16.0 +0200
@@ -22,7 +22,7 @@
Architecture: any
Depends:
dbus,
- pulseaudio,
+ pulseaudio | pipewire-pulse,
${misc:Depends},
${shlibs:Depends},
Recommends:
diff -Nru tone-generator-1.6.1/debian/watch tone-generator-1.6.1/debian/watch
--- tone-generator-1.6.1/debian/watch 2023-01-27 22:31:06.0 +0100
+++ tone-generator-1.6.1/debian/watch 2023-05-22 10:06:16.0 +0200
@@ -1,2 +1,2 @@
version=4
-https://gitlab.com/ubports/development/core/tone-generator/tags
.*/tone-generator-(\d\S+)\.tar\.gz
+https://gitlab.com/ubports/development/core/tone-generator/-/tags
.*/tone-generator-(\d\S+)\.tar\.gz
Bug#1036540: unblock: lomiri-session/0.2-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package lomiri-session
[ Reason ]
It was discovered that GNOME and Lomiri weren't co-installable.
[ Impact ]
When co-installing GNOME and Lomiri, pulseaudio will be removed and
Lomiri needs to tolerated running on top of pipewire with pipewire-pulse
compat layer for pulseaudio.
[ Tests ]
Co-installation tests. Sound in Lomiri is still operational.
[ Risks ]
Audio operations in Lomiri haven't all been tested in depth. So
regressions might pop up. These, however, should be considered as flaws
in pipewire-pulse not providing a 100% pulseaudio-compatible API.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
This unblock correlates with two other unblocks (ayatana-indicator-sound,
tone-generator).
unblock lomiri-session/0.2-4
diff -Nru lomiri-session-0.2/debian/changelog
lomiri-session-0.2/debian/changelog
--- lomiri-session-0.2/debian/changelog 2023-02-14 11:02:58.0 +0100
+++ lomiri-session-0.2/debian/changelog 2023-05-22 09:57:57.0 +0200
@@ -1,3 +1,10 @@
+lomiri-session (0.2-4) unstable; urgency=medium
+
+ * debian/control:
++ Add pipewire-pulse as alternative D for pulseaudio. (Closes: #1035095).
+
+ -- Mike Gabriel Mon, 22 May 2023 09:57:57 +0200
+
lomiri-session (0.2-3) unstable; urgency=medium
* debian/control:
diff -Nru lomiri-session-0.2/debian/control lomiri-session-0.2/debian/control
--- lomiri-session-0.2/debian/control 2023-02-14 11:02:58.0 +0100
+++ lomiri-session-0.2/debian/control 2023-05-22 09:55:56.0 +0200
@@ -19,7 +19,7 @@
Architecture: all
Depends:
dbus,
- pulseaudio,
+ pulseaudio | pipewire-pulse,
lomiri,
lomiri-terminal-app,
${misc:Depends},
Bug#1035377: marked as done (unblock: libapache2-mod-auth-openidc/2.4.12.3-2)
Your message dated Mon, 22 May 2023 09:08:25 +0200 with message-id and subject line Re: Bug#1035377: unblock: libapache2-mod-auth-openidc/2.4.12.3-2 has caused the Debian Bug report #1035377, regarding unblock: libapache2-mod-auth-openidc/2.4.12.3-2 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 ow...@bugs.debian.org immediately.) -- 1035377: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035377 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: libapache2-mod-auth-open...@packages.debian.org Control: affects -1 + src:libapache2-mod-auth-openidc Please unblock package libapache2-mod-auth-openidc Fixes CVE-2023-28625 "segfault DoS when OIDCStripCookies is set". [ Reason ] Fixes #1033916 by fixing CVE-2023-28625. [ Impact ] The CVE with Base Score: 7.5 HIGH Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H would persist in the new stable release. [ Tests ] The patch has been verified by upstream and I have successfully tested the new package version in our infrastructure. [ Risks ] The newly added patch changes just two lines by adding a null pointer check. I don't see anything getting worse by that. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock libapache2-mod-auth-openidc/2.4.12.3-2 --- End Message --- --- Begin Message --- Dear Paul, On 03.05.23 19:55, Paul Gevers wrote: Are you asking for aging, or did you miss the point that you didn't need to request an unblock? I'm sorry, but exactly that has been the case. @( Sorry about that! -- Moritz Schlarb Unix und Cloud Zentrum für Datenverarbeitung Johannes Gutenberg-Universität Mainz OpenPGP-Fingerprint: DF01 2247 BFC6 5501 AFF2 8445 0C24 B841 C7DD BAAF OpenPGP_signature Description: OpenPGP digital signature --- End Message ---
