Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2
On 12/15/22 20:15, Ondřej Surý wrote: I think everything is mostly ready in experimental. I'll try to sort out the rest of the missing extensions over the weekend (imagick, memcached, redis and maybe few others). php-igbinary needs to be moved to unstable, php-apcu is built & installed on all release architectures. php-raphf is also built & installed on all release architectures, but php-pecl-http was not staged in experimental and will need to pass NEW. php-memcached and php-redis were not uploaded to experimental either. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1004441: unblocking chromium?
On Fri, Jan 6 2023 at 11:36:02 AM +0200, Adrian Bunk wrote: On Fri, Jan 06, 2023 at 10:18:16AM +0100, Moritz Muehlenhoff wrote: ... We might consider to set some expectation for oldstable-security, though e.g state that oldstable-security updates stop three months after the release of stable or so. Yeah, I like that idea. I think I could comfortably handle about 6 months of dual security support (stable+oldstable), personally. Chromium is very fast-paced in toolchain changes (e.g. in the past new C++ features become incompatible with GCC and we might see something similar with LLVM (which is used these days) as well. New LLVM versions are already added annually to *stable for Firefox, even in LTS (which got LLVM 13 last autumn in addition to 6, 7 and 11). The LLVM updates have been very helpful for chromium bullseye support.
NEW changes in stable-new
Processing changes file: libreoffice_7.0.4-4+deb11u5_s390x-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: libreoffice_7.0.4-4+deb11u5_arm64-buildd.changes ACCEPT Processing changes file: libreoffice_7.0.4-4+deb11u5_armhf-buildd.changes ACCEPT
Bug#1027463: transition: clamav
On Wednesday, January 4, 2023 2:27:46 PM EST Sebastian Ramacher wrote: > Control: tags -1 confirmed > > Hi Scott > > On 2022-12-31 19:29:53 -0500, Scott Kitterman wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: pkg-clamav-devel.alioth-lists.debian.net > > > > As discussed in a separate email to the release team list yesterday, we, > > unfortunately have a need to do a late clamav transition. > > > > The clamav project now maintains specified releases with long term > > support. Currently we have 0.103 in stable/testing/unstable. We should > > be able to maintain clamav for the expected life of bullseye with 0.103. > > > > For bookworm we will need to transition to clamav 1.0/libclamav11 at > > some point and we believe it's better to do it now that during the > > freeze or even potentially after release. The move from 0.103 to 1.0 is > > more complicated that usual due to upstream switching from autorools to > > CMake and the introduction of Rust code into libclamav. > > > > The package is availalbe in experimental, but still needs some cleanup > > before it's ready for release. We will be working on this over then > > next couple of days and anticipate being ready for the transition > > mid-week. > > > > There are three reverse build-depends for libclamav-dev: > > > > * c-icap-modules > > * cyrus-imapd > > * pg-snakeoil > > > > I've test built all three with the clamav 1.0 packages in experimental > > with no issue. > > > > Additionally, there is libclamunrar in non-free that will also need to > > be updated. The clamav team will address that after the transition is > > done. > > Please go ahead. > > Cheers libclamav11 is now available on all release archs, so I think we can do the binNMUs now. Scott K signature.asc Description: This is a digitally signed message part.
Re: Bug#1020413: nmu: bind-dyndb-ldap_11.6-3
Santiago Vila wrote: > El 23/9/22 a las 10:21, Timo Aaltonen escribió: >> Paul Gevers kirjoitti 22.9.2022 klo 22.26: >>> So, Timo, is the package in bullseye broken with the security update and >>> does it need a fix, or is it fine? >> >> It needs a rebuild, [...] > > I think it's really broken: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027825 Note that bind-dyndb-ldap currently also fails to build in unstable since the latest bind9 release, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027094 It is currently preventing bind9 9.18.10-2 from migrating to unstable (that fixes a couple of bugs), and bind9 security updates were already following the upstream branch in bullseye (as seen above). I'm not entirely familiar with how upstream operates on this, but as far as I understand https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 there is no API guarantee whatsoever and bind-dyndb-ldap is the only out-of-tree dyndb plugin ever created. Unless someone can fix this fast and for good, I'm afraid we will be stuck during a rock and a hard place for the entire bookworm release. src:bind9-libs was created to keep isc-dhcp on life support (and I think it could be removed from unstable, since isc-dhcp uses the bundled libraries instead of https://tracker.debian.org/news/1323159/accepted-isc-dhcp-443-1-source-into-unstable/ ), but that's an entirely different case (using some functions in bind libraries vs. being a plugin). Bernhard
Bug#1027044: transition: numpy 1.24.x
> bugs have been filed: > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-python%40lists.debian.org=numpy1.24 the pending bugs number is dropping rapidly, so i'd like to ask for this transition consideration. having numpy 1.24 in unstable, and raising severity to RC, will likely speed up bugs fixing too. Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Bug#1027686: transition: rakudo
On Saturday, 7 January 2023 11:58:29 CET you wrote: > > Unfortunately, the compiler-id also depends on the build directory. Which > > means that the compiler id changes between arches. > > This should be fixed first. Otherwise every rebuild of the compiler will > require all reverse dependencies to be rebuilt too. That does not sound > like a good solution. Agreed, but that's a long story with upstream: https://github.com/rakudo/rakudo/issues/5099 All the best
Processed: block 1028132 with 1028124
Processing commands for cont...@bugs.debian.org: > block 1028132 with 1028124 Bug #1028132 [release.debian.org] transition: hunspell 1028132 was not blocked by any bugs. 1028132 was not blocking any bugs. Added blocking bug(s) of 1028132: 1028124 > thanks Stopping processing here. Please contact me if you need assistance. -- 1028132: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028132 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1028132: transition: hunspell
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Blocks: -1 by 1028124 Hi, not a real transition but given that it involves Breaks: and a dependency bump with shlibs.local... hunspell 1.7.2 changed some *internal* headers. Unfortunately it broke hunspell-ko (fixed in 1.7.2+really1.7.2-4) and r-cran-hunspells test. r-cran-hunspell included a copy of those internal headers and thus breaks when built against the newer ones. (And I assume will do so when built against the new ones against the old one.) See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028124 for the gory details. I added Breaks: to hunspell 1.7.2+really1.7.2-5 and added a shlibs.local to my proposed solution to #1028124 Changes in hunspell 1.7.2 according to upstream github announcement: --- snip --- Crash fixes, code clean-up in ~200 commits tdf#136306 don't accept/suggest typos as 3-or-more-word compound words Prepare optional spelling mode of LibreOffice to not accept/suggest not dictionary-based words as compound words (#517) Merge in weblate translations --- snip --- Regards, Rene
NEW changes in stable-new
Processing changes file: libreoffice_7.0.4-4+deb11u5_amd64-buildd.changes ACCEPT
Bug#1028118: transition: rocksdb
On Sat, Jan 7, 2023 at 11:53 AM Sebastian Ramacher wrote: > On 2023-01-07 08:42:37 +0100, László Böszörményi wrote: > > I hope this transition gets green light despite this dependency > > problem that needs to be resolved anyway. Main reason is a specific > > memory corruption error fix in the 7.8.1 version of RocksDB. > > Please go ahead. Thanks, uploaded and just got accepted. Cheers, Laszlo/GCS
NEW changes in stable-new
Processing changes file: libreoffice_7.0.4-4+deb11u5_armel-buildd.changes ACCEPT
Processed: Re: Bug#1027686: transition: rakudo
Processing control commands: > tags -1 moreinfo Bug #1027686 [release.debian.org] transition: rakudo Added tag(s) moreinfo. -- 1027686: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027686 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1027686: transition: rakudo
Control: tags -1 moreinfo On 2023-01-02 17:02:22 +0100, Dominique Dumont wrote: > On Sunday, 1 January 2023 22:38:43 CET M. Zhou wrote: > > Specifically, the pre-compiled cache shipped in reverse dependencies > > relies on a matching compiler ID. Hence, we added the compiler ID into the > > virtual package to ensure cache compatibility: raku-api-2022.12+e556a5c0 > > The compiler ID will change when code is modified. > > Unfortunately, the compiler-id also depends on the build directory. Which > means that the compiler id changes between arches. This should be fixed first. Otherwise every rebuild of the compiler will require all reverse dependencies to be rebuilt too. That does not sound like a good solution. Please remove the moreinfo tag once this is fixed. Cheers > > > Albeit adding the compiler ID may not sound like an ideal solution, > > this seems like what we can do before the freeze. > > Unfortunately, yes. > > > Ben file: > > > > title = "rakudo"; > > is_affected = .depends ~ "raku-api-2022.07" | .depends ~ > > "raku-api-2022.12+e556a5c0"; is_good = .depends ~ > > "raku-api-2022.12+e556a5c0"; > > is_bad = .depends ~ "raku-api-2022.07"; > > I'm afraid this will break when rakudo is rebuilt in unstable. > > I may have missed something, but why not keep the following lines as ben file: > > Affected: .depends ~ /(^|\s)raku-api-/ > Good: !.edos-debcheck ~ /uninstallable/ > Bad: .edos-debcheck ~ /uninstallable/ > > This is what is currently specified in > https://release.debian.org/transitions/html/rakudo.html > > All the best > -- Sebastian Ramacher
Processed: Re: Bug#1028118: transition: rocksdb
Processing control commands: > tags -1 confirmed Bug #1028118 [release.debian.org] transition: rocksdb Added tag(s) confirmed. -- 1028118: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028118 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1028118: transition: rocksdb
Control: tags -1 confirmed On 2023-01-07 08:42:37 +0100, László Böszörményi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi RMs, > > Small transition of RocksDB to version 7.8.3 as the affected packages > are limited to balboa and sortmerna. Both build fine on amd64 with > this new RocksDB version. > While version 7.8.3 [1] has some new features, but has a bunch of bug > fixes that would be good to have for Bookworm. The only drawback is > sortmerna which is no longer built on i386 [2] since the end of last > November and can't migrate to testing due to this. Reason seems to be > either architecture misdetection or just that it doesn't support i386 > architectures anymore. Failing message is: > error: inlining failed in call to ‘always_inline’ ‘_mm_set1_epi8’: > target specific option mismatch > > I hope this transition gets green light despite this dependency > problem that needs to be resolved anyway. Main reason is a specific > memory corruption error fix in the 7.8.1 version of RocksDB. Please go ahead. Cheers > > Thanks for considering, > Laszlo/GCS > [1] https://github.com/facebook/rocksdb/releases/tag/v7.8.3 > [2] https://buildd.debian.org/status/logs.php?pkg=sortmerna=i386 > -- Sebastian Ramacher
NEW changes in stable-new
Processing changes file: libreoffice_7.0.4-4+deb11u5_mips64el-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: libreoffice_7.0.4-4+deb11u5_i386-buildd.changes ACCEPT Processing changes file: libreoffice_7.0.4-4+deb11u5_mipsel-buildd.changes ACCEPT
Re: Python 3.11 for bookworm?
Hi Thomas, Am Thu, Jan 05, 2023 at 01:57:43PM +0100 schrieb Thomas Goirand: > > This has since already been discussed here: the final decision was to "at > least try 3.11", which is exactly what we're doing. I admit I was not at site and may be I missunderstood what was finally decided. From my perspective this "at least try" is that we are actually trying by having 3.11 as additional supported version which has triggered quite some work. We are approaching the Transition and Toolchain Freeze in 5 days[1]. Given that switching default Python is a transition I wonder how you can assume that this is the right time to suggest this. I would not have been that astonished if you would have done so say at first December last year. But now its absolutely clear that a migration (with the "option" to revert which will cause extra work) will pour sand into the gears of the release process. > FYI, I'm down with only 2 major bugs (I don't mind much if the other 3 RC > bugs push the 3 affected packages away from the release, it's just a "would > be nice" thing ATM): That's a nice situation for the field you are working in. > > If I would create a list mine whould be way longer. > > Please share it in this list! #1023965 [src:pandas] pandas FTBFS with Python 3.11 as supported version #1024031 [src:numba] numba FTBFS with Python 3.11 as supported version These packages have a sufficient amount of rdepends and usually trigger lots of other autopkgtest failures in other packages which will keep them out of testing for quite some time. We could need all helping hands to fix these ... all noise that will happen afterwards will keep the relevant teams busy enough. > > We are constantly beaten by removal from testing warnings > > even with Python3.11 as an option and sometimes we simply need to remove > > that option as a temporary means for bookworm. > > Same over here. It's finally looking good for me after 2 months of heavy > efforts. You mean you are fixing Python 3.10 manually in some packages diverging what will be default Python? > > No better solution but better timing which means after bookworm release. > > I've read *many* people saying it would be disappointing for them to see > their package removed because of Python 3.11. Well, please consider that it > would also be very disappointing to *not* have Python 3.11 for those who > managed constantly fix issues for it. I can understand that we can never satisfy the needs of everybody. My main problem is the extremely unfortunate timing that is happening now. > The timing was exactly what was discussed during Debconf: it's very annoying > that this year, upstream Python release was one month late... we're only > trying to deal with it. I do not remember that the scchedule was discussed. * Add 3.11 as a supported Python3 version was done in python3-defaults (3.10.6-2) at Fri, 11 Nov 2022 11:10:31 +0200. At 12. December Graham suggested on the behalf of the release team[2] to switch to 3.11. If we would have acted upon this at that very time I would have considered this quite dense but the last chance to consider this in line with the "lets try" attempt discussed at DebConf. Bug #1026825: python3.11 as default filed right before (21.12.) a series of holidays in the region of the world where lots of developers will typically reduce their activity which is closely followed by the first freeze step is IMHO something else. Since I realised that the transition was started[3] our discussion is a bit useless. I just want to explain the motivation why I sounded "astonished" since you said that you do not understood astonishment since we are following the suggested plan. Kind regards Andreas. [1] https://release.debian.org/testing/freeze_policy.html [2] https://lists.debian.org/debian-python/2022/12/msg00074.html [3] https://release.debian.org/transitions/html/python3.11-default.html -- http://fam-tille.de
