17:00:11 <number80> #startmeeting FESCO (2016-03-04)
17:00:11 <zodbot> Meeting started Fri Mar  4 17:00:11 2016 UTC.  The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:11 <zodbot> The meeting name has been set to 'fesco_(2016-03-04)'
17:00:16 <number80> #meetingname fesco
17:00:16 <zodbot> The meeting name has been set to 'fesco'
17:00:21 <nirik> morning
17:00:37 <sgallagh> .hello sgallagh
17:00:38 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:00:49 <number80> #chair maxamillion dgilmore number80 jwb nirik paragan jsmith kalev sgallagh
17:00:49 <zodbot> Current chairs: dgilmore jsmith jwb kalev maxamillion nirik number80 paragan sgallagh
17:00:55 <jwb> hi
17:01:00 <number80> Hello
17:01:02 <sgallagh> I may have to drop with limited notice: I'm waiting for a heating repair guy to show up
17:01:05 <kalev> hello!
17:01:07 <maxamillion> .hello maxamillion
17:01:08 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
17:01:31 <number80> Meeting items are here: https://fedorahosted.org/fesco/report/9
17:01:55 <jwb> sgallagh: maybe we should start with the firefox topic then?
17:01:56 <number80> we're 6 so we have quorum
17:02:42 <sgallagh> jwb: I sent an email, but if there are questions, sure
17:02:50 <number80> Let's start
17:03:15 <number80> #topic #1518 Software packaged in Fedora should not be allowed to implement DRM schemes that cannot be disabled
17:03:24 <number80> sgallagh: stage is yours
17:03:37 <number80> .fesco 1518
17:03:41 <zodbot> number80: #1518 (Software packaged in Fedora should not be allowed to implement DRM schemes that cannot be disabled) – FESCo - https://fedorahosted.org/fesco/ticket/1518
17:03:58 <sgallagh> tl;dr: Mozilla got back to us, they understand our concerns and are willing to figure out how to address them
17:04:02 <jwb> sgallagh: i suggested it because the email isn't public.  would be good to get a recap in the meeting logs.
17:04:35 <sgallagh> We don't have an official statement of the short-term plan right now, but I expect to get that within the next few business days.
17:05:05 <sgallagh> They want to have a phone or video-conference with several of us to have a high-bandwidth conversation about our concerns
17:05:13 <sgallagh> I'll be scheduling that for next week
17:05:22 <kalev> thanks sgallagh for driving this
17:05:28 <maxamillion> sgallagh: +1
17:05:31 <maxamillion> errr
17:05:33 <maxamillion> sgallagh++
17:05:33 <zodbot> maxamillion: Karma for sgallagh changed to 7 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:05:38 <sgallagh> The probable short-term solution is that they will let us carry a patch that disables signature checking for system-installed extensions
17:05:38 <number80> thank you
17:05:52 <sgallagh> (And assert that this has no trademark impact)
17:06:04 <number80> #info there's progress in our discussion w/ Mozilla about signed add-ons
17:06:24 <kalev> for what it's worth, I think the short term solution is also the preferred long term approach from our point of view
17:06:46 <number80> kalev: well, I'd prefer having an upstreamed solution
17:06:48 <dgilmore> hi
17:06:57 <kalev> number80: yeah, sure, a configure option would be best
17:07:40 <sgallagh> Right, the intended outcome here is to have an upstreamed solution that other distros can also rely upon
17:07:42 <dgilmore> kalev: it is
17:07:51 <kalev> I didn't want to say that a patch is the best option. I wanted to say that disabling signature checking for system wide extensions is probably best and easiest for Fedora side
17:08:02 <number80> gotcha
17:08:03 <dgilmore> kalev: because us signing our extentions is a lot of net new work
17:08:44 <number80> If nobody has anything else, let's move to the next topic, we'll have more news next week or after
17:09:04 <sgallagh> ack
17:09:05 <dgilmore> number80: lets move on
17:09:06 <number80> #topic #1552 Review of delayed Changes for F24
17:09:12 <number80> .fesco 1552
17:09:13 <zodbot> number80: #1552 (Review of delayed Changes for F24) – FESCo - https://fedorahosted.org/fesco/ticket/1552
17:09:29 <number80> we had some features that needs to be reviewed
17:09:33 <number80> jkurik is in PTO
17:09:53 <dgilmore> number80: we said two weeks for followup
17:09:56 <dgilmore> well 1 to 2
17:10:03 <dgilmore> so lets do it next week
17:10:11 <maxamillion> Layered Image Build System is mine, we're like 95% done ... everything is deployed with ansible, we need to do some tweaking to allowed_smc urls for new namespaced distgit and we also need to patch fedpkg to handle namespaces distgit and that's basically it ... from there it's just testing
17:10:16 <maxamillion> oh
17:10:18 <maxamillion> >.>
17:10:20 <nirik> tuesday is alpha freeze. coming up soon. ;)
17:10:21 <number80> dgilmore: I don't mind, but sharing status is good too
17:10:45 <maxamillion> I will update the tracker BZ for mine by the end of the day
17:10:52 <dgilmore> number80: okay, well for layered images, we are working out som quirks in stage koji right now
17:10:59 <number80> systemd split is still unfinished too according the ticket
17:11:04 <number80> ack
17:11:28 <sgallagh> I asked zbyszek to provide status in BZ, but that wasn't very long ago
17:11:31 <number80> #info delayed changes for F24 will be reviewed during the next FESCO meeting
17:11:35 <number80> sgallagh: he did
17:11:53 <number80> let's move on
17:11:58 <number80> #topic #1551 Linking GPRbuild statically
17:12:06 <number80> .fesco 1551
17:12:07 <zodbot> number80: #1551 (Linking GPRbuild statically) – FESCo - https://fedorahosted.org/fesco/ticket/1551
17:12:48 <number80> for the record, FPC granted GPRbuild bootstrapping exception
17:13:15 <dgilmore> its kinda eww. it can be handled by bootstraping each bump
17:13:41 <number80> dgilmore: yeah, moreover it's not that frequent
17:14:30 <Rombobeorn> Bootstrapping twice a year would be considerable manual work.
17:14:30 <sgallagh> How is this different from gcc's double-build?
17:15:20 <maxamillion> I'm not sure I see why bootstrappping the package is a lot of manual work, I assume I'm missing something
17:15:36 <maxamillion> once the macros are in the spec file, you just build with the flag and then again without ... at least in most scenarios
17:16:48 <dgilmore> maxamillion: it needs the soname for ada from the previous gcc
17:16:57 <dgilmore> which may pull in other libraries
17:17:02 <maxamillion> dgilmore: ohh ok
17:17:02 <maxamillion> hrm
17:17:17 <maxamillion> yeah, I see that in the ticket
17:17:18 <maxamillion> hrmm
17:18:00 <Rombobeorn> sgallagh, I'm not all that familiar with GCC's build system, but doesn't it have a "make bootstrap" or something that handles that? GPRbuild doesn't. But more to the point, GCC doesn't depend on some third-party shared library that regularly changes its soname.
17:18:17 <sgallagh> ok
17:19:39 <kalev> afk a few minutes, have to get on a train. I'm +1 to the exception, don't see any problems with it
17:19:56 <number80> unless someone has a better solution, I'm also +1
17:20:34 <number80> should we vote, or need more info?
17:21:11 <jwb> i'm +1
17:21:26 <nirik> yeah, there's no great answer here I fear. I guess I can hold my nose and be +1 to the exception...
17:21:32 <maxamillion> yeah, +1
17:21:43 <number80> dgilmore?
17:21:43 <sgallagh> Same +1
17:22:01 <dgilmore> +1 even though it is ugly
17:22:37 <number80> #agreed gprbuild is allowed to link statically (+1: 6, 0:0, -1:0)
17:22:48 <number80> next topic
17:22:49 <Rombobeorn> Thanks guys.
17:23:00 <number80> #topic #1554 python-llfuse package takeover
17:23:05 <number80> .fesco 1554
17:23:06 <zodbot> number80: #1554 (python-llfuse package takeover) – FESCo - https://fedorahosted.org/fesco/ticket/1554
17:23:31 <number80> we have already 5 +1
17:23:46 <number80> anyone disagree?
17:24:33 <nirik> just that package or all their packages?
17:25:16 <number80> nirik: I'd say all packages, as maci is cleary non-responsive
17:25:38 <number80> he doesn't have a lot => https://admin.fedoraproject.org/pkgdb/packager/maci/
17:25:47 <nirik> yeah
17:26:18 <dgilmore> seems like we went about non responsive maintainer in a backwards way yet again
17:26:34 <dgilmore> do we need to revise the policy to reflect what people do
17:26:57 <jwb> i don't follow
17:27:10 <number80> ?
17:27:37 * kalev is back
17:28:08 <nirik> I think the policy does need revising, but it's not likely to be a trival thing
17:28:18 <dgilmore> jwb: wel rather than saying foo is not responsive, people are saying i want to take over this package
17:28:25 <dgilmore> well even
17:28:37 <dgilmore> minor detail I guess
17:28:39 <jwb> imo, that's even better
17:28:55 <kalev> I'd rather say, foo is not responsive, so orphan all packages, not just one
17:28:59 <nirik> yeah, if it's foo is unresponsive, we may orphan their package and no one takes it over. ;)
17:29:05 <dgilmore> we then use it to orphan all the persons packages and do non responsive maintainer
17:29:06 <maxamillion> I'm +1 to the ticket
17:29:12 <kalev> because if they are not responsive then they can't take care of other packages either
17:29:16 <number80> ok, just to be sure
17:29:27 <number80> proposal A: orphan all maci packages
17:29:31 <nirik> +1
17:29:34 <dgilmore> +1
17:29:35 <number80> +1
17:29:36 <maxamillion> +1
17:29:40 <jwb> +!
17:29:42 <jwb> er, 1
17:29:54 <kalev> +1
17:29:56 <sgallagh> +1
17:30:07 <number80> ok
17:30:26 <jwb> i think all the recent filings of this kind just illustrate that we don't have a good way to detect non-responsive maintainers in general.  we only find out when someone actually cares about a particular package
17:30:39 <nirik> yep.
17:30:40 <number80> #agreed orphan all maci packages (+1:7, 0:0, -1:0)
17:30:45 <dgilmore> jwb: indeed
17:30:51 <number80> nirik: can you take care of that?
17:30:53 <nirik> but it's often not easy to figure out.
17:30:59 <nirik> number80: yep. can do.
17:31:04 <number80> thank you
17:31:24 <dgilmore> nirik: yeah, particulary if they are active with other packages, and interests have shifted
17:31:33 <jwb> nirik: right.  which is why if we're goign to change anything, maybe we should make it easier for people to just fix the things they're interested in fixing
17:31:36 <sgallagh> I suppose we could always implement a dead-man service
17:31:53 <nirik> sgallagh: it's been suggested before but shot down
17:32:00 <jwb> maybe we save the broader discussion for open floor.
17:32:04 <sgallagh> Like, once a year, send an email to their registered Fedora account and then orphan if they don't respond in a month?
17:32:06 <number80> *nods*
17:32:07 <sgallagh> Sorry
17:32:23 <number80> #topic #1557 Update Squid 3.4.13 to 3.5.10 in F22
17:32:28 <number80> .fesco 1557
17:32:30 <zodbot> number80: #1557 (Update Squid 3.4.13 to 3.5.10 in F22) – FESCo - https://fedorahosted.org/fesco/ticket/1557
17:32:57 <number80> proposal: allow squid update to 3.5.10 in F22
17:33:00 <maxamillion> +1
17:33:01 <number80> +1
17:33:02 <dgilmore> I am +1
17:33:03 <nirik> +1
17:33:03 <sgallagh> +1
17:33:07 <jwb> +1
17:33:09 <kalev> +1
17:33:30 <number80> #agreed allow squid update to 3.5.x in F22 (+1:7, 0:0, -1:0)
17:33:33 <number80> thank you :)
17:33:42 <number80> #topic #1555 Please clarify updates policy for security issues
17:33:48 <number80> .fesco 1555
17:33:49 <zodbot> number80: #1555 (Please clarify updates policy for security issues) – FESCo - https://fedorahosted.org/fesco/ticket/1555
17:34:00 <number80> long-winded topic but last one in the agenda
17:34:43 <number80> jwb has made a good summary of use case we should not grant exceptions
17:35:21 <jwb> i think all the data is already there, just not necessarily organized in the clearest fashion
17:35:22 <sgallagh> I'd also like to add to that: "an exception that causes ABI/API breakage will never be acceptable for security issues classified below Important"
17:35:34 <number80> I'm in favor of rewritting the policy to be clearer
17:35:34 <dgilmore> I say one point jwb made while good is broken all the time
17:35:36 <dgilmore> The update changes the UI the end user sees (moves menus or buttons around, changes option names on command line)
17:35:59 <dgilmore> KDE breaks that every major bump  4.2 to 4.3 etc
17:36:10 <jwb> KDE has their own update policy, as noted on that page
17:36:10 <sgallagh> dgilmore: Well, KDE has a special exemption in general
17:36:14 <nirik> related: are exceptions one time or forever?
17:36:25 <nirik> the policy isn't clear on that
17:36:32 <number80> sgallagh: fair enough
17:36:42 <jwb> nirik: probably one time unless they get an exemption notation like KDE
17:37:14 <sgallagh> I agree: it doesn't usually happen so often that it would be too heavy weight to bring it to us
17:37:28 <kalev> yep, I think so too
17:37:31 <nirik> well, I think it does happen, but people just do it and ignore us. ;)
17:37:44 <maxamillion> nirik: probably so
17:37:45 <dgilmore> nirik: indeed.
17:38:52 <nirik> anyhow, whats the action here? some folks want to re-write things? or ?
17:39:18 <Southern_Gentlem> skywave linux
17:39:47 <sgallagh> Southern_Gentlem: Sorry, what?
17:41:01 <maxamillion> anyhoo ...
17:41:09 * jsmith apologizes for being late -- his keynote at a conference went long
17:41:34 <number80> jsmith: want to rewrite our updates policy for security issue?
17:42:17 <jsmith> number80: I'm in favor of revising it, but don't want to do all the work myself :-p
17:42:27 * jsmith is still catching up on the scrollback
17:43:06 <number80> jsmith: well, there are good ideas and you have a good pen :)
17:43:25 <jsmith> Fine... I'll take a stab at it... why not?!?
17:43:30 <number80> excellent!
17:43:33 <number80> jsmith++
17:43:33 <zodbot> number80: Karma for jsmith changed to 15 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:43:53 <number80> #action jsmith will try to clarify updates policy for security issues
17:44:11 <number80> then, I suggest that we revisit it when we have a concrete proposal?
17:44:22 <nirik> yep
17:44:29 <jsmith> number80: Sounds great -- I'll try to have something in the next week or two :-)
17:44:46 <number80> jsmith: no pressure, it can wait one week or two
17:44:58 <number80> #topic Next week's chair
17:45:01 <maxamillion> jsmith++
17:45:02 <zodbot> maxamillion: Karma for jsmith changed to 16 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:45:04 <number80> who wants it?
17:45:24 <maxamillion> let me check my calendar and make sure I'll be here
17:45:35 * jsmith will take it if nobody else volunteers
17:45:43 <dgilmore> thanks jsmith
17:45:45 <dgilmore> :)
17:46:10 * jsmith is changing jobs soon, so *should* have more free time (at least in theory)
17:46:12 <maxamillion> I'll be here, I can do it
17:46:24 <maxamillion> it'll be my first run, be nice :)
17:46:29 <number80> #info maxamillion will chair fesco meeting next week
17:46:33 <jsmith> maxamillion: OK, great!
17:46:38 <maxamillion> w00t w00t
17:46:41 <number80> jsmith: you'll have plenty occasions to do so :)
17:46:53 <number80> #topic Next week's chair
17:47:00 * maxamillion is doing stuff and things
17:47:12 <number80> ok, we can continue the non-responsive maintainers discussion or another topic
17:47:28 <jwb> er
17:47:32 <number80> #undo
17:47:32 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x241657d0>
17:47:33 <jwb> #topic Open Floor
17:47:38 <number80> jwb: thanks
17:48:45 <jwb> i don't have anything concrete for the NRM discussion.  simply that our current policy and ACL implementation makes it very cumbersome for willing people to do work
17:49:01 <number80> Yes, and it's not always respected
17:49:27 <number80> anything else before I close the meeting?
17:50:45 * jsmith has nothing else
17:50:50 <number80> Thank you gentlemen, see you next week
17:51:11 <number80> #endmeeting