Redcore Linux Project Forum

Honestly, I want to unmask wlroots v0.16 today if possible, however, Qtile strictly depends on wlroots v0.15, as an updated version hasn't been released yet. There is a pull request : https://github.com/qtile/qtile/pull/3985, but hasn't been merged yet.

In order to keep everything in the repo conflict free, I masked wlroots v0.16 for the time being. As soon as Qtile gains wlroots v0.16 compatibility, I will remove the mask.

And that's also the reason why hyprland is not packaged and provided as a binary yet. With Qtile wanting wlroots v0.15 and hyprland wanting wlroots v0.16, I had to make a choice, I choose to keep Qtile since I plan to release a Qtile iso image in the future.

That being said, if you don't have Qtile installed, or you don't intend to install it, you can comment the wlroots mask in /etc/portage/package.mask/00-gui-libs.package.mask and the pywlroots mask in /etc/portage/package.mask/00-dev-python.package.mask. In addition you must add gui-libs/wlroots x11-backend line into /etc/sisyphus/sisyphus.package.use.

These changes are what sisyphus asks you to do, in able to be able to proceed and update hyprland. Though, be aware, those changes may be overridden at any time in the future.

Or, you can just uninstall hyprland and the conflicts will go away and sisyphus will be able to update the rest of the system. Though, if you want to reinstall it afterwards, you need to do the changes mentioned above to be able to do that.

Pretty much all journaling filesystems will fill your requirements, ext4, xfs, btrfs. However, that is not a guarantee. A power loss can corrupt the filesystem to a large extent so it cannot be recovered.

It could work if you install f2fs-tools, before you start the installer.

sisyphus install f2fs-tools

Very likely. If you have both binaries and ebuilds to install, sisyphus will present the list of them separately and ask if you would like to proceed. Just make sure you have the very latest version of sisyphus, as just the other day I removed some code which could lead to some sequences to execute twice with no reason.

I don't want to sound like a smartass, but I doubt that...it took the build server four days to compile, with 48 cores.

Joke aside, an update of this scale only comes once per year, whenever we update the toolchain and rebuild everything with the new toolchain. We time the massive update to arrive simultaneously with a new ISO image release in case somebody prefers a fresh install instead of an update of this magnitude.

Unfortunately, portage is not parallel when it comes to installing the packages. It is highly parallel during compilation but still does one package at a time. The same update can take less time if a nvme disk is used instead of a mechanical drive.

I'm sorry if this creates an inconvenience. We do need to do this once per year.

Download speeds from mirrors are out of our hands, since they are...mirrors. They just grab our packages and redistribute them. Princeton mirror is known to have troubles at times.

On the other hand, if you look up at the commit log I am working already to fix as many bugs in sisyphus' code as possible. Will just take a little while.

Menu -> System -> Discover, press Enable Flathub, enjoy flatpaks. Easy as pie!

You can upgrade the system using portage :

emerge -NuDgav --backtrack=100 --with-bdeps=y --rebuilt-binaries @world
emerge --depclean -va

To update sisyphus' package database afterwards:

sisyphus spmsync

Meanwhile I will try to rethink the way sisyphus downloads the packages and implement a solution to keep the cache around. The current design in which it discards the package cache is by choice. At the time I wrote the code something was breaking if we didn't discard the package cache. I guess that choice stayed to this day.

Would you mind filing a bug report in the bugtracker? So I remember about it? Thank you!

Yes, it is as simple as that, with a caveat.

A default install of Redcore Linux pulls a few packages (sisyphus, artwork, dracut, openrc) from that git repo. You would need to hunt them down in @world and remove them. You would also need to change some masks, unmasks, keywords, useflags and recompile the affected packages. The modifications are not extensive I would say, but I might be subjective.

For example : openrc ebuild in redcore-desktop.git . It is based on Gentoo one, but with some changes : it pulls in dkms, apparmor, havege and some others as dependencies. It also modifies openrc's modules service to integrate with dkms, and it makes sure some services such as elogind are started from the corect runlevel.

Long story short, yes, it can be done...but with some work involved.

This has been fixed in 390.151. Please try again and if you still have issues, let me know.

Not anymore. Though, we're based on Gentoo's testing branch, so the system is pretty up-to-date. We only lag a few (about 3) days behind Gentoo itself.

I agree, will lower the entry barrier slightly. But I'm happy to report that 3 people, including you, managed to register even with that really hard challenge.

Well, as long as the module for such a card is in the kernel, we can always enable it, if by any chance it isn't in the default kernel configuration.