Bug#979753: nmu: viking_1.8-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Please rebuild viking (1.8-4) with the new mapnik in unstable: nmu viking_1.8-4 . ANY . unstable . -m "Rebuild against libmapnik3.1" dw viking_1.8-4 . ANY . unstable . -m "libmapnik-dev (>= 3.1.0)" Kind Regards, Bas
Bug#979750: transition: skalibs execline s6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: z...@debian.org Hi, Skarnet.org softwares just released a new version today... http://skarnet.org/cgi-bin/archive.cgi?1:mss:1515:202101:mhcdpginfgieagphalne I have packaged three of them, which are skalibs, execline and s6. They both have SO bump this time. There's no reverse depend except for themselves. I have uploaded them to experimental, and still wait for the NEW queue. Can this be warranted for the "Soft Freeze" deadline as no other packages are involved. Thanks
Bug#979749: buster-pu: package emacs/1:26.1+1-3.2+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu dkg has requested that we consider fixing this bug in buster: Debian: https://bugs.debian.org/919642 Upstream: https://debbugs.gnu.org/34121 which is fairly straightforward (just the new patch at the end, cherry-picked directly from the upstream fix): diff -Nru emacs-26.1+1/debian/.git-dpm emacs-26.1+1/debian/.git-dpm --- emacs-26.1+1/debian/.git-dpm 2019-09-04 21:35:24.0 -0500 +++ emacs-26.1+1/debian/.git-dpm 2021-01-10 19:22:48.0 -0600 @@ -1,6 +1,6 @@ # see git-dpm(1) from git-dpm package -face2676a9d5a13b40eaeecfb09a16e81364e916 -face2676a9d5a13b40eaeecfb09a16e81364e916 +7812b00398e73156c07be2ea2abe1dbf0153ccfe +7812b00398e73156c07be2ea2abe1dbf0153ccfe 511a2cebd6df0f71ec24b5939564fb58726ead84 511a2cebd6df0f71ec24b5939564fb58726ead84 emacs_26.1+1.orig.tar.xz diff -Nru emacs-26.1+1/debian/changelog emacs-26.1+1/debian/changelog --- emacs-26.1+1/debian/changelog 2019-09-04 21:35:24.0 -0500 +++ emacs-26.1+1/debian/changelog 2021-01-10 19:22:48.0 -0600 @@ -1,3 +1,11 @@ +emacs (1:26.1+1-3.2+deb10u2~1.gbp7c5887) UNRELEASED; urgency=medium + + ** SNAPSHOT build @7c5887c8ae064398fafa38b8fea4c5d500830d5f ** + + * UNRELEASED + + -- Rob Browning Sun, 10 Jan 2021 19:22:48 -0600 + emacs (1:26.1+1-3.2+deb10u1) buster; urgency=high * Update the EPLA packaging key (previous key expires 2019-09-23) via diff -Nru emacs-26.1+1/debian/patches/0001-Prefer-usr-share-info-emacs.patch emacs-26.1+1/debian/patches/0001-Prefer-usr-share-info-emacs.patch --- emacs-26.1+1/debian/patches/0001-Prefer-usr-share-info-emacs.patch 2019-09-04 21:35:24.0 -0500 +++ emacs-26.1+1/debian/patches/0001-Prefer-usr-share-info-emacs.patch 2021-01-10 19:22:48.0 -0600 @@ -15,7 +15,7 @@ index 8743b449976..14d62f7f1cb 100644 --- a/lisp/info.el +++ b/lisp/info.el -@@ -213,7 +213,8 @@ A header-line does not scroll with the rest of the buffer." +@@ -213,7 +213,8 @@ Info-default-directory-list (nconc standard-info-dirs (list config-dir)) (cons config-dir standard-info-dirs (if (not (eq system-type 'windows-nt)) diff -Nru emacs-26.1+1/debian/patches/0002-Run-debian-startup-and-set-debian-emacs-flavor.patch emacs-26.1+1/debian/patches/0002-Run-debian-startup-and-set-debian-emacs-flavor.patch --- emacs-26.1+1/debian/patches/0002-Run-debian-startup-and-set-debian-emacs-flavor.patch 2019-09-04 21:35:24.0 -0500 +++ emacs-26.1+1/debian/patches/0002-Run-debian-startup-and-set-debian-emacs-flavor.patch 2021-01-10 19:22:48.0 -0600 @@ -19,7 +19,7 @@ index 9d16b59defd..d20431492a7 100644 --- a/lisp/startup.el +++ b/lisp/startup.el -@@ -434,6 +434,10 @@ Warning Warning!!! Pure space overflow!!!Warning Warning +@@ -434,6 +434,10 @@ tutorial-directory :type 'directory :initialize #'custom-initialize-delay) @@ -30,7 +30,7 @@ (defun normal-top-level-add-subdirs-to-load-path () "Recursively add all subdirectories of `default-directory' to `load-path'. More precisely, this uses only the subdirectories whose names -@@ -1121,8 +1125,21 @@ please check its value") +@@ -1121,8 +1125,21 @@ command-line ;; be loaded from site-run-file and wants to test if -q was given ;; should check init-file-user instead, since that is already set. ;; See cus-edit.el for an example. diff -Nru emacs-26.1+1/debian/patches/0003-Remove-files-that-appear-to-be-incompatible-with-the.patch emacs-26.1+1/debian/patches/0003-Remove-files-that-appear-to-be-incompatible-with-the.patch --- emacs-26.1+1/debian/patches/0003-Remove-files-that-appear-to-be-incompatible-with-the.patch 2019-09-04 21:35:24.0 -0500 +++ emacs-26.1+1/debian/patches/0003-Remove-files-that-appear-to-be-incompatible-with-the.patch 2021-01-10 19:22:48.0 -0600 @@ -253,7 +253,7 @@ index 77e32848318..22516310692 100644 --- a/lisp/help.el +++ b/lisp/help.el -@@ -292,6 +292,14 @@ If that doesn't give a function, return nil." +@@ -292,6 +292,14 @@ view-help-file (goto-address-mode 1) (goto-char (point-min))) diff -Nru emacs-26.1+1/debian/patches/0005-Modify-the-output-of-version-to-indicate-Debian-modi.patch emacs-26.1+1/debian/patches/0005-Modify-the-output-of-version-to-indicate-Debian-modi.patch --- emacs-26.1+1/debian/patches/0005-Modify-the-output-of-version-to-indicate-Debian-modi.patch 2019-09-04 21:35:24.0 -0500 +++ emacs-26.1+1/debian/patches/0005-Modify-the-output-of-version-to-indicate-Debian-modi.patch 2021-01-10 19:22:48.0 -0600 @@ -15,7 +15,7 @@ index 3a38b1d83c8..5d1248ac581 100644 --- a/lisp/version.el +++ b/lisp/version.el -@@ -62,7 +62,7 @@ Don't use this function in programs to choose actions according +@@ -62,7 +62,7 @@ emacs-version to the system configuration; look at `system-configuration' instead." (interactive "P") (let ((version-string diff -Nru
Bug#979303: marked as done (transition: ppp)
Your message dated Mon, 11 Jan 2021 00:19:36 +0100 with message-id and subject line Re: Bug#979303: transition: ppp has caused the Debian Bug report #979303, regarding transition: ppp 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.) -- 979303: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979303 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 release team folks, There has been a new upstream release of ppp (2.4.9). I know this is very soon after my upload of 2.4.8 and its transition, but I'm also both aware of the transition freeze that's coming up and a large number of improvements in the new release. Before I go ahead and update all my packaging, is it likely that we can get ppp 2.4.9 into bullseye? I dont' wish to over-burden you or push the boundaries of the freeze, hence the query. In case this is acceptable: Ben file: title = "ppp"; is_affected = .build-depends ~ /ppp-dev/; is_good = .depends ~ /ppp \(>= 2\.4\.9-1\+~\)/ | .breaks ~ /ppp \(<< 2\.4\.9-1\+~\)/; is_bad = .depends ~ /ppp \(>= 2\.4\.8-1\+~\)/ | .breaks ~ /ppp \(<< 2\.4\.8-1\+~\)/; Many thanks in advance, Chris --- End Message --- --- Begin Message --- On 2021-01-05 00:19:13 +, Chris Boot wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi release team folks, > > There has been a new upstream release of ppp (2.4.9). I know this is > very soon after my upload of 2.4.8 and its transition, but I'm also both > aware of the transition freeze that's coming up and a large number of > improvements in the new release. > > Before I go ahead and update all my packaging, is it likely that we can > get ppp 2.4.9 into bullseye? I dont' wish to over-burden you or push the > boundaries of the freeze, hence the query. ppp 2.4.9 and the binNMUs migrated. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature --- End Message ---
Bug#976397: marked as done (transition: opencv)
Your message dated Sun, 10 Jan 2021 23:15:48 +0100 with message-id and subject line Re: Bug#976397: transition: opencv has caused the Debian Bug report #976397, regarding transition: opencv 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.) -- 976397: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976397 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 The opencv version in unstable is relatively old. I'd like to make the latest version of opencv into the next stable release. Ben file: title = "opencv"; is_affected = .depends ~ "libopencv.*4\.2" | .depends ~ "libopencv.*4\.5"; is_good = .depends ~ "libopencv.*4\.5"; is_bad = .depends ~ "libopencv.*4\.2"; -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads) 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 not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- End Message --- --- Begin Message --- On 2020-12-04 16:21:25 +, Mo Zhou wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > The opencv version in unstable is relatively old. I'd like to make the > latest version of opencv into the next stable release. The old binaries got removed from testing. Closing Cheers > > Ben file: > > title = "opencv"; > is_affected = .depends ~ "libopencv.*4\.2" | .depends ~ "libopencv.*4\.5"; > is_good = .depends ~ "libopencv.*4\.5"; > is_bad = .depends ~ "libopencv.*4\.2"; > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, > 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads) > 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 not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > -- Sebastian Ramacher signature.asc Description: PGP signature --- End Message ---
Bug#978072: marked as done (transition: libcrypto++)
Your message dated Sun, 10 Jan 2021 23:13:59 +0100 with message-id and subject line Re: Bug#978072: transition: libcrypto++ has caused the Debian Bug report #978072, regarding transition: libcrypto++ 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.) -- 978072: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978072 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 RMs, I would like to ship the recently released Crypto++ 8.3.0 release for Bullseye. List of reverse dependencies are as follows: amule clementine codecrypt entropybroker securefs tegrarcm [non-free] Currently entropybroker fails to build with this Crypto++ release, but its upstream has a fix for that. Package maintainer noted about this [1]. Thanks for consideration, Laszlo/GCS [1] https://bugs.debian.org/978071 --- End Message --- --- Begin Message --- On 2020-12-25 14:44:25 +0100, László Böszörményi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi RMs, > > I would like to ship the recently released Crypto++ 8.3.0 release for > Bullseye. List of reverse dependencies are as follows: > amule > clementine > codecrypt > entropybroker > securefs > tegrarcm [non-free] > > Currently entropybroker fails to build with this Crypto++ release, but > its upstream has a fix for that. Package maintainer noted about this > [1]. The old binaries got removed. Closing. Cheers > > Thanks for consideration, > Laszlo/GCS > [1] https://bugs.debian.org/978071 > -- Sebastian Ramacher signature.asc Description: PGP signature --- End Message ---
Bug#979724: buster-pu: package libmaxminddb/1.3.2-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi there,
This is an buster proposed update to fix CVE-2020-28241:
| libmaxminddb before 1.4.3 has a heap-based buffer over-read in
| dump_entry_data_list in maxminddb.c.
The security team has marked the CVE as " (Minor issue)", and
filed #973878 against the package.
The fix was part of the 1.4.3 upstream version; bullseye has 1.4.3-1,
sid has 1.5.0-1, so it's fixed in both.
You'll find the source debdiff below (and also in salsa).
Thanks!
Faidon
diff -Nru libmaxminddb-1.3.2/debian/changelog
libmaxminddb-1.3.2/debian/changelog
--- libmaxminddb-1.3.2/debian/changelog 2018-05-26 19:37:59.0 +0300
+++ libmaxminddb-1.3.2/debian/changelog 2021-01-10 21:10:00.0 +0200
@@ -1,3 +1,10 @@
+libmaxminddb (1.3.2-1+deb10u1) buster; urgency=medium
+
+ * Backport upstream fix for CVE-2020-28241, heap-based buffer over-read in
+dump_entry_data_list in maxminddb.c. (Closes: #973878)
+
+ -- Faidon Liambotis Sun, 10 Jan 2021 21:10:00 +0200
+
libmaxminddb (1.3.2-1) unstable; urgency=medium
* New upstream release.
diff -Nru libmaxminddb-1.3.2/debian/gbp.conf libmaxminddb-1.3.2/debian/gbp.conf
--- libmaxminddb-1.3.2/debian/gbp.conf 2018-05-26 19:28:43.0 +0300
+++ libmaxminddb-1.3.2/debian/gbp.conf 2021-01-10 21:10:00.0 +0200
@@ -1,6 +1,6 @@
[DEFAULT]
upstream-tree=tag
-debian-branch=debian
+debian-branch=debian/buster
upstream-tag = %(version)s
no-create-orig = False
submodules = True
diff -Nru libmaxminddb-1.3.2/debian/patches/0002-CVE-2020-28241.patch
libmaxminddb-1.3.2/debian/patches/0002-CVE-2020-28241.patch
--- libmaxminddb-1.3.2/debian/patches/0002-CVE-2020-28241.patch 1970-01-01
02:00:00.0 +0200
+++ libmaxminddb-1.3.2/debian/patches/0002-CVE-2020-28241.patch 2021-01-10
21:10:00.0 +0200
@@ -0,0 +1,113 @@
+From: Gregory Oschwald
+Date: Wed, 5 Aug 2020 14:16:17 -0700
+Subject: [PATCH] Replace most malloc uses with calloc
+
+Closes #236.
+---
+ bin/mmdblookup.c| 2 +-
+ doc/libmaxminddb.md | 2 +-
+ src/maxminddb.c | 16
+ 3 files changed, 10 insertions(+), 10 deletions(-)
+
+diff --git a/bin/mmdblookup.c b/bin/mmdblookup.c
+index 030d88c..513ad2d 100644
+--- a/bin/mmdblookup.c
b/bin/mmdblookup.c
+@@ -263,7 +263,7 @@ LOCAL const char **get_options(
+ }
+
+ const char **lookup_path =
+-malloc(sizeof(const char *) * ((argc - optind) + 1));
++calloc((argc - optind) + 1, sizeof(const char *));
+ int i;
+ for (i = 0; i < argc - optind; i++) {
+ lookup_path[i] = argv[i + optind];
+diff --git a/doc/libmaxminddb.md b/doc/libmaxminddb.md
+index e6de9d5..15433c3 100644
+--- a/doc/libmaxminddb.md
b/doc/libmaxminddb.md
+@@ -307,7 +307,7 @@ libmaxminddb code.
+
+ The `utf8_string`, `bytes`, and (maybe) the `uint128` members of this
structure
+ are all pointers directly into the database's data section. This can either be
+-a `malloc`'d or `mmap`'d block of memory. In either case, these pointers will
++a `calloc`'d or `mmap`'d block of memory. In either case, these pointers will
+ become invalid after `MMDB_close()` is called.
+
+ If you need to refer to this data after that time you should copy the data
+diff --git a/src/maxminddb.c b/src/maxminddb.c
+index 7580e1e..ec547d6 100644
+--- a/src/maxminddb.c
b/src/maxminddb.c
+@@ -35,7 +35,7 @@
+ do {\
+ char *binary = byte_to_binary(byte);\
+ if (NULL == binary) { \
+-fprintf(stderr, "Malloc failed in DEBUG_BINARY\n"); \
++fprintf(stderr, "Calloc failed in DEBUG_BINARY\n"); \
+ abort();\
+ } \
+ fprintf(stderr, fmt "\n", binary); \
+@@ -54,7 +54,7 @@
+ #ifdef MMDB_DEBUG
+ DEBUG_FUNC char *byte_to_binary(uint8_t byte)
+ {
+-char *bits = malloc(sizeof(char) * 9);
++char *bits = calloc(9, sizeof(char));
+ if (NULL == bits) {
+ return bits;
+ }
+@@ -687,7 +687,7 @@ LOCAL int populate_languages_metadata(MMDB_s *mmdb, MMDB_s
*metadata_db,
+ MMDB_INVALID_METADATA_ERROR);
+
+ mmdb->metadata.languages.count = 0;
+-mmdb->metadata.languages.names = malloc(array_size * sizeof(char *));
++mmdb->metadata.languages.names = calloc(array_size, sizeof(char *));
+ if (NULL == mmdb->metadata.languages.names) {
+ return MMDB_OUT_OF_MEMORY_ERROR;
+ }
+@@ -705,7 +705,7 @@ LOCAL int populate_languages_metadata(MMDB_s *mmdb, MMDB_s
*metadata_db,
+ if (NULL == mmdb->metadata.languages.names[i]) {
+ return MMDB_OUT_OF_MEMORY_ERROR;
+ }
+-// We assign this as we go so that if we fail a malloc and need to
++// We assign this
Processed: Re: Bug#979651: transition: libpodofo
Processing control commands: > forwarded -1 https://release.debian.org/transitions/html/auto-libpodofo.html Bug #979651 [release.debian.org] transition: libpodofo Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/auto-libpodofo.html'. > tag -1 moreinfo Bug #979651 [release.debian.org] transition: libpodofo Added tag(s) moreinfo. -- 979651: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979651 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#979651: transition: libpodofo
Control: forwarded -1 https://release.debian.org/transitions/html/auto-libpodofo.html Control: tag -1 moreinfo On Sat, Jan 09, 2021 at 07:03:34PM +0100, Mattia Rizzolo wrote: > I haven't yet rebuilt the rdeps, but since the API didn't change I don't > expect any breakage; I'll follow up once I've confirmed everything's > fine. I rebuilt the 5 rdeps and it turns out scribus failed with it. I'll be back once I get it building. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#976352: marked as done (transition: libjsoncpp)
Your message dated Sun, 10 Jan 2021 18:29:14 +0100 with message-id and subject line Re: Bug#976352: transition: libjsoncpp has caused the Debian Bug report #976352, regarding transition: libjsoncpp 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.) -- 976352: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976352 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal Hello, I would like to finally do this libjsoncpp transition before freeze. The version in sid has lots of bugs, and its really outdated. We have ~30 reverse-dependencies, last time I checked they were all building fine, I'm doing test rebuilds again and will update this bug report in a day or two with a complete list. Ben file: title = "libjsoncpp"; is_affected = .depends ~ "libjsoncpp1" | .depends ~ "libjsoncpp24"; is_good = .depends ~ "libjsoncpp24"; is_bad = .depends ~ "libjsoncpp1"; thanks Gianfranco --- End Message --- --- Begin Message --- On 2020-12-03 22:09:35 +0100, Gianfranco Costamagna wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: transition > Severity: normal > > Hello, I would like to finally do this libjsoncpp transition before freeze. > The version in sid has lots of bugs, and its really outdated. > > We have ~30 reverse-dependencies, last time I checked they were all building > fine, I'm doing test rebuilds again and will update this bug report in a day > or two with a complete list. The old binaries got removed. Closing Cheers > > Ben file: > > title = "libjsoncpp"; > is_affected = .depends ~ "libjsoncpp1" | .depends ~ "libjsoncpp24"; > is_good = .depends ~ "libjsoncpp24"; > is_bad = .depends ~ "libjsoncpp1"; > > > thanks > > Gianfranco > -- Sebastian Ramacher signature.asc Description: PGP signature --- End Message ---
Re: Why does opencascade not migrate?
Hello Sebastian, seems your original email didn't reached me, but I've seen your answer in the list web ui. ... > That means that migrating those packages renders libdeal.ii-dev > uninstallable in testing. Consequently, the changes are not committed. > > The binNMU fixing libdeal.ii-dev's installability issues is currently > blocked by openmpi and other packages waiting for openmpi to migrate: > > deal.ii/amd64 (9.2.0-3 to 9.2.0-3) > Migration status for deal.ii/amd64 (9.2.0-3 to 9.2.0-3): BLOCKED: > Cannot migrate due to another item, which is blocked (please check which > dependencies are stuck) > Issues preventing migration: > Depends: deal.ii/amd64 petsc (not considered) > Invalidated by dependency > Depends: deal.ii/amd64 opencascade > Depends: deal.ii/amd64 openmpi > Depends: deal.ii/amd64 slepc > > (from https://release.debian.org/britney/update_excuses.html) > > Once the openmpi situation is resolved, opencascade should be able to > migrate. Thanks for analyzing and explanation. So this all should get solved by simply further waiting currently. -- Regards Carsten
Re: Re: Why does opencascade not migrate?
Bug#974649: marked as done (transition: nifticlib)
Your message dated Sun, 10 Jan 2021 16:11:45 +0100 with message-id <20210110151145.ga24...@ramacher.at> and subject line Re: Bug#974649: release.debian.org: new libnifti2 broke runtime (see #968730) has caused the Debian Bug report #974649, regarding transition: nifticlib 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.) -- 974649: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974649 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal Hello, looks like new libnifti2 changed the runtime library name without changing soname (See #968730 for underground issue), so now reverse-dependencies are having troubles to start without a binNMU. We might just ask libnifti2 people to restore a symlink for compatibility, but I think its better to just binNMU reverse-dependencies and then break old version to ensure good upgrade paths. This is the list of stuff that needs binNMUs reverse-depends -r hirsute -b libnifti-dev Reverse-Build-Depends * dicomnifti * elastix * fsl * gifticlib * insighttoolkit4 * libminc * mia * minc-tools * odin * xmedcon thanks Gianfranco --- End Message --- --- Begin Message --- On 2020-11-13 13:14:32, Sebastian Ramacher wrote: > Control: block -1 by 968730 > Control: tags -1 + moreinfo > > On 2020-11-13 11:29:40, Gianfranco Costamagna wrote: > > Package: release.debian.org > > Severity: normal > > > > Hello, looks like new libnifti2 changed the runtime library name without > > changing soname (See #968730 for underground issue), so > > now reverse-dependencies are having troubles to start without a binNMU. > > > > We might just ask libnifti2 people to restore a symlink for compatibility, > > but I think its better to just binNMU reverse-dependencies and then break > > old version to ensure good upgrade paths. > > This package is currently broken. I cannot judge if the ABI actually > changed or not and the SONAME changes are desired, but please get this > fixed in libnifti first. binNMUs would just paper over the underlying > problem. > > Once that's fixed, we can still do a proper transition if necessary. That's finally done. Cheer > Cheers > > > > > This is the list of stuff that needs binNMUs > > > > reverse-depends -r hirsute -b libnifti-dev > > Reverse-Build-Depends > > * dicomnifti > > * elastix > > * fsl > > * gifticlib > > * insighttoolkit4 > > * libminc > > * mia > > * minc-tools > > * odin > > * xmedcon > > > > thanks > > > > Gianfranco > > > > -- > Sebastian Ramacher > -- Sebastian Ramacher--- End Message ---
Bug#979106: transition: limesuite
Re: Sebastian Ramacher > > There is a new version of limesuite in experimental, the driver for > > the Limesdr software defined radios. > > The old packages got removed from testing. Closing Thanks! Christoph
Bug#974667: marked as done (transition: dpdk)
Your message dated Sun, 10 Jan 2021 14:35:01 + with message-id and subject line Bug#974667: fixed in dpdk 20.11-2 has caused the Debian Bug report #974667, regarding transition: dpdk 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.) -- 974667: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974667 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: openvswitch Version: 2.13.0+dfsg1-12 Severity: normal X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org christian.ehrha...@canonical.com Tags: bullseye Dear Openvswitch Maintainers, We are scoping the src:dpdk 19.11 -> 20.11 transition. If possible, we'd really like to go to bullseye with the latest upstream LTS, as 19.11 is EOL at the end of next year. OVS support for DPDK 20.11 will be released upstream in v2.15, which is due for release on February 15 [1]. Bullseye transition freeze is on January 12 [2], so the dates don't align very well. So we are looking to formulate a plan that you can agree with, to sort this out. Based on experience, what Ubuntu usually does to meet release deadlines is to upload from git earlier than the release, so that all major incompatibilities can be sorted. And then after the freeze, once the release is officially out, do a final upgrade to the released version - since a similar enough version was uploaded from git, and at the end of a release cycle it's mostly bug fixes that land upstream, such an upload is acceptable. So we'd like to propose the following ideas: - between now and December: upload v2.14, to minimize the later jump - by the first week of January: upload 2.15~git from the tip of the master branch to experimental - stabilize and sort eventual build issues - upload dpdk 20.11 and ovs 2.15~git to unstable - upload 2.15 proper in February as a bug fix upload to unstable What do you think? Does this sound like a workable plan? We are of course happy to help - Ubuntu will go through the exact same process for 21.04, so a lot of the work is "shared". Thank you! -- Kind regards, Luca Boccassi [1] https://docs.openvswitch.org/en/latest/internals/release-process/ [2] https://release.debian.org/bullseye/freeze_policy.html signature.asc Description: This is a digitally signed message part --- End Message --- --- Begin Message --- Source: dpdk Source-Version: 20.11-2 Done: Luca Boccassi We believe that the bug you reported is fixed in the latest version of dpdk, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 974...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Luca Boccassi (supplier of updated dpdk package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 10 Jan 2021 13:49:27 + Source: dpdk Architecture: source Version: 20.11-2 Distribution: unstable Urgency: high Maintainer: Debian DPDK Maintainers Changed-By: Luca Boccassi Closes: 974667 979489 Changes: dpdk (20.11-2) unstable; urgency=high . [ Christian Ehrhardt ] * dpdk.service: start earlier and avoid dependency loop (Closes: #979489) . [ Luca Boccassi ] * Upload to unstable. (Closes: #974667) . dpdk (20.11-1) experimental; urgency=medium . * dpdk: suggest dpdk-kmods-dkms * dpdk: drop Suggests: linux-image-generic, not needed * New upstream release 20.11; for a full list of changes see: http://doc.dpdk.org/guides-20.11/rel_notes/release_20_11.html * dpdk: install new dpdk-hugepages.py script * dpdk-dev: override lintian warnings about new scripts * d/watch: bump to version 4, no changes * d/copyright: update new path to rte_kni_common.h * Bump Standards-Version to 4.5.1, no changes * Add symbols files for librte-graph, librte-node, librte-regexdev . dpdk (20.11~rc3-1) experimental; urgency=medium . [ Christian Ehrhardt ] * New upstream release candidate 20.11~rc1 For details see https://doc.dpdk.org/guides/rel_notes/release_20_11.html * d/update-helper-control.py: bump to new deb822 name * d/p/*: drop python3 test fixes [applied upstream] * d/control, d/rules: igb-uio module no more provided by dkms source * d/*.symbols: update to new names and added
Bug#979106: marked as done (transition: limesuite)
Your message dated Sun, 10 Jan 2021 15:35:55 +0100 with message-id <20210110143555.gb2...@ramacher.at> and subject line Re: Bug#979106: transition: limesuite has caused the Debian Bug report #979106, regarding transition: limesuite 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.) -- 979106: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979106 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 There is a new version of limesuite in experimental, the driver for the Limesdr software defined radios. There are only 2 rdepends external to the source package, gr-limesdr and osmo-trx. Both build fine with the new version, and I also tested with sdrangel (an ITP which should finally upload). Ben file: title = "limesuite"; is_affected = .depends ~ "liblimesuite20.01-1" | .depends ~ "liblimesuite20.10-1"; is_good = .depends ~ "liblimesuite20.10-1"; is_bad = .depends ~ "liblimesuite20.01-1"; Are we ok to upload to unstable? Thanks, Christoph --- End Message --- --- Begin Message --- On 2021-01-02 20:00:36, Christoph Berg wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > There is a new version of limesuite in experimental, the driver for > the Limesdr software defined radios. > > There are only 2 rdepends external to the source package, gr-limesdr > and osmo-trx. Both build fine with the new version, and I also tested > with sdrangel (an ITP which should finally upload). The old packages got removed from testing. Closing Cheers > > Ben file: > > title = "limesuite"; > is_affected = .depends ~ "liblimesuite20.01-1" | .depends ~ > "liblimesuite20.10-1"; > is_good = .depends ~ "liblimesuite20.10-1"; > is_bad = .depends ~ "liblimesuite20.01-1"; > > Are we ok to upload to unstable? > > Thanks, > Christoph > -- Sebastian Ramacher--- End Message ---
Processed: Re: Bug#979185: transition: muparserx
Processing control commands: > forwarded -1 https://release.debian.org/transitions/html/auto-muparserx.html Bug #979185 [release.debian.org] transition: muparserx Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/auto-muparserx.html'. > tags -1 + confirmed Bug #979185 [release.debian.org] transition: muparserx Added tag(s) confirmed. -- 979185: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979185 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#979185: transition: muparserx
Control: forwarded -1 https://release.debian.org/transitions/html/auto-muparserx.html Control: tags -1 + confirmed On 2021-01-04 01:36:50, Andreas Bombe wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > This package has been sitting in experimental for… a while (and there > was no upstream release in the meantime, so at least there's that). It's > just a small transition so this should be quick and easy to get out of > the way. > > There are only 2 rdepends, and of those only otb is actually in testing. > I made a successful test build of otb with the new package. Please go ahead. Cheers > > Ben file (but the auto-ben file also looks good): > > title = "muparserx"; > is_affected = .depends ~ "libmuparserx4.0.7" | .depends ~ "libmuparserx4.0.8"; > is_good = .depends ~ "libmuparserx4.0.8"; > is_bad = .depends ~ "libmuparserx4.0.7"; > > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.9.0-5-amd64 (SMP w/16 CPU threads) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled -- Sebastian Ramacher
Bug#979320: marked as done (transition: xmltooling)
Your message dated Sun, 10 Jan 2021 15:14:18 +0100
with message-id <20210110141418.ga2...@ramacher.at>
and subject line Re: Bug#979320: transition: xmltooling
has caused the Debian Bug report #979320,
regarding transition: xmltooling
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.)
--
979320: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979320
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
Dear Release Team,
The recent 3.2 release of the Shibboleth SP is a minor release, but due
to the internal structure of the stack it entails the usual three
transitions for xmltooling, opensaml and shibboleth-sp. I'd like to do
successive sourceful uploads for these (the updated packages are already
in experimental). The two other impacted packages build fine without any
change: shibboleth-resolver and moonshot-gss-eap. The auto-{xmltooling,
opensaml,shibboleth-sp} trackers are good. I'm ready to upload to
unstable on your word.
--
Thanks,
Feri.
--- End Message ---
--- Begin Message ---
On 2021-01-05 10:47:56, Ferenc Wágner wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Dear Release Team,
>
> The recent 3.2 release of the Shibboleth SP is a minor release, but due
> to the internal structure of the stack it entails the usual three
> transitions for xmltooling, opensaml and shibboleth-sp. I'd like to do
> successive sourceful uploads for these (the updated packages are already
> in experimental). The two other impacted packages build fine without any
> change: shibboleth-resolver and moonshot-gss-eap. The auto-{xmltooling,
> opensaml,shibboleth-sp} trackers are good. I'm ready to upload to
> unstable on your word.
The old binaries got removed from testing. Closing
Cheers
> --
> Thanks,
> Feri.
>
--
Sebastian Ramacher--- End Message ---
NEW changes in stable-new
Processing changes file: gnutls28_3.6.7-4+deb10u6_s390x-buildd.changes ACCEPT Processing changes file: qxmpp_1.0.0-4+deb10u1_s390x-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: geoclue-2.0_2.5.2-1+deb10u1_s390x-buildd.changes ACCEPT Processing changes file: iproute2_4.20.0-2+deb10u1_s390x-buildd.changes ACCEPT
