[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: I would like to submit a package to debian-med



Hi Jorge,

On Tue, Dec 03, 2013 at 03:23:20PM +0000, Jorge Sebastião Soares wrote:
> > packaging code.  Serving as proxy in case of things we would like to
> > ask upstream at Sanger and so on.
> >
> >
> I'm happy to help in that role.

:-)

> Also, now with Sascha Steinbiss (working by my side and helping a lot in
> the creation of the snp-sites package), there might be a chance of creating
> critical mass here at Sanger.

This would be cool.  I just had some conversation with Sascha about this.

> Let's keep this line of conversation open.

+1
 
> > Sure - you probably can not deal with all Sanger faculties.
> >
> Maybe we could actually create a group here, establish a mailing list and
> this would in turn advertise the existence of a Debian group on site to the
> other faculties.

I have no idea how feasible this might be but you can surely use the
Debian Med mailing list for all issues that are unproblematic for open
discussion.  I'd recommend this since you will probably profit from
Sanger external users here on this list.

> > There used to be official Debian developers at Sanger but they did not
> > played an important role here inside the Debian Med team
> > (unforutunately).
> 
> I guess they were extremely busy with other tasks... :(
> 
> :)

I was far from any allegation here - just telling you to perhaps get
your GPG key signed or something like this..  I met two of them at
DebConf 7 in Edinburgh and whatever they do this is perfectly fine. :-)

> > > >
> > > >    https://github.com/sanger-pathogens/snp_sites
> > > >Just do some
> >
> >     git tag 0.1
> >     git push --tags
> >
> > would be perfectly sufficient (If I'm not totally wrong - I do not use
> > github).  can you publish your work you mentioned at some place to let
> > us have a look?
> >
> >
> I've done that already, but I still need to decide with the upstream
> developer which version does he want to be the first.
> He had already tagged it as version 1.0.

Ahh, OK.  Feel free to commit whatever your state of packaging is to
git.debian.org and we'll have a look.
 
> > I agree that making it the most simple is a good way to start.  So in
> > principle there is nothing wrong with your approach.
> >
> Brilliant.
> I actually have a binary debian package with me at the moment.
> Again, Sascha has pointed me in the right direction many times for the past
> couple of days.

I guess it is nice to have a mentor right in the same room. :-)

> > That's very cool if we can meet in Stonehaven!!!
> >
> It will indeed. :)
> 
> As for the package, I have a couple of questions.
> As instructed by Sascha, I have run lintian over the snp-sites package.
> 
> This is the output I get (notice the new version number on the package
> name. This will all be made uniform before official deployment):
> 
> js21@builder:~/tinker/snp_sites-1$ lintian /tmp/snp-sites_1-1_amd64.deb
> ...
> E: snp-sites: file-directly-in-usr-share usr/share/string_cat.h
> E: snp-sites: file-directly-in-usr-share usr/share/vcf.h
> ...
> I was wondering if it would be better to define:
> 
>    /usr/share/snp-sites/
> 
> Has the place holder for the header files rather than bluntly on /usr/share/
> 
> I would like to hear/read your thoughts on this.

Without having seen your packaging I can only give poor advise.  In any
case lintian expects *.h files in /usr/include (or any of its
subdirectories) and having these in /usr/share sounds suspicious
especially having something *directly* in /usr/share (and not in a
subdirectories) is something you need to prevent in any case.

> Sascha has advised me to use asciidoc as a step in the rules file to
> convert the .txt manpages ( that I haven't written yet ), into actual
> manpages. Again this will be adressed before official release.

I think the official upstream release is totally orthogonal to the
Debian packaging.  I hope Sascha told you that you should not include
any debian/ dir in your upstream release tarball.  (Please ask here
if it is not clear why.)

> I have also tried to run piuparts on the recently crerated
> snp-sites_1-1_amd64.deb in this fashion:
> 
> js21@builder:~/tinker/snp_sites-1$ sudo piuparts -b
> /var/cache/pbuilder/sid-amd64-base.tgz /tmp/snp-sites_1-1_amd64.deb
> 
> But it keeps complaining about the lack of a CD-ROM. Here's the output I
> got:
> 
> js21@builder:~/tinker/snp_sites-1$ sudo piuparts -b
> /var/cache/pbuilder/sid-amd64-base.tgz /tmp/snp-sites_1-1_amd64.deb
> [sudo] password for js21:
> Guessed: debian
> ...

Ahhh, excelent.  A new user using piuparts - that's great!  I admit I
never used piuparts (even if I'm aware I should!) and so I can not give
any helpful advise.  Guessed by gut feeling a missing cdrom means some
broken /etc/apt/sources.list pointing to cdrom rather than somewhere
else but for the moment you can safely skip this step as long as your
serious problems in lintian are remaining.
 
> I wonder if I need to do something else to get piuparts to run properly on
> this package.

As I said - I have no idea.  Let delay this step.

> If this is not the proper channel for all this, I am sorry.

This channel is perfectly OK.  Please commit your packaging soon to
git.debian.org to let others have a look.

Kind regards

      Andreas.

-- 
http://fam-tille.de


Reply to: