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