Bug#987766: unblock: open-iscsi/2.1.3-2
Hi kibi, On 25-05-2021 01:05, Cyril Brulebois wrote: > Paul Gevers (2021-05-24): >> unblocked and aged to 10 days. @kibi, let me know if you need it earlier. > > Thanks for the unblock. Do you prefer handling the aging yourself, or > can I just adjust with either age-days or urgent if I see stuff that's > not yet in testing when I'm a few days from preparing the release? I've > done the latter on my own for a while, but with the release getting > closer, I could understand if you'd like to have more visibility / > control over age requirements. I trust you to handle that in a sane way, so, unless you find "heated" discussions in an unblock bug (than please check with the Release Team member(s) involved), please go ahead. > As for this specific package, it might be slightly better to have 7 > days, so that it has a chance to be in testing by the week-end or early > next week. Ack, updated the age hint. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#988442: unblock: linux/5.10.37-1 (pre-approval checking)
Control: tags -1 confirmed d-i @boot: needs d-i ACK. As I believe you are aware of, the upload has already happened. @kibi: feel free to age it if/when you see fit Paul On 19-05-2021 17:27, Salvatore Bonaccorso wrote: > Control: retitle -1 unblock: linux/5.10.38-1 (pre-approval checking) > > On Thu, May 13, 2021 at 09:30:29AM +0200, Salvatore Bonaccorso wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> X-Debbugs-Cc: car...@debian.org >> >> Dear release team, >> >> As you know we follow the respective stable series as well in a stable >> release, and usually this is then done in point releases >> (exceptionally as well via a DSA). Now I know the time for bullseye is >> tight, but I would still like to followup with a stable series import >> in unstable, but wanted to double check with you in aprticular if >> there are ny timing issues with d-i. >> >> I would plan to upload based ideally on 5.10.37 because it will cover >> a big amount of bufixes but particularly recent CVEs which are >> important to have covered in bullseye already soon. Currently already >> covered in the imports done in git and in the packaging pending are >> CVE-2020-25670, CVE-2020-25671, CVE-2020-25672, CVE-2021-3489, >> CVE-2021-3490, CVE-2021-3491, CVE-2021-3493, CVE-2021-3501, >> CVE-2021-3506, CVE-2021-23133, CVE-2021-23134, CVE-2021-29155, >> CVE-2021-31829, but I would want do cover as well the recent >> FragAttack fixes (not yet worked on). >> >> In the packaging itself there will be additional changes pending >> currently they are: >> >>[ Vincent Blut ] >>* [x86] sound/soc/intel: Enable SND_SOC_INTEL_CATPT as module >> (Closes: #986822) >>* [x86] sound/soc/intel/boards: Enable SND_SOC_INTEL_BDW_RT5650_MACH as >> module >>* drivers/input/rmi4: Enable RMI4_F3A (Closes: #986848) >>* [armhf] drivers/gpio: Enable GPIO_MXC as module (Closes: #987019) >>* [x86] drivers/misc/mei: Enable INTEL_MEI_TXE, INTEL_MEI_HDCP as modules >> (Closes: #987281) >> >> All of those are for better hardware support. >> >>[ Uwe Kleine-König ] >>* [arm64] Enable more options for NXP's i.MX8 (Closes: #985862) >> >> Samewise. >> >>[ Salvatore Bonaccorso ] >>* vfs: move cap_convert_nscap() call into vfs_setxattr() (CVE-2021-3493) >>* Refresh "Makefile: Do not check for libelf when building OOT module" >>* [rt] Drop "xfrm: Use sequence counter with associated spinlock" >>* Bump ABI to 7 >>* Refresh "tools/include/uapi: Fix " >>* Revert "net/sctp: fix race condition in sctp_destroy_sock" >>* sctp: delay auto_asconf init until binding the first addr >> (CVE-2021-23133) >>* net/nfc: fix use-after-free llcp_sock_bind/connect (CVE-2021-23134) >>* bpf, ringbuf: Deny reserve of buffers larger than ringbuf >> (CVE-2021-3489) >>* bpf: Prevent writable memory-mapping of read-only ringbuf pages >>* bpf: Fix alu32 const subreg bound tracking on bitwise operations >> (CVE-2021-3490) >>* io_uring: truncate lengths larger than MAX_RW_COUNT on provide buffers >> (CVE-2021-3491) >> >> Various CVE fixes (which will though go as well partially in 5.10.37 >> directly), >> the FragAttack CVEs are not yet included. >> >> The RT patch which can be dropped after checking with Sebastian >> Andrzej Siewior. An ABI bump included, note that the changes are quite >> massive up to 5.10.37, (5.10.37 will contain approximately 530 >> upstream commits, 5.10.36 was as well with 300 a bigger one). I >> realize this might scary, but in the end this is the stragegy we >> necessarily need to follow to keep up with upstream stable releases. >> >>[ Vagrant Cascadian ] >>* [arm64] Disable USB type-C DisplayPort in pinebook pro device-tree. >>* [arm64] Enable TYPEC_FUSB302, SND_SOC_ES8316, TYPEC and TYPEC_TCPM as >> modules. (Closes: #987638) >> >>[ Michal Simek ] >>* [arm64] Enable clock driver for Xilinx ZynqMP SoC >> >> Additional support for hardware in the arm64 area. >> >>[ Valentin Vidic ] >>* [s390x] udeb: Include standard scsi-modules containing the virtio_blk >> module (Closes: #988005) >> >> "Acked"/wished by KiBi, to align s390x installer support to the other >> architectures. >> >> The current state is at https://salsa.debian.org/kernel-team/linux/-/tree/sid >> >> Let me know what you think of it, I would in any case send the usual >> "Upload announcement" to the various involved teams before the upload >> summarizing again the changes. > > For the record, this will be 5.10.38 based. I delayed on purpose given > the size which was forseen. > > If anybody has concern on the upload, please raise a flag. > > Regards, > Salvatore > OpenPGP_signature Description: OpenPGP digital signature
Bug#988627: unblock: broadcom-sta/6.30.223.271-16.1
Control: tags -1 moreinfo Hi, On 17-05-2021 02:12, Ben Hutchings wrote: > Please unblock package broadcom-sta > > [ Reason ] > Fix the unusable broadcom-sta-source package. > > [ Impact ] > It is not possible to build a package using module-assistant and the > version of broadcom-sta-source in bullseye. However, dkms and > broadcom-sta-dkms can be used as an alternative. > > [ Tests ] > Only the build processes are being changed. I tested that: > - broadcom-sta can be built from source > - module-assistant can build a module package from broadcom-sta-source > for the current kernel version in bullseye (5.10.0-6-amd64) > - the resulting binary module package looks like a module package > built from broadcom-sta-source in buster, modulo version changes * I wonder, broadcom-sta has seen quite some uploads the last couple of years and debhelper is even in oldstable newer than the version mentioned. How were all these uploads possible? * What is/was the behavior of debhelper if the compat level was not specified? In the freeze we don't want debhelper compat bumps unless the package is proven to have no delta regardless of the old-vs-new level. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#987081: unblock: puppet-module-puppetlabs-haproxy/2.1.0-3
Hi Thomas,
Ping.
Paul
Note: without reply, we'll close the bug without action
On 20-04-2021 11:03, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
>
> On 2021-04-17 12:02:44 +0200, Thomas Goirand wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>>
>> Please unblock package puppet-module-puppetlabs-haproxy
>>
>> This fixes a minor issue in the prerm when removing
>> alternatives (ie: wrong path when removing the alternative).
>
> Why is update-alternatives run on upgrade and deconfigure in prerm? From
> update-alternatives' manpage:
>
> update-alternatives is usually called from the following Debian package
> maintainer scripts, postinst (configure) to install the alternative and
> from prerm and postrm (remove) to remove the alternative. Note: in most
> (if not all) cases no other maintainer script actions should call
> update-alternatives, in particular neither of upgrade nor disappear, as
> any other such action can lose the manual state of an alternative, or
> make the alternative temporarily flip-flop, or completely switch when
> several of them have the same priority.
>
>
> Cheers
>
>
>>
>> (very) small debdiff attached.
>>
>> Please unblock puppet-module-puppetlabs-haproxy/2.1.0-3.
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>
>> diff -Nru puppet-module-puppetlabs-haproxy-2.1.0/debian/changelog
>> puppet-module-puppetlabs-haproxy-2.1.0/debian/changelog
>> --- puppet-module-puppetlabs-haproxy-2.1.0/debian/changelog 2020-03-24
11:21:33.0 +0100
>> +++ puppet-module-puppetlabs-haproxy-2.1.0/debian/changelog 2021-04-17
11:58:30.0 +0200
>> @@ -1,3 +1,9 @@
>> +puppet-module-puppetlabs-haproxy (2.1.0-3) unstable; urgency=medium
>> +
>> + * Fix update-alternatives --remove in prerm.
>> +
>> + -- Thomas Goirand Sat, 17 Apr 2021 11:58:30 +0200
>> +
>> puppet-module-puppetlabs-haproxy (2.1.0-2) unstable; urgency=medium
>>
>>[ Ondřej Nový ]
>> diff -Nru
>> puppet-module-puppetlabs-haproxy-2.1.0/debian/puppet-module-puppetlabs-haproxy.prerm
>>
>> puppet-module-puppetlabs-haproxy-2.1.0/debian/puppet-module-puppetlabs-haproxy.prerm
>> ---
>> puppet-module-puppetlabs-haproxy-2.1.0/debian/puppet-module-puppetlabs-haproxy.prerm
>> 2020-03-24 11:21:33.0 +0100
>> +++
>> puppet-module-puppetlabs-haproxy-2.1.0/debian/puppet-module-puppetlabs-haproxy.prerm
>> 2021-04-17 11:58:30.0 +0200
>> @@ -3,7 +3,7 @@
>> set -e
>>
>> if [ "${1}" = "remove" ] || [ "${1}" = "upgrade" ] || [ "${1}" =
"deconfigure" ] ; then
>> -update-alternatives --remove puppet-module-haproxy
>> /usr/share/puppet/modules.available/puppet-module-puppetlabs-haproxy
>> +update-alternatives --remove puppet-module-haproxy
>> /usr/share/puppet/modules.available/puppetlabs-haproxy
>> fi
>>
>> #DEBHELPER#
>
>
OpenPGP_signature
Description: OpenPGP digital signature
Bug#989037: Bug#988214: fixed in rails 2:6.0.3.7+dfsg-1
tag 989037 moreinfo thanks Hi, On 24-05-2021 11:35, Utkarsh Gupta wrote: > On Wed, 19 May 2021 22:12:59 +0200 Paul Gevers wrote: >> This new rails version renewed its versioned dependency on ruby-marcel. >> The new ruby-marcel version doesn't look like a targeted fix, so it >> doesn't fit the freeze policy. If I read the changelog correctly, this >> dependency is there to give rails a more relaxed license. I think such a >> change is not really needed at this stage of the freeze, does rails >> still work with the old version of ruby-marcel and can the version bump >> be reverted? > > Apologies, I missed (naturally because it wasn't copied) the conversation > on this bug prior to opening an unblock request for both. > > Whilst I agree that ruby-marcel isn't really a targeted fix, I believe the > bump was necessary to maintain sanity with future bug-fix releases of rails. > I've been trying to maintain rails from sid (back to jessie), ensuring that > the > CVEs are at least timely fixed. During that course, I've hit a lot of bumps > because of the version gaps, et al, so in this release I wanted rails to be > at par with its supported bug-fix only release (that is, the 6.0.3.x branch). > > 6.0.3.6 brings in an unusual change by bumping ruby-marcel to 1.0.0. But > after a lot of testing, sanity checking, et al, I found that the changes in > marcel are a no-op, that is, it doesn't really affect how marcel was before > and it is now. Marcel wanted to drop mimemagic dependency and so they > introduced a Magic class (Marcel::Magic) for mime type detection. > > I know that it doesn't go along with the freeze policy atm, but I also believe > that it's not really something that'd actually cause problems. IIUC, the > bump doesn't really affect much but just does things differently internally. > So is this edge case worth giving an exception along those lines? > > The bump shall yield nothing but (really) help in providing support to rails > for the next couple of years in/for bullseye (at least while it's > still supported). > Let me know what you think? Thanks! You haven't answered my question: "does rails still work with the old version of ruby-marcel and can the version bump be reverted" Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all, On 24-04-2021 00:41, Donald Norwood wrote: > Indeed, from this and the last few posts in the discussion it reads that > perhaps June is the better option for the 'timed' ready when ready > release date. The progress of fixing the blocking issues in the debian-installer is good enough to start thinking again about a tentative bullseye release date (see for more details in the quote below). Assuming all goes well with RC2 and RC3, we'd be looking at the following candidate release dates: 26 June 3 July 10 July 17 July 24 July Can you let us know which date work for you and which don't? > I think it would allow for extra care to be given in the areas needed > and would as Paul suggested allow the larger community to pull > together to help resolve some of the issues. The installer team needs everybody's help to test the d-i release candidates, to see if the issues that are being solved now are handled correctly across as many different machines as possible. If anybody has better ideas than the wiki page that kibi suggested in his e-mail below, then let us know. Otherwise I'll probably see if I can set up something like that shortly. Paul Forwarded Message Date: Fri, 28 May 2021 02:10:14 +0200 From: Cyril Brulebois [...] Right, I think I have a better grasp on where we stand. I haven't dug into each and every mail from debian-boot@, but it feels like people are generally happy with the installer in RC1 *provided* they don't run into the graphical installer hangs or issues at reboot time (due to firmware stuff). I have a few other topics that we may want to fix (serial console on s390x, problems on PowerPC, support for HTTPS, etc.) but that could be fixed in 11.1 or 11.n… Hangs in the graphical installer should be under control, even if it took quite some time and iterations and testing to figure that out for real. Firmware stuff is the next big item on my list. I've floated the idea of an RC2 in the next few days so that people could test the installer without fearing the hangs (and hopefully without finding new ones) but was waiting on linux to migrate, but some security issues came up and Salvatore would like to get 5.10.40 into testing instead, so it might be ready by next week-end (June 5-6)? I should be able to work on firmware stuff while waiting on the kernel to be ready. I'm mainly worried about the many hardware setups out there and having something that works for some machines locally might not be representative of what users are going to face. Provided I get a PoC ready in the right timing, and debian-cd people are available, we might be able to have something like the following: - RC2: June 5-6 (fixing hangs in graphical installer in particular) - RC3: June 12-13 (firmware PoC) The RC2 announcement (and maybe some help from publicity team) could be the right place to let people know we expect problems with firmware, and ask them to keep an eye on the RC3 that should feature an attempt at fixing it. Maybe setting up some wikipage where people could register their hardware and what they experience with the “stock” RC2, and where they could follow up with their experience with the “patched” RC3. There might be better tools for that, but I'm more used to pinging a submitter (or two or three) on a bug report than to collecting info from lots of people… If feedback from RC3 is good enough, we might call that RC sufficient to be the installer for 11.0, and think about a release by the end of June. We could refine it further still, e.g. by merging translation updates as what I have in mind would involve presenting users some information, which would require translation, but that's just a matter of uploading the right package with new/updated po files (the hard part is getting the actual translations, but we could think of merging those again in 11.1, 11.2, etc.). All that is rather optimistic (which I can try to be sometimes…), and I fear we might need to iterate a little, and I'm not sure how quickly we would get actionable feedback from users… If we were to hit real difficulties, maybe shift that “end of June” a few weeks, and call that “mid-July”? [...] OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi, On 30-05-2021 06:35, Donald Norwood wrote: > On 5/29/21 9:12 AM, Steve McIntyre wrote: >> On Fri, May 28, 2021 at 10:17:55PM +0200, Paul Gevers wrote: >>> Assuming all goes well >>> with RC2 and RC3, we'd be looking at the following candidate release dates: >>> >>> 26 June >>> 3 July >>> 10 July >>> 17 July >>> 24 July >>> >>> Can you let us know which date work for you and which don't? [Steve] >> I can do the >> 17th and 24th of July just fine. Asking a question I think most people know the answer to, but CD without Steve is no option? Don't get me wrong, I don't want to push otherwise, but I just want to understand the options. So much in Debian is based on "rituals", it's not always clear what's needed and what is just (nearly) always done in a certain way. [Press] > Press can do both the 17th and the 24th. Perhaps we add an additional 3 > dates? Yes, let's do that, so the list becomes: 26 June 3 July 10 July 17 July [Steve (CD), press] 24 July [Steve (CD), press] 31 July 7 August 14 August Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#987958: buster-pu: package liferea/1.12.6-1+deb10u1
Hi Adam, On Sun, 2 May 2021 20:23:30 +0200 Paul Gevers wrote: > [ Reason ] > It used to be enough to declare the liferea custom scheme as local to > access resources with a file scheme, but for WebKit2Gtk >= 2.32 it looks > like it is necessary to register the custom scheme with a handler. > Although WebKit2Gtk hasn't been updated to 2.32 in stable yet, I > understand that it will be relatively soon for security support reasons. webkit2gtk 2.32.1-1~deb10u1 entered stable today. So this bug is now impacting liferea users in stable. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#988442: unblock: linux/5.10.40-1
Hi, On 01-06-2021 08:06, Salvatore Bonaccorso wrote: > The version is not 4 days in unstable, looks good to me to let it > migrate to testing (unless Cyril spotted issues in recent d-i tests). I'm still good to go. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#988662: [pre-approval] unblock: apt/2.2.4
Control: tags -1 moreinfo Hi Julian, Sorry it took so long to reply; pre-approvals are regularly awkward. On Mon, 17 May 2021 17:07:08 +0200 Julian Andres Klode wrote: > Please unblock package apt Can you elaborate how severe do you think these issues are? I mean, I guess you were in doubt if they qualify for the freeze policy (typically if the maintainer doubts, the update doesn't qualify). Or were there different reasons why you didn't just upload and ask for a regular unblock? To me it seems: * The EOF could be a real thing, but the bug was reported by you and only found during testing. Is this a regression or has it long been there? * TLS handshake is nice to have (for consistency). * phased policy isn't a thing in Debian, so not relevant AFAICT I'm tempted to NACK. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#987504: imagemagick: attempt to perform an operation not allowed by the security policy `EPS'
tags 987504 wontfix thanks Hi Moritz, Adrian, On 03-06-2021 20:00, Moritz Mühlenhoff wrote: > Yes, we should not revert this and rather fix fallout in the handful > of affected packages. It's really bad we have to do this so late in the cycle, while the problem was known for so long. Adrian, can you do the bug filing for the packages that haven't worked around the problem already? I hate it that the "we should fix" is not us, but "they", the maintainers. We're doing them a disservice by having this postponed for so long. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#987262: [pre-approval] unblock: node-lodash/4.17.21+dfsg+~cs8.31.189.20210220-2
Hi Pirate, On Thu, 22 Apr 2021 13:50:18 +0200 Ivo De Decker wrote: > It seems the RC bug fix is unrelated to the new upstream. Please prepare an > upload based on the version currently in testing that only contains the fix > for the RC bug, not the new upsteam. Are you going to follow up on this? If not, please close this bug. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#988830: [pre-approval] unblock e2fsprogs [Was: Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel]
Control: tags -1 = confirmed d-i Hi Theodore, Sorry it took so long. On 20-05-2021 19:40, Theodore Y. Ts'o wrote: > That patch is rather long, but it's all mostly of the form: > > - tail = (struct ext4_fc_tail *)ext4_fc_tag_val(tl); > + memcpy(&tail, ext4_fc_tag_val(tl), sizeof(tail)); > > So the risks are very low. As I can't judge this myself, I'll take your word for it. If the upload can happen in the next couple of days, let's have this in unstable and if nothing is reported, have it in bullseye. Let's leave out the rest. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all, On 30-05-2021 09:09, Paul Gevers wrote: > 26 June > 3 July > 10 July > 17 July [Steve (CD), press] > 24 July [Steve (CD), press] > 31 July > 7 August > 14 August This can now be updated to: 26 June [Ansgar (ftp)] 3 July[Ansgar (ftp), Sebastian (release), Paul (release)] 10 July [Steve (CD) MAYBE , Ansgar (ftp), Paul (release)] 17 July [Steve (CD), press, Ansgar (ftp), Paul (release)] 24 July [Steve (CD), press, Ansgar (ftp), Sebastian (release)] 31 July [Steve (CD), press, Ansgar (ftp), Sebastian (release)] 7 August [Steve (CD), press, Ansgar (ftp), Sebastian (release)] 14 August [Steve (CD), press, Ansgar (ftp), Sebastian (release)] For those following along on IRC, we still have to figure out who from the release team that has access to the keys can join (if only for the signing). I hope we can update you on that shortly. On 30-05-2021 18:48, Steve McIntyre wrote: > We've been slowly working up to getting other people able to do image > releases, but I don't think we're *quite* there yet. Maybe on the next > point release Andy could do it all without me watching and helping, > but we want to work that out and I'm not sure a new major release is > the right time to try this! Again, without wanting to push, as we now have a point release before any of the mentioned dates, would any of the earlier dates be still a possibility from CD point of view? Andy, are you available? Donald, did you look at the earlier days and is press not available, or didn't you bother because of Steve's availability? Paul PS: I'm starting to realize I may feel uncomfortably direct for some people/cultures. The Dutch are known for it (some call it rude). Probably because I was raised like that, I don't want to read peoples mind, I rather hear what they mean. OpenPGP_signature Description: OpenPGP digital signature
Bug#988442: unblock: linux/5.10.40-1
Hi kibi, Salvatore, On 03-06-2021 22:31, Cyril Brulebois wrote: > Will keep an eye on this, and close this bug report once > migration has happend (just in case some bit is missing/some typo > happened or something). This happened, so this bug can be closed now. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989498: unblock: golang-1.15/1.15.9-5
Control: tags -1 moreinfo Hi Shengjing, On 05-06-2021 13:57, Shengjing Zhu wrote: > Please unblock package golang-1.15 You're well aware that golang builds statically so normally we're not done with just accepting one package. Do we now need to also rebuild everything that build depends on golang (I'd expect so)? Did anything in the golang community get uploaded to unstable that needs reverting before it can migrate? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989036: unblock: ruby-marcel/1.0.1+dfsg-2
Control: tags -1 moreinfo Hi Utkarsh, [While typing a reply to the rails unblock, I checked this request again]. On 24-05-2021 10:17, Utkarsh Gupta wrote: > We had to bump ruby-marcel to a newer version because the mimemagic > dependency - which relies on GPL-licensed mime type data from > freedesktop.org’s shared-mime-info project - is removed. I'm having trouble understanding what you wrote here. Did something in Debian now break the old ruby-marcel and you had to update ruby-marcel? If so, can you try again to explain how that happened? If not, I don't think you "had to bump ruby-marcel because of the mimemagic dependency"? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989037: Bug#988214: fixed in rails 2:6.0.3.7+dfsg-1
Hi Utkarsh, On 04-06-2021 11:26, Utkarsh Gupta wrote: > On Fri, Jun 4, 2021 at 1:38 AM Paul Gevers wrote: >>> You haven't answered my question: "does rails still work with the old >>> version of ruby-marcel and can the version bump be reverted" >> >> Ping. Without a proper answer, I can't decide. > > Thanks, I'm yet to figure that out and hopefully do this on weekend. > If it were to work with the older ruby-marcel, can I then just push > the newer rails to bullseye directly? Now that marcel's at v1.0 in > unstable, I don't want to downgrade again. I am hoping it's possible to just downgrade the *dependency* in rails only, such that the upload can happen via unstable. There is no "direct bullseye" route. Or do you expect you'll have to make (lots) of changes to rails to match the right ruby-marcel package? If that's the case, than ruby-marcel/unstable isn't a drop in replacement for ruby-marcel/bullseye and I'd expect that ruby-marcel/unstable would need a versioned Breaks for reverse dependent packages (ruby-activestorage), but I'm not seeing that. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#988830: [pre-approval] unblock e2fsprogs [Was: Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel]
Control: tags -1 moreinfo Control: retitle -1 unblock: e2fsprogs/1.46.2-1 On 03-06-2021 22:06, Paul Gevers wrote: > As I can't judge this myself, I'll take your word for it. If the upload > can happen in the next couple of days, let's have this in unstable and > if nothing is reported, have it in bullseye. Please removed the moreinfo tag once the package is available. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989198: unblock: webkit2gtk/2.32.1-1
Hi Alberto, On 05-06-2021 01:52, Alberto Garcia wrote: > So if you are ok with the change of dependencies I will upload it to > unstable and request a new unblock. Ack. But next time, please create a new unblock (pre-approval) request. This bug is closed and your message had a high chance of being missed. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all, On 04-06-2021 06:49, Paul Gevers wrote: > 26 June [Ansgar (ftp)] > 3 July[Ansgar (ftp), Sebastian (release), Paul (release)] > 10 July [Steve (CD) MAYBE , Ansgar (ftp), Paul (release)] > 17 July [Steve (CD), press, Ansgar (ftp), Paul (release)] > 24 July [Steve (CD), press, Ansgar (ftp), Sebastian (release)] > 31 July [Steve (CD), press, Ansgar (ftp), Sebastian (release)] > 7 August [Steve (CD), press, Ansgar (ftp), Sebastian (release)] > 14 August [Steve (CD), press, Ansgar (ftp), Sebastian (release)] With the availability of Adam now known (and some off-list info), we have: 26 June [Ansgar (ftp), Sebastian (release), Adam (release)] 3 July [Ansgar (ftp), Paul (release), Adam (release)] 10 July [Steve (CD) MAYBE , Ansgar (ftp), Paul (release), Adam (release), Graham (release)] 17 July [Steve (CD), press, Ansgar (ftp), Paul (release)] 24 July [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release), Graham (release)] 31 July [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)] 7 August [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)] 14 August [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)] So, what to pick? We still believe that shorter freezes are better for the Debian community as a whole, so Steve can you look at turning your maybe on 10 July into a "lets go for this"? If the answer is no, than lets pick 24 July as the *tentative* release date. Regardless of which of the two we pick, I propose we decide two weeks before if it's going to be final. And, relevant for every maintainer of non-key packages without passing autopkgtests, the full freeze will start two weeks before the *tentative* release. The means that, with traditionally the last week being totally frozen, the last week that packages can migrate *all* packages need manual unblocks by the release team. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989498: unblock: golang-1.15/1.15.9-5
Control: tags -1 - moreinfo Control: tags -1 confirmed Hi Shengjing, On 06-06-2021 08:36, Shengjing Zhu wrote: > On Sun, Jun 6, 2021 at 11:46 AM Paul Gevers wrote: >> On 05-06-2021 13:57, Shengjing Zhu wrote: >>> Please unblock package golang-1.15 Unblocked. >> You're well aware that golang builds statically so normally we're not >> done with just accepting one package. Do we now need to also rebuild >> everything that build depends on golang (I'd expect so)? > > Yes. That's why the compiler is uploaded in unstable, as rebuilding in > unstable is much easier before release. We didn't manage to rebuild > any package in buster for the compiler security update after release. So let's keep this bug open to keep track of this and only close it when all rebuilds have migrated. Please know that I expect the golang team to keep an eye on this too and warn us if anything is going wrong or takes longer than expected. Please refrain from uploading any of the reverse dependencies until their rebuild has migrated. > + one package won't migrate, which is kubernetes, but the > outdated-built-using rebuild script will not pick it up, as it doesn't > have built-using field. (This doesn't mean it doesn't need to be > rebuilt for the compiler security update, but no one cares about this > package). I know that last sentence to be untrue. Did you contact the maintainer to inform him? I'm putting him in CC to make him aware of the CVE's. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all, On 06-06-2021 20:03, Paul Gevers wrote: > With the availability of Adam now known (and some off-list info), we have: > > 26 June > [Ansgar (ftp), Sebastian (release), Adam (release)] > 3 July > [Ansgar (ftp), Paul (release), Adam (release)] > 10 July > [Steve (CD) MAYBE , Ansgar (ftp), Paul (release), Adam (release), >Graham (release)] > 17 July > [Steve (CD), press, Ansgar (ftp), Paul (release)] > 24 July > [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release), >Graham (release)] > 31 July > [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)] > 7 August > [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)] > 14 August > [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)] > > So, what to pick? We still believe that shorter freezes are better for > the Debian community as a whole, so Steve can you look at turning your > maybe on 10 July into a "lets go for this"? If the answer is no, than > lets pick 24 July as the *tentative* release date. Nevermind 10 July. Steve, you can stop contemplating about it. We'll go for 24 July as the *tentative* release date. > Regardless of which of the two we pick, I propose we decide two weeks > before if it's going to be final. So, we'll decide around 10 July. > And, relevant for every maintainer of non-key packages without passing > autopkgtests, the full freeze will start two weeks before the > *tentative* release. The means that, with traditionally the last week > being totally frozen, the last week that packages can migrate *all* > packages need manual unblocks by the release team. And the Full Freeze will start on 10 July too. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all again, On 07-06-2021 23:08, Adam D. Barratt wrote: > On Mon, 2021-06-07 at 20:38 +0200, Paul Gevers wrote: >> Nevermind 10 July. Steve, you can stop contemplating about it. We'll >> go for 24 July as the *tentative* release date. > > Unfortunately I've just discovered that I was given the wrong date for > a family event, so I'm actually going to be AFK for most of the 24th. > :-( > > Apologies for sticking a slight spanner in the works at this stage. Those things happen. It's the price we pay for our bus factors (which we should fix/are fixing). So, if I did all the booking right (including updates from IRC) we now have: 26 June [Ansgar (ftp), Sebastian (release), Adam (release)] 3 July [Ansgar (ftp), Paul (release), Adam (release)] 10 July [Steve + Andy (CD), Paul (release), Adam (release), Graham (release)] 17 July [Steve (CD), press, Ansgar (ftp), Paul (release)] 24 July [Steve (CD), press, Ansgar (ftp), Sebastian (release), Graham (release)] 31 July [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)] 7 August [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)] 14 August [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)] The first available date is 31 July, so let's shift all my dates another week. 17 July: Hard Freeze & confirmation of the release date 31 July: ** tentative ** release date Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989500: unblock eyed3/0.8.10-4
Control: tags -1 moreinfo Hi On Sat, 5 Jun 2021 15:06:31 +0200 Gaetano Guerriero wrote: > Please unblock package eyed3 I haven't looked at the diff yet, but... > Package is not blocked, but it is marked for removal from > testing on 16 Jun and the auto migration period expires on 22 Jun. I have pinged the RC bug. That should reset the autoremoval timer, so the package should migrate on its own. Don't hesitate to remove the moreinfo tag if you're seeing issues. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#987958: buster-pu: package liferea/1.12.6-1+deb10u1
Hi Adam, On 30-05-2021 22:06, Paul Gevers wrote: > On Sun, 2 May 2021 20:23:30 +0200 Paul Gevers wrote: >> [ Reason ] >> It used to be enough to declare the liferea custom scheme as local to >> access resources with a file scheme, but for WebKit2Gtk >= 2.32 it looks >> like it is necessary to register the custom scheme with a handler. >> Although WebKit2Gtk hasn't been updated to 2.32 in stable yet, I >> understand that it will be relatively soon for security support reasons. > > webkit2gtk 2.32.1-1~deb10u1 entered stable today. So this bug is now > impacting liferea users in stable. Upstream now has a blog post about it: https://lzone.de/liferea/blog/Recent-WebKitGTK-HTML-renderer-instabilities?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+LifereaBlog+%28Liferea+Blog%29 I've just uploaded the version I had prepared. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989513: unblock: galera-4/26.4.8-1
Control: tags -1 moreinfo Dear Otto, On 06-06-2021 03:47, Otto Kekäläinen wrote: > Please unblock package galera-4 to fix MariaDB upgrade as reported in #988089. I appreciate a fix for that bug, but did you really have to do that by uploading a new upstream release too? How is the new upstream release related to that bug? > [ Risks ] > Low, leaf package. Nope, the package is a key package. > This also introduces the latest upstream version. It has already been > in Sid for a while without reported regressions, and in general Galera > packages have been very low on regressions. But that is totally not in line with our freeze policy [1][2]. Please revert the upstream release while fixing 988089. Paul [1] https://release.debian.org/bullseye/freeze_policy.html [2] https://release.debian.org/bullseye/FAQ.html OpenPGP_signature Description: OpenPGP digital signature
Bug#987874: [pre-approval] unblock: osspd/1.3.2-12
Hi Ralf, On 03-06-2021 13:00, Ralf Jung wrote: >> Changing compat levels is no longer acceptable for bullseye. Please >> revert. > > Ah, that's a bummer. I was not aware of this policy, sorry for that. > Doing a revert upload sounds like a lot of hassle though that this > package is probably not worth -- so in this case it likely makes more > sense to simply remove the package from testing, and let it re-migrate > after the release. The current testing version (1.3.2-11) is broken with > current PulseAudio, so shipping it as-is makes no sense. If you really think another upload is too much hassle, you could convince us to unblock regardless if you build twice and show with diffoscope that the compat bump doesn't impact the (binary) packages at all. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989540: unblock: git/1:2.32.0-1
Control: tags -1 moreinfo Hi Jonathan, On Sun, 6 Jun 2021 15:56:50 -0700 Jonathan Nieder wrote: > [x] I reviewed all changes and I approve them I hope for you you didn't go over all changes line-by-line: 1089 files changed, 151811 insertions(+), 82910 deletions(-) You're debdiff was so large, that your request didn't reach our lists. At the very least, could you please filter out stuff like Documentation, translations and tests? And verify yourself that that looks sane. Please read our FAQ [1] and see if you can answer the questions we raise there about new upstream releases. > I can make an upload for testing-proposed-updates that only makes > those three changes if you prefer. We prefer to *not* use testing-proposed-updates and in all cases where we won't accept the new upstream release we ask maintainers to rather revert the new upstream release such that we can get the changes via unstable. testing-proposed-updates is nearly exclusively used for no-change uploads where versioned dependencies are picked up that can't migrate to testing. Paul [1] https://release.debian.org/bullseye/FAQ.html OpenPGP_signature Description: OpenPGP digital signature
Bug#988234: unblock: acorn/8.0.5+ds+~cs19.19.27-2
Control: tag -1 moreinfo Hi Yadd, On Thu, 20 May 2021 11:29:15 +0200 Paul Gevers wrote: > Control: tag -1 confirmed moreinfo > > Hi Yadd, > > On 08-05-2021 13:30, Yadd wrote: > > [ Reason ] > > Buster to Bullseye transition needs a real node-acorn package (#986134) > > I pinged ftp on IRC some days ago, but the package didn't land yet. We > need the package in the archive to unblock. Please remove the moreinfo > tag once you receive the notification that the package is processed. I noticed that you removed the moreinfo tag, but because you had to traverse NEW we now have: Not built on buildd: arch all binaries uploaded by x.guim...@free.fr, a new source-only upload is needed to allow migration We can't sensibly binNMU arch:all packages. Can you do an no-change source-only upload to have the binaries build on the buildd please? If not, shout and I can have a stab at it. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#988830: [pre-approval] unblock e2fsprogs
Hi kibi, On 20-05-2021 17:55, Cyril Brulebois wrote: > If that's fine for the release team, I'd be happy to have the package in > unstable so that can be tested via daily builds of the installer (they > pull udebs from unstable). I'm not sure how much testing those daily > builds get from people running arm* systems, but it would be better to > have the fix at least exposed to some testing than just ponder looking > at the source debdiff (I know alignment issues are not my forte…). I'm following up on two bugs reported against the version in unstable, but assuming they're no regressions, how long do you want us to wait until unblocking it? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989037: Bug#988214: fixed in rails 2:6.0.3.7+dfsg-1
Hi Utkarsh On 06-06-2021 06:14, Paul Gevers wrote: > I am hoping it's possible to just downgrade the *dependency* in rails > only, such that the upload can happen via unstable. There is no "direct > bullseye" route. Or do you expect you'll have to make (lots) of changes > to rails to match the right ruby-marcel package? If that's the case, > than ruby-marcel/unstable isn't a drop in replacement for > ruby-marcel/bullseye and I'd expect that ruby-marcel/unstable would need > a versioned Breaks for reverse dependent packages (ruby-activestorage), > but I'm not seeing that. Did your experimenting (as discussed on IRC last week) yield anything? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989695: pre-approval: mono/6.8.0.105+dfsg-3.1
Hi, On 10-06-2021 19:25, Andreas Beckmann wrote: > If you ACK this, I intend to 0-day NMU this to experimental because it > needs NEW processing. Please prod the ftp-masters to get this actually done. We don't have control over ftp-masters *and* I still need some days before I can actually look properly into this (I suspect strongly that other colleagues won't beat me to it). Therefor, I propose you already upload to experimental. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990354: unblock: curl/7.74.0-1.3
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package curl
[ Reason ]
My NMU fixes an RC bug (#989064) where Bernd reported a regression in
the output of the curl -w option. As there's probably a huge amount of
scripts deployed that parse this output, I agreed with the RC status
and uploaded the upstream fix for the issue.
[ Impact ]
Users (including scripts) that expect time to be reported in seconds
will be confused by the answer in microseconds.
[ Tests ]
curl runs a test suite during the build (actually, three times as it
builds three flavors of itself). Also curl has a huge amount of
reverse dependencies with autopkgtest. curl triggered some regressions
in minor flaky tests but by now, we're only waiting for armhf to finish
testing.
[ Risks ]
curl is of course a key package, but the patch is small and comes
straight from upstream.
[ 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 testing
unblock curl/7.74.0-1.3
diff -Nru curl-7.74.0/debian/changelog curl-7.74.0/debian/changelog
--- curl-7.74.0/debian/changelog2021-04-03 14:43:39.0 +0200
+++ curl-7.74.0/debian/changelog2021-06-25 20:59:54.0 +0200
@@ -1,3 +1,11 @@
+curl (7.74.0-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add upstream patch bc7ecc7 so curl -w times shown as seconds with
+fractions (Closes: #989064)
+
+ -- Paul Gevers Fri, 25 Jun 2021 20:59:54 +0200
+
curl (7.74.0-1.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru
curl-7.74.0/debian/patches/fix-regression-microseconds-instead-of-seconds.patch
curl-7.74.0/debian/patches/fix-regression-microseconds-instead-of-seconds.patch
---
curl-7.74.0/debian/patches/fix-regression-microseconds-instead-of-seconds.patch
1970-01-01 01:00:00.0 +0100
+++
curl-7.74.0/debian/patches/fix-regression-microseconds-instead-of-seconds.patch
2021-06-25 20:59:54.0 +0200
@@ -0,0 +1,87 @@
+From bc7ecc71c0c11d22fdbe6415a7945bfc43dc3c33 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg
+Date: Tue, 15 Dec 2020 08:09:29 +0100
+Subject: [PATCH] =?UTF-8?q?too=C4=BA=5Fwriteout:=20fix=20the=20-w=20time?=
+ =?UTF-8?q?=20output=20units?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Fix regression from commit fc813f80e1bcac (#6248) that changed the unit
+to microseconds instead of seconds with fractions
+
+Reported-by: 不确定
+Fixes #6321
+Closes #6322
+---
+ src/tool_writeout.c | 22 +++---
+ 1 file changed, 15 insertions(+), 7 deletions(-)
+
+diff --git a/src/tool_writeout.c b/src/tool_writeout.c
+index c12738c439aa..8b9f590053e5 100644
+--- a/src/tool_writeout.c
b/src/tool_writeout.c
+@@ -106,6 +106,14 @@ static const struct writeoutvar variables[] = {
+0, JSON_NONE}
+ };
+
++static void us2sec(FILE *stream, curl_off_t us)
++{
++ curl_off_t secs = us / 100;
++ us %= 100;
++ fprintf(stream, "%" CURL_FORMAT_CURL_OFF_TU ".%06" CURL_FORMAT_CURL_OFF_TU,
++ secs, us);
++}
++
+ void ourWriteOut(CURL *curl, struct per_transfer *per, const char *writeinfo)
+ {
+ FILE *stream = stdout;
+@@ -190,41 +198,41 @@ void ourWriteOut(CURL *curl, struct per_transfer *per,
const char *writeinfo)
+ case VAR_REDIRECT_TIME:
+ if(CURLE_OK ==
+curl_easy_getinfo(curl, CURLINFO_REDIRECT_TIME_T,
&offinfo))
+- fprintf(stream, "%" CURL_FORMAT_CURL_OFF_TU, offinfo);
++ us2sec(stream, offinfo);
+ break;
+ case VAR_TOTAL_TIME:
+ if(CURLE_OK ==
+curl_easy_getinfo(curl, CURLINFO_TOTAL_TIME_T, &offinfo))
+- fprintf(stream, "%" CURL_FORMAT_CURL_OFF_TU, offinfo);
++ us2sec(stream, offinfo);
+ break;
+ case VAR_NAMELOOKUP_TIME:
+ if(CURLE_OK ==
+curl_easy_getinfo(curl, CURLINFO_NAMELOOKUP_TIME_T,
+ &offinfo))
+- fprintf(stream, "%" CURL_FORMAT_CURL_OFF_TU, offinfo);
++ us2sec(stream, offinfo);
+ break;
+ case VAR_CONNECT_TIME:
+ if(CURLE_OK ==
+curl_easy_getinfo(curl, CURLINFO_CONNECT_TIME_T, &offinfo))
+- fprintf(stream, "%" CURL_FORMAT_CURL_OFF_TU, offinfo);
++ us2sec(stream, offinfo);
+ break;
+ case VAR_APPCONNECT_TIME:
+ if(CURLE_OK ==
+curl_easy_getinfo(curl, CURLINFO_APPCONNECT_TIME_T,
+ &offinfo))
+- fprintf(stream, "%" CUR
Bug#989540: unblock: git/1:2.32.0-1
Hi Jonathan, On 13-06-2021 22:32, Paul Gevers wrote: > On Sun, 6 Jun 2021 15:56:50 -0700 Jonathan Nieder > wrote: >> [x] I reviewed all changes and I approve them > > I hope for you you didn't go over all changes line-by-line: > 1089 files changed, 151811 insertions(+), 82910 deletions(-) > > You're debdiff was so large, that your request didn't reach our lists. > At the very least, could you please filter out stuff like Documentation, > translations and tests? And verify yourself that that looks sane. Please > read our FAQ [1] and see if you can answer the questions we raise there > about new upstream releases. > >> I can make an upload for testing-proposed-updates that only makes >> those three changes if you prefer. > > We prefer to *not* use testing-proposed-updates and in all cases where > we won't accept the new upstream release we ask maintainers to rather > revert the new upstream release such that we can get the changes via > unstable. testing-proposed-updates is nearly exclusively used for > no-change uploads where versioned dependencies are picked up that can't > migrate to testing. > > Paul > > [1] https://release.debian.org/bullseye/FAQ.html Ping... Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989695: pre-approval: mono/6.8.0.105+dfsg-3.1
Control: tags -1 moreinfo Hi Andreas, First off, a huge thanks for the enormous amount of QA work you're doing. It's truly great. Please don't take this reply as a "no", I really just wish to discuss my concerns in the open. On 10-06-2021 19:25, Andreas Beckmann wrote: > mono packaging contains an awful lot of circular dependencies. The biggest > one is [1]. Bugs are open for more than 10 years ... Right. Without a lot of investigation from my side it appears the Debian Mono Group may be a bit understaffed at the moment. I'm CC'ing them nevertheless to allow them to respond. > [1] http://debian.semistable.com/dot/mono-runtime-sgen_testing.png > (copy attached) > > As a "workaround" mono-gac started to mess around with conffiles of > mono-runtime-common, confusing the dpkg database state of the conffile. > => #985066 Noted. Am I correct that the other issues you found and mention below were only found after you tried to fix this issue? In other words, if we leave this (RC buggy) hack in bullseye that the other bugs do not appear? I'm really, really wondering if at this stage of the release we shouldn't just leave this bug in, instead of rushing (albeit piuparts tested) solutions in. Maybe it's best to fix this early in bookworm? > Some background: mono-gac provides gacutil which is called via hooks from > maintainer scripts. The new gacutil does not work with an old version of > the conffile /etc/mono/config from mono-runtime-common => #986275, #986293 > > Thus we need versioned pre-depends and need to reverse the dependency > between mono-gac and mono-runtime-common. (And add a Depends: mono-gac > to all rdepends of mono-runtime-common, only 2 relevant packages) > > To Break the big dependency loop I'm going to drop mono-runtime > dependency from libmono-system-4.0-cil and > libmono-system-configuration4.0-cil - all rdepends of some libmono-*-cil > also depend on libmono-corlib4.5-cil which keeps this dependency. > Then I'm going to move the actual .dll from libmono-corlib4.5-cil to a > NEW package libmono-corlib4.5-core-cil (better name welcome, I think > I'll switch to libmono-corlib4.5-dll) and redirect the > libmono-corlib4.5-cil dependencies from libmono-*-cil on the big cycle > there. > libmono-corlib4.5-cil depends on libmono-corlib4.5-core-cil, so for all > 250+ rdepends outside this big cycle nothing changes, they still get the > corlib+runtime dependency > > We still have several independent dependency cycles between > libmono-*-cil, but these don't seem to cause problems currently. > > I'm attaching both a source and binary debdiff, since dependencies are > going to change ... > > I've run a lot of piuparts install and upgrade tests on these changes > (and will do some more) on amd64 and have stopped encountering mono > related issues ;-) > > If you ACK this, I intend to 0-day NMU this to experimental because it > needs NEW processing. Please prod the ftp-masters to get this actually done. > Then I'll reupload to sid (since the NEW package is arch:all). > > unblock mono/6.8.0.105+dfsg-3.1 > > Andreas > > PS: > I haven't seen any maintainer comment on any of these bugs :-( Hence, explicit in CC now. > PPS: > I have no clue about mono, but I'm confident enough that this patch does > not make the situation worse :-) Yes, but mono is a true key package (not only by the 5% popcon limit as indicated on [2], but also when removing the popcon based key packages; it's needed by meson <- atk1.0 <- d-i), otherwise I might have removed it. Paul [2] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi OpenPGP_signature Description: OpenPGP digital signature
Re: "Applications Menu" bug in testing... see screenshot. Execute does not work. Using Whisker Menu (which I don't like, too 'bulky'... lol)
Hi Rick, Thanks for caring. On 27-06-2021 22:26, Rick Lell wrote: > image.png This list is no bug tracker. Please follow the instructions [1] to file a bug report. Paul [1] https://www.debian.org/Bugs/Reporting OpenPGP_signature Description: OpenPGP digital signature
Bug#990379: unblock: rdiff-backup/2.0.5-2
Control: clone -1 -2 Control: reassign -2 release-notes Control: retitle -2 rdiff-backup protocol changed incompatible Control: close -1 Hi Samuel, On 27-06-2021 23:05, Samuel Thibault wrote: > Please unblock package rdiff-backup unblocked. > rdiff-backup is a sort of rsync-like backup tool. It happens that the > version that will be shipped in Bullseye (2.0.5) has a network protocol > that is incompatible with that of the version that was shipped in Buster > (1.2.8). The details are in https://bugs.debian.org/975270 This sounds worth mentioning in the release notes. Cloned accordingly. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989695: pre-approval: mono/6.8.0.105+dfsg-3.1
Control: tags -1 confirmed Hi Andreas, On 28-06-2021 19:47, Andreas Beckmann wrote: > Control: tag -1 moreinfo I guess you missed a minus here :) Serves me now, so leaving it. > Attached is also the latest version of my proposed patch, > I'm trying to upload this to experimental/NEW tonight. Ok, lets have this than if we can have it processed in time. Please also prod ftp-master after you upload saying this is targeting bullseye. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989599: upgrade issue: apt: fails to upgrade guile-2.2-libs from buster to bullseye
Hi Andreas, On Tue, 15 Jun 2021 14:50:39 +0200 Andreas Beckmann wrote: > This has not been discussed with the libgc maintainers (nor does there > exist a bug, yet). There is: https://bugs.debian.org/988963 with a solution (in buster). > I still think reusing 'libgc1' was a very bad decision (maybe the soname > should have been bumped if there were symbols gone?), and it has > uncovered a problem in apt handling swapping real/virtual > Package/Conflicts on the same name pair. I prefer to update libgc in buster and document this behavior in the release notes. As far as I'm aware, this is a "cosmetic" issue in that after the upgrade where packages are hold back, a second upgrade fixes the issue. If that view of the situation is incomplete, please enlighten us. If that view is correct, lets fix bug 988963. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989599: upgrade issue: apt: fails to upgrade guile-2.2-libs from buster to bullseye
Hi, On 30-06-2021 21:53, Andreas Beckmann wrote: > On 30/06/2021 21.38, Paul Gevers wrote: > In case there is no further buster point release before bullseye, the > fix could be pushed to buster-updates s.t. it is available for the > oldstable-upgrade before the dist-upgrade, at least on sane systems. We'll have to discuss this with the SRM, hence I also wanted to know from you if you experienced worse cases than "just" needing two upgrades instead of one. I'm missing the point about oldstable though. > Should be docuented in the release notes. It's on the release notes radar for a while already: https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;exclude=tags%3Abuster;package=release-notes Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990500: unblock: lxml/4.6.3+dfsg-0.1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Please unblock package lxml [ Reason ] The source of lxml contained a file that's marked as unacceptable by ftp-master and as such a future upload of lxml would hit the auto-reject list. To avoid problems with security uploads, I prefer to fix the issue now. The file was a image shipped with the documentation, which wasn't even used. In the process of fixing this issue, I discovered that the documentation package was nearly empty and didn't contain any documentation. This is fixed by enabling the build of the documentation. [ Impact ] If not unblocked, security or plain pu uploads will have to take remove the file at that time. [ Tests ] The removed file is just an unlinked image. I have checked that the package now contains the documentation files. [ Risks ] Close to 0 risk as it's just removing an image and building documentation files. [ 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 testing unblock lxml/4.6.3+dfsg-0.1 diff -Nru lxml-4.6.3/debian/changelog lxml-4.6.3+dfsg/debian/changelog --- lxml-4.6.3/debian/changelog 2021-03-22 14:31:55.0 +0100 +++ lxml-4.6.3+dfsg/debian/changelog2021-06-26 19:40:37.0 +0200 @@ -1,3 +1,11 @@ +lxml (4.6.3+dfsg-0.1) unstable; urgency=medium + + * Non-maintainer upload + * Repack upstream to drop non-free and unused file (Closes: #988717) + * Build and ship documentation (Closes: #799334) + + -- Paul Gevers Sat, 26 Jun 2021 19:40:37 +0200 + lxml (4.6.3-1) unstable; urgency=high * New upstream version. diff -Nru lxml-4.6.3/debian/control lxml-4.6.3+dfsg/debian/control --- lxml-4.6.3/debian/control 2020-12-07 14:42:24.0 +0100 +++ lxml-4.6.3+dfsg/debian/control 2021-06-26 19:40:37.0 +0200 @@ -9,6 +9,7 @@ python3-setuptools (>= 0.6.29), python3-bs4, python3-html5lib, + python3-lxml , cython3, cython3-dbg, python3-sphinx-autoapi, X-Python-Version: all diff -Nru lxml-4.6.3/debian/rules lxml-4.6.3+dfsg/debian/rules --- lxml-4.6.3/debian/rules 2020-07-17 11:16:59.0 +0200 +++ lxml-4.6.3+dfsg/debian/rules2021-06-26 19:40:37.0 +0200 @@ -24,6 +24,9 @@ touch $@ build3-python%: prebuild python$* setup.py build +ifeq (,$(filter nodoc,$(DEB_BUILD_OPTIONS))) + python$* doc/mkhtml.py doc/html . $(UPSTREAMVER) +endif touch $@ dbg-build3-python%: prebuild python$*-dbg setup.py build Binary files /tmp/nGluINxi3b/lxml-4.6.3/doc/html/flattr-badge-large.png and /tmp/DP0ayk9l1g/lxml-4.6.3+dfsg/doc/html/flattr-badge-large.png differ OpenPGP_signature Description: OpenPGP digital signature
Bug#990515: release.debian.org: buster->bullseye upgrade issue: sshfs is not upgraded due to fuse/fuse3
Hi Andreas, Laszlo,
On 01-07-2021 08:27, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
>
> let's start a discussion here and once we found a package to upgrade,
> turn this into an unblock request.
And let's add the fuse and fuse3 maintainer to the discussion.
> sshfs is sometimes kept at the buster version because of some dependency
> mess of fuse/fuse3.
> This usually shows up in large metapackages like freedombox or kde-full
> with --install-recommends enabled. Probably because there are additional
> dependency paths on fuse.
>
> * sshfs/buster depends on fuse
> * sshfs/bullseye depends on fuse3
> * fuse still exists in bullseye as a real package
> * fuse3/bullseye has Conflicts/Replaces: fuse and a
> versioned Provides: fuse (= ${source:Version})
> Upgrading would require kicking out fuse and installing fuse3 but apt
> does not do that, as so often.
>
> This isn't solved by a followup distupgrade either.
>
> I haven't found a solution adding more Breaks: fuse to various packages
> to solve this cleanly. Naturally I would have suggested to add a
> transitional fuse binary package to src:fuse3 which just
> Depends: fuse3 (= ${binary:Version}) and adjust the Breaks/Replaces in
> fuse3 to fuse (<< 3). src:fuse then should drop its fuse package (or
> rename it to fuse2 while adding a '2' to all filenames).
>
> I'm also not convinced that fuse3 is a real replacement for fuse: it has
> symlinks foo -> foo3 for all binaries and manpages. But the initramfs
> hook only does 'copy_exec /sbin/mount.fuse3 /sbin', it does not care
> about /sbin/mount.fuse
Laszlo, what do you think?
Paul
OpenPGP_signature
Description: OpenPGP digital signature
Bug#990515: release.debian.org: buster->bullseye upgrade issue: sshfs is not upgraded due to fuse/fuse3
Hi, On 01-07-2021 10:03, Michael Biebl wrote: > Related issue: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918984 Right, I forgot about that bug. The issue and "solution" is documented in the release notes. @Andreas, can you confirm that the text there is sufficient for the issues you experience? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990237: unblock: aoetools/36-5
Hi, On 23-06-2021 19:58, Christoph Biedl wrote: > Please unblock package aoetools (as of 36-5) unblocked. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990297: unblock: pyyaml/5.3.1-5
Hi, On 25-06-2021 01:12, Stefano Rivera wrote: > Please unblock package pyyaml unblocked. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990531: unblock: grub2/2.04-19
Control: tags -1 confirmed d-i Hi, On 01-07-2021 14:02, Colin Watson wrote: > Please unblock grub2 2.04-19. This fixes unbootability problems after > certain kinds of grub-install failure, which I think constituted an > important-severity bug at the very least. I did this by resyncing the > grub-install backup/restore patches with what actually landed upstream; > we'd previously had early versions of these that hadn't been entirely > bug-fixed. > > I know that there may be more RC things to be fixed in grub2, but we > might as well get this in. I had a look at this the other day and if my memory recalls correctly, I'm fine with it. But as there's a block-udeb, we need an ACK from kibi (in CC via boot). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990570: unblock: slurm-wlm/20.11.7-1
Control: tags -1 moreinfo Hi, On Fri, 2 Jul 2021 01:12:41 +0200 Gennaro Oliva wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package slurm-wlm 510 files changed, 6706 insertions(+), 5099 deletions(-) Your diff was so large, it didn't even reach the list. > [ Reason ] > > 20.11.6 and 20.11.7 were bugfix and stability releases with no feature > changes. > Please allow this into bullseye. Can you please provide a filter diff that's reviewable to confirm this statement? > [ Impact ] > Fixes CVE-2021-31215 > > [ Tests ] > I have successfully run the same set of standard test I use for each > release. > > [ Risks ] > The software is very stable and one packages (mpich) is built against > its lib. > > [ Checklist ] > [X] all changes are documented in the d/changelog and in NEWS file > [X] I reviewed all changes and I approve them All 6000 lines? > [X] attach debdiff against the package in testing and the relevant > part of the NEWS file > > unblock slurm-wlm/20.11.7-1 Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990630: unblock: fuse3/3.10.3-2
Control: tags -1 d-i Hi On 03-07-2021 07:17, László Böszörményi (GCS) wrote: > [ Other info ] > Builds an udeb and needs a d-i hint as well. So, let's make kibi aware of this too (via boot). Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Hi all, On 04-07-2021 00:42, Colin Watson wrote: > Sorry for my delay - it took me a while to spot the problem. libc6's > postinst does arrange to restart services where needed, but in this case > it doesn't realize that you have the ssh service installed because you > only have the openssh-server package installed, not the ssh metapackage > (i.e. the package with the same name as the service). > > I've proposed > https://salsa.debian.org/glibc-team/glibc/-/merge_requests/3 to fix > this. glibc maintainers, if there's any way to get this into bullseye, > I'm sure it would help avoid some people upgrading remote systems ending > up being unable to fix them if something goes wrong between configuring > libc6 and configuring openssh-server. Also CCing debian-release for > their information, as I know it's pretty late for glibc changes. I think we really want this. I *think* I ran into exactly this issue two days ago when I upgraded my NAS. It's really scary to notice that you can't log into your system and your only connection is the current one running the upgrade. In my case, it was asking questions along the way. I had considered running the upgrade in screen. In the end it look longer than expected and I left my laptop on. If I would have run in screen and disconnected, I would have had no idea what hit me. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990500: unblock: lxml/4.6.3+dfsg-0.1
Control: tags -1 - moreinfo Hi Sebastian, On 04-07-2021 22:01, Sebastian Ramacher wrote: >> diff -Nru lxml-4.6.3/debian/control lxml-4.6.3+dfsg/debian/control >> --- lxml-4.6.3/debian/control2020-12-07 14:42:24.0 +0100 >> +++ lxml-4.6.3+dfsg/debian/control 2021-06-26 19:40:37.0 +0200 >> @@ -9,6 +9,7 @@ >>python3-setuptools (>= 0.6.29), >>python3-bs4, >>python3-html5lib, >> + python3-lxml , >>cython3, cython3-dbg, >>python3-sphinx-autoapi, >> X-Python-Version: all >> diff -Nru lxml-4.6.3/debian/rules lxml-4.6.3+dfsg/debian/rules >> --- lxml-4.6.3/debian/rules 2020-07-17 11:16:59.0 +0200 >> +++ lxml-4.6.3+dfsg/debian/rules 2021-06-26 19:40:37.0 +0200 >> @@ -24,6 +24,9 @@ >> touch $@ >> build3-python%: prebuild >> python$* setup.py build >> +ifeq (,$(filter nodoc,$(DEB_BUILD_OPTIONS))) >> +python$* doc/mkhtml.py doc/html . $(UPSTREAMVER) >> +endif > > Shouldn't this use the just built version of lxml, e.g., by setting the > appropriate PYTHONPATH, instead of the old packaged lxml in python3-lxml? Oh, yes. But as I don't do Python packaging (just didn't happen, I don't object), I didn't know how to do that and I didn't want to spend too much time on it to figure it out (and potentially getting it wrong). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989540: unblock: git/1:2.32.0-1
Hi Jonathan, On 26-06-2021 22:24, Paul Gevers wrote: > Ping... Ping again. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990570: unblock: slurm-wlm/20.11.7-1
Hi, On 06-07-2021 13:03, Gennaro Oliva wrote: >>> [X] I reviewed all changes and I approve them >> >> All 6000 lines? > > I had a quick review to the relevant changes contained in the attached > patch. I'm confused. This line doesn't sound like this is appropriate material for an unblock. We want targeted fixes in bullseye right now, and a "quick review" doesn't sound like you did the appropriate checking. To be clear, you as the requestor of the unblock should make the judgement call if the new version of the package follows the freeze rules [1,2] and convince us of that. We don't have the bandwidth to do this ourselves, we can only try do judge if you made the right call. And to avoid more back and forth, if the new upstream doesn't meet the freeze requirements, please revert the new upstream release (e.g. by using a "+really" version number) and upload with only the CVE fix backported to the version in bullseye. Paul [1] https://release.debian.org/bullseye/freeze_policy.html [2] https://release.debian.org/bullseye/FAQ.html OpenPGP_signature Description: OpenPGP digital signature
Re: how to patch package rhonabwy before bullseye release?
Hi Nicolas, Disclaimer: I haven't looked at the content of your proposed changes at all yet. On 04-07-2021 14:21, Nicolas Mora wrote: > Would you accept a new package in unstable, maybe with a high urgency? > > I can also wait for bullseye release and push the new package in > proposed-updates? If you think this would be proposed-updates material, then we prefer to have it via the regular release. So please upload soon to unstable. and file a normal unblock report (using reportbug makes sure you get all the tags right). Urgencies are currently ignored, so don't really matter. Our documentation is here [1, 2]. Paul [1] https://release.debian.org/bullseye/freeze_policy.html [2] https://release.debian.org/bullseye/FAQ.html OpenPGP_signature Description: OpenPGP digital signature
Bug#990743: unblock: ncbi-entrez-direct/14.6.20210224+dfsg-4
Control: tags -1 confirmed moreinfo Hi Aaron, On 06-07-2021 04:23, Aaron M. Ucko wrote: > [ Introduction / Reason ] > I would like to issue a new ncbi-entrez-direct upload (patch attached) > adjusting two wrapper scripts to account fully for their wrappees' > repertoire of options, or at minimum acknowledging that NCBI's efetch > accepts -docsum as shorthand for -format docsum for the sake of > ncbi-blast+'s get_species_taxids script. > (https://bugs.debian.org/990741 has more details.) Assuming the upload happens shortly, please go ahead. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990743: unblock: ncbi-entrez-direct/14.6.20210224+dfsg-4
Hi, On 08-07-2021 21:06, Aaron M. Ucko wrote: > I should be able to upload around 22:00 UTC. (Also, I take it you're OK > with the full version, since you didn't indicate otherwise.) Thanks much! Yes. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990956: uploading lintian-brush to testing-proposed-updates
Hi Jelmer, On 11-07-2021 19:44, Jelmer Vernooij wrote: > Can I upload a small fix for lintian-brush to testing-proposed-updates to > allow > it to remain in testing? I just found out an old FTBFS bug is still affecting > it in testing, and there's a much newer version in unstable. That's not why we have t-p-u. We really prefer you to revert the new upstream release in unstable (using e.g. +really version number). See also our FAQ [1]. Paul [1] https://release.debian.org/bullseye/FAQ.html OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all, On 08-06-2021 21:30, Steve McIntyre wrote: > On Tue, Jun 08, 2021 at 08:50:55PM +0200, Paul Gevers wrote: >> 31 July: ** tentative ** release date > > Cool, works for me. Pencilled into my calendar now. :-) With less than three weeks to go until the tentative release date, I would love to confirm the date by now, but there is a serious issue with crucial infrastructure (cdbuilder.d.o). Apart from this issue (and what it means for solving the debian-installer blocking issues in time), I'm not aware of other blocking issues, so let's hope the teams involved can recover in time. We'll keep you posted as we learn more. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990965: unblock: liferea/1.13.5-3
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Please unblock package liferea
[ Reason ]
The version of liferea in bullseye is susceptible to bug 990911 where
the application can crash if the user select a specific element (news
bin) in the GUI. What's worse, if a news bin was the last selected item
before upgrading, it will then automatically crash on startup with no
way for the user to recover, except by downgrading.
[ Impact ]
Program crashes, or fails to start after upgrade.
[ Tests ]
I verified manually that I can trigger the crash with the version in
bullseye and that the crash doesn't happen with the patch from upstream
applied.
[ Risks ]
The patch is small and is a move of three lines of existing code to
inside an if(). I'd say the risk is small. The patch comes from upstream
(and is nearly a year ago).
[ 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 testing
unblock liferea/1.13.5-3
Paul
diff -Nru liferea-1.13.5/debian/changelog liferea-1.13.5/debian/changelog
--- liferea-1.13.5/debian/changelog 2021-04-27 20:27:39.0 +0200
+++ liferea-1.13.5/debian/changelog 2021-07-11 21:37:39.0 +0200
@@ -1,3 +1,10 @@
+liferea (1.13.5-3) unstable; urgency=medium
+
+ [ Frédéric Brière ]
+ * Add 0001-Fix-crash-on-selecting-news-bins.patch (Closes: #990911)
+
+ -- Paul Gevers Sun, 11 Jul 2021 21:37:39 +0200
+
liferea (1.13.5-2) unstable; urgency=medium
* Add patch to work with latest webgit2gkt:
diff -Nru
liferea-1.13.5/debian/patches/0001-Fix-crash-on-selecting-news-bins.patch
liferea-1.13.5/debian/patches/0001-Fix-crash-on-selecting-news-bins.patch
--- liferea-1.13.5/debian/patches/0001-Fix-crash-on-selecting-news-bins.patch
1970-01-01 01:00:00.0 +0100
+++ liferea-1.13.5/debian/patches/0001-Fix-crash-on-selecting-news-bins.patch
2021-07-11 21:37:39.0 +0200
@@ -0,0 +1,43 @@
+From dd9ede21cd822989e9fafecadefb4fc410a7c0e7 Mon Sep 17 00:00:00 2001
+From: Lars Windolf
+Date: Fri, 2 Apr 2021 01:22:24 +0200
+Subject: [PATCH] Fix crash on selecting news bins
+
+---
+ src/feed.c | 11 ++-
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/src/feed.c b/src/feed.c
+index 585ed82a..97848f9f 100644
+--- a/src/feed.c
b/src/feed.c
+@@ -165,9 +165,14 @@ feed_add_xml_attributes (nodePtr node, xmlNodePtr
feedNode)
+ xmlNewTextChild (feedNode, NULL, "feedId", node_get_id (node));
+ xmlNewTextChild (feedNode, NULL, "feedTitle", node_get_title (node));
+
+- if (node->subscription)
++ if (node->subscription) {
+ subscription_to_xml (node->subscription, feedNode);
+
++ tmp = g_strdup_printf("%d", node->subscription->error);
++ xmlNewTextChild(feedNode, NULL, "error", tmp);
++ g_free(tmp);
++ }
++
+ tmp = g_strdup_printf("%d", node->available?1:0);
+ xmlNewTextChild(feedNode, NULL, "feedStatus", tmp);
+ g_free(tmp);
+@@ -178,10 +183,6 @@ feed_add_xml_attributes (nodePtr node, xmlNodePtr
feedNode)
+
+ if(feed->parseErrors && (strlen(feed->parseErrors->str) > 0))
+ xmlNewTextChild(feedNode, NULL, "parseError",
feed->parseErrors->str);
+-
+- tmp = g_strdup_printf("%d", node->subscription->error);
+- xmlNewTextChild(feedNode, NULL, "error", tmp);
+- g_free(tmp);
+ }
+
+ xmlDocPtr
+--
+2.30.2
+
diff -Nru liferea-1.13.5/debian/patches/series
liferea-1.13.5/debian/patches/series
--- liferea-1.13.5/debian/patches/series2021-04-27 20:27:39.0
+0200
+++ liferea-1.13.5/debian/patches/series2021-07-11 21:37:39.0
+0200
@@ -1,3 +1,4 @@
debian-example-feeds.patch
www-browser.patch
34d26be00328a68d2f1625c78b54dc168da0648e.patch
+0001-Fix-crash-on-selecting-news-bins.patch
OpenPGP_signature
Description: OpenPGP digital signature
Bug#990956: uploading lintian-brush to testing-proposed-updates
Hi Jelmer, On 11-07-2021 21:47, Jelmer Vernooij wrote: > It's going to be tricky to get this resolved in time before the removal of > lintian-brush from testing. Can you elaborate why it's tricky (not promising anything, but there could be reasons for t-p-u)? The current autoremoval is scheduled for August 8, which is *after* the tentative release date. > Of the reverse dependencies, routine-update can > hopefully be updated easily (I've already pinged Andreas) to skip > lintian-brush > and silver-platter should probably not make it into bullseye (I've just filed > a > removal request for it). I'll handle the removals. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990932: unblock: udpkg/1.20
Control: tags -1 confirmed d-i Hi Steve, On 11-07-2021 12:21, Steve McIntyre wrote: > Please unblock package udpkg unblocked > I've added locking for the status file, so parallel udpkg invocations > will not break the world. This fixes #987368. We definitely want this > fix for Bullseye. I've CC:ed KiBi too. ...but waiting for ack from kibi. (Didn't see the CC, so adding d-boot). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990897: unblock: linux/5.10.46-1
Control: tags -1 d-i Hi, On 10-07-2021 22:15, Salvatore Bonaccorso wrote: > Hi release team, hi Cyril (specifically for d-i) So, let's add him (via d-boot) in. > Please unblock package linux > > It contained a rebase of the 5.10.y series to 5.10.46 upstream and > included the following changes relevant to add additional HW support > and bugfxes. The upstream import to 5.10.46 contained fixes for > various CVEs. Ack. > I guess at this point we want to delay any further 5.10.y imports to > the first bullseye point release, but let me know your toughts on > this. If the tentative release date becomes solid, I think that's a good plan. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990956: uploading lintian-brush to testing-proposed-updates
Hi, On 12-07-2021 01:20, Jelmer Vernooij wrote: > On Sun, Jul 11, 2021 at 09:58:30PM +0200, Paul Gevers wrote: >> On 11-07-2021 21:47, Jelmer Vernooij wrote: >>> It's going to be tricky to get this resolved in time before the removal of >>> lintian-brush from testing. >> >> Can you elaborate why it's tricky (not promising anything, but there >> could be reasons for t-p-u)? The current autoremoval is scheduled for >> August 8, which is *after* the tentative release date. > > There have been updates to the other packages that relate to > lintian-brush - both dependencies (python-tr, debmutate, > upstream-ontologist, buildlog-consultant) and reverse dependencies > ((silver-platter); we'd have to either roll those back in unstable as > well or instead patch lintian-brush with a set of changes to lintian-brush > that isn't really a > roll back. Still not promising anything, but what would be the proposed change in t-p-u? >>> Of the reverse dependencies, routine-update can >>> hopefully be updated easily (I've already pinged Andreas) to skip >>> lintian-brush >>> and silver-platter should probably not make it into bullseye (I've just >>> filed a >>> removal request for it). >> >> I'll handle the removals. Sebastian beat me to it. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990065: unblock: squid-deb-proxy/0.8.15+nmu1
Hi Hideki, Sebastian, On 20-06-2021 16:02, Sebastian Ramacher wrote: >> --- squid-deb-proxy-0.8.15/debian/squid-deb-proxy.install2020-01-10 >> 19:02:40.0 +0900 >> +++ squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.install >> 2021-06-14 23:40:21.0 +0900 >> @@ -1,3 +1,4 @@ >> ../update-libc.d etc/resolvconf/ >> etc/squid-deb-proxy >> init-common.sh usr/share/squid-deb-proxy/ >> +../apparmor-profiles/* etc/apparmor.d/abstractions/squid-deb-proxy/ > > I'm not an apparmor expert, but is this enough? Shouldn't there also be > a profile for the binary that uses this abstraction? @Hideki, can you please respond, this is a concern that you fix is not enough. @Sebastian, Hideki claims it fixes the issue: """ [ Tests ] Tested on KVM bullseye environment, it does not work well without this changes as the bug report says, and patched system works fine. """ so, even without a reply from Hideki, don't we expect bullseye to be better with this change? Or is there a worry you have that I don't see? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990990: unblock: libcgroup/2.0
Hi, On 12-07-2021 18:45, Michael Biebl wrote: > This was already discussed in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022 > > My takeaway from that discussion was, that rdeps of cgroup-tools, would > itself have to be made cgroupv2 aware, especially OpenStack and its > components. That resembles my understanding of that discussion too. > Have those rdeps been tested successfully with libcgroup/cgroup-tools > from experimental? I'm not in favor of doing this transition now. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all, On 11-07-2021 21:11, Paul Gevers wrote: > With less than three weeks to go until the tentative release date, I > would love to confirm the date by now, but there is a serious issue with > crucial infrastructure (cdbuilder.d.o). Apart from this issue (and what > it means for solving the debian-installer blocking issues in time), I'm > not aware of other blocking issues, so let's hope the teams involved can > recover in time. Albeit there is some progress, we think it better for the people involved to now say that we will *not* release on July 31. Unfortunately, that means that we have to start looking for a new date again. Assuming what we'll learn in the upcoming week or two is good, I propose to already start the list below with two weeks after the previous date. Upcoming time is around DebConf, I can imagine it could even be an advantage, especially as that's on-line, let's see. 14 August (day before DebCamp) 21 August (last day of DebCamp) RT: elbrus 28 August (DebConf) RT: elbrus 4 September RT: elbrus 11 September: RT: elbrus Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all, Current overview to check if I got things right and to hopefully trigger more replies. We currently don't have any day yet with all involved teams comfortably present, the one coming closest is 4 September. Somebody from ftp available on 14 august? 14 August (day before DebCamp) RT: Adam Image: Steve, Andy Press: Donald FTP: 21 August (last day of DebCamp) RT: Adam, elbrus Image: Press: 1/2 (not ideal) FTP: 28 August (DebConf) RT: elbrus Image: Press: FTP: Joerg 4 September RT: Adam, elbrus Image: Steve, Andy Press: FTP: Joerg 11 September: RT: Adam, elbrus, Sebastian Image: Andy Press: FTP: Joerg 18 September: RT: Adam, elbrus Image: Andy Press: Donald FTP: Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990956: uploading lintian-brush to testing-proposed-updates
Control: tags -1 confirmed moreinfo On 20-07-2021 00:29, Jelmer Vernooij wrote: >> Still not promising anything, but what would be the proposed change in >> t-p-u? > Please find attached the proposed change. Please note that it only > affects the testsuite. That last note was what I was hoping for. Under the assumption that the upload happens soon (we're hopefully close to releasing), please go ahead. Please remove the moreinfo tag once the upload happened. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990897: unblock: linux/5.10.46-1
Hi Salvatore, On 20-07-2021 20:05, Salvatore Bonaccorso wrote: > We do not have yet the signed packages that said, but once present > ideally the package get's aged as well to have fixes asap in bullseye. As asked on IRC: IIUC it's best to wait until all binaries are in and migrate the set right? So including the linux-signed-(amd64|arm64|i386) binaries. I've added the unblocks and urgents for linux-signed-* and all *but* the urgent for linux. If the answer is: let's migrate as they get in, please, any RT member, urgent linux. If the set arrives before I'm back on line, please, urgent linux. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991372: unblock: glibc/2.31-13
Control: tags -1 confirmed d-i Hi Aurelien, On 21-07-2021 22:31, Aurelien Jarno wrote: > Please unblock package glibc Thanks, waiting for the ACK from kibi. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#990956: uploading lintian-brush to testing-proposed-updates
Control: tags -1 moreinfo Hi Jelmer, On 21-07-2021 00:24, Jelmer Vernooij wrote: > Done, thanks. Hopefully this looks alright. The diff of the package in tpu doesn't look like the one I ACKed. Paul OpenPGP_signature Description: OpenPGP digital signature
Releasing bullseye on 14 August 2021 [Was Re: Finding a tentative bullseye release date]
Hi all, Thanks to the reply from Ansgar, we now have a release date for bullseye: 14 August. For the avoidance of doubt, this is *not* a tentative date anymore. I'll do a proper announcement later today or tomorrow evening. 14 August (day before DebCamp) RT: Adam Image: Steve, Andy Press: Donald FTP: Ansgar Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#989863: debian-installer: Firmware problems in bullseye
Hi Cyril, On 24-07-2021 09:05, Cyril Brulebois wrote: > @RT: I'd be happy to have some feedback from your regarding this > approach; telling people to enable contrib/non-free so that they > can install firmware packages is definitely *not* something I take > lightly, but I'd be happy to have some kind of review there to see > if that looks reasonable at all. I'm not sure there are many > options these days anyway… It's only my opinion, but as it's my understanding too that a lot of hardware just doesn't work great without the contrib/non-free drivers, I think it's sensible to help users with instructions on how to get those. You're not installing them and you're not enabling contrib/non-free, so decent warnings can be given (spirit of free software vs hardware that works well). I understand it's hard to get, but having the confirmation that `nomodeset` actually works for the (or most) black screen issues would obviously be great. Side note: apart from the installation guide, do we think that this warrants a note in the release notes too? > @RT: This would be my preferred approach, and based on cdbuilder coming > back up, plus my recent verifications in a d-i context, I think > this should be manageable in time for the announced release date. > Ideally we would be able to release an RC3 a week from now, letting > us fix any boo-boo in time before mid-August. I assume your ugly backup plan is (near) ready (or really trivial), so can be dropped in at the last moment in case there's set backs? > Thanks for your attention! I've had plenty on my mind, and some > braindump was in order. Sorry it's been *that* long a read. I even read in more than once to get the details right. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991122: unblock: varnish/6.5.2-1
Control: tags -1 moreinfo On 20-07-2021 21:46, Stig Sandbeck Mathisen wrote: > On Mon, Jul 19, 2021 at 10:06:37PM +0200, Graham Inggs wrote: >> On Mon, 19 Jul 2021 at 13:00, Stig Sandbeck Mathisen wrote: >>> Attached is the diff. Changes are the upstream bugfix, as well as two >>> commits in the packaging repository: >> >> Thanks. Please go ahead and upload to unstable, then remove the moreinfo tag >> once it has built. > > Hello Graham, > > Thanks, will do. Bug #991348 has been raised do this upload. What's the proposal out of the current situation? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991512: unblock: flatpak/1.10.2-3 (pre-approval)
Control: tags -1 confirmed moreinfo Hi Simon, On 26-07-2021 10:54, Simon McVittie wrote: > unblock flatpak/1.10.2-3 As we're getting very close to the release, the upload needs to happen soon. If it does, let's have this. Please remove the moreinfo tag once the upload happened. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991703: unblock: openjdk-11/11.0.12+7-2
Hi Emmanuel, On 30-07-2021 14:41, Matthias Klose wrote: > 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. Matthias is asking for an unblock of openjdk-11, but it breaks openjdk-11-jre-dcevm. Are you in the position to fix this soon? As I understand it, this version is a release version. I would have expected from you that you're on top of this and that you would have uploaded openjdk-11-jre-dcevm already. Otherwise I'm not sure if it makes sense to ship openjdk-11-jre-dcevm in a stable release anyways, because it will constantly be broken by newer versions of openjdk-11. Or am I misunderstanding the situation? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991703: unblock: openjdk-11/11.0.12+7-2
Hi, On 01-08-2021 16:02, Emmanuel Bourg wrote: > I've just uploaded openjdk-11-jre-dcevm/11.0.12+7-1 which fixes the issue. > > Should I file an unblock request? Yes, please. Please elaborate on the items I asked last time a bit too, like how the source is literately the same (and if not, how not). Just for the avoidance of doubt. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991555: unblock: wpewebkit/2.32.3-1
Control: tags -1 moreinfo Hi Alberto, On 27-07-2021 15:57, Alberto Garcia wrote: > Please unblock package wpewebkit wpewebkit is blocked behind wpebackend-fdo which was NACK'ed already due to build system changes. Can the upload be done in such a way that that dependency doesn't show up? Can wpebackend-fdo be reverted to unblock wpewebkit? Having said all this, the window to resolve this is closing. Less than one week. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991600: unblock: bind9-libs/1:9.11.19+dfsg-2.1
Control: tag -1 d-i confirmed Hi Cyril, On 28-07-2021 12:40, Adrian Bunk wrote: > Please unblock package bind9-libs > > * Add patch from Jorge Niedbalski to stop redundant DHCP servers > from crashing. (Closes: #968298) > > isc-dhcp is only user of the bind9-libs libraries. > > This patch is in Ubuntu LTS since August 2020. > > unblock bind9-libs/1:9.11.19+dfsg-2.1 This needs your ack. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991830: unblock: linux/5.10.46-4
Control: tags -1 confirmed moreinfo Hi Salvatore, On 02-08-2021 22:19, Salvatore Bonaccorso wrote: > Upstream added in 5.13-rc4 a new kconfig know to diable unprivilged > bpf by default, but without making it irreversible. I cherry-picked > this commit as well, and set BPF_UNPRIV_DEFAULT_OFF, closing #990411. I wonder if this would warrant a NEWS item and if you have time left to squeeze it in. > Would you agree on such a very short timed upload still to be > targetting for bullseye? If all (including magic of signing) can be build and ready for Saturday I think this issue is worth it. Normally you kernel people know very well what you're doing. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991834: unblock: galera-4/26.4.9-1
Control: tags -1 moreinfo Hi On 02-08-2021 23:00, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package galera-4 > > It's a new upstream bugfix release, Otto can probably comment on that. Yes, please. We want totally targeted fixes at this moment. This doesn't sound like one. > Packaging wise it contains the second half of solving the mariadb > upgrade issues (there is a conflicts cycle between galera-3 and galera-4 > and upgrading from buster to bullseye requires switching from galera-3 > to galera-4 ... sometimes the upgrade outcome is an unexpected removal > of mariadb-server - #990708) > > Andreas > > unblock galera-4/26.4.9-1 diff -Nru galera-4-26.4.8/debian/control galera-4-26.4.9/debian/control [...] -Breaks: galera, -galera-3 -Replaces: galera +Breaks: galera-3 (<< 26.4) +Replaces: galera-3 (<< 26.4) What are these versions? The highest version of galera-3 from src:galera-3 is 25.3.34-1. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991845: unblock: libx11/2:1.7.2-1
Control: tags -1 confirmed d-i Hi Cyril, The item below needs your ack. Paul On 03-08-2021 10:54, Timo Aaltonen wrote: > Please unblock package libx11 > > [ Reason ] > The new upstream release fixes regressions in the previous CVE release, > including a segfault in fdesign. (bug 990998) > > [ Impact ] > Regressions remain in bullseye release. > > [ Tests ] > The new version has a commit that fixes a bug with a similar backtrace as > 990998, Matt can verify here that fdesign works with the new libx11. > > [ Risks ] > The upstream changes are small, only three commits, > > [ 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 testing > > [ Other info ] > The diff is filtered to have only changes to the code and packaging, > autotools changes are removed. > > unblock libx11/2:1.7.2-1 > OpenPGP_signature Description: OpenPGP digital signature
Bug#991122: unblock: varnish/6.5.2-1
Hi, On 05-08-2021 20:23, Salvatore Bonaccorso wrote: > Hi Stig, > > On Thu, Jul 29, 2021 at 07:33:39PM +0200, Paul Gevers wrote: >> Control: tags -1 moreinfo >> >> On 20-07-2021 21:46, Stig Sandbeck Mathisen wrote: >>> On Mon, Jul 19, 2021 at 10:06:37PM +0200, Graham Inggs wrote: >>>> On Mon, 19 Jul 2021 at 13:00, Stig Sandbeck Mathisen >>>> wrote: >>>>> Attached is the diff. Changes are the upstream bugfix, as well as two >>>>> commits in the packaging repository: >>>> >>>> Thanks. Please go ahead and upload to unstable, then remove the moreinfo >>>> tag >>>> once it has built. >>> >>> Hello Graham, >>> >>> Thanks, will do. >> >> Bug #991348 has been raised do this upload. What's the proposal out of >> the current situation? > > Though probably too late now for this? (I assume we will face the same > problem for varnish to be released either via bullseye-security or > bullseye-pu?) I think the question is, are the varnish-modules incompatible due to the CVE fixes, or due to other changes included in the upload. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991811: unblock: libapache2-mod-auth-openidc/2.4.9-1
Hi Christopher, On 02-08-2021 13:33, Christoph Martin wrote: > Please unblock package libapache2-mod-auth-openidc > > currently the version 2.4.4.1-2 of libapache2-mod-auth-openidc is in > testing/bullseye . Some days ago four CVE security bugs were published > which are fixed in version 2.4.9 . > > The fix to CVE-2021-32791 looks quite big, so that I think it is not > safe to backport it to 2.4.4.1 like the others could be. > > I uploaded the latest upstream (2.4.9) rather than try to > backport the fixes to 2.4.4. It's *very* late in the freeze so I need an answer *real soon*. You didn't tell us how you tested the package, how upstream tested the changes and how you *judge* the changes between bullseye and sid. I can't estimate the risk by myself. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991831: unblock: mat2/0.12.1-3
Hi Georg, On 06-08-2021 11:07, Georg Faerber wrote: > > On 21-08-06 08:32:20, Paul Gevers wrote: >> It's too late for changes like this one. > > Is this due to mat2 being a key package? That's part of the equation, yes. > Besides, would this potentially accepted in 11.1? I won't speak for SRM, but I would expect so. Tip: reportbug from bullseye has a better template for unblock and p-u bugs than buster. Please be verbose on impact, tests and risks if/when you file a p-u bug so that SRM can properly assess the gain vs risks. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#991961: golang-1.15: CVE-2021-36221
Hi Shengjing, On 06-08-2021 22:01, Shengjing Zhu wrote: > Should we fix it before the bullseye release? No, at least not in 11.0. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#970675: [Openjdk] Bug#970606: src:openjdk-*: autopkgtest times out on Debian/Ubuntu infrastructure
Control: retitle -1 enable per-package timeout exceptions Control: severity -1 wishlist Control: tags -1 = Hi debci co-maintainers, On Mon, 21 Sep 2020 11:43:06 +0200 Matthias Klose wrote: > On 9/19/20 9:16 PM, Paul Gevers wrote: > > Source: openjdk-15 > > Version: 15+36-1 > > Severity: serious > > Tags: sid bullseye > > X-Debbugs-CC: debian...@lists.debian.org > > User: debian...@lists.debian.org > > Usertags: timeout > > > > Dear maintainers, Matthias, > > > > For a long time, the autopkgtests of openjdk-* have been failing on the > > ci.debian.net infrastructure and they are currently blacklisted because > > they time out and thus fail. As can be seen on the Ubuntu autopkgtest > > framework, this is no different for openjdk-15 [1] and some recent try > > outs [2,3] show it's still the case on the Debian infrastructure as > > well. Due to the failure/blacklist, openjdk-15 is not migrating to > > testing. Can you please fix the autopkgtest to not time out on our > > infrastructure? > > > > If you need help investigating the situation on our infrastructure, > > don't hesitate to contact us on debian...@lists.debian.org or on #debci. > > I don't think that referring to the Ubuntu autopkg testers is helping here. I > couldn't find any documentation on the timeout settings for the Debian > infrastructure, for both amd64 and arm64. I think it would help to document > these constraints (and yes, Ubuntu doesn't document those either). Apparently > the very same tests don't time out on the buildds. > > Unsure if you want to track that under the release.d.o meta issue. There was more follow-up in the original bug, but it boils down to: it would be nice if we could have some exceptions for packages where the tests structurally take longer and the effort to fix/split that is too big. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#982598: incomplete logs for autopkg tests
Control: reassign -1 debci Control: retitle -1 trunkate huge logs at the start instead of the end Hi, On Fri, 12 Feb 2021 20:35:11 +0100 Paul Gevers wrote: > reassign -1 debci Oops. > Hi Matthias, > > On 12-02-2021 10:54, Matthias Klose wrote: > > Package: release.debian.org > > It's not the release team that runs ci.debian.net. Reassigning > appropriately. > > > As seen with glibc autopkg tests [1], the Debian CI infrastructure doesn't > > store > > complete build logs, cutting these to 20MB (uncompressed), resulting in > > ~450k > > compressed logs. This might not be important for successful tests, but it > > doesn't provide any information for failed tests, as the summary at the end > > is > > always cut. Looking at the Ubuntu CI testers, you see that the glibc log > > for a > > successful test can reach 150MB, compressed 3.5GB [2]. With a glibc patch > > to > > not stop on test failures with the first pass [3], logs for failed tests can > > also reach that size. > > > > The outcome of tests is used by the release team to make decisions about the > > upcoming release [4]. Pointing out to a failed log which doesn't provide > > useful > > information is not helpful, and does cost volunteer time to analyze. In > > this > > case it turned out to be the flaky test infrastructure, and retries > > resulted in > > a successful test. Good luck with that for a real regression ... > > > > As pointed out in another context, "machine time is cheap, volunteer time is > > not" [5], as well as machine storage is cheap compared to volunteer time, so > > please stop cutting the autopkg test logs. > > Unfortunately, we're hitting infrastructure issues if we don't cap the > logs [1]. However, I think we should save the last part (and not the > first part) if we have to cap, because normally the failure happens in > the end. > > Paul > > [1] > https://salsa.debian.org/ci-team/debci/-/commit/9240d93a3e8a017c303d4d1604808fbc1d0f > OpenPGP_signature Description: OpenPGP digital signature
Bug#992371: transition: opensubdiv
Control: tags -1 confirmed moreinfo Hi Matteo, On 17-08-2021 23:08, Matteo F. Vescovi wrote: > Following advice/request from fellow DD elbrus, I'm filing this > transition bug report to track down the one-package transition of > opensubdiv library. Thanks. > The only reverse dependency for osd is blender, as in [1]; > I've already test-built it to check any FTBFS and it builds fine. > > Thanks for your time and patience. Please go ahead. As you mentioned on IRC that you also maintain blender, do you intent to upload that too, or should we schedule the binNMU's as normal? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1
Hi, On 22-08-2021 14:58, Aurelien Jarno wrote: > The alternative is to read the release notes and upgrade openssh-server > before upgrading the full system. That would be this paragraph: https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#ssh-not-available It would be good if we could drop that. For what it's worth (I'm not the SRM), I agree with this fix. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#992787: release.debian.org: state/autopkgtest-results.cache keeps on growing
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: britney
I'm filing this bug to remind myself (and others) that britney never
cleans up its autopkgtest-results.cache file. Today I used an
out-of-band script to reduce the file a bit (from 529M to 50M), but
britney should do that somehow by itself.
As far as I understand, this isn't so much an issue for Ubuntu because
they start over again with each release. IIRC we could do that as well
as it would be just a bit more churn at the start of the release, so
it's probably smarter to drop results of versions that don't exist
anymore in the involved suites.
Paul
-rw-rw-r-- 1 release debian-release 50M aug 23 11:10 autopkgtest-results.cache
-rw-rw-r-- 1 release debian-release 529M aug 23 10:13
autopkgtest-results.cache.old
(Ugly) Code used
elbrus@respighi:~$ cat bin/strip-britney-autopkgtest.cache
#!/usr/bin/python3
import json
import time
from copy import deepcopy
ref_time = round(time.time()) - 150 * 86000
with open('/home/release/britney/state/autopkgtest-results.cache') as f:
test_results = json.load(f)
test_results_new = deepcopy(test_results)
for (trigger, trigger_data) in test_results.items():
for (src, results) in trigger_data.items():
for (arch, result) in results.items():
if result[3] < ref_time:
del test_results_new[trigger][src][arch]
if len(test_results_new[trigger][src]) == 0:
del test_results_new[trigger][src]
if len(test_results_new[trigger]) == 0:
del test_results_new[trigger]
with open('/home/elbrus/autopkgtest-results.cache.new', 'w') as f:
json.dump(test_results_new, f, indent=2)
Bug#991811: unblock: libapache2-mod-auth-openidc/2.4.9-1
user release.debian@packages.debian.org usertag 991811 = pu tags 991811 = buster reopen 991811 retitle 991811 buster-pu:package libapache2-mod-auth-openidc/2.4.9-1~deb10u1 (pre-approval) thanks Hi Christoph, On 24-08-2021 13:10, Christoph Martin wrote: > @Release Team: What do you recommend? This bug was closed, so most communication wasn't really visible in the SRM workflow. I hope I got the meta info right now. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991919: Bioconductor API Bump to 3.13
Hi Andreas, On 26-08-2021 07:45, Andreas Tille wrote: > Hi Dylan, > > On Sun, Aug 15, 2021 at 01:17:29PM +0200, Andreas Tille wrote: >> Hi, >> >> On Sun, Aug 15, 2021 at 10:01:21AM +0200, Dylan Aïssi wrote: >>> >>> The transition tracker is on at >>> https://release.debian.org/transitions/html/r-api-bioc-3.13.html >>> >>> We are now waiting for the green-light from the release team (at >>> https://bugs.debian.org/991919) to start the transition of >>> bioconductor packages. >> >> Thanks for triggering this. Meanwhile I'm starting upgrading >> r-cran-packages from the end of the alphabeth (as traveling >> connection permits). > > The transition page seems to be setup by the release team. When > do you plan to start the transition? If this question is to the release team, than the following question we asked earlier requires an answer: > What's the status wrt. to the reverse dependencies. Do those that are > binNMU-able build against the new version? Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Message from thin...@riseup.net
Hi Thinker, On 26-08-2021 18:37, thin...@riseup.net wrote: > 您好， > > 請問 Debian 11 的少兒編程軟體會跟進官方網站進行更新嗎？從 Debian 9 開始 > 關注，至今似乎沒看到最新版本的釋出。 > > 謝謝！ Google translate made this out of it: """ Hello, Will the children's programming software of Debian 11 follow the official website for updates? Since Debian 9 started to pay attention, it seems that the latest version has not been released. Thanks! """ If you're talking about scratch, IIRC there hasn't been a stand-alone program for Linux anymore. If you want to know more about the scratch package, I suggest to ask the maintainer: scra...@packages.debian.org. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: careless upload of Erlang v24 without a transition tracking with the release team (was: rabbitmq-server fails to start after erlang v24 update)
Hi Antonio, Thomas, On 27-08-2021 21:58, Antonio Terceiro wrote: > One thing that happens when you do this type of change without > coordination is that all CI pipelines on unstable where rabbitmq-server > is installed are now broken. For example all merge requests against > debci at the moment have their tests in "failed" status. This creates > unnecessary noise for a lot of people. rabbitmq-server already got an update, so unstable should be fine (if not, shout (or better, file bugs)). I expect you mean testing, as I think that the point is that erlang already migrated before the issue was detected, otherwise an RC bug would have prevented the migration. That's why it was suggested earlier that rabbitmq-server should grow an autopkgtest as that have would prevented the migration. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: careless upload of Erlang v24 without a transition tracking with the release team (was: rabbitmq-server fails to start after erlang v24 update)
Hi, Sorry my previous message was weird. On 27-08-2021 22:11, Paul Gevers wrote: > On 27-08-2021 21:58, Antonio Terceiro wrote: >> One thing that happens when you do this type of change without >> coordination is that all CI pipelines on unstable where rabbitmq-server >> is installed are now broken. For example all merge requests against >> debci at the moment have their tests in "failed" status. This creates >> unnecessary noise for a lot of people. > > rabbitmq-server already got an update, so unstable should be fine (if > not, shout (or better, file bugs)). I expect you mean testing, as I > think that the point is that erlang already migrated before the issue > was detected, otherwise an RC bug would have prevented the migration. > > That's why it was suggested earlier that rabbitmq-server should grow an > autopkgtest as that have would prevented the migration. What I should have said: we could have prevented migration of erlang until the reverse dependencies were ready by having an RC bug on erlang. That would have been totally appropriate if it would have lasted an reasonable time. I *think* rabbitmq-server has problems migrating now *because* erlang migrated, but that should clear up once the references are tested again. However, it *also* has issues with being uninstallable. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#992028: transition: libidn
Hi On 30-08-2021 21:34, Adrian Bunk wrote: > britney (testing migration software) used to be a bit too liberal on > letting things migrate, andthere were packages migrating to testing > despite a binary-all FTBFS (sometimes noone notices for months when a > -doc package is missing). That would be bug #887060, the bug report is still open. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: BUG: "bookworm" netboot image still references "bullseye" release
Hi Christoph,
On 31-08-2021 14:30, Christoph Sarnowski wrote:
> Hello Release-Mailinglist,
Our mailing list doesn't work well for plain mail as the amount of (bug)
traffic is very high. A bug report works better to avoid it failing
through the cracks.
> I stumbled upon this "bug" using di-netboot-assistant and thought that
> this mailing list might be the best
I very much doubt it, d-i is done over at d-boot.
> point of contact, feel free to teach me otherwise if I am mistaken :)
$(reportbug debian-installer)
> What I tried:
>
> - Download
> https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/netboot.tar.gz
>
>
> - Extract tar archive
>
> - Run "zcat debian-installer/amd64/initrd.gz | grep -c bookworm"
>
> Output: "0" (i.e. no references to "bookworm" inside the initrd)
>
> - Run "zcat debian-installer/amd64/initrd.gz | grep -c bullseye"
>
> Output: "13" (i.e. still a lot of references to "bullseye" inside the
> initrd)
I think that's to be expected, but people over at d-boot can probably
confirm my understanding. There has not been an update of the installer
after the bullseye release, so the installer doesn't know yet that the
release happened. It's the same for quite some "infrastructure" packages
I'd expect.
> One of the results of those references is that the netboot image
> searches for preseed.cfg files on the tftp server under a directory of
> "bullseye".
>
> If I provide a preseed file there, the installer reports a "Bad archive
> mirror" ("mirror does not support the specified release (bullseye)"). My
> guess is that the release file is checked for both Suite and Codename,
> and since "bullseye" is not "testing" anymore, it always fails.
>
>
> Expected Result:
>
> - the bookworm initrd does search for preseed.cfg under "bookworm" and
> accept debian mirrors as valid.
I wonder if that's a fair expectation so soon after the release, but I
defer to d-boot.
Paul
OpenPGP_signature
Description: OpenPGP digital signature
Re: BUG: "bookworm" netboot image still references "bullseye" release
Hi, On 31-08-2021 22:10, Christoph Sarnowski wrote: > Thanks for your reply! I will give it a little more time, then use > "reportbug debian-installer" to report it. I wasn't sure if reporting on > the netboot image should go that way, as it is not part of an > installable debian package. Sorry, you're right. I should probably go to debian-installer-netboot-images (aka dini or d-i-n-i). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#991919: List of all packages in BioConductor transition dependency level 1 failing due issue with either RUnit or testthat
Hi Andreas,
On 02-09-2021 13:12, Andreas Tille wrote:
> I did added an info about all those packages of level 1 that are failing
> either due to RUnit or testthat issues and here is a manually edited
> `grep -A8 '/jobs/' r-bioc-*/debian/changelog` on my local disk:
>
> r-bioc-biocparallel/debian/changelog: TODO:
> https://salsa.debian.org/r-pkg-team/r-bioc-biocparallel/-/jobs/1898498
> r-bioc-biocparallel/debian/changelog- >
> BiocGenerics:::testPackage("BiocParallel")
> r-bioc-biocparallel/debian/changelog- Error in library("RUnit", quietly =
> TRUE) :
> r-bioc-biocparallel/debian/changelog-there is no package called ‘RUnit’
> r-bioc-biocparallel/debian/changelog- Calls: -> library
> r-bioc-biocparallel/debian/changelog- Execution halted
I only checked this one.
> The packages in question are mentioned as Test-Depends and I have no
> idea why these are not found.
No, it's the autodep8 one that fails, not the one mentioned in
d/t/control. I don't recall of the top of my head how you can enhance
autodep8, but $(man autodep8) should come to the rescue.
Paul
OpenPGP_signature
Description: OpenPGP digital signature
