Re: Help with resolving an issue with wxwidgets3.2
Hi Scott On Wed, 16 Nov 2022 at 04:03, Scott Talbert wrote: > 2) Rebuild wxWidgets with soname bump and then rebuild all packages that > use wx (about 67 packages). > > What do you think is the best way to proceed? Option 2 seems the safest. Please upload to experimental and request another transition slot. Regards Graham
Bug#1024756: transition: libktorrent
Hi Sebastian, Le 24 novembre 2022 21:23:47 GMT+01:00, Sebastian Ramacher a écrit : >Control: tags -1 confirmed >On 2022-11-24 11:05:08 +0100, Aurélien COUDERC wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> X-Debbugs-Cc: Debian Qt/KDE Maintainers >> >> Dear Release Team, >> >> I’d like to request a transition slot for libktorrent. >> >> It has 2 reverse dependencies: >> - kget >> - ktorrent >Please go ahead. libktorrent is uploaded to unstable and built on all relevant archs. Could you please binNMU kget and ktorrent ? Thanks, -- Aurélien
Bug#1023535: transition: protobuf
Hi Sebastian, On Thu, Nov 24, 2022 at 9:03 PM Sebastian Ramacher wrote: > On 2022-11-21 20:42:41 +0100, Sebastian Ramacher wrote: > > Please go ahead > > protobuf's autopkgtests are failing. Could you please take a look at > them? Thanks Indeed, my bad. Fixed and uploaded. Regards, Laszlo/GCS
Bug#1024343: itk-4.y buildability status
Control: severity 1012950 important Control: tags 1012950 - pending Hi, I reduce the severity of ITK4 ftbfs with introduction of gcc-12, since the package in its current form now uses gcc-11 only, and thus builds through. I also remove the tag pending upload since the initial problem is still unresolved. If I made a mistake by reducing the severity, feel free to re-raise it. I don't expect to push much further for ITK4. In hope this helps, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. On air: Genesis - White Mountain signature.asc Description: PGP signature
Bug#1023550: transition: qcustomplot
Greetings Sebastian, On Thu, Nov 24, 2022 at 09:05:07PM +0100, Sebastian Ramacher wrote: Hi Filippo [...] > Thanks! Please go ahead with the transition. I just uploaded the package to unstable. I have not closed the bug yet, waiting to check that everything goes fine. qcustomplot's autopkgtests are failing. Could you please take a look at them? Thanks It is weeks that I monitor the salsa stuff, but I do not understand what these tests mean. One example (bear with me): CMake Error at CMakeLists.txt:5 (FIND_PACKAGE): By not providing "FindQt5PrintSupport.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Qt5PrintSupport", but CMake did not find one. Could not find a package configuration file provided by "Qt5PrintSupport" with any of the following names: Qt5PrintSupportConfig.cmake qt5printsupport-config.cmake debian/control -- Build-Depends: debhelper (>= 13), cmake (>= 3.18), qtbase5-dev (>= 5.12), qt6-base-dev (>= 6.2.0) % apt-file search Qt5PrintSupportConfig.cmake qtbase5-dev: /usr/lib/x86_64-linux-gnu/cmake/Qt5PrintSupport/Qt5PrintSupportConfig.cmake So, I do not understand why the autopkgtest does not do the right thing: install the packages I have listed in Build-Depends... I always build my packages with cowbuilder (gbp buildpackage) in a pristine enviroment... Further, how can that be that the build passes and then the build of autopkgtest fails? I'd be happy to learn more about all this, but for the moment these inconsistencies make me dubitative... Sincerely, Filippo -- ⢀⣴⠾⠻⢶⣦⠀ Filippo Rusconi, PhD ⣾⠁⢠⠒⠀⣿⡁ Research scientist at CNRS ⢿⡄⠘⠷⠚⠋⠀ Debian Developer ⠈⠳⣄ http://msxpertsuite.org http://www.debian.org
Processed: Re: Bug#1024756: transition: libktorrent
Processing control commands: > tags -1 confirmed Bug #1024756 [release.debian.org] transition: libktorrent Added tag(s) confirmed. -- 1024756: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024756 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1024756: transition: libktorrent
Control: tags -1 confirmed Hi Aurélien On 2022-11-24 11:05:08 +0100, Aurélien COUDERC wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: Debian Qt/KDE Maintainers > > Dear Release Team, > > I’d like to request a transition slot for libktorrent. > > It has 2 reverse dependencies: > - kget > - ktorrent > > Both rebuild successfully with the new version of the library. > > I’ve uploaded libktorrent 22.08.3-3 with the new ABI to experimental and > it builds successfully on the same architectures as previously. [0] Please go ahead. Cheers -- Sebastian Ramacher
Bug#1023535: transition: protobuf
On 11/24/22 21:03, Sebastian Ramacher wrote: protobuf's autopkgtests are failing. Could you please take a look at them? Thanks Patch available in: https://bugs.debian.org/1024677 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023550: transition: qcustomplot
On 2022-11-24 21:05:07 +0100, Sebastian Ramacher wrote: > Hi Filippo > > On 2022-11-22 21:41:15 +0100, Filippo Rusconi wrote: > > Greetings Sebastian, > > > > On Sat, Nov 19, 2022 at 08:17:41PM +0100, Sebastian Ramacher wrote: > > > Hi Filippo > > > > > > On 2022-11-11 10:56:08 +0100, Filippo Rusconi wrote: > > > > Greetings Sebastian, > > > > > > > > Thank your for your message. > > > > > > > > On Thu, Nov 10, 2022 at 11:04:54PM +0100, Sebastian Ramacher wrote: > > > > > Control: tags -1 moreinfo > > > > > Control: forwarded -1 > > > > > https://release.debian.org/transitions/html/auto-qcustomplot.html > > > > > > > > > > Hi Filippo > > > > > > > > > > On 2022-11-06 15:29:32 +0100, Filippo Rusconi wrote: > > > > > > Package: release.debian.org > > > > > > Severity: normal > > > > > > User: release.debian@packages.debian.org > > > > > > Usertags: transition > > > > > > X-Debbugs-Cc: lopi...@debian.org, gl...@debian.org, > > > > > > debian-science-maintain...@lists.alioth.debian.org > > > > > > > > > > > > (please explain about the transition: impacted packages, reason, ... > > > > > > for more info see: > > > > > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions) > > > > > > > > > > > > Greetings, > > > > > > > > > > > > Fundamental reason: Qt5 and Qt6 are in the archive. > > > > > > > > > > > > I am requesting a transition from package libqcustomplot2.0 to > > > > > > libqcustomplot2.1. Source package is qcustomplot. The change > > > > > > involves a change > > > > > > in the library name itself, from libqcustomplot2.0 to both > > > > > > libQCustomPlot2.1 and > > > > > > libQCustomPlotQt6.so.2.1.0 (see below). > > > > > > > > > > > > I have prepared the packaging in the following git repos branch: > > > > > > > > > > > > https://salsa.debian.org/science-team/qcustomplot/-/tree/qt5-and-qt6 > > > > > > > > [...] > > > > > > > > > > For the libs under my control, the transition is already prepared > > > > > > and these > > > > > > projects are going to be linking against the Qt6-built library, > > > > > > contrary to all > > > > > > the other packages detailed below. > > > > > > > > > > > > For the other libs listed above, I have already checked that they > > > > > > would build if > > > > > > some modifications were performed. I have already git branches > > > > > > ready for the > > > > > > packages under git VCS. For the others (source deb), I have patches > > > > > > available. > > > > > > > > > > > > The modifications are lean: change -lqcustomplot to -lQCustomPlot > > > > > > for many and > > > > > > also sometimes use the CMake-based configuration involving first > > > > > > find_package(QCustomPlot) and second the QCustomPlot::QCustomPlot > > > > > > formalism for > > > > > > the linker. > > > > > > > > > > > > That is: almost one- or two-liner patches. > > > > > > > > > > Could you please file bugs for those so that maintainers are aware? > > > > > > > > Yes, I'll do that. I have already informed them individually of the > > > > process and > > > > provided them with the relevant patch. > > > > > > Thanks! Please go ahead with the transition. > > > > I just uploaded the package to unstable. I have not closed the bug yet, > > waiting > > to check that everything goes fine. > > qcustomplot's autopkgtests are failing. Could you please take a look at > them? Thanks And from https://buildd.debian.org/status/fetch.php?pkg=libpappsomspp=amd64=0.8.60-1%2Bb1=1669195336=0 it looks like libqcustomplot-dev is missing a dependency on qtbase5-dev. Cheers -- Sebastian Ramacher
Bug#1023550: transition: qcustomplot
Hi Filippo On 2022-11-22 21:41:15 +0100, Filippo Rusconi wrote: > Greetings Sebastian, > > On Sat, Nov 19, 2022 at 08:17:41PM +0100, Sebastian Ramacher wrote: > > Hi Filippo > > > > On 2022-11-11 10:56:08 +0100, Filippo Rusconi wrote: > > > Greetings Sebastian, > > > > > > Thank your for your message. > > > > > > On Thu, Nov 10, 2022 at 11:04:54PM +0100, Sebastian Ramacher wrote: > > > > Control: tags -1 moreinfo > > > > Control: forwarded -1 > > > > https://release.debian.org/transitions/html/auto-qcustomplot.html > > > > > > > > Hi Filippo > > > > > > > > On 2022-11-06 15:29:32 +0100, Filippo Rusconi wrote: > > > > > Package: release.debian.org > > > > > Severity: normal > > > > > User: release.debian@packages.debian.org > > > > > Usertags: transition > > > > > X-Debbugs-Cc: lopi...@debian.org, gl...@debian.org, > > > > > debian-science-maintain...@lists.alioth.debian.org > > > > > > > > > > (please explain about the transition: impacted packages, reason, ... > > > > > for more info see: > > > > > https://wiki.debian.org/Teams/ReleaseTeam/Transitions) > > > > > > > > > > Greetings, > > > > > > > > > > Fundamental reason: Qt5 and Qt6 are in the archive. > > > > > > > > > > I am requesting a transition from package libqcustomplot2.0 to > > > > > libqcustomplot2.1. Source package is qcustomplot. The change involves > > > > > a change > > > > > in the library name itself, from libqcustomplot2.0 to both > > > > > libQCustomPlot2.1 and > > > > > libQCustomPlotQt6.so.2.1.0 (see below). > > > > > > > > > > I have prepared the packaging in the following git repos branch: > > > > > > > > > > https://salsa.debian.org/science-team/qcustomplot/-/tree/qt5-and-qt6 > > > > > > [...] > > > > > > > > For the libs under my control, the transition is already prepared and > > > > > these > > > > > projects are going to be linking against the Qt6-built library, > > > > > contrary to all > > > > > the other packages detailed below. > > > > > > > > > > For the other libs listed above, I have already checked that they > > > > > would build if > > > > > some modifications were performed. I have already git branches ready > > > > > for the > > > > > packages under git VCS. For the others (source deb), I have patches > > > > > available. > > > > > > > > > > The modifications are lean: change -lqcustomplot to -lQCustomPlot for > > > > > many and > > > > > also sometimes use the CMake-based configuration involving first > > > > > find_package(QCustomPlot) and second the QCustomPlot::QCustomPlot > > > > > formalism for > > > > > the linker. > > > > > > > > > > That is: almost one- or two-liner patches. > > > > > > > > Could you please file bugs for those so that maintainers are aware? > > > > > > Yes, I'll do that. I have already informed them individually of the > > > process and > > > provided them with the relevant patch. > > > > Thanks! Please go ahead with the transition. > > I just uploaded the package to unstable. I have not closed the bug yet, > waiting > to check that everything goes fine. qcustomplot's autopkgtests are failing. Could you please take a look at them? Thanks Cheers -- Sebastian Ramacher
Bug#1023535: transition: protobuf
Hi László On 2022-11-21 20:42:41 +0100, Sebastian Ramacher wrote: > Control: tags -1 = confirmed > > On 2022-11-10 23:10:29 +0100, Sebastian Ramacher wrote: > > Control: block -1 by 1022248 1018945 > > > > On 2022-11-06 09:08:57 +0100, László Böszörményi wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > > > > Hi RMs, > > > > > > There's a long awaited transition of Protobuf. It clashes with the > > > ruby3.1-default transition, but as I know its rebuilds are just > > > starting[1]. > > > On the other hand I'm done with the rebuilds and patched all issues, > > > this transition may start immediately at your decision. The only > > > downside is that the Sid version of cura-engine is FTBFS and to fix > > > it, the libarcus transition (only affecting this package) will need to > > > be done. > > > > > > Failing packages and fixes in detail. > > > Level 2: > > > android-platform-frameworks-base has my patch already applied [2] for > > > experimental (not Sid!). > > > libarcus builds in Sid, but not the version in experimental for which > > > I provided a fix [3]. > > > target-factory changed library symbols [4], maintainer will need to > > > update that. > > > > > > Level 3: > > > cura-engine fails with the Sid version [5], with the libarcus > > > transition done it compiles fine. > > > grpc-java for which I provided the fix [6], the maintainer noted he > > > will be ready to update the package. > > > llvm-toolchain-13 for which I provided the fix [7], other problems > > > seem to be fixed with the upload just happened. > > > llvm-toolchain-14 for which I also provided the fix [8], its other > > > problem [9] might be wrongly closed by cross referenced > > > llvm-toolchain-15 package - but Sylvestre Ledru seems to be aware of > > > issues anyway. > > > > Let's wait until icu and libbpf are done. > > Please go ahead protobuf's autopkgtests are failing. Could you please take a look at them? Thanks Cheers -- Sebastian Ramacher
Bug#1021838: bullseye-pu: package binfmt-support/2.2.1-1+deb11u1
On Wed, Nov 23, 2022 at 08:43:37PM +, Adam D. Barratt wrote: > On Sat, 2022-10-15 at 18:11 +0100, Colin Watson wrote: > > https://bugs.debian.org/1012154 reported a startup issue due to a > > race > > between systemd-binfmt.service and binfmt-support.service (which has > > probably been around for a long time). > > https://bugs.debian.org/1021822 > > mentions that it would be helpful to have the fix for this in stable > > as > > well, which I agree with. > > Please go ahead. Thanks, uploaded. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Help understanding why a package isn't migrating
On Thu, 24 Nov 2022, Sebastian Ramacher wrote: Hi Scott On 2022-11-23 19:38:26 +0100, Paul Gevers wrote: Hi Scott, On 23-11-2022 15:26, Scott Talbert wrote: Hi Release Team, I'm trying to understand why this package (haskell-copilot-theorem[1]) isn't migrating to testing. It looks like it is saying that it is being blocked by haskell-what4, but haskell-what4 has already migrated to testing on October 17. Also, if I look at excuses for haskell-what4, there aren't any. The only thing I can possibly think is that it is referring to migration of binNMU's, but I can't see any way to see the status of those. Is it possible? Thanks, Scott [1] https://qa.debian.org/excuses.php?package=haskell-copilot-theorem It says: haskell-copilot-theorem haskell-parameterized-utils/ppc64el (not considered) Which means that haskell-copilot-theorem on ppc64el depends on src:haskell-parameterized-utils. Picking one of the binaries from that source and asking rmadison says: paul@mulciber ~ $ rmadison libghc-parameterized-utils-dev libghc-parameterized-utils-dev | 2.1.5.0-2+b1 | testing| amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libghc-parameterized-utils-dev | 2.1.5.0-2+b2 | unstable | mips64el, mipsel, ppc64el libghc-parameterized-utils-dev | 2.1.5.0-2+b3 | unstable | armhf, i386, s390x libghc-parameterized-utils-dev | 2.1.5.0-2+b4 | unstable | amd64, arm64, armel So indeed, the binNMU's of that source are out-of-sync between testing and unstable. Searching in the excuses [2] I see this: Depends: haskell-parameterized-utils/amd64 haskell-th-abstraction So that points at haskell-th-abstraction (which seems in a similar situation but then with haskell-clash-prelude) And if you go down the rabbit hole far enough, you'll eventually reach #1023149 which needs to be taken care of. Yes, that's the same conclusion I came to. Thanks! Scott
Bug#1024726: marked as done (nmu: evolution-data-server_3.46.1-1+b1)
Your message dated Thu, 24 Nov 2022 14:03:32 +0100 with message-id and subject line Re: Bug#1024726: nmu: evolution-data-server_3.46.1-1+b1 has caused the Debian Bug report #1024726, regarding nmu: evolution-data-server_3.46.1-1+b1 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.) -- 1024726: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024726 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: high Please schedule this rebuild to fix evolution-data-server compatibility with libphonenumber which was rebuilt for the ongoing protobuf transition. This rebuild wasn't on the auto tracker which suggests that there is a bigger dependency issue somewhere. I don't know if other packages are also affected. See https://bugs.debian.org/1024674 Here's my guess at the syntax: nmu evolution-data-server_3.46.1-1+b1 . ANY . unstable . -m "libphonenumber8 (>= 8.12.57+ds-1+b2)" Thanks, Jeremy Bicha --- End Message --- --- Begin Message --- On 2022-11-24 12:27:18 +0100, Jochen Sprickerhof wrote: > * Jeremy Bicha [2022-11-23 16:33]: > > Please schedule this rebuild to fix evolution-data-server > > compatibility with libphonenumber which was rebuilt for the ongoing > > protobuf transition. This rebuild wasn't on the auto tracker which > > suggests that there is a bigger dependency issue somewhere. I don't > > know if other packages are also affected. See > > https://bugs.debian.org/1024674 > > The problem is/was that libphonenumber8 exposes the protobuf ABI. I've just > uploaded a -2 to declare this dependency through a > libphonenumber8-protobuf32 virtual package, similar how it is done in > ignition-msgs. Thanks. Note though that libphonenumber FTBFS almost everywhere. > I've just did a test build and evolution-data-server picks up the new > dependency now. so I think the request should be: > > dw evolution-data-server_3.46.1-1+b1 . ANY . unstable . -m "libphonenumber8 > (>= 8.12.57+ds-2)" Scheduled with the dw. Cheers -- Sebastian Ramacher--- End Message ---
NEW changes in stable-new
Processing changes file: postgresql-13_13.9-0+deb11u1_mipsel-buildd.changes ACCEPT
Bug#1024726: nmu: evolution-data-server_3.46.1-1+b1
* Jeremy Bicha [2022-11-23 16:33]: Please schedule this rebuild to fix evolution-data-server compatibility with libphonenumber which was rebuilt for the ongoing protobuf transition. This rebuild wasn't on the auto tracker which suggests that there is a bigger dependency issue somewhere. I don't know if other packages are also affected. See https://bugs.debian.org/1024674 The problem is/was that libphonenumber8 exposes the protobuf ABI. I've just uploaded a -2 to declare this dependency through a libphonenumber8-protobuf32 virtual package, similar how it is done in ignition-msgs. I've just did a test build and evolution-data-server picks up the new dependency now. so I think the request should be: dw evolution-data-server_3.46.1-1+b1 . ANY . unstable . -m "libphonenumber8 (>= 8.12.57+ds-2)" Cheers Jochen signature.asc Description: PGP signature
Bug#1024756: transition: libktorrent
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: Debian Qt/KDE Maintainers Dear Release Team, I’d like to request a transition slot for libktorrent. It has 2 reverse dependencies: - kget - ktorrent Both rebuild successfully with the new version of the library. I’ve uploaded libktorrent 22.08.3-3 with the new ABI to experimental and it builds successfully on the same architectures as previously. [0] Ben file: title = "libktorrent"; is_affected = .depends ~ "libkf5torrent6abi2" | .depends ~ "libkf5torrent6abi3"; is_good = .depends ~ "libkf5torrent6abi3"; is_bad = .depends ~ "libkf5torrent6abi2"; [0] https://buildd.debian.org/status/package.php?p=libktorrent=experimental Thanks, -- Aurélien
Bug#1023731: BioC Transition blocked by new dependencies
Am Thu, Nov 24, 2022 at 08:46:31AM +0100 schrieb Sebastian Ramacher: > > >r-bioc-bitseq - should be removed from testing immediately bug just > > > filed) Bug #1024661 > > >r-bioc-multiassayexperiment #1024748 > > >r-bioc-demixt (bug #1024597 was just filed) > > >r-bioc-scater #1024751 > > >r-bioc-mofa (just due dependencies) Bug filed as well even if redundant since removal of r-bioc-multiassayexperiment should also remove this. > > > Do you want me to file RC bugs against r-bioc-multiassayexperiment, > > > r-bioc-scater and r-bioc-mofa. > > > > Since r-bioc-scater is needed in autopkgtest of r-bioc-bluster[1] and > > r-bioc-singler[2] probably also these two packages need a RC bug to not > > block the transition. Bugs will be filed against r-bioc-bluster and r-bioc-singler once my 'only 5 reports per hour for submission' period is over (I'm frequently wondering whether this is a bit harsh constraint - I'm beaten by it two to four times per year by it) > > The test suite issue of r-bioc-structuralvariantannotation is discussed > > with upstream[4]. I'm fine to remove it from testing for the moment as > > well. > > > > Just let me know whether I should file the according bugs. > > Please do. Done (or about to do) - transition bug in CC. Thanks a lot for your patience Andreas. -- http://fam-tille.de
Bug#1024739: marked as done (nmu: libmcfp_1.2.2-1)
Your message dated Thu, 24 Nov 2022 10:01:46 +0100 with message-id and subject line Re: Bug#1024739: nmu: libmcfp_1.2.2-1 has caused the Debian Bug report #1024739, regarding nmu: libmcfp_1.2.2-1 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.) -- 1024739: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024739 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: binnmu Hello, I want to request binNMU on amd64 for recently accepted new package. nmu libmcfp_1.2.2-1 . amd64 . unstable . -m "Rebuild on buildd" Thanks, Andrius --- End Message --- --- Begin Message --- Hi, On 24-11-2022 07:52, Andrius Merkys wrote: I want to request binNMU on amd64 for recently accepted new package. nmu libmcfp_1.2.2-1 . amd64 . unstable . -m "Rebuild on buildd" A newer version was uploaded. Closing. Paul OpenPGP_signature Description: OpenPGP digital signature --- End Message ---
Bug#1024745: bullseye-pu: package node-xmldom/0.5.0-1+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
node-xmldom is vulnerable: it doesn't verify that root element is uniq
(#1024736, CVE-2022-39353)
[ Impact ]
Medium vulnerability
[ Tests ]
Test still pass
[ Risks ]
Moderate risk: test still pass and patch isn't too big
[ 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 (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
Verify XML document before change it
Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index e486812..50d0288 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-xmldom (0.5.0-1+deb11u2) bullseye; urgency=medium
+
+ * Team upload
+ * Prevent inserting DOM nodes when they are not well-formed
+(Closes: #1024736, CVE-2022-39353)
+
+ -- Yadd Thu, 24 Nov 2022 09:22:10 +0100
+
node-xmldom (0.5.0-1+deb11u1) bullseye; urgency=medium
* Team upload
diff --git a/debian/patches/CVE-2022-39353.patch
b/debian/patches/CVE-2022-39353.patch
new file mode 100644
index 000..b15040a
--- /dev/null
+++ b/debian/patches/CVE-2022-39353.patch
@@ -0,0 +1,270 @@
+Description: Prevent inserting DOM nodes when they are not well-formed
+Author: Christian Bewernitz
+Origin: upstream, https://github.com/xmldom/xmldom/commit/7ff7c10a
+Bug: https://github.com/xmldom/xmldom/security/advisories/GHSA-crh6-fp67-6883
+Bug-Debian: https://bugs.debian.org/1024736
+Forwarded: not-needed
+Reviewed-By: Yadd
+Last-Update: 2022-11-24
+
+--- a/lib/dom.js
b/lib/dom.js
+@@ -111,7 +111,31 @@
+ serializeToString(this[i],buf,isHTML,nodeFilter);
+ }
+ return buf.join('');
+- }
++ },
++ /**
++ * @private
++ * @param {function (Node):boolean} predicate
++ * @returns {Node | undefined}
++ */
++ find: function (predicate) {
++ return Array.prototype.find.call(this, predicate);
++ },
++ /**
++ * @private
++ * @param {function (Node):boolean} predicate
++ * @returns {Node[]}
++ */
++ filter: function (predicate) {
++ return Array.prototype.filter.call(this, predicate);
++ },
++ /**
++ * @private
++ * @param {Node} item
++ * @returns {number}
++ */
++ indexOf: function (item) {
++ return Array.prototype.indexOf.call(this, item);
++ },
+ };
+ function LiveNodeList(node,refresh){
+ this._node = node;
+@@ -182,7 +206,7 @@
+ }
+ }
+ }else{
+- throw DOMException(NOT_FOUND_ERR,new Error(el.tagName+'@'+attr))
++ throw new DOMException(NOT_FOUND_ERR,new
Error(el.tagName+'@'+attr))
+ }
+ }
+ NamedNodeMap.prototype = {
+@@ -496,48 +520,177 @@
+ _onUpdateChild(parentNode.ownerDocument,parentNode);
+ return child;
+ }
++
+ /**
+- * preformance key(refChild == null)
++ * Returns `true` if `node` can be a parent for insertion.
++ * @param {Node} node
++ * @returns {boolean}
+ */
+-function _insertBefore(parentNode,newChild,nextChild){
+- var cp = newChild.parentNode;
++function hasValidParentNodeType(node) {
++ return (
++ node &&
++ (node.nodeType === Node.DOCUMENT_NODE || node.nodeType ===
Node.DOCUMENT_FRAGMENT_NODE || node.nodeType === Node.ELEMENT_NODE)
++ );
++}
++
++/**
++ * Returns `true` if `node` can be inserted according to it's `nodeType`.
++ * @param {Node} node
++ * @returns {boolean}
++ */
++function hasInsertableNodeType(node) {
++ return (
++ node &&
++ (isElementNode(node) ||
++ isTextNode(node) ||
++ isDocTypeNode(node) ||
++ node.nodeType === Node.DOCUMENT_FRAGMENT_NODE ||
++ node.nodeType === Node.COMMENT_NODE ||
++ node.nodeType === Node.PROCESSING_INSTRUCTION_NODE)
++ );
++}
++
++/**
++ * Returns true if `node` is a DOCTYPE node
++ * @param {Node} node
++ * @returns {boolean}
++ */
++function isDocTypeNode(node) {
++ return node && node.nodeType === Node.DOCUMENT_TYPE_NODE;
++}
++
++/**
++ * Returns true if the node is an element
++ * @param {Node} node
++ * @returns {boolean}
++ */
++function isElementNode(node) {
++ return node && node.nodeType === Node.ELEMENT_NODE;
++}
++/**
++ * Returns true if `node` is a text node
++ * @param {Node} node
++ * @returns {boolean}
++ */
++function isTextNode(node) {
++ return node && node.nodeType === Node.TEXT_NODE;
++}
++
++/**
++ * Check if en element node can be inserted before `child`, or at the end if
child is falsy,
++ * according to the presence and position of a doctype node on the same level.
++ *
++ * @param {Document} doc The document node
++ * @param {Node} child the
