[Debian-med-packaging] Inconsistencies in pristine-tar of several packages

Andreas Tille andreas at an3as.eu
Mon May 19 19:20:39 UTC 2014


Hi Roland,

On Mon, May 19, 2014 at 08:48:22PM +0200, rf at q-leap.de wrote:
>     Andreas> I have no idea as well.  I'm just blindly following our
>     Andreas> team policy document git hints and doing
> 
>     Andreas>    git import-orig --pristine-tar <tarball>
> 
>     Andreas> expecting it to work nicely (and never observed a problem
>     Andreas> in the described workflow).
> 
> I just tested with "git import-orig --pristine-tar bambamc_0.0.50.tar.gz"
> after which the id in bambamc_0.0.50.orig.tar.gz.id is correct and
> corresponds to the commit of the upstream import. So git-buildpackage is
> doing the right thing but something fishy must have been going on with
> the repos after importing the upstream source which lead to the loss of
> some commits. Anybody done some history rewriting?

I can not seriosly believe this.  The repository is quite new and from
the log I'm the only commiter.  I would have probably noticed any other
commits.  So I must most probably claim responsibility for this problem
even if I have no idea at all in how far I did this - definitely not
manually nor intentionally.
 
>     >> - Shouldn't we fix bambamc_0.0.49.orig.tar.gz.id to contain the
>     >>   correct
>     >> commit $(git show-ref --tags -s upstream/0.0.49)
> 
>     Andreas> Well, I'm fine with anything that is fixing a potential
>     Andreas> issue (even if I can not really see in what situation this
>     Andreas> could cause a problem).
>  
> OK, so if you don't mind, I will fix bambamc_0.0.49.orig.tar.gz.id (+
> the other affected packages) and commit to alioth.

Just go for it.
 
> On another note. Shall I commit an update to the new bambamc upstream
> version as well? When I do a backport, I usually like to do it for the
> most recent version, unless there are reasons speaking against it.

Definitely!  Feel free to push any enhancement to any package you are
noticing.  Please keep the target distribution "UNRELEASED".  Usually I
will notice this since I'm reading the commit mailing list and will
react as soon as possible.  (Just for the record:  I'll be on vac from
23.5. - 2.6.  but if needed you will hopefully find some other sponsor.)
 
>     Andreas> I'm fine with any enhancement that might make things
>     Andreas> cleaner.  However, we should also document in our policy
>     Andreas> document what to do and how to prevent this issue in the
>     Andreas> future.
>  
> I'm thinking about how to add checks for such kind of things. Here at
> Q-Leap, we notice it automatically when using our package create scripts.

Well, there are a lot of tools you could check.  For instance there is
UDD dashboard:

   http://udd.debian.org/dmd/?email1=debian-med-packaging%40lists.alioth.debian.org

There is the QA team package overview

   http://qa.debian.org/developer.php?login=debian-med-packaging@lists.alioth.debian.org&ordering=3

You can also use the tasks pages - if something is colored yellow there
is something to do:

   http://blends.debian.org/med/tasks/bio-dev#libbambamc-dev

and you can also run uscan in a cron job and let it send you an e-mail.
I also have code written that scans UDD for upgradable software of a
blend and send an e-mail to the team which is in a "close to be
finished" state for about two years. :-(

Probably there are even more tools (Package Entropy Tracker = PET comes
to mind) which could be effectively used.

Hope this helps

      Andreas.

-- 
http://fam-tille.de



More information about the Debian-med-packaging mailing list