Bug 713562 (SysVtoSystemd)

Services that are installed in the "base" or "core" groups must have their conversion to systemd completed by Fedora 16 Alpha, per FESCo decision on 6/15/2011

Note that this has been extended to include all service that get shipped on the Fedora-livecd

Discussed at the 2011-07-15 blocker review meeting. We agreed that these bugs do not constitute release blockers under the release blocker process - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - which is intended to ensure Fedora releases meet set quality standards, as embodied in the release criteria - https://fedoraproject.org/wiki/Fedora_Release_Criteria .

We are not contesting FESCo's requirement that some of these conversions be complete by Alpha, this is still in effect, but we ask FESCo to manage that through the feature process. A tracker bug outside of the blocker bug process could easily be used to achieve this.

Missing bug #660069 (Samba)

Question: I've just done preupgrade from F15 to F16 and system-config-vsftpd does not work with respect to starting/stopping the server. Is this a new bug or should it be considered part of this or is there some other bug opened on this (I can't find one)?

More details: 
I don't know if it was broken in F15 because, although I had installed vsftp in F15, I had not tried starting/stopping it via system-config-vsftpd. I don't really remember but I think I started it through system-config-services.

When I try to start the server via system-config-vsftpd, it fails with the following message in the Status Log: "sh: /etc/init.d/vsftpd: No such file or directory"

The server will start via command line: /bin/systemctl start vsftpd.service

When started via the above command line, the fact that it is started is not recognized by system-config-vsftpd and thus cannot be stopped by system-config-vsftpd. Xfer Log and System Log do contain information related to vsftp activity performed using the server started by the command line.

Thanks
Jim

Did rpm -qa | grep vsftpd and it showed:
system-config-vsftpd-0.5.1-7.fc15.noarch
vsftpd-2.3.4-6.fc16.x86_64

So I've got a back-level version of system-config-vsftpd.

Thanks
Jim

OK, never mind. I thought I had done package-cleanup --orphans and gotten rid of obsolete packages but I had not. system-config-vsftpd is obsolete.

Sorry for the diversion.

Jim

Add Tracking keyword to avoid bug closure during Rawhide rebase process.

Given that I have left the project and a new individual may or may not continue with systemd integration in the project by submitting new feature following whatever demands FPC and FESCo might have and thus new units in the process I'm closing this and all remaining bugs I had submitted for this particular feature as WONTFIX

Restore relevant bugs, and reopen.

Zbigniew any particular reason you reopened this ancient bug ( there was a new bug per release cycle ) as opoosed to simply open a new one and attach all those ca 150 remaining components to be migrated on that one since you seem to be so inclined of working on this as opposed to just leave it up to the project leader left foot and rest of FPC, FESCo and those Red Hat employees that are so inclined of getting in the way of contributors doing needed work for the distribution? 

My advice to you is to leave this mess to be cleaned up by certain Red Hatters on Red Hat's dime since this is what they wanted and this is what they should get and this should be something *they* should do ( along with cron to timers the cleanup of units that should have happened arguable before RHEL 7 got released with systemd etc ).

Focus on preparing the distribution for up coming changes in systemd ( kdbus,networkd etc ) since from the looks of it you and Harald already have your handful dealing first hand with "usefulness" of the FPC trying to prep dracut and systemd for networkd where those fpc geniuses cant even follow they own approved guidelines or realize that there exist no such thing as system wide change anymore due to the distribution moving to products.

(In reply to Jóhann B. Guðmundsson from comment #13)
> Zbigniew any particular reason you reopened this ancient bug
The title and description fits, and it seems less work and noise to simply reopen this one. I don't very high expectations for this to be finished quickly, but having an open tracker bug at least makes it easier to track progress.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #14)
> (In reply to Jóhann B. Guðmundsson from comment #13)
> > Zbigniew any particular reason you reopened this ancient bug
> The title and description fits, and it seems less work and noise to simply
> reopen this one. I don't very high expectations for this to be finished
> quickly, but having an open tracker bug at least makes it easier to track
> progress.

It's going to cost you up to 300 hours of your life familiarizing yourself with those services/daemon which is required for you to do, so you can a test it when you migrate their legacy sysv initscripts to native systemd units as well as the conversion itself along with those spec file changes and other cleanups you should do based on what other progress is taking place on the core/baseOS to reduce any amount of work in that area. ( which one would be doing in an functional community which Fedora is not )

Those up to 300 hours you could be spending for nothing since the maintainers of those 150 components ( assuming they exist in the first place ) would by now, if interested done the migration themselves so the likely hood is that they a) they dont exist or b) opposed the migration or simply dont know what they are doing thus wont accept those patches is higher than you think so you would be wasted that time for nothing.

In a larger scheme of things those 300 hours of your contributed time with your skill sett is better spent a) directly upstream systemd or b) properly prep and fix python 3.x integration in Fedora ( that is if Toshio and Red Hat's SCL let by Marcela has not royally thwarted that effort for the distribution ) and finally c) simply with your family.

Let this and other integration/migration work be handled by Red Hat employees since they are incapable of accepting responsibility for the outcome of the decisions they make and the position they are in.

The only way they will learn is having them to do all the hard work themselves since they are incapable of listening as in by bumping into those things them themselves.