Packages depending on python-testtools are now RC: is bzr still a thing?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Packages depending on python-testtools are now RC: is bzr still a thing?

Thomas Goirand-3
Hi,

As I wrongly thought python-extras was used only by OpenStack stuff, I
removed Python 2 support for it. Then someone filed a bug against
python-testtools (ScottK, I believe) saying that it became RC.
Therefore, I went ahead and removed Python 2 support for testtools, but
now, this implies that a few packages which I didn't wish to impact are
also RC:

* bzr-builddeb
* bzr-email
* bzr-fastimport
* bzr-git
* bzr-stats
* bzr-upload
* loggerhead

So, basically, unfortunately, Bazaar has lost some of its build
dependencies.

So, I went ahead, and looked what I could do for Bazaar. Unfortunately,
when looking at:
https://launchpad.net/bzr

I can see no release since January 2016, no daily archive. The last
commit in the bzr repository of bzr is from 2017-03-17.

Then I went to see how much Python 3 effort would be needed, and I
quickly gave up. It'd be A LOT of work, but nobody seems doing ANY work
on bzr anymore.

So I wonder: is it time to remove bazaar from Debian? Or is there any
vague plan to make it work with Python 3? If we are to remove it from
Debian, then we'd better do it ASAP.

Your thoughts?

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Packages depending on python-testtools are now RC: is bzr still a thing?

Scott Kitterman-5
On Saturday, September 14, 2019 6:43:13 PM EDT Thomas Goirand wrote:

> Hi,
>
> As I wrongly thought python-extras was used only by OpenStack stuff, I
> removed Python 2 support for it. Then someone filed a bug against
> python-testtools (ScottK, I believe) saying that it became RC.
> Therefore, I went ahead and removed Python 2 support for testtools, but
> now, this implies that a few packages which I didn't wish to impact are
> also RC:
>
> * bzr-builddeb
> * bzr-email
> * bzr-fastimport
> * bzr-git
> * bzr-stats
> * bzr-upload
> * loggerhead
>
> So, basically, unfortunately, Bazaar has lost some of its build
> dependencies.
>
> So, I went ahead, and looked what I could do for Bazaar. Unfortunately,
> when looking at:
> https://launchpad.net/bzr
>
> I can see no release since January 2016, no daily archive. The last
> commit in the bzr repository of bzr is from 2017-03-17.
>
> Then I went to see how much Python 3 effort would be needed, and I
> quickly gave up. It'd be A LOT of work, but nobody seems doing ANY work
> on bzr anymore.
>
> So I wonder: is it time to remove bazaar from Debian? Or is there any
> vague plan to make it work with Python 3? If we are to remove it from
> Debian, then we'd better do it ASAP.

As I understand it, bazaar (bzr) is dead and being replaced by breezy (brz),
which is python3 compatible.

https://www.breezy-vcs.org/

My inference is that anything bzr specific can go, but I'm not involved in
either project.

Scott K



Reply | Threaded
Open this post in threaded view
|

Re: Packages depending on python-testtools are now RC: is bzr still a thing?

Jelmer Vernooij-3


On 15 September 2019 01:15:11 CEST, Scott Kitterman <[hidden email]> wrote:

