Regolith 2.x updates, possible contributions??

[SoumyaRanjanPatnaik]

Hey.
I am an avid arch user. I recently contributed to regolith under GSoC and I really want to use it as my daily driver. I was going to install all the packages on arch one by one by myself, but I found this repo. I was hoping to contribute to this repository to help port regolith 2.x to arch. If you can breif me on the current status, I'll start working on this and try to create a few PRs.

[gardotd426]

Jesus, it's about time I get an single genuine offer for some help with this. Im going to send this short acknowledgement comment so you know I got your message and am in the process of responding.

[thebashpotato]

I want regolith on arch as well. I'm more than willing to spend time on the project, however I'm not very familar on how regolith works. If there were tickets on a project board or something I'd be more than happy to start working on them.

[SoumyaRanjanPatnaik]

Great. Let me know what I can do.

[SoumyaRanjanPatnaik]

BTW, I was looking at the PKGBUILD, and the first thing I saw missing was ilia, which is the application launcher that regolith uses. I recently built ilia while contributing to regolith. I think I should be able to package it as well..

[gardotd426]

BTW, I was looking at the PKGBUILD, and the first thing I saw missing was ilia, which is the application launcher that regolith uses. I recently built ilia while contributing to regolith. I think I should be able to package it as well..

Again, there is a very, very long list of background info I need to provide you. Which is what I was in the process of doing.

But no, it's not missing ilia. Look at the pkgver. It's 1.6. Ilia doesn't exist. And throwing bespoke tools into the PKGBUILD is exactly how everything breaks.

The AUR package will be updated when 2.1 is fully implemented. To that end, I have to decide whether I'm going to basically scrap the current PKGBUILD format and move to a more upstream-style solution, or what. I'll likely move to GH Actions or modify the current Regolith build system scripts to work with Arch and libalpm.

[Strykar]

Again, there is a very, very long list of background info I need to provide you. Which is what I was in the process of doing.

Having some idea of the effort involved here, I second this idea.
This should be documented making it easier for new folks wishing to contribute.

[SoumyaRanjanPatnaik]

Again, there is a very, very long list of background info I need to provide you.

Ahh okay.

I'll likely move to GH Actions or modify the current Regolith build system scripts to work with Arch and libalpm

Makes sense. Regolith currently uses the volage repository to test build and deploy its packages. Maybe that can act as a starting point. I'm not very familiar with GH Actions, but I think I can still contribute to this. I'll learn something new as well :)

[gardotd426]

Again, there is a very, very long list of background info I need to provide you. Which is what I was in the process of doing.

Having some idea of the effort involved here, I second this idea. This should be documented making it easier for new folks wishing to contribute.

@Strykar There's no point in documenting it here, because it's a one-time thing. The "very long list of background info" I was referring to was strictly referring to a bunch of behind the scenes stuff which is what's led to the delay in moving the Arch port to 2.X. It's not something that warrants documentation.

[gardotd426]

Makes sense. Regolith currently uses the volage repository to test build and deploy its packages. Maybe that can act as a starting point. I'm not very familiar with GH Actions, but I think I can still contribute to this. I'll learn something new as well :)

@SoumyaRanjanPatnaik Yeah, voulage is what I was referring to using.

I'll go ahead and try to give a short rundown of what I was trying to explain earlier (I was typing it on mobile, had about 4 paragraphs, and went back to finish it and everything I'd typed was gone. Ugh).

So. I started this project over two years ago, after seeing an issue thread on Regolith asking about an Arch Linux port. At the time, Ken was basically 100% solo, he did just about everything regarding Regolith with very few (if not zero) regular contributors, and he had stated on that thread that not only was he pressed for time, but that he knew little-to-nothing about Arch, but would love to see Regolith on Arch so that if anyone could help, he would welcome that and provide whatever help he could.

I didn't use Regolith, I didn't even use i3 at the time (I used i3 for about a year, but I'd long since given up on the minimal tiling WM bullshit). I was (and still am) using Plasma. But I knew I could do it, so I volunteered. Several people offered to help, but I only really ever got like a day's worth of help (I think maybe it might have even been Strykar) that IIRC amounted to some sha256sum hunting.

I ran into some issues due to how far behind Ubuntu packages are relative to Arch, especially Rofi caused some issues. I had to write a python patch for Remontoire as well. But I got it working and had enough testers report that it worked with no problems to list it on the AUR by 1.4. Then 1.6 came, I made a minor fix and updated the packages, and all was good.

By earlier this year, Ken finally had enough contributors to try and find somewhere we could all communicate that wasn't just commenting on GH issue threads. He chose Slack, and unfortunately I just loathe Slack, every time I try to use it I go red. He also added me to the Regolith Organization, giving me full admin access to every single repository under the Regolith-Linux GH account. This includes read/write access to every file in every repo, and moderation access on every issue and PR. This project here also became the de facto - if not de jure - official Arch Linux edition of the Regolith Desktop

But anyway, the Slack channel was where the discussion about upcoming 2.0 was happening. I didn't see any of it, but luckily I did find out that 2.0 was in beta with plenty of time before the release to try and do some testing. But the repos were a mess. Launchpad had been abandoned, and the URL where the manifests and .debs were apparently hosted (regolith.github.io or something) didn't exist. So I was stuck, and could do no testing whatsoever.

Finally that was fixed, but I had some family stuff come up (my great grandmother died from Covid, then my cat died, then I had a couple months where I struggled with my anxiety and depression much worse than usual). And trying to do everything all alone felt overwhelming, but I did start some minimal work toward migrating to 2.0.

I think I've made my decision, and I think I'm going to TRY to move to using voulage (but not GitHub Actions) to create local builds and use those in the PKGBUILD, so the PKGBUILD will just have to pull in the already built pkg.tar.zst packages.

What I do need help with, unfortunately it's not very exciting, is checking the manifest.txt (we're gonna use the jammy manifest) to find all the packages that already have Arch repo or AUR packages, because obviously whenever there is an already-existing Arch/AUR package for something, we are going to use that as a dependency rather than including it in the PKGBUILD. For example, obviously we don't need i3 or i3-gaps, which are listed in the manifest.txt.

Just be aware that you can't go by package names. You'll need to look at the manifest.txt, find a package you think probably already has an Arch version, go to the repo listed in the manifest, and see if there's an Arch project that provides those files. Then let me know, so I can avoid having to add them to the .json file for voulage.

[SoumyaRanjanPatnaik]

Oh damn!! That's quite a journey. Losing your loved ones can definitely have an impact on mental health. You have my sympathies. I hope you're doing well now.

[gardotd426]

Yeah, I'm gonna see how easy or difficult Voulage is to work with, and I'll either use that, or I'll create a GH Actions workflow where I grab every repo from manifest.txt that we don't already have a native package for, build them, and then for the PKGBUILD I SHOULD be able to just download each package artifact, and install the contents to the pkgdir. Basically, there'd be no compilation for the user, imagine a tar.gz archive of a completed build of every package we include, only it would be automated.

I set up a fork (but really just a mirror) repo from https;//GitHub.com/Frogging-Family/wine-tkg-git and created a GH Action to build an Arch-Linux-targeted build with DXVK_ASYNC support enabled (it's disabled by default in the proton-tkg config). It took 5 minutes and I swear, it's the only way I'm gonna get my proton-tkg builds from now on. I've been building them locally using the TKG build system for literally 3 years, and I have a 5900X with 32GB of RAM, building locally is no trouble. But these GH Actions have a ton of potential.

As far as what type of installation we're gonna use (like how Regolith has minimal installs. Full installs, etc). I've always used some editorial control in this regard, and that's not changing. My current philosophy is that this is supposed to provide the full Regolith experience. But unlike with Gnome or Plasma, we aren't able to use package groups to create a Regolith group that could prompt the user which packages they want. No, we have to either provide everything in the main PKGBUILD, or we have to split it up into dozens of packages, just in case someone wants the most minimal Regolith install possibld. Fuck that.

