16:59:31 <lamby> #startmeeting
16:59:31 <MeetBot> Meeting started Thu Jul  6 16:59:31 2017 UTC.  The chair is lamby. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:31 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:59:34 <lamby> Welcome all!
16:59:41 <lamby> #info Agenda at https://pad.riseup.net/p/reproducible-irc-meeting-10
17:00:06 <mapreri> o/
17:00:06 <lamby> How is everyone?
17:00:13 <vagrantc> good morning
17:00:19 <siamezzze> Hi!
17:00:30 <brett> Hi all.
17:00:35 <lamby> vagrantc: 10am, right?
17:00:45 <cbehling[m]> Hello
17:00:47 <lamby> Hey mapreri, brett, siamezzze :)
17:00:53 <lamby> oh hello cbehling[m]
17:00:54 <vagrantc> lamby: you know your timezones!
17:00:55 <sangy> Hello everyone
17:01:09 <lamby> vagrantc: Oh, I can append /$yourlocation to an URL.
17:01:33 <lamby> https://time.is/compare/1700_6_July_2017_UTC/Malawi
17:01:52 <lamby> hey sangy
17:02:10 <lamby> We'll give it a couple of minutes and then we'll jump into it
17:04:09 <dkg> ahoy ahoy
17:04:18 <lamby> Always worth waiting for dkg
17:04:29 <lamby> Fashionably fashionable.
17:04:43 <emaste> hi
17:04:48 <mapreri> wasn't dkg that always felt groovy at a meeting start? :)
17:05:06 <lamby> Righto.
17:05:14 <Faux> I'm here for questions but won't be keeping up.
17:05:14 <lamby> #topic Apologies
17:05:35 <lamby> No apologies "officially" received on the pad but h'01ger mentioned he was likely to be away
17:05:46 <lamby> … which may affect a few of the other items, we'll see.
17:06:00 <lamby> hey Faux
17:06:01 <lamby> #topic Introductions
17:06:09 <lamby> So, anybody new? Or anyone's first IRC meeting?
17:06:17 <lamby> If so, please say "hi."
17:06:42 <cbehling[m]> I sort of lurked the last one but didn't participate.
17:06:55 <cbehling[m]> Hi
17:06:58 <lamby> Hi :)
17:06:58 <mapreri> I replied last week to a prospect winter Outreachy student, and invited her here, no idea if she came.  Would love if you speak up :)
17:07:04 <mapreri> cbehling[m]: \o
17:07:18 <lamby> cbehling[m]: What's your background/project/interest? Or just general?
17:07:51 <cbehling[m]> I work with Eric on repeatr. Those of you at the Hamburg hackathon may have met me.
17:08:01 <lamby> :)
17:08:12 <lamby> Neat.
17:08:20 <lamby> #topic Reproducible Builds Summit update
17:08:31 <lamby> Somehow this is assigned to me!
17:08:50 <lamby> I don't have any update on the dates, however if you have not already replied to the survey/poll please do so ASAP.
17:09:03 <sangy> lamby: can you link the poll ?
17:09:26 <lamby> SUre
17:09:36 <lamby> #info Date poll is http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20170612/008807.html
17:10:24 <sangy> thanks
17:10:24 <lamby> Naturally as soon as we have one of them confirmed we'll let you know so you can at least reserve yourself, book flights etc.
17:10:34 <lamby> I assume nobody has any updates here?
17:10:56 <lamby> nod
17:10:59 <lamby> #topic Agreement on https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20170626/008897.html
17:11:18 <lamby> There is no owner here, but it links to a post from mapreri; care to take this?
17:11:22 <mapreri> sure
17:11:46 <mapreri> short: do anybody oppose rm -r old-packages/ + rm instead of mv?
17:12:03 <mapreri> otherwise, I'll go ahead after the meeting.
17:12:24 <bmwiedemann> just out of interest: how old is 'old' usually?
17:13:53 <mapreri> old here is packages that have 2 new versions already, or don't belong in our custom repo anymore
17:13:57 <mapreri> roughly.
17:14:18 <mapreri> you can see the mtims in https://reproducible.alioth.debian.org/old-packages/
17:14:33 <lamby> Even 1 version almost seems excessive if we mostly reject the "being able to reproduce old builds" idea.
17:14:40 <lamby> But personally I'm easy.
17:15:02 <mapreri> the 2 versions is just to avoid not-yet-updated chroots to fail if they try to pull an older version.
17:15:17 <lamby> #action mapreri rm -r old-packages/ + rm (instead of mv)
17:15:18 <lamby> nod
17:15:32 <mapreri> just easier to delete them at the second update than to chase the updater jobs
17:15:36 <lamby> :)
17:15:37 <lamby> Thanks!
17:15:41 <lamby> #info NMU campaign for buster
17:16:05 <mapreri> h01ger: do you want to take this?
17:16:14 <mapreri> (I noticed that you just appeared)
17:17:02 <bmwiedemann> NMU = non maintainer uploads?
17:17:06 <mapreri> yes.
17:17:42 <lamby> mapreri: Perhaps you can run with this for now?
17:17:45 <mapreri> ok
17:17:47 <vagrantc> pretty debian-specific issue
17:17:49 <mapreri> So, I've been meaning (and I still mean) to start a mass NMU for our patches already filed.  Considering we have filed them ages ago it means we could theoretically just start and go ahead, but before doing so I would like to 1) write a d-d-a email with bits for r-b 2) write another d-d email proposing to rise severity of our bugs to minor or normal (to decide) 3) start the NMU campaign if nobody from d-d starts yelling.
17:18:02 <mapreri> comments?
17:18:30 <lamby> I worry that people will block without a Policy change.
17:18:47 <mapreri> srly :S
17:18:48 <bmwiedemann> I have sometimes found small bugs in r-b patches so maybe have someone review/test them ?
17:18:49 <lamby> But that then means the chain is  Policy change → raise severity → NMU… which takes ages.
17:19:22 <bmwiedemann> also, upstreaming could help
17:19:25 <lamby> Sorry, policy change → d-d mail.
17:19:35 <mapreri> I find such opposition kind stupid from people who don't understand how policy work, as it's suppoesd to document current practise.
17:19:49 <mapreri> lamby: is that a correction or what?
17:20:15 <lamby> A correction. Policy change → debian-devel consensus → raise severities → NMUs can begin.
17:20:32 <vagrantc> #link https://bugs.debian.org/844431
17:20:33 <lamby> (Just to be clear, I'm saying that sucks as a timeline)
17:20:41 <mapreri> I do not think a policy change is needed here, really.
17:20:59 * vagrantc agrees with mapreri
17:21:16 <vagrantc> bmwiedemann: we do generally push things upstream, but some of these are packaging-specific bugs
17:21:32 <lamby> I agree, I'm just putting the other side to cover our bases
17:21:41 <vagrantc> bmwiedemann: it's also sometimes easier to convince upstream if it's be in-use in the wild (e.g. Debian) without reported issues
17:21:50 <lamby> Cool, well assuming that general consensus on -devel matches that, that leaves debian-devel consensus → raise severities → NMUs.
17:22:08 <lamby> I'm assuming we shouldn't NMU *wishlist* bugs, so that keeps that blocker?
17:22:19 <lamby> I mean, just politically/socially speaking.
17:22:54 <mapreri> according to devref, everything can be NMUed, but yes, NMUs for wishlist is still kind of not socially nice for somebody
17:22:54 <lamby> (Besides, the bump in severity is likely to encourage maintainers to act by themselves, saving us some work!)
17:23:26 <mapreri> can we start off point 1 (dda report email, been a while since the last one) and 2 (dd email) now?
17:23:27 <lamby> nodnod. We should keep our (somehow) good social standing as a Well-Behaved Team :3
17:23:40 <mapreri> I could prepare some drafts
17:23:42 <lamby> Sure
17:23:49 * vagrantc will happily review drafts
17:23:52 <mapreri> another thing that could be done: team uplods
17:24:21 <lamby> They don't block each other? I mean, d-d-a mail is just a general update… it almost seems not directly relevant to an NMU campaign
17:24:23 <Eric[m]> (Belated o/)
17:24:27 <vagrantc> mapreri: isn't that still basically an NMU?
17:24:28 <lamby> (hey Eric[m])
17:24:40 <lamby> vagrantc: Not if you join the team :3
17:24:43 <mapreri> I am in a miriad of teams and I can probably "team upload" half of the archive, people in a position like mine could work within teams to get it quicker
17:24:49 <vagrantc> ah.
17:25:02 <mapreri> vagrantc: not really.  in several teams people are quite free to do whatever they want with all packages
17:25:06 <lamby> #action mapreri to draft dda report email
17:25:16 <mapreri> or there are quicker rules than NMUs, anyway
17:25:32 <lamby> #action mapreri to draft "debian-devel consensus mail" re raising severity of patches prior to NMU campaign
17:25:37 <lamby> Sound good?
17:25:47 <mapreri> lamby: they are not blocker, but easier to say in the dd email "we have come this far as reported in this dda email, so we would like to…..) :)
17:26:02 <mapreri> yes, wfm!
17:26:04 <lamby> awesome
17:26:18 <mapreri> "love it!"
17:26:20 <lamby> #topic Press release: Debian is doing Reproducible Builds for Buster
17:26:39 <lamby> Another from h01ger, I'll just leave that ping here for 30 seconds and move on if not.
17:27:05 <bmwiedemann> so that means 100% reproducible in 2 years ?
17:27:18 <mapreri> also, question: are we?  if we the NMU campaign above doesn't fly it's still not likely..
17:27:33 <vagrantc> mapreri: we seem to be on the same page today. :)
17:27:42 <lamby> bmwiedemann: Well, that would be the *goal*
17:28:17 <lamby> mapreri: Well, that's one way of pushing the NMU campaign through! But, yes.
17:28:20 <mapreri> bmwiedemann: but if we leave out the huge ones I say we can still call buster 99.9% reproducible :)
17:28:30 <vagrantc> obviously, we'd achieve reproducibility before the release, so less than 2 years. :)
17:29:16 <bmwiedemann> sounds feasible.
17:31:08 <vagrantc> seems like also really targeting the essential/required sets would be a key milestone
17:31:26 <vagrantc> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844431
17:31:28 <vagrantc> oops
17:31:36 <mapreri> vagrantc: infinity0 wanted to NMU them these days
17:31:38 <lamby> That's a good idea. infinity0 NMUd some of those recently (see most r… yeah
17:31:45 <vagrantc> https://tests.reproducible-builds.org/debian/unstable/amd64/pkg_set_required.html
17:31:47 <lamby> see most recent blog post
17:31:51 <mapreri> https://ftp-master.debian.org/deferred.html
17:31:53 <lamby> #info https://tests.reproducible-builds.org/debian/unstable/amd64/pkg_set_required.html
17:31:54 <mapreri> they are already in the queue
17:31:58 <vagrantc> and build-essential...
17:32:38 <lamby> Cool, let's leave that for now, conscious of time.
17:32:41 <lamby> #info Reproducible Builds Branding & Logo
17:32:54 <lamby> Any updates from folks? Otherwise will timeout in 30s.
17:33:11 <infinity0> i uploaded a bunch, they are due on jul 12
17:33:23 <infinity0> after that, gcc will be the only non-reproducible required package
17:33:26 <infinity0> gcc-5,6,7
17:34:51 <mapreri> infinity0: to figure, have you started tackling some unreproducible issue in gcc already too?
17:35:03 <infinity0> no
17:35:10 * emaste curious about gcc nonreproducibility, would like to find out more details after the meeting ends
17:35:21 <lamby> :
17:35:21 <lamby> :)
17:35:28 <lamby> #topic Reproducible Builds Branding & Logo
17:35:33 <lamby> (should have been #topic, not #info)
17:35:46 <lamby> #topic Should we become an SPI member?
17:35:51 <mapreri> lamby: jfyi, there is #undo too :)
17:35:55 <lamby> oh neat
17:36:01 <lamby> Anyone have any thoughts on this? (another timeout)
17:36:36 <vagrantc> i do think making it it's own project would be a good thing
17:36:55 <vagrantc> e.g. at the reproducible-builds q & a session, the impression still is that it's "just a debian thing"
17:37:15 <emaste> which 'it' ?
17:37:22 <vagrantc> reproducible-builds
17:37:27 <emaste> (making it it's own project)
17:37:33 <vagrantc> reproducible-builds
17:37:54 <bmwiedemann> I think, that perception is shrinking as more projects are picking up the concept
17:38:03 <lamby> I fear that might persist even if we were under SPI given the skew/background of developers, but bmwiedemann is right that it is changing.
17:38:25 <vagrantc> true, and we might want to be able to accept donations as "reproducible-builds" rather than as a sub-project of some other project
17:38:26 <emaste> as a non-Debian-folk, I think r-b is sufficiently non-Debian, officially
17:38:28 <lamby> We could do a bunch of stuff without any SPI stuff by, for example, moving entirely off 'debian' domains.
17:38:38 <sangy> emaste: why do you think this is?
17:38:55 <sangy> I think there is very little to do about it, other  than maybe making the toolchain more debian-agnostic
17:39:03 <vagrantc> lamby: and then what funds those domains?
17:39:22 <vagrantc> who pays for reproducible-builds.org now, that is?
17:39:27 <emaste> much of the effort is contributed by Debian folk, so it's unsurprising to have a strong Debian flavour, but I don't think that is a problem
17:40:02 <Eric[m]> +1 to both emaste and vagrantc
17:40:02 <emaste> the domain is reproducible-builds.org, the summit is the reproducible builds summit not a part of a DebConf, etc.
17:40:05 <lamby> vagrantc: Is that a real blocker? Domains are so cheap…
17:40:07 <vagrantc> i guess i didn't want to derail the conversation with that point; it was merely one point suggesting more autonomy from Debian would help with the perception
17:40:13 <infinity0> what are the concrete benefits of being an SPI member apart from "perception"
17:40:56 <vagrantc> being able to take donations as a 501(c)3 non-profit charitable organization
17:40:57 <sangy> maybe obvious, but isn't debian part of SPI anyway?
17:40:59 <bmwiedemann> infinity0: having an entity to own + pay the domain
17:41:08 <vagrantc> sangy: yes, still
17:42:18 <emaste> vagrantc: I see, and on the topic of a logo I think it could help with perception as well - my point is just that I agree making r-b seem more os-agnostic is good, but it's not really a problem per se
17:42:32 <vagrantc> emaste: sure. :)
17:43:07 <emaste> I think h01ger just paid the domain out of pocket perhasp?
17:43:47 <lamby> I like SPI but if the only advantage is a free domain, it seems like a bit of hassle. I mean, I'll just pay the domain…
17:43:59 <lamby> :p
17:44:12 <sangy> lol I can chip-in :P
17:44:15 <emaste> I'll split it with you :-)
17:44:17 <vagrantc> from the agenda: "main benefit: we'd become an entity that can raise money"
17:44:27 <mapreri> let's split a 8€ domain among 16 of us!
17:44:40 <infinity0> do we have even a semi-concrete thing to spend money on?
17:44:46 <lamby> I don't believe so.
17:44:51 <bmwiedemann> r-b meetups
17:45:03 <infinity0> LF pays for those at the moment :)
17:45:07 <vagrantc> partially
17:45:14 <lamby> Yeah, we can get funds from $misc when needed rather than rely/need donations.
17:45:30 <vagrantc> or specific solicitations
17:45:36 <emaste> it's a lot of effort to continually raise money
17:45:46 <lamby> Mmm.
17:45:53 <mapreri> also, it's not like even if you have the ability to raise money as an organization you will rise money
17:46:01 <mapreri> yes, what emaste said
17:46:07 <lamby> But… the magic money tree.
17:46:17 <lamby> Shall we table this for a bit?
17:46:22 <vagrantc> it's hard to raise any money if you can't clearly say where the money will go
17:46:31 <infinity0> i think let's leave it for now until someone has a concrete finance plan with both inputs and outputs semi-specified
17:46:33 <sangy> making builds reproducible, of course :P
17:46:37 <vagrantc> sure
17:46:38 <emaste> +1
17:46:41 <lamby> Cool
17:46:43 <lamby> #topic Next meeting
17:46:55 <lamby> I'll send around the next meeting detail with the minutes/logs as usual
17:47:07 <lamby> #topic Any Other Business?
17:47:08 <bmwiedemann> Thu 2017-08-04 ?
17:47:22 <vagrantc> fwiw, that's during Debconf
17:47:22 <bmwiedemann> err Thu 2017-08-03 ?
17:47:33 <emaste> also during BSDCam
17:47:53 <mapreri> ..."bsdcam" has a weird sound.... :>
17:47:56 <bmwiedemann> and during summer vacation time
17:48:01 <infinity0> perhaps we should kick off some discussion about the dak-aptitude workflow at some point? i think that was one major piece of work that nobody has started upon right?
17:48:23 <mapreri> yes
17:48:26 <mapreri> dak, mostly
17:48:29 <infinity0> and perhaps try to refactor the jenkins code so that other organisations can run it on their own infrastructure?
17:48:37 <infinity0> after all we are supposed to have third parties rebuild stuff
17:48:37 <emaste> mapreri: we had BSDCon, then BSDCan in Ottawa, and now BSDCam in Cambridge
17:48:55 <vagrantc> testing and documenting jenkins was a major todo item i haven't managed to follow-up on...
17:49:12 <mapreri> infinity0: ftpmasters don't reply to mails, so I believe somebody at debconf should chase down one into an allay and have him tell us what they want.
17:49:31 <infinity0> are most people working on "reproducing packages" atm, or are there other infrastructure-type stuff that people are doing?
17:49:57 <sangy> infinity0: speaking of which, I'm refactoring reprotest to strip out the dpkg-specific stuff. Is it worth, or is this tool not going to be part of the "official" toolchain
17:50:02 <bmwiedemann> infinity0: I'm planning to code an automated checker for openSUSE package update submissions
17:50:20 <vagrantc> sangy: that sounds really valuable
17:50:44 <infinity0> sangy: cool, yes reprotest would definitely be a supported tool and that contribute would be really welcome
17:50:49 <lamby> sangy: awesome
17:51:05 <vagrantc> asheesh once proposed an upload queue like the delayed queue that runs reproducible tests and then uploads if everything was good
17:51:31 <infinity0> not sure if it we would plan for it to be run on a rebuilding service, but it's a possibility. we'd have to design that, drawing in experience from the different rebuilders that we already have
17:51:54 <vagrantc> to make it simple for individual developers to opt-in to doing reproducible builds without having to change their workflow much
17:52:12 <infinity0> bmwiedemann: cool, that would be similar to jenkins but running koji, or something else?
17:52:25 <sangy> infinity0: awesome I'll probably continue the discussion outside of this meeting with some questions :)
17:53:06 <bmwiedemann> infinity0: it would interact with our Open Build Service (OBS), but be an independently deployed tool, checking for updates, testing r-b and reporting results back
17:53:12 * emaste glad "don't reply to emails" seems to apply to many projects
17:53:17 <infinity0> sangy: yeah definitely poke me if you want me to merge stuff or tweak things so you can extend it more easily :)
17:53:56 <infinity0> i wonder if it's worth trying to create a generic "rebuilder service daemon" that can rebuild debian packages, fedora packages, etc etc all at once
17:54:33 <vagrantc> would be nice if it ran builds in parallel by design
17:54:41 <bmwiedemann> infinity0: OBS have a generic builder service for all those. I wonder how easy it would be to add the re-build part.
17:54:59 <mapreri> emaste: #763822 has been open for years, with several contributions, questions and stuff from several people, but 0 replies from the most important party (if you are curious)
17:55:14 <mapreri> that said, I believe we are wandering off the path of the "AOB" topic
17:55:19 <mapreri> Shall we wrap up?
17:55:26 <infinity0> sure
17:55:28 <lamby> :)
17:55:38 <lamby> Thanks all o/
17:55:38 <infinity0> i think they just want someone to code it, since it would be a non-trivial component
17:55:53 <lamby> We already archive them JFTR
17:56:00 <lamby> #endmeeting