Bug#1061188: transition: python3-defaults (making python3.12 the default python3 version)
On 15.05.24 11:14, Emilio Pozuelo Monfort wrote: Hi Matthias, On 20/01/2024 15:41, Matthias Klose wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Please setup a tracker for the python3-defaults transition, making 3.12 the default Python version. What's the current status? Has a mass-build been done with python3-defaults from experimental? a mass rebuild doesn't help, because you only get valid results for the first level of the dependencies. I think that question has been answered many times. The transition has been done for Ubuntu 24.04 LTS, so there should be some confidence that packages are in a good shape for 3.12. The archive had been frozen for transitions for some time, but the thawing wasn't announced, and I only about that last week. I won't drive that transition before mid June myself, but if people would like to start earlier, please coordinate with Stefano. Matthias
Bug#1065309: transition: gnat (12 -> 13 + time_t64)
Package: release.debian.org X-Debbugs-CC: Nicolas Boulenguez when preparing GCC packages for time_t64, I noticed that we'll have an ABI change for libgnat as well. Instead of doing a gnat 12 -> 12+t64 transition, let's do a gnat 12 -> 13+t64 transition instead. According to Nicolas, packages are already prepared in experimental. Waiting with the transition until all t64 stuff is finished doesn't work well, packages which need binNMUs will ftbfs.
Bug#1061188: transition: python3-defaults (making python3.12 the default python3 version)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Please setup a tracker for the python3-defaults transition, making 3.12 the default Python version.
Bug#1055085: waiting for 3.12.1
wait until 3.12.1 is in the archive. 3.12.0+ isn't well handled as a version by some third party libraries.
Bug#1055085: (some kind of) transition: add python3.12 as a supported python3 version
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: debian-pyt...@lists.debian.org Please setup a tracker to add python3.12 as a supported python3 version. This is non-blocking, as packages can migrate on their own once built. I'm not yet starting this, just want to have an overview of affected packages. Please re-use the final version of the python3.11 tracker. https://release.debian.org/transitions/html/python3.11-add.html The upstream release in on time again, so we should be prepared to start this addition after the upstream release end of October.
Bug#1038820: transition: glibc 2.37
uploaded On 01.07.23 16:55, Aurelien Jarno wrote: Hi Matthias, On 2023-07-01 14:16, Aurelien Jarno wrote: On 2023-07-01 10:14, Sebastian Ramacher wrote: Control: forwarded -1 https://release.debian.org/transitions/html/glibc-2.37.html Control: tags -1 confirmed On 2023-06-21 20:53:54 +0200, Aurelien Jarno wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-gl...@lists.debian.org Control: affects -1 + src:glibc Dear release team, I would like to get a transition slot for glibc 2.37. It has been available in experimental for a bit more than a month and does not have any known issue. It has been built successfully on all release architectures and many ports architectures (technically 2.37-2 hasn't been built yet on mipsel and mips64el due to the buildds lagging, but 2.37-1 has been built successfully). Please go ahead. Thanks, I have just uploaded it. The arch:all build finished and got uploaded, so the glibc-source package is now available in the archive. Matthias, could you please upload cross-toolchain-base and cross-toolchain-base-ports using glibc 2.37? Thanks, Aurelien
Bug#1032928: unblock: python3.11/3.11.2-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock python3.11 for bookworm. Changes include: - one code change to fix a regression compared to 3.11.1 #1032019 - making the python3-dbg-config script usable again. - Emit a proper error when users try to use venv without having it installed. - Documentation and lintian cleanups. python3.11 (3.11.2-6) unstable; urgency=high [ Stefano Rivera ] * Explain more ways to pass --break-system-packages to pip. [ Matthias Klose ] * Fix syntax error in python3-dbg-config script. LP: #2009967. -- Matthias Klose Mon, 13 Mar 2023 13:18:29 +0100 python3.11 (3.11.2-5) unstable; urgency=medium [ Matthias Klose ] * Update VCS attributes. * Fix error message for 'python3 -m venv dir`, when python3-venv is not installed. Closes: #1026268. [ Stefano Rivera ] * Mention that deleting EXTERNALLY-MANAGED is an option, in README.venv. * Patch: fix deadlock at shutdown when clearing thread states. Closes: #1032019. * Override expat embedded-library lintian false-positives. (See: #1031859) -- Matthias Klose Sun, 05 Mar 2023 09:28:49 +0100 diff -Nru python3.11-3.11.2/debian/changelog python3.11-3.11.2/debian/changelog --- python3.11-3.11.2/debian/changelog 2023-02-12 01:48:52.0 +0100 +++ python3.11-3.11.2/debian/changelog 2023-03-13 13:18:29.0 +0100 @@ -1,3 +1,28 @@ +python3.11 (3.11.2-6) unstable; urgency=high + + [ Stefano Rivera ] + * Explain more ways to pass --break-system-packages to pip. + + [ Matthias Klose ] + * Fix syntax error in python3-dbg-config script. LP: #2009967. + + -- Matthias Klose Mon, 13 Mar 2023 13:18:29 +0100 + +python3.11 (3.11.2-5) unstable; urgency=medium + + [ Matthias Klose ] + * Update VCS attributes. + * Fix error message for 'python3 -m venv dir`, when python3-venv +is not installed. Closes: #1026268. + + [ Stefano Rivera ] + * Mention that deleting EXTERNALLY-MANAGED is an option, in README.venv. + * Patch: fix deadlock at shutdown when clearing thread states. +Closes: #1032019. + * Override expat embedded-library lintian false-positives. (See: #1031859) + + -- Matthias Klose Sun, 05 Mar 2023 09:28:49 +0100 + python3.11 (3.11.2-4) unstable; urgency=medium [ Stefano Rivera ] diff -Nru python3.11-3.11.2/debian/control python3.11-3.11.2/debian/control --- python3.11-3.11.2/debian/control2023-02-12 01:48:02.0 +0100 +++ python3.11-3.11.2/debian/control2023-02-15 06:29:54.0 +0100 @@ -20,8 +20,8 @@ valgrind-if-available, Build-Depends-Indep: python3-sphinx, python3-docs-theme, texinfo Standards-Version: 4.6.2 -Vcs-Browser: https://salsa.debian.org/cpython-team/python3 -Vcs-Git: https://salsa.debian.org/cpython-team/python3.git +Vcs-Browser: https://salsa.debian.org/cpython-team/python3/tree/python3.11 +Vcs-Git: https://salsa.debian.org/cpython-team/python3.git -b python3.11 XS-Testsuite: autopkgtest Package: python3.11 diff -Nru python3.11-3.11.2/debian/control.in python3.11-3.11.2/debian/control.in --- python3.11-3.11.2/debian/control.in 2023-02-12 01:47:59.0 +0100 +++ python3.11-3.11.2/debian/control.in 2023-02-15 05:16:46.0 +0100 @@ -20,8 +20,8 @@ valgrind-if-available, Build-Depends-Indep: python3-sphinx, python3-docs-theme, texinfo Standards-Version: 4.6.2 -Vcs-Browser: https://salsa.debian.org/cpython-team/python3 -Vcs-Git: https://salsa.debian.org/cpython-team/python3.git +Vcs-Browser: https://salsa.debian.org/cpython-team/python3/tree/python3.11 +Vcs-Git: https://salsa.debian.org/cpython-team/python3.git -b python3.11 XS-Testsuite: autopkgtest Package: @PVER@ diff -Nru python3.11-3.11.2/debian/libPVER-dbg.overrides.in python3.11-3.11.2/debian/libPVER-dbg.overrides.in --- python3.11-3.11.2/debian/libPVER-dbg.overrides.in 2019-02-06 13:02:26.0 +0100 +++ python3.11-3.11.2/debian/libPVER-dbg.overrides.in 2023-03-05 09:27:09.0 +0100 @@ -15,3 +15,6 @@ # yes, some extensions don't have references to any external lib lib@PVER@-dbg binary: shared-lib-without-dependency-information lib@PVER@-dbg binary: library-not-linked-against-libc + +# pyexpat.c contains expat error messages that lintian mis-attributes to embedding +lib@PVER@-dbg binary: embedded-library diff -Nru python3.11-3.11.2/debian/libPVER.overrides.in python3.11-3.11.2/debian/libPVER.overrides.in --- python3.11-3.11.2/debian/libPVER.overrides.in 2013-11-23 13:09:48.0 +0100 +++ python3.11-3.11.2/debian/libPVER.overrides.in 2023-03-05 09:27:20.0 +0100 @@ -1 +1,4 @@ lib@PVER@ binary: package-name-doesnt-match-sonames + +# pyexpat.c contains expat error messages that lintian mis-attributes to embedding +lib@PVER@ binary: embedded-library diff -Nru python3.11-3.11.2/debian/patches/ensurepip-disabled.diff python3.11-3.11.2/debian/patches/ensurepip-disabled.diff --- python3.11-3.11.2/debian/patches/ensurepip
Re: Python 3.11 for bookworm?
while we have not an 100% agreement to go ahead, I think we should aim for 3.11. The following steps would be: - accept the current python3-defaults into testing (adding 3.11 as supported) - ask for a transition slot to upload (see #1026825) python3-defaults with 3.11 as the default - start the no-change NMUs - file bug reports. - fix issues - let 3.11 as default migrate to testing. If things don't go as planned, we could default back to 3.10. Mostly that would be no-change uploads, however in the case of a 3.11 specific fix that doesn't work for 3.10, these fixes would need reverting. I have no idea who many of these we will introduce with this transition. Also we might want to ask for some freeze exceptions for third party libraries, that we can't fix before the feature freeze, unfortunately at this point we cannot say which and how many packages would be affected. Matthias
Bug#1026825: python3.11 as default
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: debian-pyt...@lists.debian.org Please setup a transition window for python 3.11 as the default python3 version. A tracker is setup at https://release.debian.org/transitions/html/python3.11-default.html Thanks to many Debian and Ubuntu developers, this transition is now finished for Ubuntu, and outstanding bug reports should be filed as https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.11;users=debian-pyt...@lists.debian.org
Bug#1021984: (some kind of) transition: add python3.11 as a supported python3 version
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Please setup a tracker to add python3.11 as a supported python3 version. This is non-blocking, as packages can migrate on their own once built. I'm not yet starting this, just want to have an overview of affected packages. Please re-use the final version of the python3.9 tracker (#996584). The upstream release in on time again, so we should be prepared to start this addition after the upstream release end of October.
Bug#1007905: transition: icu
On 18.03.22 17:38, László Böszörményi (GCS) wrote: Hi all, On Fri, Mar 18, 2022 at 1:42 PM Sebastian Ramacher wrote: On 2022-03-18 13:06:13, Jérémy Lal wrote: FYI same here, i had to fallback to nodejs 14 instead of 16 because of that. Last time I asked, icu maintainer had issues fixing icu reverse build-dependencies. He probably needs help ? Have those bugs already been filed? Otherwise, filing bugs for the reverse dependencies that FTBFS would be a good first step. I didn't file those bugs, but started patching those and filed only when succeeded. At this point I remember only two packages that FTBFS with ICU 70.1 and I couldn't fix those. One is mozjs78 and the other is 0ad. I had trouble with PostgreSQL, but that has a new major upstream release uploaded since then, meaning it needs to be re-tested. My box has an issue at the moment and I need to finish converting my 4 Tb big (badly chosen) BTRFS filesystem to ext4 over an USB link. It's not that fast and may still need an hour or two. Going to restart the rebuilds after this and report all issues I find. I had been in contact with Laszlo earlier, and then did that transition in Ubuntu. Yes, icu 7x support needs some updates in rdep packages with new upstream versions, but that was possible. Matthias
Bug#1007222: transition: onetbb
On 13.03.22 21:59, M. Zhou wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi release team, This involves an upstream source name change (from tbb to onetbb), as well as SOVERSION bump (from 2 to 12), along with a major API change including some changes in the core API. I should have submitted this after my local build test for the reverse dependencies of libtbb-dev, but fellow developers from debian-science are eager to see this in unstable to unblock their works. I have not tested by myself, but I heard from an archlinux developer that this API bump breaks a lot packages. And some upstreams decided to disable or drop tbb support as a result. I guess we can take similar measures for short term workaround. "I heard from archlinux" is not good enough. I sent you email about this without getting a reply, then filed #1006920, without getting a reply, now this incomplete proposal. you may want to look at all the build rdeps for libtbb2-dev in Ubuntu to get an overview what at least breaks: $ reverse-depends -b libtbb2-dev Reverse-Testsuite-Triggers * intel-mkl Reverse-Build-Depends * casparcg-server * flexbar * gazebo * opencascade * opensubdiv * r-cran-rcppparallel (plus implicit dependencies) Ben file: title = "tbb"; is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12"; is_good = .depends ~ "libtbb12"; is_bad = .depends ~ "libtbb2"; this breaks everything immediately because of the conflicting libtbb2 and libtbb12. Please fix this first. Matthias
Bug#1006836: transition: python3.10 as default
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: debian-pyt...@lists.debian.org Please setup a transition window for python 3.10 as the default python3 version. A tracker is setup at https://release.debian.org/transitions/html/python3.10-default.html Thanks to many Debian and Ubuntu developers, this transition is now finished for Ubuntu, and outstanding bug reports should be filed as https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.10;users=debian-pyt...@lists.debian.org We had to remove at least numba from testing/release, as it requires updated dependencies as well, which are not yet in unstable.
Re: Bug#975016: #975016 - OpenJDK 17 support state for Bullseye
On 2/10/22 11:26, Moritz Mühlenhoff wrote: > Am Thu, Feb 03, 2022 at 03:59:00PM +0100 schrieb Thorsten Glaser: >> Hi Holger, >> >>> and filed against src:debian-security-support, as openjdk-17 seems to be >>> supported and src:debian-security-support's purpose is to documented what's >> >> no, 11 is supported, 17 is just for users to run third-party >> stuff on (IIUC). > > In Bullseye 11 is the default Java and fully covered by security support. > > 17 can be installed (and it can also take over the typical alternatives), > but nothing pulls it in via dependencies. But if anyone needs to run an > application requiring 17, this is the JRE of choice (those are rare at > this point, but it will change over the life time of Bullseye). > > And yes there have been security updates for 17 already, but it's a best > effort > thing. If someone commits to rebuild the openjdk-17 uploads to unstable > for bullseye-security (along with proper testing), we can also omit a note > for src:debian-security-support. "along with proper testing" means, that we can turn on again the tests during the build, which requires a heap of new upstream versions for jtreg, jtharness, testng, groovy, and probably much more. Matthias
Bug#996584: (some kind of) transition: add python3.10 as a supported python3 version
On 11/18/21 06:51, Sebastiaan Couwenberg wrote: > On 11/16/21 14:23, Matthias Klose wrote: >> I'm planning to upload python3-defaults later tonight, adding 3.10 as a >> supported Python version. Packages are able to migrate on their own, there >> are >> no blockages introduced on other transitions. > > numpy rdeps (e.g. pyproj) are a bit problematic, they fail with the 3.10 as > long > as numpy is not built with it yet. numpy is in stage6 of the transition. so please be a bit patient until all the binNMUs up to stage6 are built.
Bug#996584: (some kind of) transition: add python3.10 as a supported python3 version
I'm planning to upload python3-defaults later tonight, adding 3.10 as a supported Python version. Packages are able to migrate on their own, there are no blockages introduced on other transitions. We have most packages ready to build for 3.10, and around 70 leaf packages still needing some work. Otoh, we can much better work on these if reverse dependencies are already built for 3.10 in the archive. The tracker used is https://release.debian.org/transitions/html/python3.10-add.html As some kind of reference, the current state of the 3.10 addition in Ubuntu can be seen at https://people.canonical.com/~ubuntu-archive/transitions/html/python3.10-add.html Matthias
Bug#996584: (some kind of) transition: add python3.10 as a supported python3 version
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Please setup a tracker to add python3.10 as a supported python3 version. This is non-blocking, as packages can migrate on their own once built. I'm not yet starting this, just want to have an overview of affected packages. Please re-use the final version of the python3.9 tracker (#966426).
Bug#996094: transition: libgphobos
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition please binNMU packages for the (non-blocking) libgphobos transition, triggered by the GCC defaults change (dub and cheesecutter are ftbfs, bug reports are already filed): Reverse Depends: Depends: val-and-rick (>= 10.1) Depends: tumiki-fighters (>= 10.1) Depends: torus-trooper (>= 10.1) Depends: titanion (>= 10.1) Depends: tatan (>= 10.1) Depends: projectl (>= 10.1) Depends: parsec47 (>= 10.1) Depends: mu-cade (>= 10.1) Depends: ii-esu (>= 10.1) Depends: gunroar (>= 10.1) Depends: a7xpg (>= 10.1) Depends: dustmite (>= 10.1) Depends: dub (>= 10.1) Depends: cheesecutter (>= 10.1)
Bug#994560: transition: libffi
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Update libffi to version 3.4.2. The transition was done for Ubuntu, a handful of bugs regarding build failures (mostly due to GCC 11) are filed in Debian. I would like to get this done before the ghc version in unstable changes, due to the rather large number of ghc related no-change uploads.
Bug#991846: unblock: openjdk-17/17~33ea-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: secur...@debian.org Please unblock openjdk-17, the next openjdk-17 snapshot build, also including security fixes from the last openjdk-11 security release. That could be done as a security update as well, the unblock would just avoid that extra work. The only packaging change is to mark the early-access status in the Debian package versions. Not attaching a debdiff compared to the version in testing, it's huge. openjdk-17 (17~33ea-1) unstable; urgency=high * OpenJDK 17 snapshot, build 33. * Regenerate the control file. -- Matthias Klose Fri, 30 Jul 2021 14:48:42 +0200 openjdk-17 (17~32ea-1) unstable; urgency=high * OpenJDK 17 snapshot, build 32. * Security fixes: - JDK-8256157: Improve bytecode assembly. - JDK-8256491: Better HTTP transport. - JDK-8258432, CVE-2021-2341: Improve file transfers. - JDK-8260453: Improve Font Bounding. - JDK-8260960: Signs of jarsigner signing. - JDK-8260967, CVE-2021-2369: Better jar file validation. - JDK-8262380: Enhance XML processing passes. - JDK-8262403: Enhanced data transfer. - JDK-8262410: Enhanced rules for zones. - JDK-8262477: Enhance String Conclusions. - JDK-8262967: Improve Zip file support. - JDK-8264066, CVE-2021-2388: Enhance compiler validation. - JDK-8264079: Improve abstractions. - JDK-8264460: Improve NTLM support. -- Matthias Klose Mon, 26 Jul 2021 11:25:32 +0200 openjdk-17 (17~31ea-1) unstable; urgency=medium * OpenJDK 17 snapshot, build 31. * Encode the early-access status into the package version. LP: #1934895. -- Matthias Klose Sat, 17 Jul 2021 14:25:02 +0200 openjdk-17 (17~29-1) unstable; urgency=medium * OpenJDK 17 snapshot, build 29. * Update watch file. * Prepare to build with jtreg6, where available. -- Matthias Klose Thu, 01 Jul 2021 16:42:23 +0200 openjdk-17 (17~27-1) unstable; urgency=medium * OpenJDK 17 snapshot, build 27. * Only build using lto with GCC 11. * Build using GCC 11 in recent distributions. * Update VCS attributes. * Disable runnning the tests, requires not yet packaged jtreg6. * Remove rimd, removed upstream. -- Matthias Klose Fri, 18 Jun 2021 15:06:18 +0200 openjdk-17 (17~24-1) unstable; urgency=medium * OpenJDK 17 snapshot, build 24. * Drop the work around for JDK 8211105. * Remove jaotc (the experimental JIT compiler), removed upstream. * Add an (unapplied) patch to replace OASIS header files with ones imported from NSPR and NSS. See #985765. Not reviewed, not applying. -- Matthias Klose Thu, 27 May 2021 11:26:59 +0200
Bug#991703: unblock: openjdk-11/11.0.12+7-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-CC: secur...@debian.org Please unblock openjdk-11, the next openjdk-11 security release. That could be done as a security update as well, the unblock would just avoid that extra work. The only packaging change is to mark the early-access version in the Debian package versions, which is a no-op for the final release build. The debdiff is a bit large, I put it at https://people.debian.org/~doko/tmp/openjdk.debdiff.xz openjdk-11 (11.0.12+7-2) unstable; urgency=high * OpenJDK 11.0.12+7 build (release). * Security fixes: - JDK-8256157: Improve bytecode assembly. - JDK-8256491: Better HTTP transport. - JDK-8258432, CVE-2021-2341: Improve file transfers. - JDK-8260453: Improve Font Bounding. - JDK-8260960: Signs of jarsigner signing. - JDK-8260967, CVE-2021-2369: Better jar file validation. - JDK-8262380: Enhance XML processing passes. - JDK-8262403: Enhanced data transfer. - JDK-8262410: Enhanced rules for zones. - JDK-8262477: Enhance String Conclusions. - JDK-8262967: Improve Zip file support. - JDK-8264066, CVE-2021-2388: Enhance compiler validation. - JDK-8264079: Improve abstractions. - JDK-8264460: Improve NTLM support. * Encode the early-access status into the package version. LP: #1934895. -- Matthias Klose Wed, 21 Jul 2021 09:03:54 +0200 openjdk-11 (11.0.12+6-1) unstable; urgency=medium * OpenJDK 11.0.12+6 build (early access). -- Matthias Klose Wed, 07 Jul 2021 12:00:44 +0200 openjdk-11 (11.0.12+4-1) unstable; urgency=medium * OpenJDK 11.0.12+4 build (early access). * Don't apply the m68k-support patch, needs an update. -- Matthias Klose Thu, 27 May 2021 11:37:31 +0200
Bug#991200: unblock: python2.7/2.7.18-8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: Andreas Beckmann Please unblock python2.7/2.7.18-8, just adding some breaks for smoother upgrades as requested in #990520. No code changes. The debdiff is in the bug report.
Re: Bug#987013: Release goal proposal: Remove Berkeley DB
On 5/5/21 8:51 PM, Niko Tyni wrote: > On Fri, Apr 16, 2021 at 08:29:52PM +0200, Bastian Blank wrote: >> On Fri, Apr 16, 2021 at 05:04:03PM +0200, Marco d'Itri wrote: > >>> And then all the packages currently depending on libdb5.3 will need to >>> implement, or at least document, a transition strategy. >> >> My first goal would be to drop it from base packages, so not every >> system out there needs to have it installed. > > Hi, please note that there's a number of indirect users of libdb via > interpreter packages - at least Perl, presumably Python too. > > Given perl gets installed on almost all systems, this seems to to be > on the path to the first goal. > > For the perl core, the libdb5.3 bindings are exposed with the DB_File > module. I think this is the only place but have not cross-checked that. > (The libberkeleydb-perl package is an entirely separate matter AIUI.) > > I see 110 source packages in Debian matching DB_File. The list will > need to be inspected manually to weed out false positives. The remaining > packages need to be changed before perl can drop its libdb5.3 dependency. > I suppose this will also need a long list of Breaks declarations on the > perl side. > > Then there's user code too. I also think we'll need at least a dumper > utility so that users can migrate their data manually when they discover > their program no longer works after upgrading. For Python, the dbm/ndbm.py module, based on the _dbm extension is also affected. You can build the _dbm extension using libgdbm-compat-dev, however that changes the on-disk format, and the license used (likely the new one should be moved into the python3-gdbm package). Matthias
Bug#987836: unblock: openjdk-11/11.0.11+9-1 and openjdk-17/17~19-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock the openjdk-11 and openjdk-17 packages. For openjdk-11, it's the quaterly security release, and for openjdk-17 it's the next snapshot made after including the security fixes made for the openjdk-11 release. openjdk-11 (11.0.11+9-1) unstable; urgency=high * OpenJDK 11.0.11+9 build (release). * Security fixes: - JDK-8244473: Contextualize registration for JNDI. - JDK-8244543: Enhanced handling of abstract classes. - JDK-8259633: compiler/graalunit/CoreTest.java fails with NPE after JDK-8244543. - JDK-8250568: Less ambiguous processing (CVE-2021-2161). - JDK-8253799: Make lists of normal filenames. - JDK-8261183: Follow on to Make lists of normal filenames. - JDK-8249906: Enhance opening JARs (CVE-2021-2163). - JDK-8258247: Couple of issues in fix for JDK-8249906. - JDK-8259428: AlgorithmId.getEncodedParams() should return copy. - JDK-8257001: Improve HTTP client support. openjdk-17 (17~19-1) unstable; urgency=high * OpenJDK 17 snapshot, build 19. - Fix JDK-8250568: Less ambiguous processing (CVE-2021-2161). - Fix JDK-8249906: Enhance opening JARs (CVE-2021-2163).
Bug#987835: unblock: python2.7/2.7.18-7
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package python2.7. No code changes, just adding a breaks for upgrades, see #987661 for the issue and the diff for the fix.
Bug#986756: unblock: please unblock python3-defaults
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock please unblock python3-defaults/3.9.2-3. * Ship index.html to unbreak links in python-policy.html. Closes: #985313. * Don't ship html policy links in the python3.9 doc directory. Closes: #984961. There are no code changes, the package is a dependency package. Fixing a dangling symlink, and making the html policy links work, however the latter is already worked around at https://www.debian.org/doc/packaging-manuals/python-policy/
Bug#986755: unblock: please unblock what-is-python
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock please unblock what-is-python. * Update package descriptions for the Debian 11 (bullseye) release. * Bump package versions and provides. * Provide pdb symlinks in the -dev packages. * Also provide symlinks to the manual pages for all packages. There are no code changes, the package is a dependency package. The python-is-python3 and python-dev-is-python3 are now provided in version 3.9.x, instead of 3.8.x to match what is shipped with bullseye.
Bug#986754: unblock: please unblock gcc-9-cross and gcc-9-cross-ports
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock please unblock gcc-9-cross and gcc-9-cross-ports, no-change rebuilds using the gcc-9 version as found in bullseye.
Bug#986753: unblock: cross-toolchain-base-ports
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock please unblock cross-toolchain-base-ports/45, same rationale as given for cross-toolchain-base in #985363
Bug#986551: unblock: binutils-mipsen/7+c2
On 4/7/21 4:12 PM, Sebastian Ramacher wrote: > Control: tags -1 + moreinfo > > On 2021-04-07 18:26:47, YunQiang Su wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> >> Please unblock package binutils-mipsen/7+c2 >> >> It is a minimal FTBFS change: add debugedit to its build-deps. >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986508 >> >> It is also needed to have sync with the version of binutils in bullseye. > > This upload also drops zlib1g-dev from Build-Depends: > > Build-Depends: debhelper (>= 11), bison, flex, > - dejagnu, chrpath, lsb-release, > - binutils-source (>= 2.35.1-2), zlib1g-dev > + dejagnu, chrpath, lsb-release, debugedit, > + binutils-source (>= 2.35.1-2) > > Is that no longer needed? no, binutils-source depends on it.
Bug#984648: unblock: packages with unversioned python dependencies
linkchecker is fixed in 10.0.1-2
Bug#984648: unblock: packages with unversioned python dependencies
Control: reopen -1 there are more packages to fix/unblock: - b-d on python-dev, #942912, bagel, has a fix in the VCS - #942960, announced NMU, but never NMU'd now fixed in catch/1.12.1-1.1 - #936950, link-checker, reopened - apertium-arg-cat, filed new #984785 fixed in 0.2.0-2 - apertium-separable, filed new #984786 fixed in 0.3.6-2
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
On 3/4/21 9:58 AM, Paul Gevers wrote: > Control: tag -1 moreinfo > > Hi Stefano, > > On 25-02-2021 07:17, Stefano Rivera wrote: >> Please unblock package python3-defaults and python3.9 > > The python3-defaults package is currently blocked by autopkgtest > regressions. As usual, I suspect these are transient failures (either > infrastructure or flaky tests). If your going to inspect, flaky tests > are RC and can be filed, all failures are retried after a day. Please > remove the moreinfo bug if there's something that needs our attention. The four remaining failures are triggered by the fix for https://security-tracker.debian.org/tracker/CVE-2021-23336 bugs for mercurial, python-furl, python-w3lib and twisted are filed. the vorta/ppc64el issue seems to be unrelated, and fixed with vorta 0.7.5-1.
Bug#984697: unblock: setuptools/52.0.0-3
Package: release.debian.org X-Debbugs-CC: Stefano Rivera please unblock: setuptools/52.0.0-3, fixing the same issue #982921 as fixed in python-packaging in https://tracker.debian.org/news/1232090/accepted-python-packaging-209-2-source-into-unstable/ and already migrated to testing. Discussed with Stefano Rivero, that we don't want to unvendor packaging at this point.
Bug#984648: unblock: packages with unversioned python dependencies
Package: release.debian.org we don't want to ship packages in bullseye still referencing the unversioned python packages in build dependencies, dependencies and recommendations. Graham Inggs and I were looking for those, and identified at least yasm and zziplib, fixed in yasm/1.3.0-2.1 zziplib/0.13.62-3.3 The tracker https://release.debian.org/transitions/html/unversioned-python-rm.html shows some more packages as affected, but these all seem to be false positives: dipy nipype ola pycairo pygame-sdl2 spyne voluptuous
gcc-10 update for bullseye/bullseye-backports
Hi,
I never got feedback on the binutils/GCC plans outlined last July
https://lists.debian.org/debian-release/2020/07/msg8.html
At this point, I don't think another gcc-10 upload is needed, as people can work
around existing issues by using gcc-9, which still is used as a build
dependency. I will prepare a gcc-10 package for bullseye-backports, based on
the upstream 10.3.0 release.
The upgrade issue reported as #972936 is not confirmed, and missing feedback if
the suggested solution is working.
To check the current status of gcc-10 as found in experimental, I built a
package for unstable (including the suggested fix for #972936) at
deb [trusted=yes] http://people.debian.org/~doko/gcc/gcc10 ./
and asked Lucas Nussbaum for a comparative test rebuild. Results can be found
at
https://people.debian.org/~doko/logs/20210228/diff.vanilla-gcc10
Progressions:
$ awk '/Failed OK/ {print $1}' diff.vanilla-gcc10
gammaray
mkvtoolnix
nheko
odb
Regressions:
$ awk '/OK Failed/ {print $1}' diff.vanilla-gcc10
gsequencer
The latter filed as #983868, having both a work around and an upstream fix.
Matthias
Bug#983531: buster-pu: package python2.7/2.7.16-2+deb10u2
On 2/25/21 7:41 PM, Moritz Muehlenhoff wrote: > + * CVE-2021-3177 are all the ctypes tests passing with this patch? See #983516. Matthias
Bug#983499: unblock: python3-defaults/3.9.2~rc1-1, python3.9/3.9.2~rc1-1
On 2/25/21 10:16 PM, Paul Gevers wrote: > Control: tags -1 confirmed > > Hi Stefano, > > On 25-02-2021 07:17, Stefano Rivera wrote: >> Please unblock package python3-defaults and python3.9 >> >> Adding a new binary package, -full, to both source packages. Both are >> currently in binNEW. > > We'll unblock with the understanding that the only difference is these > new meta packages. I'm planning to upload the upload as done to experimental, plus the final (no changes) 3.9.2 release. Granted, refreshing the patches is not not necessary, but that's what is now tested in experimental. Matthias python3.9 (3.9.2-1) unstable; urgency=medium * Python 3.9.2 release. No changes since 3.9.2~rc1-1. * Build idlelib/help.html from source, don't ship the pre-generated file. -- Matthias Klose Sat, 20 Feb 2021 12:05:08 +0100 python3.9 (3.9.2~rc1-1) experimental; urgency=medium * Python 3.9.2 release candidate 1. Changes since 3.9.1-4: - Fix issue #42967, web cache poisoning vulnerability. - Fix issue #42938, explicitly disable bracketed paste in the interactive interpreter. Closes: #979154. * Fix permissions and group for local directories. Closes: #962422. * Build a python3.9-full package. * idle-python3.9: Drop dependency on libjs-mathjax, Unused in 3.8 and 3.9. * python3.9-doc: Fix links to the documentation in /usr/share/doc/python3.9. * Refresh patches. -- Matthias Klose Wed, 17 Feb 2021 19:32:50 +0100
Re: planning to upload binutils 2.35.2
On 2/1/21 7:57 PM, Paul Gevers wrote: > Hi > > On 29-01-2021 12:13, Matthias Klose wrote: >>> We would be happy with either of the following: >>> 1) upload to unstable with PR27218 only >>> 2) upload to experimental first (with a 2.36+really2.35.2 version) to >>> check all is fine. >> >> so I don't see what an upload for 2) would provide you with more information. > > It would give us a PASS or a FAIL. Where a PASS would tell us that > apparently it's not the DWARF5 changes that made the glibc autopkgtest > FAIL. A FAIL would tell us to be very suspicious about the change. I think your analysis is flawed. There's nothing producing DWARF5 debug information, so even a test rebuild of glibc doesn't tell you anything about the status of DWARF5. Also requesting a test rebuild of glibc not having information about concrete failures is not the most friendly way towards developers, and not the best use of volunteers time, as you mentioned elsewhere. I filed #982598 to address this, and from my perspective the severity of this issue should be raised if you plan to make the outcome of these tests a criteria for release decisions. https://release.debian.org/britney/pseudo-excuses-experimental.html#binutils shows no regressions except for cross-toolchain-base, caused by the version scheme proposed by yourself. As the build in experimental shows, the package builds and the regression will go away with a proper version number. The final 2.35.2 release also includes a fix for PR27259, and also some addition to recognize new POWER10 instructions (again, nothing produces these by default). Summarizing the changes compared to 2.35.1-7: * binutils 2.35.2 release. - PR gas/27218, memory access violation in dwarf2dbg.c - PR gas/27195, enable DWARF5 support when required - PR binutils/27231: Fix parsing DWARF-5 line number tables, DWARF-5: Ignore empty range in DWARF-5 line number tables - Fix thinko in objcopy's memory freeing code (double free). - Fix Segmentation fault i386-gen. - PR binutils/26483, ASAN: ppc_elf_link_params elf32-ppc.c. - PR binutils/26492, ASAN: ppc64_elf_before_check_relocs elf64-ppc.c. - PR binutils/26489, ASAN: ppc64_elf_size_stubs elf64-ppc.c. - power10 on ppc32 fix: We don't support power10 on ppc32, mainly because some instructions have 34-bit fields for which we don't have relocations on ppc32. If you try to assemble typical code, you'll see errors saying "reloc ... not supported by object file format". Also, on 32-bit hosts with binutils configured without a 64-bit bfd, you'll see errors saying "bignum invalid" when using large offsets. But let's not kill output of prefix insns entirely on 32-bit hosts. - R_PPC64_GOT_LO_DS and R_PPC64_GOT_HA sanity check. - POWER10: Add Return-Oriented Programming instructions. - PR gold/27246, skip address size and segment selector for DWARF5. - Fix PR ld/27259, stop ld from endless looping on SHF_LINK_ORDER sh_link loops. Also attaching the upstream git log for these changes. As you might guess, this review process didn't make much sense to me. Also seeing another linux upload flying by again without getting any ack or review seems to be odd. No, I didn't look for other frozen packages uploaded without ack or review. Matthias commit 3bcf28ab4a7205c606e6dfde4f55548f188ad7eb Author: Nick Clifton Date: Sat Jan 30 12:35:52 2021 + GNU Binutils 2.35.2 Release commit 7ed5ed075b9a166f74cf13be216b3e5cf04cd622 Author: Alan Modra Date: Thu Jan 28 10:30:36 2021 +1030 PR27259, SHF_LINK_ORDER self-link This stops ld from endless looping on SHF_LINK_ORDER sh_link loops. bfd/ PR 27259 * elflink.c (_bfd_elf_gc_mark_extra_sections): Use linker_mark to prevent endless looping of linked-to sections. ld/ PR 27259 * ldelf.c (ldelf_before_place_orphans): Use linker_mark to prevent endless looping of linked-to sections. (cherry picked from commit def97fb945a98544938087eff3111e16ce58da6d) commit 9107f37953b565a7604a4d89b8f2bf5b07a0279b Author: Alan Modra Date: Wed Jul 29 17:30:15 2020 +0930 Don't assert at ldwrite.c:212 When excluding SHF_LINK_ORDER sections that happen to have SEC_KEEP set, we need to set SEC_EXCLUDE here to avoid a problem later. * ldelf.c (ldelf_before_place_orphans): Set SEC_EXCLUDE for discarded sections. (cherry picked from commit 5987401fcbc9933808fa0d84d1b01c93356c39a1) commit 756beae66817dcf3794028cb49c8371f4ba54bfa Author: H.J. Lu Date: Thu Jan 28 04:21:15 2021 -0800 gold: Skip address size and segment selector for DWARF5 The .debug_line secton in DWARF5 has a byte for address size and a byte for segment selector after DWARF ver
Bug#982598: incomplete logs for autopkg tests
Package: release.debian.org Severity: important Tags: sid bullseye As seen with glibc autopkg tests [1], the Debian CI infrastructure doesn't store complete build logs, cutting these to 20MB (uncompressed), resulting in ~450k compressed logs. This might not be important for successful tests, but it doesn't provide any information for failed tests, as the summary at the end is always cut. Looking at the Ubuntu CI testers, you see that the glibc log for a successful test can reach 150MB, compressed 3.5GB [2]. With a glibc patch to not stop on test failures with the first pass [3], logs for failed tests can also reach that size. The outcome of tests is used by the release team to make decisions about the upcoming release [4]. Pointing out to a failed log which doesn't provide useful information is not helpful, and does cost volunteer time to analyze. In this case it turned out to be the flaky test infrastructure, and retries resulted in a successful test. Good luck with that for a real regression ... As pointed out in another context, "machine time is cheap, volunteer time is not" [5], as well as machine storage is cheap compared to volunteer time, so please stop cutting the autopkg test logs. Matthias [1] https://ci.debian.net/packages/g/glibc/unstable/amd64/ [2] https://autopkgtest.ubuntu.com/packages/g/glibc/hirsute/amd64 [3] https://bugs.debian.org/982360 [4] https://lists.debian.org/debian-release/2021/02/msg6.html [5] https://lists.debian.org/debian-devel/2021/02/msg00175.html
Re: OpenJDK 17 for bullseye-backports
[please ignore this thread started by Adrian; he's making statements on behalf of other teams, which are not correct. Also he "forgot" to CC the security team and the package maintainers. The issue is handled in #975016.] On 2/6/21 11:47 PM, Emmanuel Bourg wrote: > Le 02/02/2021 à 19:04, Adrian Bunk a écrit : > I agree that shipping a non LTS release of OpenJDK (12 to 16) is a bad > idea. Shipping OpenJDK 17 is worth considering though. > > >> My suggestion: >> >> No OpenJDK other than 11 is shipped in bullseye. >> >> If at the time of the bullseye release openjdk-17 in unstable is ready >> to migrate to testing except for the freeze, this means that: >> 1. it will migrate at the first migration of bookworm, and >> 2. the binaries will be installable on all architectures in bullseye >> >> The bootstrap could then be avoided by verbatim copying of this >> openjdk-17 sources and binaries for all architectures from bookworm >> to bullseye-backports. >> >> Subsequent updates of openjdk-17 in bullseye-backports would then follow >> the normal backports rules. > > If openjdk-17 can't be shipped in bullseyes even with prominent warnings > that it's unsupported, then this sounds like a good idea. See #975016. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#98 lists the proposals made. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#123 lists the OK of the security team for all proposals. So I'm going with option 1, preparing for an openjdk-17 in bullseye, and preparing release notes and notes for security support. This is more conservative than option 2, but allows to do better than the commitment made. The option also has the advantage that approval is only needed by the security team. openjdk-17 already is in testing. granting unblock requests for new snapshot builds by the release team would be appreciated, but isn't strictly necessary as long as we can build newer snapshots. And that can be checked in unstable. Matthias
Re: planning to upload binutils 2.35.2
On 1/28/21 8:36 PM, Paul Gevers wrote: > Hi Matthias, > > On 27-01-2021 22:42, Matthias Klose wrote: >> I have been following the way the linux source package was uploaded. >> Apparently >> the package entered unstable with just an announcement like this. And more >> than >> one time. > > For linux there was alignment, but see below. > >>> So, can you please clarify why you think these changes are needed? What >>> are the risks of including or not including these changes? How are the >>> risks mitigated? >> >> staging in experimental is not possible, unless you remove 2.36, or override >> it >> bumping the epoch. > > (or a +really version number). > >> - PR27218 is an obvious bug fix, avoiding a segfault. >> - DWARF5 is not enabled by default, the DWARF5 fixes are >>required for GCC 11 defaulting to use DWARF5. And no, >>I'm not planning to upload gcc-11 to unstable. >> >> I'm very unhappy about the private decision making for some uploads, while >> showing a pedantic attitude towards others. > > I must confess that indeed the alignment with the Release Team on linux > uploads happened in private. It shouldn't have, or at least the outcome > should have been public. > >> - PR27218 is an obvious bug fix, avoiding a segfault. > > Sound OK to have. > >> - DWARF5 is not enabled by default, the DWARF5 fixes are >>required for GCC 11 defaulting to use DWARF5. > > https://release.debian.org/britney/pseudo-excuses-experimental.html#binutils > (for 2.36-1) shows a regression for glibc. Hence we're not totally > confident. If it's not the default, why do we want this feature now? the log ends with: 8<8<8<- WARNING: log file truncated at 20 MB (before compression) 8<8<8<- autopkgtest [01:21:39]: summary rebuild FAIL non-zero exit status 2 > We would be happy with either of the following: > 1) upload to unstable with PR27218 only > 2) upload to experimental first (with a 2.36+really2.35.2 version) to > check all is fine. so I don't see what an upload for 2) would provide you with more information.
Re: planning to upload binutils 2.35.2
On 1/27/21 9:47 PM, Paul Gevers wrote: > Hi Matthias, > > On 26-01-2021 18:57, Matthias Klose wrote: >> I would like to upload binutils version 2.5.2-1 to unstable later this week. >> The >> 2.25.2 release is announced for this weekend ([1]). It imports fixes towards >> the next stable version. >> >> The pending fixes in the package are: >> >> * PR27218, memory access violation in dwarf2dbg.c >> * PR gas/27195, enable DWARF5 support when required >> * PR binutils/27231: Fix parsing DWARF-5 line number tables, >> DWARF-5: Ignore empty range in DWARF-5 line number tables >> >> All these changes also are in 2.36-1 as found in experimental. >> No packaging changes are planned for the upload. > In our freeze policy [1] we requested packages that are part of the > (build-)essential set to stop uploading to unstable. binutils is listed > there [2]. I have been following the way the linux source package was uploaded. Apparently the package entered unstable with just an announcement like this. And more than one time. > """ > If you think changes are needed anyway, please coordinate with the > release team before uploading to unstable. Consider staging changes in > experimental. > """ > > So, can you please clarify why you think these changes are needed? What > are the risks of including or not including these changes? How are the > risks mitigated? staging in experimental is not possible, unless you remove 2.36, or override it bumping the epoch. - PR27218 is an obvious bug fix, avoiding a segfault. - DWARF5 is not enabled by default, the DWARF5 fixes are required for GCC 11 defaulting to use DWARF5. And no, I'm not planning to upload gcc-11 to unstable. I'm very unhappy about the private decision making for some uploads, while showing a pedantic attitude towards others. Not so kind regards, Matthias
Re: Bug#975016: OpenJDK 15 support state for Bullseye
On 1/26/21 6:53 PM, Holger Levsen wrote: > On Tue, Jan 26, 2021 at 06:30:25PM +0100, Matthias Klose wrote: >> On 1/26/21 5:55 PM, Holger Levsen wrote: >>> On Tue, Jan 26, 2021 at 04:36:13PM +0100, Matthias Klose wrote: >>>>>> :) note however that "#975016: OpenJDK 15 support state for Bullseye" is >>>>>> still >>>>> ping, has there been any progress on this? >>>> chatting with Moritz from the security team, we found four options: >>>> 1) Ship a snapshot of OpenJDK 17 in bullseye. [...] >>> >>> I'm confused, the bug title is about OpenJDK 15?! >>> >>> So besides OpenJDK 17, what about 15 and 16? >> >> see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#10 > > thanks > >> the bug title is about one, and only one more, additional openjdk-N version, >> which is supposed to be an openjdk LTS version again: 17. > > so if 17 were shipped, 15 would not be shipped?!? (and 16 neither) please read above: "one, and only one more, additional openjdk-N version"
planning to upload binutils 2.35.2
Hi I would like to upload binutils version 2.5.2-1 to unstable later this week. The 2.25.2 release is announced for this weekend ([1]). It imports fixes towards the next stable version. The pending fixes in the package are: * PR27218, memory access violation in dwarf2dbg.c * PR gas/27195, enable DWARF5 support when required * PR binutils/27231: Fix parsing DWARF-5 line number tables, DWARF-5: Ignore empty range in DWARF-5 line number tables All these changes also are in 2.36-1 as found in experimental. No packaging changes are planned for the upload. Matthias [1] https://sourceware.org/pipermail/binutils/2021-January/115092.html
Re: Bug#975016: OpenJDK 15 support state for Bullseye
On 1/26/21 5:55 PM, Holger Levsen wrote: > On Tue, Jan 26, 2021 at 04:36:13PM +0100, Matthias Klose wrote: >>>> :) note however that "#975016: OpenJDK 15 support state for Bullseye" is >>>> still >>> ping, has there been any progress on this? >> chatting with Moritz from the security team, we found four options: >> 1) Ship a snapshot of OpenJDK 17 in bullseye. [...] > > I'm confused, the bug title is about OpenJDK 15?! > > So besides OpenJDK 17, what about 15 and 16? see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#10 the bug title is about one, and only one more, additional openjdk-N version, which is supposed to be an openjdk LTS version again: 17.
Re: Bug#975016: OpenJDK 15 support state for Bullseye
On 12/2/20 5:42 PM, Holger Levsen wrote: > On Fri, Nov 20, 2020 at 08:40:22AM +, Holger Levsen wrote: >>> Thanks for the upload. >> :) note however that "#975016: OpenJDK 15 support state for Bullseye" is >> still >> open... > > ping, has there been any progress on this? chatting with Moritz from the security team, we found four options: 1) Ship a snapshot of OpenJDK 17 in bullseye. The package is marked as a snapshot build. Mention in debian-security-support and the Release Notes, that the package is unsupported. The package should be updated to the final OpenJDK 17 release via debian-security (final release is expected in October 2021). I volunteer to do that, I also volunteer to prepare follow-up updates, but unlikely for every security update which is expected every three months. 2) Like option 1), but find somebody committing to constant security updates. Mentioning in debian-security-support and the Release Notes is not needed. 3) Provide OpenJDK 17 in the same archive area as planned for all the go dependencies. I don't know what would be involved with that. 4) Provide OpenJDK 17 in bullseye-backports only. I don't know how it can land there. The backports section also might not be enabled for everybody. My personal preference would be option 1. Matthias
Bug#978750: openjdk-N (non-default) should not trigger autopkg tests
Package: release.debian.org openjdk-N (non-default) should not trigger autopkg tests. All these don't make any sense, as the tests are always run using the default JRE/JDK. E.g. for 13, these were triggered today: autopkgtest for airport-utils: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for android-platform-tools-apksig: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for apgdiff: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for beagle: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for beast2-mcmc: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress (will not be considered a regression), ppc64el: Test in progress autopkgtest for chromhmm: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for chromimpute: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress (will not be considered a regression), i386: Test in progress (will not be considered a regression), ppc64el: Test in progress autopkgtest for clojure: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for davmail: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for drop-seq: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for imagej: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for libreoffice: amd64: Test in progress, arm64: Test in progress (will not be considered a regression), armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress (will not be considered a regression) autopkgtest for libsis-jhdf5-java: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for munin: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for openjdk-13: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for picard-tools: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for pilon: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress (will not be considered a regression), ppc64el: Test in progress autopkgtest for runescape: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress autopkgtest for swi-prolog: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Test in progress
Re: Porter roll call for Debian Bullseye
On 12/1/20 5:02 AM, YunQiang Su wrote: > I am sorry for the later response. >Hi, > > I am an active porter for the following architectures and I intend > to continue this for the lifetime of the Bullseye release (est. end > of 2024): > > For mipsel and mips64el, I > - test most packages on this architecture > - run a Debian testing or unstable system on port that I use regularly > - fix toolchain issues great ;-) gcc-cross-mipsen and gcc-10-cross-mipsen have never been in testing ... > - triage arch-specific bugs > - fix arch-related bugs any help with #972269 ?
Bug#972253: samba was forgotten for py3.9
On 11/20/20 9:33 PM, Matthias Klose wrote: > On 11/20/20 9:13 PM, Mathieu Parent wrote: >> Hi, >> >> It looks like samba was forgotten by the binNMU request. >> >> See https://bugs.debian.org/975330 >> >> Can you schedule that? > > no, according to > https://release.debian.org/transitions/html/python3.9-default.html > ldb ftbfs on s390x. wait, the build is still pending ...
Bug#972253: samba was forgotten for py3.9
On 11/20/20 9:13 PM, Mathieu Parent wrote: > Hi, > > It looks like samba was forgotten by the binNMU request. > > See https://bugs.debian.org/975330 > > Can you schedule that? no, according to https://release.debian.org/transitions/html/python3.9-default.html ldb ftbfs on s390x.
Re: Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye
On 11/18/20 8:03 PM, Adrian Bunk wrote: > On Wed, Nov 18, 2020 at 12:20:37PM +0100, Matthias Klose wrote: >> For OpenJDK there are two other possibilities, which would require approval >> by >> release managers / stable release managers. >> >> - openjdk-16 will be released in April 2021, which is expected >>before the bullseye release. Shipping openjdk-16 instead of >>openjdk-15 would have the advantage that you are able to build >>openjdk-17 directly, without having to build openjdk-17 (LTS). >> >>This would require a feature freeze exception for bullseye. >> >> - package a snapshot of openjdk-17 (in April/May 2021), and >>only ship openjdk-17 in bullseye. In that case, update to >>the final openjdk-17 release in Oct 2021 as a stable release >>update, or as a security update. >> >>This would require a feature freeze exception for bullseye. >> >>After the bullseye release, it would require an approval of >>the stable release managers, or approval by the security >>team as a security update. I'm not saying that this package >>should see constant security support, but it is likely >>that openjdk-17 sees extended support upstream. > > New OpenJDK versions tend to cause both buildtime and runtime breakages > in reverse dependencies, some of them hard to resolve and requiring > updates to new upstream versions which in turn require new dependencies > that might not even be in Debian. New upstream versions likely do that, that's not an attribute of OpenJDK. What's your point?
Re: Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye
On 11/18/20 7:46 PM, Moritz Muehlenhoff wrote: > On Wed, Nov 18, 2020 at 12:20:37PM +0100, Matthias Klose wrote: >> [removed the Python 2 bits] >> >> On 11/17/20 11:08 PM, Moritz Muehlenhoff wrote: >>> Package: debian-security-support >>> Severity: normal >>> X-Debbugs-Cc: d...@debian.org, t...@security.debian.org >> >>> openjdk-15 will be included, but not covered by support >>> (as it's only needed to bootstrap openjdk-16 and eventually >>> openjdk-17, the next LTS release of Java). >>> >>> How about the following for "security-support-limited"? >>> >>> >>> openjdk-15Only included for bootstrapping later OpenJDK >>> releases >>> >>> >>> One important thing: These only applies to Bullseye and >>> security-support-limited is currently independent of releases, so this >>> needs to be fixed or alternatively we need to stop rebuilding the current >>> unstable package for older releases and instead branch of per distro. >> >> As background: OpenJDK 12 can only be built with 11, 13 with 12, 14 with 13, >> 15 >> with 14, 16 with 15. Only having 11 in bullseye would make backports more >> "interesting". >> >> For OpenJDK there are two other possibilities, which would require approval >> by >> release managers / stable release managers. > > If the whole "buildlibs" (or however it gets called in the end) > infrastructure is > ready for bullseye it would also be an option to include > openjdk-15/openjdk-16 in > there? As such, it would be non-available to users by default, but present for > bootstraps. sure, if you don't change it for the sid/unstable packages.
Re: Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye
On 11/18/20 1:36 PM, Florian Weimer wrote: > * Matthias Klose: > >> As background: OpenJDK 12 can only be built with 11, 13 with 12, 14 with 13, >> 15 >> with 14, 16 with 15. Only having 11 in bullseye would make backports more >> "interesting". > > All recent OpenJDK releases can be built by themselves, right? yes, forgot to mention that.
Re: Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye
[removed the Python 2 bits] On 11/17/20 11:08 PM, Moritz Muehlenhoff wrote: > Package: debian-security-support > Severity: normal > X-Debbugs-Cc: d...@debian.org, t...@security.debian.org > openjdk-15 will be included, but not covered by support > (as it's only needed to bootstrap openjdk-16 and eventually > openjdk-17, the next LTS release of Java). > > How about the following for "security-support-limited"? > > > openjdk-15Only included for bootstrapping later OpenJDK > releases > > > One important thing: These only applies to Bullseye and > security-support-limited is currently independent of releases, so this > needs to be fixed or alternatively we need to stop rebuilding the current > unstable package for older releases and instead branch of per distro. As background: OpenJDK 12 can only be built with 11, 13 with 12, 14 with 13, 15 with 14, 16 with 15. Only having 11 in bullseye would make backports more "interesting". For OpenJDK there are two other possibilities, which would require approval by release managers / stable release managers. - openjdk-16 will be released in April 2021, which is expected before the bullseye release. Shipping openjdk-16 instead of openjdk-15 would have the advantage that you are able to build openjdk-17 directly, without having to build openjdk-17 (LTS). This would require a feature freeze exception for bullseye. - package a snapshot of openjdk-17 (in April/May 2021), and only ship openjdk-17 in bullseye. In that case, update to the final openjdk-17 release in Oct 2021 as a stable release update, or as a security update. This would require a feature freeze exception for bullseye. After the bullseye release, it would require an approval of the stable release managers, or approval by the security team as a security update. I'm not saying that this package should see constant security support, but it is likely that openjdk-17 sees extended support upstream. Matthias
Bug#972253: transition: python3.9 as default
as outlined in https://lists.debian.org/debian-python/2020/07/msg00023.html it's now time to go ahead with the 3.9 defaults change. https://lists.debian.org/debian-python/2020/11/msg00012.html has a status update about outstanding issues, focusing on the key packages. While not every fix is available in unstable, there is upstream support for those key packages, and the status is covered in bug reports. this transition should be less dependent on other transitions as we already have 3.8 and 3.9 extensions migrated to testing. The only entanglement should be with packages only supporting to build with the default python3 version, and introducing a transition themself. It might be good to wait on finishing the perl transition, but currently there's no entanglement at this point. Matthias
Bug#972253: transition: python3.9 as default
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition While we are still in the first phase, adding 3.9 as a supported python3 version, please setup a tracker for 3.9 as the default python3 version, re-using the tracker for 3.8 as the default.
Bug#966426: (some kind of) transition: add python3.9 as a supported python3 version
status update: https://lists.debian.org/debian-python/2020/10/msg00033.html
Re: Bug#969946: binutils: ld.gold produces wrong C++ EH information on mipsel and mips64el
On 9/12/20 8:55 AM, Vasyl Gello wrote: > Hi Matthias! > > On Fri, 11 Sep 2020 12:50:33 +0200 Matthias Klose wrote: >> Control: severity -1 important >> >> lowering the severity, please use the BFD linker if possible, CCing to the >> mips >> porters. > > Unfortunately Octeon boards with 8GB dont play well with bfd - bfd fails > allocating memory and exits with "memory exhausted" error. > How should I act further? Should I file a ticket on sourceware bugzilla or > send a message to their mailing list or do different things? Please ask the mips porters how to proceed.
Bug#965057: guile OOM test failures on ppc64el
On 8/14/20 11:33 AM, Matthias Klose wrote: > I'm now NMUing both guile-2.2 and guile-3.0 to just ignore the test results on > ppc64el, without closing the bug reports. It's blocking the gcc-10 migration > to > testing. now, the NMUs fail with the same OOM error on armhf (3.0) and armhf/i386 (2.2) as well... Maybe just don't run the OOM tests, instead of ignoring the test results?
Bug#965057: guile OOM test failures on ppc64el
I'm now NMUing both guile-2.2 and guile-3.0 to just ignore the test results on ppc64el, without closing the bug reports. It's blocking the gcc-10 migration to testing.
Bug#965057: transition: libgc
On 8/1/20 12:28 PM, Sebastian Ramacher wrote: > Control: block -1 by 966300 966301 > > On 2020-07-21 23:07:09 +0200, Sebastian Ramacher wrote: >> Control: forwarded -1 >> https://release.debian.org/transitions/html/auto-libgc.html >> Control: tags -1 + confirmed >> >> On 2020-07-15 12:14:06 +0200, Matthias Klose wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> >>> Packages build ok with the libgc from experimental, except for guile. Filed >>> patches to fix the guile builds with make 4.3, however guile-2.0 fails >>> tests on >>> amd64. guile-2.0 could be removed from testing, only has three rdeps on >>> leaf >>> packages. >> >> guile-2.0 has no reverse dependencies in testing anymore, so I've added >> a removal hint. Are you going to take care of guile-2.2? >> >> Please go ahead with the upload to unstable. > > This transition is currently blocked by build failures of guile-2.2 and > guile-3.0 on ppc64el. reported a week ago as #966300 and #966301. Rob commented on that issue yesterday.
Bug#966426: (some kind of) transition: add python3.9 as a supported python3 version
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Please setup a tracker to add python3.9 as a supported python3 version. This is non-blocking, as packages can migrate on their own once built. I'm not yet starting this, just want to have an overview of affected packages. Please re-use the final version of the python3.8 tracker (#942106).
Bug#965970: transition: libgphobos
On 7/21/20 7:16 PM, Matthias Klose wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > These packages need rebuilding for gdc-10. Maybe it's safe to add an extra > b-d > on gdc (>= 1:10.1) for the binNMUs. that should be: gdc (>= 4:10.1)
Bug#965972: transition: libasan
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Two packages are built using the address sanitzer, the binNMUs should be done with an extra b-d on gcc (>= 4:10.1). wlcs goxel
Bug#965971: transition: libgo
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Two packages are built using gccgo, the binNMUs should be done with an extra b-d on gccgo (>= 4:10.1). uswgi gitbrute
Bug#965970: transition: libgphobos
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition These packages need rebuilding for gdc-10. Maybe it's safe to add an extra b-d on gdc (>= 1:10.1) for the binNMUs. a7xpg cheesecutter dub dustmite gunroar ii-esu mu-cade parsec47 projectl tatan titanion torus-trooper tumiki-fighters val-and-rick
Bug#965057: transition: libgc
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Packages build ok with the libgc from experimental, except for guile. Filed patches to fix the guile builds with make 4.3, however guile-2.0 fails tests on amd64. guile-2.0 could be removed from testing, only has three rdeps on leaf packages.
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On 7/8/20 9:21 PM, Paul Gevers wrote: > Hi, > > [Note, this e-mail may look familiar as it is mostly copied over from > the buster call, not much has changed, AFAICT]. > > As part of the interim architecture qualification for bullseye, we > request that DSA, the security team, Wanna build, and the toolchain > maintainers review and update their list of known concerns for bullseye > release architectures. > > Summary of the current concerns and issues: > * DSA have announced a blocking issue for armel and armhf (see below) > * Concerns from DSA about ppc64el and s390x have been carried over from >(stretch and) buster. > * Concerns from the GCC maintainers about i386, armel, armhf, mips64el >and mipsel have been carried over from (stretch and) buster. > > If the issues and concerns from you or your team are not up to date, > then please follow up to this email (keeping debian-release@l.d.o in CC > to ensure we are notified). > > Whilst porters remain ultimately responsible for ensuring the > architectures are ready for release, we do expect that you / your team > are willing to assist with clarifications of the concerns and to apply > patches/changes in a timely manner to resolve the concerns. > > > List of blocking issues by architecture > === > > The following is a summary from the current architecture qualification > table. > > armel/armhf: > > > * Undesirable to keep the hardware running beyond 2020. armhf VM >support uncertain. (DSA) >- Source: [DSA Sprint report] >- I was under the impression that this issue has been resolved (at > least for armhf) by now, but we like a fresh statement on this. > > > [DSA Sprint report]: > https://lists.debian.org/debian-project/2018/02/msg4.html > > > List of concerns for architectures > == > > The following is a summary from the current architecture qualification > table. > > * Concern for ppc64el and s390x: we are dependent on sponsors for >hardware. >(Raised by DSA; carried over from stretch and buster) > > * Concern for armel and armhf: only secondary upstream support in GCC >(Raised by the GCC maintainer; carried over from stretch and buster) this was wrong, and still is wrong. See https://gcc.gnu.org/gcc-10/criteria.html. arm-linux-gnueabi is listed as a primary platform. The arm-linux-gnueabihf triplet never gained much traction outside of Debian/Ubuntu, so should be included. armel might be special because the use of the libatomics library is mandatory. > * Concern for mips, mips64el, mipsel and ppc64el: no upstream support >in GCC; Debian carries patches in binutils and GCC that haven't been >integrated upstream even after a long time. >(Raised by the GCC maintainer; carried over from stretch and buster) this is wrong for ppc64el (at least I didn't raise that). powerpc64-unknown-linux-gnu is listed as a primary platform. https://gcc.gnu.org/gcc-8/criteria.html explicitly lists the little endian variant, and after checking with upstream it looks like an omission to document that for GCC 9 and GCC 10 as well. A concern that appears to get ignored by the release team is that both mipsel and mips64el are neither a primary or a secondary release architecture. You seem to mention it in the summary, but don't have it in the list of concerns. GCC upstream only lists the bare metal mips*elf target, plus I don't see any other test results getting posted to the gcc-testresults ML besides for the Debian builds. Please also note the 100+ test failures for mips* in binutils, which are not addressed for years. See https://sourceware.org/pipermail/binutils/2020-July/112201.html mipsel now adds another work around to build 64bit compilers to be able to build larger projects (see e.g. binutils64). > Architecture status > === > > These are the architectures currently being built for bullseye: > > * Intel/AMD-based: amd64, i386 > * ARM-based: arm64, armel, armhf > * MIPS-based: mipsel, mips64el > * Other: ppc64el, s390x > > If the blocking issues cannot be resolved, affected architectures are at > risk of removal from testing before bullseye is frozen. > > We are currently unaware of any new architectures likely to be ready in > time for inclusion in bullseye. > > On behalf of the release team, > Paul Gevers >
GCC and binutils plans for bullseye
Debian bullseye will be based on a gcc-10 package taken from the gcc-10 upstream branch, and binutils based on a binutils package taken from the 2.35 branch. I'm planning to make gcc-10 the default after gcc-10 (10.2.0) is available (upstream targets mid July). binutils will be updated before making the GCC switch. The GCC 10 switch involves some minor library transitions for D, gccgo, M2, which should be no-brainers. The gnat transition will be handled separately by the debian Ada maintainers. binutils should be pretty stable until the bullseye release, not planning an update to 2.36. GCC 10 should be updated to 10.3, or close to 10.3 (the release date is not yet known, could be Feb 2021). I'd like to get rid off GCC 8 and GCC 9 for the bullseye release. Matthias
Bug#961195: transition: glibc
On 6/4/20 2:05 PM, Aurelien Jarno wrote: > On 2020-06-04 13:06, Matthias Klose wrote: >> On 5/21/20 11:39 AM, Aurelien Jarno wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> >>> Dear release team, >>> >>> I would like to get a transition slot for glibc 2.31. It is available in >>> experimental for more than 2 months and there are no known issues or >>> regression. It has been built successfully on all release architectures >>> and most ports architectures. It fails to build on ia64 and sparc64 due >>> to a few testsuite issues that need to be investigated and which are >>> similar to existing failures in version 2.30. It doesn't build on >>> kfreebsd-*, but this has been the case for a few glibc releases already. >>> >>> As glibc is using symbol versioning, there is no soname change. That >>> said a few packages are using libc internal symbols and have to be >>> rebuilt for this transition: >>> - apitrace >>> - bro >>> - dante >>> - gcc-9 (s390x only) >>> - libnih >>> - libnss-db >>> - r-bioc-preprocesscore >>> - unscd >>> >>> Compare to the previous transition, gcc-10 and gcc-snapshot got removed, >>> and r-bioc-preprocesscore got added. >>> >>> Here is the corresponding ben file: >>> title = "glibc"; >>> is_affected = .depends ~ /libc[0-9.]* \(<>> is_good = .depends ~ /libc[0-9.]* \(<< 2.32\)/; >>> is_bad = .depends ~ /libc[0-9.]* \(<< 2.31\)/; >>> >>> In addition a few new symbols have been added that might prevent a few >>> other packages to migrate to testing until glibc migrates if they pick >>> up the new symbols, however those are really limited in this version. >> >> there are dozens of packages that ftbfs with this new version. Please could >> you >> at least file bug reports for all of those? > > Yes I can do that. Do you have a list available? No.
Bug#961195: transition: glibc
On 6/4/20 1:06 PM, Matthias Klose wrote: > On 5/21/20 11:39 AM, Aurelien Jarno wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> >> Dear release team, >> >> I would like to get a transition slot for glibc 2.31. It is available in >> experimental for more than 2 months and there are no known issues or >> regression. It has been built successfully on all release architectures >> and most ports architectures. It fails to build on ia64 and sparc64 due >> to a few testsuite issues that need to be investigated and which are >> similar to existing failures in version 2.30. It doesn't build on >> kfreebsd-*, but this has been the case for a few glibc releases already. >> >> As glibc is using symbol versioning, there is no soname change. That >> said a few packages are using libc internal symbols and have to be >> rebuilt for this transition: >> - apitrace >> - bro >> - dante >> - gcc-9 (s390x only) >> - libnih >> - libnss-db >> - r-bioc-preprocesscore >> - unscd >> >> Compare to the previous transition, gcc-10 and gcc-snapshot got removed, >> and r-bioc-preprocesscore got added. >> >> Here is the corresponding ben file: >> title = "glibc"; >> is_affected = .depends ~ /libc[0-9.]* \(<> is_good = .depends ~ /libc[0-9.]* \(<< 2.32\)/; >> is_bad = .depends ~ /libc[0-9.]* \(<< 2.31\)/; >> >> In addition a few new symbols have been added that might prevent a few >> other packages to migrate to testing until glibc migrates if they pick >> up the new symbols, however those are really limited in this version. > > there are dozens of packages that ftbfs with this new version. Please could > you > at least file bug reports for all of those? this is about the missing SIOCGSTAMP macro. So maybe jsut triggered by a removed glibc include? Including fixes these.
Bug#961195: transition: glibc
On 5/21/20 11:39 AM, Aurelien Jarno wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear release team, > > I would like to get a transition slot for glibc 2.31. It is available in > experimental for more than 2 months and there are no known issues or > regression. It has been built successfully on all release architectures > and most ports architectures. It fails to build on ia64 and sparc64 due > to a few testsuite issues that need to be investigated and which are > similar to existing failures in version 2.30. It doesn't build on > kfreebsd-*, but this has been the case for a few glibc releases already. > > As glibc is using symbol versioning, there is no soname change. That > said a few packages are using libc internal symbols and have to be > rebuilt for this transition: > - apitrace > - bro > - dante > - gcc-9 (s390x only) > - libnih > - libnss-db > - r-bioc-preprocesscore > - unscd > > Compare to the previous transition, gcc-10 and gcc-snapshot got removed, > and r-bioc-preprocesscore got added. > > Here is the corresponding ben file: > title = "glibc"; > is_affected = .depends ~ /libc[0-9.]* \(< is_good = .depends ~ /libc[0-9.]* \(<< 2.32\)/; > is_bad = .depends ~ /libc[0-9.]* \(<< 2.31\)/; > > In addition a few new symbols have been added that might prevent a few > other packages to migrate to testing until glibc migrates if they pick > up the new symbols, however those are really limited in this version. there are dozens of packages that ftbfs with this new version. Please could you at least file bug reports for all of those?
Re: architecture qualification season
On 5/7/20 9:41 PM, Paul Gevers wrote: > Hi > > On 02-05-2020 21:53, Paul Gevers wrote: >> I don't think anybody likes to do it, but we have to discuss the >> architectures that will be part of bullseye. In the before last IRC >> meeting I promised I would send this mail, so here we go. Let's see what >> items we consider a must. Anybody else that wants to step in, feel free >> to take any action. >> >> 1) I haven't heard of new architectures that want to be on board for >> bullseye. >> >> 2) I think we have to ask several parties if they are OK with supporting >> the existing architectures: porters, DSA and security. I recall [1] DSA >> had issues with armel, but I believe that has been resolved by building >> on some other arm boxes, right? Do we already know of other issues? > > I found this mail from Niels from the buster release cycle [2]. Going > through it, it looks like it could be reused nearly completely. > >> 3) In the current state, I think it boils down to the question if armel >> and mipsel should be dropped for bullseye or not. What do we think >> ourselves? Myself, I've been regularly cursing mipsel for it being so >> much slower to build packages than most architectures, but I don't think >> that's enough ;). Also, the limited address space of 32 bit >> architectures is lowest on mipsel and it is starting to count. I've seen >> several issues due to it (e.g. rustc), meaning that maintainers of some >> large packages need to spend serious effort to build their package on >> mipsel. I feel that several maintainers seriously doubt that effort is >> well spent. > > The 32 bit issue was discussed for buster quite extensively. There are now also attempts to package binutils64 and gcc-N-64 to build a 64bit toolchain on at least mipsel and i386. As a maintainer I'm not keen to add these builds to the binutils and gcc-N packages. In additions to the concerns in [2], there are also a bunch of mips* patches which are not yet integrated upstream in binutils and GCC. mipsel buildds also seem to be the slowest buildds among the buildds for release architectures. Matthias >> [1] https://release.debian.org/bullseye/arch_qualify.html > > Paul > > [2] https://lists.debian.org/debian-release/2018/06/msg00644.html >
Bug#949187: transition: python3.8
On 2/3/20 8:22 PM, Simon McVittie wrote: > On Sun, 02 Feb 2020 at 09:35:04 +0100, Matthias Klose wrote: >> I think this is now in shape to be started. > > Please can this wait until the remaining bits of the libffi7 transition > and the restructuring of the libgcc_s packaging have settled down? > > I'm still trying to sort out the missing Breaks around > gobject-introspection, as highlighted by autopkgtest failures: this has > been delayed by needing coordinated action between multiple packages, > some of them quite big (glib2.0), and by Paul and I being at FOSDEM. > This is entangled with python3.8 via pygobject (which will fail tests > with python3.8 as default - an upload is pending to fix that). fine. I'm happy to see that fixed. > Meanwhile, multiple packages seem to FTBFS on s390x with the new libgcc_s > (I've just opened the bug for that, so no bug number known yet), which is > going to limit the ability to get things into testing. please retry your package builds. it's fixed in unstable.
Bug#949187: transition: python3.8
On 2/2/20 5:53 PM, Rene Engelhard wrote: > On Sun, Feb 02, 2020 at 09:35:04AM +0100, Matthias Klose wrote: >>> On 17-01-2020 23:28, Matthias Klose wrote: >>>> Please add a transition tracker to switch the python3 default to 3.8. >>>> It's not >>>> yet ready, however it would be good to see affected packages. Please copy >>>> it >>>> from the 3.7 defaults change if possible. >>> >>> Tracker is in place. Please remove the moreinfo tag when you're ready. >> >> I think this is now in shape to be started. bug reports have been filed for > > I don't think so. > > e.g. fontforge is still red in > https://release.debian.org/transitions/html/python3.8.html. > > That means that a rebuild of stuff using fontforge in the build will > just FTBFS since it will be called with python3.8 and that has no module > for 3.8 (yet). > > (Seen in a python-3.8-as-default testbuild for libreoffice some time > ago.) you are wrong. fontforge just builds for the default python version.
Bug#949187: transition: python3.8
Control: tags -1 - moreinfo On 1/18/20 9:30 PM, Paul Gevers wrote: > Control: tags -1 moreinfo > > Hi Matthias, > > On 17-01-2020 23:28, Matthias Klose wrote: >> Please add a transition tracker to switch the python3 default to 3.8. It's >> not >> yet ready, however it would be good to see affected packages. Please copy it >> from the 3.7 defaults change if possible. > > Tracker is in place. Please remove the moreinfo tag when you're ready. I think this is now in shape to be started. bug reports have been filed for issues with 3.8 in [1], and there may be some which are missing the proper tagging. I also filed bug reports for a dozen missing dh-python build dependencies. I would prefer a transition slot with less activity with transitions in the science area, like opencv, openmpi, gnuradio, ros*, and others which only build extensions for the default python3 version. Matthias [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.8;users=debian-pyt...@lists.debian.org
Bug#949185: transition: libffi
On 19.01.20 09:40, Graham Inggs wrote: > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-libffi.html > Control: tags -1 + moreinfo > > On Fri, 17 Jan 2020 at 23:33, Matthias Klose wrote: >> libffi is finally released. There are two packages needing patches: >> >> ecl >> polyml > > Please file bugs for these. these are now filed, with patches.
Bug#949187: transition: python3.8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Please add a transition tracker to switch the python3 default to 3.8. It's not yet ready, however it would be good to see affected packages. Please copy it from the 3.7 defaults change if possible.
Bug#949185: transition: libffi
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition libffi is finally released. There are two packages needing patches: ecl polyml and three packages already ftbfs in unstable: bustle uuagc haskell-stack I had done a test rebuild in November in Ubuntu [1], [2], and it's currently looking ok in [3]. It's not a Debian test build, but it covers some more architectures. Please use the auto libffi tracker. Matthias [1] https://launchpad.net/~doko/+archive/ubuntu/libffi [2] https://launchpad.net/~doko/+archive/ubuntu/libffi-3.2.1 [3] https://people.canonical.com/~ubuntu-archive/transitions/html/libffi.html
Bug#946157: libisl transition
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Not really a transition, but a binNMU for one package should be done: gcc-mingw-w64 Not asking for any -mipsen package, because these are not in testing.
Re: Severity bump script
On 02.12.19 20:28, Paul Gevers wrote: > Hi all, > > On 01-12-2019 22:45, Sandro Tosi wrote: >> Paul, this is the thread i was talking about. >> >> you were copied in the original email: >> https://lists.debian.org/debian-python/2019/10/msg00098.html >> >> if there is something the RT wants to discuss about this effort, >> please do so here, not directly to me (i may be the mail address >> sending those control commands, but the decision was taken here). > > I understand the drive to push for Python 2 removal and sympathize with > it. The issue I had yesterday with the process is that "leaf" was > wrongly defined, it was looking at Depends, instead of also including > Build-Depends. that should be fixed. > I don't want to stand in the way of Python 2 removal, but as I said > before, pulling packages out from underneath maintainers isn't pretty so > needs to be done with proper notifications and care. An RC bug to ones > own package is acceptable in my opinion as it is a clear discussion > forum, and can be (temporarily) down-graded while the discussion is > ongoing. Being notified about some other package that I not even need > directly but is going to pull "my" package out of testing isn't a nice > experience and should be avoided. Yes, that slows down the process, but > there are people, emotions and all those irrational things involved. It's unfortunate that issues for some packages only get attention when the severity of an issue is raised. Following your proposal means that the issue is probably ignored forever, and you don't propose a better way going forward, just saying we should stop earlier. I don't think that's the correct choice. For now these seem to be single packages, so please could you name those, and we can look at those with a priority? That's at least a path that is forward looking, or feel free to propose another approach better than your current proposal for not getting the attention of maintainers. Matthias PS: There's a RC issue for creduce now, not caused by the package itself, should I downgrade it?
Bug#942106: Adding Python 3.8 as a supported Python3 version
On 12.11.19 23:39, Matthias Klose wrote: > On 07.11.19 15:08, Matthias Klose wrote: >> This weekend, I am planning to upload python3-defaults, adding python3.8 as a >> supported Python3 version. This may introduce some churn in unstable until >> the >> basic binNMUs are available as well. >> >> Details for the addition can be found at [1], known issues and patches are >> filed >> [2]. There was no test rebuild in Debian itself, but the addition was made >> in >> the current Ubuntu development series. Things look good, and from my point >> of >> view don't block any unrelated transition work. python3-defaults will get a >> RC >> issue to stay in unstable until the packages build-depending on >> python3-all-dev >> are built, and after doing a test rebuild with the two supported Python3 >> versions. Earlier test rebuilds don't make sense. >> >> There are a few packages, where the upstream versions used in Ubuntu diverge >> from the ones currently in unstable (not naming those already updated in >> unstable by the DPMT): >> >> - hypothesis #942693, not sure if this is really needed, >> the testsuite stack might be fixed by the new pluggy >> version as well. >> >> - python-xarray #944044. 1.4 is already broken with Python 3.7. For >> Ubuntu I fell back to 1.2.1. 1.2.3 might work as well, still seeing >> one or two test failures. >> >> - Using numpy from experimental, and only building the Python2 numpy >> packages from the python-numpy source. >> >> - Using python-scipy from experimental, building the Python3 packages, >> and renaming the python-scipy package to python2-scipy, only building >> the Python2 packages. >> >> - matplotlib and pandas don't have Python2 packages in Ubuntu >> anymore, so I can't tell much what is needed here. Pandas needs >> a new upstream for 3.8. >> >> Packages building on top of numpy/scipy/pandas, like the PyAstro stack, >> continue >> to work with these updates, despite some new test failures. > > So this upload didn't happen, but thanks to Rebecca we now have an almost > Python2 free pandas in unstable. And apologies to the science team for the > 1-day > delayed NMUs for patsy and scikit-learn. > > Now planning the python3-defaults upload for Thursday or Friday. python3-defaults with 3.8 as a supported Python3 version is now built in unstable. Release team, please schedule binNMUs fpr stage1 and then stage2. I'll raise severity of the 3.8 issues, and follow-up with 2-days delayed NMUs. Matthias
Bug#942106: Adding Python 3.8 as a supported Python3 version
On 07.11.19 15:08, Matthias Klose wrote: > This weekend, I am planning to upload python3-defaults, adding python3.8 as a > supported Python3 version. This may introduce some churn in unstable until > the > basic binNMUs are available as well. > > Details for the addition can be found at [1], known issues and patches are > filed > [2]. There was no test rebuild in Debian itself, but the addition was made in > the current Ubuntu development series. Things look good, and from my point of > view don't block any unrelated transition work. python3-defaults will get a > RC > issue to stay in unstable until the packages build-depending on > python3-all-dev > are built, and after doing a test rebuild with the two supported Python3 > versions. Earlier test rebuilds don't make sense. > > There are a few packages, where the upstream versions used in Ubuntu diverge > from the ones currently in unstable (not naming those already updated in > unstable by the DPMT): > > - hypothesis #942693, not sure if this is really needed, > the testsuite stack might be fixed by the new pluggy > version as well. > > - python-xarray #944044. 1.4 is already broken with Python 3.7. For > Ubuntu I fell back to 1.2.1. 1.2.3 might work as well, still seeing > one or two test failures. > > - Using numpy from experimental, and only building the Python2 numpy > packages from the python-numpy source. > > - Using python-scipy from experimental, building the Python3 packages, > and renaming the python-scipy package to python2-scipy, only building > the Python2 packages. > > - matplotlib and pandas don't have Python2 packages in Ubuntu > anymore, so I can't tell much what is needed here. Pandas needs > a new upstream for 3.8. > > Packages building on top of numpy/scipy/pandas, like the PyAstro stack, > continue > to work with these updates, despite some new test failures. So this upload didn't happen, but thanks to Rebecca we now have an almost Python2 free pandas in unstable. And apologies to the science team for the 1-day delayed NMUs for patsy and scikit-learn. Now planning the python3-defaults upload for Thursday or Friday. Matthias
Bug#942106: python3.8 / pandas py2removal
On 10.11.19 14:46, Rebecca N. Palmer wrote: mdp isn't in testing either, but if you're using a policy of "no py2removals that break packages in testing", tnseq-transit (Depends: statsmodels) and possibly stimfit (Recommends: pandas) need to be done as well. Those are both thought to need new upstream versions. tnseq-transit is a leaf package, raising the severity now, could be removed and re-enter later. IMO, we should care about the recommends later ... (patsy isn't a leaf package for py2removal, it's in a cycle with pandas and statsmodels, i.e. for a non-breaking removal they all have to go together.) ok I'm undoing the NMU from the delayed queue, you'll find it at https://people.debian.org/~doko/tmp/
Bug#942106: python3.8 / pandas py2removal
On 10.11.19 14:22, Matthias Klose wrote: patsy is a leaf package, no problem. scikit-learn, needs mdp, pymvpa2, I think that's manageable, so I'm volunteering to do the NMUs, preferably with a 0 or 1 day delay. PyMVPA has other RC issues, is removed from testing, so ignore it for now. and I'm raising the severity of the py2removal bug.
Bug#942106: python3.8 / pandas py2removal
[CCing debian-science] On 10.11.19 13:18, Rebecca N. Palmer wrote: Matthias Klose wrote: yes, please do [raise pandas 0.25 blocking bugs to "important"] Done, but only 2 of them have been fixed since. This leaves 13: has patch or Ubuntu fix: matplotlib2 patsy python-apptools scikit-learn may need more extensive work: cnvkit python-feather-format python-skbio stimfit tnseq-transit already not in testing: mdp psychopy pymvpa q2-types If you can get that done with [pandas] 0.25, fine, It took longer than I was expecting, but pandas 0.25 / statsmodels 0.10 now appear to be working, including with python3.8. (Though we won't actually know if #943732 is gone until mipsel tries to build it.) \o/ and I wouldn't worry too much about the other four breaking packages at this point. Was this intended as... ... a request to upload pandas 0.25 / statsmodels 0.10 to unstable (and apply the Ubuntu py2removal patches to patsy and scikit-learn?), overriding normal py2removal rules? patsy is a leaf package, no problem. scikit-learn, needs mdp, pymvpa2, I think that's manageable, so I'm volunteering to do the NMUs, preferably with a 0 or 1 day delay. So yes, please go ahead. ... a request to split pandas into a pandas2 0.23 and a pandas 0.25? (since 4 is only the number of non-py2removal breakages, and the wiki page https://wiki.debian.org/Python/Python3.8 says to do this if 2.7 and 3.8 need different upstream versions) Should be technically easy, but means going through NEW. ... a statement that once pandas 0.25 works, this is no longer my problem, i.e. that I don't have to fix 0.23? I don't think that's necessary at this point. matplotlib and pandas don't have Python2 packages in Ubuntu anymore, so I can't tell much what is needed here matplotlib has already been split into Python 2 and Python 3 source packages. (matplotlib2 is in Ubuntu, and unbuildable there due to #943924.) Python2 matplotlib are already removed in Ubuntu, I shouldn't have synced matplotlib2 from experimental. According to its Ubuntu build log: https://launchpad.net/ubuntu/+source/matplotlib/3.0.2-2ubuntu1/+build/17942804 matplotlib has one python3.8-specific test failure, test_axes.py::test_pathological_hexbin. This is currently being ignored (#942766) along with (many) errors that also happen on 3.7.
Bug#944459: please run abigail on library packages before they are allowed to transition
Package: release.debian.org
Severity: wishlist
User: release.debian@packages.debian.org
Usertags: britney
Library packages still have ABI differences despite the best effort to track
them, and often migrate undetected. Reasons for that might be
- No symbols files provided in the package.
- No easy way to write a symbols file for C++, and unable
to differentiate between real issues and artifacts due to
compiler changes.
- Intentionally ignored ABI changes ("it's not part of the ABI")
A first step could be to just run abigail on such packages, report issues but
not block on those, to get an idea for possible issues.
An alternative could be to add abigail support to the packaging, as an
alternative to symbols files. That would either require a new packaging helper
dh_abigail, or integration into dpkg/debhelper. But maybe this isn't just an
alternative, but a separate step.
Bug#944458: britney doesn't run autopkg tests for binNMUs
Package: release.debian.org Severity: important User: release.debian@packages.debian.org Usertags: britney britney doesn't run autopkg tests for binNMUs. E.g. for a library transition, britney only runs the tests triggered by the library package, it doesn't run the autopkg tests for all the packages built with the new library version. Things known not to be catched are at least: * A library rebuild causes an ABI change in another library. E.g. when boost is rebuilt with a new version of icu, it changes ABI (that seems to be not the case in recent boost versions). However this kind of thing is currently not detected. * binNMUs picking up unrelated changes, and failing. E.g. dh-python now generates dependencies on python2 instead of python, but the autopkg tests still call python.
Bug#942106: Adding Python 3.8 as a supported Python3 version
This weekend, I am planning to upload python3-defaults, adding python3.8 as a supported Python3 version. This may introduce some churn in unstable until the basic binNMUs are available as well. Details for the addition can be found at [1], known issues and patches are filed [2]. There was no test rebuild in Debian itself, but the addition was made in the current Ubuntu development series. Things look good, and from my point of view don't block any unrelated transition work. python3-defaults will get a RC issue to stay in unstable until the packages build-depending on python3-all-dev are built, and after doing a test rebuild with the two supported Python3 versions. Earlier test rebuilds don't make sense. There are a few packages, where the upstream versions used in Ubuntu diverge from the ones currently in unstable (not naming those already updated in unstable by the DPMT): - hypothesis #942693, not sure if this is really needed, the testsuite stack might be fixed by the new pluggy version as well. - python-xarray #944044. 1.4 is already broken with Python 3.7. For Ubuntu I fell back to 1.2.1. 1.2.3 might work as well, still seeing one or two test failures. - Using numpy from experimental, and only building the Python2 numpy packages from the python-numpy source. - Using python-scipy from experimental, building the Python3 packages, and renaming the python-scipy package to python2-scipy, only building the Python2 packages. - matplotlib and pandas don't have Python2 packages in Ubuntu anymore, so I can't tell much what is needed here. Pandas needs a new upstream for 3.8. Packages building on top of numpy/scipy/pandas, like the PyAstro stack, continue to work with these updates, despite some new test failures. Matthias [1] https://wiki.debian.org/Python/Python3.8. [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.8;users=debian-pyt...@lists.debian.org
Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
>> And afaik there was no test rebuild for bullseye >> either. > > It does not help to blame people for not doing a rebuild when there is no rebuild necessary. Please could you turn off your mode feeling attacked by any email, before you understood these? On 31.10.19 15:33, rene.engelh...@mailbox.org wrote: Hi, Am 31. Oktober 2019 15:15:10 MEZ schrieb Matthias Klose : And afaik there was no test rebuild for bullseye either. Accepted cppunit 1.14.0-4 (source) into unstable On July 26: https://tracker.debian.org/news/1049803/accepted-cppunit-1140-4-source-into-unstable/ Buster release was 3 weeks before that. So this "no test rebuild for bullseye" is not true. bullseye didn't see any test rebuild of the archive, and filing of FTBFS bugs yet.
Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
On 29.10.19 15:09, Vincent Lefevre wrote: On 2019-10-29 13:09:46 +0100, rene.engelh...@mailbox.org wrote: Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre : In case makefile magic triggers some rebuild, you can also run the generated executable directly (with the right environment variables, in case this matters). If the programs honors the system ABI, this is allowed, and you'll effectively test the new libstdc++6. No, if the rebuild rebuilds cppunittester or one of the exceptionprotectors or the smoketest so or similar we are at the same situation as with the autopkgtest (that's what it builds) and are not sure whether it's g++-9 or libstdc++6. Neither LO nor the test are an executable it's a executable with gazillions of .sos. I meant running the generated program (smoketest) without rebuilding it: 1. Build smoketest with the old g++-9 / libstdc++6. 2. Upgrade g++-9 / libstdc++6. 3. Run smoketest directly. (I assume that the smoketest executable does not invoke g++-9 to rebuild things on the fly.) I'm not sure if Rene wants to help tracking this down, he just disabled running the test in https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/99764f8d0df2f40aba9a220a8a4858d3f6d05494 and introducing a typo in https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/998c3b1c63bbedf8d886227749279d7ccb26a30b So maybe don't commit if you are angry. <_rene_> how supported is clang on the various (release) archs? <_rene_> completely? <_rene_> (clang++ if it matters) <_rene_> (actually probably only matters for amd64/arm64 for now, but...) so I assume we cannot expect Rene's help for that issue anymore. The comment about cppunit made me look at the cppunit package to find #935902, and yes, the test case is reproducible. So looking at the test failure would have been revealed that the test frame work is broken, not a single test. This turned out to be https://gcc.gnu.org/PR92267, causing an ABI breakage in cppunit. The fix is now in -16. So a symbols file and a test rebuild should have at least flagged something, however cppunit doesn't have symbols files, because the package maintainer doesn't like them. And afaik there was no test rebuild for bullseye either. The upstream issue was introduced in May, I don't know why it's only seen now.
Re: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
On 28.10.19 22:17, Paul Gevers wrote: Dear all, The visible progress on this bug report stopped several days ago. I'd like to try an get it a bit further. I'm expecting frustration on all sides, yes, and side note that I will use the same terms of "several days ago" for a three day silence including two non-work days. but let's try to work together to fix the current situation. my moreinfo tag was removed, and I'm not interested in a bts war, which rene likes to start very often. and, no, I won't start citing rene's private messages here. Matthias, did you have time to look into the issue? Have you discovered anything that is worth knowing already? If not, do you intent to work on this soon. I noticed you uploaded a new version that doesn't address this RC bug, for the reason I mentioned above, could you please refrain from uploading new versions unless critical issues that aren't present in testing are fixed in those uploads until a version of gcc-9 migrates? I asked for a test case, not a multi-hour build and a multi-hour test run. Sure I can start looking at this myself, but I don't have the LO domain knowledge anymore. Yes, I could start bisecting, however that doesn't sound very effective. My main effort however now is to restore native and cross builds, an issue I didn't cause myself and I'd like to see fixed. Matthias
Bug#942106: (some kind of) transition: add python3.8 as a supported python3 version
On 26.10.19 22:09, Rebecca N. Palmer wrote: What should be done with modules where Python 3.8 compatibility requires moving to a new upstream release that doesn't support Python 2, but the Python 2 package still has dependencies (so can't be removed yet under existing rules)? - Split them into two source packages with different upstream versions, as was done for matplotlib and numpy? - Remove the Python 2 package anyway? - Let them be broken in Python 3.8 for now? e.g. pandas dropped python2 support in 0.25.0, and gained python3.8 support in 0.25.2: https://github.com/pandas-dev/pandas/issues/29043 yes, that will be an ongoing problem, I see the same for pillow (latest 2.7 supporting release is 6.2.1) and numpy (1.16 not supporting 3.8, and 1.17 not supporting 2.7). Ubuntu got pandas 0.23 to build with python3.8, but only by ignoring 268 test failures (I haven't yet had time to assess their severity): https://bugs.launchpad.net/ubuntu/+source/pandas/+bug/1849374 https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/p/pandas/20191024_181815_7c017@/log.gz yes, https://bugs.launchpad.net/bugs/1849374 documents where I ignored test results for a first build, and numpy test results are ignored as well due to a packaging bug. Ubuntu already dropped python-pandas, I wasn't involved with that. So this should be possible to do. Please ask Steve Langasek for details. In the case for pandas it should be possible to remove it now with some work, avoiding a second Pandas source. Having a first build in the archive allows you to get more packages built, and more people working on the stack. For example the whole astropy stack builds and passes tests (except astropy itself). So there is value. Lets enable to build stuff first for 3.8 as a supported non-default option.
Bug#942106: (some kind of) transition: add python3.8 as a supported python3 version
On 11.10.19 18:46, Paul Gevers wrote: Hi Matthias, On 10-10-2019 15:06, Matthias Klose wrote: Please setup a tracker to add python3.8 as a supported python3 version. This is non-blocking, as packages can migrate on their own once built. I'm not yet starting this, just want to have an overview of affected packages. Please could you re-use the final version of the python3.7 tracker, which had several iterations in #902582? Done. Will appear slightly after 17:30 UTC if I didn't make any mistake. I'm now ready to upload python3-defaults to unstable and would like to proceed on Saturday. Ideally that should be followed by binNMUs, so that we don't end up with too much infrastructure like broken python test frameworks. Matthias
Re: Bug#943401: libreoffice: Autopkgtests are failing since 2019-10-21
On 25.10.19 18:09, Rene Engelhard wrote: Hi, On Fri, Oct 25, 2019 at 05:59:53PM +0200, Rene Engelhard wrote: OK, thanks, reassigning to src:gcc-9 (libstdc++6 for now) then. no. based on what rationale? And to prevent said gcc-9 version from migrating, to not break something else (no idea whether it does, but..). The Release Team asked me exactly this: to reassign the bug to gcc-9. base on what rationale? > As can be seen on [1], the autopkgtests started failing this Monday and > succeeded only once since then. At this time, there was no new gcc-9 in the archive, -9 was on the archive on Oct 8, -10 and -11 are ftbfs, and -12 was uploaded on Oct 23, but you say that the tests started failing on Oct 21. So why do you think this is related to gcc-9?
Bug#942106: (some kind of) transition: add python3.8 as a supported python3 version
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Please setup a tracker to add python3.8 as a supported python3 version. This is non-blocking, as packages can migrate on their own once built. I'm not yet starting this, just want to have an overview of affected packages. Please could you re-use the final version of the python3.7 tracker, which had several iterations in #902582?
Bug#942095: nmu: rebuild packages for binutils 2.33
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please binNMU these packages for the binutils 2.33 upload to unstable: naev 0.7.0-2 wcc 0.0.2+dfsg-3 (amd64 only) looking-glass 0+b1-1 kcov 36+dfsg-1 also, binutils-mingw64 might need a sourceful upload.
Re: Bug#941263: gcc-9: ICE in mips_split_move when compiling qtwebengine-opensource-src on mipsel
On 27.09.19 12:48, Dmitry Shachnev wrote: It looks like it is already fixed upstream: https://gcc.gnu.org/viewcvs/gcc?view=revision=273174 So please backport that change to the Debian package. The Debian MIPS maintainers should get this backported upstream, then it get's updated in the package. Matthias
Bug#940004: nmu: isl
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please binNMU these packages for the recent isl upload to unstable: that only affects various gcc packages. the native and cross compilers are uploaded, the -mipsen packages are in unstable only, and stuck in NEW, the remaining one is gcc-mingw-w64 Pinged the maintainer too.
