[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, Jan 07, 2014 at 12:01:42PM +0000, Jorge Sebastião Soares wrote:
> > If you write to Debian mailing lists people will even tell you that you
> > should only reply to the list and not to the poster.  For sure we are
> > tolerant to newbies ... but in principle I do not need another copy of a
> > mail in my inbox. :-)
> 
> Fair enough.
> This is what I should have done in the first place.
> Sorted now.

:-)
 
> > > I have managed to build the package with:
> > >
> > > git-buildpackage --git-pbuilder --git-arch=amd64 --git-dist=sid
> > > --git-ignore-new
> >
> > BTW, there is no need to explicit these options since all except the
> > last one are default and the last one is redundant for a fresh pull
> > without changes.
> 
> Cool.
> There's a lot to read and lots of tools for the same sort of purpose. I'm
> getting to grips with it...

Yep.  In general I'm personally very bad in remembering options and in
case there are really some options needed in close to all cases you can
specify these in configuration files.  These 'musts' are mentioned in
the Debian Med team policy document and you only need

   git-buildpackage [--git-ignore-new]

> > You mean to rename the directory, not the tarball, right?
> > Dpkg-buildsource is clever enough to deal with this automatically.  The
> > point is that the files are *really* missing in the master branch while
> > they are inside upstream branch.  You should not change the upstream
> > files in the master branch but just add the debian/ dir.  Somehow the
> > repository is mixed up - and I really have no idea why it would build at
> > your side.  What happens if you clone from scratch and try
> > git-buildpackage?
> >
> 
> I have not tried this. I will try it now and report back.
> Just to be clear, cloning from scratch from the git snp_sites project, not
> from the debian git project, right?

What I meant was:

   gbp-clone ssh://git.debian.org/git/debian-med/snp-sites.git 
   cd snp-sites
   git-buildpackage

If this would work on your side I would be quite astonished.  In case you
might realise some differences to your local clone this might explain why
it works for you.

> > > So it seems that the upstream tarball is definitely not what pdebuild or
> > > git-buildpackage are expecting.
> >
> > It is rather that the *content* of the directory is different from the
> > tarball and this is hat the build log is telling you.
> 
> I understand.
> 
> 
> > > I'm not exactly inventing, but I get your point.
> >
> > Yes - I wrote "inventing" because your internal knowledge is in advance
> > to what outsiders can really see.
> 
> Sure. :)
> 
> > > At this point, version 1 is the only public version.
> > > I'll see what I can do to properly tag the snp-sites code.
> >
> > Just advise (or if you have commit permission to upstream do it yourself)
> > to tag the upstream repository with `git tag 1` (or `git tag 1.0` which
> > would be more convinient tagging).
> 
> I will do this now.
> I do have commit permission.

That's good.
 
> > > I have dropped the git project entirely and have recreated it.
> > > So, can you tell me...
> > > If I'd tag the snp-sites project with version 1.0, would the tag be
> > > appended to the package name? And would it conform to the Debian
> > standard?
> >
> > If I were you I would wait until upstream is tagged properly.  Once this
> > is done do
> >
> >
> > $ uscan --verbose --report
> > -- Scanning for watchfiles in .
> > -- Found watchfile in ./debian
> > -- In debian/watch, processing watchfile line:
> >    https://github.com/sanger-pathogens/snp_sites/tags
> >  /sanger-pathogens/snp_sites/archive/([.\d]+)\.tar\.gz
> > -- Found the following matching hrefs:
> >      /sanger-pathogens/snp_sites/archive/0.1.tar.gz
> > Newest version on remote site is 0.1, local version is 1
> >  => remote site does not even have current version
> > -- Scan finished
> >
> > If this is reporting 1 (or 1.0) you can do `uscan --force-download`
> > which creates a valid and properly named tarball.  Once you have this
> > tarball you can import it using
> >
> >    git import-orig --pristine-tar
> >
> > as it is written in our policy document and later simply add the debian/
> > dir.  This workflow usually leads to a properly buildable repository.
> >
> 
> Brilliant!
> Thanks Andreas. I will do this now.

Just let us know in case you might face more stumbling stones.

Kind regards

       Andreas.


-- 
http://fam-tille.de


Reply to: