15:59:37 <lamby> #startmeeting
15:59:37 <MeetBot> Meeting started Thu Jun  1 15:59:37 2017 UTC.  The chair is lamby. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:37 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:59:44 <lamby> Good evening all
15:59:50 <lamby> #topic Introductions
15:59:54 <lamby> Who is around? :)
15:59:55 <siamezzze> Good evening!
16:00:00 <h01ger> hi
16:00:00 <Faux> o/
16:00:01 <lamby> hey siamezzze
16:00:05 <lamby> hey h01ger, Faux o/
16:00:08 <h01ger> lamby: can you please #chair me?
16:00:10 * danielsh` (multitasking)
16:00:20 <lamby> h01ger: Tell me what to paste :)
16:00:22 <infinity0> hi
16:00:26 <bmwiedemann> good evening
16:00:27 * emaste waves
16:00:29 <h01ger> lamby: #chair h01ger
16:00:29 <fsckd> hello
16:00:29 <vagrantc> hello!
16:00:35 <emaste> hello from FreeBSDLandia
16:00:36 <lamby> #chair h01ger
16:00:36 <MeetBot> Current chairs: h01ger lamby
16:00:46 <h01ger> fsckd: hey, what are you working on?
16:00:55 <lamby> hey fsckd!
16:00:57 <lamby> woo new faces
16:01:02 * h01ger works on debian mostly but also maintains this tests.r-b.o thing
16:01:33 * h01ger singled out fsckd because the other people here have been at various irc and RL meetings before… (and the topic is as it is :)
16:01:41 <fsckd> i am an ARch Linux user and i've recently taken an interest in reproducible builds
16:01:52 <h01ger> fsckd: cool cool!
16:02:05 <sangy> hello
16:02:13 <danielsh`> welcome aboard
16:02:14 <lamby> #info Apologies from Mattia (mapreri) -- it's Festa della Repubblica tomorrow
16:02:19 <lamby> hey sangy
16:02:44 * vagrantc works on debian, and maintains armhf hardware for the debian tests.reproducible-builds.org
16:02:46 * h01ger is happy about more involvement from the Arch Linux community
16:02:56 <bmwiedemann> btw: when you make patches, be sure to send them upstream so that everyone profits from your work in the long term
16:03:10 <h01ger> #info there is #archlinux-reproducible on freenode
16:03:18 * lamby works on Debian, diffoscope, etc. etc.
16:03:23 <h01ger> #save
16:04:05 <h01ger> the agenda is at https://pad.riseup.net/p/reproducible-irc-meeting-9
16:04:09 <lamby> So, this will probably be quite a quick meeting. Do say if something or a topic is not clear; sometimes us old timers can assume too much.
16:04:36 * sangy works (volunteers?) on Arch security.
16:04:39 <lamby> Okay, let's get going.
16:04:41 <lamby> #topic Feedback for the reproducible.json spec format
16:04:47 <lamby> bmwiedemann: You're up ^
16:04:51 <h01ger> sangy: hehe :) (works/volunteers :)
16:05:30 <bmwiedemann> the idea of the reproducible.json format is for people to be able to test rb externally and publish results
16:05:46 <h01ger> #info proposed format: http://rb.zq1.de/spec/json-format.txt
16:05:47 <bmwiedemann> and then we can build tools that make nice graphs, stats etc out of it
16:05:59 <h01ger> bmwiedemann: did you look at the existing debian json when writing that format?
16:06:04 <bmwiedemann> similar to the ones that are already on tests.r-b.org
16:06:14 <lamby> ( https://tests.reproducible-builds.org/reproducible.json.bz2 that is )
16:06:25 <bmwiedemann> yes, heavily inspired by that one.
16:06:31 <h01ger> #info https://tests.reproducible-builds.org/reproducible.json.bz2 is the format debian is using
16:06:40 <Eric[m]> (moin)
16:06:47 <h01ger> hi Eric[m]
16:06:49 <danielsh`> off the top of my head: need to add a format number somewhere
16:07:07 <danielsh`> i.e., "'reproducible-json-data': 1" or so
16:07:11 <h01ger> bmwiedemann: i think there are more stati (waiting for deps, blacklisted)
16:07:25 <bmwiedemann> or "format-version": 1
16:07:41 * h01ger nods danielsh`'s idea
16:07:42 <danielsh`> bmwiedemann, no, BTDT.  The field name should be unique for the file format
16:07:51 <h01ger> where should the format definition live?
16:08:36 <bmwiedemann> human-readable definition or some .schema file for auto-validation?
16:08:38 <Faux> In the filename, to keep the format beautifully simple.
16:08:47 <danielsh`> bmwiedemann, for background: https://issues.apache.org/jira/browse/SVN-3744
16:08:49 <Faux> ^ the version, not the schema.
16:09:08 <h01ger> bmwiedemann: is http://rb.zq1.de/compare.factory/reproducible.json already updated daily or is that a one time data dump?
16:09:58 <bmwiedemann> h01ger: updated whenever a build round finished, usually every 1-2 weeks. you can see one dir level up. compare.factory is just a symlink to the latest one
16:10:05 <h01ger> ic
16:10:14 <h01ger> still very fine for now
16:10:52 <h01ger> lynxis: ^^ can you please look at that json format and comment whether its suitable for lede + coreboot or tell us whats needed?
16:11:12 <h01ger> _hc: uniq[m] : ^^ can you please look at that json format and comment whether its suitable for f-droid or tell us whats needed?
16:11:16 <lamby> I wonder if this somewhat overlaps with the whole publishing-logs-to-binary-logs. Not saying we should do that instead, but we could think ahead and ensure that each entry could serve double duty in both.
16:11:36 <lamby> (ie. "source" key?)
16:12:07 <Eric[m]> lamby i just had that same thought but i'm not sure if this json doc would actually communicate much if immutable-logged?
16:12:08 <h01ger> i'd rather keep the publishing-logs-to-binary-logs out of this for now…
16:12:09 <vagrantc> would it be better if build_date were build_time?
16:12:26 <vagrantc> while i'm guessing it's just the unix clock... it
16:12:37 <vagrantc> seconds since epoch ...
16:12:40 <bmwiedemann> it is
16:12:46 <sangy> btw, the example on http://rb.zq1.de/spec/json-format.txt doesn't match the spec does it? (suite -> release)
16:12:54 <vagrantc> that doesn't look like a date to my human eyes :)
16:12:57 <h01ger> bmwiedemann: i think the next step is to write a parser for this json and feed the data into postgresql
16:12:58 <bmwiedemann> ah, we renamed that later
16:13:13 <bmwiedemann> h01ger: any language preference?
16:13:15 <h01ger> bmwiedemann: then the next step is to modify our debian python scripts, running as jenkins jobs, to enable them to build debian pages and suse pages
16:13:18 <h01ger> bmwiedemann: python
16:13:29 <lamby> Eric[m]: (My muse was that entry dict entry would be what would be posted, but perhaps too much would change for binary logs anyway that this is highly premature)
16:13:57 <h01ger> bmwiedemann: and once we have this json parser, the format defintion should be part of that code, possible as comments
16:14:10 <h01ger> cause that will be the de facto reference implementation
16:14:13 <bmwiedemann> sangy: fixed the suite=> release in examples
16:14:23 <Eric[m]> istm that json blob would be a nice simple standard (doesn't do too much, thus hard to argue about..) for drawing pictures of progress and such
16:15:14 <Eric[m]> but i'm sitting here with the hash-all-the-things hat on again and so of course the metadata i'd want to immutable-log has a very different set of additional stuff in it (which no one else will likely agree with...)
16:15:34 <Eric[m]> </2cents>
16:15:48 <lamby> nodnod
16:15:53 <h01ger> #info: the next step is to write a parser for this json and feed the data into postgresql on jenkins.d.n - then the next step is to modify our debian python scripts, running as jenkins jobs, to enable them to build debian pages and suse pages
16:15:55 <bmwiedemann> Eric[m]: I have a checksums.txt in the same dir keeping track of binary results
16:15:57 <vagrantc> it seems odd that the build_date isn't more specifically defined
16:16:10 <vagrantc> e.g. any time between when the build start or finish
16:16:14 <h01ger> #info once we have this json parser, the format defintion should be part of that code, possible as comments - because that will be the de facto reference implementation
16:16:26 <vagrantc> why not record build_date_start, build_date_finish ?
16:16:55 <bmwiedemann> vagrantc: because it does not matter so much - and it makes implementation easier for producers (like me)
16:17:13 <h01ger> bmwiedemann: i'm happy to write this code or help writing it… mapreri and spectranaut also know that part of the code base really well, partly better than myself (cause they wrote the latest iterations of it)
16:17:57 <h01ger> though i dont know what else to discuss here in the meeting. someone needs to code something, but i think thats it…
16:18:37 <bmwiedemann> h01ger: I can draft a simple stand-alone snippet, but that will maybe only be 20 lines
16:18:57 <sangy> Following vagrantc, couldn't each node on this list map to a file with the complete build log, start_date and other relevant info?
16:19:08 <h01ger> bmwiedemann: cool cool
16:19:21 <h01ger> bmwiedemann: i'd be very glad to guide you into the code base
16:19:26 <lamby> sangy: Some sort of external URI reference?
16:19:57 <sangy> I'd imagine so, maybe it could be implicit if we define a directory structure, but that may be overcomplicating thigns?
16:20:04 <bmwiedemann> sangy: should be optional.
16:20:15 <lamby> Yeah, that sounds a little overcomplicated.
16:20:33 <h01ger> are we still discussing the format?
16:20:35 * vagrantc wonders what the real goal is
16:20:35 <bmwiedemann> like, first we want stats and graphs, and then we want to click on package names and get details
16:21:14 <vagrantc> should be able to find build logs by the package and build time, i guess
16:21:26 <vagrantc> makes sense
16:21:29 <h01ger> we want t.r-b.o/suse/$srcpkg to work and have nice graphs and stuff for suse as we do for debian
16:21:41 <lamby> That would be awesome
16:21:43 <h01ger> and then we want the same for guix, archlinux, lede, foo
16:21:43 <lamby> bmwiedemann: Could use https://github.com/bdrung/image-release-spec as some kind of template.
16:22:03 <bmwiedemann> yeah
16:22:05 <lamby> Anyway, sounds like we have enough here to get going on…?  Do we have some specific action points
16:22:08 <lamby> * ?
16:22:27 <h01ger> i #info'ed some points but i didnt want to #action them
16:22:29 <h01ger> #save
16:23:01 <Eric[m]> i don't know if this will be interesting but for an example of how far out i might be going in my checksums.txt
16:23:02 <Eric[m]> https://github.com/polydawn/hitch/blob/7c30b81209d7495eb09a6f079b3458beeebb6b74/api/records.go
16:23:13 <danielsh`> still waiting for the feedback from lede/fdroid
16:23:15 <h01ger> lamby: can you please say #save? seem it didnt work for me
16:23:17 <lamby> #save
16:23:20 <h01ger> merci
16:23:29 <lamby> #info https://github.com/polydawn/hitch/blob/7c30b81209d7495eb09a6f079b3458beeebb6b74/api/records.go
16:23:31 <h01ger> sigh, works now indeed.
16:23:36 <lamby> #info https://github.com/bdrung/image-release-spec
16:23:48 <h01ger> whats that polydawn url about?
16:24:03 <lamby> 5 lines up ;)
16:24:12 <Eric[m]> i link that not to say it's a good idea that i've got there, but because it's an example of how much someone could possibly dissent what the spec should look like when they get increasingly aggressive about linking build records and dependency graphs
16:24:22 <lamby> I think we have enough here. Next topic!
16:24:25 <lamby> #topic tests.r-b.o/Debian once Stretch has been released
16:24:34 <lamby> h01ger: I think this is yours, judging by the colour…?
16:24:50 <h01ger> so, stretch will be released on 2017-06-17
16:24:58 <h01ger> at which point testing will become buster
16:25:01 <lamby> \o/
16:25:08 <h01ger> and i think we should keep logs+stats for stretch
16:25:20 <h01ger> so i think we ought to rename testing to stretch now
16:25:27 <h01ger> and add buster on 2017-06-18
16:25:31 <vagrantc> not sure if this is on-topic, but given that almost all the armhf boards require newer kernels, i'd love to upgrade armhf to stretch, at least...
16:25:36 <h01ger> and stop testing "testing" ;)
16:25:40 <h01ger> vagrantc: thats a different topic
16:25:55 <h01ger> vagrantc: lets discuss that in a minute, it is related :)
16:26:21 * h01ger is not sure what to discuss about this topic here and now though
16:26:22 <vagrantc> i generally always prefer to reference things by codename, when possible
16:26:31 <bmwiedemann> h01ger: why stop testing 'testing' ? wont that be updated again soon?
16:26:43 <h01ger> a few commits are needed to make this happen, so i guess this was just a heads-up topic
16:26:53 <danielsh`> bmwiedemann, 'testing' is a floating label... the suggestion is to test what the label points to, directly.
16:26:53 <h01ger> bmwiedemann: because we'll test buster instead, which is/will be "testing"
16:27:06 <bmwiedemann> ah. good.
16:27:16 <lamby> Can we avoid this for buster+1 ? ie. always use codenames from now on?
16:27:17 <vagrantc> h01ger: will we keep testing stretch once it's released?
16:27:34 <lamby> We'll potentially hit this with other distros anyway.
16:27:53 <vagrantc> lamby++
16:28:08 <h01ger> vagrantc: yes, but way slower and eventually not really anymore
16:28:20 <vagrantc> h01ger: right.
16:28:37 <h01ger> #topic upgrading build nodes once stretch is out
16:28:40 <vagrantc> could test security updates and proposed-updates...
16:28:46 <h01ger> vagrantc: your topic :)
16:28:51 <h01ger> frankly, i think we should do it
16:28:57 <vagrantc> should we do it now?
16:28:58 <lamby> "Just" add some stuff to .htaccess, right… ;)
16:29:03 <h01ger> upgrade all build nodes to stretch on the 17th or 18th or so
16:29:31 <h01ger> vagrantc: i'd rather do more urgent stuff first, like preparing buster, and maybe even the json parser, to make bmwiedemann happy and keep momentum
16:29:31 <vagrantc> if there's some RC bug we haven't yet discovered, would be a shame to not get it fixed in release
16:29:42 <h01ger> vagrantc: are you really suffering to run those boards on jessie for the next 2.5 weeks?
16:30:11 <vagrantc> h01ger: no, it's fine ... but this late in the release cycle...
16:30:21 <vagrantc> i like to try and make sure there are no hidden bugs awaiting us
16:30:27 <bmwiedemann> why not just upgrade one of them to discover bugs?
16:30:28 <h01ger> vagrantc: oh, i would also like to add your 3 new nodes first… ;)
16:31:05 <bmwiedemann> (we often do that in our SUSE-internal CI hosts)
16:31:06 <vagrantc> bmwiedemann: that's feasible
16:31:07 <h01ger> and if mapreri wants to go crazy on this and just do it, i woudlnt object either
16:31:26 <h01ger> but i dont think it would be helpful to update just some
16:31:38 <h01ger> that will increase maintenance costs for that period
16:31:45 <vagrantc> true enough...
16:31:57 <h01ger> we're talking about 38 hosts here…
16:31:58 * vagrantc will talk to mapreri
16:32:29 <h01ger> also, one of those 38 is jenkins, and i do expect some more issues there, once we upgrade that to stretch
16:32:43 <h01ger> jenkins runs 1400 jobs, only 200 of them are related to reproducible…
16:32:52 <vagrantc> in general, i've been testing new machines with stretch first, and then re-installing with jessie
16:32:56 <bmwiedemann> newer jenkins needs java-1.8 - and sometimes slaves then too
16:33:07 <h01ger> bmwiedemann: we dont have java on any slave
16:33:43 <vagrantc> well, it's been at the back of my mind weather to go for it
16:33:55 <h01ger> and we already use java-1.8 on jenkins because upstream thought it would be nice to change this requirement when going from 2.46.2 to 2.46.3
16:34:01 <vagrantc> will check in what mapreri thinks, and check in before doing anything drastic
16:34:26 <h01ger> vagrantc: i'd prefer we wait til after the release and then upgrade all nodes in one go
16:35:05 <vagrantc> i won't push it
16:35:11 <h01ger> thanks
16:35:25 <vagrantc> figured it was worth mentioning, though
16:35:31 <h01ger> sure thing!
16:35:37 <lamby> :)
16:35:46 <h01ger> #topic Reproducible Builds Summit #3 2017
16:35:48 <lamby> Next? :)
16:36:15 <h01ger> so, i've spoken/mailed with gunner and would be happy to have another summit with us
16:36:46 <lamby> \o/ \o/ \o/
16:36:48 <h01ger> gunner is our moderator/facilitator who together with beatrix helps to run the meetings smoothly, nicely & effectivly, and documented
16:36:49 <vagrantc> nice to be thinking about it with plenty of lead time
16:37:00 <emaste> h01ger: most excellent
16:37:08 <h01ger> so, while we do have two dates to choose now
16:37:09 <bmwiedemann> nice. any proposal for the place?
16:37:18 <h01ger> we dont have any funding yet
16:37:28 * vagrantc hopes for something central, like iceland
16:37:36 <h01ger> so the summit might as well not happen, if we dont get funding… or might happen very differently
16:37:47 <h01ger> no proposals for a place yet…
16:38:11 <lamby> We haven't had pushback *against* funding yet though? We've just not asked?
16:38:17 <h01ger> lamby: yes
16:38:23 <vagrantc> h01ger: what are the suggested dates?
16:38:43 <h01ger> possible dates are either 30 Oct-3 Nov or 6-10 Nov
16:38:51 <h01ger> 2017
16:39:10 <bmwiedemann> so Mon-Fri each
16:39:13 * h01ger will set up a doodle poll so that you all can state your preferences on these dates
16:39:28 <h01ger> bmwiedemann: thats ment to be Tue-Thu each
16:39:32 <h01ger> 3 day summit
16:39:39 <lamby> #action h01ger to set up a doodle poll re Summit #3 dates
16:39:46 <emaste> somewhere in Europe presumably?
16:39:49 <h01ger> are you aware of any other free software events on these dates?
16:40:09 <h01ger> emaste: yes, something like that, though we thought about Tunesia too
16:40:13 <lamby> LWN event calendar is good this
16:40:24 <h01ger> lamby: can you check that calendar please?
16:40:51 <h01ger> emaste: also gwolf's offer for mexico city still stands, i assume, but i also assume flying us there will be too expensive. dunno
16:40:59 <bmwiedemann> openstack summit in sydney 2017-11-06 to 08
16:41:16 <vagrantc> piggybacking on another event can give some people extra reason to go
16:41:32 <h01ger> last news about the meeting: /me has found some help with organizing it. so you should see a more relaxed and less exhausted h01ger at the meeting
16:42:00 <h01ger> vagrantc: piggypacking on another event sounds like a good idea but in practice has often turned out to be a not so good idea in the end
16:42:00 <emaste> good
16:42:08 <lamby> O'Reilly Security Conference clashes (NY)
16:42:29 <emaste> for the first week
16:42:30 <lamby> But… even if there were more clashes, probably do the doodle anyway as that will capture the same details.
16:42:35 <emaste> yeah
16:42:39 <h01ger> yeah
16:43:04 <vagrantc> h01ger: curious why those two dates came up?
16:43:15 <h01ger> vagrantc: available in gunner's calendar
16:43:27 <vagrantc> got it
16:43:28 <h01ger> not in december, not in the next 3 months, this year
16:43:51 <lamby> #info Tentative dates are a) Oct 31 → Nov 2, b) Nov 7 → Nov 9.
16:44:02 <h01ger> there's a 3rd fallback date too, but thats in early mid december…
16:44:23 <emaste> will you put it in doodle poll too?
16:44:31 <h01ger> #info no work has been done on funding the event yet… talk to us if you want to sponsor it
16:44:42 <h01ger> emaste: not sure, probably rather not
16:45:01 <lamby> Feel like we've got everything captured here. Next topic? :)
16:45:13 <bmwiedemann> why not? if people dont like it, it will not get the most 'yes'es
16:45:14 <h01ger> almost
16:45:23 <h01ger> one thing: you should all attend the summit! :-D
16:45:50 <h01ger> bmwiedemann: because i would rather do it in january than mid december
16:46:11 * h01ger has a date in mid december in leipzig… ;)
16:46:18 <bmwiedemann> hehe
16:46:21 <lamby> Yes, definitely; if you are remotely interested in Reproducible Builds (ie. you are in this channel) then you _should_ be at this meeting.
16:46:38 <bmwiedemann> totally worth it
16:46:38 <lamby> Don't think "oh, no, I am not doing / thinking enough…"
16:46:48 <lamby> #topic Next meeting when?
16:46:49 <h01ger> what lamby says!
16:46:55 <h01ger> when is the next irc meeting?
16:47:07 <h01ger> (this is basically a standard topic for each meeting…)
16:47:18 <bmwiedemann> Thu 2017-07-06 ?
16:47:22 <h01ger> (even if we have a very fixed schedule…)
16:47:28 <lamby> 1st Thursday of July, ie. 6th :)
16:47:38 <vagrantc> lamby: didn't you come up with a rough plan for rotating the time?
16:47:40 <h01ger> which time?
16:47:52 <lamby> I will send out a confirmation of it all after this meeting :)
16:48:20 <h01ger> #info next meeting on the first thursday of the month, that will be july 6th 2017 at a to be decided time
16:48:32 <bmwiedemann> there might be people not subscribed to the rb-general ML
16:48:32 <h01ger> #action lamby will announce the next meeting
16:48:33 <lamby> Thanks
16:48:43 <lamby> #topic Any other business
16:48:46 <lamby> #save
16:48:46 <h01ger> bmwiedemann: you're point being?
16:48:56 <bmwiedemann> they will not know the time then ;-)
16:49:06 <h01ger> we'll also blog it
16:49:08 <h01ger> and tweet it
16:49:11 <h01ger> and /topic it
16:49:12 <h01ger> :-)
16:49:14 <bmwiedemann> fair enough
16:49:31 <emaste> thanks all
16:49:37 <lamby> thanks emaste
16:49:38 * h01ger is happy about 13 people being present at this meeting
16:49:53 <h01ger> well, 12, lets not count meetbot ;)
16:50:12 <bmwiedemann> hey, even robots have feelings.
16:50:22 <vagrantc> citation needed
16:50:32 <h01ger> marvin
16:50:40 * sangy hastily edits wikipedia's robot entry
16:50:56 <h01ger> any other other business?
16:50:56 * vagrantc tries to think of any outstanding issues that warrant irc discussion...
16:51:09 <bmwiedemann> I got one
16:51:23 <bmwiedemann> I recently stumbled over gcc's profile guided optimisations
16:51:34 * h01ger has submitted a BoF about jenkins.debian.org & its team maintenance for DebConf17
16:51:39 <bmwiedemann> causing non-determinism (e.g. in gcc6 and python for openSUSE)
16:52:15 <bmwiedemann> has anyone else seen such?
16:52:57 <sangy> I have a quick query
16:52:59 <bmwiedemann> the effect is typically some diffs in assembler, where code gets moved around
16:53:24 <sangy> are there any up for grabs kinda tasks that I can start looking at to get myself familiar with any codebase, etc.?
16:54:09 <bmwiedemann> sangy: in what direction? working on tools to track rb work or fixing rb issues? or other?
16:54:15 <h01ger> bmwiedemann: once we have shared json and thus suse in our db, we can make the notes cross-distro (see the branch in git for a notes.yaml format discussion there) and then you can documents your findings there and then we can hopefully share problems and solutions better
16:54:31 <h01ger> but first the packages.json, then the notes.yaml… :)
16:54:49 <Eric[m]> Profile guided optimizations is a losing game
16:54:50 <h01ger> sangy: we have several codebases…
16:55:10 <sangy> bmwiedemann: mostly the former
16:55:13 <h01ger> (eg diffoscope, the webpages, build_path_prefix fixes in 30 projects or so)
16:55:21 <Eric[m]> We actually had a sticky note for that very thing on one of our pages about "defining reproducible" at last summit iirc
16:55:27 <sangy> h01ger: yep, that's right.
16:56:03 <bmwiedemann> Eric[m]: I found that it is possible to do PGO and RB, but it is not so easy.
16:56:06 <h01ger> for Arch Linux, you might want to look at anthraxx's pacman patch and try that?
16:56:26 <bmwiedemann> the trick is to make sure to only have reproducible input to the profiling-run
16:56:32 <Eric[m]> Profiling to select optimizations: great.  Doing it in the middle of the build, thus making the result host and lunar phase dependent: not great.  Answer: save your profile results, bless them forever...
16:56:40 <Eric[m]> Oh can that really be managed?
16:56:44 <sangy> h01ger: yeah, that's something I'm already looking at
16:56:57 <h01ger> sangy: cool. i was about to give you the urls… :)
16:57:20 <emaste> Yes ISTM that the profiling data must just become a build input
16:57:36 <Eric[m]> I'd have thought universe-1.0 insanity like temperatures and stuff would be able to derail it (low probability, but nonetheless probabilistically)
16:57:40 <h01ger> shall we close the meeting and keep the discussion happening as they do?
16:57:45 <bmwiedemann> Eric[m]: I did a fix in https://build.opensuse.org/package/view_file/Base:System/gzip/gzip.spec?expand=1 line 70
16:57:51 <Eric[m]> +1 to the emaste phrasing there
16:58:35 <emaste> h01ger: I think so.
16:58:40 <h01ger> sangy: re, the tools to track rb… thats in jenkins.debian.net.git
16:58:51 <bmwiedemann> OK
16:59:00 <sangy> h01ger: awesome, thanks
16:59:05 <lamby> h01ger: Yes :)
16:59:05 <h01ger> sangy: look for bin/reproducible_db_maintenance.py and bin/reproducible*html*.py
16:59:09 <lamby> #endmeeting