fesco
LOGS
18:02:12 <nirik> #startmeeting FESCO (2015-01-28)
18:02:12 <nirik> #meetingname fesco
18:02:12 <nirik> #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza
18:02:12 <nirik> #topic init process
18:02:12 <zodbot> Meeting started Wed Jan 28 18:02:12 2015 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:02:12 <zodbot> The meeting name has been set to 'fesco'
18:02:12 <zodbot> Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh stickster t8m thozza
18:02:20 <mitr> Hello
18:02:25 <kalev> hello
18:02:43 <jwb> hi
18:03:14 <mattdm> half here -- leaving for the airport soon for fosdem
18:03:24 <dgilmore> hola
18:04:06 <t8m> hi all
18:04:06 <sgallagh> .hello sgallagh
18:04:07 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
18:04:20 <nirik> cool. We have a long agenda today so I guess we should get started.
18:04:30 <nirik> is there anything in particular folks would like to do first?
18:04:37 <nirik> or shall I just go via the agenda order?
18:04:53 <t8m> as for me - just go ahead
18:05:02 <sgallagh> Full speed ahead
18:05:16 <nirik> alrighty
18:05:23 <nirik> #topic ticket #1326 change to fesco replacement process?
18:05:23 <nirik> https://fedorahosted.org/fesco/ticket/1326
18:05:24 <nirik> .fesco 1326
18:05:26 <zodbot> nirik: #1326 (change to fesco replacement process?) – FESCo - https://fedorahosted.org/fesco/ticket/1326
18:05:35 <nirik> we tabled this to discuss more in ticket.
18:05:39 <nirik> which we... didn't do.
18:05:47 <nirik> so, punt further down the road?
18:05:54 <mitr> Yes
18:05:58 <jwb> like after the Change deadline
18:06:11 <t8m> +1 to punt
18:06:21 <sgallagh> jwb: We're past the Change Submission Deadline already
18:06:26 <kalev> +1 to punt
18:06:32 <jwb> sgallagh, but we're not done reviewing them
18:06:36 <sgallagh> But yeah, let's punt it
18:06:41 <jwb> until we are, i don't see this being discussed
18:06:52 <nirik> sure. Next meeting is new fesco? or the one after that?
18:07:08 <nirik> #info will table this for now and discuss more as time permits.
18:07:18 <sgallagh> /me wonders when the magazine interviews will be up
18:07:21 <nirik> #topic ticket #1392 Review scope of "Python 3 as default" Change for F22
18:07:22 <nirik> https://fedorahosted.org/fesco/ticket/1392
18:07:22 <nirik> .fesco 1392
18:07:25 <zodbot> nirik: #1392 (Review scope of "Python 3 as default" Change for F22) – FESCo - https://fedorahosted.org/fesco/ticket/1392
18:07:59 <nirik> adamw: did your concerns get answered here?
18:08:09 <nirik> or do we still need to determine the real scope?
18:09:19 <nirik> so, it reads to me like f23 might be a better cycle for this.
18:09:34 <t8m> nirik, I think that as well
18:09:39 <sgallagh> This Change is kind of the new system units change. It could be years before everything moves.
18:09:41 <nirik> there's also a proposal just posted to the mailing list about mass filing bugs for python apps to switch to python3
18:09:57 <kalev> we already ship both Python 2 and Python 3 on the install media, so it's kind of incremental process converting indivial apps
18:10:05 <t8m> kalev, +1
18:10:07 <sgallagh> nirik: I'm in favor of the mass-filing.
18:10:15 <kalev> I guess it comes down to when we want to _advertise_ that we're using python 3 by default
18:10:21 <sgallagh> If nothing else, it will help keep track of how far along we are
18:10:43 <nirik> sgallagh: I'm ok with it, but perhaps after branch and targeting rawhide.
18:10:51 <kalev> we are already using it in some capacity, but not _everything_ is using it -- maybe it would make sense to advertise the python 3 porting when everything is done in the default install?
18:11:10 <jwb> kalev, agreed
18:11:15 <mitr> nirik: The Change (as its title says) is targeting F22
18:11:33 <sgallagh> kalev: Either that, or at least require the default install to call to python2 explicitly and make /usr/bin/python -> /usr/bin/python3
18:11:34 <adamw> nirik: sorry, just caught the ping, let me catch up
18:11:34 <dgilmore> not that it is a blocker for the release or feature, but none of the compose tools have been looked at porting yet
18:11:35 <nirik> mitr: yeah, I am wondering if it shouldn't retarget for f23.
18:11:39 <sgallagh> That effectively makes it "default"
18:11:52 <nirik> sgallagh: we shouldn't do that ever, imho. ;)
18:12:12 <dgilmore> sgallagh: afaik upstream recommends that /usr/bin/python die in a fire
18:12:21 <adamw> the key point for me is to get clarity on whether anaconda is going python3 for f22, because that would worry me.
18:12:22 <sgallagh> dgilmore: acknowledged
18:12:23 <dgilmore> and that you call explicitly python2 and python3
18:12:40 <mitr> (PEP 394)
18:13:03 <dgilmore> adamw: I think the answer to that is no
18:13:38 <nirik> I think the answer should be no, but it's not clear. ;)
18:13:40 <sgallagh> Anaconda can probably be excused from the  "default" argument since it's really only run in a private environment. So what's left of the Change proposal?
18:13:47 <adamw> if the answer is no, then the Change page should be amended not to cover it (so we don't have confusion later in the process and in PR and stuff)
18:14:21 <t8m> for example there is no chance we would have authconfig-gtk gui in Python3 any time soon
18:14:35 <t8m> on the other hand the command line ui could be ported easily
18:14:42 <adamw> anaconda using python2 will also mean that bullet point " Python 3 is the only Python implementation on the LiveCD " is not going to be true either
18:15:00 <dgilmore> adamw: right
18:15:01 <nirik> and I am not sure about the dnf point
18:15:04 <t8m> I am currently thinking about dropping the gui altoghether for F23
18:15:08 <dgilmore> maybe cloud can be python3 only
18:15:08 <adamw> DNF has its own Change, so we probably don't need to discuss it much here
18:15:28 <adamw> (but obviously if that Change gets pushed out, this page should be updated too)
18:15:38 <nirik> adamw: I meant dnf using python3
18:15:42 <t8m> and postponing the switch of the command line ui to F23 as well
18:15:47 <nirik> right now, it does not.
18:15:49 <jwb> does anyone see value in highlighting an on-going porting effort in F22?
18:16:06 <jwb> because if not, then we punt this to F23 and we can stop talking about it
18:16:07 <adamw> nirik: ah, heh, hadn't even thought about that.
18:16:20 <dgilmore> jwb: some. but it really depends on how much lands
18:16:20 <sgallagh> jwb: Well, there's one advantage.
18:16:35 <sgallagh> No one ever works on a porting effort until there's a time constraint.
18:16:38 <kalev> jwb: right, that's what my point earlier was as well -- I don't think it's worth highlighting the on-going porting for F22
18:16:49 <sgallagh> The further out it gets punted, the less likely it becomes that anyone will do the work.
18:17:00 <sgallagh> (Until the eventual upstream death of Python 2.7)
18:17:05 <jwb> sgallagh, i don't even think F23 is a realistic target.  i also don't think magic porting is going to happen because FESCo accepts a feature.
18:17:11 <sgallagh> At which point now we have a fire-drill
18:17:16 <nirik> I do see a fair bit of work...
18:17:26 <dgilmore> I see a crap ton of work
18:17:32 <nirik> it's just that IMHO trying to land it for f22 will result in lots of pain and slippage
18:17:37 <jwb> i see ponies.
18:17:49 <t8m> nirik, +1
18:18:12 <sgallagh> Yeah, I don't think this will be *complete* in F22
18:18:15 <t8m> I see a big city whose fame touches the stars.
18:18:18 <kalev> I think we should encourage individual apps to go on with porting if they feel it's safe to do so
18:18:21 <nirik> there's a python3-dnf (just don't know how well it works), there's dnf support in anaconda now, there's a ton of upstream patches.
18:18:23 <kalev> but don't require it
18:18:26 <mitr> jwb: I don’t think we will ~ever get _everything_ ported, but a smaller target of more popular/frequently used packages (like the default Product installs) must be feasible, or what is FESCo really doing here?
18:18:59 <sgallagh> Considering the scope of this, it might be worth proposing "Update software to use modern interpreters" as one of the Council Goal positions.
18:19:00 <jwb> mitr, FESCo isn't doing anything here.  why do you think this is something FESCo is doing?
18:19:08 <nirik> well, the question here is: is there enough work or things landing to make it worth highlighting as a change?
18:19:11 <sgallagh> Thereby assigning it a high-level shepherd
18:19:20 <jwb> mitr, or, more specifically, what action do you think FESCo should take?
18:19:27 <t8m> (that was my poor translation of a Czech prophet Libuše's words)
18:19:33 <t8m> :S
18:19:35 <t8m> :D
18:19:51 <nirik> I'm ok with: a) rescoping this change to what really will happen in f22, or b) moving to f23... but if a) is small, it seems like it might not be worth it.
18:19:59 <mitr> jwb: That’s not what I mean—if we can’t get a cross-distribution effort done then why have a voted cross-distribution decision body (instead of e.g. just letting adamw decide what daily build is a GA release)?
18:20:18 <jwb> mitr, again, what action(s) do you see FESCo needing to take to accomplish that?
18:20:43 <jwb> i'm not disagreeing with you.  i'm asking you what we need to do.
18:20:49 <t8m> mitr, +1
18:20:50 <sgallagh> mitr: Someone has to decide whether such an effort is a) desirable and b) feasible
18:21:11 <sgallagh> And then ideally act as a coordinating force to see it done.
18:21:14 <nirik> I think it is, it's just too late to land some of it this cycle. ;)
18:21:17 <dgilmore> sgallagh: and i think we all say its desirable but question feasibility for f22
18:21:26 <mitr> jwb: Dunno.  Write Fedora Magazine articles?  Ping people individually?  Slip the release?  Reject any commits that aren’t porting Python until Python is ported?
18:21:27 <sgallagh> As far as the latter, I think we can improve on the coordination
18:21:42 <sgallagh> Part of that would be approving the mass-bug-filing request (which I am in favor of)
18:21:50 <mitr> (and fwiw this ticket did cause people to be individually pinged, at least by anaconda developers)
18:21:58 * jwb sighs
18:22:14 <dgilmore> what can we decide here?
18:22:18 <jwb> proposal: defer this to F23, file bugs against rawhide after branch
18:22:25 <dgilmore> jwb: +1
18:22:26 <nirik> jwb: +1
18:22:27 <sgallagh> jwb: +1
18:22:40 <mitr> Proposal: Check status at the Change checkpoint, and _then_ decide.
18:22:42 <t8m> jwb, +1
18:22:44 * nirik wishes the change owner could be here... oh well
18:22:59 <t8m> but i can be mitr +1 as well
18:22:59 <kalev> +1
18:23:15 <nirik> mitr: that was -3 days ago?
18:23:34 <mitr> Do we specifically need to be hasty now?  Would deferring this free up critical resources needed elsewhere  or something?
18:23:34 <nirik> sorry...
18:23:49 <nirik> 2-24
18:23:49 <mitr> nirik: Feb 24 = completion deadline / alpha freeze
18:23:57 <sgallagh> mitr: Well, Anaconda has plenty on their plates
18:24:02 <nirik> mitr: well, my 2 concerns are:
18:24:19 <sgallagh> If they could spend the next month porting to python 3 or fixing bugs, I know where I'd rather see them spend the time
18:24:23 <nirik> a) qa says they would be ok with that anaconda change landing 2 weeks ago... but not now.
18:24:34 <nirik> b) things like python3-dnf haven't been used likely by anyone.
18:24:52 * mitr counts +6 to jwb’s proposal (if he is voting for that proposal as well)
18:24:59 <jwb> i am :)
18:25:17 <jwb> fwiw, i don't think we're being hasty.  i think we're being realistic
18:25:31 <dgilmore> jwb: agreed
18:25:35 <t8m> I agree
18:25:37 <Corey84> .hello corey84
18:25:38 <nirik> #agreed defer this to F23, file bugs against rawhide after branch (+6,0,0)
18:25:38 <zodbot> Corey84: corey84 'Corey84' <sheldon.corey@gmail.com>
18:25:57 <nirik> #topic ticket #1393 Making perl-sig a watcher on all perl packages
18:25:57 <nirik> https://fedorahosted.org/fesco/ticket/1393
18:25:57 <nirik> .fesco 1393
18:25:58 <nirik> +1 from thozza in ticket.
18:25:58 <t8m> the python3 switch of anaconda should bake in rawhide at least for a while, not to be developed after branch
18:25:59 <zodbot> nirik: #1393 (Making perl-sig a watcher on all perl packages) – FESCo - https://fedorahosted.org/fesco/ticket/1393
18:26:15 <nirik> I'm +1 to this since it's just watching.
18:26:19 <Corey84> +1 watch
18:26:24 <dgilmore> t8m: thats the kind of thing that should land the day after branching :)
18:26:34 <dgilmore> +1 to this
18:26:35 <kalev> +1 to adding perl-sig to watch
18:26:40 <t8m> dgilmore, yeah
18:26:41 <mitr> +1
18:26:48 <t8m> +1
18:26:51 <sgallagh> Assuming all members of the PERL SIG are okay, with this, +1
18:26:54 <Corey84> that +5 so far
18:26:57 <mitr> Note: this is an one-time request.  Would it be easy to make this apply automatically for future packages?
18:27:05 <sgallagh> (If they are not, this could lead to a lot of surprising extra emails for them)
18:27:14 <nirik> actually I am not sure why they are requesting it now that I think about it.
18:27:24 <mitr> Corey84: Please don’t add +- votes if you are not on FESCo, it makes counting more difficult.
18:27:39 <nirik> watchbugzilla and watchcommits are automatically granted I thought.
18:27:53 <nirik> so they could just do it.
18:28:10 <sgallagh> nirik: They're saying there are hundreds of them to go through.
18:28:11 <t8m> nirik, I suppose they did not want to manually go through all the packages
18:28:22 <nirik> pkgdb-cli is your friend. ;)
18:28:34 <jwb> i was under the impression they wanted to be included by default on all future perl packages
18:28:39 <jwb> maybe i misread
18:28:42 <mitr> t8m: (for hundreds == 83)
18:28:56 <nirik> jwb: well, if the request has it, it would be added.
18:29:04 <nirik> if not, how do we know something is a 'perl' package?
18:29:18 <sgallagh> nirik: prefix of "perl-"?
18:29:18 <jwb> nirik, don't we have packaging guidelines that say perl packages start with perl- ?
18:29:58 <dgilmore> not everything does
18:30:00 <nirik> perl using applications don't need that do they?
18:30:09 <dgilmore> if its a program written in perl it does not have to have it
18:30:19 <jwb> and i don't think the perl sig cares about those?
18:30:30 <dgilmore> but we could add logic if it starts with perl- we add it
18:30:37 <dgilmore> but it will not catch all users of perl
18:30:56 <kalev> I guess automating it for perl- and missing some users would still be an improvement?
18:31:00 <t8m> better catch some than nothing?
18:31:02 <nirik> proposal: have the perl sig add those to existing packages and work with releng/infra if something needs to be done ongoing
18:31:03 <jwb> i mean, i'm certainly doing a lot of reading between the lines here, but yeah
18:31:16 <jwb> because "everything that uses perl" probably isn't what they really want
18:31:31 <jwb> i doubt they want to get bug reports for the kernel, which they would if you take that stance because perf uses it
18:31:36 <jwb> WELCOME TO BUG HELL
18:31:38 <t8m> yeah I think they care only about libraries
18:31:42 <dgilmore> the ticket does say perl-*
18:31:51 <mitr> nirik: +1
18:32:00 <kalev> nirik: +1
18:32:03 <dgilmore> nirik: +1
18:32:04 <nirik> they have definitely cared about non library/module ones in the past, but I don't want to speak for them
18:32:14 <t8m> note that some perl-* packages might be subpackages of something that isn't perl-* package
18:32:21 <kalev> those can go through the manual process if needed
18:32:29 <t8m> sure
18:32:36 <t8m> nirik, +1
18:32:40 <jwb> anyway, +1 to nirik's proposal
18:32:59 <nirik> #agreed have the perl sig add those to existing packages and work with releng/infra if something needs to be done ongoing (+6,0,0)
18:33:11 <eseyman> \o/
18:33:12 <nirik> #undo
18:33:12 <zodbot> Removing item from minutes: AGREED by nirik at 18:32:59 : have the perl sig add those to existing packages and work with releng/infra if something needs to be done ongoing (+6,0,0)
18:33:16 <nirik> #agreed have the perl sig add those to existing packages and work with releng/infra if something needs to be done ongoing (+7,0,0)
18:33:27 <nirik> #topic ticket #1394 Use timedatex when an NTP package is installed
18:33:27 <nirik> https://fedorahosted.org/fesco/ticket/1394
18:33:27 <nirik> .fesco 1394
18:33:27 <nirik> +1 from thozza in ticket.
18:33:28 <zodbot> nirik: #1394 (Use timedatex when an NTP package is installed) – FESCo - https://fedorahosted.org/fesco/ticket/1394
18:34:35 * nirik isn't sure what to think of this really
18:34:39 <kalev> mclasen: do you know what Lennart's stance is here?
18:34:49 <jwb> i haven't had enough time to actually understand this
18:34:56 <jwb> so i'm not voting on anything
18:35:03 * mclasen missed the question
18:35:12 <mclasen> oh, timedated
18:35:24 <mitr> I have escalated this to FESCo to allow for a sanity check at least; we will end up with two implementations providing the same interface
18:36:13 <mitr> I don’t see any reason why it would be problematic but it does seem risky/unusual so I wanted a few more experienced eyes
18:36:17 <sgallagh> If I read this correctly, the fundamental issue here is that the systemd guys decided to only support their NIH NTP alternative and have broken compatibility with traditional NTP sources
18:36:41 <mitr> IIRC the devel@ discussions didn't bring up any specific technical objections
18:36:47 <kalev> from timedated API user's point of view, I think it makes a lot of sense to keep using the same API for controlling both daemons
18:36:55 <kalev> gnome-control-center for example doesn't overly care what's the underlying NTP implementation, as long as the API stays the same
18:36:56 <sgallagh> /me notes that chrony and ntpd are still in wide use (and that Fedora Server's Domain Controller role relies on and sets up ntpd)
18:36:58 <mclasen> not going to speak for lennart here, but my take it that I don't really want a full ntp server implemenation on my laptop
18:37:26 <mitr> mclasen: More to the point, a full NTP _client_?
18:37:32 <dgilmore> sgallagh: yeah. I run ntp everywhere
18:37:38 <sgallagh> mclasen: the NTP server and client are the same daemon
18:37:40 <dgilmore> using ntpd
18:38:03 <sgallagh> The only difference is whether you allow it to also listen for incoming connections
18:38:03 <nirik> chrony is a pretty full featured client.
18:38:06 <kalev> mclasen: I _think_ the proposal allows that -- if we don't install chrony, we'd get the systemd implementation and thing should keep on working
18:38:06 <mclasen> sgallagh: you're getting to the core of the issue...
18:38:30 <dgilmore> i am +1 to this going ahead
18:38:33 <jwb> so the systemd thingy is a client-only implementation?
18:38:43 <jwb> whereas chrony and ntpd provide both client and server?
18:38:54 <zbyszek> jwb: yes, and it's also only SNTP
18:38:55 <mitr> jwb: client-only for “sntp“
18:39:01 <t8m> is the server really so big addition to the code that is needed for client?
18:39:19 <zbyszek> t8m: the difference in size is fairly big
18:39:25 <mlichvar> fwiw, chronyd doesn't listen on ntp port by default
18:39:54 <t8m> how big?
18:40:03 <dgilmore> given http://lists.freedesktop.org/archives/systemd-devel/2014-August/022523.html I think lennart is wrong. there are a lot of good reasons to configure your own ntp servers
18:40:32 <dgilmore> to talk to your ipa server. in a corporate environment that block outbound ntp requests
18:40:35 <t8m> 500 kBytes of chrony does not seem big to me
18:40:36 * nirik is a weak +1 to this as well.
18:40:44 <jwb> still 0
18:40:48 <t8m> so I am +1 as well
18:41:25 <sgallagh> Wait, timedated can *only* talk to the root servers?
18:41:29 <sgallagh> That's... that's horrible.
18:41:50 <kalev> I am unsure which implementation would make more sense for Workstation, but my current understanding is that the proposal allows individual products to choose if they want systemd implementation or the timedatex one
18:41:52 <mitr> Proposal: 1) FESCo knows no technical reason why this change would break anything.  2) We prefer a timedated implementation that can allow using chrony or ntpd as the NTP client being used.
18:41:55 <zbyszek> sgallagh: it has a configured list of servers
18:41:58 <kalev> with this in mind, I am +1 as well
18:41:59 <dgilmore> sgallagh: it can only talk to the servers it has configured apparently
18:42:17 <zbyszek> sgallagh: compile time default, overridable in config file, or through dhcp
18:42:19 <mitr> (would splitting this discussion help?)
18:42:35 <mitr> I am weakly +1 (to both)
18:42:40 <sgallagh> zbyszek: Well, if a config file can change it, that's not unreasonable.
18:43:29 <zbyszek> sgallagh: Sorry, I meant that the compile time default is set to e.g. pool.ntp.fedora.org or something like that, and in addition it can be overriden by config file.
18:43:34 <nirik> mitr: +1 to both
18:43:57 <t8m> mitr, +1 to both
18:44:42 <dgilmore> +1 to both
18:44:57 <sgallagh> So currently, timedated can only talk to timesyncd?
18:45:07 <dgilmore> sgallagh: that is the takeaway yes
18:45:11 <sgallagh> Which only supports sntp as a protocol, not traditional NTP?
18:45:19 <zbyszek> sgallagh: In f22. In f21 the old schme is in place.
18:45:21 <dgilmore> sgallagh: and only one server
18:45:24 <nirik> yes, thats my understanding
18:45:45 <zbyszek> dgilmore: It cycles through servers on error.
18:46:08 <zbyszek> (after some timeout without a valid answer)
18:46:09 <sgallagh> zbyszek: Any plans to support a round-robin or other alternative mechanism?
18:46:14 <dgilmore> zbyszek: okay, that is not what is said in the email thread I am reading on systemd-devel
18:46:51 <dgilmore> zbyszek: but realistically you should check 2 or 3 sources at all times. just to make sure that you are not trustinga  source that is wildly off
18:46:57 <mitr> sgallagh: SNTP is a subset of NTP (less features but interoperable)
18:47:25 <mitr> Yeah, the SNTP design case of single-master-server seems not to be too well suited for the actual usage of pool.ntp.org
18:47:33 <mitr> mlichvar: (or am I wrong?)
18:47:48 <zbyszek> dgilmore: I don't really have a position on this issue. I think timesyncd is not yet ready for wide consumption.
18:48:24 <nirik> so, we are at +4 I think...
18:48:39 <sgallagh> OK, so do we as FESCo want to mandate that timedated must be backed (or at least capable of being backed) by chrony and/or ntpd?
18:48:55 <dgilmore> mitr: are you +1 to your proposal
18:49:08 <nirik> sgallagh: not sure what good it would do if upstream doesn't want to do that?
18:49:23 <nirik> kalev: you were +1 to mitr's ?
18:49:30 <dgilmore> mitr: sorry missed your vote
18:49:36 <kalev> I was +1 to the original proposal in the ticket
18:49:46 <sgallagh> nirik: I'd like to believe that upstream will occasionally listen to the needs of its users.
18:50:37 <nirik> ok, so what do we want to do here... mitr's more detailed proposal is +4, but the ticket proposal is probibly +6?
18:50:59 <mitr> nirik: I think the original proposal is equivalent to my 1), so make the original proposal pass.
18:51:11 <nirik> ok.
18:51:23 <nirik> #agreed This use is approved (+6,0,0)
18:51:28 <mitr> sgallagh: I do think that it would be good to support all of them, I am not quite sure that it is important enough to mandate by FESCo.  Effectively, through, if we allow 1) then de facto the situation will change and we will not strictly _need_ the mandate :)
18:51:32 <nirik> do we want to discuss the second part more? or just move on?
18:51:52 <mclasen> what is the systemd preset file that the ticket is talking about ? there's different preset files per product, no ?
18:51:57 <mitr> Move on…. let me formally withdraw it to save time.  Someone can repropose if necessary.
18:52:01 <sgallagh> mitr: Until upstream decides they know better than FESCo and breaks API...
18:52:22 <sgallagh> mclasen: There's a global one and per-product add-ons to it
18:52:34 <sgallagh> (Which can add or subtract from the common one)
18:53:03 <nirik> #topic ticket #1407 F22 System Wide Change: Vagrant Box for Fedora Atomic and Fedora Cloud - https://fedoraproject.org/wiki/Changes/Vagrant_Box_Atomic
18:53:03 <nirik> https://fedorahosted.org/fesco/ticket/1407
18:53:03 <nirik> .fesco 1407
18:53:04 <mitr> sgallagh: I’d rather not be angry about the _possibility_ about either of the upstreams being stupid right now
18:53:04 <zodbot> nirik: #1407 (F22 System Wide Change: Vagrant Box for Fedora Atomic and Fedora Cloud - https://fedoraproject.org/wiki/Changes/Vagrant_Box_Atomic) – FESCo - https://fedorahosted.org/fesco/ticket/1407
18:53:59 <mitr> +1 as written.
18:54:08 <jwb> is it realistic that we're going to get the koji changes in place to do this?
18:54:27 <kalev> dgilmore, nirik: what's releng's position here, anything that would make it difficult to deliver the new deliverables?
18:54:30 <dgilmore> jwb: it should actually all be tehre
18:54:42 <nirik> +1 from me
18:54:43 <dgilmore> everything should be in place as of last night
18:54:47 <jwb> dgilmore, that is a pleasant surprise!
18:54:51 <mitr> Though, there are several Changes that propose adding new rel-eng deliverables (and mirror space requirements?); should we just let rel-eng deal with the requests as they think best?
18:54:58 <walters> note i'm trying to consolidate these: https://lists.fedoraproject.org/pipermail/devel/2015-January/207240.html
18:55:11 <nirik> jwb: dgilmore upgraded our builders/hubs to the latest git head koji to pick up a bunch of things (even your xz change I hope)
18:55:29 <dgilmore> most of the atomic changes seem to be things we delivered in f21
18:55:37 <jwb> nirik, sure, i knew that.  it wasn't clear the koji patches for this were actually written yet
18:55:58 <dgilmore> jwb: the vagrant patches are and are deployed elsewhere
18:56:23 <t8m> +1 from me
18:56:33 <jwb> so, to be clear on the vagrant thing, the "out of the box on VirtualBox/VMWare" goal for this change does not include vbox/vmware guest additions, correct?
18:56:45 <nirik> walters: yeah, there were questions about some of those changes... if they were already done, etc.
18:57:10 <dgilmore> walters: main concern is that most of what is proposed we did in f21
18:57:14 <mitr> jwb: Didn’t we approve VMWare guest additions as a package installed by default about a year ago?
18:57:23 <walters> the bare metal atomic was not done in f21
18:57:23 <dgilmore> so it was really unclear as to what was actually being proposed
18:57:44 <dgilmore> walters: yes it was
18:57:48 <jwb> mitr, i'm specifically thinking about the kernel modules vbox requires.  pretty sure we didn't approve random kernel module packages
18:58:04 <jwb> i'm just interested to hear how "out of the box" the experience will be without those
18:58:13 <dgilmore> walters: you can use anaconda to install atomic on bare metal in f21. that is how we do it for the cloud image.
18:58:21 <dgilmore> but its not really well documented
18:58:41 <walters> i dunno man, i mean i wrote most of the anaconda patches and maintained the content and actively debug it
18:58:50 <nirik> one other question on this: QA and release critera? I guess the cloud wg is going to do the testing here ?
18:59:12 <walters> among other things the switch to grub2 only landed post f21
18:59:22 <walters> so technically you're right some components are in f21
18:59:33 <dgilmore> walters: right, but you can deploy it on bare metal. what you likely really want is more anaconda work to make it easier and more integrated
19:00:25 <walters> i'd say it this way; i tell people who ask about f21 atomic anaconda not to do it and wait for f22
19:00:47 <dgilmore> as to the vagrant images. I guess we will find out if it works well without external kernel modules and is a feasible option
19:00:53 <walters> besides grub2, the partitioning defaults are also not in f21
19:00:58 <dgilmore> jwb: I guess we find out
19:01:16 <nirik> so, we are at +3 for this change...
19:01:17 <walters> partitioning: https://github.com/projectatomic/fedora-productimg-atomic
19:01:26 <dgilmore> do we want to consider all teh atomic changes right now
19:01:30 <jwb> dgilmore, i'm find with wait and see, but i want the proposal owners to be aware of the potential issue if they aren't already
19:01:33 <dgilmore> since walters wants to make them one?
19:01:35 <nirik> dgilmore: if it would help, sure.
19:01:44 <kalev> nirik: +1 here too
19:01:45 <nirik> walters: you want to go to 1? or 2? from 3
19:01:51 <dgilmore> we are kinda mixing them anyway
19:01:52 <mitr> dgilmore: I’d rather work with the text as it is today instead of trying to group-edit it in 10 people right now
19:02:01 <jwb> mitr, agreed
19:02:02 <dgilmore> mitr: no problems
19:02:09 <walters> the RpmOstree change is strongly related to but technologically independent of AtomicHost
19:02:14 <dgilmore> walters: lets table this until we get to the relevant ticket
19:02:34 <dgilmore> right now we are talking pure vagrant images
19:02:43 <mitr> Perhaps we will end up consolidating them but let's actually talk about the individual items.
19:02:50 <nirik> sure.
19:02:53 <nirik> so thats +4
19:02:53 <dgilmore> so the status is the koji changes are landed already
19:03:07 <dgilmore> there is concerns over the experience and kernel modules
19:03:27 <jwb> i don't have concerns as much as i'm just curious if they even thought about it
19:03:38 <jwb> if they didn't, it doesn't concern me one bit :)
19:03:47 <jwb> anyway, +1 from me
19:03:49 <dgilmore> jwb: likely they didn't as its not mentioned
19:03:54 <dgilmore> but we can ask
19:04:12 <dgilmore> nirik: so with jwb +5?
19:04:14 <nirik> yep
19:04:22 <nirik> #agreed Change is approved (+5,0,0)
19:04:24 <dgilmore> that lets it pass
19:04:44 <nirik> #topic ticket #1374 F22 Self Contained Changes
19:04:44 <nirik> https://fedorahosted.org/fesco/ticket/1374
19:04:44 <nirik> .fesco 1374
19:04:44 <nirik> +1 for all from thozza in ticket.
19:04:46 <zodbot> nirik: #1374 (F22 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1374
19:05:32 <kalev> +1
19:05:40 <nirik> +1 here
19:05:52 <sgallagh> +1 to all of them
19:05:55 <dgilmore> +1 to all
19:06:05 <jwb> sure, +1
19:06:13 <dgilmore> there was a +1 in the ticket also
19:06:24 <mitr> +1 to all
19:06:24 <nirik> #agreed All self contained changes approved (+7,0,0)
19:06:29 <nirik> #undo
19:06:29 <zodbot> Removing item from minutes: AGREED by nirik at 19:06:24 : All self contained changes approved (+7,0,0)
19:06:31 <t8m> +1
19:06:36 <sgallagh> Also, sorry. I got distracted for the last conversation, but I'm also +1 to the Vagrant change. (Feel free not to edit the minutes)
19:06:53 <nirik> #agreed All self contained changes approved (+7,0,0)
19:06:57 <nirik> #undo
19:06:57 <zodbot> Removing item from minutes: AGREED by nirik at 19:06:53 : All self contained changes approved (+7,0,0)
19:07:02 <nirik> #agreed All self contained changes approved (+9,0,0)
19:07:12 <nirik> #topic ticket #1390 F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades -
19:07:12 <nirik> https://fedoraproject.org/wiki/Changes/RpmOstree
19:07:12 <nirik> https://fedorahosted.org/fesco/ticket/1390
19:07:12 <nirik> .fesco 1390
19:07:15 <zodbot> nirik: #1390 (F22 System Wide Change: RpmOstree - Server side composes and atomic upgrades - https://fedoraproject.org/wiki/Changes/RpmOstree) – FESCo - https://fedorahosted.org/fesco/ticket/1390
19:07:35 <dgilmore> so to me this all landed in f21
19:07:47 <dgilmore> walters: what here is actually new for fedora 22?
19:08:42 <walters> the goal of the standalone RpmOstree change is to have the tooling and changes go through a more proper documented process
19:08:51 <walters> and be standalone/consumable indepdently of the AtomicHost product
19:08:52 <dgilmore> walters: providing docs and tooling on people to build, test and deploy their own trees I think would be extremely worthwhile
19:08:57 <walters> right
19:08:57 <mitr> There is the (unknown/not yet proposed?) /var packaging change also
19:09:11 <walters> also there are other related changes like https://fedoraproject.org/wiki/Changes/SystemdSysusers
19:09:16 <t8m> if it is really just polish and advertisement of what was already implemented shouldn't it be a self-contained change?
19:09:40 <sgallagh> t8m: Not if it involves rel-eng and mirroring changes, I think
19:09:47 <t8m> ok
19:09:52 <mitr> And anaconda…
19:09:55 <sgallagh> Right
19:09:58 <dgilmore> sgallagh: but it doesn't that was done in f21
19:10:06 <dgilmore> as was anaconda support
19:10:12 <dgilmore> that is how we install it
19:10:14 <mitr> Or are the anaconda etc. changes logically part of AtomicHost instead?
19:10:16 * nirik looks back to the f21 change
19:10:19 <dgilmore> so its not adding rpmos tree
19:10:19 <walters> dgilmore, only in VMs
19:10:22 <sgallagh> Maybe I misunderstood the above statements then
19:10:31 <dgilmore> its about advertising and improving on what we already have
19:10:36 <dgilmore> walters: not true
19:10:48 <dgilmore> walters: you could do an anaconda install witha  kickstart
19:10:50 <sgallagh> walters: What do you expect to be the impact outside of the Atomic SIG?
19:11:00 <dgilmore> I suspect only on a legacy bios
19:11:09 <walters> dgilmore, there's a vast gap between what you *can* do and what is advertised/supported
19:11:10 <sgallagh> That would need multiple-project coordination, I mean
19:11:21 <nirik> https://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image was the f21 change?
19:11:29 <nirik> yeah, it doesn't really say much at all. ;)
19:12:39 <dgilmore> I am -1 to this change right now because I really do not see what is that new over what we delivered in f21
19:13:01 <dgilmore> I think it could be reworked to be a very useful thing
19:13:15 <nirik> dgilmore: what we delivered and what we advertised as we delivered were very different.
19:13:26 <t8m> I don't have a problem with self-contained change that would provide the polish, documentation of use-cases and advertising
19:13:45 <nirik> so, without that advertisement, people likely don't know all that we did in f21.
19:13:48 <dgilmore> t8m: agreed
19:13:54 <mitr> t8m: If this should be done by Fedora QA and end up in release criteria it might be proper to make it system-wide.
19:14:23 <roshi> currently there are no Atomic release criteria
19:14:33 <mitr> But it does seem like an implementation detail of Atomic_Cloid_Image and AtomicHost, so perhaps merge / consider an implementation detail of these?
19:14:42 <dgilmore> there is a need for anaconda polish to make it much more useful in different senarios,  as well as docs on how you could compose and deploy locally
19:15:01 <dgilmore> making a tree and deploying 10,000 web servers would be awesome
19:15:14 <roshi> release criteria implies that it can block release, is that the proposal?
19:15:18 * roshi reads backscroll
19:15:24 <nirik> dgilmore: isn't that what this change is?
19:15:32 <dgilmore> nirik: not from what I read
19:16:13 <dgilmore> nirik:in the scope  the only thing i see as new is " Anaconda/Architecture porters: Backends for the OSTree bootloader code, similar to grubby"
19:16:25 <mitr> walters: ?
19:16:32 <dgilmore> the rpm content is a bunch of todo's
19:16:42 <nirik> dgilmore: so what would you like to see there? documentation? or ?
19:16:48 <dgilmore> maybe its just lacking the needed detail
19:17:09 <dgilmore> the releng scope of it was done in f21
19:17:43 <nirik> right.
19:17:45 <randomuser> the docs team can possibly, maybe provide some assistance with this, given some investment from people in the know
19:17:47 <dgilmore> walters: I believe if you plan on packaging guideline changes in a change you are supposed to provide a proposed guideline in the change
19:18:12 <randomuser> we don't have a walters equivalent FTE for.. anything, basically
19:18:13 <nirik> anyhow, I am +1...
19:18:22 <sgallagh> Yes, we voted on that some weeks ago now.
19:18:26 <dgilmore> I guess I fill it is void of anything that is changing from what we did in f21
19:18:31 <dgilmore> feel
19:18:39 <mitr> dgilmore: “This draft does not need to be prepared prior to submitting the Change request, but must be complete by Alpha Freeze or the Contingency Plan will be invoked. ”
19:19:02 <dgilmore> mitr: okay so there is about 4 weeks
19:19:07 <dgilmore> or so
19:19:09 <nirik> dgilmore: I think it's good to actually document and advertise that work we did in f21.
19:19:38 <t8m> Ok +1 anyway as I don't really care if this is self-contained or not
19:19:50 <mitr> Considering the questions seem the same as last time…
19:19:52 <mitr> Proposal: Defer for answers, rewording, or merging with the others
19:20:09 <dgilmore> I would like a lot more detail in the change
19:20:18 <mitr> (i.e. if Colin plans to merge them anyway then let’s hope this one goes away)
19:20:18 <dgilmore> but maybe I am alone on that
19:20:20 <nirik> walters: you still with us?
19:20:21 <walters> dgilmore, yeah, i'll fill it in more
19:20:56 <mitr> dgilmore: It might be more detail or perhaps _less_ detail (and content)even ☺, but as it is it is unclear
19:21:08 <dgilmore> mitr: sure
19:21:12 <sgallagh> OK, so I'm +1 for voting next week with a revised Change
19:21:14 <nirik> ok, so punt to next week?
19:21:14 <dgilmore> I guess I mean more clarity
19:21:46 <dgilmore> sgallagh: that I can get behind
19:22:09 <nirik> ok, since we don't have enough votes to pass, I think defer wins automagically.
19:22:23 <nirik> perhaps dgilmore and walters could hash out some changes before next week?
19:22:24 <t8m> +1 to punt
19:22:45 <nirik> #info will revisit next week
19:22:49 <nirik> #topic ticket #1396 F22 System Wide Change: Atomic Host - https://fedoraproject.org/wiki/Changes/AtomicHost
19:22:49 <nirik> https://fedorahosted.org/fesco/ticket/1396
19:22:49 <nirik> .fesco 1396
19:22:50 <zodbot> nirik: #1396 (F22 System Wide Change: Atomic Host - https://fedoraproject.org/wiki/Changes/AtomicHost) – FESCo - https://fedorahosted.org/fesco/ticket/1396
19:22:56 <nirik> this is another atomic one. ;)
19:23:12 <dgilmore> nirik: I am happy to work with walters on it
19:23:30 <mitr> Scope:  Other developers: Unknown ???
19:23:58 <dgilmore> this seems very tied into the previous change
19:24:06 <mitr> Also, the Contingency Plan says about this being a blocker for Atomic Cloud upgrade mechanisms, but that is not in Scope AFAICT
19:24:20 <dgilmore> as this is about installing of said tree
19:24:35 <nirik> walters: was this one you wanted to fold into the last one?
19:24:41 <mitr> (In principle this seems nice and desirable)
19:24:41 <nirik> perhaps we should revisit this next week as well?
19:25:02 * dgilmore thinks all of this is some of what was missing in the previous change
19:25:20 <sgallagh> walters was talking about merging all these into a single Change.
19:25:23 <mitr> dgilmore: This seems to add _6_ new deliverables.  Feasible?
19:25:26 <sgallagh> Perhaps we should just let him? :)
19:25:42 <dgilmore> mitr: we do most of them already
19:25:53 <mitr> sgallagh: Seems we won't get detailed answers in the meeting, so, yes.
19:26:05 <t8m> let the changes be merged!
19:26:12 <t8m> :)
19:26:13 <dgilmore> mitr: and most of it I think is changes to anaconda
19:26:30 <nirik> proposal: revisit this (or just the last one if this is merged) next week.
19:26:46 <jwb> yeah
19:26:50 <kalev> sure
19:26:59 <mitr> +1
19:27:02 <dgilmore> mitr: we only make one image for cloud providers and we already upload to EC2  we can't upload to Google, that is pending legal folks
19:27:19 <dgilmore> nirik: +1
19:27:34 <nirik> #agreed will revisit next week (+5,0,0)
19:27:53 <nirik> #topic ticket #1397 F22 System Wide Change: Bare Metal Installer for Fedora Atomic Host - https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic
19:27:53 <nirik> https://fedorahosted.org/fesco/ticket/1397
19:27:53 <nirik> .fesco 1397
19:27:53 <nirik> +1 from thozza in ticket.
19:27:54 <zodbot> nirik: #1397 (F22 System Wide Change: Bare Metal Installer for Fedora Atomic Host - https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic) – FESCo - https://fedorahosted.org/fesco/ticket/1397
19:28:05 <jwb> same proposal as above
19:28:15 <dgilmore> yep
19:28:37 <dgilmore> propoasal: wait on merged change
19:28:41 <dgilmore> +1 from me
19:28:45 <t8m> +1
19:28:49 <nirik> +1
19:28:53 <jwb> yes
19:28:57 <t8m> (to wait)
19:29:08 <sgallagh> +1
19:29:09 <mitr> I could be +1 to this individually, but let’s wait
19:29:14 <dgilmore> if only I could spell today
19:29:15 <nirik> #agreed will revisit next week (+6,0,0)
19:29:24 <nirik> #topic ticket #1398 F22 System Wide Change: Database Server Role - https://fedoraproject.org/wiki/Changes DatabaseServerRole
19:29:24 <nirik> https://fedorahosted.org/fesco/ticket/1398
19:29:24 <nirik> .fesco 1398
19:29:24 <nirik> +1 from thozza in ticket.
19:29:27 <zodbot> nirik: #1398 (F22 System Wide Change: Database Server Role - https://fedoraproject.org/wiki/Changes/DatabaseServerRole) – FESCo - https://fedorahosted.org/fesco/ticket/1398
19:29:31 <nirik> +1 from me
19:29:36 <sgallagh> Biased +1 ;-)
19:29:42 <mitr> +1
19:29:45 <kalev> +1
19:30:06 <t8m> +1
19:30:10 <dgilmore> +1
19:30:36 <nirik> #agreed Change is approved (+7,0,0)
19:30:38 <jwb> +1
19:30:42 <nirik> #undo
19:30:42 <zodbot> Removing item from minutes: AGREED by nirik at 19:30:36 : Change is approved (+7,0,0)
19:30:45 <nirik> #agreed Change is approved (+8,0,0)
19:30:58 <nirik> #topic ticket #1399 F22 System Wide Change: Django18 - https://fedoraproject.org/wiki/Changes/Django18
19:30:58 <nirik> https://fedorahosted.org/fesco/ticket/1399
19:30:58 <nirik> .fesco 1399
19:30:58 <nirik> +1 from thozza in ticket.
19:30:59 <zodbot> nirik: #1399 (F22 System Wide Change: Django18 - https://fedoraproject.org/wiki/Changes/Django18) – FESCo - https://fedorahosted.org/fesco/ticket/1399
19:31:18 <mitr> +1
19:31:19 <dgilmore> +1
19:31:23 <jwb> +1
19:31:40 <kalev> +1
19:31:47 <nirik> +1
19:32:02 <t8m> +1
19:32:26 <nirik> #agreed Change is approved (+7,0,0)
19:32:34 <sgallagh> +1
19:32:38 <nirik> #undo
19:32:38 <zodbot> Removing item from minutes: AGREED by nirik at 19:32:26 : Change is approved (+7,0,0)
19:32:40 <sgallagh> (sorry)
19:32:45 <nirik> #agreed Change is approved (+8,0,0)
19:32:52 <nirik> #topic ticket #1400 F22 System Wide Change: Glibc Unicode 7.0 - https://fedoraproject.org/wiki/Changes/Glibc_Unicode_7
19:32:52 <nirik> https://fedorahosted.org/fesco/ticket/1400
19:32:52 <nirik> .fesco 1400
19:32:52 <nirik> +1 from thozza in ticket.
19:32:53 <zodbot> nirik: #1400 (F22 System Wide Change: Glibc Unicode 7.0 - https://fedoraproject.org/wiki/Changes/Glibc_Unicode_7) – FESCo - https://fedorahosted.org/fesco/ticket/1400
19:33:01 <jwb> +1
19:33:03 <mitr> +1
19:33:07 <kalev> +1
19:33:10 <dgilmore> +1
19:33:22 <sgallagh> +1
19:33:34 <nirik> +1
19:33:44 <t8m> +1
19:33:45 <nirik> #agreed Change is approved (+8,0,0)
19:33:55 <nirik> #topic ticket #1401 F22 System Wide Change: GNOME 3.16 - https://fedoraproject.org/wiki/Changes/GNOME3.16
19:33:55 <nirik> https://fedorahosted.org/fesco/ticket/1401
19:33:55 <nirik> .fesco 1401
19:33:55 <nirik> +1 from thozza in ticket.
19:33:56 <zodbot> nirik: #1401 (F22 System Wide Change: GNOME 3.16 - https://fedoraproject.org/wiki/Changes/GNOME3.16) – FESCo - https://fedorahosted.org/fesco/ticket/1401
19:34:02 <dgilmore> +1
19:34:03 <kalev> +1
19:34:11 <jwb> +1
19:34:28 <mitr> +1
19:34:29 <nirik> +1
19:34:30 <t8m> +1
19:34:44 * nirik is looking forward to that notifcation redesign.
19:34:47 <sgallagh> +1
19:34:51 <nirik> #agreed Change is approved (+8,0,0)
19:34:56 <sgallagh> Yes, the notification redesign is much-desired.
19:35:02 <nirik> #topic ticket #1402 F22 System Wide Change: Plasma 5 - https://fedoraproject.org/wiki/Changes/Plasma_5
19:35:02 <nirik> https://fedorahosted.org/fesco/ticket/1402
19:35:02 <nirik> .fesco 1402
19:35:02 <nirik> +1 from thozza in ticket.
19:35:03 <zodbot> nirik: #1402 (F22 System Wide Change: Plasma 5 - https://fedoraproject.org/wiki/Changes/Plasma_5) – FESCo - https://fedorahosted.org/fesco/ticket/1402
19:35:07 <jwb> +1
19:35:17 <kalev> +1
19:35:20 <mitr> +1
19:35:27 <jwb> fwiw, i tried a plasma5 image a while ago.  i find it much nicer than whatever kde 4.x is called
19:35:34 <nirik> +1
19:35:42 * nirik hasn't tried it yet.
19:35:42 <t8m> +1
19:35:45 <kalev> I haven't tried plasma 5, but I trust the KDE team
19:36:02 <dgilmore> jwb: its interesting
19:36:05 <dgilmore> im +1
19:36:05 <sgallagh> I think the KDE team did the right thing with waiting until Plasma 5 was further along. +1
19:36:14 <nirik> #agreed Change is approved (+8,0,0)
19:36:29 <sgallagh> /me intends to spend a couple weeks with it soon and blog on it like I did with GNOME 3.
19:36:53 <nirik> yeah, I'll be happy to give it a try when it lands in rawhide.
19:36:56 <nirik> #topic ticket #1403 F22 System Wide Change: Login Screen Over Wayland - https://fedoraproject.org/wiki/Changes/Login_Screen_Over_Wayland
19:36:57 <nirik> https://fedorahosted.org/fesco/ticket/1403
19:36:57 <nirik> .fesco 1403
19:36:57 <nirik> +1 from thozza in ticket.
19:36:58 <zodbot> nirik: #1403 (F22 System Wide Change: Login Screen Over Wayland - https://fedoraproject.org/wiki/Changes/Login_Screen_Over_Wayland) – FESCo - https://fedorahosted.org/fesco/ticket/1403
19:37:00 <jwb> sgallagh, i had a similar thought.  in the end, the result would have been boring.  "it works.  it's different."
19:37:23 <mitr> +1
19:37:33 <kalev> +1
19:37:34 <jwb> i'm +1 to this
19:37:44 <t8m> +1
19:37:53 <sgallagh> +1
19:38:08 <sgallagh> (I'd love to see sddm updated to support this as well, but I realize that may be ambitious)
19:38:22 <nirik> +1
19:39:27 <nirik> #agreed Change is approved (+7,0,0)
19:39:53 <nirik> #topic ticket #1404 F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default - https://fedoraproject.org/wiki/Changes/Polyinstantiated_tmp_by_Default
19:39:53 <nirik> https://fedorahosted.org/fesco/ticket/1404
19:39:53 <nirik> .fesco 1404
19:39:54 <nirik> -1 as written from thozza, +1 to adding a easy user enable/disable feature
19:39:55 <zodbot> nirik: #1404 (F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default - https://fedoraproject.org/wiki/Changes/Polyinstantiated_tmp_by_Default) – FESCo - https://fedorahosted.org/fesco/ticket/1404
19:40:17 <mitr> t8m: You are the expert on pam_namespace, aren’t you?
19:40:58 <dgilmore> this would break some of the workflows i use for some things but is easily worked around
19:41:10 <t8m> mitr, well, I did not work with it for a long time
19:41:23 <mitr> t8m: any comments?
19:41:33 <t8m> mitr, I am currently undecided on whether we really want this
19:42:06 * mitr will go with -1 based on the “individual namespaces break mount(1) from user sessions” claim and no response to it
19:42:19 <kalev> I am -1 as well
19:42:22 <t8m> mitr, the breakage is not about pam_namespace itself but mainly about the X and simple sharing of data between accounts through /tmp
19:42:24 <nirik> I also do not see any 'how to disable this'
19:42:48 <t8m> and yes, individual namespaces do break mount() from user sessions
19:42:48 <mitr> nirik: It is editing 2-3 lines in /etc/security/namespace.conf, so reasonably easy to both enable and disable
19:43:13 <nirik> mitr: ok. If you just disable selinux or put it permissive what happens?
19:43:49 * nirik notes we have had this enabled on fedorapeople.org for many years.
19:43:51 <mitr> nirik: namespaces are not that related to SELinux (it’s more a part of the container implementation)
19:44:53 <nirik> so, thats -3
19:45:18 <sgallagh> poly-instantiated /tmp can cause problems with kerberos as well (though we've mitigated a lot of that through the KEYRING cache type)
19:46:06 <mitr> (In principle, I guess this has the same answer as tmp-on-tmpfs: if you want new semantics, invent a new name first, then migrate the users that you _know_ want the new ones)
19:46:31 <dgilmore> I am -1
19:46:33 <t8m> I am +0 as I think we could try it
19:46:40 <jwb> i'm leaning -1
19:46:50 <sgallagh> I'm on the fence here somewhat, as the security benefits are fairly obvious, but I know it will break a lot of things.
19:46:58 * nirik is with sgallagh
19:47:12 <nirik> so, if jwb leans -1, thats -5?
19:47:19 <jwb> think so
19:47:29 <sgallagh> I'd rather vote -1 and encourage the security folks to work towards improving the vulnerable software
19:47:48 <dgilmore> It seems like something that should be tried in test environments and find more of the things it will break and get them fixed
19:47:55 <nirik> #agreed This change is not approved as written (-6,0,0)
19:48:00 <sgallagh> Rather than attempting to shoehorn in a safety net (made of unset concrete)
19:48:01 <dgilmore> re-evaluate down the road
19:48:12 <nirik> #topic ticket #1405 F22 System Wide Change: python-dateutil 2.x - https://fedoraproject.org/wiki/Changes/python-dateutil_2.x
19:48:12 <nirik> https://fedorahosted.org/fesco/ticket/1405
19:48:12 <nirik> .fesco 1405
19:48:12 <nirik> +1 from thozza in ticket
19:48:13 <zodbot> nirik: #1405 (F22 System Wide Change: python-dateutil 2.x - https://fedoraproject.org/wiki/Changes/python-dateutil_2.x) – FESCo - https://fedorahosted.org/fesco/ticket/1405
19:48:21 <kalev> +1
19:48:24 <mitr> +1
19:48:26 <nirik> +1
19:48:33 <dgilmore> +1
19:48:37 <sgallagh> +1 (and I'll be working to help with this where needed)
19:48:50 <t8m> +1
19:48:57 <jwb> +1
19:49:27 <nirik> #agreed Change is approved (+8,0,0)
19:49:58 <nirik> #topic ticket #1406 F22 System Wide Change: Systemd Package Split - https://fedoraproject.org/wiki/Changes SystemdPackageSplit https://fedorahosted.org/fesco/ticket/1406
19:49:58 <nirik> .fesco 1406
19:49:58 <nirik> -1 from thozza in ticket
19:49:59 <zodbot> nirik: #1406 (F22 System Wide Change: Systemd Package Split - https://fedoraproject.org/wiki/Changes/SystemdPackageSplit) – FESCo - https://fedorahosted.org/fesco/ticket/1406
19:50:05 <nirik> zbyszek: you around?
19:50:12 <zbyszek> yes
19:50:30 <kalev> I am not opposed to the change per se, but I think the systemd maintainers need to form consensus on this
19:50:32 <nirik> so, you still want to do this, even tho upstream is not happy with it? :)
19:51:02 <dgilmore> I am -1 to this
19:51:05 <mitr> +1.  Could go with the “does not override package owners” clause
19:51:05 * nirik isn't sure it really gets us much
19:51:10 <kalev> without systemd maintainers having consensus, I'd be -1 as well
19:51:19 <dgilmore> I do not see the buidlroot case as giving us vey much
19:51:20 <nirik> mitr: a good point.
19:51:29 <zbyszek> I made the proposal knowing that some other maintainers are unhappy.
19:51:54 <mitr> nirik: We are deduplicating freaking licenses to save space in cloud and containers.  Throwing out things like systemd-fsck and systemd-hibernate from the insides of a container seems like a no-brainer in comparison.
19:51:59 <sgallagh> zbyszek: Is the only advantage that it trims some stuff out of the buildroot?
19:52:24 <zbyszek> buildroot and possibly minimal containers etc.
19:52:28 <nirik> mitr: yeah, those seem a bit crazed to me too to be honest. ;)
19:52:28 <sgallagh> right
19:52:53 <zbyszek> Please note that systemd-resolved will soon depend on cryptographic libraries :)
19:52:54 <dgilmore> du -hs /usr/lib/systemd/system
19:52:54 <dgilmore> 1.5M	/usr/lib/systemd/system
19:53:09 <mitr> nirik: Instinctively I’d rather have a good image deduplication solution for cloud but the experts say it’s needed, so I guess it’s needed.
19:53:10 <nirik> 1.5mb is lost in the noise.
19:53:35 <zbyszek> nirik: It's mostly in the deps.
19:53:53 <nirik> even so, I bet it's not much
19:54:21 <mitr> dgilmore: All of systemd is ~12 MB, wouldn’t we loose most of it?
19:54:42 <t8m> I am +1
19:54:57 <mitr> dgilmore: Just /usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb is > 2 MB
19:55:02 <sgallagh> Frankly, I don't see any downside to this.
19:55:37 <dgilmore> mitr: perhaps.
19:55:40 <sgallagh> I think it's up to zbyszek if he wants to diverge from upstream's wishes here.
19:55:47 <sgallagh> It's a distro packaging decision.
19:55:49 <nirik> I'm going to vote +0. I don't think the change is worth it, so I would vote -1, but I agree with mitr we shouldn't override maintainers on things they want to do as they know their package best.
19:55:51 <sgallagh> I'm +1
19:55:54 <dgilmore> it seems that the name for the proposed subpackage is not optimal
19:56:01 <dgilmore> perhaps systemd-core is better
19:56:22 <zbyszek> dgilmore: It's the opposite of "core"
19:56:22 <dgilmore> I guess systemd-units was chosen due to previous usage
19:56:25 <mitr> dgilmore: This is _not_ core; it is specifically _the_ package we used to have, for scriptlets that deal with units.
19:56:28 <sgallagh> dgilmore: I think the shed should be yellow. Or maybe green....
19:56:32 <nirik> so, we are at -3/+3/
19:56:41 <mitr> dgilmore: It is not supposed to be useful in the way @core is useful.
19:57:31 <dgilmore> zbyszek: so what deps do you think would get dropped?
19:58:02 <kalev> I have to leave in 2 minutes, sorry
19:58:16 <dgilmore> I need to leave in about 7
19:58:31 <zbyszek> dgilmore: http://paste.fedoraproject.org/176989/14224750
19:59:05 <dgilmore> zbyszek: what is what?
19:59:25 <zbyszek> It's the addition over -units.
19:59:35 <dgilmore> zbyszek: which means what
19:59:36 <zbyszek> (+ is full systemd + systemd-libs)
20:00:03 <dgilmore> zbyszek: most of those things in the + are always installed
20:00:05 <zbyszek> Things with + are the things which fall out.
20:00:43 <zbyszek> dgilmore: In a full system, not in a minimal one, I think.
20:00:59 <dgilmore> zbyszek: systemd-libs is in the minimal buildroot
20:01:06 <nirik> so, we don't have enough votes to pass or fail here... what do we want to do? punt and revisit next week? ask for more info? just not approve?
20:01:23 <dgilmore> you need ld-linux-x86-64.so.2()(64bit) libgcc_s.so.1()(64bit) etc
20:01:29 <dgilmore> i am -1
20:01:34 <dgilmore> still
20:01:55 <zbyszek> I'm fine with dropping this, if people don't see usefulness.
20:02:15 <dgilmore> zbyszek: not that I do not see the usefulness. I do not see the gain
20:02:26 <edgates> .fas edgates
20:02:27 <zodbot> edgates: edgates 'Elijah Hanson' <pkwesihanson@yahoo.com>
20:02:37 <nirik> zbyszek: well, it doesnt seem to have votes to pass...
20:02:39 <dgilmore> zbyszek: show me a useable minimal system without most of those things that will get dropped out
20:02:42 <jwb> -1
20:03:46 <nirik> so, I think thats -4, +3, 1 0.
20:03:52 <mitr> dgilmore: Consider a container for a single processs (i.e. no systemd running inside): definitely doesn’t need acl, diffutils, kmod, elfutils, sed, PAM)
20:03:57 <dgilmore> zbyszek: i.e. what would be the gains in say a docker base image
20:04:31 <zbyszek> dgilmore: I can't answer that right now, sorry.
20:04:55 <nirik> zbyszek: if we revisit next week, can you gather that?
20:05:04 <zbyszek> Sure.
20:05:07 <nirik> I don't know if it would change any votes, but who knows.
20:05:21 <zbyszek> I'll post to the ticket.
20:05:27 <dgilmore> zbyszek: thanks
20:05:37 <nirik> #info will gather more info and revisit next week
20:05:38 * dgilmore needs to go
20:05:49 <nirik> #topic Next weeks chair
20:05:53 <nirik> who wants the chair next week?
20:06:05 <sgallagh> I will not be able to make it next week, most likely.
20:06:12 <jwb> nor i
20:06:27 <sgallagh> I'll be in Brno for DevConf and associated meetings and pub nights.
20:06:34 <jwb> i doubt dgilmore or mattdm will either
20:06:58 <sgallagh> Hmm, I wonder if we'll have a quorum for all these deferred Change decisions
20:07:07 <nirik> dunno
20:07:15 <t8m> I will be in Brno for Devconf too and I won't be FESCo member after that? As the elections will be done by then?
20:07:58 <drago01> do the meeting at devconf?
20:07:59 <nirik> results are scheduled for the 4th.
20:08:09 <nirik> (ie, next week, but not sure when)
20:08:19 <walters> mitr, indeed
20:08:37 <nirik> actually no, it will be after the meeting...
20:10:38 <nirik> so, sounds like we may have no quorum next week.
20:10:41 <mitr> drago01: Various (= many) Red Hatters will be meeting in the Brno office before devconf, and the schedule isn’t yet set well enough to know who will be available next week; historical experience suggests low likelihood.
20:10:44 <nirik> but we need a chair for week after?
20:11:01 * nirik would like to end this meeting someday.
20:11:11 <drago01> mitr: ok
20:11:58 <mitr> drago01: (the meeting _starts_ at 7pm Central European time; it is >9 pm now)
20:12:20 <drago01> mitr: (fwiw I am in CET right now ;))
20:12:52 <nirik> proposal: no meeting next week, someone agrees to chair the week after?
20:13:02 <nirik> of course we have a new fesco then. sigh.
20:13:36 <mitr> I guess I can take the Feb 11 meeting.
20:14:00 <mitr> And +1 to no meeting next week; let’s try to resolve items in the tickets directly.
20:14:21 <nirik> mitr: thanks.
20:14:28 <nirik> #info no meeting next week.
20:14:37 <nirik> #info mitr to chair feb 11th meeting
20:14:42 <nirik> #topic Open Floor
20:14:50 <nirik> Anyone have items for open floor?
20:15:17 <t8m> So good bye to all FESCo members. As I am ending my membership for now.
20:15:29 <nirik> t8m: been great working with you on fesco. ;)
20:15:33 <nirik> Oh, reminder...
20:15:45 <nirik> #info everyone should go vote in fesco elections (now open)
20:16:17 <t8m> It was great time and perhaps I'll return later. :)
20:16:49 <sgallagh> I'm working on publishing the FESCo interviews on Magazine right now
20:16:54 * nirik will end the meeting in a minute if nothing else.
20:16:56 <sgallagh> (jreznik and I are splitting the work)
20:17:34 <nirik> cool.
20:18:07 <nirik> Thanks for coming everyone.
20:18:10 <nirik> #endmeeting