[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#745126: RFS: passwordsafe/0.95.1+dfsg-1



Hi Bill,

Am Mittwoch, den 23.09.2015, 22:36 -0400 schrieb Bill Blough:

> Thanks so much for all the feedback.
> On Wed, Sep 23, 2015 at 11:03:01PM +0200, Tobias Frost wrote:
> > 
> > - d/source/options: Why do you have the option diff-ignore?
> 
> 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.  I did quite a bit of searching
> on how to
> deal with it, but that was the only solution I found.  Is there a
> better way to
> handle it
> ?

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)

> > - d/patches are marked as Forwarded: no and not-needed. Are they
> > really
> > not upstreamable?
> 
> The pixmap patch I could forward, but with the menu/.desktop change,
> I think I
> can go ahead and remove it since the pixmap won't be needed. (desktop
> can use
> the existing png, whereas menu couldn't)
> 
> 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...

> 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"

> - please use wrap-and-sort; this will also remove those trailing
> > whitespaces I love to nitpick about...
> 
> Done.
> 
> > 
> > - Well, README.LINUX does not really have information for the user
> > beside it's beta, so I'd not install it but explain in the package
> > description that not all features are implemented
> 
> Done.
> 
> > 
> > - I would not install both the html and txt version of
> > docs/ReleaseNotes, they have identical content. Also, this seems to
> > be
> > the project's changelog, so it should be installed with
> > dh_installchangelog and not via dh_installdocs. Therefore it should
> > also not be registered using doc-base
> 
> Done.  Note, I created an override for dh_installchangelogs to keep
> (symlink)
> the original name, since it's referred to by name in README.txt.-
> d/menu should be depreciated in favour of .desktop files, so remove
> > this file. See also #741573
> 
> Done. That was an interesting read, thanks :-) 
> > 
> > - the chm file you refer in your source override -- I guess  it is
> > not
> > built at build time. We need to build everything from source... Can
> > you
> > simply remove it? 
> 
> Upon further inspection, I don't think we actually need it.  Removed
> via
> d/copyright Files-Excluded
> 
> > That's how far I come... Will continue as soon as possible
> 
> Really appreciated, thanks!

Continueing:

d/rules: DEB_BUILD_OPTIONS: With debhelper compat 9, it should not be
necessary to specify hardening.

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) ... 

There is an embedded code copy: pugixml -- please use the packaged
version if possible.

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?

 
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


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 guess that's it for now! Let me know when you are ready for the next
iteration :)

Tobi


Reply to: