Re: [arch-dev-public] [RFC] dropping cpufrequtils
On Wed, Aug 15, 2012 at 2:46 AM, Tom Gundersen wrote: > Hi guys, > > As was discussed some time ago, I'd like to drop cpufrequtils from our > repos. It is dead upstream, and has been replaced by cpupower (in > community). > > I see no reason to move cpupower out of community, but let me know if > you disagree. > > The only blocker now is that gnome-applets depend on cpufrequtils and > cpupower is not binary/source compatible. There are patches around > though, so shouldn't be a big problem. > > Comments? > > Tom cpupower currently has no hook for pm-utils. I attached the one I'm using. gnome-applets are deprecated anyway (they don't work with gnome-shell). We can just kick out the cpufreq-applet. cpupower Description: Binary data
[arch-dev-public] [RFC] dropping cpufrequtils
Hi guys, As was discussed some time ago, I'd like to drop cpufrequtils from our repos. It is dead upstream, and has been replaced by cpupower (in community). I see no reason to move cpupower out of community, but let me know if you disagree. The only blocker now is that gnome-applets depend on cpufrequtils and cpupower is not binary/source compatible. There are patches around though, so shouldn't be a big problem. Comments? Tom
[arch-dev-public] Orphaning sysklogd
Hi, I'm orphaning sysklogd, an old logger pre-dating syslog-ng. With systemd internal logger and syslog-ng for those who still wants text file logs, I don't feel like adding service files to sysklogd. I'll move it to AUR in a few days if no-one adopts it. Eric
Re: [arch-dev-public] Migration to systemd
On Tue, Aug 14, 2012 at 10:57 AM, Stéphane Gaudreault wrote: > Systemd has a overall better design than SysV, lots of useful administrative > features and provide quicker boot up. Considering that it has been around in > our repositories for some time and that it could be considered stable enough > for production use, I would suggest to replace iniscript by systemd once the > 'Missing systemd units' is over. Thus we will avoid duplicating our efforts > on two init systems. > > Any objections to start the migration process ? > > Cheers, > > Stéphane > > +1. I don't use systemd or know how it works or compare to initscripts but I am aware that we'll need to switch to it eventually as more and more projects will depends on it. So the sooner the better. Eric
Re: [arch-dev-public] Migration to systemd
On Tue, Aug 14, 2012 at 4:57 PM, Stéphane Gaudreault wrote: > Systemd has a overall better design than SysV, lots of useful administrative > features and provide quicker boot up. Considering that it has been around in > our repositories for some time and that it could be considered stable enough > for production use, I would suggest to replace iniscript by systemd once the > 'Missing systemd units' is over. Thus we will avoid duplicating our efforts > on two init systems. > > Any objections to start the migration process ? > > Cheers, > > Stéphane > > +1 Ronald
Re: [arch-dev-public] Migration to systemd
Am 14.08.2012 16:57, schrieb Stéphane Gaudreault: > Systemd has a overall better design than SysV, lots of useful > administrative features and provide quicker boot up. Considering that > it has been around in our repositories for some time and that it could > be considered stable enough for production use, I would suggest to > replace iniscript by systemd once the 'Missing systemd units' is over. > Thus we will avoid duplicating our efforts on two init systems. > > Any objections to start the migration process ? > > Cheers, > > Stéphane > > +1 I use systemd on all my machines. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Migration to systemd
On Aug 14, 2012 7:17 PM, "Dave Reisner" wrote: > > On Tue, Aug 14, 2012 at 12:09:33PM -0500, Dan McGee wrote: > > On Tue, Aug 14, 2012 at 11:57 AM, Dave Reisner wrote: > > > On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote: > > >> On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote: > > >> > There are still a lot of unit files missing; we should create a todo > > >> > list. It would also be helpful to write down a simple wiki page with > > >> > some guidelines here. > > >> > > >> Did I miss something or did you miss the Jan's todo list[1]? > > >> > > >> > E.g. I am not sure if we should read those > > >> > /etc/conf.d/$damon files from the unit files as well or drop these as > > >> > the user should override unit files in /etc. > > >> > > >> Indeed, I was wondering if we should adapt our packages to the layout used by > > >> the upstream systemd services files. E.g. the upstream proftpd service sources > > >> /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd. > > > > > > So there is no standard for this, and the general recommendation is that > > > if you disagree with the default command line args the service in /lib > > > provides, you should simply override the service in /etc. If anything, > > > I'd vote that /etc/conf.d (or whatever other name you give it) should > > > slowly shrink/disappear over time. > > > > What does the non-standard think about distro-provided updates to the > > units? Seems like with overriding the whole thing rather than small > > pieces in a separate config file, it isn't obvious to the user when > > they need to merge updates to the unit files. > > > > -Dan > > It's possible to include unit files (.include /lib/systemd/), though > in practice, I haven't seen how well this works. There its also systemd-delta, which makes this much easier to deal with. Tom
Re: [arch-dev-public] Migration to systemd
On Tue, Aug 14, 2012 at 12:09:33PM -0500, Dan McGee wrote: > On Tue, Aug 14, 2012 at 11:57 AM, Dave Reisner wrote: > > On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote: > >> On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote: > >> > There are still a lot of unit files missing; we should create a todo > >> > list. It would also be helpful to write down a simple wiki page with > >> > some guidelines here. > >> > >> Did I miss something or did you miss the Jan's todo list[1]? > >> > >> > E.g. I am not sure if we should read those > >> > /etc/conf.d/$damon files from the unit files as well or drop these as > >> > the user should override unit files in /etc. > >> > >> Indeed, I was wondering if we should adapt our packages to the layout used > >> by > >> the upstream systemd services files. E.g. the upstream proftpd service > >> sources > >> /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd. > > > > So there is no standard for this, and the general recommendation is that > > if you disagree with the default command line args the service in /lib > > provides, you should simply override the service in /etc. If anything, > > I'd vote that /etc/conf.d (or whatever other name you give it) should > > slowly shrink/disappear over time. > > What does the non-standard think about distro-provided updates to the > units? Seems like with overriding the whole thing rather than small > pieces in a separate config file, it isn't obvious to the user when > they need to merge updates to the unit files. > > -Dan It's possible to include unit files (.include /lib/systemd/), though in practice, I haven't seen how well this works.
Re: [arch-dev-public] Migration to systemd
On Tue, Aug 14, 2012 at 6:57 PM, Dave Reisner wrote: > On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote: >> On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote: >> > There are still a lot of unit files missing; we should create a todo >> > list. It would also be helpful to write down a simple wiki page with >> > some guidelines here. >> >> Did I miss something or did you miss the Jan's todo list[1]? >> >> > E.g. I am not sure if we should read those >> > /etc/conf.d/$damon files from the unit files as well or drop these as >> > the user should override unit files in /etc. >> >> Indeed, I was wondering if we should adapt our packages to the layout used by >> the upstream systemd services files. E.g. the upstream proftpd service >> sources >> /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd. > > So there is no standard for this, and the general recommendation is that > if you disagree with the default command line args the service in /lib > provides, you should simply override the service in /etc. If anything, > I'd vote that /etc/conf.d (or whatever other name you give it) should > slowly shrink/disappear over time. > > d > This approach would also necessitate educating our users about running systemd-delta after upgrades. Users might end up having overridden units that got updated, and as a result, break.
Re: [arch-dev-public] Migration to systemd
On Tue, Aug 14, 2012 at 11:57 AM, Dave Reisner wrote: > On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote: >> On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote: >> > There are still a lot of unit files missing; we should create a todo >> > list. It would also be helpful to write down a simple wiki page with >> > some guidelines here. >> >> Did I miss something or did you miss the Jan's todo list[1]? >> >> > E.g. I am not sure if we should read those >> > /etc/conf.d/$damon files from the unit files as well or drop these as >> > the user should override unit files in /etc. >> >> Indeed, I was wondering if we should adapt our packages to the layout used by >> the upstream systemd services files. E.g. the upstream proftpd service >> sources >> /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd. > > So there is no standard for this, and the general recommendation is that > if you disagree with the default command line args the service in /lib > provides, you should simply override the service in /etc. If anything, > I'd vote that /etc/conf.d (or whatever other name you give it) should > slowly shrink/disappear over time. What does the non-standard think about distro-provided updates to the units? Seems like with overriding the whole thing rather than small pieces in a separate config file, it isn't obvious to the user when they need to merge updates to the unit files. -Dan
Re: [arch-dev-public] Migration to systemd
On Tuesday 14 August 2012 12:57:37 Dave Reisner wrote: > So there is no standard for this, and the general recommendation is that > if you disagree with the default command line args the service in /lib > provides, you should simply override the service in /etc. If anything, > I'd vote that /etc/conf.d (or whatever other name you give it) should > slowly shrink/disappear over time. Ok, so since there's no standard I'm fine with Pierre's idea to write the default parameters in the service files and drop the conf.d*whatever files. -- Andrea
Re: [arch-dev-public] Migration to systemd
On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote: > On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote: > > There are still a lot of unit files missing; we should create a todo > > list. It would also be helpful to write down a simple wiki page with > > some guidelines here. > > Did I miss something or did you miss the Jan's todo list[1]? > > > E.g. I am not sure if we should read those > > /etc/conf.d/$damon files from the unit files as well or drop these as > > the user should override unit files in /etc. > > Indeed, I was wondering if we should adapt our packages to the layout used by > the upstream systemd services files. E.g. the upstream proftpd service > sources > /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd. So there is no standard for this, and the general recommendation is that if you disagree with the default command line args the service in /lib provides, you should simply override the service in /etc. If anything, I'd vote that /etc/conf.d (or whatever other name you give it) should slowly shrink/disappear over time. d
Re: [arch-dev-public] Migration to systemd
On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote: > There are still a lot of unit files missing; we should create a todo > list. It would also be helpful to write down a simple wiki page with > some guidelines here. Did I miss something or did you miss the Jan's todo list[1]? > E.g. I am not sure if we should read those > /etc/conf.d/$damon files from the unit files as well or drop these as > the user should override unit files in /etc. Indeed, I was wondering if we should adapt our packages to the layout used by the upstream systemd services files. E.g. the upstream proftpd service sources /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd. [1] https://www.archlinux.org/todo/178/ -- Andrea
Re: [arch-dev-public] Migration to systemd
Am 14.08.2012 17:17, schrieb Dave Reisner: > For the future: > > - drop rc.conf compat for systemd. For me it actually caused some trouble that systemd reads rc.conf as well. > - finish the /usr migration. Not strictly related, but this makes > writing unit files easier imo. Also lets us drop a local patch against > systemd. > > In parallel, I'd love to see a working install media with systemd on it. > I've got some changes planned for arch-install-scripts (and devtools) to > use systemd-nspawn instead of all this manual chroot business (though > the manual fallback will remain) as its so much cleaner and easier > Note that this also requires some changes that will be in systemd 189. I'll definitely have a look at this when 189 is released. I am not sure if we can use nspawn in ais at we might actually want to see the chroot the real devices etc.. There are still a lot of unit files missing; we should create a todo list. It would also be helpful to write down a simple wiki page with some guidelines here. E.g. I am not sure if we should read those /etc/conf.d/$damon files from the unit files as well or drop these as the user should override unit files in /etc. We also might need to add a little force to push the migration process. E.g. at some point a missing unit file is a bug and might result in the package being dropped. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-dev-public] Migration to systemd
[2012-08-14 10:57:42 -0400] Stéphane Gaudreault: > I would suggest to replace iniscript by systemd Let's do it. It's about time we lose these ML trolls. -- Gaetan
Re: [arch-dev-public] Migration to systemd
On Tue, Aug 14, 2012 at 4:57 PM, Stéphane Gaudreault wrote: > Systemd has a overall better design than SysV, lots of useful administrative > features and provide quicker boot up. Considering that it has been around in > our repositories for some time and that it could be considered stable enough > for production use, I would suggest to replace iniscript by systemd once the > 'Missing systemd units' is over. Thus we will avoid duplicating our efforts > on two init systems. > > Any objections to start the migration process ? > > Cheers, > > Stéphane > > +1 from me. I want to be able to start getting rid of ConsoleKit where possible.
Re: [arch-dev-public] Migration to systemd
On Tue, Aug 14, 2012 at 5:17 PM, Dave Reisner wrote: > A few things to encourage this which were discussed on IRC: > > - merge systemd back to a single package (aside from sysvcompat) > - split off some of the tools from sysvinit (pidof, last, ...) > > For the future: > > - drop rc.conf compat for systemd. > - finish the /usr migration. Not strictly related, but this makes > writing unit files easier imo. Also lets us drop a local patch against > systemd. Another big +1 from me on this too. -t
Re: [arch-dev-public] Migration to systemd
On Tue, Aug 14, 2012 at 10:57:42AM -0400, Stéphane Gaudreault wrote: > Systemd has a overall better design than SysV, lots of useful > administrative features and provide quicker boot up. Considering > that it has been around in our repositories for some time and that > it could be considered stable enough for production use, I would > suggest to replace iniscript by systemd once the 'Missing systemd > units' is over. Thus we will avoid duplicating our efforts on two > init systems. > > Any objections to start the migration process ? At this point, I've had a _lot_ of people give the same feedback -- the transition is more or less seamless. As you mention, we're simply lacking the unit file coverage to make this the default. +1 to finishing off what we're obviously sitting in the middle of. A few things to encourage this which were discussed on IRC: - merge systemd back to a single package (aside from sysvcompat) - split off some of the tools from sysvinit (pidof, last, ...) For the future: - drop rc.conf compat for systemd. - finish the /usr migration. Not strictly related, but this makes writing unit files easier imo. Also lets us drop a local patch against systemd. In parallel, I'd love to see a working install media with systemd on it. I've got some changes planned for arch-install-scripts (and devtools) to use systemd-nspawn instead of all this manual chroot business (though the manual fallback will remain) as its so much cleaner and easier Note that this also requires some changes that will be in systemd 189. d
Re: [arch-dev-public] Migration to systemd
On Tue, Aug 14, 2012 at 4:57 PM, Stéphane Gaudreault wrote: > Systemd has a overall better design than SysV, lots of useful administrative > features and provide quicker boot up. Considering that it has been around in > our repositories for some time and that it could be considered stable enough > for production use, I would suggest to replace iniscript by systemd once the > 'Missing systemd units' is over. Thus we will avoid duplicating our efforts > on two init systems. > > Any objections to start the migration process ? A big +1 from me. As to the future of initscripts: I am (as I keep saying) committed to maintaining it as long as it is part of our repos (at some point I expect it will not be any more). We'll make sure that the transition to systemd is such that initscripts can still be installed for the time being if that is desired. However, I expect that third-party packages (gnome, NetworkManager, polkit, etc.) at some point will stop working well without systemd, so that is something to consider if you stick with initscripts. Cheers, Tom
Re: [arch-dev-public] Migration to systemd
On di, 2012-08-14 at 10:57 -0400, Stéphane Gaudreault wrote: > Any objections to start the migration process ? Go ahead. Maintaining 2 systems is a lot of duplicate work. Besides the duplicate work, you'll get covered in patches trying to support setups that avoid installing something new. Polkit is an example of this: we have a patch to make systemd optional at runtime, we request users to test it, and instead of testing it we end up with a 300+ posts thread about how bad Lennart is, with nearly no-one trying to investigate what is wrong about the patch and in which situations it doesn't work.
Re: [arch-dev-public] Migration to systemd
On Wednesday 15 August 2012 01:04:48 Allan McRae wrote: > +1 - this move needs done now. Delaying it longer will just be painful. I couldn't agree more. Go for it. -- Andrea
Re: [arch-dev-public] Migration to systemd
On 15/08/12 00:57, Stéphane Gaudreault wrote: > Systemd has a overall better design than SysV, lots of useful > administrative features and provide quicker boot up. Considering that it > has been around in our repositories for some time and that it could be > considered stable enough for production use, I would suggest to replace > iniscript by systemd once the 'Missing systemd units' is over. Thus we > will avoid duplicating our efforts on two init systems. > > Any objections to start the migration process ? > +1 - this move needs done now. Delaying it longer will just be painful. Allan
[arch-dev-public] Migration to systemd
Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems. Any objections to start the migration process ? Cheers, Stéphane
Re: [arch-dev-public] [arch-general] Lennart Poettering on udev-systemd
On 14/08/12 23:32, Thomas Bächler wrote: > > I wonder if there is a way to lock a thread in mailman. > My solution was to unsubscribe to arch-general... So all those long threads have achieved is that I will now make decisions with even less community input. Allan
Re: [arch-dev-public] [arch-general] Lennart Poettering on udev-systemd
On 14/08/12 23:32, Thomas Bächler wrote:
> I want to just add replaces=('initscripts')
> to the systemd package just to make this fucking "discussion" stop.
I'm doing nothing tomorrow...
Re: [arch-dev-public] [arch-general] Lennart Poettering on udev-systemd
Am 14.08.2012 15:08, schrieb Baho Utot:
>> Wow, this sounds so much like a conspiracy theory. The fact is that the
>> people who write the code inevitably dictate which software is
>> maintained,
>> based on their interests and convictions, and they're pretty much
>> unanimous
>> that systemd is a better solution to the problem of booting and
>> maintaining
>> daemons than the solution we currently have.
>>
>> So yeah, I guess that's been the game plan all along: make booting and
>> daemon
>> control more consistent, faster, and easier for most users to maintain.
>>
>> Paul
>
> I don't understand your point
>
> What is so wrong with the booting using sysvinit?
>
> I really don't need what systemd offers and sysvinit does everything I
> need and has not failed me.
And you don't want systemd because you are sure it won't do what
sysvinit can, even though you didn't try it.
> So is your point that I need to move to systemd because the developers
> tell me I must?
You need to move because the rest of the Linux ecosystem will require
systemd at some point, just like it now requires udev. If you don't like
it, then stop annoying us and start maintaining code that makes sure
YOUR way will keep working.
It's like that: Whoever contributes code makes the decisions.
> As for systemd being better solution for the problem of booting the
> beauty is in the eye of the beholder and I just don't see it, so why
> take away sysvint?
I could repeat what I said above.
> You can use systemd and I should be able to use what works for me and
> not be forced down the systemd path.
So, you are annoying the whole mailing list because you don't like that
you _might_ be forced to switch to a superior booting scheme which is
unlikely to affect you negatively in any way.
Arch's policy on systemd vs. initscripts has not even been discussed
among Arch developers yet, and nothing has been decided. Yet, you guys
are acting like someone's going to eat your childrn.
I can't stand this anymore. I want to just add replaces=('initscripts')
to the systemd package just to make this fucking "discussion" stop. If
you don't have anything _technical_ to discuss, and don't have any
problem that you want help solving, then move this bullshit somewhere I
don't have to see it.
I wonder if there is a way to lock a thread in mailman.
signature.asc
Description: OpenPGP digital signature
[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 13 fully signed off packages * 31 packages missing signoffs * 4 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.) == Incomplete signoffs for [core] (3 total) == * iproute2-3.5.0-1 (i686) 1/2 signoffs * net-tools-1.60.20120804git-2 (i686) 0/2 signoffs * iproute2-3.5.0-1 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (28 total) == * ethtool-1:3.5-1 (i686) 0/2 signoffs * gdk-pixbuf2-2.26.2-1 (i686) 0/2 signoffs * kdeplasma-applets-networkmanagement-1:0.9.0.4-1 (i686) 0/2 signoffs * libcap-ng-0.7-1 (i686) 0/2 signoffs * libdrm-2.4.38-1 (i686) 0/2 signoffs * lirc-1:0.9.0-25 (i686) 0/2 signoffs * network-manager-applet-0.9.6.2-1 (i686) 0/2 signoffs * networkmanager-0.9.6.0-1 (i686) 0/2 signoffs * networkmanager-openconnect-0.9.6.2-1 (i686) 0/2 signoffs * networkmanager-openvpn-0.9.6.0-1 (i686) 0/2 signoffs * networkmanager-pptp-0.9.6.0-1 (i686) 0/2 signoffs * networkmanager-vpnc-0.9.6.0-1 (i686) 0/2 signoffs * nvidia-304.32-2 (i686) 0/2 signoffs * openconnect-1:4.06-1 (i686) 0/2 signoffs * p11-kit-0.13-1 (i686) 0/2 signoffs * ethtool-1:3.5-1 (x86_64) 0/2 signoffs * gdk-pixbuf2-2.26.2-1 (x86_64) 0/2 signoffs * libdrm-2.4.38-1 (x86_64) 1/2 signoffs * lirc-1:0.9.0-25 (x86_64) 0/2 signoffs * network-manager-applet-0.9.6.2-1 (x86_64) 0/2 signoffs * networkmanager-0.9.6.0-1 (x86_64) 1/2 signoffs * networkmanager-openconnect-0.9.6.2-1 (x86_64) 0/2 signoffs * networkmanager-openvpn-0.9.6.0-1 (x86_64) 0/2 signoffs * networkmanager-pptp-0.9.6.0-1 (x86_64) 0/2 signoffs * networkmanager-vpnc-0.9.6.0-1 (x86_64) 0/2 signoffs * nvidia-304.32-2 (x86_64) 1/2 signoffs * openconnect-1:4.06-1 (x86_64) 0/2 signoffs * p11-kit-0.13-1 (x86_64) 0/2 signoffs == Completed signoffs (13 total) == * cryptsetup-1.5.0-2 (i686) * dhcpcd-5.6.0-1 (i686) * e2fsprogs-1.42.5-1 (i686) * iptables-1.4.15-1 (i686) * linux-3.5.1-1 (i686) * cryptsetup-1.5.0-2 (x86_64) * dhcpcd-5.6.0-1 (x86_64) * e2fsprogs-1.42.5-1 (x86_64) * iptables-1.4.15-1 (x86_64) * linux-3.5.1-1 (x86_64) * net-tools-1.60.20120804git-2 (x86_64) * kdeplasma-applets-networkmanagement-1:0.9.0.4-1 (x86_64) * libcap-ng-0.7-1 (x86_64) == All packages in [testing] for more than 14 days (4 total) == * kdeplasma-applets-networkmanagement-1:0.9.0.4-1 (i686), since 2012-07-29 * kdeplasma-applets-networkmanagement-1:0.9.0.4-1 (x86_64), since 2012-07-29 * lirc-1:0.9.0-25 (i686), since 2012-07-30 * lirc-1:0.9.0-25 (x86_64), since 2012-07-30 == Top five in signoffs in last 24 hours == 1. tomegun - 2 signoffs
