Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Advise on packaging a new Python module
26 views
Skip to first unread message
Tomás Di Domenico
Nov 4, 2012, 10:40:02 AM11/4/12
to
Greetings.
I've recently joined the Debian Med team, and am currently trying to
package my first project, the CSB bioinformatics toolbox [1]. CSB is
similar to the already packaged Biopython group of modules, but dealing
exclusively with the structural side of bioinformatics. This is the
reason why it seemed like a project for the Med team.
I have already set up the package in a git repository [2], and it seems
to be in pretty good shape, according to Andreas Tille, my mentor.
Laszlo Kajan, a member of the Med team, advised me to ask for help to
the Python team, and particularly to Jakub Wilk, who's helped him in the
past. His suggestion is that if the module is acceptable, it may be
worth it to have the maintainer changed from the Med team to the Python
team.
In any case, I'd be most grateful if you could check the package and
provide any observations that you may come up with.
Thank you in advance.
Tom�s
[1] http://csb.codeplex.com
[2] http://anonscm.debian.org/gitweb/?p=debian-med/python-csb.git
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/50967F26...@tdido.com.ar
I've recently joined the Debian Med team, and am currently trying to
package my first project, the CSB bioinformatics toolbox [1]. CSB is
similar to the already packaged Biopython group of modules, but dealing
exclusively with the structural side of bioinformatics. This is the
reason why it seemed like a project for the Med team.
I have already set up the package in a git repository [2], and it seems
to be in pretty good shape, according to Andreas Tille, my mentor.
Laszlo Kajan, a member of the Med team, advised me to ask for help to
the Python team, and particularly to Jakub Wilk, who's helped him in the
past. His suggestion is that if the module is acceptable, it may be
worth it to have the maintainer changed from the Med team to the Python
team.
In any case, I'd be most grateful if you could check the package and
provide any observations that you may come up with.
Thank you in advance.
Tom�s
[1] http://csb.codeplex.com
[2] http://anonscm.debian.org/gitweb/?p=debian-med/python-csb.git
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/50967F26...@tdido.com.ar
Jakub Wilk
Nov 6, 2012, 4:30:02 PM11/6/12
to
* Tomás Di Domenico <td...@tdido.com.ar>, 2012-11-04, 15:43:
>[2] http://anonscm.debian.org/gitweb/?p=debian-med/python-csb.git
I didn't play with the package for very long, because I couldn't build
the source package. It looks like contents of the repository didn't
match contents of the upstream tarball (which I downloaded with uscan),
making dpkg-source abort due to upstream changes. The diff between the
two is huge (664 files changed, 27972 insertions, 21422 deletions); it
contains e.g.:
-__version__ = '1.1.0.463'
+__version__ = '1.1.0.507'
Did upstream release a new version without changing tarball name? :(
This package requires Python >= 2.6, and since 2.5 is a supported
version in squeeze, so this should be declared in debian/control. Please
add:
X-Python-Version: >= 2.6
to the source paragraph.
To be pedantically correct, build-dependency on python-all should be
versioned: >= 2.6.6-3~ (see dh_python2 manpage).
Current standards version is 3.9.4. Note that lintian doesn't know it
yet, so you'll have to live with a spurious warning. The new Policy
version made build-arch and build-indep targets mandatory; dh support
for these targets was implemented in debhelper 8.1.0, so don't forget to
bump the build-dependency.
It looks like upstream supports Python 3.X. You may consider supporting
it in Debian, too. If you choose to do so, please build a separate
binary package python3-csb. Beware that dh doesn't support
building/installing Python 3.X modules, so you would have to write the
code yourself.
I would advise you against using a more restrictive license for debian/*
that upstream uses, like you currently do.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012110621...@jwilk.net
>I've recently joined the Debian Med team, and am currently trying to
>package my first project, the CSB bioinformatics toolbox [1]. CSB is
>similar to the already packaged Biopython group of modules, but dealing
>exclusively with the structural side of bioinformatics. This is the
>reason why it seemed like a project for the Med team.
>
>I have already set up the package in a git repository [2], and it seems
>to be in pretty good shape, according to Andreas Tille, my mentor.
>Laszlo Kajan, a member of the Med team, advised me to ask for help to
>the Python team, and particularly to Jakub Wilk, who's helped him in
>the past. His suggestion is that if the module is acceptable, it may be
>worth it to have the maintainer changed from the Med team to the Python
>team.
I feel like I've been just called to the blackboard. ;)
>package my first project, the CSB bioinformatics toolbox [1]. CSB is
>similar to the already packaged Biopython group of modules, but dealing
>exclusively with the structural side of bioinformatics. This is the
>reason why it seemed like a project for the Med team.
>
>I have already set up the package in a git repository [2], and it seems
>to be in pretty good shape, according to Andreas Tille, my mentor.
>Laszlo Kajan, a member of the Med team, advised me to ask for help to
>the Python team, and particularly to Jakub Wilk, who's helped him in
>the past. His suggestion is that if the module is acceptable, it may be
>worth it to have the maintainer changed from the Med team to the Python
>team.
>[2] http://anonscm.debian.org/gitweb/?p=debian-med/python-csb.git
I didn't play with the package for very long, because I couldn't build
the source package. It looks like contents of the repository didn't
match contents of the upstream tarball (which I downloaded with uscan),
making dpkg-source abort due to upstream changes. The diff between the
two is huge (664 files changed, 27972 insertions, 21422 deletions); it
contains e.g.:
-__version__ = '1.1.0.463'
+__version__ = '1.1.0.507'
Did upstream release a new version without changing tarball name? :(
This package requires Python >= 2.6, and since 2.5 is a supported
version in squeeze, so this should be declared in debian/control. Please
add:
X-Python-Version: >= 2.6
to the source paragraph.
To be pedantically correct, build-dependency on python-all should be
versioned: >= 2.6.6-3~ (see dh_python2 manpage).
Current standards version is 3.9.4. Note that lintian doesn't know it
yet, so you'll have to live with a spurious warning. The new Policy
version made build-arch and build-indep targets mandatory; dh support
for these targets was implemented in debhelper 8.1.0, so don't forget to
bump the build-dependency.
It looks like upstream supports Python 3.X. You may consider supporting
it in Debian, too. If you choose to do so, please build a separate
binary package python3-csb. Beware that dh doesn't support
building/installing Python 3.X modules, so you would have to write the
code yourself.
I would advise you against using a more restrictive license for debian/*
that upstream uses, like you currently do.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dmitry Shachnev
Nov 7, 2012, 4:40:02 AM11/7/12
to
Hi Tomás,
Maybe it's too pedantic, but here is what I can add to Jakub's comments:
- no dependency on ${python:Depends}, please add it;
- debian/docs is empty, please either fill it or delete the file.
On Sun, Nov 4, 2012 at 6:43 PM, Tomás Di Domenico <td...@tdido.com.ar> wrote:
> Greetings.
>
> I've recently joined the Debian Med team, and am currently trying to
> package my first project, the CSB bioinformatics toolbox [1]. CSB is
> similar to the already packaged Biopython group of modules, but dealing
> exclusively with the structural side of bioinformatics. This is the
> reason why it seemed like a project for the Med team.
>
> I have already set up the package in a git repository [2], and it seems
> to be in pretty good shape, according to Andreas Tille, my mentor.
> Laszlo Kajan, a member of the Med team, advised me to ask for help to
> the Python team, and particularly to Jakub Wilk, who's helped him in the
> past. His suggestion is that if the module is acceptable, it may be
> worth it to have the maintainer changed from the Med team
--
Dmitry Shachnev
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAKimPHWAAV+iE4T7T9WjLpui...@mail.gmail.com
Maybe it's too pedantic, but here is what I can add to Jakub's comments:
- no dependency on ${python:Depends}, please add it;
- debian/docs is empty, please either fill it or delete the file.
On Sun, Nov 4, 2012 at 6:43 PM, Tomás Di Domenico <td...@tdido.com.ar> wrote:
> Greetings.
>
> I've recently joined the Debian Med team, and am currently trying to
> package my first project, the CSB bioinformatics toolbox [1]. CSB is
> similar to the already packaged Biopython group of modules, but dealing
> exclusively with the structural side of bioinformatics. This is the
> reason why it seemed like a project for the Med team.
>
> I have already set up the package in a git repository [2], and it seems
> to be in pretty good shape, according to Andreas Tille, my mentor.
> Laszlo Kajan, a member of the Med team, advised me to ask for help to
> the Python team, and particularly to Jakub Wilk, who's helped him in the
> past. His suggestion is that if the module is acceptable, it may be
> worth it to have the maintainer changed from the Med team
Dmitry Shachnev
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jakub Wilk
Nov 7, 2012, 5:00:02 AM11/7/12
to
* Dmitry Shachnev <mit...@gmail.com>, 2012-11-07, 13:35:
Thanks for spotting it.
>- debian/docs is empty, please either fill it or delete the file.
ACK
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012110709...@jwilk.net
>Maybe it's too pedantic, but here is what I can add to Jakub's
>comments:
>
>- no dependency on ${python:Depends}, please add it;
This is one is certainly not too pendantic; it's a serious problem.
>comments:
>
>- no dependency on ${python:Depends}, please add it;
Thanks for spotting it.
>- debian/docs is empty, please either fill it or delete the file.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tomás Di Domenico
Nov 7, 2012, 6:50:02 AM11/7/12
to
Thank you very much for your input, Jakub and Dmitry. I'll start working
on those changes right away. And yes, it would be very nice to try and
get a Python3 version up. In fact, I'm quite interested in learning how
to manually write the code, without dh (though I foresee it will take me
some time ;).
About the different versions in the git repository and the upstream
package, that is actually my fault. I checked out the code from the
upstream Mercurial repository and built the tarball myself, hence using
a more recent version than the one in the tarball. It is not, however,
an "official" release. How is this best handled? Should I revert the git
repository so to keep it in sync with the official releases? Also, out
of curiosity, is there ever the case where you will build a package
against a particular build, without it being officially released by
upstream?
Thank you again for your help.
On 07/11/12 10:49, Jakub Wilk wrote:
> * Dmitry Shachnev <mit...@gmail.com>, 2012-11-07, 13:35:
>> Maybe it's too pedantic, but here is what I can add to Jakub's comments:
>>
>> - no dependency on ${python:Depends}, please add it;
>
> This is one is certainly not too pendantic; it's a serious problem.
> Thanks for spotting it.
>
>> - debian/docs is empty, please either fill it or delete the file.
>
> ACK
>
--
on those changes right away. And yes, it would be very nice to try and
get a Python3 version up. In fact, I'm quite interested in learning how
to manually write the code, without dh (though I foresee it will take me
some time ;).
About the different versions in the git repository and the upstream
package, that is actually my fault. I checked out the code from the
upstream Mercurial repository and built the tarball myself, hence using
a more recent version than the one in the tarball. It is not, however,
an "official" release. How is this best handled? Should I revert the git
repository so to keep it in sync with the official releases? Also, out
of curiosity, is there ever the case where you will build a package
against a particular build, without it being officially released by
upstream?
Thank you again for your help.
On 07/11/12 10:49, Jakub Wilk wrote:
> * Dmitry Shachnev <mit...@gmail.com>, 2012-11-07, 13:35:
>> Maybe it's too pedantic, but here is what I can add to Jakub's comments:
>>
>> - no dependency on ${python:Depends}, please add it;
>
> This is one is certainly not too pendantic; it's a serious problem.
> Thanks for spotting it.
>
>> - debian/docs is empty, please either fill it or delete the file.
>
> ACK
>
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/509A4661...@tdido.com.ar
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jakub Wilk
Nov 7, 2012, 10:50:01 AM11/7/12
to
* Tom�s Di Domenico <td...@tdido.com.ar>, 2012-11-07, 12:30:
>Also, out of curiosity, is there ever the case where you will build a
>package against a particular build, without it being officially
>released by upstream?
I think I don't understand this question. :( Could you try to rephrase
it?
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012110715...@jwilk.net
>About the different versions in the git repository and the upstream
>package, that is actually my fault. I checked out the code from the
>upstream Mercurial repository and built the tarball myself, hence using
>a more recent version than the one in the tarball. It is not, however,
>an "official" release. How is this best handled? Should I revert the
>git repository so to keep it in sync with the official releases?
I think this is the way to go, yes.
>package, that is actually my fault. I checked out the code from the
>upstream Mercurial repository and built the tarball myself, hence using
>a more recent version than the one in the tarball. It is not, however,
>an "official" release. How is this best handled? Should I revert the
>git repository so to keep it in sync with the official releases?
>Also, out of curiosity, is there ever the case where you will build a
>package against a particular build, without it being officially
>released by upstream?
it?
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dmitry Shachnev
Nov 7, 2012, 11:30:02 AM11/7/12
to
On Wed, Nov 7, 2012 at 3:30 PM, Tomás Di Domenico <td...@tdido.com.ar> wrote:
> Also, out of curiosity, is there ever the case where you will build a package
> against a particular build, without it being officially released by upstream?
You mean packaging snapshots from upstream VCS, right? That is
> Also, out of curiosity, is there ever the case where you will build a package
> against a particular build, without it being officially released by upstream?
possible, but I would not recommend doing it unless you have a
particular reason for that. If there are some bug fixes which didn't
make their way to release, it's better to backport those fixes and
apply as patches.
--
Dmitry Shachnev
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tomás Di Domenico
Nov 7, 2012, 11:40:01 AM11/7/12
to
Right, that's what I meant. Poor wording on my side, sorry about that.
Thanks!
Archive: http://lists.debian.org/509A8C11...@tdido.com.ar
Thanks!
Tomás Di Domenico
Nov 7, 2012, 11:40:03 AM11/7/12
to
On 07/11/12 16:43, Jakub Wilk wrote:
> * Tom�s Di Domenico <td...@tdido.com.ar>, 2012-11-07, 12:30:
>> About the different versions in the git repository and the upstream
>> package, that is actually my fault. I checked out the code from the
>> upstream Mercurial repository and built the tarball myself, hence
>> using a more recent version than the one in the tarball. It is not,
>> however, an "official" release. How is this best handled? Should I
>> revert the git repository so to keep it in sync with the official
>> releases?
>
> I think this is the way to go, yes.
Right, I'll do that then. Thank you.
> * Tom�s Di Domenico <td...@tdido.com.ar>, 2012-11-07, 12:30:
>> About the different versions in the git repository and the upstream
>> package, that is actually my fault. I checked out the code from the
>> upstream Mercurial repository and built the tarball myself, hence
>> using a more recent version than the one in the tarball. It is not,
>> however, an "official" release. How is this best handled? Should I
>> revert the git repository so to keep it in sync with the official
>> releases?
>
> I think this is the way to go, yes.
>> Also, out of curiosity, is there ever the case where you will build a
>> package against a particular build, without it being officially
>> released by upstream?
>
> I think I don't understand this question. :( Could you try to rephrase it?
>
that's newer than the published 1.1.0 release. Hence the differences you
mentioned. I believe I have seen Debian packages that include revision
numbers in their version numbers. I was wondering what would be a
scenario where you'd actually build the Debian package with a upstream
revision that's newer than an official release, and if this happens often.
If I'm not making any sense, please disregard the question and accept my
apologies. It certainly does not affect my packaging efforts in any case :)
Thanks again!
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Simon McVittie
Nov 7, 2012, 12:30:02 PM11/7/12
to
On 07/11/12 16:06, Tomás Di Domenico wrote:
> On 07/11/12 16:43, Jakub Wilk wrote:
>> * Tomás Di Domenico <td...@tdido.com.ar>, 2012-11-07, 12:30:
> On 07/11/12 16:43, Jakub Wilk wrote:
>>> About the different versions in the git repository and the upstream
>>> package, that is actually my fault. I checked out the code from the
>>> upstream Mercurial repository and built the tarball myself, hence
>>> using a more recent version than the one in the tarball.
If you find yourself needing to do that, you should indicate it in the
>>> package, that is actually my fault. I checked out the code from the
>>> upstream Mercurial repository and built the tarball myself, hence
>>> using a more recent version than the one in the tarball.
version number (e.g. see ioquake3_1.36+svn2287.orig.tar.gz) rather than
claiming that your orig.tar.gz is the upstream release (e.g. 1.36 here).
For svn, commit numbers are useful; for git, the number of commits since
the tag is a useful thing to use in version numbers (as done by, e.g.,
git describe).
> I believe I have seen Debian packages that include revision
> numbers in their version numbers. I was wondering what would be a
> scenario where you'd actually build the Debian package with a upstream
> revision that's newer than an official release, and if this happens often.
the one that OpenArena's fork is based on (we use a shared ioquake3
engine, not the forked version, in Debian). 1.36 was released in April
2009, so it's far too old for current OpenArena.
It also means we have some sort of hope for security support - upstream
don't make security or bugfix releases, only infrequent feature
releases, but they do fix security bugs in svn and announce which
commits are necessary for security. Trying to backport security fixes
past 3.5 years of development isn't ideal; supporting one recent-ish
snapshot per major Debian release limits how far back we need to go.
I do not recommend this approach, but if your upstream makes it
necessary, there might be no alternative.
S
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Tille
Nov 8, 2012, 9:20:01 AM11/8/12
to
Hi,
On Wed, Nov 07, 2012 at 12:30:41PM +0100, Tomás Di Domenico wrote:
> Thank you very much for your input, Jakub and Dmitry. I'll start working
> on those changes right away. And yes, it would be very nice to try and
> get a Python3 version up. In fact, I'm quite interested in learning how
> to manually write the code, without dh (though I foresee it will take me
> some time ;).
As far as I have followed this thread I have not seen an answer to this
part of your mail. I admit I have no idea how to support Python 2 *and*
3 but wild-guessing from my experience with Debian tools I doubt any
manual code writing would be needed. Any more detailed advise?
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20121108141...@an3as.eu
On Wed, Nov 07, 2012 at 12:30:41PM +0100, Tomás Di Domenico wrote:
> Thank you very much for your input, Jakub and Dmitry. I'll start working
> on those changes right away. And yes, it would be very nice to try and
> get a Python3 version up. In fact, I'm quite interested in learning how
> to manually write the code, without dh (though I foresee it will take me
> some time ;).
part of your mail. I admit I have no idea how to support Python 2 *and*
3 but wild-guessing from my experience with Debian tools I doubt any
manual code writing would be needed. Any more detailed advise?
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Kluyver
Nov 8, 2012, 9:30:02 AM11/8/12
to
On 8 November 2012 14:15, Andreas Tille <and...@an3as.eu> wrote:
As far as I have followed this thread I have not seen an answer to this
part of your mail. I admit I have no idea how to support Python 2 *and*
3 but wild-guessing from my experience with Debian tools I doubt any
manual code writing would be needed. Any more detailed advise?
Some manual code writing is needed, as debhelper doesn't yet know how to automatically build packages with Python 3.
The best description is this wiki page: http://wiki.debian.org/Python/LibraryStyleGuide
Thomas
The best description is this wiki page: http://wiki.debian.org/Python/LibraryStyleGuide
Thomas
Tomás Di Domenico
Nov 8, 2012, 10:30:02 AM11/8/12
to
Thanks, Thomas, that's a great resource. I had been looking at some
files from existing Python 3 packages, but that makes it clearer.
I'll now focus on wrapping up the Python 2 package, and then I'll move
on to the Python 3 version.
Thanks again!
files from existing Python 3 packages, but that makes it clearer.
I'll now focus on wrapping up the Python 2 package, and then I'll move
on to the Python 3 version.
Thanks again!
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/509BCDAC...@tdido.com.ar
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tomás Di Domenico
Nov 12, 2012, 9:40:02 AM11/12/12
to
I clumsily forgot to post a reference to the package repository [1] in
my previous message. My apologies.
Tom�s
[1] http://anonscm.debian.org/gitweb/?p=debian-med/python-csb.git;a=summary
On 12/11/12 15:34, Tom�s Di Domenico wrote:
> Greetings, all.
>
> After the very helpful replies I received to my first message about
> packaging the CSB library, I'm now kindly requesting a second round of
> comments on the state of the package.
>
> With the goal of having a clean repo to start with, but also willingly
> repeating some steps to better understand and learn them, I have
> recreated the git repository for the package. A consequence of this is
> that you will not be able to use the logs to see the changes since my
> first message, so here's a list of the things I did:
>
> * Rebuilt the package with an upstream release tarball
> * Added 'X-Python-Version: >= 2.6' to debian/control
> * Versioned the build-dependency on python-all (
>> = 2.6.6-3~)
> * Bumped the standard to 3.9.4
> * Bumped debhelper to 8.1.0
> * Changed debian/* license to MIT, matching upstream's
> * Added dependency on ${python:Depends}
> * Removed the empty docs file
>
> Speaking of docs, the upstream tarball contains HTML-formatted
> documentation for the module's API. How would this be handled? Should it
> be made available as a separate package?
>
> Once again, thank you all in advance.
>
> Tom�s
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/50A109AC...@tdido.com.ar
my previous message. My apologies.
Tom�s
[1] http://anonscm.debian.org/gitweb/?p=debian-med/python-csb.git;a=summary
On 12/11/12 15:34, Tom�s Di Domenico wrote:
> Greetings, all.
>
> After the very helpful replies I received to my first message about
> packaging the CSB library, I'm now kindly requesting a second round of
> comments on the state of the package.
>
> With the goal of having a clean repo to start with, but also willingly
> repeating some steps to better understand and learn them, I have
> recreated the git repository for the package. A consequence of this is
> that you will not be able to use the logs to see the changes since my
> first message, so here's a list of the things I did:
>
> * Rebuilt the package with an upstream release tarball
> * Added 'X-Python-Version: >= 2.6' to debian/control
> * Versioned the build-dependency on python-all (
>> = 2.6.6-3~)
> * Bumped the standard to 3.9.4
> * Bumped debhelper to 8.1.0
> * Changed debian/* license to MIT, matching upstream's
> * Added dependency on ${python:Depends}
> * Removed the empty docs file
>
> Speaking of docs, the upstream tarball contains HTML-formatted
> documentation for the module's API. How would this be handled? Should it
> be made available as a separate package?
>
> Once again, thank you all in advance.
>
> Tom�s
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tomás Di Domenico
Nov 12, 2012, 9:50:02 AM11/12/12
to
Greetings, all.
After the very helpful replies I received to my first message about
packaging the CSB library, I'm now kindly requesting a second round of
comments on the state of the package.
With the goal of having a clean repo to start with, but also willingly
repeating some steps to better understand and learn them, I have
recreated the git repository for the package. A consequence of this is
that you will not be able to use the logs to see the changes since my
first message, so here's a list of the things I did:
* Rebuilt the package with an upstream release tarball
* Added 'X-Python-Version: >= 2.6' to debian/control
* Versioned the build-dependency on python-all (
>= 2.6.6-3~)
* Bumped the standard to 3.9.4
* Bumped debhelper to 8.1.0
* Changed debian/* license to MIT, matching upstream's
* Added dependency on ${python:Depends}
* Removed the empty docs file
Speaking of docs, the upstream tarball contains HTML-formatted
documentation for the module's API. How would this be handled? Should it
be made available as a separate package?
Once again, thank you all in advance.
Tom�s
After the very helpful replies I received to my first message about
packaging the CSB library, I'm now kindly requesting a second round of
comments on the state of the package.
With the goal of having a clean repo to start with, but also willingly
repeating some steps to better understand and learn them, I have
recreated the git repository for the package. A consequence of this is
that you will not be able to use the logs to see the changes since my
first message, so here's a list of the things I did:
* Rebuilt the package with an upstream release tarball
* Added 'X-Python-Version: >= 2.6' to debian/control
* Versioned the build-dependency on python-all (
>= 2.6.6-3~)
* Bumped the standard to 3.9.4
* Bumped debhelper to 8.1.0
* Changed debian/* license to MIT, matching upstream's
* Added dependency on ${python:Depends}
* Removed the empty docs file
Speaking of docs, the upstream tarball contains HTML-formatted
documentation for the module's API. How would this be handled? Should it
be made available as a separate package?
Once again, thank you all in advance.
Tom�s
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/50A108E7...@tdido.com.ar
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jakub Wilk
Nov 13, 2012, 3:20:02 PM11/13/12
to
* Tomás Di Domenico <td...@tdido.com.ar>, 2012-11-12, 15:34:
>* Changed debian/* license to MIT, matching upstream's
DEP-5-compliant short license name for the MIT license is "Expat".
You don't have to repeat the license text twice; you could use a
stand-alone license paragraph.
>* Added dependency on ${python:Depends}
You could also remove ${shlib:Depends}, as the package doesn't ship any
ELF executables or shared libraries.
>* Removed the empty docs file
>
>Speaking of docs, the upstream tarball contains HTML-formatted
>documentation for the module's API. How would this be handled?
Ideally, the documentation should be rebuilt from source.
>Should it be made available as a separate package?
If the documentation is big, then putting it into a separate package is
a good idea.
Speaking of big things, the binary package is 3.8M. It looks like most
of it is the test suite. Does it make sense to include it in the binary
package?
Tests however _love_ to be run at build time! :) You might also want to
provide DEP-8 tests. (See below however.)
csb/test/data/*.pickle appear to contain pickled Python objects. Do you
know how it was created? Or in other words, where is the source for it?
Note that unpickling (which is what the test suite appears be doing)
untrusted stuff can result in execution of arbitrary code...
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012111320...@jwilk.net
>* Rebuilt the package with an upstream release tarball
Much better now. :)
>* Changed debian/* license to MIT, matching upstream's
You don't have to repeat the license text twice; you could use a
stand-alone license paragraph.
>* Added dependency on ${python:Depends}
ELF executables or shared libraries.
>* Removed the empty docs file
>
>Speaking of docs, the upstream tarball contains HTML-formatted
>documentation for the module's API. How would this be handled?
>Should it be made available as a separate package?
a good idea.
Speaking of big things, the binary package is 3.8M. It looks like most
of it is the test suite. Does it make sense to include it in the binary
package?
Tests however _love_ to be run at build time! :) You might also want to
provide DEP-8 tests. (See below however.)
csb/test/data/*.pickle appear to contain pickled Python objects. Do you
know how it was created? Or in other words, where is the source for it?
Note that unpickling (which is what the test suite appears be doing)
untrusted stuff can result in execution of arbitrary code...
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tomás Di Domenico
Nov 14, 2012, 11:00:01 AM11/14/12
to
On 13/11/12 21:17, Jakub Wilk wrote:
> * Tomás Di Domenico <td...@tdido.com.ar>, 2012-11-12, 15:34:
>> * Rebuilt the package with an upstream release tarball
>
> Much better now. :)
>
>> * Changed debian/* license to MIT, matching upstream's
>
> DEP-5-compliant short license name for the MIT license is "Expat".
>
> You don't have to repeat the license text twice; you could use a
> stand-alone license paragraph.
>> * Added dependency on ${python:Depends}
>
> You could also remove ${shlib:Depends}, as the package doesn't ship any
> ELF executables or shared libraries.
>> * Removed the empty docs file
>>
>> Speaking of docs, the upstream tarball contains HTML-formatted
>> documentation for the module's API. How would this be handled?
>
> Ideally, the documentation should be rebuilt from source.
version, they take a snapshot from their repository and build the
release tarball. This process includes the creation of the docs from
source. The tarball I use for the package, therefore, has the already
cooked HTML files, and I happily committed them to the repository.
Seeing as it's 24M of HTML files, it would most likely be a different
package. However, I assume from your comment about rebuilding from
source that it would not be as easy as taking the "docs" dir and
packaging it separately?
>> Should it be made available as a separate package?
>
> If the documentation is big, then putting it into a separate package is
> a good idea.
>
> Speaking of big things, the binary package is 3.8M. It looks like most
> of it is the test suite. Does it make sense to include it in the binary
> package?
>
> Tests however _love_ to be run at build time! :) You might also want to
> provide DEP-8 tests. (See below however.)
>
> csb/test/data/*.pickle appear to contain pickled Python objects. Do you
> know how it was created? Or in other words, where is the source for it?
>
> Note that unpickling (which is what the test suite appears be doing)
> untrusted stuff can result in execution of arbitrary code...
separation of tasks between the tarball packaging done by upstream I
described before, and my Debian packaging. Similar to the docs, the
tests are run by upstream when they build the tarball. Is it common to
also include these tests in Debian packages?
Thanks a lot for your patience, I do realize these are quite basic
questions.
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tristan Seligmann
Nov 14, 2012, 9:10:02 PM11/14/12
to
On Wed, Nov 14, 2012 at 5:42 PM, Tomás Di Domenico <td...@tdido.com.ar> wrote:
> Another blurry point. I'm having a hard time understanding the
> separation of tasks between the tarball packaging done by upstream I
> described before, and my Debian packaging. Similar to the docs, the
> tests are run by upstream when they build the tarball. Is it common to
> also include these tests in Debian packages?
In my opinion, packages should always include a test suite if
> Another blurry point. I'm having a hard time understanding the
> separation of tasks between the tarball packaging done by upstream I
> described before, and my Debian packaging. Similar to the docs, the
> tests are run by upstream when they build the tarball. Is it common to
> also include these tests in Debian packages?
available; this allows an end-user to run the test suite on their
system once the package is installed, thus allowing them to verify
that the software as installed on their system is actually functional.
Of course, running the test suite at package build time (and during
for development, for that matter) should also be done in order to
catch problems as far upstream as possible, but I think extending the
ability to test the software downstream as far as possible is also
important.
--
mithrandi, i Ainil en-Balandor, a faer Ambar
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Barry Warsaw
Nov 14, 2012, 9:40:01 PM11/14/12
to
On Nov 15, 2012, at 03:49 AM, Tristan Seligmann wrote:
>On Wed, Nov 14, 2012 at 5:42 PM, Tomás Di Domenico <td...@tdido.com.ar> wrote:
>> Another blurry point. I'm having a hard time understanding the
>> separation of tasks between the tarball packaging done by upstream I
>> described before, and my Debian packaging. Similar to the docs, the
>> tests are run by upstream when they build the tarball. Is it common to
>> also include these tests in Debian packages?
>
>In my opinion, packages should always include a test suite if
>available; this allows an end-user to run the test suite on their
>system once the package is installed, thus allowing them to verify
>that the software as installed on their system is actually functional.
>Of course, running the test suite at package build time (and during
>for development, for that matter) should also be done in order to
>catch problems as far upstream as possible, but I think extending the
>ability to test the software downstream as far as possible is also
>important.
+1
>On Wed, Nov 14, 2012 at 5:42 PM, Tomás Di Domenico <td...@tdido.com.ar> wrote:
>> Another blurry point. I'm having a hard time understanding the
>> separation of tasks between the tarball packaging done by upstream I
>> described before, and my Debian packaging. Similar to the docs, the
>> tests are run by upstream when they build the tarball. Is it common to
>> also include these tests in Debian packages?
>
>In my opinion, packages should always include a test suite if
>available; this allows an end-user to run the test suite on their
>system once the package is installed, thus allowing them to verify
>that the software as installed on their system is actually functional.
>Of course, running the test suite at package build time (and during
>for development, for that matter) should also be done in order to
>catch problems as far upstream as possible, but I think extending the
>ability to test the software downstream as far as possible is also
>important.
-Barry
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andreas Tille
Nov 15, 2012, 3:10:02 AM11/15/12
to
Hi Tom�s,
On Wed, Nov 14, 2012 at 04:42:19PM +0100, Tom�s Di Domenico wrote:
> >
> > Ideally, the documentation should be rebuilt from source.
>
> Right, things get a bit blurry for me here. When upstream releases a new
> version, they take a snapshot from their repository and build the
> release tarball. This process includes the creation of the docs from
> source. The tarball I use for the package, therefore, has the already
> cooked HTML files, and I happily committed them to the repository.
If Jakub wrote *ideally* than he most probably intended to write that we
should try to do so but there might be some good reasons to derive from
this ideal situation. I admit, I usually try to rebuild the docs in my
packages and I do at least verify that I can *reproduce* all the docs.
However, sometimes there are good reasons to simply use the
autogenerated docs from upstream. Without having checked the thing
myself your description sounds as if it could be the case here.
> Seeing as it's 24M of HTML files, it would most likely be a different
> package. However, I assume from your comment about rebuilding from
> source that it would not be as easy as taking the "docs" dir and
> packaging it separately?
IMHO the question whether you rebuild the docs from source and the fact
whether the docs will end up in a separate binary package are
orthogonal. I'm a fan if separate docs and I think 24MB are some good
reason to do this.
> Another blurry point. I'm having a hard time understanding the
> separation of tasks between the tarball packaging done by upstream I
> described before, and my Debian packaging. Similar to the docs, the
> tests are run by upstream when they build the tarball. Is it common to
> also include these tests in Debian packages?
I agree with those other to people who answered this part of your mail
that having the tests packaged and thus ready for testing by the user
at the installation target (which is simply different from testing at
upstream side) is a very good idea and should be approached. Please
also regard Jakub's (?) hint to DEP8.
On Wed, Nov 14, 2012 at 04:42:19PM +0100, Tom�s Di Domenico wrote:
> >
> > Ideally, the documentation should be rebuilt from source.
>
> Right, things get a bit blurry for me here. When upstream releases a new
> version, they take a snapshot from their repository and build the
> release tarball. This process includes the creation of the docs from
> source. The tarball I use for the package, therefore, has the already
> cooked HTML files, and I happily committed them to the repository.
should try to do so but there might be some good reasons to derive from
this ideal situation. I admit, I usually try to rebuild the docs in my
packages and I do at least verify that I can *reproduce* all the docs.
However, sometimes there are good reasons to simply use the
autogenerated docs from upstream. Without having checked the thing
myself your description sounds as if it could be the case here.
> Seeing as it's 24M of HTML files, it would most likely be a different
> package. However, I assume from your comment about rebuilding from
> source that it would not be as easy as taking the "docs" dir and
> packaging it separately?
whether the docs will end up in a separate binary package are
orthogonal. I'm a fan if separate docs and I think 24MB are some good
reason to do this.
> Another blurry point. I'm having a hard time understanding the
> separation of tasks between the tarball packaging done by upstream I
> described before, and my Debian packaging. Similar to the docs, the
> tests are run by upstream when they build the tarball. Is it common to
> also include these tests in Debian packages?
that having the tests packaged and thus ready for testing by the user
at the installation target (which is simply different from testing at
upstream side) is a very good idea and should be approached. Please
also regard Jakub's (?) hint to DEP8.
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012111508...@an3as.eu
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Tomás Di Domenico
Nov 23, 2012, 11:10:02 AM11/23/12
to
Sorry for the late reply, and thanks to everyone who contributed to this
thread.
On 15/11/12 09:01, Andreas Tille wrote:
> If Jakub wrote *ideally* than he most probably intended to write that we
> should try to do so but there might be some good reasons to derive from
> this ideal situation. I admit, I usually try to rebuild the docs in my
> packages and I do at least verify that I can *reproduce* all the docs.
> However, sometimes there are good reasons to simply use the
> autogenerated docs from upstream. Without having checked the thing
> myself your description sounds as if it could be the case here.
> I agree with those other to people who answered this part of your mail
> that having the tests packaged and thus ready for testing by the user
> at the installation target (which is simply different from testing at
> upstream side) is a very good idea and should be approached. Please
> also regard Jakub's (?) hint to DEP8.
Right. I've contacted upstream regarding the pickled files Jakub brought
up in a previous message. I'm also looking at the autopkgtest docs I can
find, trying to figure it out. Could anyone point me to some python
packages using this kind of automated testing? If you'd rather teach me
how to fish, I'd be very interested in learning about the best way to
search packages for specific content in the "debian/*" files. In this
case, for example, search for "XS-Testsuite: autopkgtest" and "python"
or something of the sort. (Wishful thinking, maybe?)
Tomás
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/50AF9BFF...@tdido.com.ar
thread.
On 15/11/12 09:01, Andreas Tille wrote:
> If Jakub wrote *ideally* than he most probably intended to write that we
> should try to do so but there might be some good reasons to derive from
> this ideal situation. I admit, I usually try to rebuild the docs in my
> packages and I do at least verify that I can *reproduce* all the docs.
> However, sometimes there are good reasons to simply use the
> autogenerated docs from upstream. Without having checked the thing
> myself your description sounds as if it could be the case here.
> IMHO the question whether you rebuild the docs from source and the fact
> whether the docs will end up in a separate binary package are
> orthogonal. I'm a fan if separate docs and I think 24MB are some good
> reason to do this.
Great, seems like a separate package would be the way to go then.
> whether the docs will end up in a separate binary package are
> orthogonal. I'm a fan if separate docs and I think 24MB are some good
> reason to do this.
> I agree with those other to people who answered this part of your mail
> that having the tests packaged and thus ready for testing by the user
> at the installation target (which is simply different from testing at
> upstream side) is a very good idea and should be approached. Please
> also regard Jakub's (?) hint to DEP8.
up in a previous message. I'm also looking at the autopkgtest docs I can
find, trying to figure it out. Could anyone point me to some python
packages using this kind of automated testing? If you'd rather teach me
how to fish, I'd be very interested in learning about the best way to
search packages for specific content in the "debian/*" files. In this
case, for example, search for "XS-Testsuite: autopkgtest" and "python"
or something of the sort. (Wishful thinking, maybe?)
Tomás
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dmitry Shachnev
Nov 28, 2012, 11:20:03 AM11/28/12
to
On Fri, Nov 23, 2012 at 7:53 PM, Tomás Di Domenico <td...@tdido.com.ar> wrote:
>
> Right. I've contacted upstream regarding the pickled files Jakub brought
> up in a previous message. I'm also looking at the autopkgtest docs I can
> find, trying to figure it out. Could anyone point me to some python
> packages using this kind of automated testing? If you'd rather teach me
> how to fish, I'd be very interested in learning about the best way to
> search packages for specific content in the "debian/*" files. In this
> case, for example, search for "XS-Testsuite: autopkgtest" and "python"
> or something of the sort. (Wishful thinking, maybe?)
>
> Tomás
Nobody wants to show his dep-8 tests, so I'll show mine:
>
> Right. I've contacted upstream regarding the pickled files Jakub brought
> up in a previous message. I'm also looking at the autopkgtest docs I can
> find, trying to figure it out. Could anyone point me to some python
> packages using this kind of automated testing? If you'd rather teach me
> how to fish, I'd be very interested in learning about the best way to
> search packages for specific content in the "debian/*" files. In this
> case, for example, search for "XS-Testsuite: autopkgtest" and "python"
> or something of the sort. (Wishful thinking, maybe?)
>
> Tomás
http://anonscm.debian.org/viewvc/python-modules/packages/python-markdown/trunk/debian/tests/
http://anonscm.debian.org/viewvc/python-modules/packages/pygments/trunk/debian/tests/
(the latter is actually Piotr's package with my tests).
If you want some documentation, read:
http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;f=doc/README.package-tests;hb=HEAD
http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
--
Dmitry Shachnev
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages