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.
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#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#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#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#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#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#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#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#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).
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#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#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#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#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
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.
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#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.
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#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#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/pa
Bug#928185: unblock: openjdk-11/11.0.3+7-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock openjdk-11/11.0.3+7-4. That's the quarterly security update and should be released with buster. No more updates planned until the next security update in July.
Bug#928186: unblock: gcc-7/7.4.0-9
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock: gcc-7/7.4.0-9, some packaging and upstream backports to around the state of the GCC 9.1 release. If we ship gcc-7, please consider shipping -9 instead of -6. The removal of gcc-7 for buster is still blocked by the new cuda version stuck in NEW. But then, Steve Mcintyre asked for a stable GCC version to build the shim packages for buster, so maybe include the package in buster anyway.
Bug#928188: unblock gcc-8/8.3.0-7 and updated cross builds
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock gcc-8/8.3.0-7 and updated cross builds. This includes upstream backports to around the date of the GCC 9.1 release. this includes gcc-8/8.3.0-7 gcc-8-cross/28 gcc-8-cross-ports/21 gcc-8-cross-mipsen/2~c3 please also unblock gcc-defaults-ports/1.182 fixing a dangling doc dir symlink for the x32 cross compilers.
Bug#928185: unblock: openjdk-11/11.0.3+7-4
Control: tags -1 - moreinfo Control: tags -1 + wontfix On 02.05.19 10:30, Julien Cristau wrote: > Control: tag -1 moreinfo > > Hi Matthias, > > On Mon, Apr 29, 2019 at 06:12:36PM +0200, Matthias Klose wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> >> Please unblock openjdk-11/11.0.3+7-4. That's the quarterly security update >> and >> should be released with buster. No more updates planned until the next >> security >> update in July. > > From what I understand bug#926009 is a regression in that version. > There's no explanation that I can see for that change, no associated > bug, and it doesn't look appropriate. Please revert it. No. The issue is in the LibreOffice package, which already has this fixed in testing. The openjdk package also has an appropriate Breaks.
Bug#928185: unblock: openjdk-11/11.0.3+7-4
Control: tag -1 - moreinfo On 02.05.19 10:30, Julien Cristau wrote: > Control: tag -1 moreinfo > > Hi Matthias, > > On Mon, Apr 29, 2019 at 06:12:36PM +0200, Matthias Klose wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> >> Please unblock openjdk-11/11.0.3+7-4. That's the quarterly security update >> and >> should be released with buster. No more updates planned until the next >> security >> update in July. > > From what I understand bug#926009 is a regression in that version. > There's no explanation that I can see for that change, no associated > bug, and it doesn't look appropriate. Please revert it. No. With the change of ownership of the upstream jdk11-updates project, you see that the patches applied to the Oracle builds and to the OpenJDK builds differ, and the OpenJDK maintainers need to track issues based on tags in the issue tracker and backport these changes themself. The LibreOffice packages are fixed, the gradle tests are not used. Other vendors also ship OpenJDK with other vendor settings. This is a minor change, and we had far more disruptive updates in OpenJDK 11 itself like many late changes for documentation building. I will continue to update the packages to the next security release which is expected in July. If that's too late for the release, these will most likely be handled by the security team. Matthias
Bug#926778: unblock: python3.7 3.7.3 packages
On 11.05.19 18:56, Paul Gevers wrote: > Control: tags -1 moreinfo > > Hi doko, > > On Wed, 10 Apr 2019 10:23:15 +0200 Matthias Klose wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> >> Please unblock python3.7, python3-stdlib-extensions and python3-defaults, >> bumping the version to the final 3.7.3 release, and fixing a bus error on >> armhf, >> and avoiding unaligned memory accesses on arm64. > > This looks mostly OK (albeit a new upstream release, which we try to > avoid unblocking), The update beyond 3.7.2 with the goal of 3.7.3 was communicated and approved by Emilio (pochu) even before doing the first upload from the 3.7 branch to unstable. Please let me know if there is anything I can do to avoid confusion for future uploads. > except you didn't document nor mentioned the g++-8 g++-8 is the default g++, so this really is a no-change. > B-D change the locales change. Can you explain why that was done? to be able to cross-build. That is a no-change for the native-build. > These > kind of changes are not in line with the freeze policy unless they fix > serious issues. On top of that, (my python skills aren't that great), is > the change in platform-lsbrelease.diff really required, or just more robust? it silences a warning at runtime. > Please make sure that during the release, you document *all* packaging > changes in the changelog and if needed, elaborate in the unblock request. will do for future uploads. Matthias
Bug#929637: unblock: cross-toolchain-base{,-ports,-mipsen} - rebuilt using glibc 2.28-10
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock please unblock the three cross-toolchain-base* packages, rebuilt using glibc 2.28-10, which was already accepted for testing. cross-toolchain-base 35 cross-toolchain-base-ports 29 cross-toolchain-base-mipsen 4
Bug#928185: unblock: openjdk-11/11.0.3+7-4
On 29.05.19 00:23, Sam Hartman wrote: >> "Emmanuel" == Emmanuel Bourg writes: > > I'm not on the release team and cannot authorize a TPU. > > > As an interested bystander I'd ask that you make sure any TPU contains a > fix for the serious accessibility issue in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900912 no. this fix comes very late, and enabling accessibility feature broke the normal operation in the past. The packages in unstable have a fix which needs manual enabling, certainly not ideal, but safe to release. So please only backport this fix which is disabled by default. Matthias
Bug#928185: unblock: openjdk-11/11.0.3+7-4
On 12.06.19 20:38, Paul Gevers wrote: > Hi Matthias, > > On 12-06-2019 10:33, Emmanuel Bourg wrote: >> I talked to Matthias on IRC yesterday, he was ok with the +really >> version in unstable only as a testbed for a tpu upload with a sane version. > > Can you explain why, please? because we had so much fun with rants about versioning questions for OpenJDK. Just avoiding that would be nice.
Bug#928185: unblock: openjdk-11/11.0.3+7-4
On 12.06.19 00:37, Moritz Mühlenhoff wrote: > On Mon, Jun 10, 2019 at 09:46:41PM -0700, tony mancill wrote: >> I am not a member of the OpenJDK team and contributed far less to the >> JDK 8 -> 11 transition than Emmanuel has. If he and Matthias are in >> agreement and the plan is palatable to the Release and Security Teams, >> that's ideal. > > I don't have any preference either, just adding my 2 cents here; with > our buster release set to 6th of July and the next Oracle CPU set for > July 16, we'll ship a non-GA release of Java for maybe two, at most three > weeks (as buster-security will rebase to the next openjdk-11 following > the CPU). I'm also fairly sure we've shipped non-GA releases for openjdk-8 > before? yes, until reccently we didn't have any source releases, so I prepared packages from the last tag leading to the GA release, and then we applied the security patches on top of that. Matthias
Bug#928185: unblock: openjdk-11/11.0.3+7-4
On 19.06.19 22:03, Paul Gevers wrote: > Hi Tony, > > On 18-06-2019 22:14, tony mancill wrote: >> Things are looking good so far with 11.0.4+4+really11.0.3+7 in unstable, >> and so I would like to prepare the t-p-u upload. At the moment, the >> version I have is 11.0.3+7-5, since that would have been the "next" >> 11.0.3+7 Debian revision for unstable. The 11.0.3+7 orig.tar.xz already >> in the archive is the same one used for the "really" to unstable and >> this build, and this versioning makes it clear to users what they are >> getting. The resulting changelog would be: >> >>> diff -Nru openjdk-11-11.0.4+4+really11.0.3+7/debian/changelog >>> openjdk-11-11.0.3+7/debian/changelog >>> --- openjdk-11-11.0.4+4+really11.0.3+7/debian/changelog 2019-06-14 >>> 12:28:25.0 -0700 >>> +++ openjdk-11-11.0.3+7/debian/changelog2019-06-16 11:24:19.0 >>> -0700 >>> @@ -1,3 +1,10 @@ >>> +openjdk-11 (11.0.3+7-5) buster; urgency=medium >>> + >>> + * Team upload. >>> + * Upload 11.0.4+4+realy11.0.3+7-2 to buster t-p-u. >>> + >>> + -- tony mancill Sun, 16 Jun 2019 11:24:19 -0700 >> >> Is this acceptable to the Release Team? If not, (and I know there have >> been some differing opinions), how shall we version the t-p-u package? > > I think the most logical version would be 11.0.3+7-4+deb10u1, as this is > a targeted upload to buster. let's use a version which also can be nicely used for the backports upload. > I don't have a strong opinion on it. I > still don't like it we go via tpu but I understand the ranting argument. this will be very short-lived until the final 11.0.4 release to be uploaded into security. > Let's end this saga. please do.
Bug#929637: unblock: cross-toolchain-base{,-ports,-mipsen} - rebuilt using glibc 2.28-10
Control: tags -1 - moreinfo On 09.06.19 21:58, Paul Gevers wrote: > Control: tags -1 moreinfo > > Hi Matthias, > > On Mon, 27 May 2019 20:32:48 +0200 Matthias Klose wrote: >> please unblock the three cross-toolchain-base* packages, rebuilt using glibc >> 2.28-10, which was already accepted for testing. >> >> cross-toolchain-base 35 >> cross-toolchain-base-ports 29 >> cross-toolchain-base-mipsen 4 > > Why would such a rebuild be needed for buster? Does it fix any important > or release critical bug? Sorry if this is obvious to you, but it isn't > to me. The packages don't contain any source itself, just b-d on various source packages. #928404 has the rationale for the glibc updates. So the same rationale should be applied for these packages as for the glibc approval. There seems to be room for improvement in tracking/updating packages which have a Built-Using attribute, which is older than the version in testing. Matthias
Bug#926780: unblock gcc-8/8.3.0-7 and updated cross builds
Control: tags -1 - wontfix Control: reopen -1 On 20.06.19 13:54, Paul Gevers wrote: > Control: tags -1 wontfix > Control: close -1 > > Hi Matthias, > > On 06-06-2019 12:01, Paul Gevers wrote:> doko, I know you are > maintaining quite some key packages, so extra work> is probably not what > you are looking for, but neither are we and on top> of that, we don't > like turning down unblock request (hence the time it> took to reply, at > least that's the reason for me). In this case, and> also for gcc-7 > (hence cc of that bug) it would be great if we could> understand from > the beginning why you believe why we should except this.> And no, I am > not going to find upstream repositories and bug trackers> for all the > packages that we get unblock requests for. You'll have to> help us > making the judgment. > I take the lack of reply from your side to mean that you are not > pursuing to drive this further to an unblock. To clean up the unblock > that probably will not see any further action, I am closing it as > wontfix. If you are still interested, you can of course reopen, but be > aware that the time for unblocks for buster is running out quickly now [1]. well, this has a bad smell. First not replying for a month, then turning it down after not even a week. Apologies for not immediately replying to your email. Here are the list of changes for gcc-8. Most of them regressions found during the development of GCC 9, and backported. These come with test cases in the GCC testsuite, and the added tests pass. From my point of view it's safe to ship these in buster. The changes in detail are: PR target/89877 (ARC), target not affecting Debain PR target/84369 (PPC), fix test on POWER9 PR tree-optimization/85762, wrong code regression in GCC 8 PR tree-optimization/87008, missed optimization, regression in GCC 8 PR tree-optimization/85459, missed optimization, regression in GCC 8 PR target/87532 (PPC), wrong code fixes, not marked as regression PR ipa/89693, ICE on valid code, regression in GCC 9, backported to 8 PR middle-end/88587, ICE on valid code, backported to 8 PR tree-optimization/90018, x86 AVX512, wrong code, regression in GCC 7/8 PR target/90024 (ARM), ICE on valid code on ARM32, regression in 7/8 PR target/89945 (ARM), ICE on valid code, regression in 7/8/9 PR fortran/87352, compile-time-hog, memory-hog, regression in 7/8/9/10 PR fortran/89981, rejects valid code, regresion in GCC 8 PR fortran/89904, ICE on valid code, regression in GCC 9, backported to 8 PR libgfortran/79540, test failure, regression in 7/8 (PARISC only?) PR fortran/87127, rejects valid code, not marked as regression PR rtl-optimization/87979, ICE on valid code, not marked as a regression PR rtl-optimization/84032. ICE on valid code, not marked as a regression Non-upstream patches: * Fix PR c++/90050, always link with libstdc++fs.a. LP: #1824721. Not really needed for buster, has only effect with GCC 9 installed. * Fix PR bootstrap/87338 on ia64 (James Clarke). Closes: #927976. Fixes the build on ia64. Now upstreamed as well. There are no changes for the cross packages. They are rebuilt for this gcc-8 upload. Currently we don't have matching native and cross compilers in buster. Matthias
Bug#931629: nmu: rebuild packages for binutils 2.32.51.x
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please binNUM these packages for the recent binutils upload to unstable: boinc-app-eah-brp 0.20170426+dfsg-10 naev 0.7.0-2 tulip 4.8.0dfsg-2 wcc 0.0.2+dfsg-3 (amd64 only)
Re: Bits from the Release Team: ride like the wind, Bullseye!
> No binary maintainer uploads for bullseye > = > > The release of buster also means the bullseye release cycle is about to begin. > From now on, we will no longer allow binaries uploaded by maintainers to > migrate to testing. This means that you will need to do source-only uploads if > you want them to reach bullseye. [...] > Q: I needed to do a binary upload because my upload went to the NEW queue, > do I need to do a new (source-only) upload for it to reach bullseye? > A: Yes. We also suggest going through NEW in experimental instead of > unstable > where possible, to avoid disruption in unstable. I think this is bad advice, because with long running builds, you'll get stuck in NEW twice, once doing the upload in experimental, and then doing the source only upload to unstable, because your binary packages got already removed, and the builds from the buildds land in NEW again. So if you want to enforce that, it would be better to avoid that extra work on the FTP team, and the package uploaders. Matthias
Bug#931659: transition: rm python2
On 09.07.19 00:31, Scott Kitterman wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > The Debian Python teams are working to push early for reduction/removal > of our python(2) packages with the goal of releasing bullseye with > python3 only. To clarify, python2 removal is much appreciated, however if we need to ship it for some applications, we will do that. There is no such goal yet for bullseye.
Bug#931659: transition: rm python2
On 09.07.19 00:31, Scott Kitterman wrote: > Ben file: > > title = "python-defaults"; > is_affected = .depends ~ > /python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg/ > | .depends ~ "''"; > is_good = .depends ~ "''"; > is_bad = .depends ~ > /python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg/; this is missing all cases where python2 is only used for the build, and doesn't end up in any python/python2 dependency. So realistically, check for python and python2 in B-D's as well.
Bug#931629: nmu: rebuild packages for binutils 2.32.51.x
On 15.07.19 16:36, Paul Gevers wrote: > Hi Matthias, > > On 08-07-2019 14:57, Matthias Klose wrote: >> Please binNUM these packages for the recent binutils upload to unstable: >> >> boinc-app-eah-brp 0.20170426+dfsg-10 >> naev 0.7.0-2 >> tulip 4.8.0dfsg-2 >> wcc 0.0.2+dfsg-3 (amd64 only) > > boinc-app-eah-brp can't be rebuild (#887880). > tulip can't be rebuild (#853688, filed by you). > > binNMU'ed wcc and naev. > > Thanks. > > Just one request, can you enlighten me as to where these strict > dependencies on libutils come from? because of potential incompatibilities with new upstream versions, such that binutils itself ftbfs when the soname is not bumped. Note that binutils doesn't provide a stable ABI and API for the shared libs, therefore the recommendation to statically link with those libs if you need to.
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#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
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#919641: transition: readline (7 -> 8)
On 26.07.19 20:17, Jonathan Wiltshire wrote: > Control: tag -1 pending > > On Fri, Jan 18, 2019 at 08:45:38AM +0100, Matthias Klose wrote: >> readline is in experimental for some time, the changes are API compatible, >> and >> afaics there are no build failures caused by readline. I filed some RC issues >> for unrelated ftbfs. >> >> A handful of packages need sourceful uploads, like d-shlibs and >> readline-perl6. > > I think all feasible rebuilds are done or look like they will succeed; > we're left with: > > argus-clients > bareos > iverilog > libvirt > monero > sagemath > yap > > Can I leave bugs for those with you? I checked that any of these ftbfs for different reasons, and filed RC issues for those that didn't already have RC reports.
Same procedure as every year: GCC defaults change (GCC 9)
GCC 9 was released earlier this year, it is now available in Debian testing/unstable. I am planning to do the defaults change in mid August, around the time of the expected first GCC 9 point release (9.2.0). There are only soname changes for rather unused shared libraries (libgo) involved, and the gnat defaults change will be handled separately by the Debian Ada maintainers. The fortran module changes look ok according to Alastair McKinstry. The gcc-9 package still ftbfs on kfreebsd-*. We still have local patches for at least the various mips, kfreebsd and hurd targets. Please forward these upstream and make sure that these are applied upstream. powerpcspe support is removed upstream. I will keep pointing the default to GCC 8 for this target. Matthias
Bug#934967: nmu: rebuild packages for binutils 2.32.51.x
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please binNUM these packages for the recent binutils upload to unstable: naev 0.7.0-2 wcc 0.0.2+dfsg-3 (amd64 only)
Bug#934967: nmu: rebuild packages for binutils 2.32.51.x
On 17.08.19 15:32, Matthias Klose wrote: > Please binNUM these packages for the recent binutils upload to unstable: > > naev 0.7.0-2 > wcc 0.0.2+dfsg-3 (amd64 only) looking-glass 0+b1-1 is needed too.
Re: Dropping mips architecture for bullseye and sid
On 20.08.19 15:17, Aurelien Jarno wrote: > Dear release team, > > On 2019-07-20 12:46, Aurelien Jarno wrote: >> Dear all, >> >> The mips architecture, supporting 32-bit big-endian MIPS CPUs, has >> been supported in Debian for more than 15 years. Due to the limited 2GB >> virtual address space and due to the fact this architecture is one of >> the last big-endian architecture Debian supports, the porting effort >> is increasingly difficult. On the other hand the interest for this >> architecture is going down, and with it the human resources available >> for porting is going down. >> >> Now that buster has been released, it is probably time to drop this >> architecture from bullseye and sid. Unless there is a sudden interest >> for this architecture, that is commitment from some new porters and new >> hardware for the build daemons, the plan is to ask for the ftpmasters >> to drop this architecture in about 4 weeks. > > This has now been one month, and nobody volunteered to help. Therefore > it's time to drop the "mips" architecture. From what I understood the > first step of the removal is to get rid of it in testing. Could you > please take care of that? > > Once it's done, I'll forward the request to ftpmasters. what's the plan for mips, keep it in ports, or remove it completely? what's the plan with mipsel?
Bug#931659: transition: rm python2
On 09.07.19 17:50, Matthias Klose wrote: > On 09.07.19 00:31, Scott Kitterman wrote: could somebody fix the py2-removal tracker again? replacing the terminating \b chars with \s (4 times)? currently it matches all python-* (python-gi-dev, python-*-doc, ...) I think we are better with a smaller set this removes around 2000 matches, and obviously is missing some dependencies, but the current tracker has too many false positives. Or we create another tracker with this change. Interesting thing found: python-gi-dev depends on both python2 and 3 packages ...
Re: [Cross-toolchain-base-devs] Testing migration of linux
On 23.08.19 17:41, Ben Hutchings wrote: > We now have a version of linux (5.2.9-2) that builds on all release > architectures and doesn't seem to cause build regressions for other > packages. I think that this should migrate to testing soon, as the > version in testing is missing important security fixes. > > I'm aware of autopkgtest regressions for two packages: > > * cross-toolchain-base 36: This appears to be a bug in that version of > the package. cross-toolchain-base version 39 seems to be compatible > with Linux 5.2 and would need to migrate at the same time. > > * glibc 2.28-10: This is a minor regression in the kernel uAPI headers, > which could *possibly* lead to build failures if programs define > conflicting macros. (I fixed the larger regression which did cause > build failures.) glibc 2.29 as packaged in experimental will stop > using these uAPI headers. > > The excuses file mentions "new bug" #934483, but that was a bug in > virtualbox-guest-dkms which has now been fixed. virtualbox is not in > testing. > > So these packages should migrate to testing together: > > cross-toolchain-base 39 > linux 5.2.9-2 > linux-latest 106 > linux-signed-amd64 5.2.9+2 > linux-signed-arm64 5.2.9+2 > linux-signed-i386 5.2.9+2 > > cross-toolchain-base seems to be dependent on these packages, which > also inter-depend on each other, so that they'll also need to migrate > at the same time: > > binutils > gcc-8 > gcc-9-cross-ports > gcc-defaults-ports due to the removal of the mips packages, binutils, cross-toolchain-base, gcc-8-cross, gcc-9-cross and gcc-defaults need to migrate together. The combination of linux-libc-dev (<< 5.2) and linux-libc-dev (>= 5.2) leads to build failures for some cross compilers, so all the -ports packages should migrate as well. Blockers: https://piuparts.debian.org/sid/source/g/gcc-9-cross.html why? Matthias
Bug#931659: transition: rm python2
On 21.08.19 21:40, Matthias Klose wrote: > On 09.07.19 17:50, Matthias Klose wrote: >> On 09.07.19 00:31, Scott Kitterman wrote: > > could somebody fix the py2-removal tracker again? replacing the terminating \b > chars with \s (4 times)? currently it matches all python-* (python-gi-dev, > python-*-doc, ...) I think we are better with a smaller set that was too much, now not matching a package name followed by a comma. attaching the two lines, and using [\s,] for the delimiter. > this removes around 2000 matches, and obviously is missing some dependencies, > but the current tracker has too many false positives. Or we create another > tracker with this change. > > Interesting thing found: python-gi-dev depends on both python2 and 3 packages > ... is_affected = .depends ~ /\s(python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg)[\s,]/ | .build-depends ~ /\s(python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg)[\s,]/; is_bad = .depends ~ /\s(python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg)[\s,]/ | .build-depends ~ /\s(python|python-minimal|python-dev|libpython-dev|libpython-stdlib|python-doc|python-dbg|libpython-dbg|python-all|python-all-dev|python-all-dbg|libpython-all-dev|libpython-all-dbg|python2|python2-minimal|python2-dev|libpython2-dev|libpython2-stdlib|python2-doc|python2-dbg|libpython2-dbg|python2.7|libpython2.7-stdlib|python2.7-minimal|libpython2.7-minimal|libpython2.7|python2.7-examples|python2.7-dev|libpython2.7-dev|libpython2.7-testsuite|idle-python2.7|python2.7-doc|python2.7-dbg|libpython2.7-dbg)[\s,]/;
Bug#939048: transition: glibc
On 31.08.19 16:12, Aurelien Jarno wrote: - gcc-9 - gcc-snapshot I'll take care of these with regular uploads.
stop building the mipsel and mips64el cross compilers
Hi, I will stop building the mipsel and mips64el cross packages from the binutils, gcc-8-cross, gcc-9-cross, gcc-defaults, cross-toolchain-base packages. There is infrastructure to build these cross compilers from the binutils-mipsen, gcc-8-cross-mipsen, gcc-9-cross-mipsen, gcc-defaults-mipsen and cross-toolchain-base-mipsen packages, so anybody interested in these can build these from the set of source packages instead. To ease the transition and avoid NEW processing, I will wait until September 15 to disable building these packages. So please prepare to build these packages from the -mipsen source packages. Thanks, Matthias
Re: stop building the mipsel and mips64el cross compilers
On 05.09.19 11:41, YunQiang Su wrote: Matthias Klose 于2019年9月4日周三 下午1:46写道： Hi, I will stop building the mipsel and mips64el cross packages from the binutils, gcc-8-cross, gcc-9-cross, gcc-defaults, cross-toolchain-base packages. There is Thank you for your great work on cross toolchains. infrastructure to build these cross compilers from the binutils-mipsen, gcc-8-cross-mipsen, gcc-9-cross-mipsen, gcc-defaults-mipsen and cross-toolchain-base-mipsen packages, so anybody interested in these can build I will take care about these packages, and make them easy to binNMUed. c-t-b-mipsen cannot be nmu'ed, and the gcc-cross-* packges shouldn't be nmu'ed because the _all packages are not rebuilt. So it requires some activity ...
Bug#940003: nmu: rebuild packages for binutils 2.32.51.x
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please binNMU these packages for the recent binutils upload to unstable: naev 0.7.0-2 wcc 0.0.2+dfsg-3 (amd64 only) looking-glass 0+b1-1
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.
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&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#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.
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?
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
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
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.
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
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: 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.
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
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#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#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#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
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: 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: 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
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#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.
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#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#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#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#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#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#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: 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?
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#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
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#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
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
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
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 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?
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.
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 ...
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#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: 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
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.
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 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"
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: 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.
