Re: I would like to submit a package to debian-med
Hi Jorge,
On Tue, Jan 07, 2014 at 11:04:39AM +0000, Jorge Sebastião Soares wrote:
> Gmail defaults to reply instead of reply all...
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. :-)
> > > aborting
> > > dpkg-buildpackage: warning: (Use -d flag to override.)
> > > debuild: fatal error at line 1357:
> > > dpkg-buildpackage -rfakeroot -D -us -uc -i -I failed
> > > gbp:error: Couldn't run 'debuild -i -I': debuild -i -I returned 29
> >
> > Hmmm, this is just an unmet build depends which is strange since
> > it should not be needed for the clean target.
>
>
> 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.
> >
> >
> > It seems the clean target is totally broken or the upstream tarball is
> > somehow wrong. I never have faced such a problem before.
> >
>
> What happens if you rename the original tarball to:
>
> snp-sites_1?
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?
> 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 think so. You should not simply invent a version number if upstream
> > does not provide versioned tarballs. You should ask upstream for doing
> > proper tags for a release since we can not be sure that if upstream does
> > some changes before a final 1 (or 1.0??) release we will have identical
> > tarballs when doing a later checkout.
> >
>
> 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.
> 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).
> > > Also, should I add the debian folder to the upstream git project?
> >
> > Oh nooooooo. ;-)
> > We are *really* happy that there is no such debian/ dir since in the
> > past we had to deal with wrong / broken / outdated packaging stuff in
> > such dirs and we regularly advise upstream to delete this if possible.
> >
>
> Sounds sensible. I just had to ask. :)
Asking is perfectly fine.
> 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.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: