RFS: python-coverage 3.0.1-1

[Ben Finney-5]

Howdy Python mentors,

I am looking for a sponsor for the new release 3.0.1-1 of my package
‘python-coverage’. At the request of the current primary maintainer,
Lars Wirzenius, I am taking over as active maintainer for this package
and seeking a sponsor.

It builds these binary packages:

    python-coverage – code coverage tool for Python

The upload would fix these bugs: 535764

The package is downloadable via:

    $ dget http://mentors.debian.net/debian/pool/main/p/python-coverage/python-coverage_3.0.1-1.dsc

I look forward to working with a new sponsor. Please let me know whether
anything further needs to be done before this package can be sponsored.

--
 \      “Often, the surest way to convey misinformation is to tell the |
  `\               strict truth.” —Mark Twain, _Following the Equator_ |
_o__)                                                                  |
Ben Finney


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Piotr Ożarowski-2]

[Ben Finney, 2009-10-02]
>     $ dget http://mentors.debian.net/debian/pool/main/p/python-coverage/python-coverage_3.0.1-1.dsc

* why 2.3-2.6 in pyversions? Will it not work with 2.7? Do not worry about
  Python >= 3 (modules for py3k will be shipped in python3-coverage)
* how about adding -dbg package?
* there's new upstream release already (3.1)

--
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

[Ben Finney-5]

Piotr Ożarowski <piotr@...> writes:

> [Ben Finney, 2009-10-02]
> >     $ dget http://mentors.debian.net/debian/pool/main/p/python-coverage/python-coverage_3.0.1-1.dsc
>
> * why 2.3-2.6 in pyversions? Will it not work with 2.7? Do not worry about
>   Python >= 3 (modules for py3k will be shipped in python3-coverage)

That range of versions is what upstream declares support for. Python 2.7
is not on their list of supported versions.

> * how about adding -dbg package?

Good idea, thanks. I've never looked into how that's done. Where should
I begin reading about it?

Once I learn how to make a ‘foo-dbg’ package, I can do that in the next
release (see below).

> * there's new upstream release already (3.1)

Yes, I've begun work on packaging it.

Thank you for inspecting this package. Is it fit for sponsorship into
Debian?

--
 \           “If you do not trust the source do not use this program.” |
  `\                                —Microsoft Vista security dialogue |
_o__)                                                                  |
Ben Finney

[Piotr Ożarowski-2]

[Ben Finney, 2009-10-16]

> Piotr Ożarowski <piotr@...> writes:
>
> > [Ben Finney, 2009-10-02]
> > >     $ dget http://mentors.debian.net/debian/pool/main/p/python-coverage/python-coverage_3.0.1-1.dsc
> >
> > * why 2.3-2.6 in pyversions? Will it not work with 2.7? Do not worry about
> >   Python >= 3 (modules for py3k will be shipped in python3-coverage)
>
> That range of versions is what upstream declares support for. Python 2.7
> is not on their list of supported versions.

if there are no known problems, please use "2.3-" - this way we'll have
less work while adding 2.7 to the supported versions

> > * how about adding -dbg package?
>
> Good idea, thanks. I've never looked into how that's done. Where should
> I begin reading about it?
>
> Once I learn how to make a ‘foo-dbg’ package, I can do that in the next
> release (see below).

IIRC you're using dh sequencer, so just add -dbg package in debian/control,
build depend on python-all-dbg and dh will do the rest
--
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ben Finney-5]

Ben Finney <ben+debian@...> writes:

> Once I learn how to make a ‘foo-dbg’ package, I can do that in the
> next release […]

I've learned some about creating a ‘foo-dbg’ package [0]. However, I'm
ending up with a source package that installs none of the Python files
into any of the binary packages.

Can someone point me to an existing package that:

* uses ‘debhelper’ vversion 7 or later (i.e. uses the implied-sequence
  ‘dh’ command instead of explicit lists of ‘dh_foo’ commands)

* uses ‘python-support’

* creates multiple packages, preferably including a ‘foo-dbg’ package

I can't find any package that does all of those, but can't really do
better than guess and manually check source packages with trial and
error.


[0] <URL:http://wiki.debian.org/PkgSplit> is really difficult to follow,
    probably because it needs some love from a fluent English writer.
    <URL:http://www.debian.org/doc/developers-reference/best-pkging-practices.html#multiple-binary>
    ignores using Debhelper 7 to avoid explicit use of ‘setup.py’ or
    ‘dh_install’.

