Bug#983071: unblock: xz-utils/5.2.5-1.1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Please unblock package xz-utils. I NMUed xz-utils to 5.2.5-1.0 fixing a few bugs including #844770 and #975981. Both bugs were fixed by upstream differently / more complete. I prepared an NMU 5.2.5-1.1, #983067 by replacing my patches with upstream patches: - #844770 "xzcmp: SIGPIPE is raised because CMP does exit while the XZ commands are still writing to the pipe" https://git.tukaani.org/?p=xz.git;a=commitdiff;h=194029ffaf74282a81f0c299c07f73caca3232ca - #975981 "xz-utils: "unxz -k" should not refuse to decompress a file because it has more than one hard link" https://git.tukaani.org/?p=xz.git;a=commitdiff;h=074259f4f3966aeac6edb205fecbc1a8d2b58bb2 I would like to avoid having different changes to the package (and possibly creating new bugs) and therefore keep what upstream applied here. The patches were reviewed at least by the maintainer of the upstream package. During that review a similar SIGPIPE problem was found and fixed in xzgrep: Scripts: Fix exit status of xzgrep. https://git.tukaani.org/?p=xz.git;a=commitdiff;h=73c555b3077c19dda29b6f4592ced2af876f8333 This bug was never reported and fixed within the Debian package. If it is okay with the release then I would backport the patch and NMU it as part of the 5.2.5-1.1 upload. Otherwise I would stick with the replacement of the two patches as can been seen in the attached debdiff. The package was not yet uploaded, I plan to upload it to delayed/5 once the release team agrees. unblock xz-utils/5.2.5-1.1 Sebastian diff -Nru xz-utils-5.2.5/debian/changelog xz-utils-5.2.5/debian/changelog --- xz-utils-5.2.5/debian/changelog 2020-12-28 11:25:06.0 +0100 +++ xz-utils-5.2.5/debian/changelog 2021-02-18 23:12:30.0 +0100 @@ -1,3 +1,10 @@ +xz-utils (5.2.5-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Update the patches for #844770 and #975981 to what upstream applied. + + -- Sebastian Andrzej Siewior Thu, 18 Feb 2021 23:12:30 +0100 + xz-utils (5.2.5-1.0) unstable; urgency=medium * Non-maintainer upload. diff -Nru xz-utils-5.2.5/debian/patches/0001-Scripts-Fix-exit-status-of-xzdiff-xzcmp.patch xz-utils-5.2.5/debian/patches/0001-Scripts-Fix-exit-status-of-xzdiff-xzcmp.patch --- xz-utils-5.2.5/debian/patches/0001-Scripts-Fix-exit-status-of-xzdiff-xzcmp.patch 1970-01-01 01:00:00.0 +0100 +++ xz-utils-5.2.5/debian/patches/0001-Scripts-Fix-exit-status-of-xzdiff-xzcmp.patch 2021-02-17 23:52:05.0 +0100 @@ -0,0 +1,118 @@ +From: Lasse Collin +Date: Mon, 11 Jan 2021 22:01:51 +0200 +Subject: Scripts: Fix exit status of xzdiff/xzcmp. +MIME-Version: 1.0 +Content-Type: text/plain; charset="utf-8" +Content-Transfer-Encoding: 8bit + +This is a minor fix since this affects only the situation when +the files differ and the exit status is something else than 0. +In such case there could be SIGPIPE from a decompression tool +and that would result in exit status of 2 from xzdiff/xzcmp +while the correct behavior would be to return 1 or whatever +else diff or cmp may have returned. + +This commit omits the -q option from xz/gzip/bzip2/lzop arguments. +I'm not sure why the -q was used in the first place, perhaps it +hides warnings in some situation that I cannot see at the moment. +Hopefully the removal won't introduce a new bug. + +With gzip the -q option was harmful because it made gzip return 2 +instead of >= 128 with SIGPIPE. Ignoring exit status 2 (warning +from gzip) isn't practical because bzip2 uses exit status 2 to +indicate corrupt input file. It's better if SIGPIPE results in +exit status >= 128. + +With bzip2 the removal of -q seems to be good because with -q +it prints nothing if input is corrupt. The other tools aren't +silent in this situation even with -q. On the other hand, if +zstd support is added, it will need -q since otherwise it's +noisy in normal situations. + +Thanks to Étienne Mollier and Sebastian Andrzej Siewior. +--- + src/scripts/xzdiff.in | 35 +-- + 1 file changed, 21 insertions(+), 14 deletions(-) + +diff --git a/src/scripts/xzdiff.in b/src/scripts/xzdiff.in +index eb7825c..98ac0e5 100644 +--- a/src/scripts/xzdiff.in b/src/scripts/xzdiff.in +@@ -116,23 +116,18 @@ elif test $# -eq 2; then + if test "$1$2" = --; then + xz_status=$( + exec 4>&1 +- ($xz1 -cdfq - 4>&-; echo $? >&4) 3>&- | ++ ($xz1 -cdf - 4>&-; echo $? >&4) 3>&- | + eval "$cmp" - - >&3 + ) + elif # Reject Solaris 8's buggy /bin/bash 2.03. + echo X | (echo X | eval "$cmp" /dev/fd/5 - >/dev/null 2>&1) 5<&0; then ++# NOTE: xz_status will contain two numbers. + xz_status=$( + exec 4>&1 +- ($xz1 -cdfq -- "$1" 4>&-; echo $? >&4) 3>&- | +-( ($xz2 -cdfq -- "$2" 4>&-; echo $?
Bug#983065: debian-policy: Downgrades are not allowed / Package upgrades must have a greater version than previous packages of the same name in the same suite
Package: debian-policy Version: 4.5.1.0 Severity: normal Hi, I know this is very obvious, but if you read * https://www.debian.org/Bugs/Developer#severities and * https://release.debian.org/testing/rc_policy.txt it seems as if it should be listed somewhere in the policy that package downgrades MUST not happen during upgrades within the same suite (i.e. also not during dist-upgrades from e.g. oldstable to stable). I searched for "downgrad" (case-insensitively) in the whole policy and read at least the sections 3.2 "The version of a package" and 5.6.12 "Version". (If it's documented elsewhere in the policy, it might need a pointer to there in these sections.) Reason for this bug report: After reading https://release.debian.org/testing/rc_policy.txt, especially after word "complete" this paragraph … The purpose of this document is to be a correct, complete and canonical list of issues that merit a "serious" bug under the clause "a severe violation of Debian policy". … I really had a hard time arguing why https://bugs.debian.org/983018 is actually release-critical, despite I was 100% sure that it is. Luckily the maintainer did not start discussing but just fixed it. :-) X-Debugs-Cc'ing the release team for the involvement of rc_policy.txt. The best written source I so far found was https://wiki.debian.org/SystemDowngrade and hence outside the policy. I suggest to add maybe a section 3.2.3 at https://www.debian.org/doc/debian-policy/ch-binary.html#the-version-of-a-package with a text like this: ---8<--- 3.2.3 Version numbers of upgrades within one suite Version numbers of succeeding package upgrades within the same suite MUST be strictly greater than the one of the previous package. Package downgrades within one suite or when dist-upgrading from an old stable to a new stable release MUST not happen. See 5.6.12.1. Epochs should be used sparingly for cases where you need to package an upstream release with a lower upstream version number. Even in that case the package version itself MUST be greater. --->8--- Maybe some of the phrases from https://wiki.debian.org/SystemDowngrade can be reused, too. Mostly thinking of these, because these are the core reasons: 1. The packages' installation scripts (postinst...) are designed to handle upgrade only. 2. The installation tools are designed to replace older versions of packages by newer versions. Improvements of this text are very welcome as it's currently just a first brain dump. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 3.4.3-1 Versions of packages debian-policy suggests: ii doc-base 0.11.1 -- no debconf information
Bug#983055: marked as done (nmu: libinih_53-1)
Your message dated Thu, 18 Feb 2021 22:54:11 +0200 with message-id and subject line Re: Bug#983055: nmu: libinih_53-1 has caused the Debian Bug report #983055, regarding nmu: libinih_53-1 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.) -- 983055: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983055 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: jrt...@debian.org mmyan...@gmail.com Severity: normal Hi, The latest upload of libinih/53-1 was not a source-only upload. Please schedule a binNMU for amd64 to rebuild the binary packages on buildd. nmu libinih_53-1 . amd64 . unstable . -m "Rebuild on buildd" -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part --- End Message --- --- Begin Message --- Hi Boyuan On Thu, 18 Feb 2021 at 19:57, Boyuan Yang wrote: > nmu libinih_53-1 . amd64 . unstable . -m "Rebuild on buildd" Scheduled, thanks. Regards Graham--- End Message ---
Bug#983064: unblock: notmuch/0.31.4-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Please unblock package notmuch [ Reason ] There is two improvements in 0.31.4-1 that would be nice for bullseye. The first is a fix for a flaky test that causes failures about 15% of the time for parallel builds. The second fixes a build failure against glib 2.67 (currently in experimental). [ Impact ] The test related build failures generate failures generate false positives during archive rebuilds. They could potentially cause issues for binNMUs, although that hasn't been an issue in practice. The incompatibility with glib 2.67 is mostly hypothetical at this point. [ Tests ] I've done 80+ rebuilds on 60 hardware threads / 30 cores without triggering the test failure. I also built a few times against glib 2.67 in an sid/experimental chroot. [ Risks ] Both sets of changes are (textually) trivial. Notmuch is not quite a leaf package, but the number of dependencies is relatively small. [ 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 notmuch/0.31.4-1 - -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmAu0gsACgkQA0U5G1Wq FSHc/hAAof5a6L+xF/v/O9HEpTeKI2mSGwxQpsrce3qna56dS3ochLvHJ1F0PBTZ /JZ1ka+OmqJ/txcITQjHWgBVSdb5ulUJuVxBljVt4Ysos7V468isd1pqBX33W3Jy qUBrqpqclZ6S3uyof6KUAshrG5Exj5gm379PW+DoHouaujeJysXA5FNj+R2PavB2 DIupBLPaHFEhiYtFHJj4Zvk5dULVctrlhYE8vo1hrS3GEJg1F9Sbrp7K8Wy//fB7 93qMP7hIG63S77TZ7PXTB88dLXuszVzwXirc1jIF0OemLnDXgIvpC4I2VKKR3+I+ NYYhjhxJoD/w6MtjJElTmS0CU6LRqcy+Cw4ErMUDwNdxIxie7tVaiCvlrYYBEL6C ALlXCNyLrnBzx1XLQofGRX/m9sNxcEqHBwaaHoRuegmyRbxEW36r+O91K1uLQIlH taWYthp7UX9dcdo6QogWHdMVTOKpdwFAGWBtHXjbwwYahJdPzOHhG/hgsdVEH4EN HTxC7R4tcoqUbdwIvHvcTwAUGX2Dy/gV3ThCLanG6dbrZccTAv3SpfQjbn68TAtq r9kHfh+J4R+tohu4zlIrxoksPyKlAp2J06BhWfDnf0Guu/vWu+4ich+5LOjGv5rp eDD81pANU3bjehfotY83kcaz5mShnKq3YcGTB8S7eCsYn+n7NcA= =Q+wV -END PGP SIGNATURE- diff -Nru --exclude debian-changes notmuch-0.31.3/bindings/python/notmuch/version.py notmuch-0.31.4/bindings/python/notmuch/version.py --- notmuch-0.31.3/bindings/python/notmuch/version.py 2020-12-25 12:21:05.0 -0400 +++ notmuch-0.31.4/bindings/python/notmuch/version.py 2021-02-18 07:55:28.0 -0400 @@ -1,3 +1,3 @@ # this file should be kept in sync with ../../../version -__VERSION__ = '0.31.3' +__VERSION__ = '0.31.4' SOVERSION = '5' diff -Nru --exclude debian-changes notmuch-0.31.3/bindings/python-cffi/version.txt notmuch-0.31.4/bindings/python-cffi/version.txt --- notmuch-0.31.3/bindings/python-cffi/version.txt 2020-12-25 12:21:05.0 -0400 +++ notmuch-0.31.4/bindings/python-cffi/version.txt 2021-02-18 07:55:28.0 -0400 @@ -1 +1 @@ -0.31.3 +0.31.4 diff -Nru --exclude debian-changes notmuch-0.31.3/debian/changelog notmuch-0.31.4/debian/changelog --- notmuch-0.31.3/debian/changelog 2020-12-26 15:14:07.0 -0400 +++ notmuch-0.31.4/debian/changelog 2021-02-18 07:23:00.0 -0400 @@ -1,3 +1,11 @@ +notmuch (0.31.4-1) unstable; urgency=medium + + * New upstream bugfix release +- Fix include bug triggered by glib 2.67 +- Fix race condition in T568-lib-thread + + -- David Bremner Thu, 18 Feb 2021 07:23:00 -0400 + notmuch (0.31.3-2) unstable; urgency=medium * Don't install gdb on hppa (skip gdb based tests) diff -Nru --exclude debian-changes notmuch-0.31.3/debian/patches/series notmuch-0.31.4/debian/patches/series --- notmuch-0.31.3/debian/patches/series2020-12-26 15:14:07.0 -0400 +++ notmuch-0.31.4/debian/patches/series1969-12-31 20:00:00.0 -0400 @@ -1 +0,0 @@ -debian-changes diff -Nru --exclude debian-changes notmuch-0.31.3/doc/conf.py notmuch-0.31.4/doc/conf.py --- notmuch-0.31.3/doc/conf.py 2020-12-25 12:21:05.0 -0400 +++ notmuch-0.31.4/doc/conf.py 2021-02-18 07:55:28.0 -0400 @@ -14,7 +14,7 @@ # General information about the project. project = u'notmuch' -copyright = u'2009-2020, Carl Worth and many others' +copyright = u'2009-2021, Carl Worth and many others' location = os.path.dirname(__file__) diff -Nru --exclude debian-changes notmuch-0.31.3/lib/notmuch-private.h notmuch-0.31.4/lib/notmuch-private.h --- notmuch-0.31.3/lib/notmuch-private.h2020-12-25 12:21:05.0 -0400 +++
Bug#983055: nmu: libinih_53-1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: jrt...@debian.org mmyan...@gmail.com Severity: normal Hi, The latest upload of libinih/53-1 was not a source-only upload. Please schedule a binNMU for amd64 to rebuild the binary packages on buildd. nmu libinih_53-1 . amd64 . unstable . -m "Rebuild on buildd" -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#983051: buster-pu: package xterm/344-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Salvatore Bonaccorso , Julien Cristau
, Sven Joachim
I would like to fix bug #982439/CVE-2021-27135[1] in Buster, a potential
DoS against xterm when the user selects specially crafted text. The fix
is already in testing and applies unmodified to the version in Buster,
the code in question had not seen any changes since then. The xterm
package in Stretch-LTS has also already been patched. At [2] there is
the upstream source of the patch.
Thanks for considering.
1. https://bugs.debian.org/982439
2.
https://github.com/ThomasDickey/xterm-snapshots/commit/82ba55b8f994ab30ff561a347b82ea340ba7075c#diff-1316a8dc8f904428cd95f29accdea9fff33e680f9f30216391d8df33d2f9f806
diff -Nru xterm-344/debian/changelog xterm-344/debian/changelog
--- xterm-344/debian/changelog 2019-02-14 18:04:18.0 +0100
+++ xterm-344/debian/changelog 2021-02-18 17:39:44.0 +0100
@@ -1,3 +1,11 @@
+xterm (344-1+deb10u1) buster; urgency=medium
+
+ * Apply upstream fix from xterm 365d for CVE-2021-27135.
+- Correct upper-limit for selection buffer, accounting for combining
+ characters (Closes: #982439).
+
+ -- Sven Joachim Thu, 18 Feb 2021 17:39:44 +0100
+
xterm (344-1) unstable; urgency=medium
* New upstream release.
diff -Nru xterm-344/debian/patches/CVE-2021-27135.diff xterm-344/debian/patches/CVE-2021-27135.diff
--- xterm-344/debian/patches/CVE-2021-27135.diff 1970-01-01 01:00:00.0 +0100
+++ xterm-344/debian/patches/CVE-2021-27135.diff 2021-02-17 19:28:55.0 +0100
@@ -0,0 +1,55 @@
+Description: Fix for CVE-2021-27135 from xterm 365d
+ Correct upper-limit for selection buffer, accounting for
+ combining characters (report by Tavis Ormandy).
+
+---
+ button.c | 23 +++
+ 1 file changed, 19 insertions(+), 4 deletions(-)
+
+--- a/button.c
b/button.c
+@@ -3914,6 +3914,7 @@ SaltTextAway(XtermWidget xw,
+ int i;
+ int eol;
+ int need = 0;
++size_t have = 0;
+ Char *line;
+ Char *lp;
+ CELL first = *cellc;
+@@ -3948,7 +3949,11 @@ SaltTextAway(XtermWidget xw,
+
+ /* UTF-8 may require more space */
+ if_OPT_WIDE_CHARS(screen, {
+- need *= 4;
++ if (need > 0) {
++ if (screen->max_combining > 0)
++ need += screen->max_combining;
++ need *= 6;
++ }
+ });
+
+ /* now get some memory to save it in */
+@@ -3986,10 +3991,20 @@ SaltTextAway(XtermWidget xw,
+ }
+ *lp = '\0'; /* make sure we have end marked */
+
+-TRACE(("Salted TEXT:%u:%s\n", (unsigned) (lp - line),
+- visibleChars(line, (unsigned) (lp - line;
++have = (size_t) (lp - line);
++/*
++ * Scanning the buffer twice is unnecessary. Discard unwanted memory if
++ * the estimate is too-far off.
++ */
++if ((have * 2) < (size_t) need) {
++ scp->data_limit = have + 1;
++ line = realloc(line, scp->data_limit);
++}
++
++TRACE(("Salted TEXT:%u:%s\n", (unsigned) have,
++ visibleChars(line, (unsigned) have)));
+
+-scp->data_length = (size_t) (lp - line);
++scp->data_length = have;
+ }
+
+ #if OPT_PASTE64
diff -Nru xterm-344/debian/patches/series xterm-344/debian/patches/series
--- xterm-344/debian/patches/series 2019-02-13 17:54:29.0 +0100
+++ xterm-344/debian/patches/series 2021-02-17 18:51:05.0 +0100
@@ -1,3 +1,4 @@
900_debian_xterm.diff
902_windowops.diff
904_fontops.diff
+CVE-2021-27135.diff
signature.asc
Description: PGP signature
Re: Go issues wrt. Debian infrastructure: moving forward
Hi, On 31-01-2021 18:43, Shengjing Zhu wrote: > It might be the time to resume the discussion... > Dear ftpmaster, will the task that imports all sources to > security-master be ready for bullseye? I think this is a fair question. What's the status on the archive side of things? (A "no" or "depends on $something" is also an answer). Paul OpenPGP_signature Description: OpenPGP digital signature
Re: planning to upload binutils 2.35.2
Hi Matthias On Fri, 12 Feb 2021 at 12:41, Matthias Klose wrote: > https://release.debian.org/britney/pseudo-excuses-experimental.html#binutils > shows no regressions except for cross-toolchain-base, caused by the version > scheme proposed by yourself. As the build in experimental shows, the package > builds and the regression will go away with a proper version number. That looks good, and thanks for the explanation of the failure. Please go ahead and upload 2.35.2 to unstable. > Also > seeing another linux upload flying by again without getting any ack or review > seems to be odd. The acknowledgement from Release Team, that unfortunately happened in private, was for 5.10.x updates, so you may still see more of these. Regards Graham
Bug#982997: marked as done (unblock: python-hdf5storage/0.1.15+git20200608.09dfc5f-2)
Your message dated Thu, 18 Feb 2021 13:24:08 +0200 with message-id and subject line Re: Bug#982997: unblock: python-hdf5storage/0.1.15+git20200608.09dfc5f-2 has caused the Debian Bug report #982997, regarding unblock: python-hdf5storage/0.1.15+git20200608.09dfc5f-2 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.) -- 982997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982997 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: unblock Please unblock package python-hdf5storage [ Reason ] Upstream has identified the problem affecting random failure of tests reported in RC Bug#971806. It was in a random number used to label the numpy dtype. They have prepared a small patch, already commited to the upstream main branch and applied in python-hdf5storage/0.1.15+git20200608.09dfc5f-2 [ Impact ] Preventing python-hdf5storage from migrating to bullseye will have a negative impact on hdf5storage users attempting to upgrade from buster, stranding them with a deprecated version of the package. [ Tests ] debian/tests run the affected test, which was test_write_readback.TestPythonMatlabFormat.test_dtype_structured_with_offsets_titles in tests/test_write_readback.py This test is now expected to succeed reliably. [ Risks ] Minimal clear patch (+6-2 lines) in a leaf package not affecting other packages. Very low risk. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [ ] attach debdiff against the package in testing (the package is not currently in testing, the diff is taken against the preceding version in unstable) unblock python-hdf5storage/0.1.15+git20200608.09dfc5f-2 diff -Nru python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/changelog python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/changelog --- python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/changelog 2020-08-07 16:39:18.0 +0200 +++ python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/changelog 2021-02-17 21:33:33.0 +0100 @@ -1,3 +1,13 @@ +python-hdf5storage (0.1.15+git20200608.09dfc5f-2) unstable; urgency=medium + + * Team upload. + * debian patch fix_dtype_random_title_1444936.patch applies +upstream commit #1444936 to fix random dtype titles used in tests. +Closes: #971806. + * Standards-Version: 4.5.1 + + -- Drew Parsons Wed, 17 Feb 2021 21:33:33 +0100 + python-hdf5storage (0.1.15+git20200608.09dfc5f-1) unstable; urgency=medium * Team upload. diff -Nru python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/control python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/control --- python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/control 2020-08-07 16:39:18.0 +0200 +++ python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/control 2021-02-17 21:33:33.0 +0100 @@ -18,7 +18,7 @@ python3-sphinx, python3-sphinx-rtd-theme, python3-setuptools -Standards-Version: 4.5.0 +Standards-Version: 4.5.1 Vcs-Browser: https://salsa.debian.org/science-team/python-hdf5storage Vcs-Git: https://salsa.debian.org/science-team/python-hdf5storage.git Homepage: https://github.com/frejanordsiek/hdf5storage diff -Nru python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/patches/fix_dtype_random_title_1444936.patch python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/patches/fix_dtype_random_title_1444936.patch --- python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/patches/fix_dtype_random_title_1444936.patch 1970-01-01 01:00:00.0 +0100 +++ python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/patches/fix_dtype_random_title_1444936.patch 2021-02-17 21:33:33.0 +0100 @@ -0,0 +1,32 @@ +From 144493620a76e44f9012a22f163b14cd5e6cc61b Mon Sep 17 00:00:00 2001 +From: Freja Nordsiek +Date: Wed, 17 Feb 2021 19:46:07 +0100 +Subject: [PATCH] Fixed bug (Issue #104) in generating random titles for the + dtype fields in the unit tests, which must be unique. + +--- + tests/test_write_readback.py | 8 ++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +Index: python-hdf5storage/tests/test_write_readback.py +=== +--- python-hdf5storage.orig/tests/test_write_readback.py 2021-02-17 21:24:21.288834712 +0100 python-hdf5storage/tests/test_write_readback.py2021-02-17 21:24:21.284834709 +0100 +@@ -846,11 +846,15 @@ + while s in names and
Processed: closing 982949
Processing commands for cont...@bugs.debian.org: > close 982949 Bug #982949 [release.debian.org] Please allow libvirt-python 7.0.0 into bullseye Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 982949: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982949 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#982949: Please allow libvirt-python 7.0.0 into bullseye
Hi Paul, On Wed, Feb 17, 2021 at 10:55:14PM +0100, Paul Gevers wrote: > Hi Bernd, > > On 17-02-2021 22:30, Bernd Zeimetz wrote: > > On Wed, 2021-02-17 at 18:37 +0100, Paul Gevers wrote: > >> libvirt-python is a key package. > > > > and it should match libvirt. Having libvirt-python 6.x and libvirt 7.0 > > is (imho, ymmv...) much worse than an completely (from us) untested > > libvirt-python. > > I understood from the request that it's an option to patch 6.x. Because, > if Guido believes it really should match, than why did he file an > unblock request? We're only in the soft freeze right now, only *new* I don't think I marked it as unblock request. I used "allow" here to indicate that i'm not entirely sure if the scope is still o.k. Sorry if it was confusing. > packages are blocked and we age packages a bit more, so technically > there's nothing to unblock at this moment. Currently it's still the > maintainers call what's right for bullseye. We, as the release team, ask > for targeted fixes. If you consider this out-of-sync to be an issue of > its' own, than please, align with Guido and I have good faith that > you'll do the best in Debian interest, keeping our guidelines in the > freeze policy [1] into account. I suggest to really not wait to long, Uploaded now. Cheers, -- Guido > because after the hard freeze starts, this indeed requires an unblock > from us. If the package (whichever option you choose) can migrate before > that, that would be great. > > Paul > > [1] https://release.debian.org/bullseye/freeze_policy.html#soft >
