Following is the list of topics that will be discussed in the FESCo meeting Friday at 16:00UTC in #fedora-meeting on irc.freenode.net.
To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto
or run: date -d '2016-07-29 16:00 UTC'
Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9
= Followups =
#topic #1600 F25 System Wide Change: KillUserProcesses=yes by default .fesco 1600 https://fedorahosted.org/fesco/1600
= New business =
#topic #1568 F25 Self Contained Changes .fesco 1568 https://fedorahosted.org/fesco/ticket/1568
#topic #1602 dvgrab, non-responsive maintainer .fesco 1602 https://fedorahosted.org/fesco/ticket/1602
#topic #1603 scons, non-responsive maintainer for epel builds .fesco 1603 https://fedorahosted.org/fesco/ticket/1603
#topic #1604 wise2, non-responsive maintainer .fesco 1604 https://fedorahosted.org/fesco/ticket/1604
#topic #1605 finish retirement of sysvinit-only packages .fesco 1605 https://fedorahosted.org/fesco/ticket/1605
#topic #1606 f25 approved Changes not in MODIFIED status (considered as not testable) .fesco 1606 https://fedorahosted.org/fesco/ticket/1606
#topic #1607 Orphan package for "patches" .fesco 1607 https://fedorahosted.org/fesco/ticket/1607
= Open Floor =
For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.
=================================== #fedora-meeting: FESCO (2016-07-29) ===================================
Meeting started by nirik at 16:00:03 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2016-07-29/fesco.2016-07-29... .
Meeting summary --------------- * init process (nirik, 16:00:03)
* #1600 F25 System Wide Change: KillUserProcesses=yes by default (nirik, 16:05:09) * LINK: https://fedorahosted.org/fesco/1600 (nirik, 16:05:10) * AGREED: accept sgallagh's proposal from https://fedorahosted.org/fesco/ticket/1600#comment:17 (+7,0,0) (nirik, 16:17:38)
* #1568 F25 Self Contained Changes (nirik, 16:17:58) * LINK: https://fedorahosted.org/fesco/ticket/1568 (nirik, 16:17:59) * AGREED: nodejs6 change is approved. (+6,0,0) (nirik, 16:19:45)
* #1602 dvgrab, non-responsive maintainer (nirik, 16:20:38) * LINK: https://fedorahosted.org/fesco/ticket/1602 (nirik, 16:20:38) * AGREED: orphan packages in 4 maintainer tickets (+6,0,0) (nirik, 16:24:29)
* #1605 finish retirement of sysvinit-only packages (nirik, 16:24:51) * LINK: https://fedorahosted.org/fesco/ticket/1605 (nirik, 16:24:51) * AGREED: retire packages on list aside nagios (which must be fixed by alpha) and opentracker (+6,0,0) (nirik, 16:33:43)
* #1606 f25 approved Changes not in MODIFIED status (considered as not testable) (nirik, 16:34:35) * LINK: https://fedorahosted.org/fesco/ticket/1606 (nirik, 16:34:36) * AGREED: ask FPM to follow recommendations in comment2 and revisit next meeting for items we deferred (+6,0,0) (nirik, 16:43:24)
* Next meeting chair (nirik, 16:44:10) * sgallagh to chair on aug 12th (nirik, 16:47:31)
* Open Floor (nirik, 16:47:35) * LINK: https://flock2016.sched.org/event/7mOO/prd-workshop (sgallagh, 16:49:43)
Meeting ended at 16:54:27 UTC.
Action Items ------------
Action Items, by person ----------------------- * **UNASSIGNED** * (none)
People Present (lines said) --------------------------- * nirik (86) * sgallagh (66) * Rathann (29) * paragan (18) * jwb (18) * zodbot (14) * jsmith (13) * zbyszek (7) * kalev (0) * rathann (0) * maxamillion (0) * dgilmore (0) -- 16:00:03 <nirik> #startmeeting FESCO (2016-07-29) 16:00:03 <zodbot> Meeting started Fri Jul 29 16:00:03 2016 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:03 <zodbot> The meeting name has been set to 'fesco_(2016-07-29)' 16:00:03 <nirik> #meetingname fesco 16:00:03 <nirik> #chair maxamillion dgilmore jwb nirik paragan jsmith kalev sgallagh rathann 16:00:03 <nirik> #topic init process 16:00:03 <zodbot> The meeting name has been set to 'fesco' 16:00:03 <zodbot> Current chairs: dgilmore jsmith jwb kalev maxamillion nirik paragan rathann sgallagh 16:00:36 <sgallagh> .hello sgallagh 16:00:37 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' sgallagh@redhat.com 16:01:32 <paragan> .hello pnemade 16:01:33 <zodbot> paragan: pnemade 'Parag Nemade' pnemade@redhat.com 16:02:16 <nirik> well, thats 3 of us... will wait a bit more and see if we reach quorum. 16:02:22 <jsmith> .hello jsmith 16:02:23 <zodbot> jsmith: jsmith 'Jared Smith' jsmith.fedora@gmail.com 16:02:41 <jwb> sorry for being late 16:02:54 <nirik> no worries. 16:03:20 <nirik> ok, thats 5, so we can go ahead... 16:03:23 <jsmith> I think that gives a quorum 16:03:38 <paragan> yes :) 16:04:01 <nirik> So, we have a newly elected fesco... I'd like to thank number80 for all his service on the last fesco and welcome rathann 16:04:13 <nirik> should we do a new whenisgood for a new time? 16:04:32 <sgallagh> nirik: Why don't we just ask rathann first. 16:04:46 <nirik> sure, although he appears not to be here today. ;) 16:04:50 <nirik> so, lets move on then... 16:04:51 * jsmith still prefers Fridays, as those are typically the only days he has access to IRC 16:05:01 * paragan also fine with current timing 16:05:09 <nirik> #topic #1600 F25 System Wide Change: KillUserProcesses=yes by default 16:05:10 <nirik> .fesco 1600 16:05:10 <nirik> https://fedorahosted.org/fesco/1600 16:05:11 <zodbot> nirik: #1600 (F25 System Wide Change: KillUserProcesses=yes by default) – FESCo - https://fedorahosted.org/fesco/ticket/1600 16:05:23 <nirik> sgallagh put a more concrete proposal in this morning. 16:05:27 <jwb> the list looks fine to me 16:05:29 <nirik> .fesco 1600 16:05:30 <zodbot> nirik: #1600 (F25 System Wide Change: KillUserProcesses=yes by default) – FESCo - https://fedorahosted.org/fesco/ticket/1600 16:05:50 <nirik> zbyszek: you thoughts ? ^ 16:06:30 <zbyszek> screen and tmux are obviously fine. 16:06:50 <zbyszek> nohup and disown can be shell builtins, and I'm not sure if they can be redefined. 16:07:06 <zbyszek> (or should rather) 16:07:10 <sgallagh> I'll admit that I didn't have the time to do an in-depth look into nohup and disown before creating the list. 16:07:22 <sgallagh> However given that their obvious purpose is to do exactly this... 16:07:34 <sgallagh> (survive a session) 16:07:55 <nirik> well, with nohup there's a standalone, which I think all the shells use now a days (but I could be wrong) 16:08:01 <nirik> disown could be a lot harder 16:08:01 <zbyszek> Right, but there's always the option of redirecting people to a differnt-but-equivalent comamdn. 16:08:02 <Rathann> hi, I'm here, sorry 16:08:21 <nirik> morning Rathann. ;) Is this time ok for you? or should we try and find a better one? and welcome. 16:08:31 <Rathann> no, it's fine 16:08:36 <sgallagh> if nohup is standalone, then I think it's reasonable to leave it Tier 1 (even if we end up making downstream changes). 16:08:39 <Rathann> it's actually late afternoon for me 16:08:55 <nirik> well, the man page apparently tells me I am wrong. 16:09:13 <zbyszek> Yeah, I think the list of Tier 1 is good. 16:09:14 <nirik> "NOTE: your shell may have its own version of nohup, which usually supersedes the version described here." 16:10:24 <nirik> I'm personally fine with the list/proposal. Shall we vote then? or anything else to discuss? 16:11:21 <nirik> Oh, one addon: Should we set it to 'yes' in rawhide? That might gather some small amount more feedback as well. 16:11:56 <jwb> I think so 16:12:04 <jsmith> I'm OK with it 16:12:08 <paragan> any timeline for Tier 1 and 2? 16:12:09 <nirik> proposal: accept sgallagh's proposal from https://fedorahosted.org/fesco/ticket/1600#comment:17 16:12:18 <jwb> +1 16:12:22 <nirik> +1 16:12:51 <sgallagh> paragan: Tier 1 has to be complete or we enact the Contingency Plan 16:12:57 <sgallagh> I think we said Beta Freeze for that 16:13:02 <sgallagh> /me checks 16:13:11 <sgallagh> Yes 16:13:21 <paragan> okay +1 16:13:33 <sgallagh> Tier 2 are things that we will file bugs on and mark in Common Bugs but don't need to have a timeframe attached 16:14:16 <sgallagh> +1 from me for the record 16:14:20 <jsmith> +1 from me 16:14:36 <nirik> Rathann: ? Or just catching up. ;) 16:15:04 <Rathann> actually I'm still undecided 16:15:10 <Rathann> so 0 from me 16:15:28 <Rathann> I'm not completely sold on the change 16:15:29 <sgallagh> Rathann: Before tallying, could you say what makes you hesitate? 16:16:26 <sgallagh> Rathann: The Change itself was already approved by the previous FESCo; this is just hashing out the conditions for completion. 16:16:44 <Rathann> ah 16:17:11 <Rathann> ok, +1 for the conditions, then 16:17:38 <nirik> #agreed accept sgallagh's proposal from https://fedorahosted.org/fesco/ticket/1600#comment:17 (+7,0,0) 16:17:42 <sgallagh> (meaning if the Tier 1 stuff isn't ready by Beta Freeze, the default stays "no" on F25 and we revisit in F26) 16:17:54 <Rathann> right 16:17:58 <nirik> #topic #1568 F25 Self Contained Changes 16:17:59 <nirik> .fesco 1568 16:17:59 <nirik> https://fedorahosted.org/fesco/ticket/1568 16:17:59 <zbyszek> Thanks sgallagh. 16:18:00 <zodbot> nirik: #1568 (F25 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1568 16:18:26 <nirik> this is just nodejs6 16:18:31 <nirik> which is already done even. 16:18:33 <nirik> +1 16:18:45 <jwb> +1 16:18:47 <paragan> +1 16:18:54 <Rathann> +1 16:19:02 <jsmith> +1 16:19:02 <sgallagh> Yeah, sorry for the late proposal. I thought I had filed it months ago. 16:19:12 <sgallagh> Biased +1 16:19:18 <jsmith> sgallagh: You did all the work, so we'll forgive you :-) 16:19:36 <sgallagh> :) 16:19:45 <nirik> #agreed nodejs6 change is approved. (+6,0,0) 16:20:38 <nirik> #topic #1602 dvgrab, non-responsive maintainer 16:20:38 <nirik> .fesco 1602 16:20:38 <nirik> https://fedorahosted.org/fesco/ticket/1602 16:20:40 <zodbot> nirik: #1602 (dvgrab, non-responsive maintainer) – FESCo - https://fedorahosted.org/fesco/ticket/1602 16:21:03 <sgallagh> Do we want to just do all of them together, or do we expect discussion? 16:21:59 <sgallagh> Maybe rephrased: Does anyone have anything to say against following the non-responsive maintainerpolicy for any of these people? 16:22:16 * jsmith has nothing 16:22:21 <nirik> yeah, we have 4 of them 16:22:39 * nirik thinks again we should have a better process, but I keep not having time to propose something. ;) 16:22:40 <jwb> I don't 16:22:41 <sgallagh> They are dvgrab, scons, wise2 and patches 16:22:55 <jwb> +1 to all 16:22:58 <paragan> I am +1 to orphan all of 4 requests 16:23:09 <sgallagh> +1 to orphaning all 4 16:23:10 * nirik is also +1 to all 16:23:25 <jsmith> +1 to all four, for the record 16:23:50 <Rathann> +1 to all 16:24:14 * Rathann notes he needs wise2 as a dependency so he'll probably grab it if nobody beats him to it 16:24:29 <nirik> #agreed orphan packages in 4 maintainer tickets (+6,0,0) 16:24:35 <nirik> I'll do the orphaning after the meeting 16:24:46 <sgallagh> Thanks nirik 16:24:51 <nirik> #topic #1605 finish retirement of sysvinit-only packages 16:24:51 <nirik> .fesco 1605 16:24:51 <nirik> https://fedorahosted.org/fesco/ticket/1605 16:24:56 <zodbot> nirik: #1605 (finish retirement of sysvinit-only packages) – FESCo - https://fedorahosted.org/fesco/ticket/1605 16:25:43 <sgallagh> So the proposal I made in the ticket was: 16:25:46 <jwb> I think we should process all of these now 16:25:50 <nirik> I'm fine with the list (once opentracker and nagios are removed). We should announce and possibly mail owners and give them a last week 16:26:03 <sgallagh> Retire all of the remaining sysv-only packages immediately after Flock with a final reminder warning. 16:26:08 <nirik> yeah, I guess there has been lots and lots of time 16:26:17 <jwb> Why after Flock? 16:26:21 <sgallagh> But yeah, we were supposed to do this six months ago 16:26:25 <paragan> +1 to retire all those packages 16:26:40 <sgallagh> jwb: Mostly just to give that last week, then a few days to account for the people who have to do it mostly being at Flock 16:26:50 <jwb> Seems like an unnecessary delay where we'll forget again 16:26:54 <Rathann> +1 16:27:16 <sgallagh> jwb: If you want to hit the button today, I'll +1 that too. 16:27:17 <Rathann> though I think psad also supports systemd now and it's several releases behind upstream 16:27:26 <Rathann> so, also a bug 16:27:28 <nirik> we could orphan them and let them die the normal process... but then someome might bring them back and not fix the sysvinit 16:27:29 <sgallagh> I suppose the worst-case situation is that people have to resubmit for package review 16:28:21 * Rathann will try to fix psad if there's time during Flock ;) 16:28:25 <sgallagh> OK, so let 16:28:29 <sgallagh> 's try this: 16:28:42 <nirik> nagios also needs fixing (I did file a bug) 16:28:46 <sgallagh> Proposal: retire all packages on this list (save opentracker and nagios which have been fixed) immediately. 16:29:02 <sgallagh> A +1 means immediate retirement, a -1 means wait until after Flock. 16:29:08 <sgallagh> But either way, it's happening 16:29:49 <Rathann> does "immediately" mean without a final warning? 16:30:00 <Rathann> I'm sure some people forgot about this 16:30:03 <sgallagh> Rathann: Yes, we *did* give a "final" warning six months ago 16:30:03 <nirik> I'm +1 I guess... lets get it over with, people can unretire if they actually care and hopefully get them fixed in review. 16:30:10 <sgallagh> And then forgot to actually execute on it. 16:30:11 <Rathann> ah 16:30:12 <jwb> we just reminded them like a week ago 16:30:17 <jwb> with the ticket 16:30:22 <jwb> anyway, +1 16:30:24 <paragan> I can help with retiring those packages 16:30:26 <sgallagh> +1 16:30:26 <paragan> +1 16:30:31 <Rathann> ok +1 16:30:51 <Rathann> I can always file an unretirement request or even re-review ticket when I need psad back in Fedora 16:31:21 <sgallagh> nirik: RE: nagios: are you proposing to not retire it? We did leave in a provision for FESCo to grant exceptions. 16:31:38 <sgallagh> Rathann: Yeah, and a new package review is usually a good thing for package health anyway. 16:31:41 <nirik> I would very much prefer we not retire it. 16:31:53 <nirik> I was going to give the maintainer a bit of time then just go fix it. 16:32:24 <sgallagh> Proposal: nagios gets an extension to Alpha Freeze 16:32:36 <nirik> it's a conditional bug. It shipped with a systemd unit since 2013... they just messed something up so it shipped the sysvinit instead 16:32:42 <sgallagh> (Which I am only okay with because nirik is committing to fixing it) 16:33:10 <nirik> so, thats +6 I guess with sgallagh ? 16:33:22 <sgallagh> Right, +1 for the record. 16:33:43 <nirik> #agreed retire packages on list aside nagios (which must be fixed by alpha) and opentracker (+6,0,0) 16:33:55 <nirik> paragan: can you retire them? 16:34:02 <paragan> sure I will 16:34:02 <nirik> I guess we do f25 and rawhide? 16:34:10 <jwb> yes 16:34:11 <sgallagh> Yes 16:34:11 <jsmith> WORKSFORME 16:34:20 <nirik> cool. 16:34:35 <nirik> #topic #1606 f25 approved Changes not in MODIFIED status (considered as not testable) 16:34:36 <nirik> .fesco 1606 16:34:36 <nirik> https://fedorahosted.org/fesco/ticket/1606 16:34:37 <zodbot> nirik: #1606 (F25 approved Changes not in MODIFIED status (considered as not testable)) – FESCo - https://fedorahosted.org/fesco/ticket/1606 16:35:14 <sgallagh> paragan, nirik: Someone should also send out the announcement on devel-announce, if for no other reason than so we can finally say the systemd conversion is complete 16:35:46 <paragan> okay will send an email on devel-announce first 16:35:49 <sgallagh> RE: 1606 - I added my thoughts on each of the Changes to the ticket as https://fedorahosted.org/fesco/ticket/1606#comment:2 16:36:03 <sgallagh> paragan: I didn't say "first", just that it should be announced that it happened. 16:36:12 <paragan> oh okay 16:37:18 <nirik> I find myself agreeing with sgallagh on the changes. ;) 16:37:40 <jsmith> nirik: I was just going to say the same thing, but I didn't want people to think I was just being lazy :-p 16:37:42 <paragan> I too agree with sgallagh comment 16:37:58 <nirik> some of the ones with no response may well be people already traveling to flock... 16:38:04 <sgallagh> I agree with his comments (because I'm too lazy to re-read them) 16:38:53 <sgallagh> The Bodhi one was the only one I think I was unsure about. 16:39:02 <nirik> I am unsure how far along that is... 16:39:17 <sgallagh> But if it's not feature complete already, then I'm wary of the disruption of putting it in place for F25 16:39:20 <Rathann> I read the comments and I concur with sgallagh 16:39:52 <nirik> proposal: ask FPM to follow recommendations in comment2 and revisit next meeting for items we deferred 16:39:54 <sgallagh> (Given that we very intentionally want F25 to be a short cycle) 16:40:04 <nirik> (I'm assuming no meeting next week? so week after?) 16:40:31 <paragan> +1 16:40:37 <sgallagh> nirik: Seems sensible, especially if some stuff gets solved at Flock 16:40:41 <sgallagh> +1 16:40:44 <nirik> +1 16:40:44 <Rathann> +1 16:42:33 <sgallagh> Just so we're clear, this is also following my last comment RE: setting KillUserProcesses=yes in F25 for Alpha? 16:42:43 <Rathann> yes 16:42:48 <nirik> yeah 16:42:59 <sgallagh> /me didn't want that slipping by without notice 16:43:04 <nirik> any other votes? jsmith / jwb 16:43:09 <jwb> +1 16:43:10 <sgallagh> zbyszek: ^^ 16:43:13 <jsmith> +1 16:43:24 <nirik> #agreed ask FPM to follow recommendations in comment2 and revisit next meeting for items we deferred (+6,0,0) 16:44:02 <zbyszek> +1 to setting KillUserProcesses=yes in F25 for Alpha 16:44:10 <nirik> #topic Next meeting chair 16:44:18 <nirik> who wants the hot seat next meeting? 16:44:35 <jwb> so.. 16:44:39 <jwb> when exactly is that? 16:44:45 <jwb> we're skipping next week, right? 16:44:50 <paragan> 12th August I guess 16:44:53 <nirik> yeah, I think so. 16:44:56 <sgallagh> Aug. 12? 16:44:58 <nirik> yep 16:45:14 <Rathann> for the record, I'm on vacation for the next two weeks, so I can't promise I'll attend on Aug 12th 16:45:42 <sgallagh> Rathann: What are you, a Congressman? Win an election, immediately go on vacation. ;-) 16:45:53 <Rathann> LOL 16:45:59 <Rathann> no, Flock is part of that vacation 16:46:24 <sgallagh> If no one else is going to volunteer, I'll chair Aug. 12 16:47:00 <Rathann> thanks, sgallagh 16:47:02 <Rathann> ;) 16:47:23 <nirik> thanks. 16:47:31 <nirik> #info sgallagh to chair on aug 12th 16:47:35 <nirik> #topic Open Floor 16:47:40 <nirik> anyone have anything for open floor? 16:48:20 <sgallagh> nirik: One minor Flock item. 16:48:56 <sgallagh> There's a Flock PRD workshop that's meant to get the PRDs for the various Editions in shape 16:49:18 <sgallagh> It would be best if any FESCo member present and not in another workshop were to attend and lend their expertise. 16:49:43 <sgallagh> #link https://flock2016.sched.org/event/7mOO/prd-workshop 16:50:07 <sgallagh> <EOF> 16:50:25 <nirik> alrighty 16:51:24 * jsmith has to run... thanks everyone! 16:51:37 <nirik> oh, clarification: on those orphanings, am I orphaning just the indicated package, or all the ones from that maintainer? 16:51:47 <nirik> ie, maintainer of dvgrab has several other packages 16:52:15 <sgallagh> Isn't official policy to orphan all of their packages? 16:52:35 <sgallagh> I'd figure doing otherwise should be the exceptional case. 16:52:35 <paragan> orphan all of their packages 16:52:54 <nirik> it's not clear, but yeah, will do 16:53:03 <nirik> ok, will close up in a minute if nothing else 16:53:13 <sgallagh> nirik: Thanks for running the meeting! 16:53:39 <paragan> nirik, Thanks for this meeting 16:54:24 <nirik> no problem. Safe travels to flock for everyone going. 16:54:27 <nirik> #endmeeting
On Sex, 2016-07-29 at 10:55 -0600, Kevin Fenzi wrote:
- #1605 finish retirement of sysvinit-only packages (nirik,
16:24:51) * LINK: https://fedorahosted.org/fesco/ticket/1605%C2%A0%C2%A0 (nirik, 16:24:51) * AGREED: retire packages on list aside nagios (which must be fixed by alpha) and opentracker (+6,0,0) (nirik, 16:33:43)
why we need retire sysvinit-only packages ? is not suppose systemd support sysvinit and why don't you fixed the packages like you will do for nagios ? BTW I'd like keep 2 packages noip and tetrinetx. Shouldn't you give some time or open bug reports before do the retirement ?
why such hurry ?
On Sun, Jul 31, 2016 at 04:18:18AM +0100, Sérgio Basto wrote:
On Sex, 2016-07-29 at 10:55 -0600, Kevin Fenzi wrote:
- #1605 finish retirement of sysvinit-only packages (nirik,
16:24:51) * LINK: https://fedorahosted.org/fesco/ticket/1605%C2%A0%C2%A0 (nirik, 16:24:51) * AGREED: retire packages on list aside nagios (which must be fixed by alpha) and opentracker (+6,0,0) (nirik, 16:33:43)
why we need retire sysvinit-only packages ? is not suppose systemd support sysvinit and why don't you fixed the packages like you will do for nagios ? BTW I'd like keep 2 packages noip and tetrinetx. Shouldn't you give some time or open bug reports before do the retirement ?
why such hurry ?
Hi Sérgio,
this retirement was announced 6 months ago [1] and was scheduled for 2016-02-23. That action slipped and was not carried out in the previous development cycle, but is done now when we are again in pre-alpha phase.
Nevertheless, if you want to keep one of those packages, you can always contribute a systemd unit. The fact that nobody did that since systemd became default in F15 suggests that those packages don't have enough maintainer care. noip seems to be one of those.
[1] https://lists.fedoraproject.org/archives/list/devel-announce%40lists.fedorap...
Zbyszek
On Sun, 31 Jul 2016 04:18:18 +0100 Sérgio Basto sergio@serjux.com wrote:
why we need retire sysvinit-only packages ?
Because they have had 10+ releases to adjust and haven't.
is not suppose systemd support sysvinit and why don't you fixed the packages like you will do for nagios ?
systemd does support sysvinit scripts, but it's a good deal less optimal than a native systemd unit file for lots of reasons.
nagios has a systemd unit file. It was setup/enabled in 2013, but recent spec file changes caused it to ship the old sysvinit script instead. Thats just a bug.
BTW I'd like keep 2 packages noip and tetrinetx. Shouldn't you give some time or open bug reports before do the retirement ?
why such hurry ?
The orig ticket ( https://fedorahosted.org/fesco/ticket/615 ) was opened 5 years ago.
9 months ago an announcement was made: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapro...
Then another 6 months ago: https://lists.fedoraproject.org/archives/list/devel-announce%40lists.fedorap...
We could keep putting it off, but it's had a long long ramp.
kevin
On Sáb, 2016-07-30 at 22:29 -0600, Kevin Fenzi wrote:
On Sun, 31 Jul 2016 04:18:18 +0100 Sérgio Basto sergio@serjux.com wrote:
why we need retire sysvinit-only packages ?
Because they have had 10+ releases to adjust and haven't.
is not suppose systemd support sysvinit and why don't you fixed the packages like you will do for nagios ?
systemd does support sysvinit scripts, but it's a good deal less optimal than a native systemd unit file for lots of reasons.
nagios has a systemd unit file. It was setup/enabled in 2013, but recent spec file changes caused it to ship the old sysvinit script instead. Thats just a bug.
BTW I'd like keep 2 packages noip and tetrinetx. Shouldn't you give some time or open bug reports before do the retirement ?
why such hurry ?
The orig ticket ( https://fedorahosted.org/fesco/ticket/615 ) was opened 5 years ago.
9 months ago an announcement was made: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fe doraproject.org/thread/3XJN6JZ4S7SOG2KH2UT3GYY4K7LAJGGU/
Then another 6 months ago: https://lists.fedoraproject.org/archives/list/devel-announce%40lists. fedoraproject.org/thread/ULPGRGI3OBFXWZISXRIX2S3Z35RBCMBN/
We could keep putting it off, but it's had a long long ramp.
But is so easy do the units files why you just don't add it ? it more work for volunteers, like me, now I will add 2 more packages just because nobody updates the initd :/ OK maybe you are right, but maybe you may think in save work to volunteers, it is too many things, I think. It is to get a better Fedora that we try keep the packages. If they still work, why not ? Even we have FTBFS you may help out or add appdata or even have people to migrate some software for example gtk2 -> gtk3, SDL1 -> SDL2 , qt3 -> qt4 -> qt5 etc etc, teams that knows , what are obsolete like asound or gnome2-vfs (this one is a guess). I think, have some people that can keep some software alive, will save much resources. Also I think this pre-alpha window is too small, I'd like have a bigger pre-alpha window, many things happens at same time, I think we should have more time between tasks and before branching. For example closing F22, I got lost of emails to check, at same time, happens mass rebuild of python, some soname bumps which may imply rebuilds, if not worst, and everything before branching. This tasks shouldn't be done almost at same time because volunteers will have many things to do at same time, IMHO.
Best regards,
Hi,
On Sun, Jul 31, 2016 at 10:53 AM, Sérgio Basto sergio@serjux.com wrote:
On Sáb, 2016-07-30 at 22:29 -0600, Kevin Fenzi wrote:
On Sun, 31 Jul 2016 04:18:18 +0100 Sérgio Basto sergio@serjux.com wrote:
why we need retire sysvinit-only packages ?
Because they have had 10+ releases to adjust and haven't.
is not suppose systemd support sysvinit and why don't you fixed the packages like you will do for nagios ?
systemd does support sysvinit scripts, but it's a good deal less optimal than a native systemd unit file for lots of reasons.
nagios has a systemd unit file. It was setup/enabled in 2013, but recent spec file changes caused it to ship the old sysvinit script instead. Thats just a bug.
BTW I'd like keep 2 packages noip and tetrinetx. Shouldn't you give some time or open bug reports before do the retirement ?
why such hurry ?
The orig ticket ( https://fedorahosted.org/fesco/ticket/615 ) was opened 5 years ago.
9 months ago an announcement was made: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fe doraproject.org/thread/3XJN6JZ4S7SOG2KH2UT3GYY4K7LAJGGU/
Then another 6 months ago: https://lists.fedoraproject.org/archives/list/devel-announce%40lists. fedoraproject.org/thread/ULPGRGI3OBFXWZISXRIX2S3Z35RBCMBN/
We could keep putting it off, but it's had a long long ramp.
But is so easy do the units files why you just don't add it ? it more work for volunteers, like me, now I will add 2 more packages just because nobody updates the initd :/
Kevin has already given a detailed information how longer it took to retire these packages. Also see this https://fedoramagazine.org/systemd-converting-sysvinit-scripts/
OK maybe you are right, but maybe you may think in save work to volunteers, it is too many things, I think.
Why it is too many things? If you are a packager maintainer then you need to follow the current development happening in Fedora. If something is getting replaced by something else and your package is a candidate of that change then I think its the maintainer's responsibility also to make sure his/her package works with the current development Changes.
It is to get a better Fedora that we try keep the packages. If they still work, why not ? Even we have FTBFS you may help out or add appdata or even have people to migrate some software for example gtk2 -> gtk3, SDL1 -> SDL2 , qt3 -> qt4 -> qt5 etc etc, teams that knows , what are obsolete like asound or gnome2-vfs (this one is a guess). I think, have some people that can keep some software alive, will save much resources.
Also I think this pre-alpha window is too small, I'd like have a bigger pre-alpha window, many things happens at same time, I think we should have more time between tasks and before branching. For example closing F22, I got lost of emails to check, at same time, happens mass rebuild of python, some soname bumps which may imply rebuilds, if not worst, and everything before branching. This tasks shouldn't be done almost at same time because volunteers will have many things to do at same time, IMHO.
Well, Fedora Project is a collaborative work. All teams need to work together we can't stop releng from branching or FPM to stop closing F22 bugs. Every participating team has their own work that need to be carried within particular timeframe otherwise we will blocking each other and endup with longer development cycle. Mass-rebuilds for any Change is carried mostly by releng team or Change owners. All these tasks are carried according to the that current Fedora development schedule.
Regards, Parag
On 07/31/2016 06:29 AM, Parag Nemade wrote:
Kevin has already given a detailed information how longer it took to retire these packages. Also see this https://fedoramagazine.org/systemd-converting-sysvinit-scripts/
Take that article with a grain of salt since it's written by somebody that has not done any real migration to any extent.
JBG
On Tue, 2016-08-02 at 09:11 +0000, Jóhann B. Guðmundsson wrote:
On 07/31/2016 06:29 AM, Parag Nemade wrote:
Kevin has already given a detailed information how longer it took to retire these packages. Also see this https://fedoramagazine.org/systemd-converting-sysvinit-scripts/
Take that article with a grain of salt since it's written by somebody that has not done any real migration to any extent.
Jóhann, if there is a factual error in the article point it out, this sniping at people implying they do not know what they are doing and FUD is really not welcome in a community, we are all here to contribute.
Simo.
On 08/02/2016 09:24 AM, Simo Sorce wrote:
On Tue, 2016-08-02 at 09:11 +0000, Jóhann B. Guðmundsson wrote:
On 07/31/2016 06:29 AM, Parag Nemade wrote:
Kevin has already given a detailed information how longer it took to retire these packages. Also see this https://fedoramagazine.org/systemd-converting-sysvinit-scripts/
Take that article with a grain of salt since it's written by somebody that has not done any real migration to any extent.
Jóhann, if there is a factual error in the article point it out, this sniping at people implying they do not know what they are doing and FUD is really not welcome in a community, we are all here to contribute.
This article is meant to be about migration and to be able to write such article you need to have migrated quite few initscripts so please point me to the actual work that the writer has done in that regard.
Then you can cut FUD crap and if you need factual error then the line about EnvironmentFiles should not have been mentioned since it should not exist in type unit files and if everything would have gone as planned an feature would have already been submitted and they cleaned out from the distribution at this point in time along with quite few other things that got "obsoleted" with systemd.
And FYI Red Hat employees are not only here to contribute but apparently they also exist here in this community to threaten to out people from the project if they don't suck up to the Red Hat desktop team.
Perhaps that's just Fedora/Red Hat conference thing.
JBG
On Tue, 2016-08-02 at 10:09 +0000, Jóhann B. Guðmundsson wrote:
On 08/02/2016 09:24 AM, Simo Sorce wrote:
On Tue, 2016-08-02 at 09:11 +0000, Jóhann B. Guðmundsson wrote:
On 07/31/2016 06:29 AM, Parag Nemade wrote:
Kevin has already given a detailed information how longer it took to retire these packages. Also see this https://fedoramagazine.org/systemd-converting-sysvinit-scripts/
Take that article with a grain of salt since it's written by somebody that has not done any real migration to any extent.
Jóhann, if there is a factual error in the article point it out, this sniping at people implying they do not know what they are doing and FUD is really not welcome in a community, we are all here to contribute.
This article is meant to be about migration and to be able to write such article you need to have migrated quite few initscripts so please point me to the actual work that the writer has done in that regard.
I do not actually have to prove anything, in a welcoming community you give the beneit of the doubt that people researched and know what they are talking about and you stick to actual fact in whatever they produce, not to some badge of credentials that can be publicly displayed.
For what I know Jon may have done hundreds of migrations in private.
Then you can cut FUD crap and if you need factual error then the line about EnvironmentFiles should not have been mentioned since it should not exist in type unit files and if everything would have gone as planned an feature would have already been submitted and they cleaned out from the distribution at this point in time along with quite few other things that got "obsoleted" with systemd.
And FYI Red Hat employees are not only here to contribute but apparently they also exist here in this community to threaten to out people from the project if they don't suck up to the Red Hat desktop team.
Perhaps that's just Fedora/Red Hat conference thing.
Please grow up a bit.
Simo.
JBG
-- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On 08/02/2016 10:23 AM, Simo Sorce wrote:
I do not actually have to prove anything, in a welcoming community you give the beneit of the doubt that people researched and know what they are talking about and you stick to actual fact in whatever they produce, not to some badge of credentials that can be publicly displayed.
For what I know Jon may have done hundreds of migrations in private.
Or he has done zero.
And FYI Red Hat employees are not only here to contribute but apparently they also exist here in this community to threaten to out people from the project if they don't suck up to the Red Hat desktop team.
Perhaps that's just Fedora/Red Hat conference thing. Please grow up a bit.
Good to know the Red Hat corporate stance that community members that have been subjected to bullying by Red Hat employees should "grow up a bit".
JBG
On Tue, 2016-08-02 at 10:37 +0000, Jóhann B. Guðmundsson wrote:
On 08/02/2016 10:23 AM, Simo Sorce wrote:
I do not actually have to prove anything, in a welcoming community you give the beneit of the doubt that people researched and know what they are talking about and you stick to actual fact in whatever they produce, not to some badge of credentials that can be publicly displayed.
For what I know Jon may have done hundreds of migrations in private.
Or he has done zero.
And FYI Red Hat employees are not only here to contribute but apparently they also exist here in this community to threaten to out people from the project if they don't suck up to the Red Hat desktop team.
Perhaps that's just Fedora/Red Hat conference thing. Please grow up a bit.
Good to know the Red Hat corporate stance that community members that have been subjected to bullying by Red Hat employees should "grow up a bit".
I would like to drop the thread as it is useless, but I have to say that this is obviously not "the Red Hat corporate stance", but my opinion.
Simo.
On Sun, Jul 31, 2016 at 12:29 AM, Kevin Fenzi kevin@scrye.com wrote:
On Sun, 31 Jul 2016 04:18:18 +0100 Sérgio Basto sergio@serjux.com wrote:
why we need retire sysvinit-only packages ?
Because they have had 10+ releases to adjust and haven't.
There remain compelling reasons to avoid systemd for daemons. The need for system privileges to activate systemd based startups instead of being to debug init scripts as a non-root user and the complete incompatibility of systemd based startip configurations with any other operating system, including all the actual UNIX operating systems, means a very real compatibility cost for cross-platform work.
Sysv init compatibility is invaluable for cross-platform or older OS work, such as for the still supported RHEL 5 and RHEL 6, which makes supporting such projects for EPEL backporting require multiple sets of init scripts. It's also much easier to start daemons and tie the actual operation of the daemon to the last core dump with sysV init scripts, because of the tendency of daemontools to "flap" failing daemons when trying to restart them, and the difficulty of tying the debugger and the console to the startup daemon itself.
Why waste the cycles for daemons that benefit very little from systemd management?
why such hurry ?
The orig ticket ( https://fedorahosted.org/fesco/ticket/615 ) was opened 5 years ago.
It is true that hte migrations to systemd has been long in the process, and is hardly new.
We could keep putting it off, but it's had a long long ramp.
kevin
I'd leave the sleeping dog lie. It's going to keep coming up with cross-platform packages and maintainers who don't care to spend spare cycles to integrate systemd support.
On Mon, Aug 01, 2016 at 07:58:42AM -0400, Nico Kadel-Garcia wrote:
There remain compelling reasons to avoid systemd for daemons. The need for system privileges to activate systemd based startups instead of being to debug init scripts as a non-root user and the complete
I'm confused; are you saying that these mythical init scripts don't require root to function? If not, why would an equivalent systemd unit file somehow require root to activate/invoke?
As for debugging, if anything, systemd makes it simpler to debug failures.
incompatibility of systemd based startip configurations with any other operating system, including all the actual UNIX operating systems, means a very real compatibility cost for cross-platform work.
Um, not even "real" UNIX uses sysvinit any more. And, incidently, only the most trivial of init scripts is portable -- even to other Linux environments, much less non-Linux systems. (Years ago I lost quite a bit of my life trying to maintain "portable" networking-related init scripts. What a cluster@$#%@)
Sysv init compatibility is invaluable for cross-platform or older OS work, such as for the still supported RHEL 5 and RHEL 6, which makes supporting such projects for EPEL backporting require multiple sets of init scripts.
Um, it's a fairly trivial bit of specfile work to alternatively include an init script or a systemd unit file based on EPEL5/6 or PEL7/Fedora builds.
It's also much easier to start daemons and tie the actual operation of the daemon to the last core dump with sysV init scripts.
Um, you do realize that systemd can capture and log coredumps along with everything else a unit file generates?
Why waste the cycles for daemons that benefit very little from systemd management?
How about -- To provide consistency across the whole system, which means everything behaves and can be logged/debugged/analyzed the same way?
I'd leave the sleeping dog lie. It's going to keep coming up with cross-platform packages and maintainers who don't care to spend spare cycles to integrate systemd support.
Just so you know, "not caring to spend cycles to integrate systemd support" means that you're now ignoring the overwhelming majority of your userbase.
Anyway.
- Solomon
On Mon, Aug 1, 2016 at 8:50 AM, Solomon Peachy pizza@shaftnet.org wrote:
On Mon, Aug 01, 2016 at 07:58:42AM -0400, Nico Kadel-Garcia wrote:
There remain compelling reasons to avoid systemd for daemons. The need for system privileges to activate systemd based startups instead of being to debug init scripts as a non-root user and the complete
I'm confused; are you saying that these mythical init scripts don't require root to function? If not, why would an equivalent systemd unit
Depends on the init script. I can set up sshd, for example, to run on a non-privileged port as a non-root user, and tweak the init script very slightly to support that. Other testable daemons, like Jenkins or Tomcat, certainly can run as non-privileged users on non-privileged ports, and are often done exactly that way for debugging in parallel with a production system on a privilieged port.
file somehow require root to activate/invoke?
As for debugging, if anything, systemd makes it simpler to debug failures.
incompatibility of systemd based startip configurations with any other operating system, including all the actual UNIX operating systems, means a very real compatibility cost for cross-platform work.
Um, not even "real" UNIX uses sysvinit any more. And, incidently, only the most trivial of init scripts is portable -- even to other Linux environments, much less non-Linux systems. (Years ago I lost quite a bit of my life trying to maintain "portable" networking-related init scripts. What a cluster@$#%@)
And yet, the "most trivial of UNIX scripts" are embedded in stable packages decades old that have had little to no benefit from systemd.
Sysv init compatibility is invaluable for cross-platform or older OS work, such as for the still supported RHEL 5 and RHEL 6, which makes supporting such projects for EPEL backporting require multiple sets of init scripts.
Um, it's a fairly trivial bit of specfile work to alternatively include an init script or a systemd unit file based on EPEL5/6 or PEL7/Fedora builds.
It's a burden, usually solved by ignoring one or the other. Since systemd is always incompatible and always will be incompatible with anything but relatively modern Linux distrubitutions, guess which packages never get ported to non-Linux systems.
How about -- To provide consistency across the whole system, which means everything behaves and can be logged/debugged/analyzed the same way?
That would be very sweet, if it ever worked that way. We've seen to many times when systemd merged logging is not intelligible to stable, cross-platform tools and even cases where systemd settings alter system behavior with no logging whatsoever, so there's frankly little reason to trust its completeness. (KullUserProcess=yes, anyone? Making /etc/resolv.conf a sylink for the new dhcp service, then failing to ever restore it if someone hand edits it with vi and breaks the symlink?)
I'd leave the sleeping dog lie. It's going to keep coming up with cross-platform packages and maintainers who don't care to spend spare cycles to integrate systemd support.
Just so you know, "not caring to spend cycles to integrate systemd support" means that you're now ignoring the overwhelming majority of your userbase.
No, most of my userbase doesn't use systems capable of supporting systemd. Not many stable industry systems do. Fedora is where I get a handle on up and coming projects and try to help prevent trouble for myself down the road.
Anyway.
- Solomon
-- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur.
-- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On Mon, Aug 01, 2016 at 08:25:01PM -0400, Nico Kadel-Garcia wrote:
Depends on the init script. I can set up sshd, for example, to run on a non-privileged port as a non-root user, and tweak the init script very slightly to support that. Other testable daemons, like Jenkins or Tomcat, certainly can run as non-privileged users on non-privileged ports, and are often done exactly that way for debugging in parallel with a production system on a privilieged port.
I did not ask why you wish to do this, only why it was something that was supposedly impossible (or more difficult) with systemd.
(FYI: I routinely run daemons as an unprivlidged user, using systemd units. Versus running by hand I get first-rate logging and all of the other cgroup-enabled manageablility that systemd brings to the table)
And yet, the "most trivial of UNIX scripts" are embedded in stable packages decades old that have had little to no benefit from systemd.
So what are these decades-old daemons?
(Heck, of the four systems I directly control, there is only one sysvinit script in use -- for the 3ware RAID controller management daemon)
Um, it's a fairly trivial bit of specfile work to alternatively include an init script or a systemd unit file based on EPEL5/6 or PEL7/Fedora builds.
It's a burden, usually solved by ignoring one or the other. Since systemd is always incompatible and always will be incompatible with anything but relatively modern Linux distrubitutions, guess which packages never get ported to non-Linux systems.
We're talking about EPEL 5/6 vs EPEL7/Fedora here, not "Linux distributions" in general. You could have written a complete unit script (and the condifitonal specfile logic) in fraction of the time you've spent writing these emails.
But since you brought it up, I'd love to hear an example of something that isn't getting ported to non-Linux systems solely due to systemd, as opposed to utilizing some other feature unique to "relatively modern Linux distributions". I can think of many examples of the latter, but not the former.
When it comes to non-Linux systems, in my experience folks who deliberately chose those fringe platforms are nearly always willing to help out. Patches are almost always welcome.
That would be very sweet, if it ever worked that way. We've seen to many times when systemd merged logging is not intelligible to stable, cross-platform tools and even cases where systemd settings alter system behavior with no logging whatsoever, so there's frankly little reason to trust its completeness. (KullUserProcess=yes, anyone? Making /etc/resolv.conf a sylink for the new dhcp service, then failing to ever restore it if someone hand edits it with vi and breaks the symlink?)
You appear to be conflating several unrelated things, so let me address them individually.
* Logging -- Got any examples that aren't resolved by enabling syslog passthrough? (Log parsing is something historically quite brittle; I can recall many things that broke release-to-release far before systemd was ever conceived) * Systemd settings altering system behavor with no logging -- Given that a setting is in of itself intended to alter system behavior, I'm not really sure what your point is. * KillUserProcesses=yes -- Given that this setting was only part of Fedora Rawhide for about a week, if you're complaining that you got bitten by unexpected behavioral changes I really must question why you're running Rawhide. If you weren't running Rawhide, then the only way it could have bitten you is if you manually changed the setting yourself (in which you only have yourself to blame) or if you compiled your own systemd instance (ditto). Meanwhile, to give credit where it's due, systemd now logs when it kills stuff due to this setting, rendering the whole argument moot. * Symlinking /etc/resolv.conf -- It was due to a combination of conflicting changes in systemd and NetworkManger, and if I understand correctly, only ever affected Rawhide (or Fedora pre-releases). It's a perfect example of the sort of issues that come up when distributions attempt to integrate low-level software developed by different teams.
No, most of my userbase doesn't use systems capable of supporting systemd. Not many stable industry systems do. Fedora is where I get a handle on up and coming projects and try to help prevent trouble for myself down the road.
By your own words, doesn't this indicate that proper systemd support is something you should be concerned about?
After all, all marketshare-relevant Linux distributions now utilize systemd, along with the current releases of enterprise-y/stable/LTS distributions. Their installed/market share will only grow.
- Solonmon
On 08/02/2016 12:25 AM, Nico Kadel-Garcia wrote:
It's a burden, usually solved by ignoring one or the other. Since systemd is always incompatible and always will be incompatible with anything but relatively modern Linux distrubitutions, guess which packages never get ported to non-Linux systems.
Actually in many cases upstreams that are targeting different types of *nix dont ship initscripts et all but instead have downstream ship those instead as an upstream policy ( we had few rejection of type unit files from upstream based on that ) so I'm unsure how much of a burden that really is.
JBG
On Tue, Aug 2, 2016 at 6:15 AM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
On 08/02/2016 12:25 AM, Nico Kadel-Garcia wrote:
It's a burden, usually solved by ignoring one or the other. Since systemd is always incompatible and always will be incompatible with anything but relatively modern Linux distrubitutions, guess which packages never get ported to non-Linux systems.
Actually in many cases upstreams that are targeting different types of *nix dont ship initscripts et all but instead have downstream ship those instead as an upstream policy ( we had few rejection of type unit files from upstream based on that ) so I'm unsure how much of a burden that really is.
The first one that leaps to mind as publishing init scripts in their main source code, and no support for systemd, is OpenSSH. That's fairly understandable the base operating system for OpenSSH is OpenBSD.
The second critical daemon that provides SysV init scripts and includes no systemd support in the upstream source code is httpd.
Do I really need to dig further?
On Wed, Aug 3, 2016 at 12:11 AM, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Tue, Aug 2, 2016 at 6:15 AM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
On 08/02/2016 12:25 AM, Nico Kadel-Garcia wrote:
It's a burden, usually solved by ignoring one or the other. Since systemd is always incompatible and always will be incompatible with anything but relatively modern Linux distrubitutions, guess which packages never get ported to non-Linux systems.
Actually in many cases upstreams that are targeting different types of *nix dont ship initscripts et all but instead have downstream ship those instead as an upstream policy ( we had few rejection of type unit files from upstream based on that ) so I'm unsure how much of a burden that really is.
The first one that leaps to mind as publishing init scripts in their main source code, and no support for systemd, is OpenSSH. That's fairly understandable the base operating system for OpenSSH is OpenBSD.
The second critical daemon that provides SysV init scripts and includes no systemd support in the upstream source code is httpd.
Do I really need to dig further?
Those do get ported. I didn't mean to be confusing. "buildbot", the Python based build tool, is unlikely to ever be ported. Not that it's a very good tool, but it remains additionally unlikely to be ported due to the extra burden of having to provide system admin provided systemd integration.
On Wed, Aug 03, 2016 at 12:15:09AM -0400, Nico Kadel-Garcia wrote:
Those do get ported. I didn't mean to be confusing. "buildbot", the Python based build tool, is unlikely to ever be ported. Not that it's a very good tool, but it remains additionally unlikely to be ported due to the extra burden of having to provide system admin provided systemd integration.
https://github.com/buildbot/buildbot/blob/master/master/contrib/systemd/buil...
This commit landed in January, 2014, and sits alongside an example sysvinit script. Fedora's packages include neither, not even as exmples -- there's no provided init integration at all.
Incidently, I wouldn't consider buildbot an example of a "decades-old" daemon for which systemd adds nothing; indeed it's one of the most finiky and brittle tools I've ever used, and systemd's isolation, logging, and cleanup features are greatly beneficial when trying to figure out why buildbot has crapped out yet again.
- Solomon
On Wed, Aug 3, 2016 at 8:56 AM, Solomon Peachy pizza@shaftnet.org wrote:
On Wed, Aug 03, 2016 at 12:15:09AM -0400, Nico Kadel-Garcia wrote:
Those do get ported. I didn't mean to be confusing. "buildbot", the Python based build tool, is unlikely to ever be ported. Not that it's a very good tool, but it remains additionally unlikely to be ported due to the extra burden of having to provide system admin provided systemd integration.
https://github.com/buildbot/buildbot/blob/master/master/contrib/systemd/buil...
This commit landed in January, 2014, and sits alongside an example sysvinit script. Fedora's packages include neither, not even as exmples -- there's no provided init integration at all.
Interesting, and thank you for the pointer. It was not in the tag that I last worked with.
Incidently, I wouldn't consider buildbot an example of a "decades-old" daemon for which systemd adds nothing; indeed it's one of the most finiky and brittle tools I've ever used, and systemd's isolation, logging, and cleanup features are greatly beneficial when trying to figure out why buildbot has crapped out yet again.
Oh, dear lord, I agree it's horrible and does nothing that Jenkins or even Hudson didn't master a decade ago. I'm having some difficulty finding decades old standards that haven't either died, or have finally gained systemd support. Much of the systemd support remains outside the primary source repository for many daemons, including httpd and OpenSSH and Subverison that I mentioned. Buildbot... has surprised me by having enough suckers stuck using it to ever have gotten systemd tools written for it.
One of the benefit of a sysvinit script that I've not personally made clear is that it's easier to start it *from the console*, and activate gdb or a graphical debugger around it the running binary. I've never seen anyone get that working for systemd, and activating the daemons in systemd typically requires administrative privileges. It's often easier to activate a daemon with a raw init script, as a local user, without adding the potentially fragile intricacies of running it as a systemd daemon. If it fails once, you get one core file suitable for debugging, and the daemon stays *dead* until manually restarted.
On Qua, 2016-08-03 at 00:11 -0400, Nico Kadel-Garcia wrote:
On Tue, Aug 2, 2016 at 6:15 AM, Jóhann B. Guðmundsson johannbg@gmail.com wrote:
On 08/02/2016 12:25 AM, Nico Kadel-Garcia wrote:
It's a burden, usually solved by ignoring one or the other. Since systemd is always incompatible and always will be incompatible with anything but relatively modern Linux distrubitutions, guess which packages never get ported to non-Linux systems.
Actually in many cases upstreams that are targeting different types of *nix dont ship initscripts et all but instead have downstream ship those instead as an upstream policy ( we had few rejection of type unit files from upstream based on that ) so I'm unsure how much of a burden that really is.
But why you don't maintain or propose (via bugzilla) systemd configuration for the 18 packages that left ? , why I have to learn to configure systemd daemon to maintain one package ? when I don't want to, I don't have time for that, when you certainly do it better. etc etc. Other reason that I ask you to do it, I think we waste much less time with this discussions.
The first one that leaps to mind as publishing init scripts in their main source code, and no support for systemd, is OpenSSH. That's fairly understandable the base operating system for OpenSSH is OpenBSD.
The second critical daemon that provides SysV init scripts and includes no systemd support in the upstream source code is httpd.
Do I really need to dig further?
#rpm -q httpd -l | grep -P "system|legacy" /etc/httpd/conf.modules.d/00-systemd.conf /usr/lib/systemd/system/htcacheclean.service /usr/lib/systemd/system/httpd.service /usr/lib/systemd/system/httpd.service.d /usr/lib/systemd/system/httpd.socket /usr/lib/systemd/system/httpd.socket.d /usr/lib64/httpd/modules/mod_systemd.so /usr/libexec/initscripts/legacy-actions/httpd /usr/libexec/initscripts/legacy-actions/httpd/configtest /usr/libexec/initscripts/legacy-actions/httpd/graceful
#rpm -q openssh-server -l | grep -P "system|legacy" /usr/lib/systemd/system/sshd-keygen.service /usr/lib/systemd/system/sshd.service /usr/lib/systemd/system/sshd.socket /usr/lib/systemd/system/sshd@.service
-- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject .org
On 07/31/2016 03:18 AM, Sérgio Basto wrote:
why such hurry ?
There has been a more than enough time for this migration to happen already and now it's existence has started to hinder other changes and adoptions in the distribution.
The initial target was for the feature completion was F20 or two years for every component in Fedora with an average migration time of 4 hours per components including changes to spec files and ( minimal ) testing ( and this was done with real submitted work not drive by maintainers tagging expecting the components maintainers to do the work for them ) but it came immediately clear what would prevent that from happening in F15 when we started the migration ( we started it in F14 ) and that was package maintainers ( mostly due to same 4 or 5 reasons ) not the migration process itself then idiotic decisions making by FESCo and bottlenecks in the FPC process itself added additional delays to that and other systemd integration work.
JBG
-
Jóhann B. Guðmundsson -
Kevin Fenzi -
Nico Kadel-Garcia -
Parag Nemade -
Simo Sorce -
Solomon Peachy -
Sérgio Basto -
Zbigniew Jędrzejewski-Szmek