Bug#1023731: BioC Transition blocked by new dependencies
On 2022-11-24 07:52:37 +0100, Andreas Tille wrote: > Am Tue, Nov 22, 2022 at 08:54:13PM +0100 schrieb Andreas Tille: > > If I understood that BioConductor packages should not block other > > transitions. I've just pinged ftpmaster on IRC to check packages > > r-bioc-bsseq, r-bioc-dss, r-bioc-biocbaseutils and r-cran-ggrastr. > > The following packages are blocked by the packages in new: > > > >r-bioc-bitseq - should be removed from testing immediately bug just > > filed) > >r-bioc-multiassayexperiment > >r-bioc-demixt (bug #1024597 was just filed) > >r-bioc-scater > >r-bioc-mofa (just due dependencies) > > > > 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. > > 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. Cheers -- Sebastian Ramacher
Re: Help understanding why a package isn't migrating
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 href="#haskell-th-abstraction">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. Cheers -- Sebastian Ramacher
Bug#1024726: nmu: evolution-data-server_3.46.1-1+b1
This seems related: https://bugs.debian.org/1024701 Regards signature.asc Description: This is a digitally signed message part
Bug#1023731: BioC Transition blocked by new dependencies
Am Tue, Nov 22, 2022 at 08:54:13PM +0100 schrieb Andreas Tille: > If I understood that BioConductor packages should not block other > transitions. I've just pinged ftpmaster on IRC to check packages > r-bioc-bsseq, r-bioc-dss, r-bioc-biocbaseutils and r-cran-ggrastr. > The following packages are blocked by the packages in new: > >r-bioc-bitseq - should be removed from testing immediately bug just filed) >r-bioc-multiassayexperiment >r-bioc-demixt (bug #1024597 was just filed) >r-bioc-scater >r-bioc-mofa (just due dependencies) > > 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. 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. Kind regards Andreas. [1] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-bluster/28612583/log.gz [2] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-singler/28612594/log.gz [3] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-bioc-structuralvariantannotation/28615556/log.gz [4] https://lists.debian.org/debian-r/2022/11/msg00067.html -- http://fam-tille.de
Bug#1024739: nmu: libmcfp_1.2.2-1
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
NEW changes in stable-new
Processing changes file: postgresql-13_13.9-0+deb11u1_armel-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: postgresql-13_13.9-0+deb11u1_armhf-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: postgresql-13_13.9-0+deb11u1_arm64-buildd.changes ACCEPT Processing changes file: postgresql-13_13.9-0+deb11u1_mips64el-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: postgresql-13_13.9-0+deb11u1_amd64-buildd.changes ACCEPT Processing changes file: postgresql-13_13.9-0+deb11u1_i386-buildd.changes ACCEPT Processing changes file: postgresql-13_13.9-0+deb11u1_ppc64el-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: postgresql-13_13.9-0+deb11u1_s390x-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: postgresql-13_13.9-0+deb11u1_all-buildd.changes ACCEPT
Bug#1021645: bullseye-pu: package postfix/3.5.13-0+deb11u1
On Wednesday, November 23, 2022 3:42:08 PM EST Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Wed, 2022-10-12 at 00:05 -0400, Scott Kitterman wrote: > > This is another in my occasional series of postfix updates to > > keep up with upstream maintenance updates to the version in > > stable (v3.5). Upstream is still judicious and reasonable in > > their approach to fixing things. The maintenance updates are > > generally suitable for Debian stable updates. > > Please go ahead. Uploaded. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1024726: Bug#1024674: libphonenumber8: breaks Evolution
On Wed, Nov 23, 2022 at 5:15 PM László Böszörményi (GCS) wrote: > On Wed, Nov 23, 2022 at 6:52 AM tony mancill wrote: > > This issue goes away for me after a rebuild of src:evolution-data-server > > and installing the freshly rebuilt libebook-contacts-1.2-4. > > > > Maybe we can kick off a rebuild via the transition. If not that, would > > you be willing to do a sourceful upload Jeremy? > Just for the record, he asked for a evolution-data-server binNMU [1] > for this issue. No sourceful upload will be needed. Will the evolution-data-server binNMU be held in Unstable until libphonenumber and protobuf migrate to Testing? I don't want to have Testing broken because of this issue either. Thank you, Jeremy Bicha
Bug#1024054: bullseye-pu: package mariadb-10.5 10.5.18-0+deb11u1
On Sun, 2022-11-13 at 22:10 -0800, Otto Kekäläinen wrote: > I propose that the latest version of MariaDB 10.5.18 would be > included > in the upcoming stable release update of Debian. Package almost ready > at > https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commits/bullseye > > Before I submit the final debdiff and changelog I will wait for the > release date to show up at https://release.debian.org/ > That now happened, fwiw. Regards, Adam
Bug#1023423: bullseye-pu: package pysubnettree/0.33-1
On Wednesday, November 23, 2022 3:55:01 PM EST Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Thu, 2022-11-03 at 16:32 -0400, Scott Kitterman wrote: > > Package is totally broken in Bullseye (see #1005044) and this fixes > > it. > > Please go ahead. > > Regards, > > Adam Uploaded. Scott K signature.asc Description: This is a digitally signed message part.
NEW changes in stable-new
Processing changes file: grub-efi-amd64-signed_1+2.06+3~deb11u4_amd64-buildd.changes ACCEPT Processing changes file: grub-efi-arm64-signed_1+2.06+3~deb11u4_arm64-buildd.changes ACCEPT Processing changes file: grub-efi-ia32-signed_1+2.06+3~deb11u4_i386-buildd.changes ACCEPT
Bug#1024726: nmu: evolution-data-server_3.46.1-1+b1
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
NEW changes in stable-new
Processing changes file: heimdal_7.7.0+dfsg-2+deb11u1_sourceonly.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u1_all-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u1_amd64-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u1_arm64-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u1_armel-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u1_armhf-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u1_i386-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u1_mips64el-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u1_mipsel-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u1_ppc64el-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u1_s390x-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u2_sourceonly.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u2_all-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u2_amd64-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u2_arm64-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u2_armel-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u2_armhf-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u2_i386-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u2_mips64el-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u2_mipsel-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u2_ppc64el-buildd.changes ACCEPT Processing changes file: heimdal_7.7.0+dfsg-2+deb11u2_s390x-buildd.changes ACCEPT Processing changes file: postgresql-13_13.9-0+deb11u1_source.changes ACCEPT
Bug#1024343: insighttoolkit4: releasability with bookworm?
Control: tags -1 - moreinfo Hi Sebastian, Sorry, I might have triggered the upload a couple of minutes too early. Anyway, thanks for reaching out! Sebastian Ramacher, on 2022-11-23: > On 2022-11-17 21:44:22 +0100, Étienne Mollier wrote: > > However, there are still several reverse dependencies which have > > not made the jump to itk-5.y yet, and are currently out of > > testing due to depending on packages which are not part of the > > testing distribution anymore. Also, I noticed in the RC bug[1] > > affecting it that there has been quite some effort from > > different parties to try to help bringing it back to testing, > > but to no avail. Finally, I had been hoping to keep the library > > in a somewhat working condition for downstream users to be able > > to migrate somewhat smoothly from itk-4.y to itk-5.y in > > bookworm; the latter was not made available in bullseye alas. > > Which of the reverse dependencies do you want to see in bookworm? From > the two of the three I looked at, they have their own RC bugs and look > mostly unmaintained. ants, for example, has a RC bug open from 2017. I've been mostly concerned by the third one, otb[1], which seems still under active maintenance even though it is held by missing ITK4 dependencies. [1]: https://tracker.debian.org/pkg/otb itksnap 4.0.0 is due to support vtk9 and itk5, but looks still under beta release, so didn't make it to the packaging step yet. Looking at reverse build dependencies, facet-analyser looks to have made the move to itk5 recently and shouldn't be in trouble. Things otherwise moved on since last time I checked. Maybe I worry too much. Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Camel - Rainbow's End signature.asc Description: PGP signature
Processed: Re: Bug#1024343: insighttoolkit4: releasability with bookworm?
Processing control commands: > tags -1 - moreinfo Bug #1024343 [release.debian.org] insighttoolkit4: releasability with bookworm? Removed tag(s) moreinfo. -- 1024343: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024343 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
NEW changes in stable-new
Processing changes file: grub-efi-amd64-signed_1+2.06+3~deb11u4_source.changes ACCEPT Processing changes file: grub-efi-amd64-signed_1+2.06+3~deb11u4_amd64-buildd.changes REJECT Processing changes file: grub-efi-arm64-signed_1+2.06+3~deb11u4_source.changes ACCEPT Processing changes file: grub-efi-arm64-signed_1+2.06+3~deb11u4_arm64-buildd.changes REJECT Processing changes file: grub-efi-ia32-signed_1+2.06+3~deb11u4_source.changes ACCEPT Processing changes file: grub-efi-ia32-signed_1+2.06+3~deb11u4_i386-buildd.changes REJECT Processing changes file: grub2_2.06-3~deb11u4_source.changes ACCEPT Processing changes file: grub2_2.06-3~deb11u4_amd64-buildd.changes ACCEPT Processing changes file: grub2_2.06-3~deb11u4_arm64-buildd.changes ACCEPT Processing changes file: grub2_2.06-3~deb11u4_armel-buildd.changes ACCEPT Processing changes file: grub2_2.06-3~deb11u4_armhf-buildd.changes ACCEPT Processing changes file: grub2_2.06-3~deb11u4_i386-buildd.changes ACCEPT Processing changes file: grub2_2.06-3~deb11u4_mips64el-buildd.changes ACCEPT Processing changes file: grub2_2.06-3~deb11u4_mipsel-buildd.changes ACCEPT Processing changes file: grub2_2.06-3~deb11u4_ppc64el-buildd.changes ACCEPT Processing changes file: grub2_2.06-3~deb11u4_s390x-buildd.changes ACCEPT
Processed: Re: Bug#1024385: bullseye-pu: package openvpn-auth-radius/2.1-7+deb11u1
Processing control commands: > tags -1 + confirmed Bug #1024385 [release.debian.org] bullseye-pu: package openvpn-auth-radius/2.1-7+deb11u1 Added tag(s) confirmed. -- 1024385: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024385 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1024385: bullseye-pu: package openvpn-auth-radius/2.1-7+deb11u1
Control: tags -1 + confirmed On Sat, 2022-11-19 at 01:21 +0800, Shengjing Zhu wrote: > Fix #954264: Support for verify-client-cert openvpn 2.4 directive. > > [ Impact ] > The current version doesn't work with openvpn version (2.5.1) in > stable. > The old workaround only works for openvpn 2.4. > Please go ahead. Regards, Adam
Bug#1023981: bullseye-pu: package onionshare/2.2-3+deb11u1
Control: tags -1 + confirmed On Sun, 2022-11-13 at 14:57 +0100, Clément Hermann wrote: > Following discussion with Security Team about vulnerabilities in > onionshare (see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014966 ), I > prepared a > patched version which backport upstream fixes for CVE-2022-21689 and > CVE-2022-21690. > Please go ahead. Regards, Adam
Processed: Re: Bug#1023981: bullseye-pu: package onionshare/2.2-3+deb11u1
Processing control commands: > tags -1 + confirmed Bug #1023981 [release.debian.org] bullseye-pu: package onionshare/2.2-3+deb11u1 Added tag(s) confirmed. -- 1023981: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023981 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1023798: Update to fix also CVE-2022-37599
Processing control commands: > tags -1 + confirmed Bug #1023798 [release.debian.org] bullseye-pu: package node-loader-utils/2.0.0-1+deb11u1 Added tag(s) confirmed. -- 1023798: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023798 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1023798: Update to fix also CVE-2022-37599
Control: tags -1 + confirmed On Mon, 2022-11-14 at 11:05 +0100, Yadd wrote: > On 14/11/2022 11:01, Yadd wrote: > > Hi, > > > > here is another update to fix CVE-2022-37599 (trivial patch). > > > > Cheers, > > Yadd > > This fix also CVE-2022-37603 (duplicate of CVE-2022-37599) Please go ahead. Regards, Adam
Bug#1018888: marked as done (nmu: elastix_5.0.1-3+b1)
Your message dated Wed, 23 Nov 2022 21:57:36 +0100 with message-id and subject line Re: Bug#101: nmu: elastix_5.0.1-3+b1 has caused the Debian Bug report #101, regarding nmu: elastix_5.0.1-3+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.) -- 101: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=101 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 nmu elastix_5.0.1-3+b1 . ANY . unstable . -m "Rebuild against updated insighttoolkit5" --- End Message --- --- Begin Message --- On 2022-09-01 23:33:39 +0200, Sebastian Ramacher wrote: > Control: tags -1 moreinfo > > On 2022-09-01 08:37:55 -0500, Steve M. Robbins wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: binnmu > > > > nmu elastix_5.0.1-3+b1 . ANY . unstable . -m "Rebuild against updated > > insighttoolkit5" > > Why is this rebuild needed? Let's close this for now. Please reopen if that is still needed. Cheers -- Sebastian Ramacher--- End Message ---
Processed: Re: Bug#1023602: bullseye-pu: package xfig/1:3.2.8-3
Processing control commands: > tags -1 + confirmed Bug #1023602 [release.debian.org] bullseye-pu: package xfig/1:3.2.8-3 Added tag(s) confirmed. -- 1023602: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023602 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1023602: bullseye-pu: package xfig/1:3.2.8-3
Control: tags -1 + confirmed On Mon, 2022-11-07 at 14:16 +0100, Roland Rosenfeld wrote: > This fixes CVE-2021-40241 (a potential buffer overflow in reading an > environment variable). > Please go ahead. Regards, Adam
Processed: Re: Bug#1023423: bullseye-pu: package pysubnettree/0.33-1
Processing control commands: > tags -1 + confirmed Bug #1023423 [release.debian.org] bullseye-pu: package pysubnettree/0.33-1 Added tag(s) confirmed. -- 1023423: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023423 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1023423: bullseye-pu: package pysubnettree/0.33-1
Control: tags -1 + confirmed On Thu, 2022-11-03 at 16:32 -0400, Scott Kitterman wrote: > Package is totally broken in Bullseye (see #1005044) and this fixes > it. > Please go ahead. Regards, Adam
Processed: Re: Bug#1023263: bullseye-pu: package clickhouse/18.16.1+ds-4+deb10u1
Processing control commands: > tags -1 + confirmed Bug #1023263 [release.debian.org] bullseye-pu: package clickhouse/18.16.1+ds-4+deb10u1 Added tag(s) confirmed. -- 1023263: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023263 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1023263: bullseye-pu: package clickhouse/18.16.1+ds-4+deb10u1
Control: tags -1 + confirmed On Tue, 2022-11-01 at 12:24 +0100, Tobias Frost wrote: > I'm currently preparing a security update for clickhouse for LTS. > As the versions are quite similar, I've also prepared an update for > bullseye, > even if the issues are marked "minor". > > The CVE's are: > CVE-2021-42387, CVE-2021-42388, CVE-2021-43304, CVE-2021-43305 > (Details on them are in #1008216) > Please go ahead. Regards, Adam
Bug#1024343: insighttoolkit4: releasability with bookworm?
Control: tags -1 moreinfo On 2022-11-17 21:44:22 +0100, Étienne Mollier wrote: > Package: release.debian.org > Severity: important > X-Debbugs-Cc: debian-...@lists.debian.org > > Dear Release Team, > > I would like to seek advice whether build-depending on gcc-11 > for insighttoolkit4 would be an acceptable tradeoff to maintain > this library in the upcoming bookworm? Even, whether trying to > bring it to bookworm would be acceptable at all? > > The library is not maintained anymore for quite some time, in > favor of it's up-to-date version insighttoolkit5. I also > suspect maintainability of the old version will be a problem > from a security point of view: for instance some un-vendored > libraries went back in the source package after breakages in the > test suite caused by updates in the system libraries. > > However, there are still several reverse dependencies which have > not made the jump to itk-5.y yet, and are currently out of > testing due to depending on packages which are not part of the > testing distribution anymore. Also, I noticed in the RC bug[1] > affecting it that there has been quite some effort from > different parties to try to help bringing it back to testing, > but to no avail. Finally, I had been hoping to keep the library > in a somewhat working condition for downstream users to be able > to migrate somewhat smoothly from itk-4.y to itk-5.y in > bookworm; the latter was not made available in bullseye alas. Which of the reverse dependencies do you want to see in bookworm? From the two of the three I looked at, they have their own RC bugs and look mostly unmaintained. ants, for example, has a RC bug open from 2017. Cheers > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012950 > > Thank you for your effort in coordinating the construction of > Debian releases! > > Have a nice day, :) > -- > .''`. Étienne Mollier > : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da > `. `' sent from /dev/tty1, please excuse my verbosity >`-on air: Symphony X - Charon -- Sebastian Ramacher
Processed: Re: Bug#1024343: insighttoolkit4: releasability with bookworm?
Processing control commands: > tags -1 moreinfo Bug #1024343 [release.debian.org] insighttoolkit4: releasability with bookworm? Added tag(s) moreinfo. -- 1024343: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024343 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1023261: bullseye-pu: package libtasn1-6/4.16.0-2+deb11u1
Processing control commands: > tags -1 + confirmed Bug #1023261 [release.debian.org] bullseye-pu: package libtasn1-6/4.16.0-2+deb11u1 Added tag(s) confirmed. -- 1023261: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023261 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1023261: bullseye-pu: package libtasn1-6/4.16.0-2+deb11u1
Control: tags -1 + confirmed On Tue, 2022-11-01 at 12:11 +0100, Andreas Metzler wrote: > I would like to fix CVE-2021-46848 in bullseye. This was fixed in > sid/testing by new upstream 4.19.0. I already had some correspondence > with debian-security, no DSA is planned. > Please go ahead. Regards, Adam
Processed: Re: Bug#1023105: bullseye-pu: package tinyxml/2.6.2-4+deb11u1
Processing control commands: > tags -1 + confirmed Bug #1023105 [release.debian.org] bullseye-pu: package tinyxml/2.6.2-4+deb11u1 Added tag(s) confirmed. -- 1023105: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023105 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1023105: bullseye-pu: package tinyxml/2.6.2-4+deb11u1
Control: tags -1 + confirmed On Sun, 2022-10-30 at 10:31 +0100, Felix Geyer wrote: > Fixing the no-dsa tagged CVE-2021-42260 > > [ Impact ] > DoS vulnerability > Please go ahead. Regards, Adam
Processed: Re: Bug#1022122: bullseye-pu: package node-minimatch/3.0.4+~3.0.3-1+deb11u1
Processing control commands: > tags -1 + confirmed Bug #1022122 [release.debian.org] bullseye-pu: package node-minimatch/3.0.4+~3.0.3-1+deb11u1 Added tag(s) confirmed. -- 1022122: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022122 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1022122: bullseye-pu: package node-minimatch/3.0.4+~3.0.3-1+deb11u1
Control: tags -1 + confirmed On Thu, 2022-10-20 at 17:22 +0200, Yadd wrote: > node-minimatch is vulnerable to ReDoS > Please go ahead. Regards, Adam
Processed: Re: Bug#1021963: bullseye-pu: package dcfldd/1.7-3+deb11u1
Processing control commands: > tags -1 + confirmed Bug #1021963 [release.debian.org] bullseye-pu: package dcfldd/1.7-3+deb11u1 Added tag(s) confirmed. -- 1021963: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021963 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1021963: bullseye-pu: package dcfldd/1.7-3+deb11u1
Control: tags -1 + confirmed On Mon, 2022-10-17 at 21:35 -0300, Joao Eriberto Mota Filho wrote: > This is not a regression, but a discovered bug. > > dcfldd is an enhanced dd command that is able to calculate the > following hashes > when copying data: MD5, SHA1 and SHA2. > > The SHA1 was being wrongly calculated on big endian architectures. > Please go ahead. Regards, Adam
Processed: Re: Bug#1021838: bullseye-pu: package binfmt-support/2.2.1-1+deb11u1
Processing control commands: > tags -1 + confirmed Bug #1021838 [release.debian.org] bullseye-pu: package binfmt-support/2.2.1-1+deb11u1 Added tag(s) confirmed. -- 1021838: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021838 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1021838: bullseye-pu: package binfmt-support/2.2.1-1+deb11u1
Control: tags -1 + confirmed 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. > > [ Impact ] > binfmt-support.service will sometimes fail to start, so binary format > specifications registered with it may or may not do anything > depending on luck at boot time. > Please go ahead. Regards, Adam
Processed: Re: Bug#1021645: bullseye-pu: package postfix/3.5.13-0+deb11u1
Processing control commands: > tags -1 + confirmed Bug #1021645 [release.debian.org] bullseye-pu: package postfix/3.5.13-0+deb11u1 Added tag(s) confirmed. -- 1021645: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021645 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1021645: bullseye-pu: package postfix/3.5.13-0+deb11u1
Control: tags -1 + confirmed On Wed, 2022-10-12 at 00:05 -0400, Scott Kitterman wrote: > This is another in my occasional series of postfix updates to > keep up with upstream maintenance updates to the version in > stable (v3.5). Upstream is still judicious and reasonable in > their approach to fixing things. The maintenance updates are > generally suitable for Debian stable updates. > Please go ahead. Regards, Adam
Upcoming stable point release (11.6)
Hi, The next point release for "bullseye" (11.6) is scheduled for Saturday, December 17th. Processing of new uploads into bullseye-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Processed: Re: Bug#1024322: transition: dpdk
Processing control commands: > tags -1 moreinfo Bug #1024322 [release.debian.org] transition: dpdk Added tag(s) moreinfo. -- 1024322: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024322 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1024322: transition: dpdk
Control: tags -1 moreinfo On 2022-11-17 14:27:25 +, Luca Boccassi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org z...@debian.org > > Hello Thomas and Release Team, > > As we did for Bullseye, we are proposing the following plan to allow > Bookworm to ship with the latest LTS versions of DPDK and OVS. This > will let us make use of the full LTS support windows for both projects, > as we have done for the past few releases. > > Upload OVS built from git (with new sonames/package renames if > necessary), new OVN, DPDK 22.11 in early-to-mid December to unstable, > ideally before the 16th as we go on vacation after that, to finish the > transition. > > Then, after OVS 3.1 releases in February, upload it unstable (no > soname/transition required, as only bug fixes will go in at that > point). The upstream release might happen before or after the > 2023/02/12 soft freeze, and if it is after we will ask for an > exception. > > Would this plan work for everyone? Sounds like that should work like last time. Please remove the moreinfo tag once dpdk is ready for the upload to unstable. Cheers > > Bullseye tickets for reference: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974588 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974667 > > -- > Kind regards, > Luca Boccassi -- Sebastian Ramacher
Bug#1023846: transition: gdal
On 11/23/22 19:22, Paul Gevers wrote:
On 23-11-2022 05:28, Sebastiaan Couwenberg wrote:
The libgdal-grass autopkgtest in testing is failing because it
requires gdal, grass, and libgdal-grass from unstable.
https://qa.debian.org/excuses.php?package=gdal
This combination needs to be tested to fix the regressions shown and
unblock testing migration of gdal and the related rebuilt packages.
I'll schedule the set, but I have the feeling that a proper versioned
relation (maybe an upper limit??) is missing somewhere. As there are
quite a few versioned binaries involved already, it's obvious that
there's a design. But if there's a runtime check for a version, ideally
that should be expressed in dependencies too. Unless I'm missing
something of course. (If that dependency would be there, britney would
ask apt to pin packages from the source providing it from unstable if
they are not fulfilled in testing).
"""
ERROR: Module built against version 2022-11-20T19:27:33+00:00 but trying
to use version 2022-10-25T05:34:10+00:00. You need to rebuild GRASS GIS
or untangle multiple installations.
"""
This is not reflected in the dependencies, only the ABI dependency
provided by grass-core is set:
grass820
The dependency is set with a dh_gencontrol override.
This version check in grass is much stricter than it should be, the
builds from the upstream git repo use the commit hash of include
directory to check whether the code using grass is still compatible.
Because this requirement to rebuild libgdal-grass everytime grass is
rebuilt annoyed me, I dug into this issue and had it changed upstream to
use the full GRASS version (e.g. 8.2.0) like the virtual ABI dependency
provided by grass-core for tarball builds.
GRASS 8.2.1 will contain this change, with their release process slower
than expected, it's not sure whether it will be released before the
bookworm freeze.
For future gdal transitions pulling in only the new gdal from unstable
may suffice, although grass from testing still using the old gdal may
cause different problems than just this version check. Like the crssync
segfaults tend that happen with qgis when its dependencies are linked to
different libproj versions.
"""
ERROR 1: OGR/GRASS driver was compiled against GDAL 3.5, but the current
library version is 3.6
ERROR 1: GDAL/GRASS driver was compiled against GDAL 3.5, but the
current library version is 3.6
"""
This is reflected in the libgdal-grass (1:1.0.2-2) dependencies:
libgdal32 (>= 3.6.0)
Those are the normal ${shlibs:Depends} set via symbols files.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: Help understanding why a package isn't migrating
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 href="#haskell-th-abstraction">haskell-th-abstraction So that points at haskell-th-abstraction (which seems in a similar situation but then with haskell-clash-prelude) Paul [2] "source: haskell-parameterized-utils" in https://release.debian.org/britney/excuses.yaml OpenPGP_signature Description: OpenPGP digital signature
Bug#1023846: transition: gdal
Hi Bas, On 23-11-2022 05:28, Sebastiaan Couwenberg wrote: The libgdal-grass autopkgtest in testing is failing because it requires gdal, grass, and libgdal-grass from unstable. https://qa.debian.org/excuses.php?package=gdal This combination needs to be tested to fix the regressions shown and unblock testing migration of gdal and the related rebuilt packages. I'll schedule the set, but I have the feeling that a proper versioned relation (maybe an upper limit??) is missing somewhere. As there are quite a few versioned binaries involved already, it's obvious that there's a design. But if there's a runtime check for a version, ideally that should be expressed in dependencies too. Unless I'm missing something of course. (If that dependency would be there, britney would ask apt to pin packages from the source providing it from unstable if they are not fulfilled in testing). """ ERROR: Module built against version 2022-11-20T19:27:33+00:00 but trying to use version 2022-10-25T05:34:10+00:00. You need to rebuild GRASS GIS or untangle multiple installations. """ """ ERROR 1: OGR/GRASS driver was compiled against GDAL 3.5, but the current library version is 3.6 ERROR 1: GDAL/GRASS driver was compiled against GDAL 3.5, but the current library version is 3.6 """ Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1023495: transition: ruby3.1
Hi Antonio On 2022-11-23 13:13:37 -0300, Antonio Terceiro wrote: > On Tue, Nov 22, 2022 at 11:00:57PM +0100, Sebastian Ramacher wrote: > > On 2022-11-22 21:53:31 +0100, Paul Gevers wrote: > > > Hi Lucas, > > > > > > On 22-11-2022 17:03, Lucas Kanashiro wrote: > > > > After discussing with Antonio, since our deadline to finish the > > > > transition is approaching, we decided to already enable ruby3.1 as the > > > > default and remove ruby3.0 in a single step. > > > > > > I may be remembering wrong (it's a bit late), but isn't the change of the > > > default a forward rebuild, while removal is a backward rebuild (I mean in > > > the dependency tree)? If that's true, I think doing it in two steps is > > > easier to manage, as packages can then migrate on their own and don't > > > need a > > > lock step migration. > > > > That's correct. I'd prefer to handle this with two trackers. > > Fair enough. I will update ruby-defaults accordingly. Is it OK for us to > start the transition in unstable? I'd like protobuf to migrate first which is currently doing its own transition. Afer that, we can go ahead with the switch to 3.1 as default. Cheers -- Sebastian Ramacher
Bug#1023495: transition: ruby3.1
On Tue, Nov 22, 2022 at 11:00:57PM +0100, Sebastian Ramacher wrote: > On 2022-11-22 21:53:31 +0100, Paul Gevers wrote: > > Hi Lucas, > > > > On 22-11-2022 17:03, Lucas Kanashiro wrote: > > > After discussing with Antonio, since our deadline to finish the > > > transition is approaching, we decided to already enable ruby3.1 as the > > > default and remove ruby3.0 in a single step. > > > > I may be remembering wrong (it's a bit late), but isn't the change of the > > default a forward rebuild, while removal is a backward rebuild (I mean in > > the dependency tree)? If that's true, I think doing it in two steps is > > easier to manage, as packages can then migrate on their own and don't need a > > lock step migration. > > That's correct. I'd prefer to handle this with two trackers. Fair enough. I will update ruby-defaults accordingly. Is it OK for us to start the transition in unstable? signature.asc Description: PGP signature
Help understanding why a package isn't migrating
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
Re: nageru 2.2.0-1 cannot transition due to ppc64el
Hi Steinar, On 2022-11-23 09:27:32 +0100, Steinar H. Gunderson wrote: > On Wed, Nov 23, 2022 at 09:25:04AM +0100, Steinar H. Gunderson wrote: > > I don't understand why it considers ppc64el to be important. 2.1.0-2 does > > not > > have a build for ppc64el, and ppc64el is not in the architecture list of the > > source package. (There is a ppc64el build in stable, for 2.0.1-3.) Do I need > > some sort of manual nudging here? > > Nevermind, it seems it was still stuck in the architecture list of one of the > subpackages further down! After fixing the architecture list of the package, it will also need to be removed by FTP masters from unstable. Please file a bug against ftp.debian.org to get futatabi's ppc64el binary removed. Cheers -- Sebastian Ramacher
Bug#1023419: marked as done (transition: freeglut)
Your message dated Wed, 23 Nov 2022 09:52:36 +0100 with message-id and subject line Re: Bug#1023419: transition: freeglut has caused the Debian Bug report #1023419, regarding transition: freeglut 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.) -- 1023419: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023419 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: transition New version of freeglut library and binary renaming. Reverse depends were rebuilt against new lib. Ben file: title = "freeglut"; is_affected = .depends ~ "freeglut3|freeglut3-dev" | .depends ~ "libglut-dev|libglut3.12"; is_good = .depends ~ "libglut-dev|libglut3.12"; is_bad = .depends ~ "freeglut3|freeglut3-dev"; Thanks Anton --- End Message --- --- Begin Message --- On 2022-11-05 22:22:13 +0100, Anton Gladky wrote: > Uploaded, thanks! The old binaries got removed from testing. Closing Cheers -- Sebastian Ramacher--- End Message ---
Re: nageru 2.2.0-1 cannot transition due to ppc64el
On Wed, Nov 23, 2022 at 09:25:04AM +0100, Steinar H. Gunderson wrote: > I don't understand why it considers ppc64el to be important. 2.1.0-2 does not > have a build for ppc64el, and ppc64el is not in the architecture list of the > source package. (There is a ppc64el build in stable, for 2.0.1-3.) Do I need > some sort of manual nudging here? Nevermind, it seems it was still stuck in the architecture list of one of the subpackages further down! /* Steinar */ -- Homepage: https://www.sesse.net/
nageru 2.2.0-1 cannot transition due to ppc64el
Hi, I'm trying to figure out why nageru 2.2.0-1 is not in testing (the package is flagged for autoremoval due to a library transition; 2.2.0 no longer uses the library in question): nageru (2.1.0-2 to 2.2.0-1) Maintainer: Steinar H. Gunderson Depends: nageru protobuf Migration status for nageru (2.1.0-2 to 2.2.0-1): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: ∙ ∙ nageru unsatisfiable Build-Depends(-Arch) on ppc64el: libluajit-5.1-dev ∙ ∙ missing build on ppc64el ∙ ∙ Waiting for piuparts test results (stalls migration) - https://piuparts.debian.org/sid/source/n/nageru.html ∙ ∙ arch:ppc64el not built yet, autopkgtest delayed there ∙ ∙ Depends: nageru protobuf Additional info: ∙ ∙ Updating nageru will fix bugs in testing: #1024105 ∙ ∙ 8 days old (needed 5 days) I don't understand why it considers ppc64el to be important. 2.1.0-2 does not have a build for ppc64el, and ppc64el is not in the architecture list of the source package. (There is a ppc64el build in stable, for 2.0.1-3.) Do I need some sort of manual nudging here? /* Steinar */ -- Homepage: https://www.sesse.net/
Processed: Re: Bug#1024675: transition: openturns
Processing control commands: > tags -1 confirmed Bug #1024675 [release.debian.org] transition: openturns Added tag(s) confirmed. -- 1024675: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024675 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1024675: transition: openturns
Control: tags -1 confirmed On 2022-11-23 06:02:59 +0100, Pierre Gruet wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear Release Team, > > I would like to do the transition of openturns due to ABI changes. The new > version is in experimental and builds on all relevant architectures. There is > one rdep, persalys, which also builds well. > > The autogenerated ben file is fine. > > So I am ready to proceed when you tell me. Please go ahead. Cheers -- Sebastian Ramacher
