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

2017-07-15 Thread Daniel Shahaf
Bruno Haible wrote on Sat, 15 Jul 2017 21:24 +0200: > Daniel Shahaf wrote: > > So: should po file generation allow the caller to control the timestamp > > that would be embedded? > > No, that would be a regression for the translators. > No, it would not. The proposed change is to set the

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

2017-07-15 Thread Bruno Haible
Santiago Vila wrote: > But so far, the non-reproducible Debian packages using gettext I've > seen fail to be reproducible because maintainers insist on > regenerating a .pot file at build time and performing msgmerge on all > the .po files with the newly generated .pot file "just in case", or >

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

2017-07-15 Thread Bruno Haible
Daniel Shahaf wrote: > > it's plain text, and it's a small diff. > > This doesn't scale. (For example, in my use-case, I'm dealing with a > 5000-line unified diff full of one-line changes in date strings and C > comments and any number of other things. My goal is to get the number of > lines

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

2017-07-15 Thread Santiago Vila
On Sat, Jul 15, 2017 at 06:04:58PM +, Daniel Shahaf wrote: > So: should po file generation allow the caller to control the timestamp > that would be embedded? Maybe, or maybe not. But so far, the non-reproducible Debian packages using gettext I've seen fail to be reproducible because

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

2017-07-15 Thread Daniel Shahaf
Bruno Haible wrote on Sat, 15 Jul 2017 19:40 +0200: > But SO WHAT? It does not get installed on the end user's system. I am not disputing that .mo files, which are installed on user systems, should be reproducible. I am asserting that there is another workflow which would be simpler if .po file