Bug#725373: python-tg.devtools should depends on python-babel and not python-pybabel
Package: python-tg.devtools Version: 2.0.2-3 Severity: serious Hi, I would like to remove python-pybabel from the archive, as this is a transitional package. Please switch to python-pybabel for your dependency. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131004185723.28073.22937.report...@buzig.gplhost.com
Re: SQLAlchemy 0.9.X in unstable
CC-ing the release team, since I think you should have coordinate with them here. On 02/23/2014 11:58 PM, Piotr Ożarowski wrote: > Hi guys, > > I just uploaded sqlalchemy 0.9.3 to unstable Noo !!! Man, this is a COMPLETE DISASTER for me. Don't do this again without any coordination! This *will* break about everything in OpenStack. I'm just recovering from the last upload of SQLAlchemy 0.8.x which you did last July without any coordination, yet you're doing it again. It took about 7 months for upstream to do the switch, and during a full release cycle, I had lots and lots of troubles. > (0.9.1 and 0.9.2 was only > in experimental). I've set urgency to low to give it a bit more time > before if migrates to testing. I would also submit a RC bug against it, because this needs a transition, and preferably managed by the release team. > Please check if your package works fine with 0.9 and let me know if it > doesn't. I'm letting you know. You have just broke: - ceilometer - cinder - glance - heat - keystone - neutron - nova - trove - taskflow Plus those not released yet but already packaged on Alioth, but which I was planning on uploading "soon": - ironic - tuskar - designate All of the above is using SQLA 0.8.x, and upstream isn't planning on doing the switch to 0.9.x before next April at least (schedule release of Icehouse). Are you going to help patching the upstream code for them? I don't think so... :( Note that OpenStack Icehouse will be in feature freeze early next month, and that I don't think I can ask for an upgrade of everything to SQLAlchemy 0.9. If you were doing this at the beginning of a release cycle (which happens every 6 months), maybe that could be accepted upstream, but not like this, just before the feature freeze. > If the dependency on python-sqlalchemy was generated by dh_python2, you > already have "python-sqlalchemy (<< 0.9)" in Depends. If your package > works fine with 0.9.X, just rebuild it with the one in unstable - > dh_python2 will generate "<< 0.10" That's realistically going to break everything, and rebuilding will not fix anything. I haven't checked yet, but I know upstream did in the CI, and it broke. Also, sqlalchemy-migrate doesn't currently work with SQLA 0.9. See upstream working on it: https://review.openstack.org/#/c/66156/ I don't think it's reasonable to upload SQLA if SQLA-migrate doesn't support version 0.9.x. > Migration notes: > * http://docs.sqlalchemy.org/en/rel_0_9/changelog/migration_09.html or > * /usr/share/doc/python-sqlalchemy-doc/rst/changelog/migration_09.txt or > * /usr/share/doc/python-sqlalchemy-doc/html/changelog/migration_09.html The issues I'm talking about will not simply be fixed by reading the above. The procedure to get things fixed in OpenStack are long, and probably will not be workable before the next release. Please revert this upload immediately (with an EPOC) and until other packages have reasonable upstream support for it. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/530a23e2.9080...@debian.org
Bug#1053169: Please remove librbd-dev build-depends on all 32 bits arch
Source: tcmu Version: 1.5.4-4.1 Severity: important Hi, I'd like to remove 32 bits support from Ceph, because upstream makes some 64 bits assumptions a bit everywhere, because it's not tested in upstream CI, and because it is increasingly difficult to build Ceph on a smaller addressing footprint (we used to have many tricks to reduce the build footprint that isn't sustainable in the long run). So please remove librbd-dev in build-depends of your package for all 32 bits arch, and remove Ceph support in all 32 bits binaries. I'll upload Ceph with Build-Depends: architecture-is-64-bit as soon as this is done for the 4 affected packages: - fio - libvirt - tcmu - qemu Cheers, Thomas Goirand (zigo)
Bug#689896: Ships a folder in /var/run or /var/lock (Policy Manual section 9.3.2)
Package: lastfmsubmitd
Version: 1.0.6-3
Severity: serious
Tags: patch
Dear Maintainer,
Andreas Beckmann reported in -devel that your package
(as well as 27 others) ships a folder either in /var/run or /var/lock. This
is forbidden by policy.
Lintian detects the problem and warns as follow:
/var/run may be a temporary filesystem, so any directories or files needed
/there must be created dynamically at boot time.
Refer to Debian Policy Manual section 9.3.2 (Writing the scripts) for
details.
Severity: serious, Certainty: possible
Check: files, Type: binary, udeb
which is why I am reporting this bug with severity serious (and there fore,
release critical).
Please fix your package. I have attached what I believe is a good fix the
problem, however, I haven't tried it, and I haven't tested if something more
for creating the necessary folder at runtime should be added. Please make
sure to test before applying the patch blindly.
Cheers,
Thomas Goirand (zigo)
diff -u lastfmsubmitd-1.0.6/debian/lastfmsubmitd.dirs lastfmsubmitd-1.0.6/debian/lastfmsubmitd.dirs
--- lastfmsubmitd-1.0.6/debian/lastfmsubmitd.dirs
+++ lastfmsubmitd-1.0.6/debian/lastfmsubmitd.dirs
@@ -2,3 +2,2 @@
var/log/lastfm
-var/run/lastfm
var/spool/lastfm
diff -u lastfmsubmitd-1.0.6/debian/lastmp.init.d lastfmsubmitd-1.0.6/debian/lastmp.init.d
--- lastfmsubmitd-1.0.6/debian/lastmp.init.d
+++ lastfmsubmitd-1.0.6/debian/lastmp.init.d
@@ -23,6 +23,14 @@
exit 0
fi
+if [ ! -d ${RUNDIR} ] ; then
+ mkdir -p ${RUNDIR} || true
+ if [ -d ${RUNDIR} ] ; then
+ chown ${USER}:${GROUP} ${RUNDIR}
+ chmod 2775 ${RUNDIR}
+ fi
+fi
+
case "$1" in
start)
echo -n "Starting $DESC: "
diff -u lastfmsubmitd-1.0.6/debian/lastfmsubmitd.init.d lastfmsubmitd-1.0.6/debian/lastfmsubmitd.init.d
--- lastfmsubmitd-1.0.6/debian/lastfmsubmitd.init.d
+++ lastfmsubmitd-1.0.6/debian/lastfmsubmitd.init.d
@@ -21,6 +21,14 @@
exit 0
fi
+if [ ! -d ${RUNDIR} ] ; then
+ mkdir -p ${RUNDIR} || true
+ if [ -d ${RUNDIR} ] ; then
+ chown ${USER}:${GROUP} ${RUNDIR}
+ chmod 2775 ${RUNDIR}
+ fi
+fi
+
case "$1" in
start)
echo -n "Starting $DESC: "
diff -u lastfmsubmitd-1.0.6/debian/changelog lastfmsubmitd-1.0.6/debian/changelog
--- lastfmsubmitd-1.0.6/debian/changelog
+++ lastfmsubmitd-1.0.6/debian/changelog
@@ -1,3 +1,10 @@
+lastfmsubmitd (1.0.6-3.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fixes bad handling of /var/run/lastfm life cycle (Closes: #XX).
+
+ -- Thomas Goirand Sat, 06 Oct 2012 18:41:00 +0800
+
lastfmsubmitd (1.0.6-3) unstable; urgency=low
* QA upload.
diff -u lastfmsubmitd-1.0.6/debian/lastfmsubmitd.postinst lastfmsubmitd-1.0.6/debian/lastfmsubmitd.postinst
--- lastfmsubmitd-1.0.6/debian/lastfmsubmitd.postinst
+++ lastfmsubmitd-1.0.6/debian/lastfmsubmitd.postinst
@@ -45,7 +45,7 @@
db_get lastfmsubmitd/spool_group
if [ "$RET" ]; then
-for dir in /var/log/lastfm /var/run/lastfm /var/spool/lastfm; do
+for dir in /var/log/lastfm /var/spool/lastfm; do
chown "lastfm:$RET" $dir
chmod 2775 $dir
done
Bug#706101: License problem with qpid-python
Dear QPID maintainers, Jonas Smedegaard just sent a bug report on the Debian bug tracker, because he believes that the qpid-python package in Debian is non-free: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706101 Indeed, when having a look in the sepcs/* folder, we can see a LICENSE file which contains both the Apache-2.0 and AMQP license. Though nearly all files in that folder contains only the AMQP license header. So it is not clear at all under which license these files are. And if they are only licensed under the AMQP license, then they are non-free in the eyes of Debian (the AMQP license isn't suitable for Debian). If this issue isn't solved quickly, then the package will have to be removed from Debian. Also, since Debian Wheezy will be out this week-end, a lightning fast answer from you would be really appreciated. Best case would be if we could solve this problem before the release. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517fd0a6.10...@goirand.fr
Bug#706101: Do not just rush to remove the package please
Hi, Considering that: 1/ this package comes from: http://qpid.apache.org/ which leads me to believe that it is very unlikely that the author wish to release some non-free work. If there is a license problem, then it is very likely that it will be fixed, and the license clarified. 2/ in specs/LICENSE we can see 2 license, Apache-2.0 and AMQP, which leads me to believe that the intention is that the files under specs/* are licensed under a dual-license, then I don't think it is reasonable to just rush so fast to remove this package. If there really is a problem with this package, then it will go away, that's for sure. But please allow a reasonable delay so that we get enough time to get in touch with upstream author to clarify the situation. The release of Wheezy in few days is *not* a valid reason to just blindly remove the package without trying to understand what went on, or to cleanly fix the problem. We had this kind of issues in the past, and it wasn't a problem, as long as it was addressed. I am taking care of asking upstream. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517fcdd8.6010...@debian.org
Bug#706101: Upstream mistake
Hi, Ghe Rivero got in touch with them on IRC. He just wrote to me: "acording to ssorj on irc, it's a mistake and will try to sort it out asap". So please do not just remove this package just yet, as the situation is being clarified by upstream. Thomas -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5180af72.5050...@debian.org
Re: Processed: Re: Bug#587575: mock broken due to its sub components exit with python exception
Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > >> reassign 587575 yum,urlgrabber > Bug #587575 [mock] mock broken due to its sub components exit with python > exception > Bug reassigned from package 'mock' to 'yum,urlgrabber'. > Bug No longer marked as found in versions mock/1.0.8-1. >> found 587575 yum/3.2.25-1 > Bug #587575 [yum,urlgrabber] mock broken due to its sub components exit with > python exception > Bug Marked as found in versions yum/3.2.25-1. >> found 587575 urlgrabber/3.9.1-3 > Bug #587575 [yum,urlgrabber] mock broken due to its sub components exit with > python exception > Bug Marked as found in versions urlgrabber/3.9.1-3. >> affects 587575 mock > Bug #587575 [yum,urlgrabber] mock broken due to its sub components exit with > python exception > Added indication that 587575 affects mock >> thanks > Stopping processing here. > > Please contact me if you need assistance. Hi, What's that, and how could I fix? Do you think that upgrading to the latest version of yum (which, the last time I saw, is 3.2.26) would fix the issue? Is Fedora 13 running python 2.6? And what version of yum? Thomas -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c2c439b.8080...@debian.org
Re: [PKG-Openstack-devel] Python3 and Lua bindings split out of the LXC packages
On 10/31/2016 11:23 PM, Evgeni Golov wrote: > Ohai, > > your package currently has a "Depends: lxc" in Debian. > > My short analysis told me that this is because that it uses one of the lxc-* > binaries we ship in there. If it is the case: carry on, happy hacking and > thanks for using/supporting LXC :) > > If not (or not only): we have split out the Python3 and Lua bindings from > the main lxc package into python3-lxc and lua-lxc. So if you only need the > bindings, you can switch the Depends accordingly. What about Python 2 support? What provides it? To me, it looks like OpenStack's Nova uses lxc through libvirt only. There's also lxd support, but this isn't available in Debian. As I've read the thread about it, I'm waiting on others to do the work, but I'd be happy to give a hand if needed. Cheers, Thomas Goirand (zigo)
Update for SQLAlchemy to address CVE-2019-7164 CVE-2019-7548
Dear package maintainer, We're about to upgrade SQLAlchemy in Buster to address an SQL injection issue. The fixed package is in unstable, under the version 1.2.18+ds1-2. In some rare cases, this update may break reverse depenencies, leading to non-working SQL queries. This is why I'm writing this email to you today: to ask you to please test your application with SQLAlchemy 1.2.18+ds1-2 ASAP, to address any potential unforecast issue before the Buster release. Details about the discussion can be seen here in the Debian bug #929321. Best regards, Thomas Goirand (zigo)
Bug#936189: Packages depending on python-testtools are now RC: is bzr still a thing?
On 9/15/19 2:26 PM, Mattia Rizzolo wrote: > Considering that this is bzr we are talking about, a package that is > already entering the graveyard, I think it would be easiest to just > disable the test suite and move on. > > But I would be happier it Thomas at least checked the rdeps before > dropping packages, at least evaluating if breaking things is alrightif > he really likes to break packages :/ You mean check *better*. Because I do carefully check each time, as much as I can, but in this occurrence, it looks like I didn't check well enough. Mistakes unfortunately do happen when you work on a lot of packages. Moreover, the current tooling we have at our disposal is kind of broken. reverse-depends takes sometimes forever in Sid for a reason I can't figure out. And if I'm not mistaking, that's the only tool we have that can check reverse dependencies in a meaningful way. Or is there a better way? I've read others using a dak command, how? On 9/15/19 5:17 PM, Jelmer Vernooij wrote: > It's not just bzr, it's also a bunch of plugins for bzr that we'd have > to disable the testsuite for - as well as a bunch of other non-bzr-related packages - python-subunit, python-fixtures, python-testscenarios, python-daemon, python-fastimport. I've already removed Python 2 support from subunit, python-fixtures, and python-testscenarios. Now, as I wrote in the bug report, what worries me aren't these, but the other packages that are depending on python-daemon: Packages without Python 3 support upstream: - bcfg2 doesn't seem to have Python 3 support upstream, neither the Debian package. - nss-pam-ldapd isn't Python 3 ready upstream. Note that the debian maintainer the same person as upstream. - There's been zero upstream work on this repository: https://github.com/Yubico/python-pyhsm so the package has no change to be Python 3 ready anytime soon. Packages that simply need an upgrade from latest upstream release: - lavapdu-daemon should be upgraded to latest upstream release to have Python 3 support. - mini-buildd in Experimental has been converted to Python 3, while the version in Sid is still Python 2. - I haven't been able to tell for lava-coordinator. So, for bcfg2, nss-pam-ldapd, and python-pyhsm, I'm really not convinced that waiting for longer will help. That's a general problem that we btw need to address: how are we going to deal with this? There's going to be a lot of it, and we need to find a way out if we really are going to get Python 2 out. For the other 3, I shouldn't be hard to address by the current maintainers. I've raised the severity of #936189 #937165 #938069 #936819 #937049 #936818 to serious, and included them as Cc to this reply, in order to warn the maintainers. I haven't done it for the BZR stuff, as obviously, the package maintainer is aware now. Again, sorry that it happened this way. Cheers, Thomas Goirand (zigo)
Bug#959022: cgroup-tools: does not work in cgroup2 / unified hierarchy
Hi, I would agree to do nothing and tag this bug as bullseye-ignore, and document the fact that users need to manually configure/mount cgroup1 stuff. It's IMO perfectly fine to require some level of configuration to use a piece of software. Though in no way, removing cgroup-tools from bullseye is a good idea. Some software (like cinder) need it to configure I/O bandwidth. Cheers, Thomas Goirand (zigo)
Bug#959022: No need to be RC
Hi, With the correct options as per above (message #42), I was able to get Cinder to work correctly with the QoS for I/Os. So I've lowered the severity, as this package works correctly. So I don't see this as a "grave" bug by the definition of our BTS, though that being said, I'd very much would love to have the options activated by default, or any other workaround, to make it easier for our users, be included in Bullseye. At the bare minimum, we need to document this, maybe in the release notes for Bullseye. Cheers, Thomas Goirand (zigo)
Bug#959022: Works with kernel options
Hi, With this as kernel boot options: systemd.unified_cgroup_hierarchy=false systemd.legacy_systemd_cgroup_controller=false I have the old "cgcreate -g blkio:cinder-copy" that works perfectly, as the old cgroups v1 get mounted in the sysfs: # mount | grep -i cgroup cgroup2 on /sys/fs/cgroup/unified type cgroup2 cgroup on /sys/fs/cgroup/systemd type cgroup cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup cgroup on /sys/fs/cgroup/cpuset type cgroup cgroup on /sys/fs/cgroup/hugetlb type cgroup cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup cgroup on /sys/fs/cgroup/devices type cgroup cgroup on /sys/fs/cgroup/blkio type cgroup cgroup on /sys/fs/cgroup/freezer type cgroup cgroup on /sys/fs/cgroup/perf_event type cgroup cgroup on /sys/fs/cgroup/pids type cgroup cgroup on /sys/fs/cgroup/memory type cgroup cgroup on /sys/fs/cgroup/rdma type cgroup So I see no reason to remove cgroup-tools, which would otherwise break Cinder QoS for I/O. Cheers, Thomas Goirand (zigo)
Bug#804844: Please git rid of the repoze.what / repoze.what-plugins depends
Package: python-tg.devtools Version: 2.0.2-5 Severity: important Hi Doko! It looks like repoze.what and repoze.what-plugins are not actively maintained upstream, and repoze.who >= 2 is breaking its API, making repoze.what incompatible with it. repoze.what needs repoze.who-plugins to build. I would like to get rid of repoze.what, repoze.who-plugins & repoze.what-plugins in Debian, as it would be too hard to continue to maintain it without upstream support. Note that this issue is blocking python-pysaml2 to migrate to Testing, as it depends on repoze.who who itself can't migrate to Testing because of repoze.what depending on repoze.who < 1.99. So I'd like to have the situation fixed asap, so that the last remaining OpenStack (Liberty release) can migrate to testing (so I could start doing the uploads to jessie-backports). I haven't investigated how hard it would be to get rid of repoze.what in tg.devtools. Please feel free to let me know your thoughts about it. Cheers, Thomas Goirand (zigo)
