17:58:16 #startmeeting 17:58:16 Meeting started Mon Oct 26 17:58:16 2020 UTC. The chair is h01ger. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:58:16 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:58:19 o/ 17:58:33 #topic say hi and review and amend the agenda 17:58:44 agenda is at https://pad.sfconservancy.org/p/reproducible-builds-meeting-agenda 17:58:54 * h01ger is Holger Levsen 17:59:04 Chris Lamb. o/ 17:59:27 then agenda is kinda short today (which is fine) 18:01:43 * bmwiedemann is Bernhard M. Wiedemann 18:02:41 jg_: hi, meeting just started, backlog at http://meetbot.debian.net/reproducible-builds/2020/reproducible-builds.2020-10-26-17.58.log.txt 18:03:01 * h01ger will wait two more minutes before going to the next topic 18:03:06 * aehlig is Klaus Aehlig 18:03:11 * vagrantc is Vagrant Cascadian 18:05:31 #topic 2. followup to the brainstorm of potential topic-specific irc sessions 18:05:46 https://pad.sfconservancy.org/p/reproducible-builds-meeting-agenda has a list of suggestions 18:06:07 and the idea is that at each meta meeting we nominate one topic for topic-specific irc sessions 7 days after that meta meeting 18:06:16 with the meta meeting being the one today 18:06:50 becuase the pad is going to be edited, i'll quote the list of suggested topics here 18:07:07 and then will leave it to vagrant to actually determine the topic for next week ;) 18:07:31 topics to select for future topic-specific irc sessions (paraphrased somewhat): 18:07:31 discussion of rb-format 18:07:31 debian: distributing .buildinfo files for real 18:07:31 debian: a new .deb format including .buildinfo files (combine or separate from previous?) 18:07:33 goals from last summit https://reproducible-builds.org/files/ReproducibleSummit5EventDocumentation.html#__RefHeading___Toc14828_2303288670 18:07:33 review current published research being done; collect some of it on the webpage. 18:07:36 diverse-double-compiling in the real world 18:07:36 use dettrace more in tools - especially the autoclassify. 18:07:38 strategize a vision for reproducible builds 1/3/5 years in the future 18:07:38 open office hours Q&A session 18:07:40 rebuilder progress / pain points 18:07:40 how to debug Debian and other OS versions (e.g. https://github.com/bmwiedemann/reproducibleopensuse/blob/devel/howtodebu\g) 18:07:43

