Re: Advise on packaging a new Python module

[Tomás Di Domenico]

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!

On 08/11/12 15:28, Thomas Kluyver wrote:
> On 8 November 2012 14:15, Andreas Tille  > 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


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/509bcdac.3060...@tdido.com.ar

Re: Advise on packaging a new Python module

[Thomas Kluyver]

On 8 November 2012 14:15, Andreas Tille  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

Re: Advise on packaging a new Python module

[Andreas Tille]

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-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121108141530.go17...@an3as.eu

Re: Advise on packaging a new Python module

[Simon McVittie]

On 07/11/12 16:06, Tomás Di Domenico wrote:
> On 07/11/12 16:43, Jakub Wilk wrote:
>> * Tomás Di Domenico , 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.

If you find yourself needing to do that, you should indicate it in the
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.

I use snapshots of ioquake3 to have a codebase that's somewhere close to
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-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/509a96e2.2070...@debian.org

Re: Advise on packaging a new Python module

[Tomás Di Domenico]

Right, that's what I meant. Poor wording on my side, sorry about that.

Thanks!

On 07/11/12 17:25, Dmitry Shachnev wrote:
> On Wed, Nov 7, 2012 at 3:30 PM, Tomás Di Domenico  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
> 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-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/509a8c11.4050...@tdido.com.ar

Re: Advise on packaging a new Python module

[Tomás Di Domenico]

On 07/11/12 16:43, Jakub Wilk wrote:
> * Tomás Di Domenico , 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.

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

Sure: so the situation right now is that I used an upstream revision
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-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/509a86fb.1070...@tdido.com.ar

Re: Advise on packaging a new Python module

[Dmitry Shachnev]

On Wed, Nov 7, 2012 at 3:30 PM, Tomás Di Domenico  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
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-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKimPHVqys0arDu470C-pLN=5sgqzd-h5mc9esxexscci1i...@mail.gmail.com

Re: Advise on packaging a new Python module

[Jakub Wilk]

* Tomás Di Domenico , 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?


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121107154306.ga3...@jwilk.net

Re: Advise on packaging a new Python module

[Tomás Di Domenico]

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 , 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-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/509a4661.5050...@tdido.com.ar

Re: Advise on packaging a new Python module

[Jakub Wilk]

* Dmitry Shachnev , 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

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121107094935.ga2...@jwilk.net

Re: Advise on packaging a new Python module

[Dmitry Shachnev]

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  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-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cakimphwaav+ie4t7t9wjlpuictyhke_rnvtuh4wif2hc+9y...@mail.gmail.com

Re: Advise on packaging a new Python module

[Jakub Wilk]

* Tomás Di Domenico , 2012-11-04, 15:43:
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. ;)


[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-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121106212752.ga4...@jwilk.net

Advise on packaging a new Python module

[Tomás Di Domenico]

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-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50967f26.9040...@tdido.com.ar