[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