18:59:31 #startmeeting 18:59:31 Meeting started Thu Sep 7 18:59:31 2017 UTC. The chair is lamby. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:31 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:59:37 Welcome all. 18:59:42 hello 18:59:48 * vagrantc waves 19:00:02 #link https://pad.riseup.net/p/reproducible-irc-meeting-12 19:00:05 Agenda is there ^ 19:00:10 o/ 19:00:13 o/ 19:00:14 hey vagrantc, emaste 19:00:17 * sangy waves 19:00:25 Hey pkmoore, have we met before? 19:00:29 welcome anyway 19:00:50 Maybe? Hahaha thanks! 19:01:04 lamby: pkmoore is a colleague of us at NYU, if my guess is right :) 19:01:28 yep! 19:01:39 Ah cool. 19:01:59 Speaking of NYU I was asked to look at some security/crypo papers, but that's another topic… 19:02:19 We'll just give it a few minutes to see who else is about then we'll kick off at 20h05 sharp… 19:03:01 I had some discussions about in-toto integration in OBS/osc/zypper, too 19:03:18 mea culpa on all of those 19:04:24 hah 19:04:36 #topic Apologies 19:05:09 So d'anielsh and j'athan added themselves here, and I believe h'01ger mentioned a clash earlier in the scrollback. 19:05:57 #topic 3rd Reproducible Builds Summit meeting 19:06:09 I'll take what I can of this from h'01ger 19:06:13 #info Tue Oct 31 → Thu November 2nd inclusive 19:06:18 02lynxislazus: 06@Linuzifer Glückspielmaschienen müssen reproducible sein. Wieso ist das nicht auch bei Wahlsoftware? cc @ReproBuilds14 — https://twitter.com/lynxislazus/status/905870007879565313 19:06:34 #info No need to RSVP yet but please book travel ASAP. 19:07:13 It will be in Berlin. 19:07:22 "Formal" invitations in the next 2/5 days I reckon. 19:07:38 (But, basically, everyone is invited) 19:08:05 Naturally we'll get a wiki page setup so folks liase transport and share accomodations if necessary. 19:08:34 Sponsor foo is ongoing, just to get exact quotes from venues as that tends to go down a little better. :) 19:08:43 Any queries on this atm? :) 19:09:12 will this be similar in style to last year's ? 19:09:26 hi hi 19:09:56 bmwiedemann: Yes, indeed 19:10:17 good 19:10:18 bmwiedemann: Feedback naturally welcome if you think things could be improved, but it will be "run" by Gunnar. 19:10:31 02techniker: 06In der Realität sieht das aber auch bei Glücksspielautomaten eher "anders" aus... (in reply to: @lynxislazus @Linuzifer @ReproBuilds)14 — https://twitter.com/techniker/status/905871068304461825 19:11:06 Kinda hi. 19:11:23 ('Sup.) 19:11:31 Anything else on the summit for now? 19:12:31 19:13:21 #topic Cursing on the irc channel 19:13:45 Classic. 19:13:50 I am going to leave this with h'01ger and d'anielsh as it was added by and/or from them. 19:14:05 ie. skipping as discussing without them seems silly 19:14:21 Hear hear. 19:14:35 "darn" 19:14:35 *fscking silly (etc.) 19:14:42 Oh you beat me to it. 19:14:47 #topic Mentors for Outreachy 19:14:58 mapreri sent an email 19:15:01 #link https://lists.debian.org/debian-outreach/2017/09/msg00000.html 19:15:11 If you would like to be a mentor or a student, please read that. 19:15:15 #link outreachy.org 19:15:47 * Faux bookmarks. 19:16:02 Oh dear, the linked link to the wiki 404s right now. :) 19:16:31 * vagrantc has been having 404 issues with wiki.debian.org today 19:16:32 We've had good results from outreachy/gsoc "students" previously so we would love to participate again, naturally. 19:17:04 * sangy bookmarks 19:17:29 o/ 19:18:10 o/ 19:18:22 Any questions on outreachy stuff? 19:18:25 o/ 19:19:34 Cool 19:19:39 #info Testing on ppc64el 19:19:44 err 19:19:47 #topic Testing on ppc64el 19:20:05 Ew. 19:20:11 So we currently test on i386, amd64, armhf & arm46 19:20:14 someone has hardware to offer? 19:20:19 question there: is there much benefit given that 99+% of r-b issues are arch-independent? 19:20:32 We've been offered some cloud hardware for ppc64el 19:20:34 apart from packages that only build on that arch 19:20:47 bmwiedemann: ppc64el is really fast 19:20:53 well, could be 19:21:04 arm64 is also comparable though right? 19:21:06 true. IBM builds good stuff 19:21:20 It would be nice to have a (single) alternative, fast arch. 19:21:36 It increases visibility. It also is power which not-just-another-arm-variant :) 19:22:07 There are also some initiatives (Kickstarters?) that want to make open-down-to-the-chip systems 19:22:23 like openrisc 19:22:23 … which dovetails nicely with the concept of reproducible builds from a privacy PoV. 19:22:42 How much sysahmin time currently scales per arch? Probably maperi and h1lger. 19:23:12 I can't seem to find the links right now, but it's a cool project. 19:23:17 One of these days I will spell that nick. 19:23:32 nick(s) 19:23:43 Eventually testing cross-arch reproducibility will be nice 19:23:52 Anyway, so, I had an initial poke at adding support for ppc64el and there is a branch. 19:24:02 armhf is probably the most fiddly, since there are so many slow nodes 19:24:23 But h01ger claimed there would need to be some other fixups in terms of fixing some capacity things. 19:24:35 with jenkins? 19:24:41 In/around jenkins yes. 19:24:51 it has been choking now and then lately 19:25:12 we could also explore alternative infrastructure ideas 19:25:14 So it's "just another arch" in theory but in practice it will need Jenkins admin foo. I cannot accurately recall the details atm but disk space was mentioned, just as one possible example. 19:25:21 Lag from IRC bouncer to OFTC is worse than the lag from my phone to the bouncer. SIGH. 19:25:33 Anyway, I bring it up here in case others are interested in chasing this :) 19:25:45 e.g. could use ppc64el to test rebuilds from the archive 19:25:48 do we have actual hardware ready? 19:26:31 offers of cloudware 19:26:41 Logins for cloud in fact. 19:27:02 (Currently quota limited, but easily bumped.) 19:27:15 I've done some test builds, seems to be fairly speedy. 19:27:32 i think we should spend effort elsewhere unless someone specifically has some cool stuff on ppc64el that would directly benefit from this 19:27:34 what kind of specs currently? 19:28:30 vagrantc: Cloud, so… "cloud vCPUs". Vague. 19:28:58 The capacity is there when we want it, being the important thing. 19:29:20 Anyway, just raising attention in case anyone has, err, capacity to jump on it. 19:29:28 #topic Any Other Business? 19:29:30 infinity0: a round of cross-compilations could be nice to see how much we can trust x86 CPUs 19:29:39 So, any other business? :) 19:30:29 i can see doing this stuff a bit further down the line, yes. atm we're still a fair bit a way from doing cross-arch builds (either to check reproducibility of arch-independent doc packages or to do diverse-double-compilation) 19:31:21 and gcc notably doesn't itself build reproducibly yet... 19:31:53 One other bit of "business" is that http://isdebianreproducibleyet.com/ ticked up :) 19:32:08 nice 19:32:22 Slowly, slowly… 19:32:44 should have registered reproducibleyet.com and then used subdomains :) 19:32:58 heh 19:33:05 errr, I guess we still have some time. Mind if I add a topic? 19:33:11 sangy: Sure, just raise it here 19:33:20 the NYU thing? 19:33:23 so I've been reading on reprobuilds "sharing certification" 19:33:26 vagrantc: Used? Sold! ;) 19:33:27 vagrantc: nope 19:34:16 Just throwing things around, but couldn't we easily use in-toto to have people attest to have reproduced a build? 19:34:32 guys, i just saw someone talk about the ppc64el architecture and i'd like to make a comment about it 19:34:33 In that note, I think I could easily add to reprotest an option to create/sign link metadata for it... 19:34:46 * sangy can hold this up if we want to go back to ppc64el 19:34:49 sangy: sounds useful 19:35:30 if you're interested on a build environment, i've worked for over a year on a ppc64el public cloud project with IBM and i'm sure i can get a lot of machines for reprobuilds to use (: 19:35:30 sangy: that sounds pretty useful yes. you mean like add a link to in-toto for each sha256sum/sha512sum produced? 19:35:55 we also host debian ppc64el repo on this cloud 19:36:09 infinity0: I was thinking of creating in toto metadata containing what the source-files were and the build log. Then record the hash of the final artifact as a product 19:36:29 jwnx[m]: (That is the source of my current cloud stuff ^ ) 19:37:17 infinity0: now that I re-read what you said, I think we may be saying the same thing 19:37:36 lamby: oh sry, just got here lol 19:37:55 i'd be happy to take a pull request for that! you might want to wait a few days though, i'm in the middle of refactoring reprotest quite heavily 19:38:07 can we add a link for more information? 19:38:27 emaste: just use #link 19:38:46 the goal of the refactoring is to support something similar to bmwiedemann's cause-of-irreproduciblilty auto-detector 19:38:48 #link https://ssl.engineering.nyu.edu/projects#in-toto 19:38:50 infinity0: sure thing! I'm still struggling with streamlining the arch part of it. I can probably continue this discussion through the ML to work out the specific 19:39:01 sounds good :) 19:39:10 Neat. 19:39:17 infinity0: interesting, is that discussion going on in the ML? can I help anyhow on that front? :) 19:39:18 Any other other business? :) 19:39:45 * sangy is good for now :) 19:39:56 Nice one. I'll be around until my battery dies, but going to close out the meeting otherwise 19:40:24 sangy: there was a thread about it "auto-analyzing indeterminism" from mid/end-july, i'm ok to handle the reprotest-specific part of that myself 19:40:33 Will send stuff around tonight or tomorrow at the latest (minutes, etc.) plus confirming the date for the next meeting. 19:40:41 Yeah the autodetecting thing sounds awesome btw 19:40:42 infinity0: oh, ok. I'll keep an eye on it though, sounds super interesting :D 19:41:30 #topic using intoto to have people attest to have reproduced a build 19:41:45 #info see also "auto-analyzing indeterminism" from mid/end-july on ML 19:41:48 #endmeeting