>On Saturday, September 14, 2019 6:43:13 PM EDT Thomas Goirand wrote:
>> Hi,
>>
>> As I wrongly thought python-extras was used only by OpenStack stuff,
>I
>> removed Python 2 support for it. Then someone filed a bug against
>> python-testtools (ScottK, I believe) saying that it became RC.
>> Therefore, I went ahead and removed Python 2 support for testtools,
>but
>> now, this implies that a few packages which I didn't wish to impact
>are
>> also RC:
>>
>> * bzr-builddeb
>> * bzr-email
>> * bzr-fastimport
>> * bzr-git
>> * bzr-stats
>> * bzr-upload
>> * loggerhead
>>
>> So, basically, unfortunately, Bazaar has lost some of its build
>> dependencies.
>>
>> So, I went ahead, and looked what I could do for Bazaar.
>Unfortunately,
>> when looking at:
>> https://launchpad.net/bzr
>>
>> I can see no release since January 2016, no daily archive. The last
>> commit in the bzr repository of bzr is from 2017-03-17.
>>
>> Then I went to see how much Python 3 effort would be needed, and I
>> quickly gave up. It'd be A LOT of work, but nobody seems doing ANY
>work
>> on bzr anymore.
>>
>> So I wonder: is it time to remove bazaar from Debian? Or is there any
>> vague plan to make it work with Python 3? If we are to remove it from
>> Debian, then we'd better do it ASAP.
>
>As I understand it, bazaar (bzr) is dead and being replaced by breezy
>(brz),
>which is python3 compatible.
>
>https://www.breezy-vcs.org/
>
>My inference is that anything bzr specific can go, but I'm not involved
>in
>either project.

Bzr maintainer / breezy upstream here.

I'm planning to upload transitional packages to trigger upgrades from bzr to Breezy.

The packages for that are not ready yet though. Can we undo the dropping of python-testtools in the meantime?

Jelmer

Reply | Threaded
Open this post in threaded view
|

Re: Packages depending on python-testtools are now RC: is bzr still a thing?

Mattia Rizzolo-5
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 :/


On Sun, 15 Sep 2019, 11:09 am Jelmer Vernooij, <[hidden email]> wrote:


On 15 September 2019 01:15:11 CEST, Scott Kitterman <[hidden email]> wrote:
>On Saturday, September 14, 2019 6:43:13 PM EDT Thomas Goirand wrote:
>> Hi,
>>
>> As I wrongly thought python-extras was used only by OpenStack stuff,
>I
>> removed Python 2 support for it. Then someone filed a bug against
>> python-testtools (ScottK, I believe) saying that it became RC.
>> Therefore, I went ahead and removed Python 2 support for testtools,
>but
>> now, this implies that a few packages which I didn't wish to impact
>are
>> also RC:
>>
>> * bzr-builddeb
>> * bzr-email
>> * bzr-fastimport
>> * bzr-git
>> * bzr-stats
>> * bzr-upload
>> * loggerhead
>>
>> So, basically, unfortunately, Bazaar has lost some of its build
>> dependencies.
>>
>> So, I went ahead, and looked what I could do for Bazaar.
>Unfortunately,
>> when looking at:
>> https://launchpad.net/bzr
>>
>> I can see no release since January 2016, no daily archive. The last
>> commit in the bzr repository of bzr is from 2017-03-17.
>>
>> Then I went to see how much Python 3 effort would be needed, and I
>> quickly gave up. It'd be A LOT of work, but nobody seems doing ANY
>work
>> on bzr anymore.
>>
>> So I wonder: is it time to remove bazaar from Debian? Or is there any
>> vague plan to make it work with Python 3? If we are to remove it from
>> Debian, then we'd better do it ASAP.
>
>As I understand it, bazaar (bzr) is dead and being replaced by breezy
>(brz),
>which is python3 compatible.
>
>https://www.breezy-vcs.org/
>
>My inference is that anything bzr specific can go, but I'm not involved
>in
>either project.

Bzr maintainer / breezy upstream here.

I'm planning to upload transitional packages to trigger upgrades from bzr to Breezy.

The packages for that are not ready yet though. Can we undo the dropping of python-testtools in the meantime?

Jelmer

Reply | Threaded
Open this post in threaded view
|

Re: Packages depending on python-testtools are now RC: is bzr still a thing?

Jelmer Vernooij-3
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.

Jelmer

