NEW changes in stable-new
Processing changes file: debian-installer_20190702+deb10u3_amd64.changes ACCEPT Processing changes file: debian-installer_20190702+deb10u3_armel.changes ACCEPT Processing changes file: debian-installer_20190702+deb10u3_armhf.changes ACCEPT Processing changes file: debian-installer_20190702+deb10u3_ppc64el.changes ACCEPT
NEW changes in oldstable-new
Processing changes file: debian-installer_20170615+deb9u8_ppc64el.changes ACCEPT
NEW changes in oldstable-new
Processing changes file: debian-installer_20170615+deb9u8_amd64.changes ACCEPT Processing changes file: debian-installer_20170615+deb9u8_armel.changes ACCEPT Processing changes file: debian-installer_20170615+deb9u8_armhf.changes ACCEPT Processing changes file: debian-installer_20170615+deb9u8_i386.changes ACCEPT Processing changes file: debian-installer_20170615+deb9u8_mips.changes ACCEPT Processing changes file: debian-installer_20170615+deb9u8_mips64el.changes ACCEPT Processing changes file: debian-installer_20170615+deb9u8_mipsel.changes ACCEPT
NEW changes in stable-new
Processing changes file: debian-installer_20190702+deb10u3_i386.changes ACCEPT Processing changes file: debian-installer_20190702+deb10u3_mips.changes ACCEPT Processing changes file: debian-installer_20190702+deb10u3_mips64el.changes ACCEPT Processing changes file: debian-installer_20190702+deb10u3_mipsel.changes ACCEPT
NEW changes in stable-new
Processing changes file: debian-installer_20190702+deb10u3_arm64.changes ACCEPT
NEW changes in stable-new
Processing changes file: debian-installer_20190702+deb10u3_s390x.changes ACCEPT
NEW changes in oldstable-new
Processing changes file: debian-installer_20170615+deb9u8_arm64.changes ACCEPT Processing changes file: debian-installer_20170615+deb9u8_s390x.changes ACCEPT
Bug#948786: buster-pu: package apt-cacher-ng/3.2.1-1 pre-approval
On Mon, 2020-02-03 at 21:05 +0100, Eduard Bloch wrote: > Hallo, > * Adam D. Barratt [Tue, Jan 28 2020, 10:28:08PM]: > > > > I can, of course, convert all that into debian/patches/XXX but > > > honestly, that would really feel like greenwashing. > > > > > > The changes reported here can be reviewed at > > > https://salsa.debian.org/blade/apt-cacher-ng/commits/temp/debian-merge > > > , > > > starting with the commit from 2019-12-20. > > > > Those look OK as individual commits, thanks. For completeness, > > could we > > please have a finalised source debdiff of the built source package, > > compared to current stable? > > Of course, attached. I noticed that you also uploaded. Note that proposed-updates is currently frozen in preparation for the point releases on Saturday, so the package won't be processed until some point after that happens. Regards, Adam
Bug#949187: libgcc_s breakage Re: Bug#949187: transition: python3.8
Matthias Klose wrote: On 2/3/20 8:22 PM, Simon McVittie wrote: >> Meanwhile, multiple packages seem to FTBFS on s390x with the new libgcc_s (I've just opened the bug for that, so no bug number known yet), which is going to limit the ability to get things into testing. please retry your package builds. it's fixed in unstable. Do you mean #950525? If so, you might need to wait a few hours because the fix (gcc-9 9.2.1-28) is still being built. When it is ready, please retry pandas and statsmodels in experimental. (DMs can't do self-service give-backs.)
NEW changes in oldstable-new
Processing changes file: debian-installer_20170615+deb9u8_source.changes ACCEPT
NEW changes in stable-new
Processing changes file: debian-installer_20190702+deb10u3_source.changes ACCEPT
Re: [Pkg-rust-maintainers] rust ecosystem worries of a release team member
On 2/3/20 2:57 PM, Carsten Schoenert wrote: > Hi, > > Am 03.02.20 um 13:08 schrieb Sylvestre Ledru: > ... >> I have been told that the transition of one of the build-dep is blocked by >> packages blocked in NEW... >> Not sure which one. > > this is more or less what I mean, we should get clearance about the root > of problems. Hi Carsten, I also talked to elbrus on MiniDebCamp in Brussels. He explained to me some details about the migration process I didn't understand before. This will help us to identify the cause of some blockers by looking up the information in the britney log. As far as I could trace it, this leads to the packages listed in https://people.debian.org/~infinity0/rust/debian-testing.txt Most of the times when I take a detailed look on why it doesn't migrate, it leads to one of the few packages that currently are in NEW. I don't have the time right now to include it in this mail, but if desired I will assemble the list of required packages that are currently in NEW as soon as I find the time (hopefully tomorrow). A special case is the rust-compiler-builtins source package that has been rejected by NEW before due to unclear license information. https://ftp-master.debian.org/new/rust-compiler-builtins_0.1.23-1.html says: > See discussion: > https://github.com/rust-lang/compiler-builtins/issues/307 > https://github.com/rust-lang/libm/issues/215 There is another issue that might need to be resolved that affects mips[64]el, which is present in rustc (#950583) or possibly one of its deps) surfacing in one of our crate packages (#950337). Due to that we might be keeping versions in mips[64]el testing that block upgrades. This can be seen in the rust transition tracker https://release.debian.org/transitions/html/rust.html where a whole lot of packages can not be built in mips[64]el due to this directly or transitively depending on the affected package. >> We already started a discussion with the Debian release management team to >> simplify the acceptation of >> packages already existing in the archive but with a new binary coming. That is good to hear and would facilitate the procedure of updating existing crates significantly. Wolfgang.
Bug#948786: buster-pu: package apt-cacher-ng/3.2.1-1 pre-approval
Hallo,
* Adam D. Barratt [Tue, Jan 28 2020, 10:28:08PM]:
> > I can, of course, convert all that into debian/patches/XXX but
> > honestly, that would really feel like greenwashing.
> >
> > The changes reported here can be reviewed at
> > https://salsa.debian.org/blade/apt-cacher-ng/commits/temp/debian-merge ,
> > starting with the commit from 2019-12-20.
>
> Those look OK as individual commits, thanks. For completeness, could we
> please have a finalised source debdiff of the built source package,
> compared to current stable?
Of course, attached.
Although, there are a couple of changes which I added on top:
a) removing -Wl,threads from considered linker options. That's a non-functional
change, supposed to counteract FTBFS on mipsel/mips64el which I had experienced
recently (there is a similar workaround in Testing, which detects mipsel
explicitly, but this change simply removed -Wl,threads completely for all
architectures which is the safer option, IMHO)
b) upstreaming the fix of #928957 (this was approved last year for Stable
already, the code just wanders from debian-patch into upstream change)
BTW, there is one remaining change in the Debian diff on the systemd file which
I will keep as is. It existed already in Stable. Not critical and not that
important, and might be upstreamed in Sid, sooner or later.
Best regards,
Eduard.
diff -Nru apt-cacher-ng-3.2/CMakeLists.txt apt-cacher-ng-3.2.1/CMakeLists.txt
--- apt-cacher-ng-3.2/CMakeLists.txt 2018-09-07 15:02:18.0 +0200
+++ apt-cacher-ng-3.2.1/CMakeLists.txt 2020-02-03 19:54:57.0 +0100
@@ -58,6 +58,8 @@
if(NOT DEFINED(RUNDIR))
set(RUNDIR "/run")
endif()
+set(SOCKET_PATH "${RUNDIR}/${PACKAGE}/socket")
+
# carefully splicing of command line arguments, even from lists
macro(_append varname)
@@ -106,7 +108,7 @@
_append(ACNG_CXXFLAGS -fvisibility-inlines-hidden)
endif()
-foreach(linkarg -Wl,--as-needed -Wl,-O1 -Wl,--discard-all -Wl,--no-undefined -Wl,--build-id=sha1 -Wl,-fuse-ld=gold -Wl,--threads)
+foreach(linkarg -Wl,--as-needed -Wl,-O1 -Wl,--discard-all -Wl,--no-undefined -Wl,--build-id=sha1 -Wl,-fuse-ld=gold)
STRING(REGEX REPLACE "=|-|," "" optname "${linkarg}")
set(CMAKE_REQUIRED_FLAGS "${linkarg}")
CHECK_CXX_COMPILER_FLAG("" "LD_${optname}")
diff -Nru apt-cacher-ng-3.2/ChangeLog apt-cacher-ng-3.2.1/ChangeLog
--- apt-cacher-ng-3.2/ChangeLog 2018-09-07 15:02:18.0 +0200
+++ apt-cacher-ng-3.2.1/ChangeLog 2020-02-03 19:54:57.0 +0100
@@ -1,3 +1,38 @@
+apt-cacher-ng (3.2.1) SHAUN-OF-THE-LIVING; urgency=medium
+
+ * POTENTIAL SECURITY ISSUE (CVE-2020-5202):
+- in certain situations, the maint job run by acngtool could leak the
+ administrator credentials from apt-cacher-ng configuration. This is only
+ likely if the attacker is able to impersonate the daemon with an own
+ server listening on the same port.
+- The mitigation path for this is:
+ - SocketPath option is configured by default
+ - By default, acngtool only attempts to run the maint job through the
+Unix Domain Socket. If SocketPath is not set but admin credentials are
+configured, the operation is denied.
+ - For non-standard cases where acngtool is used to run special arbitrary
+commands (ACNG_REQ variable) and the operation through SocketPath is not
+possible (i.e. missing permissions or the tool is run on a different
+host), the operation through TCP can be enforced with ACNG_INSECURE
+environment variable
+
+ [ REALITY SYNC ]
+ * increased size of the decompression line buffer for config file reading
+(Debian bug #942634)
+ * Support .zst compressed packages (reference:
+https://www.archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/ )
+
+ [ Debian Stable Bugfix ]
+ * Fix of Debian bug #928957: overoptimistic guessing of the SHA256SUMS file location
+Incorrect assumption of an existing SHA256SUMS file for Debian
+repositories makes the expiration task fail without a proper way for the
+end user to recover from it. Now ignore a download error in this case
+(similar handling as for other guesses), assuming that permanent 404ing
+for other reasons than removal of remote content can be considered
+unlikely.
+
+ -- Eduard Bloch Wed, 22 Jan 2020 20:53:50 +0100
+
apt-cacher-ng (3.2) MY-NAME-IS-ANYBODY; urgency=medium
* Maintenance release
diff -Nru apt-cacher-ng-3.2/VERSION apt-cacher-ng-3.2.1/VERSION
--- apt-cacher-ng-3.2/VERSION 2018-09-07 15:02:18.0 +0200
+++ apt-cacher-ng-3.2.1/VERSION 2020-02-03 19:54:57.0 +0100
@@ -1 +1 @@
-3.2
+3.2.1
diff -Nru apt-cacher-ng-3.2/conf/acng.conf.in apt-cacher-ng-3.2.1/conf/acng.conf.in
--- apt-cacher-ng-3.2/conf/acng.conf.in 2018-09-07 15:02:18.0 +0200
+++ apt-cacher-ng-3.2.1/conf/acng.conf.in 2020-02-03 19:54:57.0 +0100
@@ -81,11 +81,12 @@
ReportPage: acng-report.html
# Socket file for accessing through local
Re: Autopkgtest preventing ocaml-dune from migrating to testing
Hi Stéphane, On 03-02-2020 10:30, Stéphane Glondu wrote: > Currently, ocaml-dune/2.1.3-1 is blocked in unstable because of > autopkgtest failure of ocaml-sedlex/2.1-3. However, this test failure > has been fixed in ocaml-sedlex/2.1-4. Likewise, ocaml-sedlex/2.1-4 is > bloked in unstable because of autopkgtest failure of itself, but this > test has been done with ocaml-dune/1.11.0-2 (i.e. the testing version) > instead of the unstable version. > > What can be done to unblock the situation? If the issue is only with the autopkgtest, than from our point of view, ideally one (or both) gains a breaks on the version of the other package in testing. If that happens, our migration software is able to schedule the right combination of tests. However, we realize that sometime maintainers consider such a breaks too strong. Then the only way currently is that we manually help the package. Are you willing to add such a breaks to either package? Paul signature.asc Description: OpenPGP digital signature
Bug#949187: transition: python3.8
On Sun, 02 Feb 2020 at 09:35:04 +0100, Matthias Klose wrote: > I think this is now in shape to be started. Please can this wait until the remaining bits of the libffi7 transition and the restructuring of the libgcc_s packaging have settled down? I'm still trying to sort out the missing Breaks around gobject-introspection, as highlighted by autopkgtest failures: this has been delayed by needing coordinated action between multiple packages, some of them quite big (glib2.0), and by Paul and I being at FOSDEM. This is entangled with python3.8 via pygobject (which will fail tests with python3.8 as default - an upload is pending to fix that). Meanwhile, multiple packages seem to FTBFS on s390x with the new libgcc_s (I've just opened the bug for that, so no bug number known yet), which is going to limit the ability to get things into testing. Thanks, smcv
Bug#949187: transition: python3.8
On 2/3/20 8:22 PM, Simon McVittie wrote: > On Sun, 02 Feb 2020 at 09:35:04 +0100, Matthias Klose wrote: >> I think this is now in shape to be started. > > Please can this wait until the remaining bits of the libffi7 transition > and the restructuring of the libgcc_s packaging have settled down? > > I'm still trying to sort out the missing Breaks around > gobject-introspection, as highlighted by autopkgtest failures: this has > been delayed by needing coordinated action between multiple packages, > some of them quite big (glib2.0), and by Paul and I being at FOSDEM. > This is entangled with python3.8 via pygobject (which will fail tests > with python3.8 as default - an upload is pending to fix that). fine. I'm happy to see that fixed. > Meanwhile, multiple packages seem to FTBFS on s390x with the new libgcc_s > (I've just opened the bug for that, so no bug number known yet), which is > going to limit the ability to get things into testing. please retry your package builds. it's fixed in unstable.
Re: [Pkg-rust-maintainers] rust ecosystem worries of a release team member
Hi, Am 03.02.20 um 13:08 schrieb Sylvestre Ledru: ... > I have been told that the transition of one of the build-dep is blocked by > packages blocked in NEW... > Not sure which one. this is more or less what I mean, we should get clearance about the root of problems. > We already started a discussion with the Debian release management team to > simplify the acceptation of > packages already existing in the archive but with a new binary coming. Sounds good! >> While Fosdem I've talked with Paul > Paul ? Paul Grevers aka elbrus ... > FYI, I've never been a QA manager at Mozilla. I was running the release > management team > (but doing something else now). > But yeah, I do see what you mean. Thanks. O.k. than my minds have fooled me, but never mind, glad you see what I'd like to mention. -- Regards Carsten Schoenert
Bug#950547: buster-pu: package mew-beta/7.0.50~6.8+0.20190228-1+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hi, the release team, I'd like to update package mew-beta in buster to fix a security issue, managed as no advisory by the security team. See this changelog and the attached debdiff. mew-beta (7.0.50~6.8+0.20190228-1+deb10u1) buster; urgency=medium * New patch 070_checkhost.patch to enable checkHost for stunnel (closes: #950412) -- Tatsuya Kinoshita Sun, 02 Feb 2020 18:43:08 +0900 Please let me know if I can upload it. Thanks, -- Tatsuya Kinoshita diffstat for mew-beta-7.0.50~6.8+0.20190228 mew-beta-7.0.50~6.8+0.20190228 changelog |7 +++ patches/070_checkhost.patch | 15 +++ patches/series |1 + 3 files changed, 23 insertions(+) diff -Nru mew-beta-7.0.50~6.8+0.20190228/debian/changelog mew-beta-7.0.50~6.8+0.20190228/debian/changelog --- mew-beta-7.0.50~6.8+0.20190228/debian/changelog 2019-02-28 20:45:20.0 +0900 +++ mew-beta-7.0.50~6.8+0.20190228/debian/changelog 2020-02-02 18:43:08.0 +0900 @@ -1,3 +1,10 @@ +mew-beta (7.0.50~6.8+0.20190228-1+deb10u1) buster; urgency=medium + + * New patch 070_checkhost.patch to enable checkHost for stunnel +(closes: #950412) + + -- Tatsuya Kinoshita Sun, 02 Feb 2020 18:43:08 +0900 + mew-beta (7.0.50~6.8+0.20190228-1) unstable; urgency=medium * New upstream version 7.0.50~6.8+0.20190228 diff -Nru mew-beta-7.0.50~6.8+0.20190228/debian/patches/070_checkhost.patch mew-beta-7.0.50~6.8+0.20190228/debian/patches/070_checkhost.patch --- mew-beta-7.0.50~6.8+0.20190228/debian/patches/070_checkhost.patch 1970-01-01 09:00:00.0 +0900 +++ mew-beta-7.0.50~6.8+0.20190228/debian/patches/070_checkhost.patch 2020-02-01 22:10:00.0 +0900 @@ -0,0 +1,15 @@ +Subject: Enable checkHost for stunnel +Origin: upstream, https://github.com/kazu-yamamoto/Mew/commit/8de0a1398f10d0e8da29ce91ec22af17430c0004 +Bug: https://github.com/kazu-yamamoto/Mew/pull/133 + +--- a/mew-ssl.el b/mew-ssl.el +@@ -109,6 +109,8 @@ insert no extra text.") + (if mew-ssl-unixlike + (insert "pid=\n")) + (insert (format "verify=%d\n" (mew-ssl-verify-level case))) ++ (if (> (mew-ssl-verify-level case) 0) ++ (insert (format "checkHost=%s\n" server))) + (if mew-ssl-unixlike + (insert "foreground=yes\n")) + (insert "debug=debug\n") diff -Nru mew-beta-7.0.50~6.8+0.20190228/debian/patches/series mew-beta-7.0.50~6.8+0.20190228/debian/patches/series --- mew-beta-7.0.50~6.8+0.20190228/debian/patches/series2019-01-06 00:28:09.0 +0900 +++ mew-beta-7.0.50~6.8+0.20190228/debian/patches/series2020-02-01 22:16:29.0 +0900 @@ -2,4 +2,5 @@ 020_netpbm.patch 030_cache-long-scans.patch 040_incm-lock.patch +070_checkhost.patch 900_changes.patch pgpkU0123rNyk.pgp Description: PGP signature
Processed: transition: opencv
Processing commands for cont...@bugs.debian.org: > block 948638 by 922583 950545 Bug #948638 [release.debian.org] transition: opencv 948638 was blocked by: 950310 948638 was not blocking any bugs. Added blocking bug(s) of 948638: 950545 and 922583 > tags 950545 + ftbfs Bug #950545 [src:eviacam] FTBFS against opencv 4.2.0 Added tag(s) ftbfs. > thanks Stopping processing here. Please contact me if you need assistance. -- 948638: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948638 950545: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950545 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#950546: buster-pu: package mew/1:6.8-4+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hi, the release team, I'd like to update package mew in buster to fix a security issue, managed as no advisory by the security team. See this changelog and the attached debdiff. mew (1:6.8-4+deb10u1) buster; urgency=medium * New patch 070_checkhost.patch to enable checkHost for stunnel (closes: #950411) -- Tatsuya Kinoshita Sun, 02 Feb 2020 18:31:28 +0900 Please let me know if I can upload it. Thanks, -- Tatsuya Kinoshita diffstat for mew-6.8 mew-6.8 changelog |7 +++ patches/070_checkhost.patch | 15 +++ patches/series |1 + 3 files changed, 23 insertions(+) diff -Nru mew-6.8/debian/changelog mew-6.8/debian/changelog --- mew-6.8/debian/changelog2019-01-06 00:22:08.0 +0900 +++ mew-6.8/debian/changelog2020-02-02 18:31:28.0 +0900 @@ -1,3 +1,10 @@ +mew (1:6.8-4+deb10u1) buster; urgency=medium + + * New patch 070_checkhost.patch to enable checkHost for stunnel +(closes: #950411) + + -- Tatsuya Kinoshita Sun, 02 Feb 2020 18:31:28 +0900 + mew (1:6.8-4) unstable; urgency=medium [ YAMANAKA Hitoshi ] diff -Nru mew-6.8/debian/patches/070_checkhost.patch mew-6.8/debian/patches/070_checkhost.patch --- mew-6.8/debian/patches/070_checkhost.patch 1970-01-01 09:00:00.0 +0900 +++ mew-6.8/debian/patches/070_checkhost.patch 2020-02-01 22:18:14.0 +0900 @@ -0,0 +1,15 @@ +Subject: Enable checkHost for stunnel +Origin: upstream, https://github.com/kazu-yamamoto/Mew/commit/8de0a1398f10d0e8da29ce91ec22af17430c0004 +Bug: https://github.com/kazu-yamamoto/Mew/pull/133 + +--- a/mew-ssl.el b/mew-ssl.el +@@ -106,6 +106,8 @@ insert no extra text.") + (insert "client=yes\n") + (insert "pid=\n") + (insert (format "verify=%d\n" (mew-ssl-verify-level case))) ++ (if (> (mew-ssl-verify-level case) 0) ++ (insert (format "checkHost=%s\n" server))) + (insert "foreground=yes\n") + (insert "debug=debug\n") + (if (and mew-ssl-libwrap (or (>= mew-ssl-ver 5) (>= mew-ssl-minor-ver 45))) diff -Nru mew-6.8/debian/patches/series mew-6.8/debian/patches/series --- mew-6.8/debian/patches/series 2019-01-06 00:19:10.0 +0900 +++ mew-6.8/debian/patches/series 2020-02-01 22:18:14.0 +0900 @@ -2,3 +2,4 @@ 020_netpbm.patch 030_cache-long-scans.patch 040_incm-lock.patch +070_checkhost.patch pgprdcoFjjRq0.pgp Description: PGP signature
NEW changes in oldstable-new
Processing changes file: glib2.0_2.50.3-2+deb9u2_mipsel.changes ACCEPT
Re: [Pkg-rust-maintainers] rust ecosystem worries of a release team member
Le 03/02/2020 à 10:47, Carsten Schoenert a écrit : Hi Sylvestre, Am 04.01.20 um 17:19 schrieb Sylvestre Ledru: 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! is there any plan or list of issues ready that the rustc people are aware that need be done next work prepared or written somewhere so other Debian maintainers can see what's going on? I have been told that the transition of one of the build-dep is blocked by packages blocked in NEW... Not sure which one. We already started a discussion with the Debian release management team to simplify the acceptation of packages already existing in the archive but with a new binary coming. While Fosdem I've talked with Paul Paul ? about the currently not migrating Thunderbird package. And we talked of course about possibilities how to solve the unfortunate situation. Quite a lot of of Debian users have emailed me and asking why Thunderbird 68.x isn't available in testing but Firefox is. And it's sometimes difficult to explain the users the current situation, you as Mozilla QA manager FYI, I've never been a QA manager at Mozilla. I was running the release management team (but doing something else now). But yeah, I do see what you mean. Cheers, Sylvestre
Re: [Pkg-rust-maintainers] rust ecosystem worries of a release team member
Hi Sylvestre, Am 04.01.20 um 17:19 schrieb Sylvestre Ledru: > 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! is there any plan or list of issues ready that the rustc people are aware that need be done next work prepared or written somewhere so other Debian maintainers can see what's going on? While Fosdem I've talked with Paul about the currently not migrating Thunderbird package. And we talked of course about possibilities how to solve the unfortunate situation. Quite a lot of of Debian users have emailed me and asking why Thunderbird 68.x isn't available in testing but Firefox is. And it's sometimes difficult to explain the users the current situation, you as Mozilla QA manager for sure knows that the current ESR cycle is almost on 50% of the planned lifetime. Furthermore it's also quite difficult for AddOn maintainers in Debian to work on the extensions and prepare them than for p-u too due the outdated version of TB in testing. The stable RM are also not that happy with that circumstance. Maybe we need to create some more tools that helping to visualize a dependency chain and mark some package that need to worked on first. Such tools could be a thing for GSoC? So can we work out a list of packages that need to get prepared first to get the dependencies fixed? I've no deeper knowledge of the Rust ecosystem so my assumptions wouldn't help much I guess. -- Regards Carsten Schoenert
Autopkgtest preventing ocaml-dune from migrating to testing
Dear Release Managers, Currently, ocaml-dune/2.1.3-1 is blocked in unstable because of autopkgtest failure of ocaml-sedlex/2.1-3. However, this test failure has been fixed in ocaml-sedlex/2.1-4. Likewise, ocaml-sedlex/2.1-4 is bloked in unstable because of autopkgtest failure of itself, but this test has been done with ocaml-dune/1.11.0-2 (i.e. the testing version) instead of the unstable version. What can be done to unblock the situation? Cheers, -- Stéphane
