Bug#948552: nmu: schroedinger-coordgenlibs_1.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu schroedinger-coordgenlibs_1.3-1 . ANY . unstable . -m "Rebuild against libschroedinger-maeparser-dev >= 1.2.2-1" The binNMU of rdkit (#946247) did not fix #945985; it appears that it is schroedinger-coordgenlibs that actually needs rebuilding to pick up the new filename of libmaeparser: $ ldd /usr/lib/x86_64-linux-gnu/libcoordgen.so.1.3 linux-vdso.so.1 (0x7fff9f9bd000) libmaeparser.so.1.2 => not found libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f5445999000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5445854000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f544583a000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f544567a000) /lib64/ld-linux-x86-64.so.2 (0x7f5445c12000) (rebuilding the package has the linking pick up libmaeparser.so.1 instead) thanks Stuart
Bug#948468: (unplanned) transition: gpsd
On Thu, Jan 9, 2020 at 8:45 AM Paul Gevers wrote: > Did I just failed to spot it, or is there no bug against gpsd filed > about this? The bugs are filed against reverse dependencies (navit/foxtrotgps for eg). PS: there are two complementary tools that could be used to detect ABI breakage: https://github.com/lvc/pkg-abidiff https://sourceware.org/libabigail/manual/abipkgdiff.html A thread that includes a comparison of the tool: https://lists.debian.org/msgid-search/192731475679...@web2g.yandex.ru -- bye, pabs https://wiki.debian.org/PaulWise
Bug#948550: buster-pu: package e2fsprogs/1.44.5-1+deb10u2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
The reason is to fix two security issues which are fixed in 1.45.5. The
debdiff is attached. Let me know if this looks good for uploading.
Thanks!!
diff -Nru e2fsprogs-1.44.5/debian/changelog e2fsprogs-1.44.5/debian/changelog
--- e2fsprogs-1.44.5/debian/changelog 2019-09-25 13:37:44.0 -0400
+++ e2fsprogs-1.44.5/debian/changelog 2020-01-09 20:19:57.0 -0500
@@ -1,3 +1,10 @@
+e2fsprogs (1.44.5-1+deb10u3) buster; urgency=medium
+
+ * Fix CVE-2019-5188: potential stack underflow in e2fsck (Closes: #948508)
+ * Fix use after free in e2fsck (Closes: #948517)
+
+ -- Theodore Y. Ts'o Thu, 09 Jan 2020 20:19:57 -0500
+
e2fsprogs (1.44.5-1+deb10u2) buster-security; urgency=high
* Fix CVE-2019-5094: potential buffer overrun in e2fsck (Closes: #941139)
diff -Nru
e2fsprogs-1.44.5/debian/patches/e2fsck-abort-if-there-is-a-corrupted-directory-block.patch
e2fsprogs-1.44.5/debian/patches/e2fsck-abort-if-there-is-a-corrupted-directory-block.patch
---
e2fsprogs-1.44.5/debian/patches/e2fsck-abort-if-there-is-a-corrupted-directory-block.patch
1969-12-31 19:00:00.0 -0500
+++
e2fsprogs-1.44.5/debian/patches/e2fsck-abort-if-there-is-a-corrupted-directory-block.patch
2020-01-09 20:19:57.0 -0500
@@ -0,0 +1,53 @@
+From: Theodore Ts'o
+Date: Thu, 19 Dec 2019 19:37:34 -0500
+Subject: e2fsck: abort if there is a corrupted directory block when rehashing
+
+In e2fsck pass 3a, when we are rehashing directories, at least in
+theory, all of the directories should have had corruptions with
+respect to directory entry structure fixed. However, it's possible
+(for example, if the user declined a fix) that we can reach this stage
+of processing with a corrupted directory entries.
+
+So check for that case and don't try to process a corrupted directory
+block so we don't run into trouble in mutate_name() if there is a
+zero-length file name.
+
+Addresses-Debian-Bug: 948508
+Addresses: TALOS-2019-0973
+Addresses: CVE-2019-5188
+Signed-off-by: Theodore Ts'o
+(cherry picked from commit 8dd73c149f418238f19791f9d666089ef9734dff)
+---
+ e2fsck/rehash.c | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/e2fsck/rehash.c b/e2fsck/rehash.c
+index 7c4ab083..27e1429b 100644
+--- a/e2fsck/rehash.c
b/e2fsck/rehash.c
+@@ -159,6 +159,10 @@ static int fill_dir_block(ext2_filsys fs,
+ dir_offset += rec_len;
+ if (dirent->inode == 0)
+ continue;
++ if ((name_len) == 0) {
++ fd->err = EXT2_ET_DIR_CORRUPTED;
++ return BLOCK_ABORT;
++ }
+ if (!fd->compress && (name_len == 1) &&
+ (dirent->name[0] == '.'))
+ continue;
+@@ -398,6 +402,11 @@ static int duplicate_search_and_fix(e2fsck_t ctx,
ext2_filsys fs,
+ continue;
+ }
+ new_len = ext2fs_dirent_name_len(ent->dir);
++ if (new_len == 0) {
++ /* should never happen */
++ ext2fs_unmark_valid(fs);
++ continue;
++ }
+ memcpy(new_name, ent->dir->name, new_len);
+ mutate_name(new_name, _len);
+ for (j=0; j < fd->num_array; j++) {
+--
+2.24.1
+
diff -Nru
e2fsprogs-1.44.5/debian/patches/e2fsck-don-t-try-to-rehash-a-deleted-directory.patch
e2fsprogs-1.44.5/debian/patches/e2fsck-don-t-try-to-rehash-a-deleted-directory.patch
---
e2fsprogs-1.44.5/debian/patches/e2fsck-don-t-try-to-rehash-a-deleted-directory.patch
1969-12-31 19:00:00.0 -0500
+++
e2fsprogs-1.44.5/debian/patches/e2fsck-don-t-try-to-rehash-a-deleted-directory.patch
2020-01-09 20:19:57.0 -0500
@@ -0,0 +1,47 @@
+From: Theodore Ts'o
+Date: Thu, 19 Dec 2019 19:45:06 -0500
+Subject: e2fsck: don't try to rehash a deleted directory
+
+If directory has been deleted in pass1[bcd] processing, then we
+shouldn't try to rehash the directory in pass 3a when we try to
+rehash/reoptimize directories.
+
+Addresses-Debian-Bug: 948508
+Signed-off-by: Theodore Ts'o
+(cherry picked from commit 71ba13755337e19c9a826dfc874562a36e1b24d3)
+---
+ e2fsck/pass1b.c | 4
+ e2fsck/rehash.c | 2 ++
+ 2 files changed, 6 insertions(+)
+
+diff --git a/e2fsck/pass1b.c b/e2fsck/pass1b.c
+index 5693b9cf..bca701ca 100644
+--- a/e2fsck/pass1b.c
b/e2fsck/pass1b.c
+@@ -705,6 +705,10 @@ static void delete_file(e2fsck_t ctx, ext2_ino_t ino,
+ fix_problem(ctx, PR_1B_BLOCK_ITERATE, );
+ if (ctx->inode_bad_map)
+ ext2fs_unmark_inode_bitmap2(ctx->inode_bad_map, ino);
++ if (ctx->inode_reg_map)
++ ext2fs_unmark_inode_bitmap2(ctx->inode_reg_map, ino);
++ ext2fs_unmark_inode_bitmap2(ctx->inode_dir_map, ino);
++ ext2fs_unmark_inode_bitmap2(ctx->inode_used_map, ino);
+
Bug#948545: buster-pu: package python-evtx/0.6.1-1+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hi, let's make python-evtx usable in buster by fixing the hexdump import. This change is cherry-picked from sid. the package is already uploaded. Andreas diff -Nru python-evtx-0.6.1/debian/changelog python-evtx-0.6.1/debian/changelog --- python-evtx-0.6.1/debian/changelog 2017-07-17 10:09:27.0 +0200 +++ python-evtx-0.6.1/debian/changelog 2020-01-10 01:26:07.0 +0100 @@ -1,3 +1,12 @@ +python-evtx (0.6.1-1+deb10u1) buster; urgency=medium + + * Non-maintainer upload. + + [ Hilko Bengen ] + * Fix hexdump import (Closes: #942353) + + -- Andreas Beckmann Fri, 10 Jan 2020 01:26:07 +0100 + python-evtx (0.6.1-1) unstable; urgency=medium * New upstream version 0.6.1 diff -Nru python-evtx-0.6.1/debian/patches/0001-Add-missing-hexdump.patch python-evtx-0.6.1/debian/patches/0001-Add-missing-hexdump.patch --- python-evtx-0.6.1/debian/patches/0001-Add-missing-hexdump.patch 2017-07-17 10:02:49.0 +0200 +++ python-evtx-0.6.1/debian/patches/0001-Add-missing-hexdump.patch 2020-01-10 01:26:07.0 +0100 @@ -3,12 +3,27 @@ Subject: Add missing hexdump --- - Evtx/hexdump.py | 466 - 1 file changed, 466 insertions(+) - create mode 100755 Evtx/hexdump.py + Evtx/Nodes.py| 2 +- + Evtx/hexdump.py | 466 +++ + scripts/evtx_record_structure.py | 2 +- + 3 files changed, 468 insertions(+), 2 deletions(-) + create mode 100644 Evtx/hexdump.py +diff --git a/Evtx/Nodes.py b/Evtx/Nodes.py +index 216321d..20b1cbe 100644 +--- a/Evtx/Nodes.py b/Evtx/Nodes.py +@@ -22,7 +22,7 @@ import base64 + import itertools + + import six +-import hexdump ++import Evtx.hexdump as hexdump + + from .BinaryParser import Block + from .BinaryParser import ParseException diff --git a/Evtx/hexdump.py b/Evtx/hexdump.py -new file mode 100755 +new file mode 100644 index 000..fc0e97e --- /dev/null +++ b/Evtx/hexdump.py @@ -479,3 +494,14 @@ +# [ ] document chunking API +# [ ] document hexdump API +# [ ] blog about sys.stdout text mode problem on Windows +diff --git a/scripts/evtx_record_structure.py b/scripts/evtx_record_structure.py +index 0da7afa..e19cd25 100755 +--- a/scripts/evtx_record_structure.py b/scripts/evtx_record_structure.py +@@ -1,5 +1,5 @@ + #!/usr/bin/env python +-import hexdump ++import Evtx.hexdump as hexdump + + import Evtx.Evtx as evtx + from Evtx.Nodes import RootNode
Bug#948544: buster-pu: package nvidia-graphics-drivers-legacy-340xx/340.108-2~deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hi, I'd like to update nvidia-graphics-drivers-legacy-340xx to the last (as in final) upstream release 340.108. NVIDIA has declared the 340 legacy driver series as End-of-Life and won't issue any further updates. A NEWS entry is added to inform the users about this fact. We did a similar update for nvidia-graphics-drivers-legacy-304xx in stretch when the 304 legacy driver was EoL-ed. The package contains all packaging updates and fixes that have accumulated since the buster release and that I consider suitable for buster. This helps us keeping the packaging in sync between the 4 driver series and over the releases from oldstable to experimental. I'll upload the package to buster-backports once 340.108-2 reached testing to give it a wider exposure and reach more potential testers. The attached diff is generated from the git repository and (as usual) excludes the blobs. A similar request for stretch will follow. Andreas nvidia-graphics-drivers-legacy-340xx_340.108-2~deb10u1.diff.gz Description: application/gzip
NEW changes in stable-new
Processing changes file: firefox-esr_68.4.0esr-1~deb10u1_source.changes ACCEPT Processing changes file: firefox-esr_68.4.0esr-1~deb10u1_all.changes ACCEPT Processing changes file: firefox-esr_68.4.0esr-1~deb10u1_amd64.changes ACCEPT Processing changes file: firefox-esr_68.4.0esr-1~deb10u1_arm64.changes ACCEPT Processing changes file: firefox-esr_68.4.0esr-1~deb10u1_armhf.changes ACCEPT Processing changes file: firefox-esr_68.4.0esr-1~deb10u1_i386.changes ACCEPT Processing changes file: firefox-esr_68.4.0esr-1~deb10u1_mips.changes ACCEPT Processing changes file: firefox-esr_68.4.0esr-1~deb10u1_mips64el.changes ACCEPT Processing changes file: firefox-esr_68.4.0esr-1~deb10u1_mipsel.changes ACCEPT Processing changes file: firefox-esr_68.4.0esr-1~deb10u1_ppc64el.changes ACCEPT Processing changes file: firefox-esr_68.4.0esr-1~deb10u1_s390x.changes ACCEPT Processing changes file: firefox-esr_68.4.1esr-1~deb10u1_source.changes ACCEPT Processing changes file: firefox-esr_68.4.1esr-1~deb10u1_all.changes ACCEPT Processing changes file: firefox-esr_68.4.1esr-1~deb10u1_amd64.changes ACCEPT Processing changes file: firefox-esr_68.4.1esr-1~deb10u1_arm64.changes ACCEPT Processing changes file: firefox-esr_68.4.1esr-1~deb10u1_armhf.changes ACCEPT Processing changes file: firefox-esr_68.4.1esr-1~deb10u1_i386.changes ACCEPT Processing changes file: firefox-esr_68.4.1esr-1~deb10u1_mips.changes ACCEPT Processing changes file: firefox-esr_68.4.1esr-1~deb10u1_mips64el.changes ACCEPT Processing changes file: firefox-esr_68.4.1esr-1~deb10u1_mipsel.changes ACCEPT Processing changes file: firefox-esr_68.4.1esr-1~deb10u1_ppc64el.changes ACCEPT Processing changes file: firefox-esr_68.4.1esr-1~deb10u1_s390x.changes ACCEPT
NEW changes in stable-new
Processing changes file: qtwebengine-opensource-src_5.11.3+dfsg-2+deb10u1_mipsel.changes ACCEPT
Processed: claws-mail: Please switch to enchant-2
Processing control commands: > block 947979 by -1 Bug #947979 [release.debian.org] transition: enchant-2 947979 was blocked by: 948439 948352 948351 948437 948106 947979 was not blocking any bugs. Added blocking bug(s) of 947979: 948532 -- 947979: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947979 948532: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948532 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#939989: transition: gdal
On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote: > gdal (3.0.2+dfsg-1) is now built & installed on all release architectures. > > Please schedule the binNMUs. Thanks for scheduling the initial batch, everything has built now. Please schedule the rest of Dependency level 1. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 signature.asc Description: OpenPGP digital signature
NEW changes in stable-new
Processing changes file: guile-2.2_2.2.4+1-2+deb10u1_mips.changes ACCEPT
Re: rust ecosystem worries of a release team member
On Thu, Jan 09, 2020 at 01:38:53PM +, Ximin Luo wrote: > Paul Gevers: > > Hi all, > > > > On 05-01-2020 14:39, Ximin Luo wrote: > >> Paul Gevers: > >>> [..] > >>> > >>> [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... > > > > And today another firefox-esr, with CVE fixes, appeared, which is also > > blocked by this. > > > > I just had a look, and both firefox-esr and thunderbird still are vendoring > their own rust source code in third_part/rust/* and make no attempt to > integrate with dh-cargo or our cargo-debian-wrapper in d/rules in the way > that I prescribe here: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907629#30 > > So their current build-dependencies on any librust-* packages are bogus, and > can simply be dropped to progress with migration. > > Likewise, rustc and cargo are purposefully designed to vendor their own > crates, and *not* depend on any librust-* packages, and so they shouldn't > affect migration either. > firefox-esr doesn't build-depend on any librust-* package. It build-depends on rustc, cargo, and cbindgen. But cbindgen is not in testing, and *it* build-depends on a bunch of librust-*-dev packages, which block its migration to testing. Cheers, Julien
Re: rust ecosystem worries of a release team member
On Sat, Jan 04, 2020 at 05:02:56PM +0100, Paul Gevers wrote: > 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? > I think this is a case where it's OK to ignore missing build-dependencies in testing, and push thunderbird anyway. I'll be doing that for firefox-esr, in any case. Cheers, Julien
Re: Planning 10.3 and 9.12
Hi all Sorry for the late reply. El 6/1/20 a las 22:42, Adam D. Barratt escribió: > Hi, > > It's (really past) time to consider a date for the next point releases > for buster and stretch. > > I've listed some suggested dates below; please indicate which you would > be available for. > > - January 25th > - February 1st > - February 8th > - February 15th > Any weekend of those should be fine for publicity/website. Kind regards, -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
Re: rust ecosystem worries of a release team member
Paul Gevers: > Hi all, > > On 05-01-2020 14:39, Ximin Luo wrote: >> Paul Gevers: >>> [..] >>> >>> [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... > > And today another firefox-esr, with CVE fixes, appeared, which is also > blocked by this. > I just had a look, and both firefox-esr and thunderbird still are vendoring their own rust source code in third_part/rust/* and make no attempt to integrate with dh-cargo or our cargo-debian-wrapper in d/rules in the way that I prescribe here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907629#30 So their current build-dependencies on any librust-* packages are bogus, and can simply be dropped to progress with migration. Likewise, rustc and cargo are purposefully designed to vendor their own crates, and *not* depend on any librust-* packages, and so they shouldn't affect migration either. >> As discussed in #debian-release, this huge migration involving >> unicode-xid, proc-macro2, etc, is blocked on some packages in NEW as >> well as other things including the autopkgtests.> >> Please be aware that rust autopkgtests are a new experimental thing >> and as such will take a while to iron out. After that though, future >> stuff should be much easier. > If it really helps migrating this lot sooner, I am willing to accept > *new* autopkgtest results that fail (so no regressions) if you'll keep > on working to fix it. If so, please let me know which ones. > Well, I'm pretty sure most of the regressions are "there used to be 0 tests, now there are >0 tests that fail". This is not specific, this is a general change done to debcargo between versions 2.2 and 2.4, so I do not have specific names to give you. Perhaps you can simply count "there used to be 0 tests, now there are >0 tests that fail" as "not a regression"? >> To help this process, is there a way we can mass-download all the >> logs of all the failures? I basically want to grep all the rust-* >> failure logs for ^error, and group them per source package. That way >> it'll be easier to see which things we have to automate solutions >> for, and which things we can get away with a manual override. > As discussed on IRC, there is the excuses.(html|yaml) file that helps > with that. At least for migration blocking items. > > Note, rust-debcargo (with your autopkgtest improvements) is also having > issues to migrate (due to rust-cargo, rust-git2, rust-glob, rust-im-rc, > rust-toml, rustc). > Yes I'm aware of that. I wrote a script to output stuff in more detail a few days ago. The current migration status is being tracked here: https://people.debian.org/~infinity0/rust/debian-testing.txt X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
NEW changes in stable-new
Processing changes file: guile-2.2_2.2.4+1-2+deb10u1_mipsel.changes ACCEPT
NEW changes in stable-new
Processing changes file: guile-2.2_2.2.4+1-2+deb10u1_armel.changes ACCEPT
Bug#948485: buster-pu: package alot/0.8.1-1+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hi, let's fix the FTBFS of alot in buster that is caused by expired certificates in the testsuite. #930057 The package is already uploaded. Andreas alot_0.8.1-1+deb10u1.dsc.diff Description: Binary data
Re: rust ecosystem worries of a release team member
Hi all, On 05-01-2020 14:39, Ximin Luo wrote: > Paul Gevers: >> [..] >> >> [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... And today another firefox-esr, with CVE fixes, appeared, which is also blocked by this. > As discussed in #debian-release, this huge migration involving > unicode-xid, proc-macro2, etc, is blocked on some packages in NEW as > well as other things including the autopkgtests.> > Please be aware that rust autopkgtests are a new experimental thing > and as such will take a while to iron out. After that though, future > stuff should be much easier. If it really helps migrating this lot sooner, I am willing to accept *new* autopkgtest results that fail (so no regressions) if you'll keep on working to fix it. If so, please let me know which ones. > To help this process, is there a way we can mass-download all the > logs of all the failures? I basically want to grep all the rust-* > failure logs for ^error, and group them per source package. That way > it'll be easier to see which things we have to automate solutions > for, and which things we can get away with a manual override. As discussed on IRC, there is the excuses.(html|yaml) file that helps with that. At least for migration blocking items. Note, rust-debcargo (with your autopkgtest improvements) is also having issues to migrate (due to rust-cargo, rust-git2, rust-glob, rust-im-rc, rust-toml, rustc). Paul signature.asc Description: OpenPGP digital signature
NEW changes in stable-new
Processing changes file: guile-2.2_2.2.4+1-2+deb10u1_armhf.changes ACCEPT Processing changes file: guile-2.2_2.2.4+1-2+deb10u1_mips64el.changes ACCEPT Processing changes file: qtwebengine-opensource-src_5.11.3+dfsg-2+deb10u1_arm64.changes ACCEPT
Bug#948474: marked as done (RM: cain/1.10+dfsg-3)
Your message dated Thu, 9 Jan 2020 10:04:11 +0100 with message-id <7b5508d0-36b1-ed75-ef92-11ad1d928...@debian.org> and subject line Re: Bug#948474: RM: cain/1.10+dfsg-3 has caused the Debian Bug report #948474, regarding RM: cain/1.10+dfsg-3 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 948474: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948474 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm cain is one of the only 2 remaining reverse dependencies of python-scipy in testing (python-networkx is schedule for RM by ftp.d.o, and i'm working on scikit-learn right now); while we figure out if it's worth keeping src:cain in Debian (see #948473), can you please remove it from testing? this will simplify the work on scipy. Thanks, Sandro -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- End Message --- --- Begin Message --- Hi Sandro, On 09-01-2020 06:42, Sandro Tosi wrote: > cain is one of the only 2 remaining reverse dependencies of python-scipy in > testing (python-networkx is schedule for RM by ftp.d.o, and i'm working on > scikit-learn right now); while we figure out if it's worth keeping src:cain in > Debian (see #948473), can you please remove it from testing? this will > simplify > the work on scipy. Hint added. Thanks. Paul signature.asc Description: OpenPGP digital signature --- End Message ---
Bug#948480: marked as done (spring needs hinting into testing)
Your message dated Thu, 9 Jan 2020 09:59:17 +0100 with message-id <85518cc4-c2f1-2831-9801-9d3d16c73...@debian.org> and subject line Re: Bug#948480: spring needs hinting into testing has caused the Debian Bug report #948480, regarding spring needs hinting into testing to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 948480: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948480 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal Issues preventing migration: uninstallable on arch arm64, autopkgtest delayed there For background see #918620. Thanks in advance --- End Message --- --- Begin Message --- Hi Adrian, On 09-01-2020 09:25, Adrian Bunk wrote: > Issues preventing migration: > uninstallable on arch arm64, autopkgtest delayed there Hint added. Paul signature.asc Description: OpenPGP digital signature --- End Message ---
Bug#944417: marked as done (transition: cgal)
Your message dated Thu, 9 Jan 2020 09:53:57 +0100 with message-id <94b19145-5410-b888-927d-24326d134...@debian.org> and subject line Re: Bug#944417: transition: cgal has caused the Debian Bug report #944417, regarding transition: cgal to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 944417: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944417 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to request a transition slot for CGAL 5.0. The CGAL library is now header-only, i.e., the two library packages "libcgal13" and "libcgal-qt5-14" are now gone. Status of reverse dependencies: crrcsimneeds source code changes, patch available gudhi binNMU should be sufficient k3dneeds source code changes, patch available openemsbinNMU should be sufficient openscad needs source code changes, patch available pgrouting needs source code changes, patch available pprepair FTBFS, https://github.com/tudelft3d/pprepair/issues/55 prepairFTBFS, https://github.com/tudelft3d/prepair/issues/35 pygalmesh binNMU should be sufficient rheolefneeds source code changes, patch available, unrelated FTBFS, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944197 sfcgal FTBFS, https://github.com/Oslandia/SFCGAL/issues/198 yade needs source code changes, patch available Ben file: title = "cgal"; is_affected = .depends ~ "libcgal13" | .depends ~ "libcgal-qt5-14"; is_good = ! ( .depends ~ "libcgal13" | .depends ~ "libcgal-qt5-14" ); is_bad = .depends ~ "libcgal13" | .depends ~ "libcgal-qt5-14"; -- System Information: Debian Release: 10.1 Architecture: amd64 (x86_64) --- End Message --- --- Begin Message --- Hi Joachim, On 14-12-2019 10:37, Paul Gevers wrote: > cgal migrated to testing. The transition is finished after the > autoremoval of k3d and rheolef in a couple of days, or when their fixed, > whatever happens first. It took a bit longer, but the transition is done. Thanks. Paul signature.asc Description: OpenPGP digital signature --- End Message ---
Processed: Re: Bug#948468: (unplanned) transition: gpsd
Processing control commands: > tags -1 confirmed Bug #948468 [release.debian.org] (unplanned) transition: gpsd Added tag(s) confirmed. -- 948468: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948468 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bug 948468 is forwarded to https://release.debian.org/transitions/html/libgps-26.html
Processing commands for cont...@bugs.debian.org: > forwarded 948468 https://release.debian.org/transitions/html/libgps-26.html Bug #948468 [release.debian.org] (unplanned) transition: gpsd Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/libgps-26.html'. > thanks Stopping processing here. Please contact me if you need assistance. -- 948468: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948468 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#948468: (unplanned) transition: gpsd
Control: tags -1 confirmed On 09-01-2020 01:14, Bernd Zeimetz wrote: > unfortunately gpsd upstream missed to change the soname version (seems > its actually mentioned in the commit message, but the change is missing) > and I also missed that one struct changed in a subtle way. Did I just failed to spot it, or is there no bug against gpsd filed about this? > gpsd 3.20-2 is in NEW right now and will go to experimental, if you > don't object I'd upload it to unstable to make the mess smaller than it > is now. Please go ahead once the package clears NEW (such that you can do a source only upload to unstable). Paul signature.asc Description: OpenPGP digital signature
Bug#948480: spring needs hinting into testing
Package: release.debian.org Severity: normal Issues preventing migration: uninstallable on arch arm64, autopkgtest delayed there For background see #918620. Thanks in advance