On 15 September 2019 14:26:35 CEST, Mattia Rizzolo <[hidden email]> 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 :/
>
>
>On Sun, 15 Sep 2019, 11:09 am Jelmer Vernooij, <[hidden email]>
>wrote:
>
>>
>>
>> On 15 September 2019 01:15:11 CEST, Scott Kitterman
><[hidden email]>
>> wrote:
>> >On Saturday, September 14, 2019 6:43:13 PM EDT Thomas Goirand wrote:
>> >> Hi,
>> >>
>> >> As I wrongly thought python-extras was used only by OpenStack
>stuff,
>> >I
>> >> removed Python 2 support for it. Then someone filed a bug against
>> >> python-testtools (ScottK, I believe) saying that it became RC.
>> >> Therefore, I went ahead and removed Python 2 support for
>testtools,
>> >but
>> >> now, this implies that a few packages which I didn't wish to
>impact
>> >are
>> >> also RC:
>> >>
>> >> * bzr-builddeb
>> >> * bzr-email
>> >> * bzr-fastimport
>> >> * bzr-git
>> >> * bzr-stats
>> >> * bzr-upload
>> >> * loggerhead
>> >>
>> >> So, basically, unfortunately, Bazaar has lost some of its build
>> >> dependencies.
>> >>
>> >> So, I went ahead, and looked what I could do for Bazaar.
>> >Unfortunately,
>> >> when looking at:
>> >> https://launchpad.net/bzr
>> >>
>> >> I can see no release since January 2016, no daily archive. The
>last
>> >> commit in the bzr repository of bzr is from 2017-03-17.
>> >>
>> >> Then I went to see how much Python 3 effort would be needed, and I
>> >> quickly gave up. It'd be A LOT of work, but nobody seems doing ANY
>> >work
>> >> on bzr anymore.
>> >>
>> >> So I wonder: is it time to remove bazaar from Debian? Or is there
>any
>> >> vague plan to make it work with Python 3? If we are to remove it
>from
>> >> Debian, then we'd better do it ASAP.
>> >
>> >As I understand it, bazaar (bzr) is dead and being replaced by
>breezy
>> >(brz),
>> >which is python3 compatible.
>> >
>> >https://www.breezy-vcs.org/
>> >
>> >My inference is that anything bzr specific can go, but I'm not
>involved
>> >in
>> >either project.
>>
>> Bzr maintainer / breezy upstream here.
>>
>> I'm planning to upload transitional packages to trigger upgrades from
>bzr
>> to Breezy.
>>
>> The packages for that are not ready yet though. Can we undo the
>dropping
>> of python-testtools in the meantime?
>>
>> Jelmer
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Packages depending on python-testtools are now RC: is bzr still a thing?

Thomas Goirand-3
In reply to this post by Mattia Rizzolo-5
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)

Reply | Threaded
Open this post in threaded view
|

Re: Packages depending on python-testtools are now RC: is bzr still a thing?

Simon McVittie-7
On Sun, 15 Sep 2019 at 23:39:46 +0200, Thomas Goirand wrote:
> 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?

Log in to the developer-accessible archive copy
(mirror.ftp-master.debian.org, currently hosted on coccia.debian.org),
and use "dak rm -R -n" (aka "dak rm --rdep-check --no-action"). Use
"dak rm --help" for help.

For the Python-2-removal transition, probably the most common query
will be to ask what would be broken if you removed all the Python 2
binary packages from a source package, but kept the rest of the source
package. For example, looking at https://tracker.debian.org/pkg/pygobject
I can see that it builds binary packages python-gi, python-gi-cairo,
python-gi-dbg, python-gi-dev, and python-gobject for Python 2 (plus some
Python 3 binary packages which are not interesting for this transition),
so I tried this:

    $ dak rm -R -n -b python-gi python-gi-cairo python-gi-dbg python-gi-dev python-gobject

