Update: the #systemd merger is in progress. We recommend NOT updating your devices which are running #postmarketOS edge until this is complete.
We are currently working through some issues with the changes to https://build.postmarketos.org
A full explanation of the changes and our recommendations for migrating your devices to systemd will be published once things are ready!
In the mean time, refresh https://build.postmarketos.org at will
https://fosstodon.org/@postmarketOS/113798746780556806
=> More informations about this toot | More toots from postmarketOS@fosstodon.org
well, ideally not too fast :D
=> More informations about this toot | More toots from postmarketOS@fosstodon.org
EDIT: this should no longer be necessary, please ensure your pmbootstrap is up to date (latest git master) and if you did run the below command reset it with pmbootstrap config -r mirrors.systemd (after updating)
if you're trying to use pmbootstrap and run into an issue because the systemd staging repo can't be found, doing the following will prevent it from attempting to fetch the (now missing) repo
$ pmbootstrap config mirrors.systemd none
=> More informations about this toot | More toots from postmarketOS@fosstodon.org
@postmarketOS I hope OpenRC will keep working :mastogrin:
=> More informations about this toot | More toots from yngmar@social.tchncs.de
@yngmar https://postmarketos.org/edge/2025/01/09/systemd-soon/
=> More informations about this toot | More toots from postmarketOS@fosstodon.org
@yngmar @postmarketOS Just curious, do you have any reason to prefer OpenRC beyond "systemd is bloated" or something like that?
=> More informations about this toot | More toots from newbyte@mastodon.nu
@newbyte @postmarketOS Yup.
=> More informations about this toot | More toots from yngmar@social.tchncs.de
@yngmar @newbyte @postmarketOS do you mind sharing it with the class?
=> More informations about this toot | More toots from craftyguy@freeradical.zone
NOOOOO!!!! PostmarketOS is adding system-shit-d?! God damn it. You were one of the good ones!
Edit: oh phew 😰 It's optional. Good!
=> More informations about this toot | More toots from djsumdog@djsumdog.com
@djsumdog @postmarketOS They were never good - all PostmarketOS images are proprietary software as they always use only the proprietary version of Linux (but that's to be expected of a distro that puts in BusyBox instead of GNU/Freedom).
=> More informations about this toot | More toots from Suiseiseki@freesoftwareextremist.com
@djsumdog @postmarketOS I've seen similar sentiments from the alpine devs
=> More informations about this toot | More toots from mischievoustomato@0.5dollah.click
@mischievoustomato @djsumdog @postmarketOS the problem iirc is that openrc has been kinda unmaintained for a long time and distros aren't exactly happy with the state of the project. my gf is fixing that tho, she recently has become a maintainer and also did a bunch of things like user services. currently i think she's doing readiness notifications. the goal is to make it competitive with systemd, but without all the horrible decisions
=> More informations about this toot | More toots from lizzy@social.vlhl.dev
@lizzy @djsumdog @postmarketOS good luck to her! That said, pOS stated that one of the reasons for wanting to move to systemD is that DEs depend more and more on systemD and that some other things to have systemd-features are also unmaintained. All in all, good luck. I'm just a bystander since I only run systemd distros.
=> More informations about this toot | More toots from mischievoustomato@0.5dollah.click
Gentoo, Void and Alpine have all been using things like elogind and forks of other things to decouple desktop environments from systemd. I really want all these to continue so at least people have options.
Alpine wasn't able to use systemd since it doesn't compile on musl, but there's been considerable work on musl patches, so they might jump ship as well. 😕
=> More informations about this toot | More toots from djsumdog@djsumdog.com
@lizzy @djsumdog@djsumdog.com @postmarketOS the proposed user services support seems quite interesting, it would be great to see openrc embracing more modern approaches - the biggest being moving away from shell scripts for service definitions.
Is there some plan for taking over openrc-settingsd? Or maybe following the Chimera (and now likely Alpine) approach of embracing the more widely standardised aspects of systemd (logind, udev and other freedesktop APIs)?
There's some folks hanging in the #postmarketos-openrc channel who maye be interested too (although not much has happened there in the 8 months since it was created)
=> More informations about this toot | More toots from cas@treehouse.systems
@cas @postmarketOS I don't see shell script services as a big problem. OpenRC services are declarative already, it's just that the declarativity works via shell variables and functions rather than, say, ini fields like systemd. It's not comparable to sysvinit or whatever, it's just that shell is the format they use, and that brings some conveniences while still having all the advantages of a declarative format.
And btw, the user services are no longer a proposal, they've been merged a few days ago :)
regarding the rest, ping @navi
=> More informations about this toot | More toots from lizzy@social.vlhl.dev
@lizzy @cas @postmarketOS
i think completely removing shell scripting would be a huge detriment to openrc, being able to define _pre or _post functions to do sanity checks inline instead of having to tie in secondary scripts/binaries is really nice, and defining custom commands like reload, check, save, restore, etc can be really nice for services that have such needs
what i do want to do is improve the declarative-ish variables, introducing easy to use namespaces under linux (networks, mount, etc), readiness notification (s6 newline style and systemd "READY=1" style), etc
there is a WIP pr for readiness notification already too
wrt to user services, the core merged (2 days ago!!), and i'm currently improving the implementation of the pam module for auto-start upon login, so openrc 0.60 (aka the next release) will have user services, and hopefully readiness notification
Is there some plan for taking over openrc-settingsd? Or maybe following the Chimera (and now likely Alpine) approach of embracing the more widely standardised aspects of systemd (logind, udev and other freedesktop APIs)?
i do want to either improve or take-over/fork/replace similar things, but i don't necessarily want to tie them to openrc unless extremely necessary. going for an open approach were people can use tools by themselves and integrate things in a modular way, tho i still didn't study openrc-settingsd yet to see how to handle that use case.
for logind, we already have half of it solved by seatd, the seat management part, and thus i want to look into the login management part, elogind is massive hack that barely works with each systemd update, turnstile... exists? so i need to study this part
there's also consolekit which freebsd still uses, and now a days consolekit also implements the logind c api and login1 (tho with another dbus endpoint as the name, so it's not a 1:1 replacement)
udev for now is on the really back burner because systemd-udev is easily buildable from the systemd tree without depending on systemd or even glibc at all. same goes for systemd-tmpfiles
=> More informations about this toot | More toots from navi@social.vlhl.dev
@navi @postmarketOS @lizzy ooh, ok sounds super interesting. ill be curious to see how this all shapes out, i'm happy to see alternatives to the hegemony and more interest being taken in actually meeting the needs that systemd fills.
=> More informations about this toot | More toots from cas@treehouse.systems
FYI: anyone calling systemd systemd-shit-d will get an appropiate shitpost linked with libsystemd-shared and on my blocklist.
=> More informations about this toot | More toots from jane@smolhaj.social
@postmarketOS really looking forward to this stabilising and absolutely amazed by the extra support the team has provided across the community today. Thank you to all involved.
=> More informations about this toot | More toots from dubstar_04@fosstodon.org This content has been proxied by September (3851b).Proxy Information
text/gemini