Bug#961519: ITP: vitrage-tempest-plugin -- OpenStack Integration Test Suite - Magnum plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: vitrage-tempest-plugin Version : 1.0.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/magnum-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Magnum plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Magnum plugin.
Bug#961518: ITP: vitrage-tempest-plugin -- OpenStack Integration Test Suite - Vitrage plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: vitrage-tempest-plugin Version : 4.0.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/vitrage-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Vitrage plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Vitrage plugin.
Bug#961517: ITP: cloudkitty-tempest-plugin -- OpenStack Integration Test Suite - CloudKitty plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: cloudkitty-tempest-plugin Version : 2.0.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/cloudkitty-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - CloudKitty plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the CloudKitty plugin.
Bug#961022: ITP: ovn-octavia-provider -- OpenStack Octavia integration with OVN
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: ovn-octavia-provider Version : 0.1.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/ovn-octavia-provider * License : Apache-2.0 Programming Lang: Python Description : OpenStack Octavia integration with OVN OVN provides virtual networking for Open vSwitch and is a component of the OpenvSwitch project. This project provides integration between OpenStack Octavia and OVN.
Bug#953970: Taking over DPMT (Was: python-boto: autopkgtest failure with Python 3.8 as default)
On 5/16/20 11:02 AM, Andreas Tille wrote: > On Mon, May 11, 2020 at 10:20:24PM -0400, Noah Meyerhans wrote: >> Control: tags -1 + patch >> >>> I'll move this package to a cloud-team repository and prepare an upload >>> to unstable on Monday if nobody beats me to it. >> >> https://salsa.debian.org/cloud-team/python-boto/-/merge_requests/1 > > Could somebody from the cloud-team please merge and upload? > I'm not a member of this team and can not do anything here. > > Thanks a lot > > Andreas. > Merged, built and uploaded. Cheers, Thomas Goirand (zigo)
Bug#960299: RM: networking-ovn -- ROM; now integrated in Neutron itself
Package: ftp.debian.org Severity: normal Dear FTP masters, This Neutron plugin package source code has been integrated in in Neutron itself, so we need can get this package removed from the archive now. Cheers, Thomas Goirand (zigo)
Bug#938108: python-pyxenstore: Python2 removal in sid/bullseye
On 5/8/20 9:35 PM, Moritz Mühlenhoff wrote: > On Fri, Aug 30, 2019 at 07:45:40AM +, Matthias Klose wrote: >> Package: src:python-pyxenstore >> Version: 0.0.2-1 >> Severity: normal >> Tags: sid bullseye >> User: debian-pyt...@lists.debian.org >> Usertags: py2removal >> >> Python2 becomes end-of-live upstream, and Debian aims to remove >> Python2 from the distribution, as discussed in >> https://lists.debian.org/debian-python/2019/07/msg00080.html >> >> Your package either build-depends, depends on Python2, or uses Python2 >> in the autopkg tests. Please stop using Python2, and fix this issue >> by one of the following actions. > > Hi, > python-pyxenstore is dead upstream and there are no reverse deps, let's > remove? > > Cheers, > Moritz By all means, yes, remove this. I believe it is in Debian when I attempted to package XCP (aka: xen-api, aka xen-server, etc.), and that's long gone from Debian. Thomas
Bug#958577: Uploaded fix to delay/2
Hi,
Since nobody seem to care, I uploaded the fix to delay/2:
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,7 @@
Package: python3-docker
Architecture: all
-Depends: ${misc:Depends}, ${python3:Depends}
+Depends: python3-distutils, ${misc:Depends}, ${python3:Depends}
Description: Python 3 wrapper to access docker.io's control socket
This package contains oodles of routines that aid in controlling
docker.io over it's socket control, the same way the docker.io
Cheers,
Thomas Goirand (zigo)
Bug#959900: CVE pending / OSSA-2020-004: EC2 and credential endpoints are not protected from a scoped context
Source: keystone Version: 2:14.0.1-2 Severity: grave Tags: patch security kay reported a vulnerability in Keystone's EC2 credentials API. Keystone is the identity service used by OpenStack for authentication (authN) and high-level authorization (authZ). Any user authenticated within a limited scope (trust/oauth/application credential) can create an EC2 credential with an escalated permission, such as obtaining "admin" while the user is on a limited "viewer" role. The details and patches are available here: https://bugs.launchpad.net/keystone/+bug/1872735
Bug#955064: Simply allowing any version of Sphinx in setup.py fixes the problem
Hi Laszlo, Attached debdiff fixes the issue. Can I NMU it? A bunch of the OpenStack packages that I maintain will otherwise be auto-removed soon... Cheers, Thomas Goirand (zigo) diff -Nru grpc-1.26.0/debian/changelog grpc-1.26.0/debian/changelog --- grpc-1.26.0/debian/changelog2020-03-21 18:23:30.0 +0100 +++ grpc-1.26.0/debian/changelog2020-04-30 22:49:57.0 +0200 @@ -1,3 +1,10 @@ +grpc (1.26.0-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Rebuild. + + -- Thomas Goirand Thu, 30 Apr 2020 22:49:57 +0200 + grpc (1.26.0-2) unstable; urgency=medium * Build with protobuf version 3.11.4 or later (closes: #946194). diff -Nru grpc-1.26.0/debian/patches/allow-any-sphinx.patch grpc-1.26.0/debian/patches/allow-any-sphinx.patch --- grpc-1.26.0/debian/patches/allow-any-sphinx.patch 1970-01-01 01:00:00.0 +0100 +++ grpc-1.26.0/debian/patches/allow-any-sphinx.patch 2020-04-30 22:49:57.0 +0200 @@ -0,0 +1,16 @@ +Description: Allow any version of sphinx +Author: Thomas Goirand +Forwarded: no +Last-Update: 2020-04-30 + +--- grpc-1.26.0.orig/setup.py grpc-1.26.0/setup.py +@@ -336,7 +336,7 @@ INSTALL_REQUIRES = ( + ) + + SETUP_REQUIRES = INSTALL_REQUIRES + ( +-'Sphinx~=1.8.1', ++'Sphinx', + 'six>=1.10', + ) if ENABLE_DOCUMENTATION_BUILD else () + diff -Nru grpc-1.26.0/debian/patches/series grpc-1.26.0/debian/patches/series --- grpc-1.26.0/debian/patches/series 2019-12-20 15:34:21.0 +0100 +++ grpc-1.26.0/debian/patches/series 2020-04-30 22:49:57.0 +0200 @@ -9,3 +9,4 @@ fix-protoc-path.patch add_grpc_libdir.patch unbreak_foreach.patch +allow-any-sphinx.patch
Bug#959209: ITP: manila-tempest-plugin -- OpenStack Integration Test Suite - Manila plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: manila-tempest-plugin Version : 1.0.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/manila-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Manila plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Manila plugin.
Bug#959026: ITP: ironic-tempest-plugin -- OpenStack Integration Test Suite - Ironic plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: ironic-tempest-plugin Version : 2.0.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/ironic-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Ironic plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Ironic plugin.
Bug#950988: RFS review of cglm 0.7.1-1
Hi Leon,
Jordan did detect something was wrong with the doc. Indeed, there's some
issues. It's overall a good review, though missing some advice, which I
intend to give myself here.
1/ Sphinx documentation
Your package must be using:
--with sphinxdoc
and the -doc package must depends on ${sphinxdoc:Depends} so that
everything is handled automatically for you. I also wouldrecommend the
following sequence which I use myself (not mandatory, but nice...):
override_dh_sphinxdoc:
ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
python3 -m sphinx -b html doc/sources \
$(CURDIR)/debian/libcglm-doc/usr/share/doc/libcglm-doc/html
dh_sphinxdoc
endif
then you don't need these:
Package: libcglm-doc
Depends:
fonts-font-awesome,
fonts-lato,
libjs-jquery,
libjs-underscore,
neither you need a debian/libcglm-doc.links file, as dh_sphinxdoc will
do that for you.
2/ copyright
Jordan is right about debian/copyright needing a debian/* section.
Though the license that you're using is "Expat", which is one flavor of
the MIT license (there's multiple MIT licenses, unfortunately, and
Debian recognize this one as "Expat").
3/ Missing hardening options
You may want to add this to your debian/rules:
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
4/ Missing .symbol file
Please read on here:
https://wiki.debian.org/UsingSymbolsFiles
5/ Others
You don't need this file:
debian/libcglm0.dirs
since you're installing things in /usr/lib with debian/libcglm0.install,
then there's no need to re-declare /usr/lib a 2nd time.
Same thing for debian/libcglm-dev.dirs and debian/libcglm-doc.dirs.
6/ General advice
Leon, I strongly recommend that you run Lintian this way on your package
before asking for a review:
lintian -Ii -E --pedantic *.changes
you would have seen the issues, and win time for everyone.
Now, if you come back with a corrected package, maybe Jordan can review
it again. If he does, I agree to do an initial sponsoring of it (though
not the follow-up ones) if Jordan is volunteering for the subsequent
ones. Jordan, just let me know when the package is ok. No need to CC me
or the archive-...@nm.debian.org anymore.
Cheers,
Thomas Goirand (zigo)
On 4/27/20 12:24 PM, Jordan Justen wrote:
> Leon,
>
> I reviewed the 0.7.1-1 packaging you posted on mentors.debian.net. I
> didn't see any major issues, but maybe some suggestions.
>
> The license is MIT, and debian/copyright has it listed properly.
>
> I think packages often will call out the debian directory in
> debian/copyright, even if it matches the upstream license. I don't
> know that this is required, but here's an example:
>
>
https://salsa.debian.org/xorg-team/lib/libglvnd/-/blob/debian-unstable/debian/copyright#L50
>
> You can also move the license text to a separate section if multiple
> sections list the same license. (Like the MIT license in the example
> above.)
>
> I did see that `lintian --display-info` prints some issues relating to
> fonts in the doc package. From `build-rdeps python3-sphinx-rtd-theme`,
> I found the dbus-python package also uses the rtd theme. I notice they
> use dh_sphinxdoc, and I wonder if it could be useful for the cglm
> package. (And, perhaps fix the lintian note.)
>
> lintian --display-info also flags no-symbols-control-file
> usr/lib/x86_64-linux-gnu/libcglm.so.0.0.1. (See dpkg-gensymbols)
>
> lintian --pedantic --display-experimental flags
> debian-watch-does-not-check-gpg-signature, but I see upstream doesn't
> sign the releases. You could ask upstream to do this, and pointing
> them at https://wiki.debian.org/Creating%20signed%20GitHub%20releases
> might make it easier for them.
>
> I don't these the info or experimental lintian items would block the
> package from debian, since they aren't even at the warning level.
>
> One easy cleanup change for the package would be to run wrap-and-sort.
>
> Do you plan to try to maintain the package going forward? (Watch for
> new upstream releases, work on bugs, etc?)
>
> Do you have plans to manage the package files in git, perhaps on
> salsa.debian.net? I'm not sure if it is allowed to start using salsa
> for a project before it makes it into debian. The salsa FAQ is vague
> on this point:
>
> https://wiki.debian.org/Salsa/FAQ#What_can_be_hosted_on_salsa
>
> But I think it is often allowed. I know of at least 2 cases where a
> repo was created for a package before it got included into Debian. I
> expect some basic review of the package is probably good first, and
> perhaps this email can serve for that.
>
> If not salsa.debian.net, you could still host it in a github repo and
> include the links to it in the control file. (And, that could move to
> salsa later too.)
>
> -Jordan
>
> Some more info, mainly for Thomas to know what I checked.
>
> I looked o
Bug#944099: CVE-2019-14433 / OSSA-2019-003: buster-pu: package nova/2:18.1.0-6 -> 18.1.0-6+deb10u1
On 4/26/20 5:06 PM, Julien Cristau wrote: > On Sun, Nov 24, 2019 at 10:06:51AM +0100, Thomas Goirand wrote: >> On 11/23/19 6:09 PM, Julien Cristau wrote: >>> Control: tag -1 moreinfo >>> >>> On Mon, Nov 04, 2019 at 11:53:52AM +0100, Thomas Goirand wrote: >>>> We would like to update Nova in Buster for 2 reasons. First, there's >>>> OSSA-2019-003 / CVE-2019-14433 which we would like to fix. Second, >>>> in non-interactive mode, upgrading Nova can lead to some configuration >>>> changes, which is an RC bug. >>>> >>> This doesn't sound like it should require new debconf templates. What's >>> the logic there? Why does upgrading touch the configuration at all? >>> >>> Cheers, >>> Julien >> >> Same as for Heat for which I just replied. >> >> In the postinst, after consuming the password prompt in the .config >> script, the password is forgotten using db_unregister. The only way to >> avoid this is to have this other screen prompting for not handling this >> through debconf, which is always the default. >> > This still doesn't make sense to me. > > Cheers, > Julien Let me explain again then. If the package was installed and the password is set in the config file, when upgrading using interactive mode, the package will prompt for the password again. If the user just hit "enter" instead of entering a correct password, then the password will be cleared in the config file, and the service will be non functional. With this added prompt, all of this part will be skipped, and the Nova users wont have to enter the password again, which really is what we want here (ie: nothing to think about when upgrading). If what you have a problem with is the priority of the prompt, I can downgrade it to medium instead of high, this way, most users wont even have anything showing up during upgrade. Please let me know if this is what you want (and please, it'd be nice if you didn't make me wait another 2 months to get a reply). Cheers, Thomas Goirand (zigo)
Bug#948332: frr fixed 948332 6.0.2-2+deb10u1
fixed 948332 6.0.2-2+deb10u1
Bug#948333: buster-pu: package frr/6.0.2-2
On 4/26/20 4:06 PM, Adam D. Barratt wrote: > Control: tags -1 -moreinfo +confirmed > > On Sun, 2020-04-26 at 13:11 +0200, Thomas Goirand wrote: >> On 4/25/20 9:05 PM, Adam D. Barratt wrote: >>> Control: tags -1 + moreinfo >>> >>> On Tue, 2020-01-07 at 14:05 +0100, Thomas Goirand wrote: >>>> On 1/7/20 2:01 PM, Thomas Goirand wrote: >>>>> As per the issue described here: >>>>> https://github.com/FRRouting/frr/issues/3251 >>>>> >>>>> extended next hop capability does not work in Debian Buster. >>>>> As a consequence, we aren't able to advertize for an IP >>>>> address on our local loopback through the IPv6 link local, >>>>> which is how we would like to do BGP to the host. >>>>> >>>>> Note that this issue is from version 5.0.1 up to version >>>>> 7.2 (which is in Sid), so I took the time to cherry-pick the >>>>> fix from upstream. I have attached the resulting debdiff, and >>>>> opened the bug against the frr package itself. >>> [...] >>>> FYI, frr bug number is: >>>> https://bugs.debian.org/cgi-bin/948332 >>> >>> Apologies for the delay in getting back to you. >>> >>> The description above, and the metadata on the referenced bug >>> report, suggest that the issue still affects the package in >>> unstable. Is that correct? > [...] >> It's not correct. The version in unstable, 7.2.1, contains the >> upstream fix for this problem. > > Then https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948332 should > have a fixed version which indicates that. > > Please feel free to go ahead, but please do fix the metadata. > > Regards, > > Adam Thanks. Uploaded. BTS metadata updated. Cheers, Thomas Goirand (zigo)
Bug#947142: buster-pu: package python-oslo.utils/3.36.4-2 CVE-2019-3866
On 4/25/20 9:45 PM, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > Apologies for the delay. > > On Sat, 2019-12-21 at 22:13 +0100, Thomas Goirand wrote: >> I'd like to update python-oslo.utils in Buster to address CVE-2019- >> 3866. >> It wasn't possible to apply directly the patch available here: >> >> https://review.opendev.org/692972 >> >> and I found too dangerous to skip the commits right before it, which >> are related to this patch. So I just merged upstream branch >> stable/rocky into the Debian package. However, looking closer to all >> patches, either they are all related to the official patch, or are >> cosmetic from the Debian perspective (ie: .gitreview, or upstream CI >> related). >> >> Please find, attached to this bug, the debdiff for the udpate. >> > > +python-oslo.utils (3.36.4+2019.11.15.git.c49a426b66-1+deb10u1) buster; > urgency=medium > > I'd prefer -0+deb10u1 there, as there was (I presume) never a -1 upload > to Debian. > > With that change, please go ahead. > > Regards, > > Adam Hi, Checking upstream, since my proposal to update this package, version 3.36.5 has been released, incorporating the change. The only difference between 3.36.4+2019.11.15.git.c49a426b66 and 3.36.5 is added release notes, which aren't even packaged in the binary. So I took the liberty to upgrade to that instead, which is IMO cleaner, and doesn't change anything regarding Debian. The resulting package is uploaded to buster with 3.36.5-0+deb10u1 as version number. Cheers, Thomas Goirand (zigo)
Bug#948333: buster-pu: package frr/6.0.2-2
On 4/25/20 9:05 PM, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Tue, 2020-01-07 at 14:05 +0100, Thomas Goirand wrote: >> On 1/7/20 2:01 PM, Thomas Goirand wrote: >>> As per the issue described here: >>> https://github.com/FRRouting/frr/issues/3251 >>> >>> extended next hop capability does not work in Debian Buster. >>> As a consequence, we aren't able to advertize for an IP >>> address on our local loopback through the IPv6 link local, >>> which is how we would like to do BGP to the host. >>> >>> Note that this issue is from version 5.0.1 up to version >>> 7.2 (which is in Sid), so I took the time to cherry-pick the >>> fix from upstream. I have attached the resulting debdiff, and >>> opened the bug against the frr package itself. > [...] >> FYI, frr bug number is: >> https://bugs.debian.org/cgi-bin/948332 > > Apologies for the delay in getting back to you. > > The description above, and the metadata on the referenced bug report, > suggest that the issue still affects the package in unstable. Is that > correct? > > Regards, > > Adam It's not correct. The version in unstable, 7.2.1, contains the upstream fix for this problem. Cheers, Thomas Goirand (zigo)
Bug#951202: RFS: cglm/0.6.2-1 [ITP] -- Optimized OpenGL Mathematics library for C
On 2/12/20 2:21 PM, Leon Marz wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "cglm" > > * Package name: cglm >Version : 0.6.2-1 >Upstream Author : Recep Aslantas > * URL : https://cglm.readthedocs.io > * License : MIT > * Vcs : https://github.com/recp/cglm >Section : libs > > It builds those binary packages: > > libcglm-doc - Documentation for the cglm library > libcglm-dev - Development files for the cglm library > libcglm0 - Optimized OpenGL Mathematics library for C > > To access further information about this package, please visit the following URL: > > https://mentors.debian.net/package/cglm > > Alternatively, one can download the package with dget using this command: > > dget -x https://mentors.debian.net/debian/pool/main/c/cglm/cglm_0.6.2-1.dsc > > Changes since the last upload: > >* Initial release (Closes: #950988) > > Regards, > > -- > Leon Marz Hi Leon, My applicant (Jordan Justen, to become a DD) will review your package, and hopefully, we'll be able to sponsor the upload at the end of the process, either by an upload from Jordan when he gets his account, or from myself. To other DDs: please do not interfere with this unless you want to add comments to the review from Jordan, or my comments on his comments. Cheers, Thomas Goirand (zigo) signature.asc Description: OpenPGP digital signature
Bug#958792: ITP: octavia-tempest-plugin -- OpenStack Integration Test Suite - Octavia plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: octavia-tempest-plugin Version : 1.4.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/octavia-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Octavia plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Octavia plugin.
Bug#958752: ITP: puppet-module-tempest -- Puppet module for OpenStack Tempest
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: puppet-module-tempest Version : 16.2.1 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/puppet-tempest * License : Apache-2.0 Programming Lang: Puppet Description : Puppet module for OpenStack Tempest Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This module manages both the installation and configuration of OpenStack Tempest. . Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected.
Bug#958745: ITP: barbican-tempest-plugin -- OpenStack Integration Test Suite - Barbican plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: barbican-tempest-plugin Version : 1.0.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/barbican-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Barbican plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Barbican plugin.
Bug#958740: ITP: heat-tempest-plugin -- OpenStack Integration Test Suite - Heat plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: heat-tempest-plugin Version : 1.0.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/heat-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Heat plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Heat plugin.
Bug#958717: ITP: designate-tempest-plugin -- OpenStack Integration Test Suite - Designate plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: designate-tempest-plugin Version : 0.8.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/designate-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Designate plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Designate plugin.
Bug#958707: ITP: cinder-tempest-plugin -- OpenStack Integration Test Suite - Cinder plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: cinder-tempest-plugin Version : 1.0.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/cinder-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Cinder plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Cinder plugin.
Bug#958677: ITP: keystone-tempest-plugin -- OpenStack Integration Test Suite - Keystone plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: keystone-tempest-plugin Version : 0.4.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/keystone-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Keystone plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Keystone plugin.
Bug#948614: python3-tabulate: Update to 0.8.5 needed - OpenStack cinder dependency
Hi, Same over here, OpenStack Cinder needs tabulate 0.8.5, so I would need a newer version packaged in Debian. Please package this ASAP. Alternatively, please allow me to NMU such an update, and push back the package into the DPMT. I don't understand why it's been removed from DPMT by the way (Sandro gives no details about it in the changelog). Cheers, Thomas Goirand (zigo)
Bug#958570: ITP: python-edgegrid -- OPEN client authentication protocol for python-requests
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-edgegrid Version : 1.1.2 Upstream Author : Jonathan Landis * URL : https://github.com/akamai/AkamaiOPEN-edgegrid-python * License : Apache-2.0 Programming Lang: Python Description : OPEN client authentication protocol for python-requests This library implements an Authentication handler for requests that provides the Akamai open Edgegrid Authentication scheme. For more information visit the Akamai open Developer Community. This is a new dependency for OpenStack DNS as a Service, aka Designate.
Bug#958543: ITP: watcher-tempest-plugin -- OpenStack Integration Test Suite - Watcher plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: watcher-tempest-plugin Version : 2.0.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/watcher-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Watcher plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Watcher plugin.
Bug#958510: ITP: neutron-tempest-plugin -- OpenStack Integration Test Suite - Neutron plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: neutron-tempest-plugin Version : 1.1.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/neutron-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Neutron plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Neutron plugin.
Bug#958498: RM: libjs-extjs -- ROM; no reverse dependencies, obsolete, no upload since 2012
Package: ftp.debian.org Severity: normal Hi, It's probably more than time to remove this package from Debian. The package is super old, with no upload since 2012, so much that I forgot about it until I saw it here: https://release.debian.org/transitions/html/python2-rm.html No way it should be on the way to remove Python 2 from Debian. Looks like upstream only has a commercial product, and that package is now super-outdated. Let's get rid of it. Cheers, Thomas Goirand (zigo)
Bug#958475: ITP: murano-tempest-plugin -- OpenStack Integration Test Suite - Murano plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: murano-tempest-plugin Version : 2.0.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/murano-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Murano plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Murano plugin.
Bug#958472: ITP: telemetry-tempest-plugin -- OpenStack Integration Test Suite - Telemetry plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: telemetry-tempest-plugin Version : 1.0.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/telemetry-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Telemetry plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Telemetry plugin.
Bug#938756: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On 4/22/20 6:23 AM, Valentin Vidić wrote: > On Tue, Apr 21, 2020 at 11:20:16PM +0200, Thomas Goirand wrote: >> You can remove all of the python-oslo* from the list. The versions in >> Experimental, which are the next version of OpenStack, are fixed. In 2 >> weeks of time, I'll upload all what I staged in Experimental to Sid >> (maybe 150 packages?) and that's going to fix it all. > > Will the new OpenStack version also fix this issue? > > #955116 python-murano-pkg-check: FTBFS with Sphinx 2.4: AttributeError: > 'Sphinx' object has no attribute 'info' Hopefully yes. As I understand, the issue is in oslo-sphinx, which is deprecated. I checked, and the master branch of murano-pkg-check doesn't use oslo-sphinx (and is therefore fixed). I'm waiting for it to be released, hopefully this week or the next one. Cheers, Thomas Goirand (zigo)
Bug#945236: mirror submission for mirror.infomaniak.com
On 4/21/20 11:00 PM, Julien Cristau wrote:
> On Tue, Apr 21, 2020 at 10:56:52PM +0200, Thomas Goirand wrote:
>> On 4/20/20 4:36 PM, Julien Cristau wrote:
>>> You might need to set MIRRORNAME in the ftpsync config to the name you
>>> wish to have appear in the mirror list.
>>
>> Is it mandatory that it matches? This would need some reconfiguration on
>> our side, if it does. Please let me know so that I can act on this if
>> you require it.
>>
> Yes, we need the trace file to exist at
> http://{mirrorname}/debian/project/trace/{mirrorname} for our tools
> (e.g. https://mirror-master.debian.org/status/mirror-status.html) to
> work.
Ok, I'll make that match and write in this bug when fixed then
(probably, I'll do that tomorrow). Thanks for the info.
Cheers,
Thomas Goirand (zigo)
Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On 4/20/20 2:51 PM, peter green wrote: > On 20/04/2020 08:57, Thomas Goirand wrote: >>> Option 1: fix all four packages to be python 2 free. >>> >>> Option 2: Remove python2 stuff from traceback2, python-funcsigs and >>> numba. Break the dependencies of nipype in sid. >>> >>> Option 3: Remove python2 stuff from traceback2, modify python-funcsigs >>> so it still builds the python2 package but does not run tests with >>> python 2. >> Funcsigs is a backport of the PEP 362 function signature features from >> Python 3.3's inspect module. > Thanks for the info. >> Python 2 has never been removed from this >> package. Though instead, we shall remove this source package entirely >> from Debian. > # Broken Depends: > nipype: python-nipype > pytest: pypy-pytest > python-logfury: python3-logfury > python-oslo.utils: python3-oslo.utils > > # Broken Build-Depends: > beaker: python3-funcsigs > kombu: python3-funcsigs > nipype: python-funcsigs > pagure: python3-funcsigs > pytest: pypy-funcsigs > python-oslo.log: python3-funcsigs > python-oslo.utils: python3-funcsigs (>= 0.4) > ripe-atlas-cousteau: python3-funcsigs You can remove all of the python-oslo* from the list. The versions in Experimental, which are the next version of OpenStack, are fixed. In 2 weeks of time, I'll upload all what I staged in Experimental to Sid (maybe 150 packages?) and that's going to fix it all. For the others, probably I should start filling bugs... > If what you say is correct then it sounds like the python3-funcsigs > revese depedencies could be dealt with fairly easily. > > But that still leaves the question of what to do about the dependency of > pytest on pypy-funcsigs ? should pypy modules be removed from pytest and > it's reverse-dependencies in the same way that regular python2 modules > were? how feasible is that? are pypy-* packages only useful with python2 > pypy or are they also useful with python3 pypy? I really don't know about pypy. Probably the pypy-pytest should indeed go away, as the initial plan was to switch to pypy3. Maybe tumbleweed (Stefano Rivera) would be able to answer. I'm adding him as Cc. >> Traceback2 *already* has Python 2 support removed in Sid. I uploaded >> this on the 21st of march, pressured by its potential autoremoval. > > Sorry it seems I got my package names mixed up when writing the list of > options. I said traceback2 where I meant unittest2. So, if I'm following correctly, what you seem to propose, is to remove Python 2 from unittest2. If that's the case, then I agree with such a plan. I just didn't dare to do it yet. Though in fact, I already worked on that, but stopped, also because unittest2 FTBFS when I try building it on my laptop. So I've pushed it in its normal Git repo [1] under a py2-removal branch. If anyone has some time available to look at it, that'd be nice (I currently don't...). Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/python-team/modules/unittest2/
Bug#945236: mirror submission for mirror.infomaniak.com
On 4/20/20 4:36 PM, Julien Cristau wrote: > Control: tag -1 moreinfo > > On Thu, Nov 21, 2019 at 04:09:03PM +0000, Thomas Goirand wrote: >> Site: mirror.infomaniak.com > > Hi, > > while checking this for inclusion our tools found that: > > o trace file: > I notice there is no tracefile matching your site name > mirror.infomaniak.com in > http://mirror.infomaniak.com/debian/project/trace/ > > Please use our ftpsync script to mirror Debian. That's what I use. I even wrote a puppet module packaged in Debian for it, which installs and configures the ftpsync package (see the Debian package puppet-module-debian-archvsync). The trace correctly lists: "ver1-debmirror-1.infomaniak.ch" That's the hostname of the machine, however, this doesn't match the public IP address, which resolves using mirror1.infomaniak.com. Is this a problem? You'll notice this on our 2nd mirror too: http://mirror2.infomaniak.com/debian/project/trace/_traces Also note that, as discussed earlier, you only want to list: mirror1.infomaniak.com mirror2.infomaniak.com rather than the alias that resolve to both: mirror.infomaniak.com as server 2 does ftpsync to the first one (they don't use a shared storage, so mirror2 is updated only after mirror1 is synced). > It should produce the trace files we require, and do the mirroring in a way > that ensures the mirror is in a consistent state even during updates. > > http://mirror.infomaniak.com/debian/project/ftpsync/ftpsync-current.tar.gz > > You might need to set MIRRORNAME in the ftpsync config to the name you > wish to have appear in the mirror list. Is it mandatory that it matches? This would need some reconfiguration on our side, if it does. Please let me know so that I can act on this if you require it. Cheers, Thomas Goirand (zigo)
Bug#937144: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
On 4/20/20 4:36 AM, peter green wrote: > (using -quiet aliases where multiple involved packages have the same > maintainer listed. > > Hi > > I have just been running some self-contained buildability tests on > bullseye and these tests indicated that the python-linecache2 and > python-traceback2 source packages have been unbuildable in testing for > 170+ days. Both are fixed in unstable by removing python 2 support, but > can't migrate to testing because the python-unittest2 binary package > depends on the python-traceback2 binary package. The python2 removal bug > for python-traceback2 lists python-funcsigs as a blocker. The python2 > removal bug for python-traceback2 lists nipype and numba as blockers. > > unittest2 and python-funcsigs seem to be just module packages, so > dropping python2 support should be simple. numba seems to be a case of > leftover recommends and test-triggers so that should be a pretty easy > job to clean up too. > > nipype on the other hand looks like it needs a new upstream release. It > seems this was previously blocked on a package passing new, but said > package has now passed new. > > python-funcsigs seems to have a build-dependency on python-traceback2 > but not a binary dependency, this suggests that the dependency is only > used to run tests at build time. > > nipype and numba are not currently in testing. > > This IMO leaves three potential ways forward > > Option 1: fix all four packages to be python 2 free. > > Option 2: Remove python2 stuff from traceback2, python-funcsigs and > numba. Break the dependencies of nipype in sid. > > Option 3: Remove python2 stuff from traceback2, modify python-funcsigs > so it still builds the python2 package but does not run tests with > python 2. Funcsigs is a backport of the PEP 362 function signature features from Python 3.3's inspect module. Python 2 has never been removed from this package. Though instead, we shall remove this source package entirely from Debian. Traceback2 *already* has Python 2 support removed in Sid. I uploaded this on the 21st of march, pressured by its potential autoremoval. > If the maintainers of nipype are willing to upload a python 3 version > soon, then option 1 is IMO the preffered way forward, but a new upstream > version is not something I would be prepared to NMU. There's no other choice but to fix nipype at this point, or wait until it gets autoremoved from Testing. IMO, it'd be fine to NMU a new upstream release if you contact the current maintainer and/or using the delayed queue. > Otherwise I am inclined towards option 2. Depending on what responses I > get to this mail I may implement this option through NMUs later. IMO, we should get unittest2 free of Py2 support ASAP, and open an FTP team bug to get funcsigs removed from Debian. Cheers, Thomas Goirand (zigo)
Bug#958064: sphinxcontrib-httpdomain: Fails to register with sphinx
On 4/18/20 2:40 AM, Martina Ferrari wrote: > Merge request created at > > https://salsa.debian.org/openstack-team/third-party/sphinxcontrib-httpdomain/-/merge_requests/1 > > On 18/04/2020 01:29, Martina Ferrari wrote: >> Source: sphinxcontrib-httpdomain >> Version: 1.5.0-1 >> Severity: grave >> Tags: patch >> Justification: renders package unusable >> >> I have been unable to use this package for a few months, but could not find >> what I was doing wrong, and assumed that such a basic problem would be >> affecting other users, but there are no bugs reported. I guess this package >> has >> no users :-) >> >> Since version 1.5.0-1, the http domain is not registered with Sphinx when >> loading this plugin, and therefore, all :http:* directives are ignored and >> discarded when generating the documentation. >> >> The problem is that this version included a patch that comes from this >> upstream commit[1], but it is missing the fix added a couple of days after in >> this other commit[2]. >> >> Just adding the commit at [2] as a patch fixes the problem. I am opening now >> a merge >> request in salsa including it. >> >> [1]: >> https://github.com/sphinx-contrib/httpdomain/commit/50166fc7caedccf4ce1cd58a4d130a36f27eb739 >> [2]: >> https://github.com/sphinx-contrib/httpdomain/commit/8243bb6ec1ea0f3c96e0ed6177e743963fdd908b Thanks a lot for the patch, it's uploaded! Thomas
Bug#956736: python3-pbr: Uninstallable because of broken alternative
On 4/15/20 1:12 AM, Sandro Tosi wrote: > On Tue, 14 Apr 2020 19:05:25 -0400 Sandro Tosi wrote: >>> Updating python3-pbr (or installing it) fails with: >>> >>> update-alternatives: error: alternative path /usr/bin/python3-pbr doesn't >>> exist >>> >>> I suppose it's a left over of the alternative configuration when there was >>> Python 2 version. Now the Python 3 package directly provides /usr/bin/pbr. >> >> this is my fault, i'll take a look When I saw what you did, I double-guessed it was a possibility of failure to install, though I didn't test. No worries, shit happens. > I see zigo already fixed it in experimental with > https://salsa.debian.org/openstack-team/libs/python-pbr/-/commit/59c12ab553f08494e89642ecd368c6777df64057 > -- wanna upload that package to sid, Thomas? Well, now we have an issue. Unfortunately, pbr kind of depends on itself because of unit tests (it depends on packages that need pbr to be installed). I know it isn't ideal to have this kind of build-dependency cycle, but it's still nicer to run unit tests than not, so I ignored this situation. If you have any suggestion ... So I uploaded a degraded version without unit tests and doc, and I'll do a 2nd upload when the new PBR package reaches Sid. Thomas Goirand (zigo)
Bug#956152: rabbitmq-server: fails to install reliably on arm64
One thing that just struck me. In your logs, I can see: Not creating home directory `/var/lib/rabbitmq'. Well, if it can't create his home, there's place were rabbit will be able to store the mnesia db, and therefore, wont be able to start. I wonder if this is due to eatmydata... Cheers, Thomas Goirand (zigo)
Bug#956152: rabbitmq-server: fails to install reliably on arm64
On 4/9/20 9:48 AM, Paul Gevers wrote:
> Hi Thomas,
>
> On 08-04-2020 18:04, Thomas Goirand wrote:
>> How may I test installing rabbitmq-server on ARM64 ? I don't have such a
>> hardware...
>
> Can't you try on a porterbox?
>
> Paul
>
Hi Paul,
It took me a long time to do it, but thanks to the help of Steve
McIntyre, I could try installing RabbitMQ on an arm64 machine. A big
thanks to him! (cc him so he sees the thanks)
And it did work perfectly:
# ps axuf | grep erl
root 30007 0.0 0.0 5888 696 ttyAMA0 S+ 15:50 0:00 \_
grep erl
rabbitmq 29591 47.7 3.3 1687452 68372 ? Sl 15:49 0:11 \_
/usr/lib/erlang/erts-10.7/bin/beam.smp -W w -A 64 -MBas ageffcbf -MHas
ageffcbf -MBlmbcs 512 -MHlmbcs 512 -MMmcs 30 -P 1048576 -t 500 -stbt
db -zdbbl 128000 -K true -- -root /usr/lib/erlang -progname erl -- -home
/var/lib/rabbitmq -- -pa
/usr/lib/rabbitmq/lib/rabbitmq_server-3.7.18/ebin -noshell -noinput -s
rabbit boot -sname rabbit@debian -boot start_sasl -kernel
inet_default_connect_options [{nodelay,true}] -sasl errlog_type error
-sasl sasl_error_logger false -rabbit lager_log_root "/var/log/rabbitmq"
-rabbit lager_default_file "/var/log/rabbitmq/rab...@debian.log" -rabbit
lager_upgrade_file "/var/log/rabbitmq/rabbit@debian_upgrade.log" -rabbit
feature_flags_file
"/var/lib/rabbitmq/mnesia/rabbit@debian-feature_flags" -rabbit
enabled_plugins_file "/etc/rabbitmq/enabled_plugins" -rabbit plugins_dir
"/usr/lib/rabbitmq/plugins:/usr/lib/rabbitmq/lib/rabbitmq_server-3.7.18/plugins"
-rabbit plugins_expand_dir
"/var/lib/rabbitmq/mnesia/rabbit@debian-plugins-expand" -os_mon
start_cpu_sup false -os_mon start_disksup false -os_mon start_memsup
false -mnesia dir "/var/lib/rabbitmq/mnesia/rabbit@debian" -kernel
inet_dist_listen_min 25672 -kernel inet_dist_listen_max 25672 --
rabbitmq 29826 0.1 0.0 1912 424 ?Ss 15:49 0:00 \_
erl_child_setup 65536
It's hard to see (huge command line), but that's the output when
rabbitmq is started, believe me.
I tried stop / start the rabbitmq-server.service a few times, and it did
work for me, no problem (even though it was a bit slow on the arm64 VM I
was using, which is kind of expected with rabbitmq-server).
I'm therefore downgrading this bug to severity: important, until further
investigation can be done on your side. Indeed, this looks like specific
to your environment here.
Cheers,
Thomas Goirand (zigo)
Bug#956152: rabbitmq-server: fails to install reliably on arm64
On 4/7/20 10:35 PM, Paul Gevers wrote: > Package: rabbitmq-server > Version: 3.7.18-1 > Severity: serious > Tags: sid bullseye > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: flaky breaks > Control: affects -1 mcollective > > Dear maintainer(s), > > As can be seen in the autopkgtests of mcollective [1], rabbitmq-server > fails to reliably install on arm64 as it often fails to start. > > Paul > > [1] https://ci.debian.net/packages/m/mcollective/testing/arm64/ > > https://ci.debian.net/data/autopkgtest/testing/arm64/m/mcollective/4853115/log.gz > > Setting up rabbitmq-server (3.7.18-1) ... > Adding group `rabbitmq' (GID 109) ... > Done. > Adding system user `rabbitmq' (UID 107) ... > Adding new user `rabbitmq' (UID 107) with group `rabbitmq' ... > ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be > preloaded (cannot open shared object file): ignored. > Not creating home directory `/var/lib/rabbitmq'. > Created symlink > /etc/systemd/system/multi-user.target.wants/rabbitmq-server.service → > /lib/systemd/system/rabbitmq-server.service. > Job for rabbitmq-server.service failed because the control process > exited with error code. > See "systemctl status rabbitmq-server.service" and "journalctl -xe" for > details. > invoke-rc.d: initscript rabbitmq-server, action "start" failed. > ● rabbitmq-server.service - RabbitMQ Messaging Server > Loaded: loaded (/lib/systemd/system/rabbitmq-server.service; > enabled; vendor preset: enabled) > Active: activating (auto-restart) (Result: exit-code) since Mon > 2020-04-06 20:55:24 UTC; 7ms ago > Process: 2726 ExecStart=/usr/sbin/rabbitmq-server (code=exited, > status=1/FAILURE) >Main PID: 2726 (code=exited, status=1/FAILURE) > dpkg: error processing package rabbitmq-server (--configure): > installed rabbitmq-server package post-installation script subprocess > returned error exit status 1 > dpkg: dependency problems prevent configuration of autopkgtest-satdep: > autopkgtest-satdep depends on rabbitmq-server; however: > Package rabbitmq-server is not configured yet. > > dpkg: error processing package autopkgtest-satdep (--configure): > dependency problems - leaving unconfigured > Hi Paul, How may I test installing rabbitmq-server on ARM64 ? I don't have such a hardware... Cheers, Thomas Goirand (zigo)
Bug#956143: ITP: python-enmerkar -- Utilities for using Babel in Django
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-enmerkar Version : 0.7.1 Upstream Author : Christopher Grebs * URL : https://github.com/Zegocover/enmerkar * License : BSD Programming Lang: Python Description : Utilities for using Babel in Django This package contains various utilities for integration of Babel into the Django web framework: * A message extraction plugin for Django templates. * A middleware class that adds the Babel Locale object to requests. * A set of template tags for date and number formatting. This is a new (build-)dependency of Horizon, the OpenStack dashboard.
Bug#956070: ITP: python-etcd3 -- client for the etcd3 API
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-etcd3 Version : 0.12.0 Upstream Author : Louis Taylor * URL : https://github.com/kragniz/python-etcd3 * License : Apache-2.0 Programming Lang: Python Description : client for the etcd3 API This package contains the python-etcd3 library, which is a module to connect to an Etcd cluster. Note: This module is needed by python3-tooz (this is a new dependency), which is the heart of the OpenStack global cluster lock system.
Bug#953970: Taking over DPMT (Was: python-boto: autopkgtest failure with Python 3.8 as default)
On 3/30/20 11:44 AM, Andreas Tille wrote: > I wonder whether we should take over python-boto into DPMT maintenance > which would enable commits to Git way more easily. I'd very much be in the favor of this, especially considering the package history. Cheers, Thomas Goirand (zigo)
Bug#955701: O: python-tablib -- format agnostic tabular dataset library
Package: wnpp Severity: normal I intend to orphan the python-tablib package. Indeed, it's not used in OpenStack anymore, which was the only reason to keep it in Debian. The package description is: Tablib is a format agnostic tabular dataset library, written in Python. It allows you to import, export, and manipulate tabular data sets. Advanced features include, segregation, dynamic columns, tags & filtering, and seamless format import & export.
Bug#955650: python-tablib: FTBFS: E NotImplementedError: DataFrame Format requires `pandas` to be installed. Try `pip install tablib[pandas]`.
On 4/3/20 9:55 PM, Lucas Nussbaum wrote: > Source: python-tablib > Version: 0.13.0-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200402 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. To whoever reads this: the OpenStack team is no longer interested in this package (it's not an OpenStack dependency anymore), please take it over. I wont be fixing this bug. Cheers, Thomas Goirand (zigo)
Bug#955473: Please upgrade to 2.7.1
Package: python3-paramiko Severity: normal Hi, OpenStack Ussuri, due next month, uses Paramiko 2.7.1. It'd be nice if we could have that version in unstable soonish. Thanks, Thomas Goirand (zigo)
Bug#948295: python-dateutils's autopkg tests fail / Update to 2.8.1 for Python 3.8
Hi! Please accept and upload the merge request over her adressing this bug: https://salsa.debian.org/agx/python-dateutil/-/merge_requests/1 Alternatively, ping me to NMU. Cheers, Thomas Goirand (zigo)
Bug#955418: Please upgrade to 0.3.1
Source: sqlparse Severity: normal Hi, OpenStack Ussuri, due in a months, needs 0.3.1. Please upgrade the package to that version. Alternatively, please consider putting the team as maintainer rather than yourself, and I'll do a team upload. Cheers, Thomas Goirand (zigo)
Bug#955396: ITP: python-django-pyscss2 -- makes it easier to use PySCSS in Django
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-django-pyscss2 Version : 3.0.0 Upstream Author : Ivan Kolodyazhny * URL : https://github.com/e0ne/django-pyscss * License : BSD-2-clause Programming Lang: Python Description : makes it easier to use PySCSS in Django Django-pyscss is a collection of tools for making it easier to use pyScss within Django. It overwrites the import system to use Django's staticfiles app. This way you can import SCSS files from any app (or any file that's findable by the STATICFILES_FINDERS) with no hassle. It provides a django-compressor precompile filter class so that you can easily use pyScss with django-compressor without having to bust out to the shell. This has the added benefit of removing the need to configure pyScss through its command-line arguments AND makes it possible for the exceptions and warnings that pyScss emits to bubble up to your process so that you can actually know what's going on. Note: this package will replace python-django-pyscss, as it is unmaintained.
Bug#955361: ITP: python-pyscss2 -- fork of pyscss
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-pyscss2 Version : 1.3.7 Upstream Author : Ivan Kolodyazhny * URL : https://github.com/e0ne/pyScss * License : Expat Programming Lang: Python Description : SCSS compiler (fork of pyscss) pyScss compiles Scss (Sass), a superset of CSS that is more powerful, elegant and easier to maintain than plain-vanilla CSS. The library acts as a CSS source code preprocesor which allows you to use variables, nested rules, mixins, and have inheritance of rules, all with a CSS-compatible syntax which the preprocessor then compiles to standard CSS. This package will supercede python-pyscss which is now unmaintained.
Bug#955098: python-os-api-ref: FTBFS with Sphinx 2.4: ImportError: cannot import name 'AutoDirective' from 'sphinx.ext.autodoc' (unknown location)
On 3/27/20 3:27 PM, Lucas Nussbaum wrote: > Source: python-os-api-ref > Version: 1.6.2+dfsg1-1 > Severity: important > Tags: ftbfs > User: python-modules-t...@lists.alioth.debian.org > Usertags: sphinx2.4 > > Hi, > > python-os-api-ref fails to build with Sphinx 2.4, currently available in > experimental. According to upstream, the issue isn't in os-api-ref, but in sphinx-testing. With sphinx-testing 1.0.1, it would just work. So I guess the next course of action is to get sphinx-testing upgraded. Cheers, Thomas Goirand (zigo)
Bug#954530: [PKG-Openstack-devel] Bug#954530: python-trollius: FTBFS: tests failed
On 3/22/20 8:58 AM, Lucas Nussbaum wrote: > Source: python-trollius > Version: 2.1~b1-5 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200321 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > The full build log is available from: >http://qa-logs.debian.net/2020/03/21/python-trollius_2.1~b1-5_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > About the archive rebuild: The rebuild was done on EC2 VM instances from > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every > failed build was retried once to eliminate random failures. Hi, FYI, this package is going away with the removal of Python 2, as it is a backport of asyncio for Python 2. Only uwsgi is using it at the moment, and this package should be addressed for Python 2 removal also. Cheers, Thomas Goirand (zigo)
Bug#805459: Debdiff for NMU of iptables-converter
Hi,
Please see attached debdiff for fixing the 2 open bugs, one of which is
a RC bug (ie: Python 2 removal). I'm uploading this to DELAYED/10.
Please let me know if that's ok, or if I should dcut the package.
Cheers,
Thomas Goirand (zigo)
diff -Nru iptables-converter-0.9.8/debian/changelog
iptables-converter-0.9.8/debian/changelog
--- iptables-converter-0.9.8/debian/changelog 2015-10-31 21:20:47.0
+0100
+++ iptables-converter-0.9.8/debian/changelog 2020-03-22 13:01:11.0
+0100
@@ -1,3 +1,25 @@
+iptables-converter (0.9.8-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Switch the package to Python 3 (Closes: #943068):
+- Remove obsolete X-Python-Version:.
+- Replaced python2 direct depends by ${python3:Depends}.
+- Removed python2 build-depends, replaced python3 build-depends by a
+ python3-all build-depends.
+- Use python3 to build the sphinx doc.
+ * Ran wrap-and-sort -bastk.
+ * Fixed the package descriptions (Closes: #805459).
+ * Removed useless overrides.
+ * Switched to debhelper-compat = 12.
+ * Standards-Version: 4.5.0.
+ * Removed wrong exports in d/rules:
+- export DH_VERBOSE=1
+- export DH_OPTIONS=-v
+- export DEB_BUILD_OPTIONS=1
+ * Better ordering for d/control source package.
+
+ -- Thomas Goirand Sun, 22 Mar 2020 13:01:11 +0100
+
iptables-converter (0.9.8-1) unstable; urgency=medium
* Import upstream version 0.9.8
diff -Nru iptables-converter-0.9.8/debian/compat
iptables-converter-0.9.8/debian/compat
--- iptables-converter-0.9.8/debian/compat 2015-10-31 21:13:12.0
+0100
+++ iptables-converter-0.9.8/debian/compat 1970-01-01 01:00:00.0
+0100
@@ -1 +0,0 @@
-9
diff -Nru iptables-converter-0.9.8/debian/control
iptables-converter-0.9.8/debian/control
--- iptables-converter-0.9.8/debian/control 2015-10-31 21:13:12.0
+0100
+++ iptables-converter-0.9.8/debian/control 2020-03-22 13:01:11.0
+0100
@@ -1,34 +1,37 @@
Source: iptables-converter
-Maintainer: Johannes Hubertz
Section: utils
Priority: optional
-Build-Depends: python (>= 2.6.5),
- python-setuptools,
- python-sphinx,
- dh-python,
- debhelper (>= 9),
- python3 (>= 3.4),
- python3-setuptools,
- python3-sphinx
-Uploaders: Toni Mueller
-X-Python-Version: (>= 2.6)
-Standards-Version: 3.9.6
+Maintainer: Johannes Hubertz
+Uploaders:
+ Toni Mueller ,
+Build-Depends:
+ debhelper-compat (= 12),
+ dh-python,
+ python3-all,
+ python3-setuptools,
+ python3-sphinx,
+Standards-Version: 4.5.0
Package: iptables-converter
Section: utils
Architecture: all
-Depends: python (>= 2.6.5), ${misc:Depends}
+Depends:
+ ${misc:Depends},
+ ${python3:Depends},
Description: convert iptables-commands from a file to iptables-save format
- iptables-converter: reads a file with iptables commands and converts
- these to an iptables-save readable format. To provide compatibility
- with iptables-save -c command zero packet and byte counters [0:0] are
- printed out.
- ip6tables-converter does the same for IPv6.
+ iptables-converter: reads a file with iptables commands and converts these to
+ an iptables-save readable format. To provide compatibility with
+ "iptables-save -c" command zero packet and byte counters [0:0] are printed
+ out. ip6tables-converter does the same for IPv6.
Package: iptables-converter-doc
Section: doc
Architecture: all
-Depends: ${misc:Depends}, ${sphinxdoc:Depends}
-Description: sphinx documentation for iptables-converter
- iptables-converter: convert iptables from file to iptables-save format
- ip6tables-converter mentioned
+Depends:
+ ${misc:Depends},
+ ${sphinxdoc:Depends},
+Description: convert iptables-commands from a file to iptables-save format -
doc
+ iptables-converter: reads a file with iptables commands and converts these to
+ an iptables-save readable format. To provide compatibility with
+ "iptables-save -c" command zero packet and byte counters [0:0] are printed
+ out. ip6tables-converter does the same for IPv6.
diff -Nru iptables-converter-0.9.8/debian/copyright
iptables-converter-0.9.8/debian/copyright
--- iptables-converter-0.9.8/debian/copyright 2015-10-31 21:13:12.0
+0100
+++ iptables-converter-0.9.8/debian/copyright 2020-03-22 13:00:58.0
+0100
@@ -25,4 +25,3 @@
On Debian systems, the full text of the GNU General Public
License version 3 can be found in the file
`/usr/share/common-licenses/GPL-3'.
-
diff -Nru iptables-converter-0.9.8/debian/iptables-converter.install
iptables-converter-0.9.8/debian/iptables-converter.install
--- iptables-converter-0.9.8/debian/iptables-converter.install 1970-01-01
01:00:00.0 +0100
+++ iptables-converter-0.9.8/debian/iptables-converter.install 2020-03-22
13:01:11.0 +0100
@@ -0,0 +1 @@
+/usr
diff -Nru iptables-converter-0.9.8/debian/iptables-converter.manpages
iptab
Bug#952127: When should I drop python2 support for python-linecache2 & python-traceback2 (therefore, unittest2, mock, sphinx, pytest... and the rest of the Python 2 world if I pull this string until e
Hi, python-fixture (the binary) is gone, therefore we have #952130 and #952127. I've been reluctant to remove Py2 support from these, because unittest2 needs it, and this would break a lot of packages (including, indirectly, stuff like sphinx, pytest, etc.). What is it that the team suggests at this point? Should I reintroduce Py2 support in fixtures, or should we go ahead and do a missive Py2 RM of what's left in the archive? We're down to only 366 packages with Py2 in testing. We can either postpone forever, or just go hardly on it (but there will be inevitable collaterals...). Your thoughts? Cheers, Thomas Goirand (zigo)
Bug#954269: buster-pu: package manila/1:7.0.0-1 CVE-2020-9543
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Dear Stable Release Team,
The security team told me that this update is a no-DSA. Can I upload this
Manila update to proposed-updates then?
If you didn't know, Manila is OpenStack's file system share as a service
(like for example, NFS share as a service, running on top of a Cinder or
a Ceph block storage, or CephFS, or a proprietary NAS, etc.).
FYI, the security bug is that anyone knowing an UUID of a Manila share,
can basically do whatever it wants with it. It's no DSA because guessing
such an UUID isn't practical, and an operator would likely notice if one
is attempting to brute-force. I still think it deserves patching Buster.
Debdiff attached.
Cheers,
Thomas Goirand (zigo)
diff -Nru manila-7.0.0/debian/changelog manila-7.0.0/debian/changelog
--- manila-7.0.0/debian/changelog 2018-09-05 15:53:37.0 +0200
+++ manila-7.0.0/debian/changelog 2020-03-09 15:53:45.0 +0100
@@ -1,3 +1,11 @@
+manila (1:7.0.0-1+deb10u1) buster; urgency=medium
+
+ * CVE-2020-9543: Manila allows other project users to view, update, delete,
+or share resources that do not belong to them. Applied upstream patch:
+share_networks: enable project_only API only (Closes: #953581).
+
+ -- Thomas Goirand Mon, 09 Mar 2020 15:53:45 +0100
+
manila (1:7.0.0-1) unstable; urgency=medium
[ Ondřej Nový ]
diff -Nru
manila-7.0.0/debian/patches/CVE-2020-9543_share_networks_enable_project_only_API_only.patch
manila-7.0.0/debian/patches/CVE-2020-9543_share_networks_enable_project_only_API_only.patch
---
manila-7.0.0/debian/patches/CVE-2020-9543_share_networks_enable_project_only_API_only.patch
1970-01-01 01:00:00.0 +0100
+++
manila-7.0.0/debian/patches/CVE-2020-9543_share_networks_enable_project_only_API_only.patch
2020-03-09 15:53:45.0 +0100
@@ -0,0 +1,124 @@
+Description: CVE-2020-9543: share_networks: enable project_only API only
+ At the moment, the share_network database API which the web
+ API layer interacts with directly does not have any checking
+ for project_id which means that a user has the ability to run
+ operations against any other share_network if they have the ID.
+ .
+ This patch implements the usage of project_only in the database
+ query which ensures that administrators still have the behaviour
+ of getting any share network they want, but users can only pull
+ up those which are part of their context/authenticated project.
+ .
+ This patch also adjusts a few other tests due to the fact that
+ the existing tests would run a lot of inserts with a different
+ project_id than the context, which is not allowed in this new
+ API behaviour. Therefore, the instances that involved projects
+ different than the context were converted to elevated ones.
+ .
+ There was also an instance where they were being created with a
+ project_id that did not match the fake context, therefore the
+ context was adjusted accordingly as well.
+Author: Mohammed Naser
+Date: Fri, 31 Jan 2020 16:13:24 +0100
+Change-Id: Id67a939a475c4ac06d546b7e095bd10f1a6d2619
+Origin: upstream
+Bug-Debian: https://bugs.debian.org/953581
+Last-Update: 2020-03-09
+
+Index: manila/manila/db/sqlalchemy/api.py
+===
+--- manila.orig/manila/db/sqlalchemy/api.py
manila/manila/db/sqlalchemy/api.py
+@@ -3330,7 +3330,8 @@ def _security_service_get_query(context,
+ def _network_get_query(context, session=None):
+ if session is None:
+ session = get_session()
+-return (model_query(context, models.ShareNetwork, session=session).
++return (model_query(context, models.ShareNetwork, session=session,
++project_only=True).
+ options(joinedload('share_instances'),
+ joinedload('security_services'),
+ joinedload('share_servers')))
+Index: manila/manila/tests/db/sqlalchemy/test_api.py
+===
+--- manila.orig/manila/tests/db/sqlalchemy/test_api.py
manila/manila/tests/db/sqlalchemy/test_api.py
+@@ -1966,7 +1966,7 @@ class ShareNetworkDatabaseAPITestCase(Ba
+ share_nw_dict2['project_id'] = 'fake project 2'
+ result1 = db_api.share_network_create(self.fake_context,
+ self.share_nw_dict)
+-result2 = db_api.share_network_create(self.fake_context,
++result2 = db_api.share_network_create(self.fake_context.elevated(),
+ share_nw_dict2)
+
+ self._check_fields(expected=self.share_nw_dict, actual=result1)
+@@ -1999,6 +1999,33 @@ class ShareNetworkDatabaseAPITestCase(Ba
+ self.assertEqual(0, len(result['share_instances']))
+ self.assertEqual(0, len(result['security_services']))
+
++def _create_share_network_for_project(self, project_id
Bug#949845: Constant 100% CPU usage by ovs-vswitchd
On 3/18/20 10:35 AM, Kees Meijs wrote: > > On 17-03-2020 14:37, Thomas Goirand wrote: >> You may have notice my last upload of OVS in buster-proposed-updates. >> This upload fixes at least one of the crashes which leads to vswitchd >> taking 100% of one core. >> >> However, there's still some other issues we've experienced in >> production. Soon, we'll test the latest version of OVS 2.10, and I'll be >> able to tell if this fixes the other crash I've seen. In the mean time, >> you can try 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u2 from >> buster-proposed-updates. > > Good morning Thomas, > > The past few weeks have been intense at least so I did not. Same for > comparing 2.10 with 2.11 code. Much appreciated you point out the > upload. > > To save valuable time our cluster is running 2.11 where possible but > it would be best to go back to the stock Debian packages. > > What other issues do you refer to? I would love to make time and test > your new build (thank you, taking a deep bow) but are curious about > other potential issues before I do. > > Best regards, > Kees Hi, I've fixed *one* type of crash, but we saw others, with a different backtrace (which I could see using gdb). We're now upgrading to the version see here: http://shade.infomaniak.ch/buster-pu/openvswitch/ This is the top of the 2.10 branch, version is: 2.10.4+2020.01.14.b2ccc307f1+dfsg1-1+deb10u3 I don't know yet if it fixes the problem we have ... I can try to convince the release team to update to that version in Buster, but chances they accept is kind of low. Cheers, Thomas Goirand (zigo)
Bug#949845: Constant 100% CPU usage by ovs-vswitchd
Hi Kees, You may have notice my last upload of OVS in buster-proposed-updates. This upload fixes at least one of the crashes which leads to vswitchd taking 100% of one core. However, there's still some other issues we've experienced in production. Soon, we'll test the latest version of OVS 2.10, and I'll be able to tell if this fixes the other crash I've seen. In the mean time, you can try 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u2 from buster-proposed-updates. Cheers, Thomas Goirand (zigo)
Bug#951699: openvswitch: please update to new upstream release 2.13 to allow dpdk 19.11's upload to unstable
Hi Luca, I've done the work for packaging OVS 2.13, and in fact, it needs dpdk 19.11 which is currently in Experimental, otherwise it can't build. So it is a little bit a problem of chicken and egg here. Do you wish me to upload OVS 2.13 in Experimental first? Cheers, Thomas Goirand (zigo)
Bug#953246: buster-pu: package openvswitch/2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u1
On 3/6/20 8:20 PM, Adam D. Barratt wrote:
> Control: tags -1 + confimred
>
> On Fri, 2020-03-06 at 14:15 +0100, Thomas Goirand wrote:
>> We experienced (in production) a bug in OVS which lead to ovs-
>> vswitchd being killed, leading to network downtime in our OpenStack
>> environment.
>> Attached is the fix. I wish to upload this update to Buster.
>
> That looks OK, but:
>
>> On top of this upstream fix, a small typo fix in ifupdown.sh.
>>
>
> --- openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/ifupdown.sh
> 2019-06-24 08:53:33.0 +0200
> +++ openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/ifupdown.sh
> 2019-09-19 14:40:49.0 +0200
> @@ -103,10 +103,10 @@
> ifdown --allow="${IFACE}" ${IF_OVS_PORTS}
> fi
>
> -ovs_vsctl -- --if-exists del-br "${IFACE}"
> +ovs-vsctl -- --if-exists del-br "${IFACE}"
> ;;
> OVSPort|OVSIntPort|OVSBond|OVSPatchPort|OVSTunnel)
> -ovs_vsctl -- --if-exists del-port "${IF_OVS_BRIDGE}"
> "${IFACE}"
> +ovs-vsctl -- --if-exists del-port "${IF_OVS_BRIDGE}"
> "${IFACE}"
>
> As far as I can see, the corresponding script in unstable is still full
> of calls to "ovs_vsctl" (admittedly, not the two list above):
>
> $ grep -c ovs_vsctl
> openvswitch-2.11.0+2019.06.25+git.9ebe795035+ds1/debian/ifupdown.sh
> 8
> $ grep -c ovs-vsctl
> openvswitch-2.11.0+2019.06.25+git.9ebe795035+ds1/debian/ifupdown.sh
> 4
>
> Feel free to go ahead with the proposed change, but you may want to
> consider fixing the remainder in unstable and then stable at some
> point.
>
> Regards,
>
> Adam
Hi Adam,
Thanks for the update review.
In fact, ovs_vsctl exists in this script, it's just a wrapper, but where
I added a thing, it really is ovs-vsctl that I wanted to call (ie:
without the timeout wrapper).
Uploaded...
Cheers,
Thomas Goirand (zigo)
Bug#953246: buster-pu: package openvswitch/2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Dear release team,
We experienced (in production) a bug in OVS which lead to ovs-vswitchd
being killed, leading to network downtime in our OpenStack environment.
Attached is the fix. I wish to upload this update to Buster.
On top of this upstream fix, a small typo fix in ifupdown.sh.
Please let me upload
openvswitch/2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u2
Cheers,
Thomas Goirand (zigo)
diff -Nru openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/changelog
openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/changelog
--- openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/changelog
2019-06-24 08:53:33.0 +0200
+++ openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/changelog
2019-09-19 14:40:49.0 +0200
@@ -1,3 +1,11 @@
+openvswitch (2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u2) buster;
urgency=medium
+
+ * Fixed debian/ifupdown.sh typo: ovs_vsctl -> ovs-vsctl.
+ * Add patch to fix ovs-vswitchd dying:
+- Fix_vswitchd_abort_when_a_port_is_added_and_the_controller_is_down.patch
+
+ -- Thomas Goirand Thu, 19 Sep 2019 14:40:49 +0200
+
openvswitch (2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12+deb10u1) buster;
urgency=medium
* Some fixups in debian/ifupdown.sh to allow setting-up the MTU.
diff -Nru openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/ifupdown.sh
openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/ifupdown.sh
--- openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/ifupdown.sh
2019-06-24 08:53:33.0 +0200
+++ openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/ifupdown.sh
2019-09-19 14:40:49.0 +0200
@@ -103,10 +103,10 @@
ifdown --allow="${IFACE}" ${IF_OVS_PORTS}
fi
-ovs_vsctl -- --if-exists del-br "${IFACE}"
+ovs-vsctl -- --if-exists del-br "${IFACE}"
;;
OVSPort|OVSIntPort|OVSBond|OVSPatchPort|OVSTunnel)
-ovs_vsctl -- --if-exists del-port "${IF_OVS_BRIDGE}" "${IFACE}"
+ovs-vsctl -- --if-exists del-port "${IF_OVS_BRIDGE}" "${IFACE}"
;;
*)
exit 0
diff -Nru
openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/patches/Fix_vswitchd_abort_when_a_port_is_added_and_the_controller_is_down.patch
openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/patches/Fix_vswitchd_abort_when_a_port_is_added_and_the_controller_is_down.patch
---
openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/patches/Fix_vswitchd_abort_when_a_port_is_added_and_the_controller_is_down.patch
1970-01-01 01:00:00.0 +0100
+++
openvswitch-2.10.0+2018.08.28+git.8ca7c82b7d+ds1/debian/patches/Fix_vswitchd_abort_when_a_port_is_added_and_the_controller_is_down.patch
2019-09-19 14:40:49.0 +0200
@@ -0,0 +1,87 @@
+Author: Numan Siddique
+Date: Thu, 18 Oct 2018 16:47:05 +0530
+Description: connmgr: Fix vswitchd abort when a port is added and the
controller is down
+ We see the below trace when a port is added to a bridge and the configured
+ controller is down
+ .
+ 0x7fb002f8b207 in raise () from /lib64/libc.so.6
+ 0x7fb002f8c8f8 in abort () from /lib64/libc.so.6
+ 0x7fb004953026 in ofputil_protocol_to_ofp_version () from
/lib64/libopenvswitch-2.10.so.0
+ 0x7fb00494e38e in ofputil_encode_port_status () from
/lib64/libopenvswitch-2.10.so.0
+ 0x7fb004ef1c5b in connmgr_send_port_status () from
/lib64/libofproto-2.10.so.0
+ 0x7fb004efa9f4 in ofport_install () from /lib64/libofproto-2.10.so.0
+ 0x7fb004efbfb2 in update_port () from /lib64/libofproto-2.10.so.0
+ 0x7fb004efc7f9 in ofproto_port_add () from /lib64/libofproto-2.10.so.0
+ 0x556d540a3f95 in bridge_add_ports__ ()
+ 0x556d540a5a47 in bridge_reconfigure ()
+ 0x556d540a9199 in bridge_run ()
+ 0x556d540a02a5 in main ()
+ .
+ The abort is because of ofputil_protocol_to_ofp_version() is called with
invalid
+ protocol - OFPUTIL_P_NONE. Please see [1] for more details. Similar aborts are
+ seen as reported in [2].
+ .
+ The commit [3] changed the behavior of the function rconn_get_version().
+ Before the commit [3], the function ofconn_receives_async_msg() would always
+ return false if the connection to the controller was down, since
+ rconn_get_version() used to return -1. This patch now checks the rconn
+ connection status in ofconn_receives_async_msg() and returns false if not
+ connected. This would avoid the aborts seen in the above stack trace.
+ .
+ The issue can be reproduced by running the test added in this patch
+ without the fix.
+ .
+ [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1640045
+ [2] - https://bugzilla.redhat.com/show_bug.cgi?id=1637926
+ .
+ [3] - 476d2551ab ("rconn: Introduce new invariant to fix assertion failure in
co
Bug#947847: Bug#952897: opentmpfiles: Please make opentmpfiles to be drop-in replacement to systemd-tmpfiles
On 3/1/20 5:15 PM, Ondřej Surý wrote:
> Package: opentmpfiles
> Version: 0.2+2019.05.21.git.44a55796ba-2
> Severity: important
>
> Dear Maintainer,
>
> to make opentmpfiles usable for package maintainers
> it needs to be drop-in replacement in a sense that
> I can rely on the interface to be available for my
> packages. Not by calling extra script, not by adding
> extra shell spaghetti to decide whether systemd-tmpfiles
> is available and if not try opentmpfiles and if not ...
>
> As a packager I want to be able to freely use the
> declaratife interfaces provided by systemd even when
> writing sysv-rc scripts. The other option would be
> to just drop the init script and provide just the
> service file, but I am not decided I want to go
> this path.
>
> Ondrej
Hi Ondrej,
I very much agree with this, which is why there's a bug open against the
tech ctte: #947847 (which I'm CC-ing hereby). That's probably too much
reading. Basically, I'm asking the tech ctte what is the best way to
achieve what you described above. We're down to:
- using update-alternatives
The tech ctte and the systemd maintainer expressed themselves against
the idea.
- having systemd package tmpfiles and sysusers in separate packages, and
have them conflict with open{sysusers,tmpfiles}
This could work, but would need some non-trivial work from systemd
maintainers, also the systemd version may be a little too big. Also,
that's micro-packaging, and we're not sure if that's the solution. If we
go that path, maybe we will need 2 new virtual packages.
- using dpkg-divert in open{sysusers,tmpfiles} to replace the systemd
implementations.
That's really what I would hate doing, because this would hide things
from our users. Most Debian users don't even know about dpkg-divert, and
even less how to use it.
The question I've opened to the tech ctte is wider than just how to
package open{sysusers,tmpfiles}, it's also about how reverse dependency
should use it. Contrary to what I've been told, the point of using
open{sysusers,tmpfiles} goes beyond just non-linux ports: I want them to
be real alternatives, including in small environment (containers, VMs,
embedded), and I want that any user can choose what to use, even if
systemd is installed. I hope I'll be heard.
So, this bug will continue to be open until the tech ctte decides, or
the systemd maintainers agree to be open{sysusers,tmpfiles} friendly,
whatever comes first. Until then, I'm also putting on hold any work on
these 2 packages.
Cheers,
Thomas Goirand (zigo)
Bug#952762: openstack-pkg-tools: please make the build reproducible
On 3/1/20 2:57 AM, Chris Lamb wrote: > Hi Thomas, > > > Do I understand well that you saw this in redfishtool? In such case, >> that's where the bug should be filled, IMO. > > I think have two issues here. This one (ie. the timing problem) in > openstack-pkg-tools is still something that should be fixed, > regardless of what other packages do IMHO. > >> This is very nice, but in fact, having python3.8 or python3.7, can be >> considered as a bug in the packages I maintain. Indeed, what it means is >> that the package is missing: >> >> override_dh_python3: >> dh_python3 --shebang=/usr/bin/python3 > > This sounds logical. However, would this not be better fixed centrally > for *all* packages that use /usr/share/openstack-pkg-tools/pkgos.make > rather than add the following snippet to redfishtool? I don't see this > package doing anything particularly special, and making this change in > every leaf package doesn't seem very elegant to me. > > > Regards, The problem is, some package may need to customize dh_python3 calls even further. For example: override_dh_python3: dh_python3 --shebang=/usr/bin/python3 dh_python3 /usr/share/foo if there's some Python files in /usr/share/foo So there's no "one fit all" solution. Or do you have a suggestion here? Cheers, Thomas Goirand (zigo)
Bug#952762: openstack-pkg-tools: please make the build reproducible
On 2/28/20 7:15 PM, Chris Lamb wrote:
> Source: openstack-pkg-tools
> Version: 108
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: toolchain
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> Hi,
>
> Whilst working on the Reproducible Builds effort [0] we noticed that
> openstack-pkg-tools is causing other packages to be built in an
> unreproducible manner.
>
> In particular, the "/usr/bin/pkgos-dh_auto_install" script may
> nondeterministically create packages with differing shebangs and binary
> dependencies. For example, this is from src:redfishtool:
>
> │ -#!/usr/bin/python3.7
> │ +#!/usr/bin/python3.8
>
> […]
>
> │ │ │ │ -Depends: python3-requests, python3.8:any, python3:any
> │ │ │ │ +Depends: python3-requests, python3.7:any, python3:any
>
> §
>
> This is caused by a number of layered reasons. First, we are building
> all supported Python versions (eg. Python 3.7 and Python 3.8) in
> separate directories but then seqeuentially installing them to the
> same destination, debian/${TARGET_DIR}.
>
> However, this causes problems because if latter installations complete
> in less than one second, distutils may decide to skip copying files in
> the shared destination as it incorrectly believes them to be up-to-
> date. This will result in a package arbitrarily containing scripts
> with different version shebangs depending on the approximate total
> execution speed of installation. This is, needless to say,
> nondeterminstic.
>
> For example, if we build for both Python 3.7 and Python 3.8 but the
> installation of the latter occurs within the same wall clock second of
> the former, the Python 3.8 version will not overwrite the Python 3.7
> verison and lead to a shebang of #!/usr/bin/python3.7 … whilst if it
> does not occur within the same second, the shebang will be overwritten
> to #!/usr/bin/python3.8.
>
> A patch is attached that passes --force to `setup.py install [..]`
> which will avoid the underlying calls to distutils's `dep_util.newer`
> and thus will always update.
>
> [0] https://reproducible-builds.org/
>
>
> Regards,
Hi Chris!
This is very nice, but in fact, having python3.8 or python3.7, can be
considered as a bug in the packages I maintain. Indeed, what it means is
that the package is missing:
override_dh_python3:
dh_python3 --shebang=/usr/bin/python3
Without this, the package incorrectly will have python3.x as dependency
instead of python3:any.
Do I understand well that you saw this in redfishtool? In such case,
that's where the bug should be filled, IMO.
Your thoughts?
Cheers,
Thomas Goirand (zigo)
Bug#952707: uwsgi-plugin-python3: Please provide httpd-wsgi3 virtual package
On 2/27/20 10:03 PM, Michael Fladischer wrote: > Package: uwsgi-plugin-python3 > Severity: normal > > Dear Maintainer, > > according to #768117, packages which provide a Python3 WSGI server should have > "Provides: httpd-wsgi3". This allows WSGI applications to depend on this > virtual > package an not be tied to a particular server. > > The debian policy defines this virtual package here: > > https://salsa.debian.org/dbnpolicy/policy/-/blob/master/virtual-package-names-list.yaml#L166 > > Kind regards, > Michael Hi, Except uwsgi, which other package would provide httpd-wsgi3? Cheers, Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
On 2/21/20 9:10 PM, Niko Tyni wrote: > Hi Thomas, > > on IRC recently you said: > > 23:24 < zigo> If you're just answering about update-alternatives, then you > haven't paid attention to what I >wrote in the bug report. > 23:25 < zigo> And IMO, missing the point ... > > As I read the above, the systemd maintainers declined your suggestion to > add support for handling /usr/bin/systemd-sysusers with the alternatives > system, and you then requested the Technical Committee to overrule them. > > If this is not the case, could you please state clearly what you want > us to decide. > > Among other things, you later mention that a separate systemd-sysusers > package would be acceptable to you, pointing to #946456 . This avenue > doesn't seem to be exhausted yet? Hi, IMO, the question is a bit more hard than just "having packages that conflicts" or "using update-alternatives". As I think the issue is complicated, I would have like to have the tech ctte opinion on how to handle this case, for the Debian project at large. This is a general opinion that I'm asking for here, and guidance on how to set the policy for programs using systemd-sysusers, and the ones willing to (re-)implement the systemd interface to be used as an alternative implementation. It is my opinion that it's not good enough for the maintainer of systemd and systemd-sysusers to just decide, as every program using sysuser may be affected. Also please keep in mind that this is not only about sysusers, but a more broad scope (tmpfiles is concerned too... more may come!). Using update-alternatives for /bin/systemd-sysusers is what I thought was the best option, because cheap and easy to implement, with the nice advantage that we can have both packages installed at the same time, and programs can decide if they want a specific implementation or just any of them. However, if everyone is in the opinion that it's a bad idea, then I'm open to other solutions. Having systemd package systemd-sysusers (and systemd-tmpfiles) as separate package is also an option that would work. It's IMO annoying, because it takes a way longer to switch from one implementation to another, when update-alternatives instantly changes the configuration. We also loose the co-instability, and the fact that a given program can actively decide to use a specific implementation. But that still works too. However, packaging systemd-sysusers as a separate package it isn't as easy as one may think. See #946456 for the discussion. Using update-alternatives should have been a way easier. At the present moment, I'm not aware of any decision from the systemd maintainer, as this looks like not as easy as one may think. The only thing which I do *not* want to do, is using dpkg-divert. It is my strong opinion that this is a disservice to our users to do that, because dpkg-divert is rarely known, yet even understood by the average Debian users, so they wouldn't be able to even understand what happened to their system. We should be able to find a much nicer way to implement things. I'm also strongly against a /bin/sysusers which both programs would update-alternatives to, because then, we have a different implementation than on other platforms (this would be Debian specific). Cheers, Thomas Goirand (zigo)
Bug#949227: fixed in python-pysaml2 4.5.0-7
On 2/19/20 2:02 PM, Santiago Vila wrote: > On Wed, Feb 19, 2020 at 10:10:27AM +0100, Thomas Goirand wrote: > >> Thanks, but I don't need you to micro-manage the bugs in the BTS for me. > > I'm not really micro-managing anything for you. I'm just making sure > that the information in the BTS is correct. Not necessarily for you, > but for anybody working on QA issues (which may be anybody, not just you). > >> FYI, the package has been uploaded to security-master, and will soon >> reach the security repositories, which is why I didn't care much about >> this bug being closed (and I prefer it to be closed, so it isn't "on my >> way" when reviewing the team's bug list). > > Glad to know a fixed version has been uploaded to security, but I'm > sure there must be already some BTS tag for that (for example, "pending" > or "fixed"), which will help you to put bugs "outside your way" > without incorrectly closing them. > > There is a reason why we use the changelog as the preferred method to > close bugs: We do it to ensure that the bug is only closed when a > fixed version is actually available in the archive, so that bugs are > not closed in error. > > This is valid for unstable, but also for stable and for security. > > So, if you did a security upload and wrote a Closes statement in the > changelog, then the thing you should not care much is really about it > being open. > > Thanks. Santiago, Your lecturing is kind of frustrating. What you wrote above, I know it, and you are right and accurate. We simply have a difference in how we see things. Let me attempt to explain. You view the BTS as the state of things for packages. I view it as a helper for my maintainer's job. This is the source of many of the exchanges (and sometimes, disagreement) we had. I hope these words will help you understand that both yours and my point of view are valid, but very different. Though like it or not, in Debian, it is up to the maintainer to decide how to manage his bugs. I will not play BTS ping-pong (we both have better things to do), though I still would have prefer this bug to not be "on my way" when I review things I have to do on my packages, because at this point, I am considering my work on this specific issue as "done". Adding a pending tag could do, but that's more work, and precious time that I very much prefer wasting arguing with you :) (just joking...) Cheers, Thomas Goirand (zigo) P.S: Thanks for your work in Debian, and maintaining key packages for so long...
Bug#950063: influxdb-python FTBFS with pandas 0.25.3
Hi, I am hereby +1-ing what Andreas wrote. I also would like influxdb-python to be moved to the DPMT, and I am also volunteering to do the work, as I need influxdb-python for cloudkitty (ie: OpenStack resource rating as a service). Cheers, Thomas Goirand (zigo)
Bug#949227: fixed in python-pysaml2 4.5.0-7
On 2/18/20 1:26 PM, Santiago Vila wrote: > reopen 949227 > found 949227 4.5.0-4 > fixed 949227 4.5.0-7 > retitle 949227 python-pysaml2: FTBFS in buster because of expired certificate > thanks > > Reopening because packages in stable *must* build in stable. > In fact, it fails right now, without waiting to 2020-11-28. > > Error message says something like this: > > ToOld: Metadata not valid anymore, it's only valid until 2020-02-10T09:59:21Z > > Full log available here: > > https://tests.reproducible-builds.org/debian/rbuild/buster/amd64/python-pysaml2_4.5.0-4.rbuild.log.gz > > Thanks. > Santiago, Thanks, but I don't need you to micro-manage the bugs in the BTS for me. FYI, the package has been uploaded to security-master, and will soon reach the security repositories, which is why I didn't care much about this bug being closed (and I prefer it to be closed, so it isn't "on my way" when reviewing the team's bug list). Cheers, Thomas Goirand (zigo)
Bug#950063: Upstream patch fixes the problem
Hi, I have tried adding the upstream patches: https://github.com/influxdata/influxdb-python/commit/002a361fdb28852a6cb9ee7ccaae96a6a076fd1b.patch https://github.com/influxdata/influxdb-python/commit/b281445590145142c52112bfaf6a65142bd67de9.patch This fixes the problem. Alexandre, can I NMU the fix (which is, including these patches in the Debian packaging)? Cheers, Thomas Goirand (zigo)
Bug#951475: RM: python-functools32 -- ROM; Python 2 only, no use with Py3, no reverse (b-)deps
Package: ftp.debian.org Severity: normal Hi there! python-functools32 is a Python 2 backport of some Python 3 functionalities. We have therefore no use of it anymore if we remove Python2. Currently, it has no reverse dependencies in Sid, so it is time to remove it from Debian. It still has reverse depends in Testing (matplotlib2 and python-flake8), though these are probably just cruft. Thanks in advance, Cheers, Thomas Goirand (zigo)
Bug#931173: Configuring static networking via NoCloud with Network Config Version 2 does not work
On 2/13/20 12:44 PM, Christian Tramnitz wrote: > Is there any progress in getting 19.3 into stable? I can see it was not > part of the Buster 10.3 release. > If this takes any longer I'd suggest to backport the initially mentioned > patch. > > > BR, > Christian We currently don't have any answer from the release team, so we can't tell, really. Opening a new big will not help. Cheers, Thomas Goirand (zigo)
Bug#936806: koji: Python2 removal in sid/bullseye
On 2/14/20 2:30 AM, Holger Levsen wrote: > On Thu, Feb 13, 2020 at 08:14:11PM -0500, Sandro Tosi wrote: >> thanks! I'm gonna go ahead and file an RM bug for the following pkgs >> too: yum createrepo python-lzma yum-metadata-parser mock yum-utils >> dtc-xen deltarpm >> >> they are a closed set > > thank you for cleaning up after all of us, now that we reached containers. > (which used to be called virtualisation mainframes before... ;) > > I mean, rpm is definitly still useful to have on Debian, but yum and > friends??? I am the one that maintained yum for about a decade in Debian. Yum is (was?) useful because it does the same thing as debootstrap. Ie: with it, you can bootstrap a CentOS chroot from a Debian host, which may be useful for example if using Xen (or other virtualization systems). That was in fact my use case. Anyway, yum is kind of dead, as distros have been moving to dnf. I see therefore no reason to keep it. Cheers, Thomas Goirand (zigo)
Bug#950038: Looks like a bug in httplib2 rather than on wsgi-intercept
Hi, It looks like this bug is on httplib2. Indeed, it is the only place where I can read "tls_maximum_version", which is the "unexpected keyword argument" (this is *not* in wsgi-intercept). I'm therefore I'm reassigning the bug. Cheers, Thomas Goirand (zigo)
Bug#950942: python-oslo.reports: please make the build reproducible
On 2/8/20 4:31 PM, Chris Lamb wrote: > Source: python-oslo.reports > Version: 1.30.0-2 > Severity: wishlist > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: randomness > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > Hi, > > Whilst working on the Reproducible Builds effort [0] I noticed that > python-oslo.reports could not be built reproducibly. > > This was because the documentation (somewhat-uselessly) generated > documentation for the tests themselves, which revealed some MagicMock > special objects that had had a Python string representation containing > a nondetermistic number. > > For example: > > -MM_FILE = MagicMock > name='file_obj' id='139866970863568' > +MM_FILE = MagicMock > name='file_obj' id='140338508670736' > > Patch attached that simply skips the API documentation for the tests > from being generated in the first place. > > [0] https://reproducible-builds.org/ > > > Regards, > FYI, upstream already has this patch, somehow... So it will be included in the next upstream release. Thomas Goirand (zigo)
Bug#949322: python-pysaml2: CVE-2020-5390
On 1/19/20 9:05 PM, Salvatore Bonaccorso wrote: > Source: python-pysaml2 > Version: 4.5.0-5 > Severity: grave > Tags: security upstream > Justification: user security hole > Control: found -1 4.5.0-4 > > Hi, > > The following vulnerability was published for python-pysaml2. > > CVE-2020-5390[0]: > | PySAML2 before 5.0.0 does not check that the signature in a SAML > | document is enveloped and thus signature wrapping is effective, i.e., > | it is affected by XML Signature Wrapping (XSW). The signature > | information and the node/object that is signed can be in different > | places and thus the signature verification will succeed, but the wrong > | data will be used. This specifically affects the verification of > | assertion that have been signed. > > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2020-5390 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5390 > [1] > https://github.com/IdentityPython/pysaml2/commit/5e9d5acbcd8ae45c4e736ac521fd2df5b1c62e25 > > Please adjust the affected versions in the BTS as needed. > > Regards, > Salvatore > Hi Salvatore, Please find attached the debdiff for fixing this CVE. I've already uploaded the fix to Sid. Please let me know if it's ok to upload to buster-security. BTW, are source-only uploads fine for security-master? Cheers, Thomas Goirand (zigo) diff -Nru python-pysaml2-4.5.0/debian/changelog python-pysaml2-4.5.0/debian/changelog --- python-pysaml2-4.5.0/debian/changelog 2018-09-07 11:54:53.0 +0200 +++ python-pysaml2-4.5.0/debian/changelog 2020-02-07 09:27:20.0 +0100 @@ -1,3 +1,14 @@ +python-pysaml2 (4.5.0-4+deb10u1) buster-security; urgency=medium + + * CVE-2020-5390: does not check that the signature in a SAML document is +enveloped and thus signature wrapping is effective, i.e., it is affected by +XML Signature Wrapping (XSW). Applied upstream patch: Fix XML Signature +Wrapping (XSW) vulnerabilities (Closes: #949322). + * Remove a test file that will fail past 2020-11-28 (Closes: #949227). + * Add fix-importing-mock-in-py2.7.patch. + + -- Thomas Goirand Fri, 07 Feb 2020 09:27:20 +0100 + python-pysaml2 (4.5.0-4) unstable; urgency=medium * CVE-2017-1000246: Reuse of AES initialization vector in AESCipher / diff -Nru python-pysaml2-4.5.0/debian/patches/CVE-2020-5390_Fix_XML_Signature_Wrapping_XSW_vulnerabilities.patch python-pysaml2-4.5.0/debian/patches/CVE-2020-5390_Fix_XML_Signature_Wrapping_XSW_vulnerabilities.patch --- python-pysaml2-4.5.0/debian/patches/CVE-2020-5390_Fix_XML_Signature_Wrapping_XSW_vulnerabilities.patch 1970-01-01 01:00:00.0 +0100 +++ python-pysaml2-4.5.0/debian/patches/CVE-2020-5390_Fix_XML_Signature_Wrapping_XSW_vulnerabilities.patch 2020-02-07 09:27:20.0 +0100 @@ -0,0 +1,180 @@ +Author: Ivan Kanakarakis +Date: Sat, 4 Jan 2020 00:39:47 +0200 +Subject: CVE-2020-5390: Fix XML Signature Wrapping (XSW) vulnerabilities + PySAML2 did not check that the signature in a SAML document is enveloped and thus + XML signature wrapping (XSW) was effective. + . + The signature information and the node/object that is signed can be in different places + and thus the signature verification will succeed, but the wrong data will be used. This + specifically affects the verification of assertions that have been signed. + . + This was assigned CVE-2020-5390 + . + Thanks to Alexey Sintsov and Yuri Goltsev from HERE Technologies to report this. + . + + + + + + + + + + . + In more detail: + . + libxml2 follows the xmldsig-core specification. The xmldsig specification is way too + general. saml-core reuses the xmldsig specification, but constrains it to use of + specific facilities. The implementation of the SAML specification is responsible to + enforce those constraints. libxml2/xmlsec1 are not aware of those constraints and thus + process the document based on the full/general xmldsig rules. + . + What is happening is the following: + . + - xmldsig-core allows the signature-information and the data that was signed to be in + different places. This works by setting the URI attribute of the Reference element. + The URI attribute contains an optional identifier of the object being signed. (see + "4.4.3 The Reference Element" -- https://www.w3.org/TR/xmldsig-core1/#sec-Reference) + This identifier is actually a pointer that can be defined in many different ways; from + XPath expressions that need to be executed(!), to a full URL that should be fetched(!) + in order to recalculate the signature. + . + - saml-core section "5.4 XML Signature Profile" defines constrains on the xmldsig-core + facilities. It explicit
Bug#947238: Not giving any clue on how to reproduce
Hi, I've seen that this bug was the cause for keepalived to be removed from Testing. However, this bug was opened against keepalived in Stable. I've been using this version in production for nearly a year, and never experienced the same thing, everything just runs smoothly for me. So without giving any clue on how to reproduce the issue, I don't think this bug is relevant. I'm therefore reducing severity to "important". Cheers, Thomas Goirand (zigo)
Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020
On 2/2/20 1:06 PM, Thomas Goirand wrote: > On 2/1/20 10:51 AM, Stig Sandbeck Mathisen wrote: >> Thomas Goirand writes: >> >>> Could you list them? I'd be ok to do that work within the team, if >>> someone else is working on Puppet itself. >> >> >From the "puppet-agent" repository, at >> https://github.com/puppetlabs/puppet-agent/blob/6.4.x/configs/projects/puppet-agent.rb#L116 >> >> puppetlabs-augeas_core https://forge.puppet.com/puppetlabs/augeas_core >> puppetlabs-cron_core https://forge.puppet.com/puppetlabs/cron_core >> puppetlabs-host_core https://forge.puppet.com/puppetlabs/host_core >> puppetlabs-mount_core https://forge.puppet.com/puppetlabs/mount_core >> puppetlabs-sshkeys_core https://forge.puppet.com/puppetlabs/sshkeys_core >> puppetlabs-selinux_core https://forge.puppet.com/puppetlabs/selinux_core >> puppetlabs-yumrepo_core https://forge.puppet.com/puppetlabs/yumrepo_core >> puppetlabs-zfs_core https://forge.puppet.com/puppetlabs/zfs_core >> puppetlabs-zone_core https://forge.puppet.com/puppetlabs/zone_core >> puppetlabs-scheduled_task https://forge.puppet.com/puppetlabs/scheduled_task >> >>>> From a user point of view, the missing modules mainly shows up when >>>> doing rspec module testing. >>> >>> So, we're talking about Ruby stuff? >> >> The resource types and provides are written in ruby, but distributed as >> puppet modules. >> >> When testing puppet modules, and your code use the "cron", "host", >> "mount" (from the list above) resource types, they need to be present. >> >> The resource types are present in the puppet 5 source repository, while >> in puppet 6, they are maintained as separate puppet modules in their own >> repositories, and we would need to add them as packaged dependencies. >> >> -- >> Stig Sandbeck Mathisen >> Debian Developer >> > > FYI, I packaged and uploaded the first 2 so far, but can't push to Git. > Please set me as maintainer or owner, so I can do that. > > Note that I'm doing a git based workflow, packaging upstream tags, > rather than using pristine-tar. If this bothers anyone, please let me > know (but please only complain about the workflow if you really have the > intention to contribute to the packaging, otherwise you're just getting > on my way to be efficient for no reason). > > Cheers, > > Thomas Goirand (zigo) Heya, I'm not sure who did it, but I do have the "maintainer" rights on Gitlab, so everything looks fine to me. I have built and uploaded: puppetlabs-augeas_core https://forge.puppet.com/puppetlabs/augeas_core puppetlabs-cron_core https://forge.puppet.com/puppetlabs/cron_core puppetlabs-host_core https://forge.puppet.com/puppetlabs/host_core puppetlabs-mount_core https://forge.puppet.com/puppetlabs/mount_core puppetlabs-sshkeys_core https://forge.puppet.com/puppetlabs/sshkeys_core puppetlabs-selinux_core https://forge.puppet.com/puppetlabs/selinux_core The others are related to other operating systems than Debian, so I really wonder if we need them (yum, really? zfs and zone are for Solaris, and scheduled_task is for windows...). Augeas and Cron are already in Sid. I wonder if the FTP masters are in the need for these... :P Cheers, Thomas Goirand (zigo)
Bug#950530: ITP: puppet-module-puppetlabs-selinux-core -- Puppet module for SELinux
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: puppet-module-puppetlabs-selinux-core Version : 1.0.4 Upstream Author : Puppet Labs INC. * URL : https://github.com/puppetlabs/puppetlabs-selinux_core * License : Apache-2.0 Programming Lang: Puppet, Ruby Description : Puppet module for SELinux Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This module manages SELinux context of files. Note: This used to be embedded in Puppet 5, and needs to be packaged separately for Puppet 6.
Bug#950529: ITP: puppet-module-puppetlabs-sshkeys-core -- Puppet module for managing SSH authorized_keys, and ssh_known_hosts files
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: puppet-module-puppetlabs-sshkeys-core Version : 1.0.3 Upstream Author : Puppet Labs INC * URL : https://github.com/puppetlabs/puppetlabs-sshkeys_core * License : Apache-2.0 Programming Lang: Puppet, Ruby Description : Puppet module for managing SSH authorized_keys, and ssh_known_hosts files Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This puppet module Manages SSH authorized_keys, and ssh_known_hosts files. Note: This used to be part of Puppet 5, and is not packaged separately, so we can package Puppet 6.
Bug#950528: ITP: puppet-module-puppetlabs-mount-core -- Puppet module for managing mount points
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: puppet-module-puppetlabs-mount-core Version : 1.0.4 Upstream Author : Puppet Labs * URL : https://github.com/puppetlabs/puppetlabs-mount_core * License : Apache-2.0 Programming Lang: Puppet, Ruby Description : Puppet module for managing mount points Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . The mount_core module manages mounted filesystems and mount tables. . The module can mount and unmount filesystems, and manage mount tables such as /etc/fstab, /etc/vfstab, or /etc/filesystems depending on your operating system. . Mount resources can respond to refresh events, and can remount a filesystem in response to an event from another resource. . Mount resources automatically create relationships with directories that are either ancestors of the mounted directory or children. This way Puppet will automatically create ancestor directories before the mount point, and will do that before managing directories and files within the mounted directory. Note: This used to be embedded in Puppet 5, and this will be needed for Puppet in version 6.
Bug#950497: ITP: puppet-module-puppetlabs-host-core -- Puppet module for managing /etc/hosts file
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: puppet-module-puppetlabs-host-core Version : 1.0.3 Upstream Author : Puppet labs Inc. * URL : https://github.com/puppetlabs/puppetlabs-host_core * License : Apache-2.0 Programming Lang: Puppet, Ruby Description : Puppet module for managing /etc/hosts file Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . The host_core module is used to manage host entries in a hosts file. For most systems, the hosts file is located in /etc/hosts. Note: this package will be needed for puppet 6, which is not embedding this code anymore.
Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020
On 2/1/20 10:51 AM, Stig Sandbeck Mathisen wrote: > Thomas Goirand writes: > >> Could you list them? I'd be ok to do that work within the team, if >> someone else is working on Puppet itself. > >>From the "puppet-agent" repository, at > https://github.com/puppetlabs/puppet-agent/blob/6.4.x/configs/projects/puppet-agent.rb#L116 > > puppetlabs-augeas_core https://forge.puppet.com/puppetlabs/augeas_core > puppetlabs-cron_core https://forge.puppet.com/puppetlabs/cron_core > puppetlabs-host_core https://forge.puppet.com/puppetlabs/host_core > puppetlabs-mount_core https://forge.puppet.com/puppetlabs/mount_core > puppetlabs-sshkeys_core https://forge.puppet.com/puppetlabs/sshkeys_core > puppetlabs-selinux_core https://forge.puppet.com/puppetlabs/selinux_core > puppetlabs-yumrepo_core https://forge.puppet.com/puppetlabs/yumrepo_core > puppetlabs-zfs_core https://forge.puppet.com/puppetlabs/zfs_core > puppetlabs-zone_core https://forge.puppet.com/puppetlabs/zone_core > puppetlabs-scheduled_task https://forge.puppet.com/puppetlabs/scheduled_task > >>> From a user point of view, the missing modules mainly shows up when >>> doing rspec module testing. >> >> So, we're talking about Ruby stuff? > > The resource types and provides are written in ruby, but distributed as > puppet modules. > > When testing puppet modules, and your code use the "cron", "host", > "mount" (from the list above) resource types, they need to be present. > > The resource types are present in the puppet 5 source repository, while > in puppet 6, they are maintained as separate puppet modules in their own > repositories, and we would need to add them as packaged dependencies. > > -- > Stig Sandbeck Mathisen > Debian Developer > FYI, I packaged and uploaded the first 2 so far, but can't push to Git. Please set me as maintainer or owner, so I can do that. Note that I'm doing a git based workflow, packaging upstream tags, rather than using pristine-tar. If this bothers anyone, please let me know (but please only complain about the workflow if you really have the intention to contribute to the packaging, otherwise you're just getting on my way to be efficient for no reason). Cheers, Thomas Goirand (zigo)
Bug#950480: ITP: puppet-module-puppetlabs-cron-core -- Puppet module for installing and managing cron resources
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: puppet-module-puppetlabs-cron-core Version : 1.0.3 Upstream Author : Puppet labs Inc. * URL : https://github.com/puppetlabs/puppetlabs-cron_core * License : Apache-2.0 Programming Lang: Puppet, Ruby Description : Puppet module for installing and managing cron resources Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . The cron_core module installs and manages cron resources. Note: This package is needed to transition to the Puppet 6 release.
Bug#950475: ITP: puppet-module-puppetlabs-augeas-core -- Puppet module for Augeas Core
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: puppet-module-puppetlabs-augeas-core Version : 1.0.5 Upstream Author : Puppet Labs * URL : https://github.com/puppetlabs/puppetlabs-augeas_core * License : Apache-2.0 Programming Lang: Puppet, Ruby Description : Puppet module for Augeas Core Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . The augeas_core module is used to manage configuration files using Augeas. This module is suitable for any host for which there are Augeas libraries and ruby bindings. Note: This package will be needed to switch to Puppet 6, as Puppet 5 and lower used to have it embedded.
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/30/20 8:18 PM, Anthony DeRobertis wrote: > On 1/30/20 7:02 AM, Thomas Goirand wrote: >> This is normally solved if using pre-depends, which ensure that a >> package is configured before using it (and not just unpacked). > > Having everything using sysusers have versioned Pre-Depends on systemd | > opensysusers would probably minimize the problem, but could potentially > be a fair number of Pre-Depends to add. (I have no idea if non-versioned > Pre-Depends on a virtual package works, if so that'd be better. If not, > it'd also require adjusting them all if another alternative is introduced.) I wrote that it could be a solution to the said problem, but I am really not convince there's a problem at all. Thomas
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/30/20 7:16 AM, Anthony DeRobertis wrote: > There are some more that come to mind: > > * if we convert the exiting name to an alternative, there is the > somewhat interesting work of actually changing a file over from an > executable shipped in the package to an alternative, which would > normally be set up by postinst. That could leave an uncomfortably > large window during upgrade where the system would be broken (and > possibly not boot) if interrupted. This is normally solved if using pre-depends, which ensure that a package is configured before using it (and not just unpacked). > * if we use a new, different name, then we've introduced a > Debian-specific interface. One of the nice things about most of the > Linux world standardizing on systemd is increased cross-distro > compatibility; here we'd be breaking it. That's exactly what made me think that using the original name was less Debian wide work indeed. Though because of the binary name prefixed with "systemd-" this is less elegant than standardizing on /bin/sysusers. Cheers, Thomas Goirand (zigo)
Bug#950182: [Pkg-puppet-devel] Bug#950182: Puppet 5.5 EOL in November 2020
On 1/30/20 7:23 AM, Stig Sandbeck Mathisen wrote: > Antoine Beaupre writes: > >> ... the upgrade from 5 to 6 doesn't involve much churn in the DSL, so >> it's not as big of a deal as the 3 to 4 or 4 to 5 migrations we had to >> suffer through. The tooling does change, however, so it might be >> tricky on the packaging side (which is why, I am guessing, P6 is not >> yet in Debian). > > The biggest difference I've seen between Puppet 5 and 6 is that many > previously built-in resource types have moved from the puppet repository > to external modules. Puppet include those in their own packaging. We > will have to package those as well, and add them as dependencies. Could you list them? I'd be ok to do that work within the team, if someone else is working on Puppet itself. > From a user point of view, the missing modules mainly shows up when > doing rspec module testing. So, we're talking about Ruby stuff? Cheers, Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 8:19 PM, Simon McVittie wrote:
> - Linux systems not booted with systemd
> (either no init system at all, like a typical schroot or Docker
> container, or a non-systemd init system like sysvinit)
This is very much one type of systems I have in mind, yes, and
open{sysusers,tmpfiles} could help to make them smaller. Just pulling
the whole systemd stack to add system users seems too much for very
little benefits.
> I think we have a fairly good picture of the costs that would be
> incurred from using alternatives: more interacting code paths to test,
> potentially more configurations that are technically possible but are
> not considered supported, and packages with "Depends: systemd (>= 321)"
> (or indeed systemd itself, in the case of systems using it to boot)
> not being able to rely on having access to all systemd 321 features,
> which doesn't seem like a least-astonishment situation to be in. However,
> Michael, or anyone else opposing this change: if you have anything to
> add to those, please do.
We don't need to do "Depends: systemd (>= 321)", we could have a virtual
package provided by both implementations.
Cheers,
Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 4:49 PM, Didier 'OdyX' Raboud wrote: > Le mercredi, 29 janvier 2020, 16.07:21 h CET Thomas Goirand a écrit : >> This reasoning can make sense, if we agree that we should use something >> else than /bin/systemd-sysusers and standardize on something else like >> /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is >> *the* way to do things, and using /bin/systemd-sysusers becomes a bug of >> severity "serious" (policy violation). > > We'd first have to agree that an alternative is actually _needed_. And so > far, > the only arguments I have read in favour of providing alternatives to > /bin/systemd-sysusers are: > * A) it is shipped in the systemd binary package; > * B) Having competing implementations is important; > * C) it comes from the systemd project; > * D) it has a systemd-* name; Very much, B for me... I don't want to see Debian stuck in a position where we are locked-in. This is my main motivation. C and B are distractions that I'm not at all diving into. A is annoying, because that imposes micro-packaging on systemd maintainers (a 200k+ package for just this simple feature? really?), and we try to avoid this project-wide. Thomas
Bug#947847: please install systemd-sysusers using update-alternatives
my thing (I'm not so much interested in kFreeBSD or Hurd...). I do like the fact though, that maybe one day OpenRC will implement the parsing of .service files as Xu told about, and then it can become nice to have opensysusers and opentmpfiles. On 1/29/20 7:29 PM, Gunnar Wolf wrote: > I mean - We should encourage people to use /bin/sysusers. Now, if > systemd-sysusers grows a piece of functionality that open-sysusers > is not willing to adopt (or vice versa) Thanks for considering the "or vice versa" possibility!!! :) > following past examples, I > believe a package set to predepend on systemd-sysusers should be able > to call /bin/systemd-sysusers — And a package set to predepend on > open-sysusers can do likewise. This feels reasonable to me. Even better if this goes into the policy. I've read many telling about a potential new functionality that would not be implemented here or there. However, my guts feeling is that this feels like a kind of stable API that isn't intended to grow very much, and hopefully, will be of low maintenance. Let's see what the future shows... Cheers, Thomas Goirand (zigo) P.S: Just a quick digression: I really dislike the fact that I've constantly read people saying "what if opensysusers lags behind". And what about if I decide to contribute a super nice functionality that systemd-sysusers authors didn't think about? Could everyone at least attempt to consider that this is a possibility as well? That innovation doesn't come *only* from systemd? Also, best would be if we keep both compatible, and hopefully, this will be the case over a long period of time.
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 1:50 PM, Raphael Hertzog wrote: > On Wed, 29 Jan 2020, Thomas Goirand wrote: >> echo 'u radvd - "radvd daemon"' | \ >>systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf > > Does opensysusers support this use case? Yes it does. > There's no need to predict the future, you must analyze the > current situation and go forward from there. Of course we are planning for the future. Let's say an important feature appears to be needed (this is just a point or argumentation at this time, please everyone: don't add unnecessary FUD), then of course, it's always possible to fill the gap and implement the missing feature. The clear goal is for opensysusers to become a full replacement of the systemd implementation. > As for the > service creating users during boot, you can provide a debconf > question giving the option to the user to install an override > of systemd-sysusers.service which actually calls opensysusers. The intend is for opensysusers to be a full replacement, I don't see why we should bother users with some annoying debconf prompt that they probably wont be able to understand without a an extensive knowledge of the situation. > And when we get to the point where the lack of systemd-sysuvers is a > problem, we can always patch programs to use /bin/create-system-users > instead of systemd-sysusers. I'm unsure what your above proposal is, so let's expand a little bit. Sorry if it appears I'm distorting your words (that's not the intent). This reasoning can make sense, if we agree that we should use something else than /bin/systemd-sysusers and standardize on something else like /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is *the* way to do things, and using /bin/systemd-sysusers becomes a bug of severity "serious" (policy violation). However, imposing everyone (for current or future use of sysusers) to handle a specific case for opensysusers is IMO *not* the way to go. And this is the very point of this bug entry. Cheers, Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 11:34 AM, Raphael Hertzog wrote: > On Tue, 28 Jan 2020, Thomas Goirand wrote: >> This is exactly what should be avoided. It's perfectly fine to try to >> use opensysusers with systemd if one wants. In fact, that's exactly the >> best way we could do to be able to test it. Also, dpkg-divert is really >> ugly, and something you use as the last resort, when all other options >> have been exhausted. > > It's not that ugly if you consider that you are in an experimental phase > where you want to test opensysusers. > > Also you seem to imply that the common interface is the systemd-sysusers > binary. I don't think that this is necessarily the case. The common > interface is the file format. The name of the program creating the users > is not important as long as it's properly hooked in the packaging system > and boot sequence. Hi Raphael, I'm replying to you, but it goes also for Phillip Kern too, which had a similar answer. My idea is to have a single entry point for programs to call the sysusers binary. If we collectively decide that it's going to be called /bin/foo, then by all means, let's do that. But I don't think it's reasonable to say it's going to be called /bin/systemd-bar, and nobody can take over this path. This is the wrong answer to the problem. I do agree that the data file is the interface, but can you predict *ALL* the cases where /bin/systemd-sysusers is called? As much as I understand, it could be called by: - something debhelper adds to postinst - something the maintainer adds manually to postinst - the init system itself And more disturbingly, it could be called by any program that just wants to add a user the same way one would just call useradd or adduser. The man page for systemd-sysusers even gives a very clear example: echo 'u radvd - "radvd daemon"' | \ systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf which clearly, looks like something someone would write in a shell script, manually calling /bin/systemd-sysusers, from anywhere, maybe even from a running program / daemon (I haven't seen any designed limitation, have you?). So I am in the opinion that "as long as it's properly hooked in the packaging system and boot sequence" simply doesn't work in this case, as systemd-sysusers could be called from virtually anywhere. As for the use of dpkg-divert, as you wrote above, it's ok for experimentation, but I do think it's making a disservice to our users to use that as the proper interface to implement. The update-alternatives has the very nice advantage that it clearly shows the current status of the system, and that it can be very easily tweaked, by hand or by some kind of automation. It's also super easy to go from one state of the system to another, compared to reinstalling / uninstalling a package. Cheers, Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
Anthony DeRobertis
> It's different than awk because the decision the admin is making
> ("which init system do I want to run"?) isn't done through
> alternatives. So you can't use the alternatives system to coordinate
> swapping all the different bits together.
You are mixing things here. We are *not* talking about init systems, but
about sysusers, which can be used with any init systems.
> It seems retty reasonable to me that the systemd maintainers don't
> want to support systems which are running arbitrary combinations of
> systemd with alternatives to some parts.
Absolutely nobody is asking them to do that. I'm just asking for a
solution to easily replace /bin/systemd-sysusers. There are 2 solutions,
one is to have /bin/systemd-sysusers packaged separately, though this
would probably be micro-packaging, which I'm not a fan of. The other
solution is to use update-alternatives. I'm fine with both solution, I
just don't think it's fine to say "get away, my implementation is
better", and leave no reasonable solution to install something else.
> Strikes me as there is a possible solution, though: have opensysusers
> dpkg-divert it and put a shell script in its place that checks which
> init system is running, and exec's the right sysusers based on that.
This is exactly what should be avoided. It's perfectly fine to try to
use opensysusers with systemd if one wants. In fact, that's exactly the
best way we could do to be able to test it. Also, dpkg-divert is really
ugly, and something you use as the last resort, when all other options
have been exhausted.
> This wouldn't affect systemd-only machines (as opensysusers would not
> be installed at all), and would do the right thing if someone has
> installed two init systems to, e.g., consider switching.
Again, you are mixing things (ie: what type of init system and
re-implementation of an independent component of systemd). We should be
able to allow to run opensysusers if systemd is running (exactly, why
not?). This is desirable, at least for testing. It would also be
desirable to use systemd-sysusers with other init system if one wants
(also: why not?).
> It'd need to be a script that the systemd maintainers feel reasonably
> confident will always run systemd's implementation when systemd is
> running, to avoid the mixed implementations issue.
Not at all. Systemd maintainers have no say if someone wishes to
implement things in another way, the same way there's gawk and mawk,
implementing the same thing. If we don't allow such things, then really,
Debian is doomed.
I am not buying into the "we will have wrong bug reports" argument. We
constantly get many types of wrong reports in the BTS. We just shall do
sensible bug triaging in a correct way, that's it.
Cheers,
Thomas Goirand (zigo)
P.S: Note that this bug also concerns systemd-tmpfiles, the very exact
same way, though I believe one single bug is enough to address both
cases which are similar.
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/25/20 5:05 PM, Michael Biebl wrote: > Control: tags -1 + wontfix > > Hi Thomas > > On Tue, 31 Dec 2019 17:29:29 +0100 Thomas Goirand wrote: >> Package: systemd >> Version: 244-3 >> Severity: important >> >> Hi, >> >> As I'm packaging opensysusers (see ITP: #947846), I would like my >> package to also provide /bin/systemd-sysusers. Please install this >> binary on another location, so that both systemd and opensysusers can >> implement it. I am very much fine to have systemd have the priority over >> opensysusers if you believe it should (I'm open to discussion about >> priorities). > > Thanks for your interest in systemd-sysusers. > After thinking more about this, I don't consider renaming > systemd-sysusers and installing it via alternatives as a good idea. > > When systemd is installed and used, we definitely want to use its own > implementation. > > My recommendation would be to install the opensysusers implementation > under a different binary name. > > Alternative init systems can then decide to support sysusers by calling > that opensysusers binary during boot. > debhelper, should it get sysusers support, should generate code which > calls the correct binary depending on the current circumstances. > > Regards, > Michael > > > Hi Michael, It is my view that what you're proposing would be a lot more work for on valid reason. I'm therefore re-assigning the bug to the tech-ctte, asking them to decided instead. It is my view that using update-alternatives is *very* easy to implement, so that we can share the /usr/bin/systemd-sysuser location. Besides the fact that, with the way you're suggesting, we'd need to fix debhelper (which I don't think is reasonable, as it wont be the only place to handle multiple cases, I'm foreseeing...), there's also the concern that you don't seem to agree that it'd be ok for one to use opensysuser instead of the systemd implementation if systemd is running. I do not agree with this, and I believe it is up to the users to decide what to do, even if we, as an operating system, must provide sensible defaults (which also can be discussed, but that's not the point of this bug report). Moreover, I don't see why /usr/bin/systemd-sysusers would be any different from let's say /usr/bin/awk. The update-alternatives system is there exactly to handle the case we're facing today. So, tech-ctte, please decide. Cheers, Thomas Goirand (zigo)
Bug#949845: Constant 100% CPU usage by ovs-vswitchd
On 1/25/20 8:33 PM, Kees Meijs wrote: > Is upgrading to 2.11 in stable a viable option? No it's not. The release team wont let this happen. > (The backports team felt > this bug is severe enough and the upgrade is only very minor.) Uploading to stable-backports is *not* the way to fix bugs in Debian stable. The way to fix bugs in stable is ... to fix bugs in stable! :) Have you investigated to know which upstream patch fixed the issue, so that we could backport that single patch instead? Cheers, Thomas Goirand (zigo)
Bug#949859: google-apputils-python: should this package be removed?
On 1/26/20 7:02 AM, Sandro Tosi wrote: > Source: google-apputils-python > Severity: serious > > Hello, > i think we should remove google-apputils-python from debian: > > * last upstream release in 2014 > * upstream marked[1] it as "Obsolete. Please migrate to absl-py instead." > * no reverse dependencies for both py2 and py3 packages > * RC-buggy since a year and a half with no action on a (simple?) bug > > [1] https://pypi.org/project/google-apputils/ > > If i dont hear back within a week with a good reason to keep this package, > i'll > file for its removal. > > Regards, > Sandro I agree with this. Thomas
Bug#949227: This was fixed
Hi, I tried rebuilding the package, and it looks like the latest upload fixed the issue (I could build the package without any problem). If you believe I'm wrong, please reopen and let me know. Cheers, Thomas Goirand (zigo)
