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 <ro...@users.sf.net> > > License: > > Artistic-2.0 > > > > Files: Misc/maemo2pwsafe.pl Copyright: 2012-2014 Rony Shapiro > > <ro...@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 < > > kris...@tima.net> > > 2006-2012 Arseny Kapoulkine <arseny.kapoulk...@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