Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #11809 > unrolled thread

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

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Packages depending on python-testtools are now RC: is bzr still a thing? Scott Kitterman <debian@kitterman.com> - 2019-09-15 01:20 +0200
    Re: Packages depending on python-testtools are now RC: is bzr still a thing? Jelmer Vernooij <jelmer@jelmer.uk> - 2019-09-15 11:10 +0200
      Re: Packages depending on python-testtools are now RC: is bzr still a thing? Mattia Rizzolo <mattia@debian.org> - 2019-09-15 14:30 +0200
        Re: Packages depending on python-testtools are now RC: is bzr still a thing? Jelmer Vernooij <jelmer@jelmer.uk> - 2019-09-15 17:40 +0200
        Re: Packages depending on python-testtools are now RC: is bzr still  a thing? Simon McVittie <smcv@debian.org> - 2019-09-16 00:40 +0200
          Re: Packages depending on python-testtools are now RC: is bzr still  a thing? Andrey Rahmatullin <wrar@debian.org> - 2019-09-16 09:20 +0200
            A possibly easier way to check dependencies for 2Removal? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-09-18 00:20 +0200
              Re: A possibly easier way to check dependencies for 2Removal? Diane Trout <diane@ghic.org> - 2019-09-18 19:40 +0200
              Re: A possibly easier way to check dependencies for 2Removal? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-10-26 20:30 +0200

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

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

[toc] | [next] | [standalone]

#11812

On 15 September 2019 01:15:11 CEST, Scott Kitterman <debian@kitterman.com> 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

[toc] | [prev] | [next] | [standalone]

#11813

[Multipart message — attachments visible in raw view] — view raw

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, <jelmer@jelmer.uk> wrote:

>
>
> On 15 September 2019 01:15:11 CEST, Scott Kitterman <debian@kitterman.com>
> 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
>
>

[toc] | [prev] | [next] | [standalone]

#11815

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 <mattia@debian.org> 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, <jelmer@jelmer.uk>
>wrote:
>
>>
>>
>> On 15 September 2019 01:15:11 CEST, Scott Kitterman
><debian@kitterman.com>
>> 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
>>
>>

[toc] | [prev] | [next] | [standalone]

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

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 <pkg-gnome-maintainers@lists.alioth.debian.org>

    ------------------- 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

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#11831 — A possibly easier way to check dependencies for 2Removal?

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.)

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

This had a bug: packages with source name = binary name don't have a 
Source: field in the binary Packages file, which makes grep-dctrl skip 
them when asked to output the Source field.

Fixed version:

grep-dctrl -w -F Pre-Depends,Depends,Recommends -s Package 
"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

I have updated the wiki page.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web