systemd support

[baptx]

If someone wants to use systemd to manage processes (like it is done on Sailfish OS), is there a way to support systemd or it is not possible at all because Maemo Leste operating system is based on Devuan instead of Debian? By the way, why is Maemo Leste based on Devuan instead of Debian?

[MerlijnWajer]

@spinal84 was working on a debian-based thing with systemd instead of devuan + openrc. I don't know what the status of it is.

[MerlijnWajer]

Also: https://leste.maemo.org/Leste_FAQ#Are_there_any_technical_merits_in_using_System_V_init_with_OpenRC_instead_of_systemd.3F

[baptx]

@MerlijnWajer thanks for the information, maybe you could add a link to the FAQ on https://maemo-leste.github.io/ so it is easier to find.

[MerlijnWajer]

Understood. Will try to add some links in the near future, and then close the ticket.

[spinal84]

Hello friends.

In fact, I was able to boot and run systemd based environment with hildon-desktop on my Nokia N900. I had noted all the actions needed to deploy systemd-based environment from scratch to make this process repeatable. Of course there is a lot of work remaining. But the significant part is complete.

I couldn't find much enthusiasm from Maemo Leste community about this in the past. So I abandoned the work.

If the wind has changed and there's real interest in systemd for Maemo Leste, I could take care of it. But we need to configure Debian based environment for Jenkins and add some repositories to the server.

[MerlijnWajer]

Hi @spinal84 !

I would be happy to have systemd support, next to OpenRC support. Do you know how we can do it next to OpenRC? I'm happy to host a Jenkins instance, but we don't want to build separate versions of mce, ke-recv, hulda, hildon-desktop, etc just because we have separate init systems, I imagine?

I reckon packages can have multiple init scripts, and depending on the init system in use, one of them would be used?

[sicelo]

@spinal84 from a user perspective, I am also interested in a version of Leste with systemd (I don't love sysd, nor hate it).

If it is possible to build them using existing infra, great. If not, perhaps you could still consider documenting it in the wiki, and if possible, you could even make private builds and share images somewhere :)

[MerlijnWajer]

Private builds don't make sense. Let's just see what we can do to have it integrated. I'm happy to host another jenkins for testing, but I think ultimately we probably just want both in the same repo.

[spinal84]

Hi @MerlijnWajer, @sicelo !

I'm not excluding that some packages will need to have separate branches/versions for systemd just because Debian and Devuan have diverted. You could already see one such example - it's UPower. I don't know why but Debian and Devuan have different versions of this util. I'm pretty sure we will find more examples of such diversions, so be prepared and don't be surprised.

Of course I will try hard to make packages support both init systems in one place.

If you still think that's a good idea, please confirm and let's start.

[sicelo]

If you still think that's a good idea, please confirm and let's start.

ACK

[MerlijnWajer]

What we do for leste and leste-devel repo is having separate branches: maemo/ascii and maemo/ascii-devel, we could have something like leste-systemd and maemo/ascii-systemd (probably maemo/stretch-systemd) and have it end up in a systemd component. So then in the apt line in /etc/apt/sources.list you'd have to add the systemd component to get those versions?

[spinal84]

@MerlijnWajer, I think that could be a good point to start with. It won't be a huge problem to rename stuff if we find something to be more logical.

[MerlijnWajer]

I can make the Jenkins changes for that tomorrow probably - need @parazyd for a few things though.

[MerlijnWajer]

@spinal84 - didn't get to doing it today, but @parazyd is back, and I'll check with him this weekend if we can do it with just a 'separate' branch, or if we need another jenkins instance or more changes.

[MerlijnWajer]

@spinal84 - @parazyd said that you should be able to just work in maemo/ascii and maemo/ascii-devel and add unit files to packages without issues using our existing jenkins, without any changes.

Want to try that and see how that goes?

[spinal84]

@MerlijnWajer, xorg-server and upower have different package versions in Debian and Devuan systems. How can this be solved by adding unit files?

An issue example: https://github.com/maemo-leste/status-area-applet-battery/pull/2#issuecomment-445428771

I prefer not to start (continue) my work on systemd until we have prepared basic infra for it. So I won't get my time wasted.

