Bug#745126: RFS: passwordsafe/0.95.1+dfsg-1
Am Samstag, den 10.10.2015, 20:44 -0400 schrieb Bill Blough:
> On Fri, Sep 25, 2015 at 10:38:14PM +0200, Tobias Frost wrote:
> > > Issues with the translation files - When the .mo files get
> > > generated,
> > > the .po files get updated with a new timestamp, causing repeat
> > > builds from
> > > the same source to fail the dpkg-source check.
> >
> > That's ugly and I guess should be patched away...
> > Probably you want to patch in a way that the po files are not
> > updated:
> > Those files are supposed to be sent to translators and the use to
> > update them during build is limited.
> >
> > (I missed that additional note before: You should never use diff
> > -ignore; if it'd be extend-diff-ignore (see dpkg-source(1));
> > otherwise
> > e.g changes in the git repository will also break the build.)
> >
> > And as I saw a reference to the build date in one of the po's:
> > To make the reproducible builds happen, those should be eliminated.
> > (To find them, add temporarily -Werror=date-time to your compiler
> > flags)
>
> Looking at it further, it's not just the timestamps, but rather, it's
> rescanning all of the source for gettext strings, and then updating
> the po
> files. I'm not sure if this is intentional, or an oversight in the
> way the
> makefile is written. The simple fix seems to be to touch the po
> files before
> the build so make doesn't try to rebuild them. This is what I have
> done for
> now.
> > > - d/patches are marked as Forwarded: no and not-needed. Are they
> > > r eally
> > > not upstreamable?
> > >
> > > The path patch is for compliance with the FHS, so I think it's
> > > Debian
> > > -specific
> > > since not all distributions follow the FHS.
> >
> > Try it to send it upstream :) Every patch you do not need to carry
> > around will reduce your work needed on the package...
>
> I forwarded the path patch and also another patch that I forgot about
> relating
> to compiler flags.
>
> >
> > > The gcc5 fix is cherry picked from an upstream commit, so there's
> > > no
> > > need to
> > > forward it. When the next upstream release is made for Linux,
> > > I'll
> > > be able to
> > > remove it.
> >
> > Record that in the dep3 header "Origin"
>
> I had the info in the Applied-Upstream header, but also added it to
> Origin as
> you suggested.
Ah, yes. However Applied-Upstream is to document when a patch have been
applied upstream, not when cherry-picking from upstream; for the latter
you use Origin.
Please also note that Applied-Upstream should be either a URL or
prefixed with "commit:".
(See the dep3 spec)
> > d/rules: DEB_BUILD_OPTIONS: With debhelper compat 9, it should not
> > be
> > necessary to specify hardening.
>
> I think this was left over from when I was troubleshooting build
> issues.
> Removed.
> >
> > As you are already repacking for dfsg reasons, you can also remove
> > some
> > other cruft: Codeblocks settings, CodeLite IDE settings, XCode,
> > Visual
> > Studio solutions file (the old-sln directory) ...
>
> Not having done a source repackage before, I tried to keep the
> changes minimal.
> But if it's acceptable to remove anything we don't need, I'm happy to
> do it,
> and have done so.
>
> >
> > There is an embedded code copy: pugixml -- please use the packaged
> > version if possible.
>
> I attempted to remove the embedded copy and use the packaged version,
> but it
> looks like the packaged version isn't compatible, as it's built for
> char
> instead of wchar_t. Trying to use it yields lots of undefined
> references when
> linking. I can talk to the maintainer about the possibility of
> packaging both
> versions of the library, but until that happens, the embedded version
> may have
> to stay.
>
Ok, but please file a wishlist bug against pugixml asking to provide an
flavour with w_char enabled.
Note that you should also inform the security team about the code copy
and that there is currently no other way. See
https://wiki.debian.org/EmbeddedCodeCopies
> > The README for Linux developers tells something about Yubi-Key
> > support when
> > there is libykpers availbale. This package is available in Debian,
> > but you do
> > not build-depend on it. Is this intentional?
>
> Build-depends already includes libykpers-1-dev, but the docs say that
> libyubikey-dev is also needed, so I've added that as well.
> >
> >
> > d/copyright:
> >
> > Files: * Copyright: 2003-2014 Rony Shapiro <ronys@users.sf.net>
> > License:
> > Artistic-2.0
> >
> > Files: Misc/maemo2pwsafe.pl Copyright: 2012-2014 Rony Shapiro
> > <ronys@users.sourceforge.net> License: Artistic-2.0
> >
> > You can join such paragraphs, even if the email is different.
> >
> >
> > Files: src/core/pugixml/* Copyright: 2003 Kristen Wegner <
> > kristen@tima.net>
> > 2006-2012 Arseny Kapoulkine <arseny.kapoulkine@gmail.com ^^ should
> > be
> > 2006-2014
> >
> Done.
>
> >
> > There are files in src/core, which have previous copyright, like
> > TwoFish.cpp,
> > SHA1.cpp or SHA256.cpp (only files I checked, please check all
> > files)
> >
> > (I know. Copyright check is tedious work, but usually you only need
> > to check
> > it once. But we need to, this is very important to check every
> > file)
>
> I've gone through all of the files and added the additional info to
> d/copyright.
>
>
> > I guess that's it for now! Let me know when you are ready for the
> > next
> > iteration :)
>
> Upstream just released a new Linux build, so I just uploaded the new
> version,
> along with all of the changes I've made based on your feedback.
>
>
> Bill
>
Looks good so far;
I still need to complete copyright review, I'll let you know when I
need something.
PS: You removed the signing key on purpose? Why?
Tobi
Reply to: