16:13:44 <vagrantc> #startmeeting
16:13:44 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:14:45 <vagrantc> #topic apologies
16:14:51 <vagrantc> h01ger might not be able to make it
16:14:58 <vagrantc> #intros
16:15:06 <vagrantc> #topic intro
16:15:12 <vagrantc> please introduce yourself!
16:15:13 * vagrantc waves
16:15:15 <vagrantc> hi
16:15:20 <lamby> hi o/
16:15:23 <vagrantc> just something short for the logs
16:15:23 <Foxboron> Yo!
16:15:31 <jelle> o/
16:15:39 <raboof> hi o/
16:16:22 <sangy> o/
16:16:36 <vagrantc> #topic cross distro notes
16:16:45 <vagrantc> 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 <dkg> hi hi (late)
16:17:00 <vagrantc> dkg: we all are :)
16:18:06 <vagrantc> so, anyone have thoughts on how we can more effectively share information about reproducibilities issues, patches, etc?
16:18:46 <vagrantc> this may specifically be about the "notes" git repository that debian uses, and making the format useful to other projects
16:19:41 <sangy> 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 <vagrantc> #link https://salsa.debian.org/reproducible-builds/reproducible-notes
16:20:09 <sangy> 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 <mapreri> 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 <vagrantc> #link https://salsa.debian.org/reproducible-builds/reproducible-notes/tree/multi-project-syntax
16:20:15 <jelle> 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 <sangy> oh, we could probably link that too
16:20:43 <sangy> #link  https://salsa.debian.org/reproducible-builds/reproducible-notes/blob/master/ideas_on_sharing_notes_between_distros
16:21:00 <jelle> 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 <jelle> 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 <vagrantc> we have historically removed things once they are fixed in debian
16:22:09 <sangy> I wonder if we want to change that
16:22:12 <vagrantc> right
16:22:19 <vagrantc> or have some sort of archival process
16:22:32 <sangy> vagrantc: we could just "move" them to a different file
16:22:52 <vagrantc> 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 <sangy> so I'm looking at the schema, it has state: fixed and comment:
16:23:20 <sangy> wouldn't that be enough?
16:23:43 <vagrantc> sure
16:23:49 <jelle> sounds good
16:24:00 <vagrantc> or maybe even "fixed-version" ?
16:24:20 <vagrantc> so that we don't have to extract verison information out of a comments field...
16:24:33 <sangy> I think we could also formalize what the fields mean exactly
16:24:40 <jelle> link to fix would also be nice (git commit if possible)
16:24:42 <sangy> url could be an upstream url of the bugreport or something
16:25:01 <sangy> jelle: that could be a separate field or part of comment:. I'd be fine with either
16:26:13 <vagrantc> the other main thing is actually getting people to use it ... and maybe that would lead to some refinements
16:26:27 <sangy> 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 <sangy> I believe issues may belong to many packages? (e.g., splitpkg's in Arch)
16:27:31 <jelle> package names will always differ per distro :)
16:27:36 <vagrantc> there are extensive issues, and given packages are essentially tagged with the relevent issues
16:27:57 <vagrantc> #link https://salsa.debian.org/reproducible-builds/reproducible-notes/blob/master/issues.yml
16:28:31 <vagrantc> jelle: indeed...
16:28:59 <sangy> jelle: that's why id's could probably help
16:29:41 <vagrantc> use the upstream name, and have a field for distro-specific names?
16:29:50 <jelle> sangy: but I believe that shouldn't be an issue if we use the upstream name
16:29:50 <vagrantc> although even that is maybe sometimes non-obvious
16:30:15 <jelle> 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 <sangy> it's not the mexican docker guys, it's just your usual whale-themed container system
16:31:16 <vagrantc> sangy: are you saying to use IDs unrelated to the name?
16:31:40 <sangy> vagrantc: I'm saying using the upstream name as an id, and have a reference to the distro-specific name
16:31:45 <sangy> and having an issue number for each issue
16:33:20 <vagrantc> sangy: unrelated to issues.yml ?
16:33:41 <sangy> no, i.e., add a field with issue_number: xx
16:33:49 <sangy> here: https://salsa.debian.org/reproducible-builds/reproducible-notes/blob/master/ideas_on_sharing_notes_between_distros#L34
16:34:46 <lamby> 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 <lamby> There is no need to nail the specification the first time around, after all.
16:35:02 <lamby> (if ever.)
16:35:35 * sangy grumbles academically
16:35:54 <sangy> fair enough. what'd be a good action point for this topic?
16:36:31 <vagrantc> seems like converting all the existing debian-specific files to the generic format, and then fill in other distro-specific things?
16:36:53 <vagrantc> that would probably require some re-tooling for tests.r-b.org/debian
16:38:37 <sangy> hmm, yeha that sounds a little painful
16:39:08 <vagrantc> maybe something to tackle at the summit?
16:39:26 <vagrantc> which might be a useful segway...
16:40:15 <vagrantc> someone want to bring this up on the list and try and get some discussion going?
16:41:17 <sangy> +1 to both ideas
16:41:45 <vagrantc> alright, i'm inclined to keep the agenda moving :)
16:41:48 <vagrantc> #topic summit
16:42:04 <vagrantc> paris, december 11th-13th, very exciting!
16:42:30 <sangy> 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 <lamby> https://www.opensourcesummit.paris/ is the previous week, in case people wish to make "more" of the trip.
16:43:11 <lamby> #link https://www.opensourcesummit.paris/
16:45:12 <sangy> ... is there more to say about this topic?
16:45:28 <sangy> 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 <sangy> +1 to that too. I really like your ideas vagrantc :P
16:46:39 <vagrantc> ok, next...
16:46:46 <vagrantc> #topic fosdem booth
16:47:16 <vagrantc> fosdem is coming up, does reproducible-builds want to share a booth with someone?
16:48:12 <jelle> I'll be attending fosdem, but probably busy with other things
16:48:31 <vagrantc> i'd be surprised if i make it, yet again :/
16:48:48 <demotri> Hi, I'm Björn from Guix, I asked you on the list for sharing.
16:49:05 <vagrantc> hi!
16:49:20 <lamby> 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 <sangy> 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 <Foxboron> 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 <vagrantc> 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 <sangy> 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 <vagrantc> 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 <demotri> The deadline for application is in November. I think the 5th? Or 2nd?
16:52:20 <demotri> So there is not too much time to plan.
16:53:14 <vagrantc> the thread discussing this seemed a little more alive on the guix side
16:53:57 <sangy> 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 <sangy> again, my 0.02 BTC
16:54:40 <vagrantc> hah!
16:55:07 <demotri> 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 <mapreri> (fwiw, I'm out.  I'm sorry I couldn't contribute anything to the meeting… ☹)
16:56:02 <sangy> 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 <sangy> mapreri: o/!
16:56:19 <vagrantc> 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 <vagrantc> so... it seems we don't have enough folks from R-B to commit a lot of energy to this
16:58:43 <sangy> well I'd guess we could take it to the thread and vote on it or so
16:58:59 <sangy> (vote on whether guix, alone or sfx)
16:59:51 <vagrantc> given little discussion on list, i'm guessing it might not be there
16:59:58 <vagrantc> next topic?
17:00:42 <sangy> hmm, ok?
17:00:46 <vagrantc> #topic weighted reproducibility statistics?
17:00:52 <lamby> What's this? :)
17:01:18 * sangy is presenting
17:01:22 <vagrantc> oh, great!
17:01:33 <sangy> so david wheeler's email is an interestin topic about how we present the statistics
17:01:52 <sangy> I think we could work a little in 1) using popularity metrics to present a weighted average of packages
17:02:03 <sangy> e.g., the top 1000 packages are reproducible, or so
17:02:34 <sangy> we could also show statistics on e.g., the core group is reproducible, and the metapackage x is all reproducible
17:02:43 <vagrantc> we already have some categories, but this would be something more dynamic?
17:03:13 <sangy> 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 <vagrantc> such as: https://tests.reproducible-builds.org/debian/buster/amd64/pkg_set_essential.html
17:04:02 <sangy> ah yeah, something along those lines
17:04:26 <sangy> what that thread made me wonder is whether users get a good notion of how reproducible their everyday package use is
17:04:52 <sangy> i.e., from the unreproducible packages left, how many of them are popular enough to care?
17:05:01 <sangy> 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 <vagrantc> 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 <vagrantc> 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 <jelle> sangy: guess this would be easy for arch, since it should be core > extra > community
17:07:32 <sangy> jelle: true, and we also have https://pkgstats.archlinux.de/package
17:07:49 <jelle> yeah, but that's a bit of a weird stats mechanism
17:08:10 <sangy> 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 <lamby> 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 <sangy> lamby: I think it'd be both
17:09:19 <sangy> also, rephrasing interests sake for "user's interests sake"
17:09:33 <vagrantc> it also seems like the sort of project that could get involvement from someone with different skillsets
17:10:12 <sangy> vagrantc: care to elaborate?
17:11:20 <vagrantc> 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 <lamby> 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 <sangy> lamby: agreed, I see how we're running low on manpower
17:12:09 <sangy> 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 <vagrantc> there's the contribution page ... could add an item there
17:13:29 <sangy> would that be good for everyone?
17:13:50 <sangy> certainly good by me, as I could also dump ideas on it :)
17:15:36 <vagrantc> i can also specifically reply to dwheeler
17:15:42 <vagrantc> if someone hasn't already
17:16:03 <vagrantc> moving on and wrapping up?
17:16:04 <sangy> I could also, depending on whether you have better info about those packages at hand
17:16:18 <vagrantc> #topic reprobuilds at NYU
17:16:31 <sangy> so this was just of a soft lead to later today and to wrap up quickly
17:16:47 <sangy> 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 <sangy> 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 <sangy> 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 <vagrantc> happy to see the new contributors!
17:18:40 <sangy> :)
17:19:04 <vagrantc> sangy: hard to know what's missed from the presentation and workshop ...
17:19:28 <lamby> 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 <sangy> well yeah, it was rather comprehensive in terms of what are we trying to fix and how to fix it
17:21:03 <sangy> I was wondering if we wanted to cover things such as the current stress test infra or such
17:21:09 <sangy> or would that be too advanced and time consuming
17:21:52 <sangy> either way! I have to run. If you have any comments please shoot ym a dm or so
17:22:04 <sangy> sorry about it! I only allocated an hour and now i have another meeting >.<
17:22:08 <vagrantc> sangy: thanks for getting that stuff!
17:22:13 <KGB-0> 03reproducible-notes 05master 0c1f201 06marinamoore (via 06Marina Moore) 10packages.yml * Tag efax with build_id_differences_only * 14https://deb.li/3Ztgn
17:22:15 <vagrantc> sangy: er, getting those folks involved
17:22:22 <lamby> sangy: "ym a dm" ?
17:22:35 <vagrantc> alright... let's call that a meeting
17:22:40 <Foxboron> lamby: "me a dm"
17:22:40 <sangy> lamby: me a dm (or /q, or something)
17:22:40 <vagrantc> #endmeeting