Systemd is not just an init system. It has a lot of system integration utils and services we might use to simplify things and save our (developers) time for more intensive Maemo Leste developing. Systemd helped me a lot when I debugged N900 GPU problems. One such thing was rapid rebooting which I did a lot of times per day.

[MerlijnWajer]

I don't see why you could not use the xorg server that we package in leste repo on Debian?

As for upower, I don't know what "anti-systemd" patches were applied, but maybe there were patches applied to make UPower work on systems that are non-systemd as well.

I know systemd is not just an init system - that's why we initially went for OpenRC as init system - because we needed an init system, not a way of life. ;-)

I'd be happy to see Maemo Leste run on systems with systemd (presumably based on Debian). So you think a package like upower (which we provided a patched version of, we could provide one that works with both init systems for both devuan and debian) will make your life unnecessarily complicated?

I don't know what the status of your previous systemd work was, how you got there (used debian, and then, add our repo?), etc.

[MerlijnWajer]

I'm interested in the time saving measures you mention though.

[spinal84]

The following packages have unmet dependencies: xserver-xorg-core : Depends: libeudev1 but it is not installable

[MerlijnWajer]

Alright, I see. That's a problem indeed. Either we can:

1. Clone the existing jenkins to a different repo (for now), means we won't share any packages for now
2. Go with the maemo/ascii-systemd branch, where you can build or import the debian xserver-xorg-core and make sure it's a higher version than the one provided in maemo/ascii

[spinal84]

The first option is very much preferred.

[spinal84]

About branch naming scheme. Something like "maemo/stretch", "maemo/stretch-devel", "maemo/buster" will be just fine. I.e. there's no need in "systemd" part in branch names.

[parazyd]

@spinal84 To avoid the double work, and actually building things twice, is there a chance we could fix the issues you ran into? Just lay them out and we can see what can be done.

I'd like to see a better overview of the issues and if possible - find a way to avoid building all the software twice, plus you working in a different branch than everyone else.

[spinal84]

I can't lay issues just because I don't know what issues I will have in the future. I already mentioned the first one I ran into.

The following packages have unmet dependencies:
xserver-xorg-core : Depends: libeudev1 but it is not installable

If you know how to fix it without making another repo, just do it.

[spinal84]

To avoid building all things twice we can introduce 3 repositories:

1. Debian specific packages
2. Devuan specific packages
3. System independent packages

By default all packages will go into (3). When there are issues related to "systemd vs non-systemd" we will drop problematic package from repository (3) and place it into (1) and (2).

[dderby]

I can't lay issues just because I don't know what issues I will have in the future. I already mentioned the first issue I ran into.

The following packages have unmet dependencies:
xserver-xorg-core : Depends: libeudev1 but it is not installable

If you know how to fix it without making another repo, just do it.

You probably just need to change the xserver-xorg-core package dependency from libeudev1 to libeudev1 | libudev1.

[spinal84]

You confuse runtime dependencies with build time dependencies. Google what "dynamic linking" is. Of course I may be wrong. If so, I'm awaiting for your pull request. The problematic package is https://github.com/maemo-leste/xorg-server

[dderby]

I wouldn't get your hopes up. Testing would require time and effort and there are far more important things to be worked on than adding systemd support. I know what dynamic linking is. I never said I know how to fix the issue. I suggested a possible fix based the error message you provided, and the fact that udev has been replaced with eudev in Devuan and they should be functionally the same.

I happen to loathe systemd but I don't mind helping others if I think I might be able to provide some insight without much effort. We already have OpenRC which works great. I don't take kindly to being ordered to fix something, especially a systemd issue. Please don't do it again.

EDIT: I see you've deleted your post. Thank you.

[spinal84]

If you can't help, please don't waste our time.

[spinal84]

@MerlijnWajer

2. Go with the maemo/ascii-systemd branch, where you can build or import the debian xserver-xorg-core and make sure it's a higher version than the one provided in maemo/ascii

Let's change the proposition to:

2. Go with the maemo/stretch branch, where you can build or import the debian xserver-xorg-core and make sure it's a higher version than the one provided in maemo/ascii

And I'm fine with it.