16:13:44 #startmeeting 16:13:44 Meeting started Tue Oct 23 16:13:44 2018 UTC. The chair is vagrantc. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:13:44 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:14:45 #topic apologies 16:14:51 h01ger might not be able to make it 16:14:58 #intros 16:15:06 #topic intro 16:15:12 please introduce yourself! 16:15:13 * vagrantc waves 16:15:15 hi 16:15:20 hi o/ 16:15:23 just something short for the logs 16:15:23 Yo! 16:15:31 o/ 16:15:39 hi o/ 16:16:22 o/ 16:16:36 #topic cross distro notes 16:16:45 Cross distro notes sharing and tracking patches merged upstream but not in a new release or patched already in debian and not merged. 16:16:52 hi hi (late) 16:17:00 dkg: we all are :) 16:18:06 so, anyone have thoughts on how we can more effectively share information about reproducibilities issues, patches, etc? 16:18:46 this may specifically be about the "notes" git repository that debian uses, and making the format useful to other projects 16:19:41 well, we have the upstream name of the package in the yaml right? couldn't we just add a reference to the distro-specific name and package? 16:19:41 #link https://salsa.debian.org/reproducible-builds/reproducible-notes 16:20:09 if it's unreproducible it's unreproducible. I don't think we'll have a mismatch on that fact on distro-specific information 16:20:09 I may have miss a ton of previous discussions, but what is the format that we worked on in the last summit in Berlin lacking? 16:20:11 #link https://salsa.debian.org/reproducible-builds/reproducible-notes/tree/multi-project-syntax 16:20:15 sangy: h01ger has a proposal about notes sharing. https://salsa.debian.org/reproducible-builds/reproducible-notes/blob/master/ideas_on_sharing_notes_between_distros 16:20:36 oh, we could probably link that too 16:20:43 #link https://salsa.debian.org/reproducible-builds/reproducible-notes/blob/master/ideas_on_sharing_notes_between_distros 16:21:00 I'd like to know as other distro if a fixed issue in Debian was merged upstream (and maybe even in which release it is) 16:21:50 this would save me a lot of search work basically and tracking not yet patches might be useful, although I'm not sure if that is already done somehow 16:21:59 we have historically removed things once they are fixed in debian 16:22:09 I wonder if we want to change that 16:22:12 right 16:22:19 or have some sort of archival process 16:22:32 vagrantc: we could just "move" them to a different file 16:22:52 part of the issue is we may not always know exactly why it was fixed ... toolchain fixes sometimes transform a lot of things into reproducible 16:23:14 so I'm looking at the schema, it has state: fixed and comment: 16:23:20 wouldn't that be enough? 16:23:43 sure 16:23:49 sounds good 16:24:00 or maybe even "fixed-version" ? 16:24:20 so that we don't have to extract verison information out of a comments field... 16:24:33 I think we could also formalize what the fields mean exactly 16:24:40 link to fix would also be nice (git commit if possible) 16:24:42 url could be an upstream url of the bugreport or something 16:25:01 jelle: that could be a separate field or part of comment:. I'd be fine with either 16:26:13 the other main thing is actually getting people to use it ... and maybe that would lead to some refinements 16:26:27 I also wonder if we'd like to have an issue id to cross-reference issues between the package and the issue 16:26:44 I believe issues may belong to many packages? (e.g., splitpkg's in Arch) 16:27:31 package names will always differ per distro :) 16:27:36 there are extensive issues, and given packages are essentially tagged with the relevent issues 16:27:57 #link https://salsa.debian.org/reproducible-builds/reproducible-notes/blob/master/issues.yml 16:28:31 jelle: indeed... 16:28:59 jelle: that's why id's could probably help 16:29:41 use the upstream name, and have a field for distro-specific names? 16:29:50 sangy: but I believe that shouldn't be an issue if we use the upstream name 16:29:50 although even that is maybe sometimes non-obvious 16:30:15 as seen here https://salsa.debian.org/reproducible-builds/reproducible-notes/blob/master/ideas_on_sharing_notes_between_distros#L42 16:30:39 * sangy looks at dockerio 16:31:02 it's not the mexican docker guys, it's just your usual whale-themed container system 16:31:16 sangy: are you saying to use IDs unrelated to the name? 16:31:40 vagrantc: I'm saying using the upstream name as an id, and have a reference to the distro-specific name 16:31:45 and having an issue number for each issue 16:33:20 sangy: unrelated to issues.yml ? 16:33:41 no, i.e., add a field with issue_number: xx 16:33:49 here: https://salsa.debian.org/reproducible-builds/reproducible-notes/blob/master/ideas_on_sharing_notes_between_distros#L34 16:34:46 A bunch of examples might be helpful to come up with, or even just to start with something outrageously simple and see what edge-cases need adjusting for. 16:34:59 There is no need to nail the specification the first time around, after all. 16:35:02 (if ever.) 16:35:35 * sangy grumbles academically 16:35:54 fair enough. what'd be a good action point for this topic? 16:36:31 seems like converting all the existing debian-specific files to the generic format, and then fill in other distro-specific things? 16:36:53 that would probably require some re-tooling for tests.r-b.org/debian 16:38:37 hmm, yeha that sounds a little painful 16:39:08 maybe something to tackle at the summit? 16:39:26 which might be a useful segway... 16:40:15 someone want to bring this up on the list and try and get some discussion going? 16:41:17 +1 to both ideas 16:41:45 alright, i'm inclined to keep the agenda moving :) 16:41:48 #topic summit 16:42:04 paris, december 11th-13th, very exciting! 16:42:30 sounds very good, something to mention is that it appears that it'll be at the same time as kubecon NA, which I'll be attending 16:43:05 https://www.opensourcesummit.paris/ is the previous week, in case people wish to make "more" of the trip. 16:43:11 #link https://www.opensourcesummit.paris/ 16:45:12 ... is there more to say about this topic? 16:45:28 I think it rather comes hand-in-hand with the next one 16:46:09 * vagrantc would like to see a presenter on each agenda topic in the future 16:46:36 +1 to that too. I really like your ideas vagrantc :P 16:46:39 ok, next... 16:46:46 #topic fosdem booth 16:47:16 fosdem is coming up, does reproducible-builds want to share a booth with someone? 16:48:12 I'll be attending fosdem, but probably busy with other things 16:48:31 i'd be surprised if i make it, yet again :/ 16:48:48 Hi, I'm Björn from Guix, I asked you on the list for sharing. 16:49:05 hi! 16:49:20 Alas I will not be able to firmly commit time & energy to a booth, but can probably help in the moment. (ie. soft support from me) 16:49:43 I won't be attending, but it's starting to look like sharing a booth is a good idea in terms of resources... 16:50:24 Im attending and would gladly spend a few hours in the booth if needed. Unsure how much i'd be able of helping getting things we need for a booth 16:51:01 i guess it comes down to how many people can attend and have spare time to commit to keeping the booth alive 16:51:38 would it be too soon to make a tentative calendar and have people fill in possible hours to spend on the booth? 16:52:11 i think the booth applications need to be done early november ... so not a lot of time, but still at least a week or so 16:52:11 The deadline for application is in November. I think the 5th? Or 2nd? 16:52:20 So there is not too much time to plan. 16:53:14 the thread discussing this seemed a little more alive on the guix side 16:53:57 yeah. I didn't participate because I'm not going, but it seems we don't have much people to run the booth alone 16:54:16 again, my 0.02 BTC 16:54:40 hah! 16:55:07 It looks like on Guix side we have quite some people, so we could try it alone. There would be at least some space for a RB-sign :-) 16:55:23 (fwiw, I'm out. I'm sorry I couldn't contribute anything to the meeting… ☹) 16:56:02 demotri: well I'd vote for that. I feel bad participating on this if I can't commit any time on it though 16:56:04 mapreri: o/! 16:56:19 there was also mention of sharing a booth with SFC (software freedom conservancy), but i get the rough impression that that might not be a good fit 16:58:43 so... it seems we don't have enough folks from R-B to commit a lot of energy to this 16:58:43 well I'd guess we could take it to the thread and vote on it or so 16:58:59 (vote on whether guix, alone or sfx) 16:59:51 given little discussion on list, i'm guessing it might not be there 16:59:58 next topic? 17:00:42 hmm, ok? 17:00:46 #topic weighted reproducibility statistics? 17:00:52 What's this? :) 17:01:18 * sangy is presenting 17:01:22 oh, great! 17:01:33 so david wheeler's email is an interestin topic about how we present the statistics 17:01:52 I think we could work a little in 1) using popularity metrics to present a weighted average of packages 17:02:03 e.g., the top 1000 packages are reproducible, or so 17:02:34 we could also show statistics on e.g., the core group is reproducible, and the metapackage x is all reproducible 17:02:43 we already have some categories, but this would be something more dynamic? 17:03:13 i think so. I'd think it's be good to have it in the statistics on the splash of tests.reproducible-builds.org 17:03:20 such as: https://tests.reproducible-builds.org/debian/buster/amd64/pkg_set_essential.html 17:04:02 ah yeah, something along those lines 17:04:26 what that thread made me wonder is whether users get a good notion of how reproducible their everyday package use is 17:04:52 i.e., from the unreproducible packages left, how many of them are popular enough to care? 17:05:01 that'd also probably help us triage and focus efforts 17:05:39 * sangy wonder if this is just rambling and that info is already out there he just couldn't find it 17:05:40 well, then there's the reality that almost none of them are; we have significant infrastructure to get to real-world reproducibility 17:06:35 i think there's something to be said for rethinking the presentation a little as a tool to focus on important targets 17:07:13 sangy: guess this would be easy for arch, since it should be core > extra > community 17:07:32 jelle: true, and we also have https://pkgstats.archlinux.de/package 17:07:49 yeah, but that's a bit of a weird stats mechanism 17:08:10 jelle: yeah I just loaded and I see a bunch of 100%'s hah. We still have something along those lines no? 17:08:14 What would be the goal of reorganising the statistics collection? Just for interests sake, or would it actually make us more effective in targetting key or core packages? The former seems more along the "luxury" scale. 17:08:51 lamby: I think it'd be both 17:09:19 also, rephrasing interests sake for "user's interests sake" 17:09:33 it also seems like the sort of project that could get involvement from someone with different skillsets 17:10:12 vagrantc: care to elaborate? 17:11:20 e.g. maybe they can't patch a C or python program, but they know how to take data from a database and turn it into useful or at least pretty graphical representations 17:11:33 I'm not doubting or undermining that having better or more accurate stats isn't a superior state of affairs, but it's more of an opportunity cost / prioritisation point of view. :) 17:11:51 lamby: agreed, I see how we're running low on manpower 17:12:09 I don't think it's a bad idea to have the "issue" open somewhere, so as to let people who want to contribute in that way be able to step in? 17:12:30 there's the contribution page ... could add an item there 17:13:29 would that be good for everyone? 17:13:50 certainly good by me, as I could also dump ideas on it :) 17:15:36 i can also specifically reply to dwheeler 17:15:42 if someone hasn't already 17:16:03 moving on and wrapping up? 17:16:04 I could also, depending on whether you have better info about those packages at hand 17:16:18 #topic reprobuilds at NYU 17:16:31 so this was just of a soft lead to later today and to wrap up quickly 17:16:47 I'll be doing the second session of r-b@nyu today, since we couldn't find anyone who could fly in today 17:17:09 lamby was super nice last week and did a ~3 hour presentation and workshop with them. I think they already found some issues and sent some patches around \o/ 17:17:34 I'll be helping them send more patches today, but I was wondering if there was any topic that the community here would like me to *not* forget to mention 17:18:20 happy to see the new contributors! 17:18:40 :) 17:19:04 sangy: hard to know what's missed from the presentation and workshop ... 17:19:28 I got embarrassed it was so hard to get them into the project admin-wise, so made the aforementioned "join salsa" page on the website. 17:19:29 * vagrantc imagines a presentation by lamby over 3 hours being pretty comprehensive 17:20:33 well yeah, it was rather comprehensive in terms of what are we trying to fix and how to fix it 17:21:03 I was wondering if we wanted to cover things such as the current stress test infra or such 17:21:09 or would that be too advanced and time consuming 17:21:52 either way! I have to run. If you have any comments please shoot ym a dm or so 17:22:04 sorry about it! I only allocated an hour and now i have another meeting >.< 17:22:08 sangy: thanks for getting that stuff! 17:22:13 03reproducible-notes 05master 0c1f201 06marinamoore (via 06Marina Moore) 10packages.yml * Tag efax with build_id_differences_only * 14https://deb.li/3Ztgn 17:22:15 sangy: er, getting those folks involved 17:22:22 sangy: "ym a dm" ? 17:22:35 alright... let's call that a meeting 17:22:40 lamby: "me a dm" 17:22:40 lamby: me a dm (or /q, or something) 17:22:40 #endmeeting