18:00:11 #startmeeting FESCO (2015-05-20) 18:00:11 Meeting started Wed May 20 18:00:11 2015 UTC. The chair is ajax. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:11 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:11 #meetingname fesco 18:00:11 The meeting name has been set to 'fesco' 18:00:11 #chair ajax dgilmore jwb mitr nirik paragan rishi thozza sgallagh 18:00:11 Current chairs: ajax dgilmore jwb mitr nirik paragan rishi sgallagh thozza 18:00:15 #topic init process 18:00:20 morning 18:00:34 .hello sgallagh 18:00:35 sgallagh: sgallagh 'Stephen Gallagher' 18:00:42 (waiting a moment for people to join) 18:01:16 Hi 18:02:05 hi all 18:03:16 hi! 18:03:18 * mattdm lurks 18:03:54 i count five, which is a majority, but perhaps not quorum? 18:04:22 ajax: five is quorum 18:04:29 oh indeed 18:04:39 Though it means that any decision made has to be unanimous 18:04:42 it just becomes concensus :) 18:04:54 Which we always strive for anyway 18:05:06 well, let's start and people can catch up 18:05:10 #topic #1441 Packaging: Practices for Migration of cron jobs to systemd timer units 18:05:17 .fesco 1441 18:05:18 ajax: #1441 (Packaging: Practices for Migration of cron jobs to systemd timer units) – FESCo - https://fedorahosted.org/fesco/ticket/1441 18:05:36 hey 18:05:39 hi 18:06:09 The bottom line is if we want to handle timer units any different from other types of units 18:06:36 it makes migration from cron jobs more painful, but it keeps the defaults more consistent 18:06:36 I guess the conclusion we came to was... no? 18:06:41 So, the only problem with the centrally-managed presets is third-party software. Are such packages just expected to manage themselves in %post? 18:07:23 I think as long as they are not included in Fedora repos, do we care? 18:07:30 they should ship their own preset file 18:07:37 thozza: Well, COPR makes the question fuzzy 18:08:18 lnykryn: https://fedorahosted.org/fesco/ticket/1441#comment:17 18:08:19 sgallagh: right, but those packages can do stuff that does not completely comply to packaging guidelines 18:08:42 thozza: Right, but I'd still like to have recommendations exist on how to behave 18:09:13 ok, I'm not opposed to that, however I was more concerned about the packages included in Fedora repos 18:09:14 lnykryn: Short version: a package shipping its own preset is fundamentally identical to managing itself in %post 18:09:21 I'd say they handle it in %post yeah 18:09:25 sgallagh: it is not 18:09:27 Because the admin can't configure it before the package is installed 18:09:57 admin can still deny for all unit files to enable themselfs 18:10:16 lnykryn: No, because %post can just call 'systemctl enable' 18:10:26 It's running as root 18:10:39 sgallagh: I think lnykryn means the situation with own presets 18:10:43 I was speaking about the case where package ship its own unit file and calls preset 18:10:57 lnykryn: Can that be restricted? 18:11:15 sgallagh: sure we are looking for the first match 18:11:27 so you can ship conf with lower number and some glob 18:11:35 lnykryn: the package can install preset that will be first 18:11:45 sure it can 18:12:05 but that is a corner case 18:12:12 I'm not sure that helps too much really. 18:12:24 so in the end it depends how the preset file is named 18:12:33 yes they are numbered 18:12:37 Also, putting a glob early in the process will likely break everything else :( 18:12:51 if you know what you are doing ... 18:13:45 well, if we are talking about packages not in fedora, who knows... they can do anything at all. 18:13:48 so to make use of own presets in comparison to %post, the admin would have to do things, that would most probably break his system 18:13:50 Yeah 18:14:20 I think that his is kind of out of scope to decide 18:14:21 no there is still the use-case that admin wants to have every new service disabled by default 18:14:38 lnykryn: which we just discussed 18:15:00 lnykryn: Right, but I don't think it's actually possible to do that (reliably) just with presets. 18:15:02 unless everyone agrees to some convention there, it's not likely to work 18:15:10 I think that would need to be a different systemd feature\ 18:15:29 i mean, systemd controls the world, it could shove rpm into a cgroup where systemctl enable didn't work. 18:15:36 right? 18:15:54 but failing that i think some spec convention and qa assurances are the best we can do 18:15:57 or you could install your new stuff with --noscripts. ;) 18:16:09 but I think we are going far afield 18:16:11 nirik: No one would do that. 18:16:16 so back to timer units ;) 18:16:17 I like ajax's idea though 18:16:37 right. is there a concrete proposal we should be debating for timer units? 18:17:16 personally I don't think that it would be that bad to allow to ship own preset for timer unit in some cases is bad thing... however since we moved presets to fedora-release things may work better now 18:18:01 OK, so first proposal: 18:18:05 * thozza reading what I wrote... I think I changed the idea in the middle of sentence 18:18:06 :) 18:18:17 Proposal: Timer units' default state should be managed by the system presets 18:18:26 (Not by the packages installing them) 18:18:51 ok. +1ish 18:19:17 +1 18:19:17 I agree to some extent 18:19:29 Let me rephrase 18:19:59 Proposal: For packages in the Fedora collection, the default state of their timer units should be managed by the system presets and not by the packages that contain them. 18:20:40 sure. +1 18:20:49 in case it will not take a month to get unit into presets ;) 18:20:57 * nirik is hoping adding to presets will be reasonably responsive 18:20:57 +1 18:20:59 yeah. 18:21:36 sorry if I missed in above discussion but can someone tell what is problem if individual packages allowed to change default state? 18:21:49 dgilmore: Did you end up making that its own repository or as part of fedora-release/generic-release? 18:22:03 paragan: consistency of expectations for the admin, aiui 18:22:07 paragan: https://fedorahosted.org/fesco/ticket/1441#comment:17 18:22:36 ah okay 18:23:05 +1 to sgallagh proposal 18:23:37 dgilmore: s/that/presets/ and s/repository/package/ 18:24:18 I think that we may want to have that be its own package with multiple maintainers rather than fedora-release which is painful to keep updated. 18:24:31 (Also, probably a dist-git hosted package rather than an upstream) 18:24:37 sgallagh: I think that would speed up the process 18:24:54 (by the way we already have this process in rhel and redhat-release) 18:25:31 lnykryn: I think we are talking about completely separate component 18:25:45 i count 4 votes (me, nirik, paragan, sgallagh implicitly transferring his +1 to his clarification) 18:25:53 sgallagh: its just in fedora-release 18:25:58 thozza: that was just a mention 18:26:10 sgallagh: I am going to duplicate into generic-release 18:26:26 I will be +1 if we make the process reasonably easy 18:26:27 * nirik notes we should get anything we decide codified/approved by FPC too. 18:26:38 nirik: Agreed 18:26:43 moving presets to fedora-release is a good step 18:27:15 well, i'm not a fortune teller, but i expect products to actively participate 18:27:15 I am +1 to having timers default state in system wide preset files 18:27:17 dgilmore: My recommendation is that we split it out of fedora-release and make it into fedora-presets where we can have a number of maintainers with access (without risking the stability of fedora-release_ 18:27:55 Maybe give commit privilege to fedora-presets to FESCo and WG liasons 18:28:01 sgallagh: honestly do not really care. as is I think it is fine, it should be very manageable upstream will pull requests 18:28:12 ok 18:28:30 we can split it if it turns out to be better long term? 18:28:35 Sure, I'm okay with leaving it as-is and revisiting if the process becomes bogged down 18:28:53 #agreed packages in fedora have their default timer unit settings managed by system presets and not by their providing package (+6, -0) 18:29:07 I'm also OK with revisiting if needed and keeping it as is for now ~ in fedora-release 18:29:25 #info timer unit settings recommendation to be double-checked with fpc 18:29:31 someone want to handle taking this to fpc? 18:29:41 /me volunteers 18:29:47 https://fedoraproject.org/wiki/Starting_services_by_default also should be updated to reflect new reality. Apart from the obvious s/systemd/fedora-release/, both services and timers which require or not FESCo exception need to go through the global presets file. 18:30:04 zbyszek: Yes, thanks. I'll open an FPC ticket for that as well 18:30:13 #info sgallagh to bring timer unit issue to fpc 18:30:16 sgallagh: thanks 18:30:17 #action sgallagh to work with FPC on updating https://fedoraproject.org/wiki/Starting_services_by_default 18:30:29 * nirik has a timer to submit too. ;) 18:30:38 zbyszek: I think we could generalize to any type of unit 18:30:39 nirik: Is it the end-of-meeting-timer? 18:30:44 just about! 18:30:48 #topic Open Floor 18:30:59 ha. :) spamassassin's sa-update... but sure. ;) 18:31:26 there were a couple of other fesco tickets more recent than 1441 18:31:35 thozza: yes, it applies to .sockets and anything else which can activate services... 18:31:47 which mostly look like they can be handled in the ticket 18:31:52 zbyszek: lnykryn mentioned e.g. path units and so on... 18:32:01 ajax: we need a next weeks chair selection too. 18:32:09 so, if'n people can take a look at the fesco trac, that'd be super 18:32:16 nirik: indeed. volunteers? 18:32:54 I've not done it for a bit, I can. 18:33:08 #action nirik to chair next week 18:33:13 nirik: thanks 18:33:33 if there are no other open issues i'll close out in a couple minutes 18:34:13 Just a general note: RC1 looked quite good, but we had one blocker necessitating a respin tonight. 18:34:29 hopefully RC2 will be a keeper. 18:34:40 So this is a general request for people to help test RC2; we expect it to be Go tomorrow at the meeting. 18:34:44 Here's hoping. 18:36:46 * mattdm hopes that the ext4 issue making the blog rounds turns out to be not a serious thing 18:37:14 yeah. Infomation on it is so sketchy. 18:37:28 I have trouble caring. I run XFS :-D 18:37:52 (I'm kidding of course; I hope this doesn't bite us, but the timing is suboptimal) 18:38:08 We probably won't know for certain how bad this is until it's too late to stop the machinery. 18:38:42 yeah 18:39:05 it's not super common or we would have seen more reports... or... well, almost any 18:39:18 RC2 is well underway 18:39:28 it should be out this evening US time 18:39:39 afaik it affects mdadm raid — that just might not have been common enough, or in the right triggering config — to get enough exposure 18:40:16 or people who are testing f22 are already running 4.0.4 from updates-testing and it's already fixed 18:40:19 WHO KNOWS 18:40:20 mattdm: I have a machine using raid with the 'affected' kernel with 0 problems 18:40:29 talking about it more isn't going to result in anything useful at this point 18:40:36 * nirik nods. stops 18:40:42 hey, we're running off the rails! 18:40:55 * mattdm is sorry 18:41:00 does that make this a crazy train? ;) 18:41:01 so please be testing RC2 when it is out 18:41:03 if you want #fedora-devel you know where to find it ;) 18:41:13 #info Please test RC2! 18:41:26 thanks all 18:41:28 #endmeeting