Bug#1027044: transition: numpy 1.24.x
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: nu...@packages.debian.org, mo...@debian.org Control: affects -1 + src:numpy Resuming from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025788#43 In the meantime, since upstream released it, i've uploaded numpy/1.24.0 to experimental and the autopkgtest results are https://qa.debian.org/excuses.php?experimental=1=numpy now, there's a lot of red in there but almost all of the errors come in the format of AttributeError: module 'numpy' has no attribute 'X' with X being [float, int, bool, object, ...]. This is because, numpy upstream in 1.24.0, finally decided to expire https://numpy.org/doc/stable/release/1.24.0-notes.html#:~:text=The%20deprecation%20for%20the%20aliases some deprecations introduced in 1.20.0 https://numpy.org/doc/stable/release/1.20.0-notes.html#using-the-aliases-of-builtin-types-like-np-int-is-deprecated (released almost 2 years ago). All of those are quite straightforward to fix, since often it's just necessary to stop importing them from numpy and use the python native types. There are handful more errors in the form of: * ValueError: setting an array element with a sequence. The requested array has an inhomogeneous shape after 1 dimensions. The detected shape was (2,) + inhomogeneous part. * Too many indices for array: array is 0-dimensional, but 1 were indexed which will need to be looked at in more details, likely by individual projects upstream. This additional transition seems to be comfortably in the reach for Bullseye and will place us in a better position to get support from upstream. I also anticipate that a few more patch releases (fixing bugs etc) for the 1.24.x series will be published before Bullseye is released and we would like to update numpy to them in Debian if reasonable. Please let me know if i can proceed with a numpy upload to unstable. With ginggs' reply https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025788#48 Hi Sandro I should have closed this bug once numpy 1:1.23.5-2 migrated. Doing so now. Please file a new bug for discussing 1.24.0. On Mon, 26 Dec 2022 at 00:12, Sandro Tosi wrote: > In the meantime, since upstream released it, i've uploaded > numpy/1.24.0 to experimental and the autopkgtest results are > https://qa.debian.org/excuses.php?experimental=1=numpy > > now, there's a lot of red in there but almost all of the errors come > in the format of > > AttributeError: module 'numpy' has no attribute 'X' > > with X being [float, int, bool, object, ...]. > > This is because, numpy upstream in 1.24.0, finally decided to expire > https://numpy.org/doc/stable/release/1.24.0-notes.html#:~:text=The%20deprecation%20for%20the%20aliases > some deprecations introduced in 1.20.0 > https://numpy.org/doc/stable/release/1.20.0-notes.html#using-the-aliases-of-builtin-types-like-np-int-is-deprecated > (released almost 2 years ago). > > All of those are quite straightforward to fix, since often it's just > necessary to stop importing them from numpy and use the python native > types. That's a lot of breakage, but good that the fix is straightforward. > There are handful more errors in the form of: > > * ValueError: setting an array element with a sequence. The > requested array has an inhomogeneous shape after 1 dimensions. The > detected shape was (2,) + inhomogeneous part. > * Too many indices for array: array is 0-dimensional, but 1 were indexed > > which will need to be looked at in more details, likely by individual > projects upstream. The sooner these bugs are filed, the better. > This additional transition seems to be comfortably in the reach for > Bullseye and will place us in a better position to get support from > upstream. I also anticipate that a few more patch releases (fixing > bugs etc) for the 1.24.x series will be published before Bullseye is > released and we would like to update numpy to them in Debian if > reasonable. s/Bullseye/bookworm but agreed. > Please let me know if i can proceed with a numpy upload to unstable. Please let's wait for a bit on this one. There's still a matplotlib transition in flight (#1026119) that needs bugs filed and autopkgtests fixed before it can migrate. Let's aim to do this once the initial rebuilds for Python 3.11 as default (#1026825) have been done. In the meantime, it would help if bugs were filed against the packages that need updating for numpy 1.24.x.
Processed: transition: numpy 1.24.x
Processing control commands: > affects -1 + src:numpy Bug #1027044 [release.debian.org] transition: numpy 1.24.x Added indication that 1027044 affects src:numpy -- 1027044: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027044 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1024055: Upload MariaDB 1:10.3.37-0+deb10u1 ?
On Mon, 5 Dec 2022 at 01:18, Utkarsh Gupta wrote: > > Hi Otto, > > On Mon, Dec 5, 2022 at 5:33 AM Otto Kekäläinen wrote: > > I didn't get a reply to this, so asking again. > > I could take care of the upload but if you'd like to do that, please > feel free to do so and I can take care of the paperwork. One quick > thing I spotted in the target in d/ch is "buster". Could you please > change that to "buster-security" instead? > > Let me know if you'd like to upload yourself or want me to take care > of it. Thanks. Sorry for the late reply, but 10.3.37 does not include any CVE tracked security fixes (https://mariadb.com/kb/en/security/) so I guess it does not warrant a buster-*security* upload. I will just leave it at https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/buster as the base for importing 10.3.38 in January/February.
Bug#1025788: marked as done (transition: numpy)
Your message dated Mon, 26 Dec 2022 21:38:03 + with message-id and subject line Re: Bug#1025788: transition: numpy has caused the Debian Bug report #1025788, regarding transition: numpy to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1025788: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025788 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: nu...@packages.debian.org, mo...@debian.org Control: affects -1 + src:numpy Hello, i would like to request a transition slot for numpy. numpy/1.23.5 is in experimental, the autopkgtest for it are: https://qa.debian.org/excuses.php?experimental=1=numpy I gave a look at the failures and several of them are due to other reasons (uninstallable packages and the like), others may be attributed to python3.11 being added to unstable; issues related to the newer numpy are of the type AttributeError: module 'numpy' has no attribute 'asscalar' which has been removed after being deprecated for 7 releases: https://numpy.org/doc/1.22/reference/generated/numpy.asscalar.html Please let me know when i can upload numpy/1.23.5 to unstable. Thanks, Sandro --- End Message --- --- Begin Message --- Hi Sandro I should have closed this bug once numpy 1:1.23.5-2 migrated. Doing so now. Please file a new bug for discussing 1.24.0. On Mon, 26 Dec 2022 at 00:12, Sandro Tosi wrote: > In the meantime, since upstream released it, i've uploaded > numpy/1.24.0 to experimental and the autopkgtest results are > https://qa.debian.org/excuses.php?experimental=1=numpy > > now, there's a lot of red in there but almost all of the errors come > in the format of > > AttributeError: module 'numpy' has no attribute 'X' > > with X being [float, int, bool, object, ...]. > > This is because, numpy upstream in 1.24.0, finally decided to expire > https://numpy.org/doc/stable/release/1.24.0-notes.html#:~:text=The%20deprecation%20for%20the%20aliases > some deprecations introduced in 1.20.0 > https://numpy.org/doc/stable/release/1.20.0-notes.html#using-the-aliases-of-builtin-types-like-np-int-is-deprecated > (released almost 2 years ago). > > All of those are quite straightforward to fix, since often it's just > necessary to stop importing them from numpy and use the python native > types. That's a lot of breakage, but good that the fix is straightforward. > There are handful more errors in the form of: > > * ValueError: setting an array element with a sequence. The > requested array has an inhomogeneous shape after 1 dimensions. The > detected shape was (2,) + inhomogeneous part. > * Too many indices for array: array is 0-dimensional, but 1 were indexed > > which will need to be looked at in more details, likely by individual > projects upstream. The sooner these bugs are filed, the better. > This additional transition seems to be comfortably in the reach for > Bullseye and will place us in a better position to get support from > upstream. I also anticipate that a few more patch releases (fixing > bugs etc) for the 1.24.x series will be published before Bullseye is > released and we would like to update numpy to them in Debian if > reasonable. s/Bullseye/bookworm but agreed. > Please let me know if i can proceed with a numpy upload to unstable. Please let's wait for a bit on this one. There's still a matplotlib transition in flight (#1026119) that needs bugs filed and autopkgtests fixed before it can migrate. Let's aim to do this once the initial rebuilds for Python 3.11 as default (#1026825) have been done. In the meantime, it would help if bugs were filed against the packages that need updating for numpy 1.24.x. Regards Graham--- End Message ---
Re: Python 3.11 for bookworm?
Hi Matthias On Wed, 21 Dec 2022 at 18:24, Matthias Klose wrote: > while we have not an 100% agreement to go ahead, I think we should aim for > 3.11. Action speaks louder than words, and there's been a whole lot of work done to push this forward. > The following steps would be: > > - accept the current python3-defaults into > testing (adding 3.11 as supported) This has been done. > - ask for a transition slot to upload (see #1026825) > python3-defaults with 3.11 as the default We're currently waiting on the PHP 8.2 (#1014460) and qtbase-opensource-src (#1025863) transitions. Although, there's been no progress on PHP 8.2, so this may be reconsidered. qtbase-opensource-src is currently blocked on a pyqt5 FTBFS on mipsel (#1026980), but there is a possible workaround. We hope to be able to start with the remaining steps soon. > - 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. OK, good to know we can still back out if we have to. > 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. The release team is prepared to consider these on a case-by-case basis. Regards Graham
Re: Python 3.11 for bookworm?
Hi Timo, Stefano On Thu, 22 Dec 2022 at 18:46, Stefano Rivera wrote: > > Hi Timo (2022.12.22_12:56:20_+) > > > There have been rebuilds in Ubuntu that give us some idea of how much > > > work remains. I think it's tractable, but also will have some package > > > casualties. > > I have some spare time right now, and I am happy to help > > work on problematic cases, so hopefully nobody will feel left out in > > the cold with their favorite packages. > > Offhand, the one I most expect trouble with is numba. We were reliant on > upstream for the 3.10 transition, and probably will be for 3.11. > > Thanks for your help with pony ORM, Timo. I didn't think we'd be able to > port that without upstream, but it did end up being tractable. > > I'm expecting to have more time in the upcoming weeks, too. > > So, release team, I still think we should go ahead! Thanks for committing your time to this, and for the fixes you've already uploaded (and to everyone else who has helped). Please let the release team know if you need things unstuck. Regards Graham
Bug#1027033: transition: libsecp256k1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition libsecp256k1 has a SONAME bump in 0.2.0-1 (experimental). The only reverse dependency that needs a fix for the transition is electrum (already uploaded to experimental). The other reverse dependencies bitcoin and ring FTBFS currently due to other issues.
Processed: Re: Bug#1026392: transition: gnat-12
Processing control commands: > tags -1 confirmed Bug #1026392 [release.debian.org] transition: gnat-12 Added tag(s) confirmed. > forwarded -1 https://release.debian.org/transitions/html/gnat-12.html Bug #1026392 [release.debian.org] transition: gnat-12 Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/gnat-12.html'. -- 1026392: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026392 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1026392: transition: gnat-12
Control: tags -1 confirmed Control: forwarded -1 https://release.debian.org/transitions/html/gnat-12.html Hi Nicolas On 2022-12-23 14:19:36 +0100, Nicolas Boulenguez wrote: > > libgnatcoll-db succesfully built on mipsel in the meantime. > > Yes, I have uploaded a fixed version. > > > > - are removed from testing because of #1020018, > > > - are updated in experimental, but now > > > fail to build on a supported architecture. > > > I intend to > > > - fill RC bugs against them in order to prevent their migration from > > > unstable to to testing. > > Against libgmpada and libnatcoll-db or are there also others? > > This only applies to libgmpada and bug #1026828. Okay, then please go ahead with the transition. > > > - reupload them from experimental to unstable with the other packages > > > as part of the transition > > > (so that the versions depending on gnat-11 disappear from unstable) > > > (and so that RC-buggy but mostly usable versions are available) > > > - try to fix the issues after the transition is completed > > > Given the upcoming freeze, I'd suggest fixing those as soon as possible. > > I fear I don’t know what to do for libgmpada. The build fails > reproductibly on buildds but succeeds on the i386 porterbox. Architecture-specific removal could be an option. In any case, if libgmpada should be part of bookworm, it needs to migrate to testing before the start of the soft freeze in February. Cheers -- Sebastian Ramacher
Bug#1027022: marked as done (RM: puppet-beaker/4.30.0-2)
Your message dated Mon, 26 Dec 2022 16:47:18 +0100 with message-id <953e59c4-d3b3-e685-ecc4-9783248e4...@debian.org> and subject line Re: Bug#1027022: RM: puppet-beaker/4.30.0-2 has caused the Debian Bug report #1027022, regarding RM: puppet-beaker/4.30.0-2 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1027022: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027022 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove puppet-beaker from testing. It is orphaned, broken, outdated compared to upstream, and blocks the migration of ruby-net-scp (that's how I ran into it) I tried updating it to the latest upstream version but failed. Lucas --- End Message --- --- Begin Message --- Hi, On 26-12-2022 16:15, Lucas Nussbaum wrote: On 26/12/22 at 15:30 +0100, Paul Gevers wrote: I am mainly interested in restoring a clean state for ruby-net-scp (which cannot migrate without an update of puppet-beaker in testing, or a removal of puppet-beaker from testing). Someone with more interest in puppet-beaker than I have might be able to fix it, and then it could migrate again. So I'd rather keep it in unstable for now. Fair enough. autoremoval will remove it on 10 January (under normal circumstances). Can we wait until then? Yes, it can wait until Jan 10th (but then I need to remember to check that ruby-net-scp migrates after Jan 10th). A simple check showed no reverse (build) dependencies, so I've added a hint. Paul OpenPGP_signature Description: OpenPGP digital signature --- End Message ---
Bug#1027022: RM: puppet-beaker/4.30.0-2
On 26/12/22 at 15:30 +0100, Paul Gevers wrote: > Hi Lucas, > > On 26-12-2022 14:55, Lucas Nussbaum wrote: > > Please remove puppet-beaker from testing. > > Normally that's handled by requesting removal from unstable as removal there > is synced to testing. > > > It is orphaned, broken, outdated compared to upstream, and blocks the > > migration of ruby-net-scp (that's how I ran into it) > > Have you considered requesting removal from unstable? If not, why not? I am mainly interested in restoring a clean state for ruby-net-scp (which cannot migrate without an update of puppet-beaker in testing, or a removal of puppet-beaker from testing). Someone with more interest in puppet-beaker than I have might be able to fix it, and then it could migrate again. So I'd rather keep it in unstable for now. > autoremoval will remove it on 10 January (under normal circumstances). Can > we wait until then? Yes, it can wait until Jan 10th (but then I need to remember to check that ruby-net-scp migrates after Jan 10th). Lucas
Bug#1027022: RM: puppet-beaker/4.30.0-2
Hi Lucas, On 26-12-2022 14:55, Lucas Nussbaum wrote: Please remove puppet-beaker from testing. Normally that's handled by requesting removal from unstable as removal there is synced to testing. It is orphaned, broken, outdated compared to upstream, and blocks the migration of ruby-net-scp (that's how I ran into it) Have you considered requesting removal from unstable? If not, why not? autoremoval will remove it on 10 January (under normal circumstances). Can we wait until then? In other words, should this bug be reassigned to ftp.debian.org? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1027022: RM: puppet-beaker/4.30.0-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove puppet-beaker from testing. It is orphaned, broken, outdated compared to upstream, and blocks the migration of ruby-net-scp (that's how I ran into it) I tried updating it to the latest upstream version but failed. Lucas
Bug#1024322: transition: dpdk
On 2022-12-22 20:43:20 +0100, Sebastian Ramacher wrote: > On 2022-12-22 20:16:36 +0100, Luca Boccassi wrote: > > On Sat, 17 Dec 2022 14:52:30 +0100 Sebastian Ramacher > > wrote: > > > Control: tags -1 confirmed > > > > > > Hi Luca > > > > > > On 2022-12-17 02:12:56 +, Luca Boccassi wrote: > > > > Control: tags -1 -moreinfo > > > > > > > > On Wed, 23 Nov 2022 at 19:49, Sebastian Ramacher > > wrote: > > > > > > > > > > Control: tags -1 moreinfo > > > > > > > > > > On 2022-11-17 14:27:25 +, Luca Boccassi wrote: > > > > > > Package: release.debian.org > > > > > > Severity: normal > > > > > > User: release.debian@packages.debian.org > > > > > > Usertags: transition > > > > > > X-Debbugs-CC: > > pkg-dpdk-de...@lists.alioth.debian.org z...@debian.org > > > > > > > > > > > > Hello Thomas and Release Team, > > > > > > > > > > > > As we did for Bullseye, we are proposing the following plan to > > allow > > > > > > Bookworm to ship with the latest LTS versions of DPDK and OVS. > > This > > > > > > will let us make use of the full LTS support windows for both > > projects, > > > > > > as we have done for the past few releases. > > > > > > > > > > > > Upload OVS built from git (with new sonames/package renames if > > > > > > necessary), new OVN, DPDK 22.11 in early-to-mid December to > > unstable, > > > > > > ideally before the 16th as we go on vacation after that, to > > finish the > > > > > > transition. > > > > > > > > > > > > Then, after OVS 3.1 releases in February, upload it unstable > > (no > > > > > > soname/transition required, as only bug fixes will go in at > > that > > > > > > point). The upstream release might happen before or after the > > > > > > 2023/02/12 soft freeze, and if it is after we will ask for an > > > > > > exception. > > > > > > > > > > > > Would this plan work for everyone? > > > > > > > > > > Sounds like that should work like last time. Please remove the > > moreinfo > > > > > tag once dpdk is ready for the upload to unstable. > > > > > > > > Hi, > > > > > > > > We are now ready. dpdk, openvswitch and ovn are ready in > > experimental. > > > > uhd and collectd in unstable will need a simple binary rebuild and > > are > > > > already compatible. > > > > > > Please go ahead > > > > Only src:uhd has been rebuilt, please rebuild src:collectd too (it only > > has Recommends instead of Depends as it's a plugin-based software, so > > it won't show in apt rdepends et al). > > I'll schedule those builds once dpkd migrated. Otherwise the rebuilds > migrate before the recommends can be satisfied in testing. collect has been rebuilt. There's one remaining issue: openvswitch is causing autopkgtest regressions in ovn-octavia-provider on the 32 bit architectures. https://ci.debian.net/data/autopkgtest/testing/i386/o/ovn-octavia-provider/29661632/log.gz Cheers > > Cheers > -- > Sebastian Ramacher > -- Sebastian Ramacher
