Bug#948191: nmu: vlc_3.0.8-0+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: binnmu nmu vlc_3.0.8-0+deb10u1 . ANY . buster . -m "Rebuild to tighten libmatroska6v5 dependency." --extra-depends "libmatroska6v5 (>= 1.4.9-1+deb10u1)" nmu mkvtoolnix_31.0.0-1 . ANY . buster . -m "Rebuild to tighten libmatroska6v5 dependency." --extra-depends "libmatroska6v5 (>= 1.4.9-1+deb10u1)" As a followup to #946864 (buster-pu: package libmatroska/1.4.9-1+deb10u1), vlc and mkvtoolnix should be rebuilt to tighten their libmatroska6v5 dependency. Is that syntax with --extra-depends correct? I vaguely remember seeing it in other requests, but it's missing in wanna-build.txt. Andreas
Re: [Pkg-rust-maintainers] rust ecosystem worries of a release team member
Hello, Le 04/01/2020 à 17:02, Paul Gevers a écrit : Dear rust maintainers, I should have probably contacted you earlier, but better now than latter. I think it is time to align between the rust maintainers and the release team how we (ideally you without needing our assistance) can manage the rust stack in testing (and thus in unstable). The last couple of weeks I have watched the rust uploads a bit, as I'd like thunderbird (with several CVE fixes) to migrate to testing. It has been blocked since the beginning of November due to rust dependencies that keep changing [1]. Honestly, (shame on me) I didn't pay much attention to the cbindgen migration or other migrations of rust binaries. Mostly because when I look at the transition dashboard, I don't understand why they are blocked. For example: fd find is blocked by https://qa.debian.org/excuses.php?package=rust-ansi-term Also because we are doing (too?) many changes. Anyway, sorry about that, I will try to make cbindgen migrated asap! Sylvestre
rust ecosystem worries of a release team member
Dear rust maintainers, I should have probably contacted you earlier, but better now than latter. I think it is time to align between the rust maintainers and the release team how we (ideally you without needing our assistance) can manage the rust stack in testing (and thus in unstable). The last couple of weeks I have watched the rust uploads a bit, as I'd like thunderbird (with several CVE fixes) to migrate to testing. It has been blocked since the beginning of November due to rust dependencies that keep changing [1]. It has made me worry a bit, as it seems to point at a very strict relation between rust packages (including Build-Using) than make migration to testing difficult as they need to migrate as a together. This becomes a release risk when we get nearer to the release freeze if not managed well. I'd like to know, are you coordination your uploads such that rust packages can migrate to testing in a reasonable time frame? Are you aware of the impact your work has on high profile (with relatively high security risk) packages like thunderbird and firefox? As thunderbird should really migrate some time soon, are you aware of the missing pieces for that to happen and share that with us? If possible, can you please avoid uploading updates that can wait a bit and that interfere with the required stack? Paul [1] Now thunderbird is blocked by rust-cbindgen (last version migrated in September with uploads since October), which is blocked by rust-syn (last version migrated in July, with new uploads since August). Involved is rust-proc-macro2 (last version migrated in July, with new uploads since August (and currently triggers an autopkgtest regression)), rust-unicode-xid (which has been trying to migrate to testing since August), rust-quote (trying to migrate since August). And I may be missing others. rustc was involved at some moment, cargo was involved (and FTBFS for some time) etc... signature.asc Description: OpenPGP digital signature
Processed: Re: RFS Not Needed
Processing control commands:
> reopen -1
Bug #947464 {Done: Michael Lustfield }
[release.debian.org] buster-pu: gnome-maps/3.30.3.1-1+deb10u1
Bug reopened
Ignoring request to alter fixed versions of bug #947464 to the same values
previously set
--
947464: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947464
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#947464: RFS Not Needed
Control: reopen -1 Hi Michael, On Fri, 3 Jan 2020 22:26:35 -0600 Michael Lustfield wrote: > Thanks for your interest contributing to Debian. > > Unfortunately, the packages you built are not DFSG-free and have additional > problems that would prevent them from being included in Debian. Check out the I don't think you wanted to close a buster-pu bug, but got the wrong bug number. Andreas
Processed: reassign 947979 to release.debian.org, retitle 947979 to transition: enchant-2 ..., affects 947979
Processing commands for cont...@bugs.debian.org: > reassign 947979 release.debian.org Bug #947979 [src:enchant-2] enchant-2: Consider requesting a transition for enchant1->2 Bug reassigned from package 'src:enchant-2' to 'release.debian.org'. No longer marked as found in versions enchant-2/2.2.7+repack1-1. Ignoring request to alter fixed versions of bug #947979 to the same values previously set > retitle 947979 transition: enchant-2 Bug #947979 [release.debian.org] enchant-2: Consider requesting a transition for enchant1->2 Changed Bug title to 'transition: enchant-2' from 'enchant-2: Consider requesting a transition for enchant1->2'. > user release.debian@packages.debian.org Setting user to release.debian@packages.debian.org (was bi...@debian.org). > usertags 947979 + transition There were no usertags set. Usertags are now: transition. > affects 947979 + enchant enchant-2 Bug #947979 [release.debian.org] transition: enchant-2 Added indication that 947979 affects enchant and enchant-2 > thanks Stopping processing here. Please contact me if you need assistance. -- 947979: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947979 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