fully reproducible distros ... next steps (needs to be broken down a bit more) 18:07:43 ---- end of list 18:07:47 Sounds good. 18:08:38 i figured it would be best to ask what people wanted to do 18:08:51 it also occurred to me that we could have multiple topics in parallel, potentially 18:09:08 h01ger: What does "discussion of rb-format" refer to? 18:09:14 * h01ger thinks for a start a single topic is better 18:09:51 lamby: the format aparcar[m] has been proposing to store .buildinfo files^w^wbuild results of several/all projects in one database 18:09:53 h01ger: yeah, single topic per week for starters that maybe works best 18:10:39 h01ger: i was also thinking the distributing .buildinfo files for real and the .buildinfo in .deb discussions could be one topic, but maybe i miss something 18:10:46 h01ger: so a bit like the reproducible.json files? 18:10:50 * vagrantc rearranges the post-it notes on the board 18:11:13 bmwiedemann: wes 18:11:15 yes 18:11:43 vagrantc: i think those are two different topics 18:13:18 * h01ger likes Foxboron's topic suggestion: "review current published research being done; collect some of it on the webpage." - because we already have some and we want more and because this topic would be inviting people who are very aware of r-b but probably not so much working with us so far 18:14:13 i had also thought of the "open office hours Q&A" as a potential starting point for newcomers, or people who've been out of touch for a bit 18:14:42 (it was kind of prompted by david-a-wheeler's questions) 18:14:55 we could just do that in general. be around at certain known times 18:15:00 I like both of those. 18:15:23 (sorry I'm planning my LUG repro builds presentation :) a bit delayed) 18:15:31 so, realistically, i dont see any topic that i wouldn't be interested in :) 18:15:49 shall we choose by lottery? 18:15:54 vagrantc: then pick one ;-). 18:16:00 vagrantc: what jg said 18:16:19 I would suggest "what" precedes "how", but it hardly matters. 18:16:21 so no ranked condorcet voting in good Debian tradition? 18:16:27 bmwiedemann: i think thats a good but different idea 18:16:42 (not condorcet but open office hourse) 18:17:37 the winner is: how to debug Debian and other OS versions (e.g. https://github.com/bmwiedemann/reproducibleopensuse/blob/devel/howtodebug) 18:17:49 Neat. :) 18:17:56 yay 18:18:00 though a highly sophisticated randomizing shell one-liner 18:18:12 #info the winner is: how to debug Debian and other OS versions (e.g. https://github.com/bmwiedemann/reproducibleopensuse/blob/devel/howtodebug) 18:18:27 seq 12 | sort -R 18:18:34 the results of which better not be reproducible :) 18:18:43 vagrantc: do you you want to make a quick dudle poll for the time (eg the next 48h) or just stick with 18 UTC? 18:19:02 * h01ger would just like the exact date and time to be known as much in advance as reasonable possible 18:19:03 h01ger: i'm fine with just sticking with 18 UTC on monday for simplicity 18:19:10 yay 18:19:12 hello. Sorry for being late! 18:19:17 maybe three mondays out then? 18:19:23 to give more notice 18:19:24 ? 18:19:28 #info date will be november 2nd, time 18 utc 18:19:36 vagrantc: with the timezone change, I would prefer 19 UTC 18:19:41 vagrantc: you mean in three weeks? 18:19:56 h01ger: yeah ... since in two weeks it would be our next metameeting 18:20:04 aparcar[m]: hi. backlog at http://meetbot.debian.net/reproducible-builds/2020/reproducible-builds.2020-10-26-17.58.log.txt and just in time, the next topic is yours 18:20:16 bmwiedemann: ah... well, would hate for you to miss out 18:20:27 * h01ger will miss out if its moved to 19 utc 18:20:33 dinner etc 18:20:35 ah well ... 18:20:45 maybe we need another poll? 18:20:50 but then, if we do it in three weeks, a dudle poll is fine 18:21:21 ok, i'll do a poll 18:21:25 cool 18:21:41 #info date will NOT be november 2nd, time 18 utc - instead vagrantc does another dudle poll for the time 18:21:54 h01ger: my topic as in openwrt status? 18:22:01 vagrantc: but the date will be monday, the 16th? 18:22:02 and date november 16th? 18:22:08 aparcar[m]: lets stay on topic for now 18:22:10 that's my thinking 18:22:19 aparcar[m]: agenda is at https://pad.sfconservancy.org/p/reproducible-builds-meeting-agenda 18:22:34 vagrantc: ok, works for me 18:22:55 #info date will be nov 16th, vagrant does a poll for the time(s) 18:22:55 #info date will be november 16th, time to be determined by poll 18:23:03 hah 18:23:04 (also for future meetings i' 18:23:07 d hope) 18:23:28 so next topic then? and we keep the list in the pad for future meetings 18:23:38 so if we pick it three weeks out, that gives us time to prepare people, and a metameeting to remind about the next one 18:24:00 * h01ger nods 18:24:37 #topic 3. rb-format 18:24:39 We can also announce the Nov 16 one in good time on the blog/twitter/mailing list etc. 18:24:44 yeah 18:24:57 aparcar[m]: the stage is yours. let me paste two lines from before.. 18:25:10 [19:10] < lamby> | h01ger: What does "discussion of rb-format" refer to? 18:25:16 [19:11] < h01ger> lamby: the format aparcar[m] has been proposing to store .buildinfo files^w^wbuild results of several/all projects in one database 18:25:26 [19:12] | h01ger: so a bit like the reproducible.json files? 18:25:42 ok, 3 lines :) 18:25:48 okay regarding the format, it just stalled after mapreri and me designed some database and jason from microsoft gave good comments on the format 18:26:06 there was some discussion on the mailing list but ater in-toto was proposed, very little happened 18:26:06 aparcar[m]: can you please rephrase in your words what this is about? 18:26:37 (or confirm bmwiedemann and myself got it correctly :) 18:27:14 h01ger: yes correct. Similar to buildinfo, however a file containing less details 18:27:45 a file? not a table? 18:27:54 mostly something that could replace the current jenkins rendering with a more unified approach 18:28:06 a json file containing a table/list/array so to speac 18:28:08 *speak 18:28:41 related link: 18:28:41 the format itself: https://github.com/aparcar/reproducible-builds-verification-format 18:28:58 a collector which renders results: https://github.com/aparcar/rbcollector 18:29:02 you want something a bit more cross-distribution and not reimplemented in each distro to display reproducibility information... 18:29:08 here is a demoL https://rebuild.aparcar.org/ 18:29:20 vagrantc: yes make thinkgs compareable 18:29:52 and also easier to extend. I created github/gitlab CI jobs to rebuild and create those files 18:30:04 aparcar[m]: if i remember correctly you wanted to summarize the mailing list discussion? because there were some good replies 18:30:16 so more and more people could start providing rebuild information instead of a single institution 18:30:23 also https://github.com/aparcar/reproducible-builds-verification-format ?? 18:30:48 vagrantc: I don't understand the comment 18:31:06 nevermind, mouse error on my part 18:31:27 h01ger: sorry I remembered that me and someone else would do it but I guess both forgot about it. I'll do it after this meeting 18:31:49 but my main question is is maybe if this is still "desired" 18:32:14 or if things are to different anyway between distros 18:32:39 because there were comments that debian builds different than arch, so the results don't need to be comparable 18:32:55 aparcar[m]: i think the reality could be that we desire it but find out its too difficult/impossible because distros are too different 18:33:09 (also because we have more than distros) 18:33:24 aparcar[m]: ismypackagereproducibleyet.org could use it. 18:33:41 bmwiedemann: yes that would be cool 18:33:54 h01ger: yes I think that is the current state 18:34:03 the results, as in the hashes, wont be comparable. what would be comparable is: is the software "emacs" reproducible on distro1 and distro2 and why not in distro3 18:34:20 which sounds like a useful comparison 18:34:20 (emacs being an example here, obviously) 18:34:29 h01ger: yes, and we have a clean and nice website 18:35:11 okay I'd be okay with silently continue the work and once things mature, propose it again 18:35:28 aparcar[m]: the clean website is a distraction here. we could have that with anything :) 18:35:50 h01ger: fair. point is an easily extended website 18:35:51 aparcar[m]: and i think we want to move the git repo to the usual git repo space 18:36:04 i suspect fedora/debian/arch families are going to be similar enough ... but it gets weirder with nix/guix 18:36:04 where multiple external entities can contribute results 18:36:30 aparcar[m]: we are talking about a data format. you can make pancakes or websites from it. but lets not talk about pancakes or websites but lets focus on the database 18:36:33 h01ger: what does that mean? 18:36:35 there is a more fundamental question: is there any need to share information between platforms (in the same history of builds)? Similarly, to have information from different rebuilders in the same file/log? As soon as you tie these into one database, you set up one target for bad guys.... 18:37:19 Yes, what is the concrete use case for consolidating this data cross-distribution? 18:37:34 jg: good point. i consider this database to be an aggregator of information but not to be the source of 'truth' 18:37:42 ismypackagereproducibleyet.org seems a perfect use-case 18:37:48 jg: ideally we'd had multiple collectors and many many rebuilders. rebuilders provide the rbvf files 18:37:55 i imagine bmwiedemann has to parse a lot of different data now to make that work 18:37:57 https://ismypackagereproducibleyet.org/?pkg=perl 18:38:12 in fact, I am arguing that keeping the information separate, so that a bad guy has to break multiple systems... 18:38:22 * h01ger thinks we are mixing too many topics 18:38:28 vagrantc: I just apply some normalizations on the existing reproducible.json files that vary slightly 18:38:49 eg ci results and real world results 18:38:59 h01ger: I agree we're mixing things but maybe the format is just obsolete if we agree on a lower level against combining the information 18:39:55 my fundamental question about it was a binary reproducible=yes/no result is kind of unsatisfactory ... but also more implementable 18:40:11 IMHO, it is comparable to RSS - it can be combined in aggregators, but you dont have to 18:40:22 my wish for this topic would be to continue the mailing list discussion we had. there were several good replies (to the initial proposal) but never a revised proposal based on the replies 18:40:34 i see having a standard format makes it possible to combine however one wants 18:40:44 bmwiedemann: good point 18:40:48 which can be useful for analysis 18:40:56 note that with the extensible json format, one may have one's cake and eat it too... some uses may combine the information, by adding fields. 18:41:38 h01ger: I'd suggest we continue in the mailing thread as this opens up to many jars 18:41:48 jg: agree 18:42:14 aparcar[m]: ok, cool with me. i'd suggest we still keep this topic on the agenda, if only to remind us to have this discussion via mail? 18:42:27 h01ger: ack 18:42:27 seems like a plan. 18:43:16 coolio 18:43:38 #agreed we'll continue this discussion on list and keep the topic on the irc agenda 18:44:09 * h01ger also wants to restate that he would like to see a 2nd version of the proposal with the feedback incorporated 18:44:17 next & last topic then? 18:45:12 sound good 18:45:19 #topic 4. any other business 18:45:59 * h01ger has nothing on topic to add 18:46:44 None here. 18:46:57 motion to adjourn? 18:48:21 we could still brainstorm about the r-b long-term vision after the meeting 18:48:37 can always do that :) 18:49:02 just one thing: even though the turnout is less than last time, i'm still very happy we restarted these meetings and i'm confident they will proof useful over time, especially as we wont have in person meetings for some time to come 18:49:27 +1 18:49:30 i'll be interested in how the topic-specific sessions turn out over time :) 18:49:47 h01ger: We can make these video meetings, if people want.... 18:50:20 i think some people aren't up for that ... 18:50:21 feels good to 'talk' with you, even if Gunner would have his own ways of leading 18:50:27 jg: i think text meetings are soo much better 18:50:35 but it might be interesting to have a video social around r-b for those that do 18:50:47 by all means do 18:50:49 it varies which is best... 18:52:16 vagrantc: certainly possible. I'm much more comfortable with Webrtc based video that zoom, however. 18:52:19 or maybe that would work for office hours idea too 18:52:41 could probably get some space on a jitsi instance 18:53:20 that, or I can trivially provide Google meet. I'm up for trying jitsi, however, having never had a chance. 18:53:40 * vagrantc is no fan of google 18:53:57 vagrantc: such as https://meet2.opensuse.org/rb 18:53:57 jitsi.debian.social is open for basically anyone 18:54:09 options 18:54:38 bmwiedemann: such as :) 18:55:43 actually, if we had video-chats on an opensuse server, that'd break the "reproducible builds is a debian thing" idea in a positive way :) 18:55:50 indeed 18:55:55 pick one.... 18:56:21 i'll take this as a closing comment and say thank you all for attending and looking forward to see you again in 2 weeks! 18:56:32 thanks all! 18:56:33 #topic next meeting 18:56:36 bye thanks! 18:56:46 vagrantc: pick one now, and you and I can try it out.... 18:56:52 #info next meeting will be on monday, 9th of november, at 18 utc 18:57:03 cheers! o/ 18:57:05 jg: i'd have to set up a different machine ... this machine has no video conferencing ability 18:57:19 vagrantc: you could see us? 18:57:22 Thanks all. :) 18:57:30 bmwiedemann: ah, true 18:57:47 vagrantc: feel free to ping me to try whatever you want out.... 18:57:51 i'll drop by 18:58:00 https://meet2.opensuse.org/rb 18:58:15 #endmeeting