17:59:50 #startmeeting reproducible builds, monthly meeting 17:59:50 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:00:00 #topic greetings, say hi 18:00:03 hi 18:00:38 hi 18:01:12 ho 18:03:45 agenda at https://pad.riseup.net/p/reproducible-irc-meeting-13 18:04:01 should be a short meeting :) 18:05:45 * vagrantc waves 18:06:56 #topic reproducible builds summit 3 in berlin, oct 30th and nov 1st+2nd 18:07:08 o/ 18:07:23 things have been taking shape 18:07:30 * vagrantc cheers 18:08:20 h01ger: any details yet? location, organization? 18:08:35 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 https://reproducible-builds.org/events/berlin2017/ 18:09:17 we'll also have a registration email address and elisa is helping me organising stuff 18:10:03 so location is betahaus in berlin 18:11:11 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 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 and can help, please contact me 18:11:42 any other questions? 18:13:22 seems, not yet 18:15:39 glad to hear about the progress! :) 18:17:27 I'm wondering what happens when no sponsors can be 'finalized' 18:18:13 or is that so unlikely that we dont have to consider that 18:19:59 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 so it will definitly happen 18:20:41 great 18:21:10 next topic? 18:21:48 "how to best handle tools that write input mtime into output" could someone explain that? 18:22:16 #topic how to best handle tools that write input mtime into output e.g. https://bugreports.qt.io/browse/QTBUG-62511 18:22:28 infinity0: that is from me 18:22:31 someone (who put it there?), please explain 18:23:27 I brought it up on the rb-general ML some month ago with a different instance. 18:23:53 some tools take the mtime of their input files and put it into output files they produce 18:24:23 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 how is that problematic? 18:24:43 a) we apply patches in packages that update mtimes 18:24:55 b) some packages produce the input files during build 18:25:52 so it happens in some dozen cases at least 18:26:00 you could implement the clamping part of SOURCE_DATE_EPOCH 18:26:12 if the mtime > SOURCE_DATE_EPOCH then use SOURCE_DATE_EPOCH instead 18:26:53 yes, but that would go in the consumer of the mtime, right? 18:27:18 because the Qt people seemed to be reluctant to that approach 18:27:43 because they also use the timestamps for some caching or so 18:28:10 it would go in RCCFileInfo::writeDataInfo 18:28:35 so just in the place that writes the output 18:28:45 right 18:29:04 OK, I'll try to push that 18:29:27 > some tools take the mtime of their input files and put it into output files they produce 18:29:31 if they do that itself reproducibly, that shouldn't be a problem? 18:29:47 Eric[m]: it is because of a) and b) above 18:30:04 so a) is your problem and b) is the package's problem 18:30:55 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 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 implementing clamping in the function that directly writes the output is fine i think 18:31:57 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 I was thinking of having a patch --keep-mtime option 18:32:04 ^ +1 18:32:41 that doesn't help with (b) though 18:33:05 sure. b) is rather tricky, because everyone does it differently 18:33:28 so I'd really prefer to fix it once in the tool (e.g. qt rcc here) 18:33:41 right. we've been doing clamping for ages, it works and is simple 18:33:41 so that we dont need to keep patching this ad infinitum 18:34:40 s#fix it once in the tool#fix it once in the tools# :) 18:35:05 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 what? 18:35:50 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 Eric[m]: that is for cases that are simply not a) or b) but have constant mtime 18:36:31 sometimes people like keeping older mtimes and wouldn't accept a solution that just deletes the mtime 18:36:37 clamping works for everyone 18:36:46 how shall we proceed with this topic? 18:36:46 e.g. often these dates appear in man-pages and could confuse people 18:36:54 can someone write a writeup to the list? 18:36:56 i think the discussion is over, just do clamping, there are no problems 18:37:11 just having to convince upstream 18:37:17 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 ok ok i get it, just wondering :) 18:37:51 btw: I have been pushing some patches recently that replace date with date -r ChangeLog 18:38:25 that sounds nice too, making it independent of S_D_E 18:38:27 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 anyway, I can write a summary to the ML and maybe we should also document it in a more permanent place 18:40:20 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 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 great 18:41:33 who's gonna do that? ;) 18:41:44 i'll do that :) in the next 1-2 weeks 18:42:04 it was actually top of my TODO list already before this meeting 18:44:03 next topic? 18:47:16 we should always have an 'open discussion' topic at the end 18:47:57 #topic AOB - any other business 18:48:09 (sorry, got disconnected from the network…) 18:48:58 seems we are good 18:49:04 * h01ger thanks everybody for attending 18:49:12 thanks! 18:49:24 #endmeeting