I'm going to include every theme, every style, every optional component, I'm sticking with picom as the compositor, basically it's going to install everything. BUT, once we get it ready, we can do the tedious work of actually editing every single packages depends and optdepends, so that if someone doesn't want a certain theme or style, they can uninstall it. They just don't get to choose.if it gets installed. If that makes sense.

[SoumyaRanjanPatnaik]

I'm sorry I didn't get time to reply to this yesterday...

I think we can have two package groups if we want users to have greater control- regolith-de-base and regolith-de-extras. The regolith-de-base would install the base session files and everything else that's necessary to have a working regolith installation. This wouldn't include themes, fonts and other stuff that regolith would typically install. regolith-de-extras will install those instead. Ofc this also depends on the amount of effort needed to split the project into two split packages cleanly, and tbh I don't have any idea in this regard. If it's not worth the time and effort, a single, COMPLETE installation is definitely the way to go!!

BTW, I wanted to ask you where I can find the manifest.txt file. You also mentioned in your previous comment that we'd need to check the manifest files and check if any of the packages have arch variants.

[SolarAquarion]

I'm looking at the Debian packages on launchpad, and it seems that a lot of the packages on the PPA are just using upstream version with a few changes in colors for the themes. But there have certainly been a lot of changes in the main regolith packages

[gardotd426]

Sorry y'all, I've missed these comments somehow, I never got notification emails, and 99.9% of my work on this is directly through the AUR repo, so I haven't been to this page in a while.

Anyway, if you guys want to take a look at this issue thread on regolith 2.X's ilia package, Ken (the Regolith creator) and I have been working quite a bit on moving to 2.X but also incorporating Arch into the upstream Regolith GitHub workflow action for better automation, and I've completely overhauled the PKGBUILD.

Now, regolith-i3xrocks-config completely replaces all the separate i3xrocks blocks that used to be individual packages (if you have Regolith DE installed and you've updated lately, you should have seen this happen since it would have removed all your blocks). No blocks have been removed.

I also no longer strip any libraries in regolith-styles because the sizes of the resulting installs aren't that different whether I strip or not, but stripping takes forever (even on my 5900X system). So rebuilding and installation is now MUCH faster.

I don't really even think we need help now, except for trying to find Arch packages that are already provided for things in the manifest. However, I really only need this for all the regolith styles packages (icon themes, fonts, and gtk themes). Because naming is so wild, it's hard for me to go through and pacman -F <file> for a million files to see if an Arch font/icon theme/gtk theme already provides the files Regolith needs.

AUR packages should also be looked for, though if an AUR package already provides an icon theme/font/gtk theme, then I'm still going to provide it, but I'll add that theme to the conflicts (I don't want to rely on external AUR packages for anything).

If anyone wants the manifest.txt file, you can get it by running wget http://regolith-desktop.org/unstable-ubuntu-lunar-amd64/manifest.txt Then you'll get an easy-to-read list of packages, with each line having the package name, the git repo its located at, and the commit+branch is being used.

Here's a .json-formatted file with the same information that might be easier to read (depends on what you prefer): https://github.com/regolith-linux/voulage/blob/main/stage/unstable/package-model.json

Sorry for the delay in the update guys. But yeah, 2.X is coming (and wayland support is being worked on!!!!) and once it does, then we are going to put something in place that makes updating it in the future MUCH easier.

Be aware, when the 2.X move comes, configs will move to ~/.config/regolith2. This is an upstream thing, not my doing. Probably for the best though, since Rofi is gone, I think remontoire might be too. So much has been reworked, and now there's regolith-control-center (which I believe is a fork of gnome-control-center, not sure yet) instead of gnome-control-center, and I think the only config thing that might retain most/all of its relevance will be picom, since we're sticking with our picom.