17:59:50 <h01ger> #startmeeting reproducible builds, monthly meeting
17:59:50 <MeetBot> Meeting started Thu Oct  5 17:59:50 2017 UTC.  The chair is h01ger. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:59:50 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:00:00 <h01ger> #topic greetings, say hi
18:00:03 <infinity0> hi
18:00:38 <bmwiedemann> hi
18:01:12 <h01ger> ho
18:03:45 <h01ger> agenda at https://pad.riseup.net/p/reproducible-irc-meeting-13
18:04:01 <h01ger> should be a short meeting :)
18:05:45 * vagrantc waves
18:06:56 <h01ger> #topic reproducible builds summit 3 in berlin, oct 30th and nov 1st+2nd
18:07:08 <Eric[m]> o/
18:07:23 <h01ger> things have been taking shape
18:07:30 * vagrantc cheers
18:08:20 <bmwiedemann> h01ger: any details yet? location, organization?
18:08:35 <h01ger> we have the location, the facilitators, some sponsors, a prelimariy website and tonight i can hopefully finally send those invitaions mails, and if not tonite, tomorrow
18:08:53 <h01ger> https://reproducible-builds.org/events/berlin2017/
18:09:17 <h01ger> we'll also have a registration email address and elisa is helping me organising stuff
18:10:03 <h01ger> so location is betahaus in berlin
18:11:11 <ReproBird> 02gostocks32: 06#linux #debian « @ReproBuilds: Here's what happened in Reproducible Builds between Sep 17 → Sepr 23 2017 https://reproducible.alioth.debian.org/blog/posts/126/ cc/@debian #linux #debian »14 — https://twitter.com/gostocks32/status/916003012077805568
18:11:17 <h01ger> we still need to finalize sponsors (=us getting money to make the event happen and reimburse attendees). if you read this an
18:11:33 <h01ger> and can help, please contact me
18:11:42 <h01ger> any other questions?
18:13:22 <bmwiedemann> seems, not yet
18:15:39 <vagrantc> glad to hear about the progress! :)
18:17:27 <bmwiedemann> I'm wondering what happens when no sponsors can be 'finalized'
18:18:13 <bmwiedemann> or is that so unlikely that we dont have to consider that
18:19:59 <h01ger> bmwiedemann: we have 20k. so we can pay the venue and have some money for the facilitators travel and some attendee travel. but we would need to ask people to pay their food, the facilitators would work for free (which they cannot really afford all the time as they also work for free for otehr projects)
18:20:24 <h01ger> so it will definitly happen
18:20:41 <bmwiedemann> great
18:21:10 <h01ger> next topic?
18:21:48 <infinity0> "how to best handle tools that write input mtime into output" could someone explain that?
18:22:16 <h01ger> #topic how to best handle tools that write input mtime into output e.g. https://bugreports.qt.io/browse/QTBUG-62511
18:22:28 <bmwiedemann> infinity0: that is from me
18:22:31 <h01ger> someone (who put it there?), please explain
18:23:27 <bmwiedemann> I brought it up on the rb-general ML some month ago with a different instance.
18:23:53 <bmwiedemann> some tools take the mtime of their input files and put it into output files they produce
18:24:23 <bmwiedemann> with Qt's rcc being one such, but asciidoc (meanwhile having SDE patches to avoid it) and mdate.sh were other such instances
18:24:27 <h01ger> how is that problematic?
18:24:43 <bmwiedemann> a) we apply patches in packages that update mtimes
18:24:55 <bmwiedemann> b) some packages produce the input files during build
18:25:52 <bmwiedemann> so it happens in some dozen cases at least
18:26:00 <infinity0> you could implement the clamping part of SOURCE_DATE_EPOCH
18:26:12 <infinity0> if the mtime > SOURCE_DATE_EPOCH then use SOURCE_DATE_EPOCH instead
18:26:53 <bmwiedemann> yes, but that would go in the consumer of the mtime, right?
18:27:18 <bmwiedemann> because the Qt people seemed to be reluctant to that approach
18:27:43 <bmwiedemann> because they also use the timestamps for some caching or so
18:28:10 <infinity0> it would go in RCCFileInfo::writeDataInfo
18:28:35 <bmwiedemann> so just in the place that writes the output
18:28:45 <infinity0> right
18:29:04 <bmwiedemann> OK, I'll try to push that
18:29:27 <Eric[m]> > some tools take the mtime of their input files and put it into output files they produce
18:29:31 <Eric[m]> if they do that itself reproducibly, that shouldn't be a problem?
18:29:47 <bmwiedemann> Eric[m]: it is because of a) and b) above
18:30:04 <Eric[m]> so a) is your problem and b) is the package's problem
18:30:55 <bmwiedemann> in the end it is all the problem of the distribution, but the package is just using a 3rd party tool, so not really responsable either
18:31:02 <Eric[m]> idk, I've gotten used to having a lot of `defer RepairMtime(relevantPath.Parent())()` in any of my code that's patching things
18:31:07 <infinity0> implementing clamping in the function that directly writes the output is fine i think
18:31:57 <Eric[m]> and implementing "leave it alone" (even if by mutating and then mutating-back, because filesystems are terrible and the kernel is a sad sad thing) seems a lot simpler to me than anything downstream of the word "clamping"
18:31:58 <bmwiedemann> I was thinking of having a patch --keep-mtime option
18:32:04 <Eric[m]> ^ +1
18:32:41 <infinity0> that doesn't help with (b) though
18:33:05 <bmwiedemann> sure. b) is rather tricky, because everyone does it differently
18:33:28 <bmwiedemann> so I'd really prefer to fix it once in the tool (e.g. qt rcc here)
18:33:41 <infinity0> right. we've been doing clamping for ages, it works and is simple
18:33:41 <bmwiedemann> so that we dont need to keep patching this ad infinitum
18:34:40 <h01ger> s#fix it once in the tool#fix it once in the tools# :)
18:35:05 <Eric[m]> so, forgive me if this is covered ground, but i've never quite understood where clamping became clamping rather than just steamrolling
18:35:41 <h01ger> what?
18:35:50 <Eric[m]> because in situation (b) you have tools that clearly aren't using mtimes for anything, or they'd have cared more already, surely... no?  so at that point, isn't fiat stamping everything to S_D_E the simplest?
18:35:53 <bmwiedemann> Eric[m]: that is for cases that are simply not a) or b) but have constant mtime
18:36:31 <infinity0> sometimes people like keeping older mtimes and wouldn't accept a solution that just deletes the mtime
18:36:37 <infinity0> clamping works for everyone
18:36:46 <h01ger> how shall we proceed with this topic?
18:36:46 <bmwiedemann> e.g. often these dates appear in man-pages and could confuse people
18:36:54 <h01ger> can someone write a writeup to the list?
18:36:56 <infinity0> i think the discussion is over, just do clamping, there are no problems
18:37:11 <bmwiedemann> just having to convince upstream
18:37:17 <infinity0> i don't buy Eric's position that we should push to totally get rid of mtimes, it's not worth the effort and he has'nt been the one doing the work of trying to convince upstream
18:37:40 <Eric[m]> ok ok i get it, just wondering :)
18:37:51 <bmwiedemann> btw: I have been pushing some patches recently that replace date with date -r ChangeLog
18:38:25 <infinity0> that sounds nice too, making it independent of S_D_E
18:38:27 <bmwiedemann> which would suffer from a) but it is a lot easier to get upstream to understand it than SDE with support for BSD+GNU date and who sets this variable etc
18:39:51 <bmwiedemann> anyway, I can write a summary to the ML and maybe we should also document it in a more permanent place
18:40:20 <infinity0> i've been meaning to update the S_D_E spec to mention clamping as an option, dkg had some amendment text already
18:40:50 <infinity0> we could also add the "date -r" thing either to the spec or to the wiki page that has the "ways to avoiding using S_D_E" checklist
18:41:03 <bmwiedemann> great
18:41:33 <h01ger> who's gonna do that? ;)
18:41:44 <infinity0> i'll do that :) in the next 1-2 weeks
18:42:04 <infinity0> it was actually top of my TODO list already before this meeting
18:44:03 <infinity0> next topic?
18:47:16 <bmwiedemann> we should always have an 'open discussion' topic at the end
18:47:57 <h01ger> #topic AOB - any other business
18:48:09 <h01ger> (sorry, got disconnected from the network…)
18:48:58 <h01ger> seems we are good
18:49:04 * h01ger thanks everybody for attending
18:49:12 <infinity0> thanks!
18:49:24 <h01ger> #endmeeting