Bug#745126: RFS: passwordsafe/0.95.1+dfsg-1
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
> > > really
> > > 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.
>
>
> 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.
>
> 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
Reply to: