OpenRC & eudev on Arch

artoo · 2012-11-19 16:12:37

apq, I noticed yesterday the openrc source needs to be patched.

The consolefont.in specifically, located in src/openrc/init.d/

consolefont points to a gentoo consolefont path, on Arch, it should read /usr/share/kbd/consolefonts.

Patch is here...
https://github.com/udeved/openrc-pkgbui … svinit-git

I am going to provide binary amd64 test packages here:

openrc4arch.site40.net

Last edited by artoo (2012-11-20 12:39:30)

fbt2lurker · 2012-11-20 10:15:49

I've written a simple arch install script that (optionally) installs OpenRC side-by-side with systemd and attempts some basic configuration: https://bitbucket.org/fbt/scripts/src/5 … at=default
I wouldn't really recommend using it as is, but it may be an inspiration for someone to write a good one

P.S. Someone has already snatched my nick here. Nice.

Jristz · 2012-11-20 15:51:08

for the udev problem

eudev (the gentoo fork) + consolekit-git can by usefull I think, for relly only in openRC whitout systemd (not sure about dbus)

Thaodan · 2012-11-20 20:54:21

Jristz wrote:

for the udev problem
eudev (the gentoo fork) + consolekit-git can by usefull I think, for relly only in openRC whitout systemd (not sure about dbus)

Dbus is not a part of systemd, i hope that will be not changed its already fat.

tomegun · 2012-11-21 13:17:23

Jristz wrote:

eudev (the gentoo fork) [...] can by usefull I think, for relly only in openRC whitout systemd

I'd strongly advice against that. Looking through the initial commits to eudev it appears the people behind it don't know what they are doing. Luckily, it is relatively easy to just build/install udev from the systemd sources.

x33a · 2012-11-21 13:24:33

@ tomegun,

If we compile a standalone udev from systemd sources, will it be a drop-in for systemd-udev?, i.e., will the packages depending on udev need to be recompiled.

tomegun · 2012-11-21 13:51:25

x33a wrote:

@ tomegun,
If we compile a standalone udev from systemd sources, will it be a drop-in for systemd-udev?, i.e., will the packages depending on udev need to be recompiled.

It will be a drop-in replacement. The simplest way to do it is to do what we did originally before systemd became default in Arch: build the regular systmd package, but delete everything that is not wanted (i.e., everythnig that is not part of udev). You could then call this package "udev" and you will not have to recompile anything.

If you absolutely want to avoid compaling systemd, then you can do that too, but you'd probably want to write your own Makefile.

-t

x33a · 2012-11-21 15:12:56

Thanks for the details. I am too lazy to strip udev from systemd, but the procedure sounds simple enough for those who do want to.

Last edited by x33a (2012-11-21 15:13:09)

tomegun · 2012-11-21 15:54:33

@x33a: yeah, don't get me wrong, the only thing that makes any sense is to just install the whole systemd package, even if you only use parts of it. i just wanted to point out that if people DO decide they want to avoid building/installing superfluous stuff, then using one of the two forks is probably not the best way.

smil3y · 2012-11-21 18:10:57

Or just compile the udev fork of braindamaged (https://bitbucket.org/braindamaged/udev), PKGBUILDs and stuff you may find useful:

https://bitbucket.org/smil3y/pkgbuilds/src, packages without PAM, Polkit, ConsoleKit and systemd support (where possible)
https://bitbucket.org/smil3y/new-pkgbuilds/admin, packages without systemd support (there are a few packages that I still need to import from the first one tough)

I'm maintaining both but the first one seems overkill. The second one is my current playground.

artoo · 2012-11-21 18:21:09

Update:

The repo works now, and signing should work too. The key has been uploaded to keyserver.
It avoids further confusion with AUR and different openrc builds.
The repo packages depend on openrc4arch interface, which is provided by openrc4arch package.

http://www.openrc4arch.site40.net

Updated packages and meta packages will follow soon.

I have made the additional openrc services modular, plugins, depending on the respective arch (service) package.

It is useful to set makepkg path other than /tmp with tmpfs if you plan to build the packages yourself, as the plugins access one shared git data repository to reduce network traffic.

tomegun · 2012-11-21 18:59:50

smil3y wrote:

Or just compile the udev fork of braindamaged (https://bitbucket.org/braindamaged/udev),

I really wouldn't. It is not compatible, and will likely require you to rebuild everything. Moreover, instead of just maintaining one patch against the systemd build system, they are making a big mess for themselves by making lots of unnecessary changes and attempting to back port everything systemd does on top of that. I can't imagine this project surviving for long.

It would have been so simple to do a sane udev fork, I don't get why all the forks that are cropping up are so crazy...

artoo · 2012-11-21 19:10:14

tomegun wrote:

smil3y wrote:
Or just compile the udev fork of braindamaged (https://bitbucket.org/braindamaged/udev),
I really wouldn't. It is not compatible, and will likely require you to rebuild everything. Moreover, instead of just maintaining one patch against the systemd build system, they are making a big mess for themselves by making lots of unnecessary changes and attempting to back port everything systemd does on top of that. I can't imagine this project surviving for long.
It would have been so simple to do a sane udev fork, I don't get why all the forks that are cropping up are so crazy...

I agree about using a fork momentarily on Arch. It will likely break a lot of stuff.

You pointed out the gentoo way, they simply do a standalone build from systemd sources.
This should be fine as long as the all swallowing black hole systemd doesn't further absorb stuff and makes it in some way depending on systemd.

I will probably add a udev standalone package to the repo, depending on openrc(or sysvinit, undecided) as init system.
It is in the work but needs serious testing.

Last edited by artoo (2012-11-21 19:13:09)

smil3y · 2012-11-21 19:15:31

tomegun wrote:

smil3y wrote:
Or just compile the udev fork of braindamaged (https://bitbucket.org/braindamaged/udev),
I really wouldn't. It is not compatible, and will likely require you to rebuild everything. Moreover, instead of just maintaining one patch against the systemd build system, they are making a big mess for themselves by making lots of unnecessary changes and attempting to back port everything systemd does on top of that. I can't imagine this project surviving for long.
It would have been so simple to do a sane udev fork, I don't get why all the forks that are cropping up are so crazy...

True, that includes (currently) 15 from core, 690 from extra and 809 from community which is not impossible but requires a good automation and a server to handle that on own.

BTW the udev fork of braindamaged works fine here.

tomegun · 2012-11-21 19:17:51

artoo wrote:

This should be fine as long as the all swallowing black hole systemd further absorbs stuff and makes it in some way depending on systemd.

I would not worry about this happening anytime soon: Ubuntu does not use systemd and Ubuntu dev Martin Pitt is an active udev dev with commit access to systemd. The rest of the systemd devs are committed to keep working with him, so as long as Ubuntu does not use systemd I would not worry.

The day udev gets a hard dep on systemd, would be the day to fork. I don't expect this to happen, but if it does I would suggest seeing what Martin does and follow him.

Last edited by tomegun (2012-11-21 19:19:08)

Lone_Wolf · 2012-11-21 21:40:48

I've read a bit about OpenRC and it looks like the best alternative for systemd sofar.

However, programs like cups, sane, KDE and Gnome applications bring polkit in as dependency.
polkit requires logind and several people have stated programs that rely on polkit/logind only work correctly when the system has been booted with systemd.

Does OpenRC provide an alternative for logind, or is that beyond the scope of OpenRC ?

WorMzy · 2012-11-21 21:52:35

I imagine that you'd have to recompile logind-dependent packages with consolekit support and use that.

Lone_Wolf · 2012-11-21 21:57:48

As consolekit is no longer maintained, and the last git commit was made on march 20 2012, that seems like a solution that's far from future-proof.

Gusar · 2012-11-21 22:04:43

polkit doesn't necessarily require logind, that's just the default config, you can make it use unix groups. Not sure what the security implications of that are, but it's doable: http://www.reddit.com/r/archlinux/comme … oting_and/

smil3y · 2012-11-21 22:26:57

Gusar wrote:

polkit doesn't necessarily require logind, that's just the default config, you can make it use unix groups. Not sure what the security implications of that are, but it's doable: http://www.reddit.com/r/archlinux/comme … oting_and/

That's one of the reasons I pointed out my own PKGBUILDs, https://bitbucket.org/smil3y/pkgbuilds/ … ?at=master eliminates the need of systemd and PAM. How good or bad that is as some may say that compiling without PAM may leave a security hole in the system is another topic of its own.

Last edited by smil3y (2012-11-21 22:46:30)

artoo · 2012-11-21 22:39:33

Lone_Wolf wrote:

I've read a bit about OpenRC and it looks like the best alternative for systemd sofar.
However, programs like cups, sane, KDE and Gnome applications bring polkit in as dependency.
polkit requires logind and several people have stated programs that rely on polkit/logind only work correctly when the system has been booted with systemd.
Does OpenRC provide an alternative for logind, or is that beyond the scope of OpenRC ?

Absolutely no problem so far. polkit does not need logind, and there is a polkit-consolekit build in AUR.
I could probably add the binary package to the repo.

Basically, OpenRC does not provide login managing abilities. it its dependency based init system, the login manager is your choice.

Anyway, Gentoo uses CK by default. I guess for the lack of alternatives.

Last edited by artoo (2012-11-21 22:46:47)

Lone_Wolf · 2012-11-21 22:42:32

thanks, Gusar & smil3y .

@smiley :
polkit ./configure has this option

--enable-libsystemd-login=[auto/yes/no]
                          Use libsystemd-login (auto/yes/no)

maybe you can simplify the patch you use ?

Back on topic :
With an option to solve the logind problem, i really need to find time to test OpenRC in a VM.

Artoo, please continue the good work.

--------------------
Added

Artoo wrote:

Basically, OpenRC does not provide login managing abilities. it its dependency based init system, the login manager is your choice.

Leaving such choices to the user is exactly how i prefer it, OpenRC is now definitely #1 on my list of systemd replacements.

Last edited by Lone_Wolf (2012-11-21 22:51:00)

Mr Green · 2012-11-22 05:21:21

I can manage in a VM without a login manager but would like the option to use one, looking for xdm deamon [maybe in one of the openrc git packages in AUR]

Do have networkmanager working but not nm-applet so thinking either udev or dbus is not working correctly. And need to look at automounting.

Need to read up some more

artoo · 2012-11-22 17:09:09

Mr Green wrote:

I can manage in a VM without a login manager but would like the option to use one, looking for xdm deamon [maybe in one of the openrc git packages in AUR]
Do have networkmanager working but not nm-applet so thinking either udev or dbus is not working correctly. And need to look at automounting.
Need to read up some more

Displaymanager works flawlessly.

I'd recommend you get the more current packages from the repo I posted.
The ones in AUR I submitted won't be maintained further and are not compatible with the repo builds.

Once you installed the DM plugin, just change /etc/conf.d/xdm and let it point to your DM you installed. The polkit-consolekit and consolekit-git from AUR are needed and should be added to default runlevel. These packages are pulled in by the openrc4arch-consolekit-plugin.

Last edited by artoo (2012-11-22 17:10:36)

artoo · 2012-11-22 17:26:00

A question concerning PKGBUILDs.

How do I set a default(or 'all') value for virtual packages?

Like if I install base, the default is 'all'.

How are these packages ordered/numbered? In alphabetic order?

I gathered, one of the limitations are 'or' depends?

In what build is "base" defined? I haven't found it yet in ABS.

Last edited by artoo (2012-11-22 17:28:47)

Arch Linux

#51 2012-11-19 16:12:37

Re: OpenRC & eudev on Arch

#52 2012-11-20 10:15:49

Re: OpenRC & eudev on Arch

#53 2012-11-20 15:51:08

Re: OpenRC & eudev on Arch

#54 2012-11-20 20:54:21

Re: OpenRC & eudev on Arch

#55 2012-11-21 13:17:23

Re: OpenRC & eudev on Arch

#56 2012-11-21 13:24:33

Re: OpenRC & eudev on Arch

#57 2012-11-21 13:51:25

Re: OpenRC & eudev on Arch

#58 2012-11-21 15:12:56

Re: OpenRC & eudev on Arch

#59 2012-11-21 15:54:33

Re: OpenRC & eudev on Arch

#60 2012-11-21 18:10:57

Re: OpenRC & eudev on Arch

#61 2012-11-21 18:21:09

Re: OpenRC & eudev on Arch

#62 2012-11-21 18:59:50

Re: OpenRC & eudev on Arch

#63 2012-11-21 19:10:14

Re: OpenRC & eudev on Arch

#64 2012-11-21 19:15:31

Re: OpenRC & eudev on Arch

#65 2012-11-21 19:17:51

Re: OpenRC & eudev on Arch

#66 2012-11-21 21:40:48

Re: OpenRC & eudev on Arch

#67 2012-11-21 21:52:35

Re: OpenRC & eudev on Arch

#68 2012-11-21 21:57:48

Re: OpenRC & eudev on Arch

#69 2012-11-21 22:04:43

Re: OpenRC & eudev on Arch

#70 2012-11-21 22:26:57

Re: OpenRC & eudev on Arch

#71 2012-11-21 22:39:33

Re: OpenRC & eudev on Arch

#72 2012-11-21 22:42:32

Re: OpenRC & eudev on Arch

#73 2012-11-22 05:21:21

Re: OpenRC & eudev on Arch

#74 2012-11-22 17:09:09

Re: OpenRC & eudev on Arch

#75 2012-11-22 17:26:00

Re: OpenRC & eudev on Arch

Board footer