NEW changes in stable-new
Processing changes file: libreoffice_6.1.5-3+deb10u5_mipsel.changes ACCEPT
NEW changes in stable-new
Processing changes file: libreoffice_6.1.5-3+deb10u5_mips64el.changes ACCEPT
NEW changes in stable-new
Processing changes file: base-files_10.3+deb10u2_mips64el.changes ACCEPT
NEW changes in stable-new
Processing changes file: base-files_10.3+deb10u2_mipsel.changes ACCEPT
NEW changes in stable-new
Processing changes file: base-files_10.3+deb10u2_mips.changes ACCEPT
NEW changes in stable-new
Processing changes file: base-files_10.3+deb10u2_amd64.changes ACCEPT Processing changes file: base-files_10.3+deb10u2_arm64.changes ACCEPT Processing changes file: base-files_10.3+deb10u2_armel.changes ACCEPT Processing changes file: base-files_10.3+deb10u2_armhf.changes ACCEPT Processing changes file: base-files_10.3+deb10u2_i386.changes ACCEPT Processing changes file: base-files_10.3+deb10u2_ppc64el.changes ACCEPT Processing changes file: base-files_10.3+deb10u2_s390x.changes ACCEPT
Re: Should qpdf depend on gnutls?
Okay, thanks for all the response, public and private. There seems to be broad consensus to use the gnutls crypto and disable the native one, so that's what I'll do. Appreciate the advice! --Jay On Sun, Nov 10, 2019 at 2:05 PM Moritz Mühlenhoff wrote: > On Sat, Nov 09, 2019 at 07:10:44PM -0500, Jay Berkenbilt wrote: > > I am the upstream author and the debian maintainer of qpdf. > > > > At the request of RedHat, I have made an enhancement to qpdf that > > allows an external library to be used for crypto functions rather than > > using qpdf's native crypto implementations. The qpdf library includes > > code to compute hashes with md5 and sha2 (256, 384, and 512) as well > > as encryption functions for rc4 and aes256 with and without CBC. > > Disabling insecure crypto is not a practical option because of the way > > these things are used in the PDF spec, but it is possible create PDFs > > that don't use insecure crypto by just using 256-bit encryption. > > > > I can build qpdf 9.1 for Debian in one of three ways: 1) use only the > > native crypto as in all previous releases, thus avoiding a dependency > > on gnutls; 2) build only the gnutls crypto provider thus causing a > > dependency on gnutls but eliminating the native crypto entirely; or 3) > > building both crypto providers, in which case gnutls will be used by > > default, but developers and end users will have the ability to select > > the native crypto provider at runtime if desired. > > > > Do you have an opinion about which way I should go? I believe RHEL and > > Fedora are going to use the second option of building with only gnutls > > and dropping native crypto, but I have also enjoyed the fact that qpdf > > has so few build dependencies. It is possible that a future version of > > qpdf may support digital signature, in which case I will definitely > > have to add either openssl or gnutls as a dependency. > > I'd recommend to go with 2); there's a lot of value in using a common / > scrutinised crypto library over a custom implementation and for all > practical purposes gnutls would not be an additional dep as systemd > already pulls it in on virtually every Linux system these days. > > Cheers, > Moritz > >
NEW changes in stable-new
Processing changes file: glib2.0_2.58.3-2+deb10u2_mips.changes ACCEPT
NEW changes in stable-new
Processing changes file: libreoffice_6.1.5-3+deb10u5_mips.changes ACCEPT
Bug#944190: release.debian.org: Allow britney to consider installability of dependencies of essential packages
Control: tags -1 confirmed patch
Niels Thykier:
> [...]
>
> I looking forward to your test case as it will make this issue a lot
> easier to debug.
>
Hi,
Thanks for the test case. :)
I have pushed it to britney2-tests and flagged it as a known failure.
> What is supposed to happen is that:
>
> * Britney "should" rewrite the relation on "libsystemd0" as
>"libsystemd0 | libelogin0" when building the BinaryPackageUniverse
>(actually as libsystemd0//arch | libsystemd0//arch
> tuples).
>
>- This is also based on the assumption that the Conflicts/Provides
> setup in libelogin0 is done correctly. I /think/ it is - I am just
> being explicit about the assumption.
>
Indeed, I have looked through the state of the test and the relations
are as I expected here.
> [...]> * It /could/ be related to the caching of the pseudo-essential set.
>AFAIUI, the cache should "just work(tm)" if the previous point
>does not have a flaw. At least the current cache code assumes that
>libsystemd0 and libelogin0 will not be resolved by
>_get_min_pseudo_ess_set. Though, it could also be a point where the
>bug hides.
>
> [...]
I think this ends up being the winner. The _get_min_pseudo_ess_set
method builds a set that includes libtest (libsystemd0) from the beginning.
This is technically correct and valid at the start because libprovider
(libelogind0) is *not* in testing at that point (so any selection for
the essential set will always include libtest at the start).
Unfortunately, the cache is never invalidated by adding the alternative
and thus libprovider is immediately rejected as broken.
I have attached the following patch that passes the provided test and
(AFAICT) does what we want. Please feel free to review it; I will come
back to this in a few days.
Note: I do not expect to have a lot of spare time for Debian the coming
week; please ping me on this bug if I have not replied by next Sunday.
Thanks,
~Niels
From 0d5ea5eb8c0276e48f1394f233e1441ab87dcfbc Mon Sep 17 00:00:00 2001
From: Niels Thykier
Date: Sun, 10 Nov 2019 23:08:47 +
Subject: [PATCH] Improve cache invalidation of (pseudo-)essential set
If a new pseudo-essential package was added to testing *and* it is
mutually-exclusive with an existing member, britney would incorrectly
flag it as uninstallable (unless another change triggered a cache
invalidation of the pseudo-essential set).
With this commit, the cache invalidation is now done based on whether
we add something that *might* be in the (effective) pseudo-essential
set. It is an overapproximation as there are cases where the
invalidation is unnecessary, but at the moment it is not a performance
concern.
Closes: https://bugs.debian.org/944190
Signed-off-by: Niels Thykier
---
britney2/installability/tester.py | 12
britney2/utils.py | 21 -
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/britney2/installability/tester.py b/britney2/installability/tester.py
index 5ac6ef2..4687cc0 100644
--- a/britney2/installability/tester.py
+++ b/britney2/installability/tester.py
@@ -17,7 +17,7 @@ from functools import partial
import logging
from itertools import chain, filterfalse
-from britney2.utils import iter_except
+from britney2.utils import iter_except, add_transitive_dependencies_flatten
class InstallabilityTester(object):
@@ -52,12 +52,16 @@ class InstallabilityTester(object):
# are essential and packages that will always follow.
#
# It may not be a complete essential set, since alternatives
-# are not always resolved. Noticably cases like "awk" may be
+# are not always resolved. Noticeably cases like "awk" may be
# left out (since it could be either gawk, mawk or
# original-awk) unless something in this sets depends strictly
# on one of them
self._cache_ess = {}
+essential_w_transitive_deps = set(universe.essential_packages)
+add_transitive_dependencies_flatten(universe, essential_w_transitive_deps)
+self._cache_essential_transitive_dependencies = essential_w_transitive_deps
+
def compute_installability(self):
"""Computes the installability of all the packages in the suite
@@ -137,8 +141,8 @@ class InstallabilityTester(object):
# Re-add broken packages as some of them may now be installable
self._suite_contents |= self._cache_broken
self._cache_broken = set()
-if pkg_id in self._universe.essential_packages and pkg_id.architecture in self._cache_ess:
-# Adds new essential => "pseudo-essential" set needs to be
+if pkg_id in self._cache_essential_transitive_dependencies and pkg_id.architecture in self._cache_ess:
+# Adds new possibly pseudo-essential => "pseudo-essential" set needs to be
# recomputed
del
Processed: Re: Bug#944190: release.debian.org: Allow britney to consider installability of dependencies of essential packages
Processing control commands: > tags -1 confirmed patch Bug #944190 [release.debian.org] release.debian.org: Allow britney to consider installability of dependencies of essential packages Added tag(s) confirmed. -- 944190: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944190 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
NEW changes in stable-new
Processing changes file: node-fstream_1.0.10-1+deb10u1_all.changes ACCEPT Processing changes file: python-oslo.messaging_8.1.4-1+deb10u1_all.changes ACCEPT
NEW changes in stable-new
Processing changes file: base-files_10.3+deb10u2_source.changes ACCEPT
Processed: liquidsoap unblock
Processing commands for cont...@bugs.debian.org: > unblock 939580 by 941907 944404 Bug #939580 [src:liquidsoap] liquidsoap: FTBFS with new ffmpeg ocaml library 939580 was blocked by: 941907 944404 939580 was not blocking any bugs. Removed blocking bug(s) of 939580: 941907 and 944404 > thanks Stopping processing here. Please contact me if you need assistance. -- 939580: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939580 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
NEW changes in stable-new
Processing changes file: chromium_78.0.3904.97-1~deb10u1_source.changes ACCEPT Processing changes file: chromium_78.0.3904.97-1~deb10u1_all.changes ACCEPT Processing changes file: chromium_78.0.3904.97-1~deb10u1_amd64.changes ACCEPT Processing changes file: chromium_78.0.3904.97-1~deb10u1_arm64.changes ACCEPT Processing changes file: chromium_78.0.3904.97-1~deb10u1_armhf.changes ACCEPT Processing changes file: chromium_78.0.3904.97-1~deb10u1_i386.changes ACCEPT Processing changes file: node-fstream_1.0.10-1+deb10u1_sourceonly.changes ACCEPT Processing changes file: python-oslo.messaging_8.1.4-1+deb10u1_source.changes ACCEPT
NEW changes in stable-new
Processing changes file: libreoffice_6.1.5-3+deb10u5_armel.changes ACCEPT
Bug#943667: python-oslo.messaging 8.1.4-1+deb10u1 flagged for acceptance
package release.debian.org tags 943667 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: python-oslo.messaging Version: 8.1.4-1+deb10u1 Explanation: new upstream stable release; fix switch connection destination when a rabbitmq cluster node disappears
Bug#939166: node-fstream 1.0.10-1+deb10u1 flagged for acceptance
package release.debian.org tags 939166 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: node-fstream Version: 1.0.10-1+deb10u1 Explanation: fix arbitrary file overwrite issue [CVE-2019-13173]
Processed: python-oslo.messaging 8.1.4-1+deb10u1 flagged for acceptance
Processing commands for cont...@bugs.debian.org: > package release.debian.org Limiting to bugs with field 'package' containing at least one of 'release.debian.org' Limit currently set to 'package':'release.debian.org' > tags 943667 = buster pending Bug #943667 [release.debian.org] buster-pu: package python-oslo.messaging/8.1.3-1 -> 8.1.4-1+deb10u1 Added tag(s) pending; removed tag(s) confirmed. > thanks Stopping processing here. Please contact me if you need assistance. -- 943667: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943667 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: node-fstream 1.0.10-1+deb10u1 flagged for acceptance
Processing commands for cont...@bugs.debian.org: > package release.debian.org Limiting to bugs with field 'package' containing at least one of 'release.debian.org' Limit currently set to 'package':'release.debian.org' > tags 939166 = buster pending Bug #939166 [release.debian.org] buster-pu: package node-fstream/1.0.10-1+deb10u1 Added tag(s) pending; removed tag(s) confirmed. > thanks Stopping processing here. Please contact me if you need assistance. -- 939166: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939166 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Should qpdf depend on gnutls?
On Sat, Nov 09, 2019 at 07:10:44PM -0500, Jay Berkenbilt wrote: > I am the upstream author and the debian maintainer of qpdf. > > At the request of RedHat, I have made an enhancement to qpdf that > allows an external library to be used for crypto functions rather than > using qpdf's native crypto implementations. The qpdf library includes > code to compute hashes with md5 and sha2 (256, 384, and 512) as well > as encryption functions for rc4 and aes256 with and without CBC. > Disabling insecure crypto is not a practical option because of the way > these things are used in the PDF spec, but it is possible create PDFs > that don't use insecure crypto by just using 256-bit encryption. > > I can build qpdf 9.1 for Debian in one of three ways: 1) use only the > native crypto as in all previous releases, thus avoiding a dependency > on gnutls; 2) build only the gnutls crypto provider thus causing a > dependency on gnutls but eliminating the native crypto entirely; or 3) > building both crypto providers, in which case gnutls will be used by > default, but developers and end users will have the ability to select > the native crypto provider at runtime if desired. > > Do you have an opinion about which way I should go? I believe RHEL and > Fedora are going to use the second option of building with only gnutls > and dropping native crypto, but I have also enjoyed the fact that qpdf > has so few build dependencies. It is possible that a future version of > qpdf may support digital signature, in which case I will definitely > have to add either openssl or gnutls as a dependency. I'd recommend to go with 2); there's a lot of value in using a common / scrutinised crypto library over a custom implementation and for all practical purposes gnutls would not be an additional dep as systemd already pulls it in on virtually every Linux system these days. Cheers, Moritz
Bug#942106: python3.8 / pandas py2removal
I have uploaded pandas and statsmodels. On 10/11/2019 14:18, Matthias Klose wrote: https://people.debian.org/~doko/tmp/ The patsy one has a bug: as debian/tests/nosetests3 was a symlink to nosetests2, it should have deleted this link and renamed nosetests2 to nosetests3, not deleted nosetests2.
NEW changes in stable-new
Processing changes file: systemd_241-7~deb10u2_mipsel.changes ACCEPT
NEW changes in stable-new
Processing changes file: libreoffice_6.1.5-3+deb10u5_armhf.changes ACCEPT
Bug#944190: release.debian.org: Allow britney to consider installability of dependencies of essential packages
Niels, On Sun, Nov 10, 2019 at 10:49:00AM +, Niels Thykier wrote: > I looking forward to your test case as it will make this issue a lot > easier to debug. A test case is attached. It fails without the patch I submitted (inadequate though it is, as you pointed out), but succeeds with it. I hope it is helpful and I have not missed something. > What is supposed to happen is that: > > * Britney "should" rewrite the relation on "libsystemd0" as >"libsystemd0 | libelogin0" when building the BinaryPackageUniverse >(actually as libsystemd0//arch | libsystemd0//arch > tuples). > >- This is also based on the assumption that the Conflicts/Provides > setup in libelogin0 is done correctly. I /think/ it is - I am just > being explicit about the assumption. I think so too. Certainly the binaries from src:elogind are manually installable into bullseye and satisfy the necessary dependencies of essential packages. Thanks very much for looking at this. Let me know if there is anything else I can do to help. Mark >From e7e78b251beaba5182377a15f6af226ccf950710 Mon Sep 17 00:00:00 2001 From: Mark Hindley Date: Sun, 10 Nov 2019 17:16:34 + Subject: [PATCH] Test case for #944190. The test requires that a dependency of an essential package can be satisfied by another package which Provides it. --- t/bug-944190/description | 2 ++ t/bug-944190/expected| 5 + t/bug-944190/expected-excuses.yaml | 29 t/bug-944190/var/data/testing/Packages_i386 | 15 ++ t/bug-944190/var/data/testing/Sources| 5 + t/bug-944190/var/data/unstable/Packages_i386 | 25 t/bug-944190/var/data/unstable/Sources | 11 +++ 7 files changed, 92 insertions(+) create mode 100644 t/bug-944190/description create mode 100644 t/bug-944190/expected create mode 100644 t/bug-944190/expected-excuses.yaml create mode 100644 t/bug-944190/var/data/testing/Packages_i386 create mode 100644 t/bug-944190/var/data/testing/Sources create mode 100644 t/bug-944190/var/data/unstable/Packages_i386 create mode 100644 t/bug-944190/var/data/unstable/Sources diff --git a/t/bug-944190/description b/t/bug-944190/description new file mode 100644 index 000..54418fd --- /dev/null +++ b/t/bug-944190/description @@ -0,0 +1,2 @@ +Test case for ensuring a package with Conflicts/Provides/Replaces can satisfy a +dependency of essential set. diff --git a/t/bug-944190/expected b/t/bug-944190/expected new file mode 100644 index 000..c249f4b --- /dev/null +++ b/t/bug-944190/expected @@ -0,0 +1,5 @@ +test 1.0-1 i386 +libtest1 1.0-1 i386 +test-src 1.0-1 source +libprovider1 1.0-1 i386 +provider 1.0-1 source diff --git a/t/bug-944190/expected-excuses.yaml b/t/bug-944190/expected-excuses.yaml new file mode 100644 index 000..9ea638c --- /dev/null +++ b/t/bug-944190/expected-excuses.yaml @@ -0,0 +1,29 @@ +generated-date: 2018-12-28 22:32:22.868333 +sources: +- excuses: + - Cannot be tested by piuparts (not a blocker) - (no link yet) + is-candidate: true + item-name: provider + maintainer: The R-Team + migration-policy-verdict: PASS + new-version: 1.0-1 + old-version: '-' + policy_info: +age: + age-requirement: 10 + current-age: 17892 + verdict: PASS +autopkgtest: + verdict: PASS +build-depends: + verdict: PASS +piuparts: + test-results: cannot-be-tested + verdict: PASS +rc-bugs: + shared-bugs: [] + unique-source-bugs: [] + unique-target-bugs: [] + verdict: PASS + reason: [] + source: provider diff --git a/t/bug-944190/var/data/testing/Packages_i386 b/t/bug-944190/var/data/testing/Packages_i386 new file mode 100644 index 000..d6cec70 --- /dev/null +++ b/t/bug-944190/var/data/testing/Packages_i386 @@ -0,0 +1,15 @@ +Package: test +Section: devel +Architecture: i386 +Source: test-src +Maintainer: The R-Team +Version: 1.0-1 +Depends: libtest1 +Essential: yes + +Package: libtest1 +Section: devel +Architecture: i386 +Source: test-src +Maintainer: The R-Team +Version: 1.0-1 diff --git a/t/bug-944190/var/data/testing/Sources b/t/bug-944190/var/data/testing/Sources new file mode 100644 index 000..cfd24bb --- /dev/null +++ b/t/bug-944190/var/data/testing/Sources @@ -0,0 +1,5 @@ +Package: test-src +Binary: test, libtest1 +Version: 1.0-1 +Section: devel +Maintainer: The R-Team diff --git a/t/bug-944190/var/data/unstable/Packages_i386 b/t/bug-944190/var/data/unstable/Packages_i386 new file mode 100644 index 000..ff60b43 --- /dev/null +++ b/t/bug-944190/var/data/unstable/Packages_i386 @@ -0,0 +1,25 @@ +Package: test +Source: test-src +Version: 1.0-1 +Maintainer: The R-Team +Depends: libtest1 +Architecture: i386 +Section: devel +Essential: yes + +Package: libtest1 +Source: test-src +Version: 1.0-1 +Maintainer: The R-Team +Architecture: i386 +Section: devel + +Package: libprovider1 +Source: provider +Version:
NEW changes in stable-new
Processing changes file: python2.7_2.7.16-2+deb10u1_mipsel.changes ACCEPT
Bug#944480: transition: libdvdread
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-libdvdread.html libdvdread bumped its SONAME from 4 to 7. All reverse dependencies build fine against the new version. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Processed: transition: libdvdread
Processing control commands: > forwarded -1 https://release.debian.org/transitions/html/auto-libdvdread.html Bug #944480 [release.debian.org] transition: libdvdread Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/auto-libdvdread.html'. -- 944480: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944480 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
NEW changes in stable-new
Processing changes file: uim_1.8.8-4+deb10u2_mipsel.changes ACCEPT
Bug#943667: buster-pu: package python-oslo.messaging/8.1.3-1 -> 8.1.4-1+deb10u1
On 11/9/19 2:38 PM, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sun, 2019-10-27 at 18:10 +0100, Thomas Goirand wrote: >> I'd like to upgrade oslo.messaging to version 8.1.4-1+deb10u1. >> Indeed, in versin 8.1.3, when a Rabbitmq server configured through >> transport_url dies (or is turned off because of maintenance), the >> OpenStack clients, which means, all services running on compute >> hosts, would attempt to reconnect to the same RabbitMQ host. As a >> consequence, upgrading would be *very* problematic, as the node >> wouldn't reconnect to another node when we're upgrading one rabbit >> node (and as a consequence, turning off the service there). >> > > Please go ahead. > > Regards, > > Adam Thanks. Uploaded. Can we get an update of your approval for Nova and Neutron also? It would help a lot with upgrades to later OpenStack releases if we can get the patched versions in Buster. I'm namely talking about #944099 and #942102. I'm waiting on these to start the actual upgrade to Buster for my production cluster myself. Cheers, Thomas Goirand (zigo)
Bug#942102: Adding this other patch
Hi,
I also would like to add the attached patch to the package. Indeed, when
upgrading Neutron in non-interactive mode, annoyingly this may change
the content of neutron.conf. With the added patch, this cannot happen
anymore. Note that this has been included in the Sid package for quite
some time, and that I've been using such a fix in production already, so
it's been tested extensively.
Cheers,
Thomas Goirand (zigo)
>From 2dda54a0519e9d17c0c2262a6701529c479031ce Mon Sep 17 00:00:00 2001
From: Thomas Goirand
Date: Mon, 14 Oct 2019 02:15:35 +0200
Subject: [PATCH 1340/1345] * Add the neccessary debconf stuff to stop modifying config files on upgrades.
diff --git a/debian/neutron-common.config.in b/debian/neutron-common.config.in
index f8f0d3b50b..99e010bff7 100644
--- a/debian/neutron-common.config.in
+++ b/debian/neutron-common.config.in
@@ -8,11 +8,19 @@ N_CONF=/etc/neutron/neutron.conf
ML2_CONF=/etc/neutron/plugins/ml2/ml2_conf.ini
read_nova_admin_credentials () {
- pkgos_read_config -p high ${N_CONF} nova auth_url neutron/nova_auth_url
- pkgos_read_config -p high ${N_CONF} nova region_name neutron/nova_region
- pkgos_read_config -p medium ${N_CONF} nova project_name neutron/nova_service_project_name
- pkgos_read_config -p medium ${N_CONF} nova username neutron/nova_service_username
- pkgos_read_config -p high ${N_CONF} nova password neutron/nova_service_password
+ db_get neutron/configure_ksat
+ if [ "${RET}" = "true" ] ; then
+ db_input high neutron/configure_nova || true
+ db_go
+ db_get neutron/configure_nova
+ if [ "${RET}" = "true" ] ; then
+ pkgos_read_config -p high ${N_CONF} nova auth_url neutron/nova_auth_url
+ pkgos_read_config -p high ${N_CONF} nova region_name neutron/nova_region
+ pkgos_read_config -p medium ${N_CONF} nova project_name neutron/nova_service_project_name
+ pkgos_read_config -p medium ${N_CONF} nova username neutron/nova_service_username
+ pkgos_read_config -p high ${N_CONF} nova password neutron/nova_service_password
+ fi
+ fi
}
#PKGOS-INCLUDE#
diff --git a/debian/neutron-common.postinst.in b/debian/neutron-common.postinst.in
index a3018f..f914a291bd 100755
--- a/debian/neutron-common.postinst.in
+++ b/debian/neutron-common.postinst.in
@@ -83,7 +83,10 @@ if [ "$1" = "configure" ] || [ "$1" = "reconfigure" ] ; then
su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron
fi
- write_nova_service_credentials
+ db_get neutron/configure_nova
+ if [ "${RET}" = "true" ] ; then
+ write_nova_service_credentials
+ fi
db_stop
# The /var/lib/neutron/dhcp needs to be readable from the nobody user.
diff --git a/debian/neutron-common.templates.in b/debian/neutron-common.templates.in
index df649181a6..0f19b3d6c8 100644
--- a/debian/neutron-common.templates.in
+++ b/debian/neutron-common.templates.in
@@ -7,6 +7,14 @@
# Even minor modifications require translation updates and such
# changes should be coordinated with translators and reviewers.
+Template: neutron/configure_nova
+Type: boolean
+Default: false
+_Description: Manage nova config through debconf?
+ Neutron service must contact Nova, and this is configured through
+ the [nova] section of the configuration. Specify if you wish
+ to handle this configuration through debconf.
+
Template: neutron/nova_auth_url
Type: string
Default: http://127.0.0.1:5000
diff --git a/debian/neutron-metadata-agent.config.in b/debian/neutron-metadata-agent.config.in
index 260ef3e28d..ccabc3843e 100644
--- a/debian/neutron-metadata-agent.config.in
+++ b/debian/neutron-metadata-agent.config.in
@@ -10,7 +10,13 @@ META_AGNT_CONF=/etc/neutron/metadata_agent.ini
pkgos_var_user_group neutron
chmod 755 /var/lib/neutron
-pkgos_read_config -p high ${META_AGNT_CONF} DEFAULT metadata_proxy_shared_secret neutron-metadata/metadata_secret
-pkgos_read_config -p high ${META_AGNT_CONF} DEFAULT nova_metadata_host neutron-metadata/nova_metadata_host
+
+db_input high neutron-metadata/configure || true
+db_go
+db_get neutron-metadata/configure
+if [ "${RET}" = "true" ] ; then
+ pkgos_read_config -p high ${META_AGNT_CONF} DEFAULT metadata_proxy_shared_secret neutron-metadata/metadata_secret
+ pkgos_read_config -p high ${META_AGNT_CONF} DEFAULT nova_metadata_host neutron-metadata/nova_metadata_host
+fi
exit 0
diff --git a/debian/neutron-metadata-agent.postinst.in b/debian/neutron-metadata-agent.postinst.in
index eb1f4c43d8..8615adbb26 100755
--- a/debian/neutron-metadata-agent.postinst.in
+++ b/debian/neutron-metadata-agent.postinst.in
@@ -21,7 +21,10 @@ if [ "${1}" = "configure" ] ; then
if [ ! -e ${CONF_FILE} ] ; then
install -D -m 0640 -o neutron -g neutron /usr/share/neutron-metadata-agent/metadata_agent.ini ${CONF_FILE}
fi
- manage_metadata_proxy_shared_secret
+ db_get neutron-metadata/configure
+ if [ "${RET}" = "true" ] ; then
+ manage_metadata_proxy_shared_secret
+ fi
db_stop
fi
diff --git
NEW changes in stable-new
Processing changes file: mariadb-10.3_10.3.18-0+deb10u1_mipsel.changes ACCEPT Processing changes file: network-manager_1.14.6-2+deb10u1_mipsel.changes ACCEPT Processing changes file: python-cryptography_2.6.1-3+deb10u2_mipsel.changes ACCEPT
Bug#941901: buster-pu: package octavia/3.0.0-3
On 11/9/19 2:31 PM, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Mon, 2019-10-07 at 14:35 +0200, Thomas Goirand wrote: >> Since Buster was frozen, I worked quite a long time on Octavia, and >> was >> able to make the octavia-agent work properly, as well as building an >> Octavia base image using Debian only stuff [1]. It works super well >> using the next version of OpenStack, ie: Stein, while Buster has >> Rocky. >> >> Though I'd like to be able to provide a working Amphorae image using >> only stuff from Buster, if possible. This is what this update is >> about. >> > > Please go ahead. > > Regards, > > Adam Hi Adam, On top of what you already approved, I'd like to also add what's in this commit: https://salsa.debian.org/openstack-team/services/octavia/commit/25eb5debecfc53e3394ca9d5dcf2bc01c563915f The reason is, instead of adding so many things when building the Octavia virtual machine image, it makes a lot of sense to instead push all of this in the Debian package. At the time of writing the package for Buster, I had no experience with this, though that's how I am building the image using Sid these days. When we have these in the Octavia package, then building the official Buster image for Octavia will be super simple, and will integrate easily in the cloud team's scripts. Hopefully, we can publish such an Octavia image right after the next Buster point release. I've uploaded the above. If you think that's not reasonable changes, please reject the package and let me know, then we can decide what you think can go in the Buster package and what shouldn't (though I really think all of the above is better suited in the package than in the image build script). Cheers, Thomas Goirand (zigo)
NEW changes in stable-new
Processing changes file: libapache-mod-auth-kerb_5.4-2.4~deb10u1_mipsel.changes ACCEPT Processing changes file: libofx_0.9.14-1+deb10u1_mipsel.changes ACCEPT Processing changes file: ncurses_6.1+20181013-2+deb10u2_mipsel.changes ACCEPT Processing changes file: python2.7_2.7.16-2+deb10u1_armel.changes ACCEPT
Bug#942106: python3.8 / pandas py2removal
On 10.11.19 14:46, Rebecca N. Palmer wrote: mdp isn't in testing either, but if you're using a policy of "no py2removals that break packages in testing", tnseq-transit (Depends: statsmodels) and possibly stimfit (Recommends: pandas) need to be done as well. Those are both thought to need new upstream versions. tnseq-transit is a leaf package, raising the severity now, could be removed and re-enter later. IMO, we should care about the recommends later ... (patsy isn't a leaf package for py2removal, it's in a cycle with pandas and statsmodels, i.e. for a non-breaking removal they all have to go together.) ok I'm undoing the NMU from the delayed queue, you'll find it at https://people.debian.org/~doko/tmp/
NEW changes in stable-new
Processing changes file: glib2.0_2.58.3-2+deb10u2_mipsel.changes ACCEPT Processing changes file: libxslt_1.1.32-2.2~deb10u1_mipsel.changes ACCEPT
Bug#942106: python3.8 / pandas py2removal
mdp isn't in testing either, but if you're using a policy of "no py2removals that break packages in testing", tnseq-transit (Depends: statsmodels) and possibly stimfit (Recommends: pandas) need to be done as well. Those are both thought to need new upstream versions. (patsy isn't a leaf package for py2removal, it's in a cycle with pandas and statsmodels, i.e. for a non-breaking removal they all have to go together.)
NEW changes in stable-new
Processing changes file: libreoffice_6.1.5-3+deb10u5_s390x.changes ACCEPT Processing changes file: python2.7_2.7.16-2+deb10u1_arm64.changes ACCEPT
Bug#942106: python3.8 / pandas py2removal
On 10.11.19 14:22, Matthias Klose wrote: patsy is a leaf package, no problem. scikit-learn, needs mdp, pymvpa2, I think that's manageable, so I'm volunteering to do the NMUs, preferably with a 0 or 1 day delay. PyMVPA has other RC issues, is removed from testing, so ignore it for now. and I'm raising the severity of the py2removal bug.
Bug#944460: marked as done (unblock: glibc/2.29-3)
Your message dated Sun, 10 Nov 2019 14:29:04 +0100 with message-id <8b9be57a-23e6-7ddb-29f8-0a9a2bcd0...@debian.org> and subject line Re: Bug#944460: unblock: glibc/2.29-3 has caused the Debian Bug report #944460, regarding unblock: glibc/2.29-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.) -- 944460: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944460 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 glibc 2.29-3 is prevented to migrate to testing due to autopktest regressions. However those regressions are unrelated to glibc and are due to the postgresql transition. Therefore would it be possible to ignore those tests and force glibc into testing? Thanks, Aurelien -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) --- End Message --- --- Begin Message --- Hi Aurelien, On 10-11-2019 13:03, Aurelien Jarno wrote: > Therefore would it be possible to ignore those tests and force glibc > into testing? Ignored those results. Paul signature.asc Description: OpenPGP digital signature --- End Message ---
Bug#942106: python3.8 / pandas py2removal
[CCing debian-science] On 10.11.19 13:18, Rebecca N. Palmer wrote: Matthias Klose wrote: yes, please do [raise pandas 0.25 blocking bugs to "important"] Done, but only 2 of them have been fixed since. This leaves 13: has patch or Ubuntu fix: matplotlib2 patsy python-apptools scikit-learn may need more extensive work: cnvkit python-feather-format python-skbio stimfit tnseq-transit already not in testing: mdp psychopy pymvpa q2-types If you can get that done with [pandas] 0.25, fine, It took longer than I was expecting, but pandas 0.25 / statsmodels 0.10 now appear to be working, including with python3.8. (Though we won't actually know if #943732 is gone until mipsel tries to build it.) \o/ and I wouldn't worry too much about the other four breaking packages at this point. Was this intended as... ... a request to upload pandas 0.25 / statsmodels 0.10 to unstable (and apply the Ubuntu py2removal patches to patsy and scikit-learn?), overriding normal py2removal rules? patsy is a leaf package, no problem. scikit-learn, needs mdp, pymvpa2, I think that's manageable, so I'm volunteering to do the NMUs, preferably with a 0 or 1 day delay. So yes, please go ahead. ... a request to split pandas into a pandas2 0.23 and a pandas 0.25? (since 4 is only the number of non-py2removal breakages, and the wiki page https://wiki.debian.org/Python/Python3.8 says to do this if 2.7 and 3.8 need different upstream versions) Should be technically easy, but means going through NEW. ... a statement that once pandas 0.25 works, this is no longer my problem, i.e. that I don't have to fix 0.23? I don't think that's necessary at this point. matplotlib and pandas don't have Python2 packages in Ubuntu anymore, so I can't tell much what is needed here matplotlib has already been split into Python 2 and Python 3 source packages. (matplotlib2 is in Ubuntu, and unbuildable there due to #943924.) Python2 matplotlib are already removed in Ubuntu, I shouldn't have synced matplotlib2 from experimental. According to its Ubuntu build log: https://launchpad.net/ubuntu/+source/matplotlib/3.0.2-2ubuntu1/+build/17942804 matplotlib has one python3.8-specific test failure, test_axes.py::test_pathological_hexbin. This is currently being ignored (#942766) along with (many) errors that also happen on 3.7.
NEW changes in stable-new
Processing changes file: network-manager_1.14.6-2+deb10u1_mips.changes ACCEPT
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
On Sun, Nov 10, 2019 at 01:24:42PM +0100, Santiago Vila wrote: > Ok, I have just uploaded base-files as usual, but if possible I'd like > this to be sorted-out for 10.3 (in particular, I still would like to > hear from the ansible maintainers). I wondering if change should have wider exposure. I suspect not only ansible users will be affected. I'd say this warrants a mail to d-d-a or at least -devel. Thanks for maintaining base-files, Santiago! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Bug#944460: unblock: glibc/2.29-3
On 2019-11-10 13:47, Paul Gevers wrote: > Hi Aurelien, > > On 10-11-2019 13:03, Aurelien Jarno wrote: > > glibc 2.29-3 is prevented to migrate to testing due to autopktest > > regressions. However those regressions are unrelated to glibc and are > > due to the postgresql transition. > > I agree to ignore all postgresql regressions due to the transition, but > what about the regression in rust-lscolors? This one is also a bug of autopkgtest, it runs the rust-lscolors autopkgtest from version 0.5.0-2 with many packages unrelated to glibc fetch from unstable instead of testing, and especially librust-lscolors-dev version 0.6.0-1. To be able to have conclusive autopkgtests, the only packages that should be fetched from unstable should be the glibc related ones. This is basically the same issue as for postgresql regressions, where postgresql is fetched from unstable (thus in version 12) and not from testing. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#944460: unblock: glibc/2.29-3
Hi Aurelien, On 10-11-2019 13:03, Aurelien Jarno wrote: > glibc 2.29-3 is prevented to migrate to testing due to autopktest > regressions. However those regressions are unrelated to glibc and are > due to the postgresql transition. I agree to ignore all postgresql regressions due to the transition, but what about the regression in rust-lscolors? Paul signature.asc Description: OpenPGP digital signature
Bug#944351: Providing minor version somewhere in /etc/os-release in buster
On Sat, Nov 09, 2019 at 03:33:26PM +, Adam D. Barratt wrote: > On Sat, 2019-11-09 at 16:09 +0100, Santiago Vila wrote: > > (If we can't sort this out for 10.2 I'll have to upload base-files > > for 10.2 as usual. What's the real deadline for that? This weekend?) > > Yep. Ok, I have just uploaded base-files as usual, but if possible I'd like this to be sorted-out for 10.3 (in particular, I still would like to hear from the ansible maintainers). (I assume and hope that keeping this bug open until we have all the info should not be a problem). Thanks.
Bug#942106: python3.8 / pandas py2removal
Matthias Klose wrote: yes, please do [raise pandas 0.25 blocking bugs to "important"] Done, but only 2 of them have been fixed since. This leaves 13: has patch or Ubuntu fix: matplotlib2 patsy python-apptools scikit-learn may need more extensive work: cnvkit python-feather-format python-skbio stimfit tnseq-transit already not in testing: mdp psychopy pymvpa q2-types If you can get that done with [pandas] 0.25, fine, It took longer than I was expecting, but pandas 0.25 / statsmodels 0.10 now appear to be working, including with python3.8. (Though we won't actually know if #943732 is gone until mipsel tries to build it.) and I wouldn't worry too much about the other four breaking packages at this point. Was this intended as... ... a request to upload pandas 0.25 / statsmodels 0.10 to unstable (and apply the Ubuntu py2removal patches to patsy and scikit-learn?), overriding normal py2removal rules? ... a request to split pandas into a pandas2 0.23 and a pandas 0.25? (since 4 is only the number of non-py2removal breakages, and the wiki page https://wiki.debian.org/Python/Python3.8 says to do this if 2.7 and 3.8 need different upstream versions) Should be technically easy, but means going through NEW. ... a statement that once pandas 0.25 works, this is no longer my problem, i.e. that I don't have to fix 0.23? matplotlib and pandas don't have Python2 packages in Ubuntu anymore, so I can't tell much what is needed here matplotlib has already been split into Python 2 and Python 3 source packages. (matplotlib2 is in Ubuntu, and unbuildable there due to #943924.) According to its Ubuntu build log: https://launchpad.net/ubuntu/+source/matplotlib/3.0.2-2ubuntu1/+build/17942804 matplotlib has one python3.8-specific test failure, test_axes.py::test_pathological_hexbin. This is currently being ignored (#942766) along with (many) errors that also happen on 3.7.
NEW changes in stable-new
Processing changes file: libsixel_1.8.2-1+deb10u1_mipsel.changes ACCEPT Processing changes file: ndppd_0.2.5-4+deb10u1_mipsel.changes ACCEPT
Bug#941078: transition: postgresql-12
Hi all, For the record, Christoph and I had the following discussion on IRC today. Paul Myon: I am starting to wonder, are all those PostgreSQL-11 based packages broken with the postgresql-common update, or just their autopkgtests if the latter is the case, I don't mind ignoring it all if you file RC bugs against them complaining about their autopkgtest being not robust against version bumps of PostgreSQL in postgresql-common elbrus: it's just the tests, because the wrong set of PostgreSQL versions is tested please file the bugs and I'll ignore the failures (except for pg-repack which is a real problem) you want 20+ RC bugs? yes which will fix themselves after 1 day when the packages transition? autopkgtests are clearly broken ehm, sorry, we are thinking differently -*- elbrus stares at https://sources.debian.org/src/hypopg/1.1.2-1/debian/tests/control/ that says postgresql-contrib-11 the problem will disappear once pg-common is in testing so why can't autopkgtest (the program) not figure it out? elbrus: ok that's really broken, but that's not the normal case ok, so I checked the wrong example :( can you please explain then why all those autopkgtest hint at regressions? sorry I'm only starting to grasp the full picture, in the past this was no problem at all and the transition went without RT intervention -*- elbrus doesn't know how this PostgreSQL world is set-upped the new autopkgtests (which I appreciate) really made this 2 orders of magnitude more complicated Myon: that everything went smooth in the past doesn't mean there are no (versioning) bugs autopkgtest is catching a lot of missing versioned dependencies which often aren't a big problem, but technically still missing right the "normal" case is Test-Depends: postgresql-server-dev-all, and the tests then iterate over the set of versions coded into postgresql-common so I think this just needs debugging and next time we'll have everything go smoothly again this set of versions is wrong for the "other" version at the moment so what is missing? from unstable in testing for autopkgtest the problem is that at the moment we have a static debian/tests/control which doesn't know about the list of versions because both postgresql-11 and -12 are in testing it assums that the list of versions are in sync, and then everything works no the list is hardcoded in postgresql-common I still don't see any issue https://sources.debian.org/src/postgresql-common/209/debian/supported-versions/#L103 in your description the testing postgresql-common wants to test all modules for PG11 so the PG12 modules in unstable can't migrate because the testing test tries to test them for PG11 which fails the unstable pg-common tests everything for PG12 so it can't migrate because modules in testing are still PG11 so they need to migrate in parallel, but there's no dependency that enforces this the packages themselves are fine, no matter what the pg-common version is which packages are so called modules (I can't see that from the name) they just fail to test everything building something postgresql-*-foo with * being 11 or 12? which is basically everything we are talking about now, as the rest isn't version-dependant elbrus: yes does postgresql-common do anything more than telling autopkgtest which version to test? the rest is already done (mostly I think) I guess it tells which PostgreSQL is the default? elbrus: it does that, and builds debian/control from debian/control.in using that list of versions you're not allowed to build debian/control during build, so you're meaning something else I hope (fwiw, when I say "list of versions", that list has only one element in Debian, but can have more) elbrus: it will FTBFS when the debian/control isn't up to date right that's why we do all these no-op "souceful" uploads to update the list of packages built "sourceful binnmu" uploads and get an new binary package in return yes wouldn't it be possible to not embed the postgresql version in? that new binary package works fine, but it can only be tested in an environment that has the right version config or you want all this to be co-installable while a new version is being deployed we have two packages that do that (postgresql-q3c and pgsphere), but the problem there is, once a new PostgreSQL version is supported, existing users loose support for their version if they upgrade, and that's not nice so you would need an XS-Breaks-Autopkgtest field not even true more Depends than Breaks so your modules should update the debian/tests/control file with the right version on postgresql-common I put a change into the 2nd-last pg-common upload that makes the set of versions tested depend on the set of module packages actually installed, but that didn't quite work out because it needs additional stuff we don't provide in the necessary form yet it's a versioned test dependency as I get it? elbrus: yes that would be one way out except
Bug#944460: unblock: glibc/2.29-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock glibc 2.29-3 is prevented to migrate to testing due to autopktest regressions. However those regressions are unrelated to glibc and are due to the postgresql transition. Therefore would it be possible to ignore those tests and force glibc into testing? Thanks, Aurelien -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64)
Bug#944459: please run abigail on library packages before they are allowed to transition
Package: release.debian.org
Severity: wishlist
User: release.debian@packages.debian.org
Usertags: britney
Library packages still have ABI differences despite the best effort to track
them, and often migrate undetected. Reasons for that might be
- No symbols files provided in the package.
- No easy way to write a symbols file for C++, and unable
to differentiate between real issues and artifacts due to
compiler changes.
- Intentionally ignored ABI changes ("it's not part of the ABI")
A first step could be to just run abigail on such packages, report issues but
not block on those, to get an idea for possible issues.
An alternative could be to add abigail support to the packaging, as an
alternative to symbols files. That would either require a new packaging helper
dh_abigail, or integration into dpkg/debhelper. But maybe this isn't just an
alternative, but a separate step.
Bug#944458: britney doesn't run autopkg tests for binNMUs
Package: release.debian.org Severity: important User: release.debian@packages.debian.org Usertags: britney britney doesn't run autopkg tests for binNMUs. E.g. for a library transition, britney only runs the tests triggered by the library package, it doesn't run the autopkg tests for all the packages built with the new library version. Things known not to be catched are at least: * A library rebuild causes an ABI change in another library. E.g. when boost is rebuilt with a new version of icu, it changes ABI (that seems to be not the case in recent boost versions). However this kind of thing is currently not detected. * binNMUs picking up unrelated changes, and failing. E.g. dh-python now generates dependencies on python2 instead of python, but the autopkg tests still call python.
NEW changes in stable-new
Processing changes file: uim_1.8.8-4+deb10u2_mips64el.changes ACCEPT
NEW changes in stable-new
Processing changes file: libsixel_1.8.2-1+deb10u1_buildd+amd64.changes ACCEPT Processing changes file: ndppd_0.2.5-4+deb10u1_buildd+amd64.changes ACCEPT Processing changes file: python2.7_2.7.16-2+deb10u1_mips64el.changes ACCEPT
NEW changes in stable-new
Processing changes file: network-manager_1.14.6-2+deb10u1_mips64el.changes ACCEPT
Bug#944190: release.debian.org: Allow britney to consider installability of dependencies of essential packages
Mark Hindley: > Neils, > > On Fri, Nov 08, 2019 at 07:03:00AM +, Niels Thykier wrote: >> Hi Mark >> >> Thanks for the investigative work and the patch. >> >> I have not had time to review the patch yet in details and hope to have >> a look this weekend. > > Thanks. > Hi Mark, Once again, thanks for trying to fix this. I have had a look at the code and your proposed patch. As I understand it, the bug will still be present but just "harder" to trigger and possibly harder to debug (I suspect we will end up with a corrupted state in the essential set cache). >> Could I convince you to add a small test case for this problem to our >> britney2-tests repo (https://salsa.debian.org/debian/britney2-tests) >> that fails with the current master but succeeds with your patch? This >> would ensure we do not inadvertently regress on this area when >> refactoring code. > > I will happily look at that. I am busy until Sunday, but will look at it > then. > > Many thanks. > > Mark > I looking forward to your test case as it will make this issue a lot easier to debug. What is supposed to happen is that: * Britney "should" rewrite the relation on "libsystemd0" as "libsystemd0 | libelogin0" when building the BinaryPackageUniverse (actually as libsystemd0//arch | libsystemd0//arch tuples). - This is also based on the assumption that the Conflicts/Provides setup in libelogin0 is done correctly. I /think/ it is - I am just being explicit about the assumption. * The InstallabilityTester "should" consider that relation "unsolvable" when building the cache and defer it to later. That is, it should keep the relation in "ess_choices" in _get_min_pseudo_ess_set until it returns. * It /could/ be related to the caching of the pseudo-essential set. AFAIUI, the cache should "just work(tm)" if the previous point does not have a flaw. At least the current cache code assumes that libsystemd0 and libelogin0 will not be resolved by _get_min_pseudo_ess_set. Though, it could also be a point where the bug hides. I think these are the 3 key points of assumptions to verify. Honestly, I *doubt* the first point fails (I would expect a lot more breakage), but I have been wrong before. The below is the loop responsible for pre-computing the essential set. > while ess_base: > self._check_loop(universe, suite_contents, stats, > start, ess_never, cbroken, > ess_choices, ess_base) > if ess_choices: > # Try to break choices where possible > nchoice = set() > for choice in not_satisfied(ess_choices): > b = False > for c in choice: > relations = universe.relations_of(c) > if relations.negative_dependencies <= ess_never > and \ > not > any(not_satisfied(relations.dependencies)): > ess_base.append(c) > b = True > break > if not b: > nchoice.add(choice) > ess_choices = nchoice > else: > break The crucial point here is that: relations.negative_dependencies <= ess_never ... is supposed to be false for *both* libsystemd0 *and* libelogin0, but could become True for libsystemd0 if there is a bug that makes britney pick another package in the pseudo-essential set that mandates (the "real") libsytemd0. Thanks, ~Niels
NEW changes in stable-new
Processing changes file: libapache-mod-auth-kerb_5.4-2.4~deb10u1_mips64el.changes ACCEPT Processing changes file: libofx_0.9.14-1+deb10u1_mips64el.changes ACCEPT Processing changes file: libreoffice_6.1.5-3+deb10u5_amd64.changes ACCEPT Processing changes file: libreoffice_6.1.5-3+deb10u5_arm64.changes ACCEPT Processing changes file: mariadb-10.3_10.3.18-0+deb10u1_mips64el.changes ACCEPT Processing changes file: systemd_241-7~deb10u2_mips64el.changes ACCEPT
NEW changes in stable-new
Processing changes file: libreoffice_6.1.5-3+deb10u5_all.changes ACCEPT Processing changes file: mariadb-10.3_10.3.18-0+deb10u1_mips.changes ACCEPT Processing changes file: python2.7_2.7.16-2+deb10u1_i386.changes ACCEPT
Re: Should qpdf depend on gnutls?
Hi Jan, On 10-11-2019 01:10, Jay Berkenbilt wrote: > I can build qpdf 9.1 for Debian in one of three ways: 1) use only the > native crypto as in all previous releases, thus avoiding a dependency > on gnutls; 2) build only the gnutls crypto provider thus causing a > dependency on gnutls but eliminating the native crypto entirely; or 3) > building both crypto providers, in which case gnutls will be used by > default, but developers and end users will have the ability to select > the native crypto provider at runtime if desired. > > Do you have an opinion about which way I should go? I believe RHEL and > Fedora are going to use the second option of building with only gnutls > and dropping native crypto, but I have also enjoyed the fact that qpdf > has so few build dependencies. It is possible that a future version of > qpdf may support digital signature, in which case I will definitely > have to add either openssl or gnutls as a dependency. I think the opinion of the security team is valued most here, and I am pretty sure they will opt for 2. From the release team point of view, I don't think there are any objections to having a longer list of (build-) dependencies, so I would encourage you to use non-native crypto. Paul signature.asc Description: OpenPGP digital signature
Bug#944443: unblock: kopanocore/8.7.0-5 into testing
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package kopanocore in unstable We've needed to cherry-pick some upstream changes for src:kopanocore to fix some RC issues in unstable/testing that has changed the defaults for creation of new system users. Due this the test of kopano-webapp from testing against kopanocore from unstable is currently failing. The kopano-webapp package uses quite 90% of the same autopkgtest stuff as already in kopanocore is existing and used. While running the autopkgtest of kopano-webapp from testing against kopanocore in unstable this makeS the autopkgtest failing, due the changed default behavior in the kopanocore in unstable. There is no technical reason to add some Breaks stuff to kopanocore or kopano-webapp, there is no ABI or API change happen. The autopkgtest for kopano-webapp was adjusted with a new uploaded version (3.5.12-1) to keep track of the changed default kopanocore behavior and the test of this version in unstable is successful. So please unblock kopanocore so it can migrate to testing. We need afterwards to get the same issues for kopanocore fixed in stable. Thanks! Carsten unblock kopanocore/8.7.0-5 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
NEW changes in stable-new
Processing changes file: libreoffice_6.1.5-3+deb10u5_i386.changes ACCEPT Processing changes file: python2.7_2.7.16-2+deb10u1_mips.changes ACCEPT
NEW changes in stable-new
Processing changes file: libapache-mod-auth-kerb_5.4-2.4~deb10u1_amd64.changes ACCEPT Processing changes file: libofx_0.9.14-1+deb10u1_amd64.changes ACCEPT Processing changes file: libsixel_1.8.2-1+deb10u1_mips.changes ACCEPT Processing changes file: mariadb-10.3_10.3.18-0+deb10u1_armel.changes ACCEPT Processing changes file: ncurses_6.1+20181013-2+deb10u2_mips64el.changes ACCEPT Processing changes file: network-manager_1.14.6-2+deb10u1_amd64.changes ACCEPT Processing changes file: python-cryptography_2.6.1-3+deb10u2_mips64el.changes ACCEPT Processing changes file: python2.7_2.7.16-2+deb10u1_armhf.changes ACCEPT Processing changes file: systemd_241-7~deb10u2_amd64.changes ACCEPT Processing changes file: systemd_241-7~deb10u2_armel.changes ACCEPT Processing changes file: systemd_241-7~deb10u2_mips.changes ACCEPT Processing changes file: uim_1.8.8-4+deb10u2_i386.changes ACCEPT Processing changes file: uim_1.8.8-4+deb10u2_mips.changes ACCEPT
