Bug#826063: RFS: libu2f-host/1.0.0-2 [NMU] [RC] -- U2F host communication library
Control: tags -1 - moreinfo
Hi Adam,
Sorry for having been kept away from this bug for the last few weeks;
life happened :(
On Thu, Jun 02, 2016 at 06:48:41AM +0200, Adam Borowski wrote:
> control: tags -1 moreinfo
>
> On Thu, Jun 02, 2016 at 01:31:02AM +0200, Nicolas Braud-Santoni wrote:
> >
> > The dsc and build artifacts can be found in
> > https://nicolas.braud-santoni.eu/tmp/deb/
>
> The dsc there doesn't unpack -- filenames nor checksums don't match.
I'm not entirely sure what you mean there about a filename mismatch.
In anycase, it turns out I was building on a machine with faulty memory,
so the checksums mismatch might have been caused by this.
> Only one of four commits atop of debian/1.0.0-1 looks relevant:
> 40d4511 has the following changes:
> + updated build-dependencies (ie, the meat of the NMU)
> + standards version bump
> + a changelog entry (with an error: you need # after "Closes: " before the
> number)
>
> e12e613 adds an UNRELEASED changelog entry and some gbp junk.
Indeed. I failed to clean this up while removing so-far-unreleased
versions.
> 3d0722a tries to invent a way of generating "orig" tarballs.
> + this is bad as those don't match upstream. Besides details like losing
> timestamps or degrading xz to gz, you really should use what upstream
> provides, unless this is impossible because of git-only releases or a
> need to repack.
> + not using upstream tarballs ie especially bad as these are signed
Yes, I didn't realise that the upstream packages were not from
https://github.com/Yubico/libu2f-host/releases but from
https://developers.yubico.com/libu2f-host/Releases/
(The rule that was added did reproduce the packages in
https://github.com/Yubico/libu2f-host/releases)
> 4e6802c tries to ignore changes in a generated file instead of properly
> cleaning it (deletion would suffice)
>
> On the other hand, something in clean-up after build does happen to break
> the package. If you try to package the source from a fresh repository, it
> succeeds. After a build, newly repacked source won't build anymore:
I'm not entirely sure what goes wrong there.
Is it even within the scope of this NMU, given that it is a
pre-existing problem unrelated to the RC bug I am fixing?
I uploaded a new set of files to the same directory:
https://nicolas.braud-santoni.eu/tmp/deb/
Note that the version number changed: it was following a previous
UNRELEASED version, which could have led to it being preferred to
a later release from the maintainer.
Best,
nicoo
PS: Sorry for the double-sending:
the first mail was sent to you but not to the BTS...
Reply to: