[Reproducible-builds] Bug#794740: camitk: please make the build reproducible (timestamps)

2015-08-05 Thread Maria Valentina Marin
Source: camitk
Version: 3.4.0-2
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that camitk could not be built reproducibly since it uses timestamps in
its manpage output.

The attached patch makes camitk use the environment variable
$SOURCE_DATE_EPOCH [2], which was proposed by the Debian reproducible
builds team as a way to still have timestamps in documentation but make
them be reproducible.

The value of the timestamp will be set to the latest entry in
debian/changelog.


Kind Regards,
akira

[1] https://wiki.debian.org/ReproducibleBuilds/About
[2] https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal
diff -Nru camitk-3.4.0/debian/changelog camitk-3.4.0/debian/changelog
--- camitk-3.4.0/debian/changelog   2015-06-20 11:51:04.0 +0200
+++ camitk-3.4.0/debian/changelog   2015-08-04 13:20:50.0 +0200
@@ -1,3 +1,10 @@
+camitk (3.4.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to use SOURCE_DATE_EPOCH
+
+ -- akira   Tue, 04 Aug 2015 13:20:28 +0200
+
 camitk (3.4.0-2) unstable; urgency=low
 
   * Fix cmake missing path to ITKConfig (patch force-path-to-itkconfig)
diff -Nru camitk-3.4.0/debian/patches/series camitk-3.4.0/debian/patches/series
--- camitk-3.4.0/debian/patches/series  2015-06-20 11:51:04.0 +0200
+++ camitk-3.4.0/debian/patches/series  2015-08-04 13:20:23.0 +0200
@@ -1,2 +1,3 @@
 remove-doxygen-timestamp
 force-path-to-itkconfig
+Use-SOURCE_DATE_EPOCH
diff -Nru camitk-3.4.0/debian/patches/Use-SOURCE_DATE_EPOCH 
camitk-3.4.0/debian/patches/Use-SOURCE_DATE_EPOCH
--- camitk-3.4.0/debian/patches/Use-SOURCE_DATE_EPOCH   1970-01-01 
01:00:00.0 +0100
+++ camitk-3.4.0/debian/patches/Use-SOURCE_DATE_EPOCH   2015-08-05 
11:15:42.0 +0200
@@ -0,0 +1,26 @@
+Description: Use SOURCE_DATE_EPOCH to produce reproducible timestamps in 
manpages
+
+--- a/sdk/cmake/modules/CamiTKConfig.cmake.in
 b/sdk/cmake/modules/CamiTKConfig.cmake.in
+@@ -225,10 +225,17 @@ mark_as_advanced (CAMITK_CORE_LIB CAMITK
+ # additional unix system resources
+ if (UNIX)
+ # only possible on unix
+-execute_process(COMMAND "date" "+%Y-%m-%d"
+-OUTPUT_VARIABLE CURRENT_DATE
+-OUTPUT_STRIP_TRAILING_WHITESPACE
+-)
++if(DEFINED ENV{SOURCE_DATE_EPOCH})
++execute_process(COMMAND "date" "-u" "+%Y-%m-%d" 
"--date=@$ENV{SOURCE_DATE_EPOCH}"
++OUTPUT_VARIABLE CURRENT_DATE
++OUTPUT_STRIP_TRAILING_WHITESPACE
++)
++else()
++execute_process(COMMAND "date" "+%Y-%m-%d"
++OUTPUT_VARIABLE CURRENT_DATE
++OUTPUT_STRIP_TRAILING_WHITESPACE
++)
++endif()
+ # Application man pages (always in section 1, this is an application...)
+ set(CAMITK_APPLICATION_MAN_INSTALL_DIR "share/man/man1") 
+ # Desktop file always in share/applications (freedesktop standard)


signature.asc
Description: OpenPGP digital signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Notifications for Reproducible Builds

2015-08-05 Thread Kenneth Pronovici
Hi,

I was poking around (https://reproducible.debian.net/index_notify.html) and
realized that I can get notifications if/when my packages change state.
Could you please enable notifications?   My packages are:

cedar-backup2
cedar-backup3 (sitting in NEW queue)
cproto
epydoc
gtml
ncompress
pychecker
sopwith

I believe all of these except ncompress are reproducible already.  I
uploaded changes to ncompress today which should make v4.2.4.4-12
reproducible.

Thanks,

KEN

-- 
Kenneth J. Pronovici 
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] Bug#792687: gettext: please support timestamps from environment

2015-08-05 Thread Dhole
On 07/17/2015 04:08 PM, Dhole wrote:
> Source: gettext
> Version: 0.19.4-1
> Severity: wishlist
> Tags: patch
> User: reproducible-builds@lists.alioth.debian.org
> Usertags: toolchain timestamps
> X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
> 
> Hi,
> 
> While working on the "reproducible builds" effort [1], we have noticed
> that the xgettext tool from gettext embeds timestamps on the creation of
> PO files.
> 
> For the Reproducible Builds effort we are proposing an environment
> variable (SOURCE_DATE_EPOCH) [2] that will contain a deterministic epoch
> timestamp (based on the latest debian/changelog entry) that could be
> used, which should be automatically exported by debhelper in the future [3].
> 
> The attached patch proposes a way to use this variable to get
> reproducible timestamps in the PO files generated by xgettext, if the
> variable has been set (if not, it falls back to the old behavior).
> With the attached patch packages using xgettext would then automatically
> generate reproducible translation files.
> 
> 
> [1]: https://wiki.debian.org/ReproducibleBuilds
> [2]: https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal
> [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791815
> 
> Regards,
> 
> 
> 
> ___
> Reproducible-builds mailing list
> Reproducible-builds@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
> 

Hi

I'm attaching an update of the submitted patch targeting the latest
gettext version from Debian: 0.19.5.1-1

Regards,
-- 
Dhole
diff -Nru gettext-0.19.5.1/debian/changelog gettext-0.19.5.1/debian/changelog
--- gettext-0.19.5.1/debian/changelog   2015-08-02 21:41:33.0 +0200
+++ gettext-0.19.5.1/debian/changelog   2015-08-04 18:44:31.0 +0200
@@ -1,3 +1,11 @@
+gettext (0.19.5.1-1.0~reproducible1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for reproducible builds by using $SOURCE_DATE_EPOCH as the
+date on creation of PO files with xgettext.
+
+ -- Eduard Sanou   Tue, 04 Aug 2015 18:43:52 +0200
+
 gettext (0.19.5.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
gettext-0.19.5.1/debian/patches/04-Replace-timestamp-with-SOURCE_DATE_EPOCH 
gettext-0.19.5.1/debian/patches/04-Replace-timestamp-with-SOURCE_DATE_EPOCH
--- gettext-0.19.5.1/debian/patches/04-Replace-timestamp-with-SOURCE_DATE_EPOCH 
1970-01-01 01:00:00.0 +0100
+++ gettext-0.19.5.1/debian/patches/04-Replace-timestamp-with-SOURCE_DATE_EPOCH 
2015-08-04 18:46:17.0 +0200
@@ -0,0 +1,45 @@
+Description: Replace date timestamp by SOURCE_DATE_EPOCH env var in xgettext
+ .
+ gettext (0.19.5.1-1.0~reproducible1) UNRELEASED; urgency=medium
+ .
+   * Non-maintainer upload.
+   * Add support for reproducible builds by using $SOURCE_DATE_EPOCH as the
+ date on creation of PO files with xgettext.
+Author: Eduard Sanou 
+
+--- gettext-0.19.5.1.orig/gettext-tools/src/xgettext.c
 gettext-0.19.5.1/gettext-tools/src/xgettext.c
+@@ -3516,6 +3516,7 @@ construct_header ()
+   message_ty *mp;
+   char *msgstr;
+   char *comment;
++  char *source_date_epoch;
+   static lex_pos_ty pos = { __FILE__, __LINE__ };
+ 
+   if (package_name != NULL)
+@@ -3537,7 +3538,24 @@ the MSGID_BUGS_ADDRESS variable there; o
+ specify an --msgid-bugs-address command line option.\n\
+ ")));
+ 
+-  time (&now);
++  /* Allow the date and time to be set externally by an exported
++ environment variable to enable reproducible builds. */
++  source_date_epoch = getenv ("SOURCE_DATE_EPOCH");
++  if (source_date_epoch)
++{
++  errno = 0;
++  now = (time_t) strtol (source_date_epoch, NULL, 10);
++  if (errno != 0)
++error (EXIT_FAILURE, errno, _("\
++SOURCE_DATE_EPOCH=\"%s\" is not a valid number"), source_date_epoch);
++
++  /* The function po_strftime uses localtime() to parse the timestamp, so 
++ we need to fix the environment timezone to get reproducible results 
*/
++  setenv("TZ", "UTC", 1);
++}
++  else
++time (&now);
++
+   timestring = po_strftime (&now);
+ 
+   msgstr = xasprintf ("\
diff -Nru gettext-0.19.5.1/debian/patches/series 
gettext-0.19.5.1/debian/patches/series
--- gettext-0.19.5.1/debian/patches/series  2015-08-02 20:37:20.0 
+0200
+++ gettext-0.19.5.1/debian/patches/series  2015-08-04 18:45:51.0 
+0200
@@ -1,3 +1,4 @@
 01-do-not-use-java-in-urlget
 02-msgfmt-default-little-endian
 03-fix-gettextize-version
+04-Replace-timestamp-with-SOURCE_DATE_EPOCH


signature.asc
Description: OpenPGP digital signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#794681: qt4-x11: please support timestamps from environment

2015-08-05 Thread Dhole
Source: qt4-x11
Version: 4:4.8.7+dfsg-2
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: toolchain timestamps
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi,

While working on the "reproducible builds" effort [1], we have noticed
that the qhelpgenerator tool from qt4-x11 embeds timestamps on the
creation of qch files.

For the Reproducible Builds effort we are proposing an environment
variable (SOURCE_DATE_EPOCH) [2] that will contain a deterministic epoch
timestamp (based on the latest debian/changelog entry) that could be
used, which should be automatically exported by debhelper in the future [3].

The attached patch proposes a way to use this variable to get
reproducible timestamps in the qch files generated by qhelpgenerator, if
the variable has been set (if not, it falls back to the old behavior).
With the attached patch packages using qhelpgenerator would then
automatically embed reproducible timestamps in qch files.


[1]: https://wiki.debian.org/ReproducibleBuilds
[2]: https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791815

Regards,
-- 
Dhole
diff -Nru qt4-x11-4.8.7+dfsg/debian/changelog 
qt4-x11-4.8.7+dfsg/debian/changelog
--- qt4-x11-4.8.7+dfsg/debian/changelog 2015-08-02 22:01:18.0 +0200
+++ qt4-x11-4.8.7+dfsg/debian/changelog 2015-08-04 15:19:05.0 +0200
@@ -1,3 +1,11 @@
+qt4-x11 (4:4.8.7+dfsg-2.0~reproducible1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for reproducible builds by using $SOURCE_DATE_EPOCH as the
+embedded timestamps in qch files generated with qhelpgenerator.
+
+ -- Eduard Sanou   Tue, 04 Aug 2015 15:17:35 +0200
+
 qt4-x11 (4:4.8.7+dfsg-2) experimental; urgency=medium
 
   * Add Daniel Schepler's QtScript_x32_config.diff and x32.diff to let Qt4
diff -Nru 
qt4-x11-4.8.7+dfsg/debian/patches/Replace_timestamp_with_SOURCE_DATE_EPOCH_in_qhelpgenerator.patch
 
qt4-x11-4.8.7+dfsg/debian/patches/Replace_timestamp_with_SOURCE_DATE_EPOCH_in_qhelpgenerator.patch
--- 
qt4-x11-4.8.7+dfsg/debian/patches/Replace_timestamp_with_SOURCE_DATE_EPOCH_in_qhelpgenerator.patch
  1970-01-01 01:00:00.0 +0100
+++ 
qt4-x11-4.8.7+dfsg/debian/patches/Replace_timestamp_with_SOURCE_DATE_EPOCH_in_qhelpgenerator.patch
  2015-08-04 15:41:15.0 +0200
@@ -0,0 +1,102 @@
+Description: Allow the timestamps from qhelpgenerator to be externally set
+ In order to make qhelpgenerator output reproducible, we need a way to
+ set the embedded timestamps to other values than the current time.
+ We define a new method for QDateTime (reproducibleDateTime) that returns
+ a deterministic datetime object when the SOURCE_DATE_EPOCH environment 
+ variable is set with a unix epoch timestamp, containing the datetime 
+ defined by SOURCE_DATE_EPOCH in UTC. We replace some instances of
+ QDateTime::currentDateTime() by QDateTime::reproducibleDateTime() in the
+ sources of qhelpgenerator to make the output reproducible.
+Author: Eduard Sanou 
+
+--- qt4-x11-4.8.7+dfsg.orig/src/corelib/tools/qdatetime.cpp
 qt4-x11-4.8.7+dfsg/src/corelib/tools/qdatetime.cpp
+@@ -2892,6 +2892,15 @@ bool QDateTime::operator<(const QDateTim
+ */
+ 
+ /*!
++\fn QDateTime QDateTime::reproducibleDateTime()
++If the environment variable SOURCE_DATE_EPOCH containing a unix epoch date
++is set, returns the datetime in SOURCE_DATE_EPOCH, in UTC.
++If SOURCE_DATE_EPOCH is not set, behaves as QDateTime::currentDateTime().
++
++\sa currentDateTimeUtc(), QDate::currentDate(), QTime::currentTime(), 
toTimeSpec()
++*/
++
++/*!
+ \fn QDateTime QDateTime::currentDateTimeUtc()
+ \since 4.7
+ Returns the current datetime, as reported by the system clock, in
+@@ -3120,6 +3129,29 @@ QDateTime QDateTime::currentDateTime()
+ return dt;
+ }
+ 
++QDateTime QDateTime::reproducibleDateTime()
++{
++QByteArray env_date;
++QDateTime date;
++bool env_date_ok;
++long timestamp;
++
++env_date = qgetenv("SOURCE_DATE_EPOCH");
++if (env_date.length() != 0) {
++timestamp = env_date.toLong(&env_date_ok, 10);
++if (!env_date_ok) {
++// "SOURCE_DATE_EPOCH is not a number!
++timestamp = 0;
++}
++date = QDateTime::fromTime_t(timestamp).toUTC();
++} else {
++date = QDateTime::currentDateTime();
++}
++
++return date;
++}
++
++
+ QDateTime QDateTime::currentDateTimeUtc()
+ {
+ // posix compliant system
+--- qt4-x11-4.8.7+dfsg.orig/src/corelib/tools/qdatetime.h
 qt4-x11-4.8.7+dfsg/src/corelib/tools/qdatetime.h
+@@ -264,6 +264,7 @@ public:
+ int utcOffset() const;
+ 
+ static QDateTime currentDateTime();
++static QDateTime reproducibleDateTime();
+ static QDateTime currentDateTimeUtc();
+ #ifndef QT_NO_DATESTRING
+ static QDateTime fromString(const QString &s, Qt::DateFormat f = 
Qt::TextDate);
+--- qt4-x11-4.8.7+dfsg.orig/tools/assistant/lib/qhelpg

Re: [Reproducible-builds] dpkg_1.18.1.0~reproducible5 ftbfs

2015-08-05 Thread Jérémy Bobbio
Guillem Jover:
> Ah, the problem is that the releases are being made directly from
> git with dpkg-buildpackage. The correct way to release dpkg is to
> «make dist» and then build Debian packages from that tarball.
> 
> The detailed instructions on releasing can be found on the “How to
> release“ section here:
> 
>   
> 
> although several points might not be relevant here.

Thanks for the pointer! What would you think of adding it to a
README.source [1] file? I probably would have learned about this page
(and saved some troubles) if it had been.

 [1]: https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] Reproducibility vs signatures

2015-08-05 Thread Jérémy Bobbio
Ben Hutchings:
> On Mon, 2015-08-03 at 10:27 +0200, Jérémy Bobbio wrote:
> > Ben Hutchings:
> > > At some point we're hopefully going to support Secure Boot on amd64.
> > > That means there will be a signed kernel image (separate from the
> > > current linux-image packages) and a signed GRUB image.  The kernel
> > > modules in the linux-image packages will also be signed, probably with
> > > an ephemeral key.
> > > 
> > > All these signatures will all be embedded within binaries and will of
> > > course not be reproducible.  The locations of differences will however
> > > be predictable.
> > > 
> > > How should we deal with this limited variability?  Could source
> > > packages or buildinfo describe the expected variations somehow?
> > 
> > One way to solve this, although a bit wasteful on resource, is to use
> > the clean rule to perform a first build and create a signature to be
> > added to the source package.
> 
> That sort of works as long as there's only one architecture we want to
> do this for.  But the ability to verify modules is useful in general so
> I would like to turn that on for all architectures.

Here's a solution I had in my mind when opening my eyes this
morning [1]:

Ship signatures in a separate source package, e.g. linux-signatures.
Have linux-image Recommends linux-signatures. Ideally, I think the
signatures should be shipped in extra files. Another solution would be
to use xattrs and set them in a postinst script [2]. Or mangle the files
in place to add signatures, but that would prevent using debsums.

Both linux-image and linux-signatures can be built reproducibly.
linux-signatures will have the actual signatures in its source,
generated for a specific linux-image version.

That way the release process can be: upload new linux, wait for buildds,
retrieve results from archive, create linux-signatures, upload
linux-signatures. Have linux build reproducibly can help the signers
gain exta confidence that the buildd are not compromised by performing
extra builds on different systems.

What do you think?

 [1]: Yes, human brains seem to also have background tasks.
 [2]: xattrs are used by IMA, see  and
  #766267.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: [Reproducible-builds] dpkg_1.18.1.0~reproducible5 ftbfs

2015-08-05 Thread Holger Levsen
Hi Guillem,

On Mittwoch, 5. August 2015, Guillem Jover wrote:
> Ah, the problem is that the releases are being made directly from
> git with dpkg-buildpackage. 

indeed, that's how I've built.

> The correct way to release dpkg is to
> «make dist» and then build Debian packages from that tarball.

that didnt work, but...

> The detailed instructions on releasing can be found on the “How to
> release“ section here:
>   

these were helpful indeed, thanks a lot, but this happened:

- I kept "UNRELEASED" as distro in debian/changelog
- I didnt create a tag for the release… (also because we have the illegal (for 
git tags) character "~" in our version...)
- then I ran "git clean -Xdf" 
- then I ran "autoreconf -f -i; ./configure; DPKG_DEVEL_MODE=1 make distcheck" 
which created dpkg-1.18.1-11-g1c825.tar.xz - which is not what I expected as 
"1.18.2.0~reproducible1" is the version in debian/changelog...

What now? debian/changelog inside dpkg-1.18.1-11-g1c825.tar.xz has the correct 
version, but I assume there's another location I need to change this...

If you want to look yourself, our repo is at 
git.debian.org/git/reproducible/dpkg.git and the branch is 
pu/reproducibe_builds

Thanks again for your support, much appreciated!


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds