#fedora-meeting: FESCO (2015-01-28)
Meeting started by nirik at 18:02:12 UTC. The full logs are available at
* init process (nirik, 18:02:12)
* ticket #1326 change to fesco replacement process? (nirik, 18:05:23)
* LINK: https://fedorahosted.org/fesco/ticket/1326
* will table this for now and discuss more as time permits. (nirik,
* ticket #1392 Review scope of "Python 3 as default" Change for F22
* LINK: https://fedorahosted.org/fesco/ticket/1392
* AGREED: defer this to F23, file bugs against rawhide after branch
(+6,0,0) (nirik, 18:25:38)
* ticket #1393 Making perl-sig a watcher on all perl packages (nirik,
* LINK: https://fedorahosted.org/fesco/ticket/1393
* 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)
* ticket #1394 Use timedatex when an NTP package is installed (nirik,
* LINK: https://fedorahosted.org/fesco/ticket/1394
* AGREED: This use is approved (+6,0,0) (nirik, 18:51:23)
* ticket #1407 F22 System Wide Change: Vagrant Box for Fedora Atomic and
Fedora Cloud -
* LINK: https://fedorahosted.org/fesco/ticket/1407
* AGREED: Change is approved (+5,0,0) (nirik, 19:04:22)
* ticket #1374 F22 Self Contained Changes (nirik, 19:04:44)
* LINK: https://fedorahosted.org/fesco/ticket/1374
* AGREED: All self contained changes approved (+9,0,0) (nirik,
* ticket #1390 F22 System Wide Change: RpmOstree - Server side composes
and atomic upgrades - (nirik, 19:07:12)
* LINK: https://fedoraproject.org/wiki/Changes/RpmOstree
* LINK: https://fedorahosted.org/fesco/ticket/1390
* LINK: https://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image
the f21 change? (nirik, 19:11:21)
* will revisit next week (nirik, 19:22:45)
* ticket #1396 F22 System Wide Change: Atomic Host -
* LINK: https://fedorahosted.org/fesco/ticket/1396
* AGREED: will revisit next week (+5,0,0) (nirik, 19:27:34)
* ticket #1397 F22 System Wide Change: Bare Metal Installer for Fedora
Atomic Host - https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic
* LINK: https://fedorahosted.org/fesco/ticket/1397
* AGREED: will revisit next week (+6,0,0) (nirik, 19:29:15)
* ticket #1398 F22 System Wide Change: Database Server Role -
* LINK: https://fedorahosted.org/fesco/ticket/1398
* AGREED: Change is approved (+8,0,0) (nirik, 19:30:45)
* ticket #1399 F22 System Wide Change: Django18 -
* LINK: https://fedorahosted.org/fesco/ticket/1399
* AGREED: Change is approved (+8,0,0) (nirik, 19:32:45)
* ticket #1400 F22 System Wide Change: Glibc Unicode 7.0 -
* LINK: https://fedorahosted.org/fesco/ticket/1400
* AGREED: Change is approved (+8,0,0) (nirik, 19:33:45)
* ticket #1401 F22 System Wide Change: GNOME 3.16 -
* LINK: https://fedorahosted.org/fesco/ticket/1401
* AGREED: Change is approved (+8,0,0) (nirik, 19:34:51)
* ticket #1402 F22 System Wide Change: Plasma 5 -
* LINK: https://fedorahosted.org/fesco/ticket/1402
* AGREED: Change is approved (+8,0,0) (nirik, 19:36:14)
* ticket #1403 F22 System Wide Change: Login Screen Over Wayland -
* LINK: https://fedorahosted.org/fesco/ticket/1403
* AGREED: Change is approved (+7,0,0) (nirik, 19:39:27)
* ticket #1404 F22 System Wide Change: Enable Polyinstantiated /tmp and
/var/tmp directories by default -
* LINK: https://fedorahosted.org/fesco/ticket/1404
* AGREED: This change is not approved as written (-6,0,0) (nirik,
* ticket #1405 F22 System Wide Change: python-dateutil 2.x -
* LINK: https://fedorahosted.org/fesco/ticket/1405
* AGREED: Change is approved (+8,0,0) (nirik, 19:49:27)
* ticket #1406 F22 System Wide Change: Systemd Package Split -
* will gather more info and revisit next week (nirik, 20:05:37)
* Next weeks chair (nirik, 20:05:49)
* no meeting next week. (nirik, 20:14:28)
* mitr to chair feb 11th meeting (nirik, 20:14:37)
* Open Floor (nirik, 20:14:42)
* everyone should go vote in fesco elections (now open) (nirik,
Meeting ended at 20:18:10 UTC.
Action Items, by person
People Present (lines said)
* nirik (236)
* dgilmore (136)
* sgallagh (85)
* mitr (81)
* jwb (60)
* t8m (59)
* kalev (36)
* zodbot (30)
* zbyszek (24)
* walters (17)
* adamw (7)
* mclasen (5)
* roshi (3)
* Corey84 (3)
* drago01 (3)
* randomuser (2)
* mlichvar (1)
* eseyman (1)
* mattdm (1)
* edgates (1)
* thozza (0)
* mmaslano (0)
* stickster (0)
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'
18:04:20 <nirik> cool. We have a long agenda today so I guess we should get
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 -
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
18:10:43 <nirik> sgallagh: I'm ok with it, but perhaps after branch and
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
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
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
18:15:28 <adamw> (but obviously if that Change gets pushed out, this page should be
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
18:16:06 <jwb> because if not, then we punt this to F23 and we can stop talking
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
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
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
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
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
18:20:43 <jwb> i'm not disagreeing with you. i'm asking you what we need to
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
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
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
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
18:25:38 <zodbot> Corey84: corey84 'Corey84'
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
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
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
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
18:28:11 <t8m> nirik, I suppose they did not want to manually go through all the
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
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
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
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
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
18:42:17 <zbyszek> sgallagh: compile time default, overridable in config file, or
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
18:43:29 <zbyszek> sgallagh: Sorry, I meant that the compile time default is set to
or something like that, and in addition it can be overriden by
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
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
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
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:
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
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,
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
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:
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 -
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 -
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
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
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
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
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
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
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
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,
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
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
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
19:22:23 <nirik> perhaps dgilmore and walters could hash out some changes before
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 -
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 -
) – FESCo -
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
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,
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)
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 -
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 -
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 -
) – FESCo -
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 -
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 -
) – FESCo -
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 -
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 -
) – FESCo -
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 -
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 -
) – FESCo -
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 -
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 -
) – FESCo -
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 -
) – FESCo -
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 -
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
19:39:55 <zodbot> nirik: #1404 (F22 System Wide Change: Enable Polyinstantiated /tmp
and /var/tmp directories by default -
) – FESCo -
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
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
19:48:01 <dgilmore> re-evaluate down the road
19:48:12 <nirik> #topic ticket #1405 F22 System Wide Change: 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 -
) – FESCo -
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 -
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 -
) – FESCo -
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
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
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
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
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 >
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
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
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)
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
20:02:15 <dgilmore> zbyszek: not that I do not see the usefulness. I do not see the
20:02:26 <edgates> .fas edgates
20:02:27 <zodbot> edgates: edgates 'Elijah Hanson'
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,
20:03:57 <dgilmore> zbyszek: i.e. what would be the gains in say a docker base
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
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
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
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
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
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
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