4:50 p.m.
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.
11:55 a.m.
===================================
#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...
.
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(a)redhat.com>
16:01:32 <paragan> .hello pnemade
16:01:33 <zodbot> paragan: pnemade 'Parag Nemade'
<pnemade(a)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(a)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
10:18 p.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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 (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 ?
--
Sérgio M. B.
11:25 p.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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 (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.fedo...
Zbyszek
11:29 p.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
On Sun, 31 Jul 2016 04:18:18 +0100
Sérgio Basto <sergio(a)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.fedora...
Then another 6 months ago:
https://lists.fedoraproject.org/archives/list/devel-announce%40lists.fedo...
We could keep putting it off, but it's had a long long ramp.
kevin
12:23 a.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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(a)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,
--
Sérgio M. B.
1:29 a.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
Hi,
On Sun, Jul 31, 2016 at 10:53 AM, Sérgio Basto <sergio(a)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(a)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
6:58 a.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
On Sun, Jul 31, 2016 at 12:29 AM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Sun, 31 Jul 2016 04:18:18 +0100
Sérgio Basto <sergio(a)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.
7:50 a.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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
--
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
7:25 p.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
On Mon, Aug 1, 2016 at 8:50 AM, Solomon Peachy <pizza(a)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(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
9:32 p.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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
--
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
4:11 a.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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
4:24 a.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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.
--
Simo Sorce * Red Hat, Inc * New York
4:48 a.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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
5:09 a.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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
5:15 a.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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
5:23 a.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
Simo Sorce * Red Hat, Inc * New York
5:37 a.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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
6:35 a.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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.
--
Simo Sorce * Red Hat, Inc * New York
11:11 p.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
On Tue, Aug 2, 2016 at 6:15 AM, Jóhann B. Guðmundsson
<johannbg(a)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?
11:15 p.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
On Wed, Aug 3, 2016 at 12:11 AM, Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Tue, Aug 2, 2016 at 6:15 AM, Jóhann B. Guðmundsson
<johannbg(a)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.
11:32 p.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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(a)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(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject
.org
--
Sérgio M. B.
7:56 a.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
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/b...
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
--
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
8:58 p.m.
New subject: finish retirement of sysvinit-only packages Re: Schedule for
Friday's FESCo Meeting (2016-07-29)
On Wed, Aug 3, 2016 at 8:56 AM, Solomon Peachy <pizza(a)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/b...
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.
2828
days inactive
2836
days old
23 comments
8 participants
participants (8)
-
Jóhann B. Guðmundsson -
Kevin Fenzi -
Nico Kadel-Garcia -
Parag Nemade -
Simo Sorce -
Solomon Peachy -
Sérgio Basto -
Zbigniew Jędrzejewski-Szmek