Re: [arch-dev-public] remaining items in the systemd TODO
On 26 September 2012 21:59, Tom Gundersen t...@jklm.no wrote: Hi guys, As our gnome 3.6 packages will be depending on systemd and are scheduled to be released in the not too distant future, I thought it might make sense to try and finish up as many service files as possible before that time. In our TODO list there are about 50 packages with rc scripts, but without systemd service files. I'll be going over all the orphans in [extra] tonight, but that still leaves quite a few. Could those of you with outstanding items in the TODO list please have a look and indicate if they are still intending to do it themselves, or if they need some guidance, or if they prefer someone else to do it? Cheers, Tom Hi Tom, Hi all, As for package tomcat: this version will not be supported by upstream after September 30rd. So I intend to drop it in 3 days. No real need to migrate it to systemd then. -- Guillaume
[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 7 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 2 fully signed off packages * 23 packages missing signoffs * 8 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (7 total) == * netcfg-2.8.11-1 (any) * brltty-4.3-6 (i686) * fssos-nsvs-0.5-9 (i686) * lirc-1:0.9.0-28 (i686) * brltty-4.3-6 (x86_64) * fssos-nsvs-0.5-9 (x86_64) * lirc-1:0.9.0-28 (x86_64) == Incomplete signoffs for [core] (5 total) == * netcfg-2.8.11-1 (any) 0/2 signoffs * rp-pppoe-3.11-1 (i686) 0/2 signoffs * run-parts-4.3.4-1 (i686) 0/2 signoffs * rp-pppoe-3.11-1 (x86_64) 0/2 signoffs * run-parts-4.3.4-1 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (18 total) == * brltty-4.3-6 (i686) 0/2 signoffs * fssos-nsvs-0.5-9 (i686) 0/2 signoffs * hwloc-1.5-1 (i686) 0/2 signoffs * kdevelop-4.3.90-1 (i686) 0/2 signoffs * kdevelop-php-1.3.90-1 (i686) 0/2 signoffs * kdevplatform-1.3.90-1 (i686) 0/2 signoffs * lirc-1:0.9.0-28 (i686) 0/2 signoffs * openmpi-1.6.2-1 (i686) 0/2 signoffs * polkit-0.107-2 (i686) 0/2 signoffs * brltty-4.3-6 (x86_64) 0/2 signoffs * fssos-nsvs-0.5-9 (x86_64) 0/2 signoffs * hwloc-1.5-1 (x86_64) 0/2 signoffs * kdevelop-4.3.90-1 (x86_64) 0/2 signoffs * kdevelop-php-1.3.90-1 (x86_64) 0/2 signoffs * kdevplatform-1.3.90-1 (x86_64) 0/2 signoffs * lirc-1:0.9.0-28 (x86_64) 0/2 signoffs * openmpi-1.6.2-1 (x86_64) 0/2 signoffs * polkit-0.107-2 (x86_64) 1/2 signoffs == Completed signoffs (2 total) == * patch-2.7-1 (i686) * patch-2.7-1 (x86_64) == All packages in [testing] for more than 14 days (8 total) == * kdevelop-4.3.90-1 (i686), since 2012-09-10 * kdevelop-php-1.3.90-1 (i686), since 2012-09-10 * kdevelop-4.3.90-1 (x86_64), since 2012-09-10 * kdevelop-php-1.3.90-1 (x86_64), since 2012-09-10 * kdevplatform-1.3.90-1 (i686), since 2012-09-10 * kdevplatform-1.3.90-1 (x86_64), since 2012-09-10 * patch-2.7-1 (i686), since 2012-09-13 * patch-2.7-1 (x86_64), since 2012-09-13 == Top five in signoffs in last 24 hours == 1. tpowa - 4 signoffs 2. foutrelis - 2 signoffs 3. stephane - 2 signoffs 4. dreisner - 2 signoffs 5. allan - 1 signoffs
[arch-dev-public] The future of sysvinit in Arch: Call for Help
Hi guys, As the move to systemd is under way, and we will soon have packages in our repos that require your system to be booted with systemd, I thought this would be a good time to summarize the state of sysvinit/initscripts in Arch and their future. Abstract: I think the current state is relatively good (but I'm clearly very biased) and it should not be hard to maintain a non-systemd boot on Arch even in the long-run. However, someone has to do the work. NOTE: Please let's keep any replies on-topic. This is NOT about whether or not sysvinit or systemd is good or bad. Testing = This has been repeated a lot, but I think it makes sense to say it again: We are quickly running out of people who do early testing of initscripts. I.e., who follow arch-projects, review patches and test initscripts-git. At some point we will probably also struggle with a lack of developers/TU's testing initscripts in [testing], so if you feel passionately about a non-systemd boot on Arch, please join arch-projects and help with testing. Initscripts == Initscripts are currently fully supported and actively developed. Work has been going on for a long time to make initscripts and systemd share the same configuration file format wherever that makes sense, and this work is mostly completed (at least on the initscripts side). Moreover, code is shared between systemd and initscripts wherever possible (there might still be more opportunities for this, but the work is mostly completed). Together, these two developments should make it relatively easy to maintain initscripts for Arch in the long-run, even with a small user/developer base. I intend to maintain initscripts in the official repos as long as this makes sense. However, for this to be viable, I think we would need at least one capable and active initscripts developer who is interested in helping out and who uses sysvinit/initscripts as their main init system. In the long-run it would make sense for such a person to take over maintainership of initscripts. Anyone interested, please join arch-projects and post reviews, suggestions and patches :-) Packages requiring systemd = In the (near) future, we expect some packages to no longer support non-systemd boot. In particular I'm thinking of polkit, networkmanager and some gnome packages (I don't know which as I don't use gnome myself). There will probably be more in the future. We might also drop ConsoleKit from the repos at some point in the future. No need to panic though. The number of packages that will actually be need to be rebuilt to support non-systemd boot are actually very limited (certainly less than ten). An alternative repository just providing the relevant packages could very easily be maintained by one committed person (possibly even the same person that will help out with initscripts). I would be happy to help with getting this started if anyone is interested. A point to keep in mind is that the people who don't want to switch to systemd, might not be using ConsoleKit, polkit, etc anyway, so maybe this problem is not actually a real one. rc scripts = Currently we have a few hundred rc scripts in our repos (the scripts under /etc/rc.d/) shipped with our various packages. This will probably not change in the near future, but if for whatever reason some packagers decide to drop some rc scripts from their packages (and rely purely on the systemd unit files), then it would be very simple to pull the relevant scripts from our repos and ship them in a rc-scripts package in the above suggested repository. Concluding remarks As I have tried to outline above, the amount of work required for a non-systemd boot is really small, and I'd be happy to help anyone who decides to take it on. However, I have seen some suggestions of ways of avoiding systemd that entails splitting the systemd package up, rebuilding tens of packages just to avoid a systemd-libs dependency or re-duplicate all the code shared between initscripts and systemd. This, in my humble opinion, is not worth the effort and is not something I'd be interested in getting involved with. Please direct any technical discussions to arch-proje...@archlinux.org. Cheers, Tom
Re: [arch-dev-public] The future of sysvinit in Arch: Call for Help
On Thu, Sep 27, 2012 at 9:48 AM, Tom Gundersen t...@jklm.no wrote: Hi guys, As the move to systemd is under way, and we will soon have packages in our repos that require your system to be booted with systemd, I thought this would be a good time to summarize the state of sysvinit/initscripts in Arch and their future. Abstract: I think the current state is relatively good (but I'm clearly very biased) and it should not be hard to maintain a non-systemd boot on Arch even in the long-run. However, someone has to do the work. NOTE: Please let's keep any replies on-topic. This is NOT about whether or not sysvinit or systemd is good or bad. Initscripts == Initscripts are currently fully supported and actively developed. Work has been going on for a long time to make initscripts and systemd share the same configuration file format wherever that makes sense, and this work is mostly completed (at least on the initscripts side). Moreover, code is shared between systemd and initscripts wherever possible (there might still be more opportunities for this, but the work is mostly completed). Together, these two developments should make it relatively easy to maintain initscripts for Arch in the long-run, even with a small user/developer base. I intend to maintain initscripts in the official repos as long as this makes sense. However, for this to be viable, I think we would need at least one capable and active initscripts developer who is interested in helping out and who uses sysvinit/initscripts as their main init system. In the long-run it would make sense for such a person to take over maintainership of initscripts. Anyone interested, please join arch-projects and post reviews, suggestions and patches :-) Hi, I'm a bit confused by this post. My understanding was that we were switching to systemd as the default init system because maintaining two init systems was too much work and problems. Therefore, I thought that it was implied that once systemd is the default, we would stop supporting initscripts. I agree that we should keep supporting initscripts for a short transition period (1 month?) after systemd is the default. If we do things this way, we should decide on the length so we could mention it in the systemd is now default announcement. After that transition period, we should drop support for initscript which means: -remove initscripts from the repos -no more developement in git and on arch-project ML -we can start removing rc.d scripts from packages as we update them If there is user interest, they can clone the git repo and continue developpement on github or on another one of these open source website. And AUR can host the PKGBUILD for initscript and a collection of the rc.d scripts. By letting initscripts become a user project, we will be able to use our resource on other aspects of the distro. Also maintaining initscripts in repo also means maintaining the rc.d scripts. As most of us dev/TU are using (or will use) systemd, these will be harder to maintain and fix. I don't know what you think about this but that's how I see things. Eric
[arch-dev-public] Request to drop some [extra] orphans to [community]
Hi, I would be interested in maintaining any of these orphans currently in [extra] if someone could drop them into [community]: archlinux-artwork ipcalc vim-buftabs aspell-* dvdrtools gnuchess lsdvd cmatrix Thanks, -- Jonathan Steel pgpMVMBttxgHb.pgp Description: PGP signature
Re: [arch-dev-public] The future of sysvinit in Arch: Call for Help
On Thu, Sep 27, 2012 at 10:22 PM, Eric Bélanger snowmanisc...@gmail.com wrote: I'm a bit confused by this post. I guess I should clarify my aim: As there are vocal proponents of sysvinit who feel strongly about staying with that, I'd rather help them get started in the right direction rather than cause lots of unnecessary confusion and fragmentation (as I alluded to at the end of my email I have seen some misguided attempts at doing this which I think would be detrimental to everyone). Where this work happens (if it happens), is not really anything I gave much thought. If it is the consensus that we should quickly drop initscripts and sysvinit from our repos and ask people to work on it elsewhere that's completely fine with me. My understanding was that we were switching to systemd as the default init system because maintaining two init systems was too much work and problems. My take is that it would be too much trouble to make all packages (polkit, networkmanager, gnome, ...) support both running under initscripts and systemd. Moreover, it is not really possible to improve initscripts to the point where it is competitive to systemd. So making systemd the default makes sense. However, maintaining the initscripts package as it currently is is not really a big problem from a technical point of view. Nor is maintaining non-systemd versions of the relevant packages in a separate repo. -remove initscripts from the repos -no more developement in git and on arch-project ML I don't see the benefit of doing that quickly, but if that's what you guys want, it is fine with me. I would be in favor of initscripts dying a natural death. -we can start removing rc.d scripts from packages as we update them That would be fine (and someone could gather them from svn and put them in a package in some third-party repo (as I suggested)). By letting initscripts become a user project, we will be able to use our resource on other aspects of the distro. I'm not suggesting that anyone but me should put any efforts at all towards supporting non-systemd systems. My point was exactly to get a user-driven project started (if anyone steps up). Also maintaining initscripts in repo also means maintaining the rc.d scripts. I don't think that follows. In the same way that systemd has been in community/extra/core for a long time without service files around, the same could be the case for initscripts. As most of us dev/TU are using (or will use) systemd, these will be harder to maintain and fix. I agree, rc scripts should be dropped as soon as they become a burden (which could be decided on a package-by-package basis). I don't know what you think about this but that's how I see things. Sorry if I created any confusion. Hope it is clear now. -t
Re: [arch-dev-public] The future of sysvinit in Arch: Call for Help
On Thu, Sep 27, 2012 at 5:30 PM, Tom Gundersen t...@jklm.no wrote: On Thu, Sep 27, 2012 at 10:22 PM, Eric Bélanger snowmanisc...@gmail.com wrote: I'm a bit confused by this post. I guess I should clarify my aim: As there are vocal proponents of sysvinit who feel strongly about staying with that, I'd rather help them get started in the right direction rather than cause lots of unnecessary confusion and fragmentation (as I alluded to at the end of my email I have seen some misguided attempts at doing this which I think would be detrimental to everyone). Where this work happens (if it happens), is not really anything I gave much thought. If it is the consensus that we should quickly drop initscripts and sysvinit from our repos and ask people to work on it elsewhere that's completely fine with me. My understanding was that we were switching to systemd as the default init system because maintaining two init systems was too much work and problems. My take is that it would be too much trouble to make all packages (polkit, networkmanager, gnome, ...) support both running under initscripts and systemd. Moreover, it is not really possible to improve initscripts to the point where it is competitive to systemd. So making systemd the default makes sense. However, maintaining the initscripts package as it currently is is not really a big problem from a technical point of view. Nor is maintaining non-systemd versions of the relevant packages in a separate repo. I've moved to systemd now but if the initscripts users are fine with that, then it's fine with me. -remove initscripts from the repos -no more developement in git and on arch-project ML I don't see the benefit of doing that quickly, but if that's what you guys want, it is fine with me. I would be in favor of initscripts dying a natural death. If there are people interested in maintaining it, then I have no objection that it stays in the repos. -we can start removing rc.d scripts from packages as we update them That would be fine (and someone could gather them from svn and put them in a package in some third-party repo (as I suggested)). Or put it in [extra] alongside the initscripts package. By letting initscripts become a user project, we will be able to use our resource on other aspects of the distro. I'm not suggesting that anyone but me should put any efforts at all towards supporting non-systemd systems. My point was exactly to get a user-driven project started (if anyone steps up). That's a good idea. It'll help the interested users to organize themselves. Also maintaining initscripts in repo also means maintaining the rc.d scripts. I don't think that follows. In the same way that systemd has been in community/extra/core for a long time without service files around, the same could be the case for initscripts. As most of us dev/TU are using (or will use) systemd, these will be harder to maintain and fix. I agree, rc scripts should be dropped as soon as they become a burden (which could be decided on a package-by-package basis). I don't know what you think about this but that's how I see things. Sorry if I created any confusion. Hope it is clear now. -t
[arch-dev-public] Away until Sept 2
Hi all, I will only have limited Internet access over the next three days. Please feel free to fix my packages even more diligently than you normally would. Cheers. -- Gaetan
