Bug#910878: marked as done (transition: qtbase-opensource-src)
Your message dated Tue, 23 Oct 2018 09:30:28 +0300 with message-id <20181023063028.ga6...@mitya57.me> and subject line Re: Bug#910878: transition: qtbase-opensource-src has caused the Debian Bug report #910878, regarding transition: qtbase-opensource-src 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.) -- 910878: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910878 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Dear release team, Qt has released a new bugfix release (5.11.2) recently, and we need a transition to get it into unstable. The packages are already prepared in experimental. It is a patch release so it should go smooth compared to minor (5.x.0) releases. As usual, we have two sub-transitions: title = "qtbase-opensource-src"; is_affected = .depends ~ "qtbase-abi-5-11-0" | .depends ~ "qtbase-abi-5-11-2"; is_good = .depends ~ "qtbase-abi-5-11-2"; is_bad = .depends ~ "qtbase-abi-5-11-0"; and title = "qtdeclarative-opensource-src"; is_affected = .depends ~ "qtdeclarative-abi-5-11-0" | .depends ~ "qtdeclarative-abi-5-11-2"; is_good = .depends ~ "qtdeclarative-abi-5-11-2"; is_bad = .depends ~ "qtdeclarative-abi-5-11-0"; Note that we will likely want to do one more transition before Buster release. Namely, one that will switch the default OpenGL version from desktop to OpenGL ES on arm64. We are not yet ready for it, and it will affect more packages (including some that will need NMUs), so we decided to decouple it from this one. -- Dmitry Shachnev signature.asc Description: PGP signature --- End Message --- --- Begin Message --- On Thu, Oct 18, 2018 at 12:59:37PM +0300, Dmitry Shachnev wrote: > The Qt stack is now uploaded and built almost everywhere. > Only mipsel and mips64el are a bit lagging behind (mipsel is currently > building qtwebkit, then there will be qtwebengine which takes >24 hours > to build). Qt has migrated now. Thanks everybody! -- Dmitry Shachnev signature.asc Description: PGP signature --- End Message ---
Bug#887399: stretch-pu: package python-certbot/0.10.2-1
What can be done to get this issue resolved? This issue has jumped in priority now that domain validation through the TLS-SNI-01 challenge will be completely unsupported by Let’s Encrypt on February 13th, 2019. See https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209. While the TLS-SNI-01 challenge was initially disabled by Let’s Encrypt over 10 months ago, an exception had been made for people renewing certificates they had previously obtained using the challenge. This exception is going away on the above date. This means that unless users manually intervene or are upgraded to a new version of Certbot, certificate renewal will fail. I pulled some numbers on this from Let’s Encrypt and found that there were nearly 15,000 unique Debian Stretch installations that were currently relying on this exception. This is for over 32,000 certificates covering nearly 50,000 domains. There are even more affected users on jessie-backports. Since the packages in jessie-backports cannot be upgraded to a newer version due to the version in Stretch, they are stuck on an incompatible version as well. This is nearly 20,000 unique installations for over 52,000 certificates covering nearly 85,000 domains. I certainly would like to avoid having all of these renewals fail. Please let me know if there's anything I can do to help make a version of Certbot that is compatible with Let’s Encrypt’s changes available in Debian.
Re: Scheduling 9.6
Hi, "Adam D. Barratt" writes: > - November 10th This would work if needed, though I don't mind someone else doing the archive side (still have some things to sort out *sigh*). Ansgar
Bug#911631: nmu: rdeps of xapian-core round 3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu This is a second follow-up to my previous request binnmu request: https://bugs.debian.org/910549 Since then, packagesearch 2.7.10 was uploaded to unstable with amd64 binaries built against an out-of-date xapian-core (1.4.7-2, rather than 1.4.7-4 which fixed the issue that required these binNMUs). nmu packagesearch_2.7.10 . amd64 . -m 'Rebuild against libxapian30 with dependency in shlibs' dw packagesearch_2.7.10 . amd64 . -m 'libxapian-dev (>= 1.4.7-4)' Cheers, Olly P.S. for the maintainer of packagesearch: Ben, please ensure your build chroot is up-to-date (it must have been 2 weeks or more out of date for this to happen). Also, there's no need to be uploading binaries unless the package needs to go through NEW (which would also have avoided this happening in this case) - see: https://wiki.debian.org/SourceOnlyUpload signature.asc Description: PGP signature
Bug#911512: nmu: btrfs-progs_4.17-1~bpo9+1
Nicholas, > > There is no need defend, provide proof, or even explain yourself > > here - I was the one who built & uploaded this package, and even > > apologise for doing so in my previous message. > > > > I believe you have either misread or misinterpreted the "just an > > FYI" element of me adding you to the CC. > > Yes, sorry. I interpreted this as "here is something you might not > have been aware of" and I made a snap judgment that it was worth > following up on because I'm working on a solution. I remain confused. The synopsis is, AUIU: a) You asked me to do X. b) I screwed up whilst doing X. c) I am merely letting you know that I did so just in case someone asks you about it later (and you are unware of this bug and/or context). > 'just need to find the time--my work schedule as been severe. There's nothing for you to do. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#911512: nmu: btrfs-progs_4.17-1~bpo9+1
On Sun, Oct 21, 2018 at 05:06:34PM -0400, Chris Lamb wrote: > Nicholas, > > > Thank you for CCing me. I build everything in a clean chroot and have > > taken care to configure my workflow so that every build or upload > > requires an explicit target dist and errors if anything doesn't match. > > [snip] > > There is no need defend, provide proof, or even explain yourself > here - I was the one who built & uploaded this package, and even > apologise for doing so in my previous message. > > I believe you have either misread or misinterpreted the "just an > FYI" element of me adding you to the CC. Yes, sorry. I interpreted this as "here is something you might not have been aware of" and I made a snap judgment that it was worth following up on because I'm working on a solution. 'just need to find the time--my work schedule as been severe. Cheers, Nicholas signature.asc Description: PGP signature
Bug#911580: [britney2] missing trigger with breaks relationship
Package: release.debian.org User: release.debian@packages.debian.org Usertags: britney Severity: normal As said, britney fails to add the appropriate trigger for virtualbox when a major release is out, and for this reason the ext-pack fails to install reliably on ci.d.o without additional manual triggers. "virtualbox (>= 5.2.20-dfsg-0~) | virtualbox-5.2, virtualbox (<< 5.2.20-dfsg-z) | virtualbox-5.2" should be a valid relationship. thanks for having a look, Gianfranco