and got this result:

    Will remove the following packages from unstable:

    python-gi |   3.34.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
    python-gi-cairo |   3.34.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
    python-gi-dbg |   3.34.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
    python-gi-dev |   3.34.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
    python-gobject |   3.34.0-1 | all

    Maintainer: Debian GNOME Maintainers <[hidden email]>

    ------------------- Reason -------------------

    ----------------------------------------------

    Checking reverse dependencies...
    # Broken Depends:
    autokey: autokey-gtk
    avahi: avahi-discover
    ...

    # Broken Build-Depends:
    accerciser: python-gi-dev (>= 3.4.2)
    alacarte: python-gi-dev
    avahi: python-gi-dev
    ...

    Dependency problem found.

How to interpret this: if we removed python-gi, python-gi-cairo,
python-gi-dbg, python-gi-dev and python-gobject, then it would break
Depends in binary packages autokey-gtk (from src:autokey), avahi-discover
(from src:avahi) and so on; and would also break Build-Depends in
accerciser, alacarte and so on. (I stopped quoting after "A" here.)

If there is no dependency that would prevent the packages' removal, instead
you would see:

    Checking reverse dependencies...
    No dependency problem found.

To evaluate what would happen if entire source packages were
removed, leave off the -b (aka --binary), and the package names will
be interpreted as source instead of binary packages. For example,
https://tracker.debian.org/pkg/pygobject-2 is Python-2-only (it's a legacy
version of https://tracker.debian.org/pkg/pygobject) so you might run this:

    $ dak rm -R -n pygobject-2

When doing QA work and recommending that an unmaintained/broken source
package is to be removed, the form without -b is usually the right one
to use.

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: Packages depending on python-testtools are now RC: is bzr still a thing?

Thomas Goirand-3
On 9/16/19 12:31 AM, Simon McVittie wrote:

> On Sun, 15 Sep 2019 at 23:39:46 +0200, Thomas Goirand wrote:
>> 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?
>
> Log in to the developer-accessible archive copy
> (mirror.ftp-master.debian.org, currently hosted on coccia.debian.org),
> and use "dak rm -R -n" (aka "dak rm --rdep-check --no-action"). Use
> "dak rm --help" for help.

Thanks, I'll do that from now on.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Packages depending on python-testtools are now RC: is bzr still a thing?

Andrey Rahmatullin-3
In reply to this post by Simon McVittie-7
Note that dak doesn't check autopkgtest deps. I'm using
grep-dctrl -FTestsuite-triggers $pkg -sPackage /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources
for that.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

A possibly easier way to check dependencies for 2Removal?

Rebecca N. Palmer-2
grep-dctrl -w -F Depends,Recommends -s Source "python-$module"
/var/lib/apt/lists/*_debian_dists_sid_main_binary-amd64_Packages ;
grep-dctrl -w -s Package "python-$module"
/var/lib/apt/lists/*_debian_dists_sid_main_source_Sources

where python-$module is the *binary* package name.

This finds runtime Depends/Recommends, and all mentions in the Sources
index (Build-Depends*, Testsuite-Triggers, and the package itself):

Outputs only this package's source name => ready to be removed
Outputs other source package(s) => not ready yet
Outputs nothing => package doesn't exist (either it's already been
removed, or you mis-spelt it)

(Previous suggestions in this thread were "apt-cache rdepends
python-$module ; reverse-depends -b python-$module" (can be slow) or
"dak rm -R -n -b python-$module" (DDs only); those both ignore
autopkgtest depends.)

Reply | Threaded
Open this post in threaded view
|

Re: A possibly easier way to check dependencies for 2Removal?

Diane Trout


On Tue, 2019-09-17 at 22:46 +0100, Rebecca N. Palmer wrote:
> grep-dctrl -w -F Depends,Recommends -s Source "python-$module"
> /var/lib/apt/lists/*_debian_dists_sid_main_binary-amd64_Packages ;
> grep-dctrl -w -s Package "python-$module"
> /var/lib/apt/lists/*_debian_dists_sid_main_source_Sources

Thank you that does look more thorough.

I added a lightly edited version of your recommendation to the
Python/2Removal page. (So I can find it again next time I need it)

https://wiki.debian.org/Python/2Removal