Manjaro-openrc will be discontinued



I am glad my messing around helps then :slight_smile:


I would keep it as a rumour till it transpires


i’m trying to transition from archlinux openrc to artix but i have some troubles signing the keys? i already forced the artix-keyring since pacman said it was corrupted… but i can’t find you keyid @artoo to sign it. pacman complains about all packages being corrupted. any ideas?


I gave up, too many glitches and I can’t get it nowhere close to what I have here in ManjaroOpenRC. I’ll run it till it dies.
I didn’t realize how addictive pamac can be. The one I got from manjaro worked well, when I switched to the AUR edition it sucked.
And I am not willing to give up lxde for lxqt, I’d rather go to xfce.


Yeah, the guide misses something, populating the keyring for artix.

pacman-key --populate cromnix

Should do, granted you got the artix-keyring package installed.
If not, use

pacman -U


if you just want a graphical way to search, and you’re now using (partially) the arch repos, you can search on arch’s site


Someone asked about manjaro-architect. I looked at the procedure to convert manjaro to artix, and it would not be that difficult to alter manjaro-architect to install artix when user chooses openrc version of a profile. Would just need to add the artix repos and update the package lists. This could help artix to get more desktops, as you could use the manjaro desktops for artix.

However, there are issues. Here are just two from the top of my headň

  1. it would confuse the line between manjaro and artix, because the configured desktops would be branded for manjaro even though the core would be artix. This would confuse users seeking technical assistance
  2. it would make a lot of extra maintenance work, and require communication and co-operation between manjaro iso maintainers and artix team. With help, maintainers would have difficulty to keep their openrc profiles working.

I’ll be looking into this matter, but unfortunately there is a significant chance that maintaining openrc option is not feasible. Which is kind of sad, I really liked that option. But for the future of openrc, artix is probably for the best, and can attain a a level of stability that was not festivaali with manjaro+openrc.


It was me that asked. It’s not the answer I was hoping for, but it’s certainly understandable, and I appreciate the considered response. Thanks.



If there’s a split from Manjaro OpenRC to Artix then Manjaro shouldn’t spend any effort on that - it’s like having plain Arch (or Ubuntu) as an option for Architect.

OpenRC has always had a slightly unofficial status in Manjaro so if there’s a split I don’t think Manjaro should do anything special to support it - we need to keep the effort focussed on core issues (e.g. hybrid graphics), not smoothing out edge-cases.

Essentially, it’s up to the Artix devs to make migration possible - they’re the ones splitting from Manjaro (etc.) (though obviously Manjaro shouldn’t do anything to make it difficult). It’s basically the same situation as Devuan - Debian haven’t blocked or prevented anything, but it was up to the Devuan devs to make migration easy.


Someone can fork it and call artix-architect maybe.

So far artix is a very good concept, especially under the hood. The ISO installs, works and updates just fine if the user accepts that not everything is immediately available. And users ought to be more patient!

@fungilife, @kernelKurtz, @polaca57: This is a technical topic. There is a topic in Off-Topic category, where many posts will be moved now.


I will package pamac into the galaxy repo during the week.


Thats technically speaking not true any longer with latest openrc(not available on manjaro already), it uses openrc grown sysvcompat, and we have the option to switch over to s6 or runit instead of sysvinit compat altogether.


By the way, the grub entries created by artix for Manjaro are as problematic as all other distributions. Manjaro (with OpenRc) will not start with the grub.cfg Artix creates. Why is it so hard for grub to adopt the peculiarity of Manjaro?


You can also install TKpacman works just fine no AUR support mind you but the yoguart does a excellent job of package searches as well


I liked your idea, I thinks it’s great.
Could have a big message saing that the core would change to artix.


Becuase we also don’t install intel-ucode by default. Hence it won’t detect manjaro’s intel-ucode addition to grub, like many other distro also won’t do.



Some changes are interesting here :).

If you want to centralize packages, some stuff risk to be difficult to resolve, not impossible but difficult to do it with a good way.
First the gpg signatures need to be present in the packages and the database on the ftp server too. It mean that a general package (currently i have my own called obarun-keyring) for all the spin need to be present with all the necessary coming from different packager on it.
Second, all the packager need to have a root access to the ftp server.
Third, all the packager need to have access at the source of the PKGBUILD ( a general github account or other) without doing pull request or some annoying stuff like this.
Fourth, the name of the ftp place and the PKGBUILD place need to be independant from the spin. Called the github account or the sourceforge account Artix have no sense if you want to use it a central place. The spin and the source need to be differenciate easily by the user. For example the github account can be : fuckoff-systemd ( :smiley: ) then you have your script stuff for artix in an other place.
Fifth, having a general place for users like AUR can be a good good idea. obviously called e.g FSUR (fuckoff-systemd user repositories).
Sixth, a general money account for centralising donation which will used to pay the necessary stuff for all this work. Ho yes sorry users, all this kind of works take time and MONEY because the electricity is not free, the server is not free, the wasting time is not free… it’s free to you but not free for the workers (i thinks people doesn’t realize that).

well, this is my thought


Good points @obarun

Let’s discuss this with the entire team. @agisci @aaditya @mrgreen64

Let me just quickly describe how I do it on artix with PKGBUILDs.

pkg repos:

  • system(-testing)
  • world(-testing)
  • galaxy(-testing)

git repos:

  • system

    • artix branch
    • archlinux import branch
    • testing branch
  • world

    • artix branch
    • archlinux import branch
    • testing branch
  • galaxy

    • artix branch
    • archlinux import branch
    • testing branch

We got a script that basically imports archlinux PKGBUILDs that we can take to build without changing them, libraries for example, stuff not tied to systemd.
The artix branch contains our systemd free packages
Both branches merged together give the full tree for the repo.

I guess this could be a workable model in combination with your point.



I guess you could use our tools too, I just implemented a basic s6 and runit support for creating iso. build tools and deployment tools too. Would be no problem to adopt new hosting source other than SF.


i did the steps, but when i try to switch off or reboot i come back to sddm
what am i missing ?

i think i had a wrong package, but after an hard reboot i had the control on it.

but i have a problem with password in sddm
i tried it in “user” in case of, and the keymap is well configured but i can’t log in, i had to change my password.

thx for your work by the way