Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-04 Thread Nico Kadel-Garcia 
On Wed, Aug 3, 2016 at 8:56 AM, Solomon Peachy  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/buildbot.service
>
> 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.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-03 Thread Solomon Peachy 
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/buildbot.service

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.


signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-02 Thread Sérgio Basto 
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
>  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
-- 
Sérgio M. B.

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-02 Thread Nico Kadel-Garcia 
On Wed, Aug 3, 2016 at 12:11 AM, Nico Kadel-Garcia  wrote:
> On Tue, Aug 2, 2016 at 6:15 AM, Jóhann B. Guðmundsson
>  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.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-02 Thread Nico Kadel-Garcia 
On Tue, Aug 2, 2016 at 6:15 AM, Jóhann B. Guðmundsson
 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?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-02 Thread Simo Sorce 
On Tue, 2016-08-02 at 10:37 +, 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
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-02 Thread Jóhann B . Guðmundsson 



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
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-02 Thread Simo Sorce 
On Tue, 2016-08-02 at 10:09 +, Jóhann B. Guðmundsson wrote:
> 
> On 08/02/2016 09:24 AM, Simo Sorce wrote:
> > On Tue, 2016-08-02 at 09:11 +, 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


-- 
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-02 Thread Jóhann B . Guðmundsson 

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
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-02 Thread Jóhann B . Guðmundsson 



On 08/02/2016 09:24 AM, Simo Sorce wrote:

On Tue, 2016-08-02 at 09:11 +, 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

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-02 Thread Jóhann B . Guðmundsson 

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
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-02 Thread Simo Sorce 
On Tue, 2016-08-02 at 09:11 +, 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
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-02 Thread Jóhann B . Guðmundsson 

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
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-01 Thread Solomon Peachy 
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.


signature.asc

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-01 Thread Nico Kadel-Garcia 
On Mon, Aug 1, 2016 at 8:50 AM, Solomon Peachy  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
>
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-01 Thread Solomon Peachy 
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.


signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-08-01 Thread Nico Kadel-Garcia 
On Sun, Jul 31, 2016 at 12:29 AM, Kevin Fenzi  wrote:
> On Sun, 31 Jul 2016 04:18:18 +0100
> Sérgio Basto  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.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-07-31 Thread Parag Nemade 
Hi,

On Sun, Jul 31, 2016 at 10:53 AM, Sérgio Basto  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  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-annou...@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
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-07-30 Thread Sérgio Basto 
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  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-annou...@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.

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-07-30 Thread Kevin Fenzi 
On Sun, 31 Jul 2016 04:18:18 +0100
Sérgio Basto  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-annou...@lists.fedoraproject.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. 

kevin


pgp6Qjc1ZrDDg.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-07-30 Thread Zbigniew Jędrzejewski-Szmek 
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.fedoraproject.org/thread/ULPGRGI3OBFXWZISXRIX2S3Z35RBCMBN/

Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-07-30 Thread Sérgio Basto 
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.

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Schedule for Friday's FESCo Meeting (2016-07-29)

2016-07-29 Thread Kevin Fenzi 
===
#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-16.00.log.html
.



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  #startmeeting FESCO (2016-07-29)
16:00:03  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  Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
16:00:03  The meeting name has been set to 'fesco_(2016-07-29)'
16:00:03  #meetingname fesco
16:00:03  #chair maxamillion dgilmore jwb nirik paragan jsmith kalev 
sgallagh rathann
16:00:03  #topic init process
16:00:03  The meeting name has been set to 'fesco'
16:00:03  Current chairs: dgilmore jsmith jwb kalev maxamillion nirik 
paragan rathann sgallagh
16:00:36  .hello sgallagh
16:00:37  sgallagh: sgallagh 'Stephen Gallagher' 
16:01:32  .hello pnemade
16:01:33  paragan: pnemade 'Parag Nemade' 
16:02:16  well, thats 3 of us... will wait a bit more and see if we 
reach quorum.
16:02:22  .hello jsmith
16:02:23  jsmith: jsmith 'Jared Smith' 
16:02:41  sorry for being late
16:02:54  no worries.
16:03:20  ok, thats 5, so we can go ahead...
16:03:23  I think that gives a quorum
16:03:38  yes :)
16:04:01  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  should we do a new whenisgood for a new time?
16:04:32  nirik: Why don't we just ask rathann first.
16:04:46  sure, although he appears not to be here today. ;)
16:04:50  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  #topic #1600 F25 System Wide Change: KillUserProcesses=yes by 
default
16:05:10  .fesco 1600
16:05:10  https://fedorahosted.org/fesco/1600
16:05:11  nirik: #1600 (F25 System Wide Change: KillUserProcesses=yes 
by default) – FESCo - https://fedorahosted.org/fesco/ticket/1600
16:05:23  sgallagh put a more concrete proposal in this morning.
16:05:27  the list looks fine to me
16:05:29  .fesco 1600
16:05:30  nirik: #1600 (F25 System Wide Change: KillUserProcesses=yes 
by default) – FESCo - https://fedorahosted.org/fesco/ticket/1600
16:05:50  zbyszek: you thoughts ? ^
16:06:30  screen and tmux are obviously fine.
16:06:50  nohup and disown can be shell builtins, and I'm not sure if 
they can be redefined.
16:07:06  (or should rather)
16:07:10  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  However given that their obvious purpose is to do exactly 
this...
16:07:34  (survive a session)
16:07:55  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  disown could be a lot harder
16:08:01  Right, but there's

Schedule for Friday's FESCo Meeting (2016-07-29)

2016-07-28 Thread Kevin Fenzi 
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. 


pgpiis6PmD0P9.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org