--
 \       “Imagine a world without hypothetical situations.” —anonymous |
  `\                                                                   |
_o__)                                                                  |
Ben Finney

[Jonathan Wiltshire]

On Sat, Oct 17, 2009 at 11:40:07PM +1100, Ben Finney wrote:

>
> Can someone point me to an existing package that:
>
> * uses ‘debhelper’ vversion 7 or later (i.e. uses the implied-sequence
>   ‘dh’ command instead of explicit lists of ‘dh_foo’ commands)
>
> * uses ‘python-support’
>
> * creates multiple packages, preferably including a ‘foo-dbg’ package
>

IIRC, backintime does all but the -dbg of these things.


--
Jonathan Wiltshire

1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3  A903 CA6B EA3E DB80 0B52
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ben Finney-5]

Jonathan Wiltshire <debian@...> writes:

> On Sat, Oct 17, 2009 at 11:40:07PM +1100, Ben Finney wrote:
> > * uses ‘debhelper’ vversion 7 or later […]
> > * uses ‘python-support’
> > * creates multiple packages, preferably including a ‘foo-dbg’ package
>
> IIRC, backintime does all but the -dbg of these things.

Thanks, ‘backintime’ does indeed meet these criteria.

The ‘debian/rules’ file is doing some things that I'm confused about:

=====
override_dh_auto_clean:
        rm -rf locale common/po/*.mo
        find $(CURDIR) -name "*\.py[co]" -delete
        rm -f common/Makefile gnome/Makefile kde4/Makefile
=====

Is it necessary to remove ‘*.py[co]’ files? Wouldn't it be better to
call ‘dh_auto_clean’ to do this?

=====
override_dh_pysupport:
        dh_pysupport /usr/share/backintime/
=====

Is this necessary? Why can't ‘dh_pysupport’ do this without being
overridden here?

--
 \       “Two possibilities exist: Either we are alone in the Universe |
  `\   or we are not. Both are equally terrifying.” —Arthur C. Clarke, |
_o__)                                                             1999 |
Ben Finney


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Josselin Mouette]

Le dimanche 18 octobre 2009 à 10:31 +1100, Ben Finney a écrit :
> =====
> override_dh_pysupport:
>         dh_pysupport /usr/share/backintime/
> =====
>
> Is this necessary? Why can't ‘dh_pysupport’ do this without being
> overridden here?

Yes, dh_pysupport only looks at /usr/share/$package
and /usr/lib/$package.

Cheers,
--
 .''`.      Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `-     future understand things”  -- Jörg Schilling

[Ben Finney-5]

Ben Finney <ben+debian@...> writes:

> Ben Finney <ben+debian@...> writes:
>
> > Once I learn how to make a ‘foo-dbg’ package, I can do that in the
> > next release […]
>
> I've learned some about creating a ‘foo-dbg’ package [0]. However, I'm
> ending up with a source package that installs none of the Python files
> into any of the binary packages.

Going further today, I now have a ‘python-coverage’ package that:

* uses Debhelper 7.x (as before)
* uses python-support (as before)
* has multiple binary packages

and it successfully builds the original (“normal”) binary package,
‘python-coverage’.

However, in doing so, I've had to fall back on explicitly iterating
Python versions and explicitly calling ‘setup.py install’, which partly
defeats the purpose of using Debhelper 7 and python-support. This is
frustrating, and I wonder if I'm missing some simpler way to do
multiple binary Python packages with these tools.

Also, while the ‘python-coverage’ binary package is now building
correctly, the ‘python-coverage-dbg’ binary package contains nothing
useful; it's as though there is no content for that package detected by
the tools. Isn't that exactly why I'm using Debhelper >= 7.3.5 in the
first place: to automatically handle the debug package based on
‘Build-Depends: python-all-dbg’?


I would appreciate some feedback again at this point, I'm going
cross-eyed trying to find what is wrong and someone else can probably
see it much easier.

I'm not uploading it to mentors because it's not in a fit state for
release. The Debian packaging is in a Bazaar repository:

    $ bzr branch http://bzr.debian.org/bzr/collab-maint/python-coverage/python-coverage.debian/

The original source archive is the same as the previous release,
<URL:http://mentors.debian.net/debian/pool/main/p/python-coverage/python-coverage_3.0.1.orig.tar.gz>.

Thanks in advance to mentors spending time to help me.

--
 \         “Smoking cures weight problems. Eventually.” —Steven Wright |
  `\                                                                   |
_o__)                                                                  |
Ben Finney

[Jonathan Wiltshire]

On Sun, Oct 18, 2009 at 10:31:02AM +1100, Ben Finney wrote:

> Thanks, ‘backintime’ does indeed meet these criteria.
>
> The ‘debian/rules’ file is doing some things that I'm confused about:
>
> =====
> override_dh_auto_clean:
>         rm -rf locale common/po/*.mo
>         find $(CURDIR) -name "*\.py[co]" -delete
>         rm -f common/Makefile gnome/Makefile kde4/Makefile
> =====
>
> Is it necessary to remove ‘*.py[co]’ files? Wouldn't it be better to
> call ‘dh_auto_clean’ to do this?

They must be removed to keep the .diff.gz clean, but upstream doesn't ship
makefiles with clean targets, so dh_auto_clean can't handle it. dh_clean
doesn't know about pre-compiled python files.

> =====
> override_dh_pysupport:
>         dh_pysupport /usr/share/backintime/
> =====
>
> Is this necessary? Why can't ‘dh_pysupport’ do this without being
> overridden here?

dh_pysupport:
        If your package installs private python modules in non-standard
        directories, you can make dh_pysupport check those directories by
        passing their names on the command line. By default, it will check
        /usr/lib/$PACKAGE, /usr/share/$PACKAGE, /usr/lib/games/$PACKAGE and
        /usr/share/games/$PACKAGE

In my case, the package names are backintime-* but the install directory is
always /usr/share/backintime, so dh_pysupport needs a little hint here.


--
Jonathan Wiltshire

1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3  A903 CA6B EA3E DB80 0B52
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...