Bug#996204: Bug#998411: Bug#996204: transition: numerical library stack: hypre SONAME (Policy 8.1)
I have fixed gmsh. It will appear in NEW soon. Regards Anton
Bug#996204: transition: numerical library stack: hypre SONAME (Policy 8.1)
On 2021-11-04 21:41, Sebastian Ramacher wrote: On 2021-11-03 22:33:01 +0100, Drew Parsons wrote: ... The problem that hypre 2.18.1-1 (un-versioned libhypre) intended to solve is that hypre is ABI-ignorant (https://github.com/hypre-space/hypre/issues/56), so each point patch release would have to be a new binary package, and the upstream release rate is faster than the average NEW queue processing rate (the new package for the current transition would be libhypre2.22.1, and already libhypre2.23.0 is released upstream). (So why is this packaged as shared library?) A reasonable question to ask. For my part, it was already being packaged as a shared library when I started working on it, so I just continued it so. I could imagine a clash of hypre symbols if a client programs links against both petsc and sundials (which both use hypre), and uses hypre directly. I guess the symbol table must guard against clashes like that. ... Is it best to revert back to strict Policy 8.1 compliance, which will slow down hypre patch release updates? Yes. Having to wait for binNEW to being processed is not an excuse to violate a must section of the policy. Processing of packages in NEW can take some time. I'm also waiting on some of them for months. The solution to that is however not to abondon well established practices for shared libraries. The problems that are caused by that can be seen with libhypre and its reverse dependencies. Fair enough. I'll make the change, either to libhypre2.22.2 or to libhypre-static. Drew
Processed: Re: Bug#998067: transition: libsepol and libsemanage
Processing control commands: > tags -1 moreinfo Bug #998067 [release.debian.org] transition: libsepol and libsemanage Added tag(s) moreinfo. -- 998067: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998067 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#998067: transition: libsepol and libsemanage
Control: tags -1 moreinfo On 2021-10-29 13:44:16 +0200, Laurent Bigonville wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hello, > > libsepol and libsemanage have both bumped their soname from 1 to 2, the > packages already went through the NEW queue and are in experimental. > > The transition trackers are already created: > > https://release.debian.org/transitions/html/auto-libsepol.html > https://release.debian.org/transitions/html/auto-libsemanage.html > > Most of the packages are from the same upstream. > > For libsemanage, sssd and shadow will have to adjust their build-dependencies Have bugs been filed for that? Cheers > > For libsepol, dmraid must remove the build-dependency, this is useless, > see #929484. Note that dmraid already has a RC bug, for other reasons. > > Kind regards, > Laurent Bigonville > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#997997: marked as done (transition: netcdf-parallel)
Your message dated Thu, 4 Nov 2021 22:28:45 +0100 with message-id and subject line Re: Bug#997997: transition: netcdf-parallel has caused the Debian Bug report #997997, regarding transition: netcdf-parallel 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.) -- 997997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997997 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 X-Debbugs-Cc: debian-scie...@lists.debian.org Hi dear release team, I request permission to undetake the netcdf-parallel transition. netcdf-parallell is the parallel build(s) of netcdf; netcdf 4.8.1 is now in testing, and nertcdf-parallel 4.8.1 builds successfully in experimental. This is a mini-transition; the packages depending on netcdf-parallel are: netcdf-parallel adios exodusii I maintain all three, and adios and exodusii build against netcdf-parallel-4.8.1 successfully. There are uploads of adios and exodusii ready. Ben file: title = "netcdf-parallel"; is_affected = .depends ~ "(libnetcdf\-mpi\-18|libnetcdf\-pnetcdf\-18)" | .depends ~ "(libnetcdf\-mpi\-19|libnetcdf\-pnetcdf\-19)"; is_good = .depends ~ "(libnetcdf\-mpi\-19|libnetcdf\-pnetcdf\-19)"; is_bad = .depends ~ "(libnetcdf\-mpi\-18|libnetcdf\-pnetcdf\-18)"; --- End Message --- --- Begin Message --- On 2021-10-28 21:51:23 +0200, Sebastian Ramacher wrote: > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-netcdf-parallel.html > Control: tags -1 confirmed > > On 2021-10-28 13:12:32 +0100, Alastair McKinstry wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: debian-scie...@lists.debian.org > > > > Hi dear release team, > > > > I request permission to undetake the netcdf-parallel transition. > > netcdf-parallell is the parallel build(s) of netcdf; > > netcdf 4.8.1 is now in testing, and nertcdf-parallel 4.8.1 builds > > successfully > > in experimental. > > > > This is a mini-transition; the packages depending on netcdf-parallel are: > > > > netcdf-parallel > > > > adios > > exodusii > > > > I maintain all three, and adios and exodusii build against > > netcdf-parallel-4.8.1 successfully. > > There are uploads of adios and exodusii ready. > > Please go ahead The old binaries got removed. Cheers > > Cheers > > > > > Ben file: > > > > title = "netcdf-parallel"; > > is_affected = .depends ~ "(libnetcdf\-mpi\-18|libnetcdf\-pnetcdf\-18)" | > > .depends ~ "(libnetcdf\-mpi\-19|libnetcdf\-pnetcdf\-19)"; > > is_good = .depends ~ "(libnetcdf\-mpi\-19|libnetcdf\-pnetcdf\-19)"; > > is_bad = .depends ~ "(libnetcdf\-mpi\-18|libnetcdf\-pnetcdf\-18)"; > > > > -- > Sebastian Ramacher -- Sebastian Ramacher signature.asc Description: PGP signature --- End Message ---
Bug#996204: transition: numerical library stack: hypre SONAME (Policy 8.1)
On 2021-11-03 22:33:01 +0100, Drew Parsons wrote: > On 2021-11-03 20:57, Sebastian Ramacher wrote: > > Source: hypre > > Severity: serious > ... > > The real blocker is hypre, specifically: > > > > hypre (2.18.1-1) experimental; urgency=medium > > . > >* Team upload. > >* New upstream release. > >* Standards-Version: 4.4.1 > >* Provide library binary package as libhypre without the soname > > version embedded in the package name. Enforce version dependency > > through strict shlibs dependency. This is to workaround lack of > > ABI backwards compatibility and keep minor version updates being > > delayed in the NEW queue. See README.Debian. > > > > > > As a consequence, hypre breaks co-installability of all its reverse > > dependencies, therefore breaking smooth updates of the packages involved > > in the transition. And yes, in the end, deal.ii currently keeps the > > whole stack from migrating as it renders deal.ii's binaries > > uninstallable in testing. > > > The problem that hypre 2.18.1-1 (un-versioned libhypre) intended to solve is > that hypre is ABI-ignorant (https://github.com/hypre-space/hypre/issues/56), > so each point patch release would have to be a new binary package, and the > upstream release rate is faster than the average NEW queue processing rate > (the new package for the current transition would be libhypre2.22.1, and > already libhypre2.23.0 is released upstream). (So why is this packaged as shared library?) > hypre has only 2 direct reverse dependencies, petsc and sundials, which we > can keep up-to-date easily. The current problem is that deal.ii depends on > the old petsc3.14, so it can't be installed with the new petsc3.15. That's why the second sentence of 8.1 reads: "This allows several versions of the shared library to be installed at the same time, allowing installation of the new version of the shared library without immediately breaking binaries that depend on the old version." The problem is not deal.ii. > It > wouldn't be a problem in practice, if deal.ii hadn't started FTBFS > (Bug#996277) preventing it rebuilding against petsc 3.15. We could say it > was tactical error running the hypre and petsc ABI updates at the same time > (I wasn't anticipating deal.ii Bug#996277) deal.ii doesn't FTBFS. deal.ii cannot currently be rebuilt in unsable because of another broken shared library (#995424 in gmsh). Once deal.ii is rebuilt (in testing), #996277 will disappear. > If we revert back to version-named hypre library packages then the cost is > that we won't be able to provide timely patch updates for hypre (each one > will be a new library package needing to pass NEW, since hypre does not > provide ABI compatibility). > > The alternative for this transition is to remove deal.ii from testing, which > is happening anyway due to Bug#996277 It won't be removed. > So the use of un-versioned libhypre was intended as a specific exception to > Policy 8.1, for the purpose of facilitating faster hypre patch updates. The > irregularity is due to a lack of ABI-awareness in hypre itself. > > Is it best to revert back to strict Policy 8.1 compliance, which will slow > down hypre patch release updates? Yes. Having to wait for binNEW to being processed is not an excuse to violate a must section of the policy. Processing of packages in NEW can take some time. I'm also waiting on some of them for months. The solution to that is however not to abondon well established practices for shared libraries. The problems that are caused by that can be seen with libhypre and its reverse dependencies. Cheers -- Sebastian Ramacher
Processed: your mail
Processing commands for cont...@bugs.debian.org: > tags 998169 - moreinfo Bug #998169 [release.debian.org] transition: unixodbc Removed tag(s) moreinfo. > stop Stopping processing here. Please contact me if you need assistance. -- 998169: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998169 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: bullseye-pu: package kodi/19.3+dfsg1-1~deb11u1
Processing control commands: > close -1 Bug #995823 [release.debian.org] bullseye-pu: package kodi/19.3+dfsg1-1~deb11u1 Marked Bug as done -- 995823: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995823 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#995823: bullseye-pu: package kodi/19.3+dfsg1-1~deb11u1
Control: close -1
Bug#998436: bullseye-pu: package opendmarc/1.4.0~beta1+dfsg-6+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
I would like to propose a stable update for opendmarc.
[ Reason ]
Since releasing the opendmarc version in Debian bullseye, two important
issues affecting it have been reported upstream.
[ Impact ]
1) opendmarc-import is broken in Debian bullseye (regression).
https://github.com/trusteddomainproject/OpenDMARC/issues/189
2) opendmarc crashes when receiving certain ARC-Seal headers.
https://github.com/trusteddomainproject/OpenDMARC/issues/183
[ Tests ]
For issue 1) I have tested the fix with MariaDB on Debian bullseye.
For issue 2) I am using the identical patch in unstable myself.
[ Risks ]
None that I know of, the fixes are small and seem sensible enough.
[ 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 stable
[x] the issue is verified as fixed in unstable
[ Changes ]
See changelog and debdiff.
Please let me upload this update via Debian mentors.
Thank you.
--
David
diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/changelog opendmarc-1.4.0~beta1+dfsg/debian/changelog
--- opendmarc-1.4.0~beta1+dfsg/debian/changelog 2021-06-18 09:37:57.0 +0200
+++ opendmarc-1.4.0~beta1+dfsg/debian/changelog 2021-11-03 16:56:39.0 +0100
@@ -1,3 +1,12 @@
+opendmarc (1.4.0~beta1+dfsg-6+deb11u1) stable; urgency=medium
+
+ * Amend patch "ticket193.patch" (Closes: #995694):
+- Remove unexplained diff that breaks opendmarc-import
+ * Add patch "arcseal-segfaults.patch" (Closes: #995703):
+- Fix segfaults, increase token max lengths in ARC-Seal headers
+
+ -- David Bürgin Wed, 03 Nov 2021 16:56:39 +0100
+
opendmarc (1.4.0~beta1+dfsg-6) unstable; urgency=high
* Add patch for CVE-2021-34555 from upstream issue tracker:
diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/patches/arcseal-segfaults.patch opendmarc-1.4.0~beta1+dfsg/debian/patches/arcseal-segfaults.patch
--- opendmarc-1.4.0~beta1+dfsg/debian/patches/arcseal-segfaults.patch 1970-01-01 01:00:00.0 +0100
+++ opendmarc-1.4.0~beta1+dfsg/debian/patches/arcseal-segfaults.patch 2021-11-03 14:25:50.0 +0100
@@ -0,0 +1,39 @@
+Description: Fix segfaults, increase token max lengths in ARC-Seal headers
+Origin: other, https://github.com/trusteddomainproject/OpenDMARC/files/6717466/opendmarc-arcseal.patch.txt
+Bug: https://github.com/trusteddomainproject/OpenDMARC/issues/183
+
+--- a/opendmarc/opendmarc-arcseal.c
b/opendmarc/opendmarc-arcseal.c
+@@ -24,7 +24,7 @@
+ #include "opendmarc.h"
+
+ #define OPENDMARC_ARCSEAL_MAX_FIELD_NAME_LEN 255
+-#define OPENDMARC_ARCSEAL_MAX_TOKEN_LEN 512
++#define OPENDMARC_ARCSEAL_MAX_TOKEN_LEN 768
+
+ /* tables */
+ struct opendmarc_arcseal_lookup
+@@ -223,7 +223,12 @@
+ if (*token_ptr == '\0')
+ return 0;
+ tag_label = strsep(_ptr, "=");
++ if (token_ptr == NULL)
++ return 0;
++
+ tag_value = opendmarc_arcseal_strip_whitespace(token_ptr);
++ if (tag_value == NULL)
++ return 0;
+
+ tag_code = opendmarc_arcseal_convert(as_tags, tag_label);
+
+--- a/opendmarc/opendmarc-arcseal.h
b/opendmarc/opendmarc-arcseal.h
+@@ -32,7 +32,7 @@
+ /* max header tag value length (short) */
+ #define OPENDMARC_ARCSEAL_MAX_SHORT_VALUE_LEN 256
+ /* max header tag value length (long) */
+-#define OPENDMARC_ARCSEAL_MAX_LONG_VALUE_LEN 512
++#define OPENDMARC_ARCSEAL_MAX_LONG_VALUE_LEN 768
+
+ /* names and field labels */
+ #define OPENDMARC_ARCSEAL_HDRNAME "ARC-Seal"
diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/patches/series opendmarc-1.4.0~beta1+dfsg/debian/patches/series
--- opendmarc-1.4.0~beta1+dfsg/debian/patches/series 2021-06-15 16:23:10.0 +0200
+++ opendmarc-1.4.0~beta1+dfsg/debian/patches/series 2021-11-03 14:23:34.0 +0100
@@ -13,3 +13,4 @@
cve-2020-12272.patch
cve-2019-20790.patch
cve-2021-34555.patch
+arcseal-segfaults.patch
diff -Nru opendmarc-1.4.0~beta1+dfsg/debian/patches/ticket193.patch opendmarc-1.4.0~beta1+dfsg/debian/patches/ticket193.patch
--- opendmarc-1.4.0~beta1+dfsg/debian/patches/ticket193.patch 2021-06-15 16:21:17.0 +0200
+++ opendmarc-1.4.0~beta1+dfsg/debian/patches/ticket193.patch 2021-11-03 14:18:41.0 +0100
@@ -107,92 +107,3 @@
$rows = $dbi_s->execute($maxage);
if (!$rows)
{
-diff --git a/reports/opendmarc-import.in b/reports/opendmarc-import.in
-index 3a2f404..259f546 100755
a/reports/opendmarc-import.in
-+++ b/reports/opendmarc-import.in
-@@ -233,14 +233,12 @@ sub update_db
- $envfrom_id = get_table_id($envdomain, "domains");
- $pdomain_id = get_table_id($pdomain, "domains");
- $ipaddr_id = get_table_id($ipaddr, "ipaddr", "addr");
-- $request_id = get_table_id($from_id, "requests", "domain");
-
- if (!defined($rep_id) ||
- !defined($from_id) ||
- !defined($envfrom_id) ||
- !defined($pdomain_id) ||
-- !defined($ipaddr_id) ||
-- !defined($request_id))
-+
Processed: Re: bullseye-pu: package kodi/19.3+dfsg1-1~deb11u1
Processing control commands: > retitle -1 bullseye-pu: package kodi/19.3+dfsg1-1~deb11u1 Bug #995823 [release.debian.org] bullseye-pu: package kodi/19.2+dfsg1-2~deb11u1 Changed Bug title to 'bullseye-pu: package kodi/19.3+dfsg1-1~deb11u1' from 'bullseye-pu: package kodi/19.2+dfsg1-2~deb11u1'. -- 995823: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995823 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
