Re: Re-planning for 12.6
On Sun, Apr 21, 2024 at 05:44:48PM +0100, Andy Simpkins wrote: > > On 21/04/2024 01:57, Steve McIntyre wrote: > > On Sat, Apr 20, 2024 at 05:41:13PM +0100, Jonathan Wiltshire wrote: > > > On Thu, Apr 18, 2024 at 10:58:41PM +0100, Steve McIntyre wrote: > > > > Hiya! > > > > > > > > Not wanting to pester *too* much, but where are we up to? > > > > > > > Right now I can still have 27th April on the cards but we're missing FTP > > > and > > > press. It's next week, we'd have to know this weekend and get frozen. > > > Mark indicated "maybe" and no answer from press. > > > > > > If that date works please reply urgently otherwise we're looking into May > > > and possibly just skipping to line up with the final bullseye anyway. > > It works for me, I guess. Dunno about other folks. > > > > I can still do 27th but as I have already stated Isy is now unavailable > until July due to exams. > > Please can we make a decision by Tuesday otherwise I'll end up doing > something else Too late now in any case. SRMs will regroup and decide whether we push for one in May or just wait for June anyway. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1069567: marked as done (bookworm-pu: package filezilla/3.63.0-1+deb12u4)
Your message dated Sun, 21 Apr 2024 21:49:44 +0100 with message-id <8814b02ec05bd7b8f90a85b1785fd1bdb66134b9.ca...@kathenas.org> and subject line Re: Bug#1069567: bookworm-pu: package filezilla/3.63.0-1+deb12u4 has caused the Debian Bug report #1069567, regarding bookworm-pu: package filezilla/3.63.0-1+deb12u4 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.) -- 1069567: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069567 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal Tags: bookworm Control: affects -1 + src:filezilla User: release.debian@packages.debian.org Usertags: pu [ Reason ] Fix CVE-2024-31497. [ Impact ] In PuTTY 0.68 through 0.80 before 0.81, biased ECDSA nonce generation allows an attacker to recover a user's NIST P-521 secret key. https://security-tracker.debian.org/tracker/CVE-2024-31497 [ Tests ] Manual testing on own infrastructure. [ Risks ] The fix is a clean one and the regression risk is quite low. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in stable [x] the issue is verified as fixed in unstable [ Changes ] Imported and backported the upstream patch that fixes CVE-2024-31497. Regards Phil -- Homepage: https://kathenas.org Instagram: https://instgram.com/kathenasorg Support my Free/Open Source Software contribution... Buy Me A Coffee: https://www.buymeacoffee.com/kathenasorg filezilla_3.63.0-1+deb12u3_to_filezilla_3.63.0-1+deb12u4.debdiff Description: Binary data signature.asc Description: This is a digitally signed message part --- End Message --- --- Begin Message --- Closing. Needs further review and then re-submission. Regards Phil On Sat, 2024-04-20 at 15:59 +0100, Phil Wyett wrote: > Package: release.debian.org > Severity: normal > Tags: bookworm > Control: affects -1 + src:filezilla > User: release.debian@packages.debian.org > Usertags: pu > > [ Reason ] > Fix CVE-2024-31497. > > [ Impact ] > In PuTTY 0.68 through 0.80 before 0.81, biased ECDSA nonce generation > allows an attacker to recover a user's NIST P-521 secret key. > > https://security-tracker.debian.org/tracker/CVE-2024-31497 > > [ Tests ] > Manual testing on own infrastructure. > > [ Risks ] > The fix is a clean one and the regression risk is quite low. > > [ Checklist ] > [x] *all* changes are documented in the d/changelog > [x] I reviewed all changes and I approve them > [x] attach debdiff against the package in stable > [x] the issue is verified as fixed in unstable > > [ Changes ] > Imported and backported the upstream patch that fixes CVE-2024-31497. > > Regards > > Phil > -- Homepage: https://kathenas.org Instagram: https://instgram.com/kathenasorg Support my Free/Open Source Software contribution... Buy Me A Coffee: https://www.buymeacoffee.com/kathenasorg signature.asc Description: This is a digitally signed message part --- End Message ---
Re: Re-planning for 12.6
On 21/04/2024 01:57, Steve McIntyre wrote: On Sat, Apr 20, 2024 at 05:41:13PM +0100, Jonathan Wiltshire wrote: On Thu, Apr 18, 2024 at 10:58:41PM +0100, Steve McIntyre wrote: Hiya! Not wanting to pester *too* much, but where are we up to? Right now I can still have 27th April on the cards but we're missing FTP and press. It's next week, we'd have to know this weekend and get frozen. Mark indicated "maybe" and no answer from press. If that date works please reply urgently otherwise we're looking into May and possibly just skipping to line up with the final bullseye anyway. It works for me, I guess. Dunno about other folks. I can still do 27th but as I have already stated Isy is now unavailable until July due to exams. Please can we make a decision by Tuesday otherwise I'll end up doing something else /Andy
Re: Status of the t64 transition
Hi Andreas, please stop reopening the time_t bugs where transitions are staged in experimental. When we eventually start those transitions, they do not need to change the package name again as they will enter unstable with a new SONAME and built with the 64 bit time_t ABI. Cheers -- Sebastian Ramacher
Re: R 4.4.0 coming April 24
On 4/21/24 3:04 PM, Dirk Eddelbuettel wrote: R upstream no longer releases or tests for 32 bits (and has not since the R 4.3.0 release a year ago) so 'expect trouble there'. I think you all in the release team may need to override this to unblock. Wouldn't it be better then to add architecture-is-64-bit to the r-base build dependencies to prevent it from building on 32bit architectures and then file partial RM bugreports for r-base and its rdeps to get them removed from the 32bit architectures? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: R 4.4.0 coming April 24
On 21 April 2024 at 15:25, Sebastiaan Couwenberg wrote: | On 4/21/24 3:04 PM, Dirk Eddelbuettel wrote: | > R upstream no longer releases or tests for 32 bits (and has not since the R | > 4.3.0 release a year ago) so 'expect trouble there'. I think you all in the | > release team may need to override this to unblock. | | Wouldn't it be better then to add architecture-is-64-bit to the r-base | build dependencies to prevent it from building on 32bit architectures | and then file partial RM bugreports for r-base and its rdeps to get them | removed from the 32bit architectures? Yes!! I actually grep'ed among all my (100+) packages but did not see an example. I may be missing the best way to do this: so is this (new to me) 'architecture-is-64-bit' the way to do it? A quick 'apt-cache search' leads me to 'architecture-properties'. I would be in favor. So thanks for the suggestion! Are there concerns or side effects or our desire to build for as many platforms as possible etc? Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: R 4.4.0 coming April 24
Hi Graham, Hi Release Team, On 21 April 2024 at 13:37, Graham Inggs wrote: | On Thu, 18 Apr 2024 at 13:38, Dirk Eddelbuettel wrote: | > Right now it now only shows 'all reports (re-)running'. | | That was because of the new upload, but I see the results there now. | | The packages with failing autopkgtests are: | | r-bioc-iranges/2.36.0-1 | r-bioc-mutationalpatterns/3.12.0+dfsg-1 | r-bioc-s4vectors/0.40.2+dfsg-1 | r-cran-data.table/1.14.10+dfsg-1 | r-cran-ff/4.0.12+ds-1 I checked these five just now: four of them are current so I may have to leave this with their maintainer. But r-cran-data.table is quite badly behind (the once again very active upstream) and the current release is 1.15.4. I use package a lot myself and keep an eye out on their upstream work, there were some minor CRAN required updates so an update could cure that for us too. And given how widely data.table is used (i.e. by r-bioc-s4vectors which itself is used by r-bioc-iranges and r-bioc-mutationalpatterns) we quite possibly have one package causing four hickups. | > But package r-base | > has had the usual issues in unstable for a few weeks now because 'some | > people' insist on adding autopkg tests including for architectures / build | > sizes no longer supported upstream -- R stopped 32 bit support over a year | > and release ago | | For the pseudo-excuses in experimental only amd64 and arm64 are | tested, no 32-bit architectures. Ah. I expect more skirmish then. R upstream no longer releases or tests for 32 bits (and has not since the R 4.3.0 release a year ago) so 'expect trouble there'. I think you all in the release team may need to override this to unblock. R 4.4.0 itself is fine. I decided to also eat my own dogfood and sent the same package I sent to experimental to launchpad for Ubuntu 23.10 (my daily driver here), and I am running it now for a over a day. "Everything works", I have hourly cronjobs for R too and there is no issue. So I plan to proceed with R 4.4.0. | > -- as well continually letting dependencies slip so that the | > autopkg tests involve old and outdated package releases combined with the | > fact that BioConductor has _very_ specific release cycles yet they throw | > r-bioc-* package in too) so there is little I can do on the end of package | > r-base. Briefly, I am being put into a bad corner by other maintainers here, | > and I no longer have the energy to discuss that with them. We have been at | > this for years. | | I think "discuss" was probably not the best word for Paul to suggest here. | | You only need to inform the maintainers of the affected packages, and | that can be done by filing RC bugs against the affected versions. If | the packages don't get updated, auto-removal will take care of them. | The sooner this is done, the better. Well when r-base 4.3.3-3 was being held back by what I consider autopkg overuse and a 100+ packages failed on two of the non-release-for-R 32-bit arches. I was not exactly in the mood to deal with 100+ RC bugs manually. _My package_ is fine and I take care of it. But I presume you guys have scripts for this while I do not. Some help and coordination may be useful and appreciated. One more thing: I forgot / failed to follow-up on what I had emailed about earlier. The Matrix package (aka "r-cran-matrix") update affecting the handful of packages _compiling against the Matrix header files_. That is just a few among hundreds using Matrix just as an R package (and which remain unaffected from the exported header API update which is shielded for normal use). CRAN and the Matrix team decided to wait for R 4.4.0 so Matrix will follow shortly after R 4.4.0 and I think I can handle that manually. Either n-day NMUs or simply initial bug reports requesting a rebuild. Cheers, and thanks as always for all you all on the release team do. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: R 4.4.0 coming April 24
Hi Dirk On Thu, 18 Apr 2024 at 13:38, Dirk Eddelbuettel wrote: > Right now it now only shows 'all reports (re-)running'. That was because of the new upload, but I see the results there now. The packages with failing autopkgtests are: r-bioc-iranges/2.36.0-1 r-bioc-mutationalpatterns/3.12.0+dfsg-1 r-bioc-s4vectors/0.40.2+dfsg-1 r-cran-data.table/1.14.10+dfsg-1 r-cran-ff/4.0.12+ds-1 > But package r-base > has had the usual issues in unstable for a few weeks now because 'some > people' insist on adding autopkg tests including for architectures / build > sizes no longer supported upstream -- R stopped 32 bit support over a year > and release ago For the pseudo-excuses in experimental only amd64 and arm64 are tested, no 32-bit architectures. > -- as well continually letting dependencies slip so that the > autopkg tests involve old and outdated package releases combined with the > fact that BioConductor has _very_ specific release cycles yet they throw > r-bioc-* package in too) so there is little I can do on the end of package > r-base. Briefly, I am being put into a bad corner by other maintainers here, > and I no longer have the energy to discuss that with them. We have been at > this for years. I think "discuss" was probably not the best word for Paul to suggest here. You only need to inform the maintainers of the affected packages, and that can be done by filing RC bugs against the affected versions. If the packages don't get updated, auto-removal will take care of them. The sooner this is done, the better. Regards Graham
Re: Re-planning for 12.6
as i indicated on IRC 27th April works for me May does not really work for me however Den sön 21 apr. 2024 kl 02:58 skrev Steve McIntyre : > > On Sat, Apr 20, 2024 at 05:41:13PM +0100, Jonathan Wiltshire wrote: > >On Thu, Apr 18, 2024 at 10:58:41PM +0100, Steve McIntyre wrote: > >> Hiya! > >> > >> Not wanting to pester *too* much, but where are we up to? > >> > > > >Right now I can still have 27th April on the cards but we're missing FTP and > >press. It's next week, we'd have to know this weekend and get frozen. > >Mark indicated "maybe" and no answer from press. > > > >If that date works please reply urgently otherwise we're looking into May > >and possibly just skipping to line up with the final bullseye anyway. > > It works for me, I guess. Dunno about other folks. > > -- > Steve McIntyre, Cambridge, UK.st...@einval.com > “Changing random stuff until your program works is bad coding > practice, but if you do it fast enough it’s Machine Learning.” >-- https://twitter.com/manisha72617183 >
