Hackweek 23
Since Hackweek 22 this project has been made much easier with the introduction of "ALP Granite" however that project is not in a state where it is ready for us to do significant work without it as such my goals for this hackweek atleast are somewhat less then last Hackweek, hopefully by next hackweek Granite will be in a better place to build on.
Having said that https://build.opensuse.org/project/show/openSUSE:ALP:Experimental:Linarite:Backports exists where we can work on ensuring critical infrastructure such as X11 stays in shape and this is working to an extent but there are some issues.
So Tasks for this hackweek include: * Write and post an update on the project for openSUSE Factory * Figure out why some packages provided by SUSE:ALP are currently being listed as Unresolvable in the Linarite repo? Is it due to build failures on the SUSE side or other issues with the bridge. * https://src.opensuse.org/ALP-pool is missing a lot of packages at the moment this might be an issue only Adrian can address * Possibly add some more specific packages, this could be challenging without fixing a lot of the Unresolvable issues from the SUSE side and with a number of packages that will be coming to ALP Granite we probably want to be careful not to spend too much effort on packages that will eventually be provided by SUSE.
Hackweek 22
Edit: This project has been mostly successful and the discussion has now moved to the factory mailing list, you can see the contents of the first post in the comments below. https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/YRHRI7IXZ7VIA55J6DBP4PU6FJDEHSLA/
Project Description
Aim
As the title suggests the aim of this project is to explore an ALP Based Leap replacement codename "Grassy Knoll". From a technical perspective the simplest way to summarize the project would be to create a very slow rolling Tumbleweed, to the point where once ALP is released Grassy Knoll will have an update say every 3 or 6 months taking in the new packages. We will need more detail about ALP's component Lifecycle before we can confirm this but 6 months would be more ideal.
Like Leap before it and Tumbleweed Grassy Knoll is not intending to use transactional updates or containers as part of its "core" operating system, however ideally it will be able to still run ALP's containerised workloads. Like Leap before it "Grassy Knoll" will use a "Backports" repository to allow community package submissions.
Design Goals
- Wont use transactional updates
- Wont use containers in the core of the OS but will support running containerized workloads from ALP
- Be a base that's easy for the community to build on.
- Support X11 Desktop Environments
- Be an Ideal solution for embedded systems.
- Migration from Leap 15 systems
- Continue to offer desktop apps as rpm's where possible.
Scope
- Packages SUSE ALP supports in "Bare Metal Mode"
- KVM Server
- X11
- Enlightenment
- XFCE
Anything else people would like to contribute.
x86_64
aarch64 (Raspberry Pi)
The reason for this scope is these are the requirements for my personal KVM Desktop Server alongside XFCE as its a popular community option. This is what I could commit to maintaining at a stretch it should also be enough to have a base for many other community packages. The idea is we will add more as people step up to help.
Goal for this Hackweek
- Setup a "Backports" repository for "Community Packages"
- Create a basic iso image for testing
- Setup basic openQA testing based off existing tumbleweed tests.
- Create a Raspberry Pi image for testing.
Resources
- https://build.opensuse.org/project/show/home:simotek:GrassyKnoll:Backports - Packages building.
- https://build.opensuse.org/project/show/home:simotek:GrassyKnoll:Images - Images building.
- https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll
Todo
- Fix unresolving packages and document why
- Build all of XFCE from Tumbleweed
- Live CD Images.
- Add additional packages.
- Setup openQA testing
- Raspberry PI Image
Other notes
- Disable SE Linux enforcing mode until its in tumbleweed
Looking for hackers with the skills:
Nothing? Add some keywords!
This project is part of:
Hack Week 22 Hack Week 23
Activity
Comments
-
-
-
almost 2 years ago by RBrownSUSE | Reply
Not transactional? No fun for me
Reply to simotek
Yep, you already do that fantastically
so I don't need to do that, i'm trying to make something useful for all the other people that don't have time to adapt there packages / workloads to transactional atm
# A First Level Header ## A Second Level Header Use one asterisk to *emphasize* Use two asterisks for **strong emphasis** - Use hyphens - for unordereed - lists This is an [link to example.com](http://example.com/) This is an image  This is a user link @hans This is a project link hw#some-cool-title
-
-
almost 2 years ago by lkocman | Reply
When it comes to Leap succession, we'll have to follow ALP. As already mentioned our base systems should be identical with same cadence (with exception of branding). I'm bit afraid that stepping from transactional (current course of ALP) would steer us off too much. Perhaps we should start breaking down some of the challenges you have @simotek and find out how to solve them.
-
-
almost 2 years ago by mauriziogalli | Reply
If by transactional updates we also mean "offline updates" within a desktop session, they don't work with Xfce without some patching in xfce4-session. It can probably be done but didn't really spend much time looking into it
-
almost 2 years ago by simotek | Reply
I know that KDE has had a lot of issues getting into MicroOS I haven't looked at exactly what all that was yet but my aim was to sidestep / avoid those issues for the smaller desktops by having an OS that functions more similarly to Tumbleweed.
Technically I think the biggest challenge would be getting packages like X11 as well as desktops to work in a read only filesystem environment the same could probably be said for a large number of community packages.
Given that ALP is still based on Tumbleweed it seems to me that the amount of effort to build an ALP image with a read write filesystem that still uses zypper up to update is significantly less then the effort to get everything else working with read only filesystems.
My aim is to use ALP sources to create something as functionally similar to the current Leap as possible, which means things like installing most packages to the rootfs rather then in containers etc obviously there are some limits here ALP packages wont build with apparmor support so its practically impossible to include apparmor in this distro but things like configuring the filesystem and installing packages there should be straight forward even if in SUSE's ALP they are generally run in a container workload we just need to make sure they are in the right repo.
The aim for this distro is to look like current Leap smell like current Leap and Feel like current Leap, so maybe Leap is the most sensible name for it. If as an openSUSE community we decide that we only want the Leap name to apply to the ALP variants that act like the SUSE ones that's fine we can brand this as a different name but at the end of the day if the community picks up and runs with this concept the naming will be a decision for the community rather then SUSE.
-
-
almost 2 years ago by simotek | Reply
I have created a "Backports" project at [1], It currently includes enough of the X11 / Wayland extra packages from Tumbleweed to build Enlightenment, Feel free to submit add any other community packages from Tumbleweed that you would like to see in an ALP based Leap replacement and we will start working through the dependency list. I am currently maintaining a list of dependencies and why the are installed at [2].
Next step will be building KVM images for testing followed by setting up XFCE and trying to build a live image also for testing.
- https://build.opensuse.org/project/show/home:simotek:GrassyKnoll:Backports
- https://en.opensuse.org/User:Simotek:GrassyKnoll
-
almost 2 years ago by mauriziogalli | Reply
Base set of Xfce packages in this SR: https://build.opensuse.org/request/show/1061995. These are base packages plus branding and some required dependencies to have a functional desktop
-
-
almost 2 years ago by mauriziogalli | Reply
I have successfully built Xfce dependencies and created a first attempt of a generic KVM image that should make it possible to install Xfce, Enlightenment and other packages via terminal. Next step would be to optimize Xfce pattern and possibly create a dedicated a KVM image with Xfce preinstalled out of the box.
-
almost 2 years ago by simotek | Reply
There is now a Live XFCE image available for testing, it seems to run ok in KVM although I don't think the livecd installer work yet (Unless I fix it before you read it). http://download.opensuse.org/repositories/home:/simotek:/GrassyKnoll:/Images/images/iso/
-
almost 2 years ago by bmwiedemann | Reply
works with
qemu-kvm -m 1000 -cpu host -cdrom https://download.opensuse.org/repositories/home:/simotek:/GrassyKnoll:/Images/images/iso/openSUSE-ALP-ALPHA-0.1-XFCE-Live.x86_64-2.8.0-Build380.4.isoThough a wget is probably better for IO. And it also helps to not break when a new .iso is published. -
-
-
almost 2 years ago by mauriziogalli | Reply
Generic and Xfce KVM qcow2 images are now available for testing. At the moment these are more like a POC and are usable for tinkering. Link: https://download.opensuse.org/repositories/home:/simotek:/GrassyKnoll:/Images/images/
Enlightenment images will be ready soon too
-
-
almost 2 years ago by mauriziogalli | Reply
An update on the KVM images, you can now download Generic, Enlightenment and Xfce images from https://download.opensuse.org/repositories/home:/simotek:/GrassyKnoll:/Images/images/
-
almost 2 years ago by mauriziogalli | Reply
The following observations were sent by @simotek to openSUSE Factory and ALP Community mailing lists:
This hackweek a group of us have been looking at using the ALP binaries provided by SUSE to create a functional successor to openSUSE Leap.
Goals:
Creating and maintaining it should be manageable by a small number of community volunteer maintainers, but at the same time should be scalable to grow with additional contributors.
It should be possible for community members to easily contribute additions in their preferred form whether rpm, container or something else.
Use ALP Sources wherever possible (In some cases this may require building them in a different format).
Make it possible to support smaller desktops including supporting X11, Wayland and xwayland.
Support upgrading systems from Leap 15.5 in most cases. This will likely mean alongside supporting transactional updates so that SUSE:ALP -> openSUSE:ALP is possible, it also needs to be possible to still support traditional RW filesystems with zypper up and dup.
Support running ALP containerised workloads but aim to avoid using containers in core operating system components.
Provide a lightweight environment for embedded usecases including Raspberry Pi's.
To test that these goals are realistic, our main goal for this hackweek was to get Xfce running on a combination of ALP and backports packages. It seemed like a good choice as the package set is small enough to be handled by a couple of people and it's popular in the openSUSE community. We have made good progress and have achieved a lot, but more on that later.
Design: The basic concept is to follow what we have done with Leap and create a "Backports" repository containing community packages from Tumbleweed to fill the gaps, one of the differences here is SUSE's repos for SLE contain around 10,000 packages while ALP contains around 2,000, despite this, we only had to add around another 350 packages to reach our initial goals. This includes yast and many gnome build dependencies that hopefully we will be able to take from ALP Sources once they are there. But even at this number it is probably manageable for a small team especially while the packages are present in Tumbleweed.
Once we had the packages we needed, we could use our existing tooling such as kiwi to create images for testing including livecds. The biggest benefit to SUSE's Factory first policy is with the right packages everything that works in Tumbleweed also works here. Hopefully once we know how SUSE plans to build their container images, we will also be able to use the same approach partnered with the backports repo to build openSUSE community images if people are interested in maintaining them. We didn't investigate that this hackweek though.
Lubos also spent a significant portion of his hackweek working with d-installer to see if it is currently suitable for working with the additional features that we require.
Design Limitations: While it is possible to work around many of ALP's restrictions via simply building images differently, some other design decisions are hard to avoid due to the fact ALP binaries are built without certain features such as AppArmor and NIS.
Results: Firstly we have a backports repository here[1] containing all the additional packages we required so far, we also have a wiki page documenting why many of these packages are required [2]. Secondly we built several KVM Images available for downloading and testing [3], that include Xfce, Enlightenment and a generic console environment. These are very limited images - really only designed as a proof of concept, so beyond very basic functionalities and basic desktop options, don't expect too much. Third we built live cds also for testing and available to download [4]. Initially we worked on Xfce and Enlightenment due to my personal interest but at that point Valentin discovered that we were only about 30 packages away from a usable Gnome system and decided to give it a shot. However, what Gnome ends up looking like in the future will depend a fair bit on what SUSE does with it for their ALP products. We also have a D-Installer image availiable as a proof of concept for installation.
Unanswered Questions:
Desktop apps - SUSE's ALP will likely use Flatpaks, if these are built on OBS, it may be possible to build rpm versions from the same source. It is also likely that some openSUSE contributors will prefer to ship their applications as rpms. So Ideally we want to support both.
Maintenance / Release schedule - Ideally during the year at scheduled periods, we will bundle up changes from SUSE's ALP and the community and bundle them into some form of point release. I.e. it seems likely that SUSE will release the python3.11 stack at a point when the python3.10 stack is still supported so it would be ideal to pick one point to do regular migrations rather then them happening at random times. Currently we still don't have enough detail in this area to really assess what will be possible though.
There is a chance that SUSE will use less repositories than in the past and we may need to add repository- based filtering to zypper / yast so that they only show still supported packages for install. But again we are very much waiting for more detail here.
What Next: We now know that this concept A works and B would be maintainable, so if there is broad community interest in this concept, the next step would be probably after the Leap 15.5 release, creating a backports package repo similar to the way the Leap ones have existed with bots etc. Then getting maintainers to contribute any other packages they wish to maintain. At the same time, setting up image building and openqa tests. In the meantime the packages in the backports repo under my namespace are mostly linked from Factory (i'll fix the rest) so i'll keep an eye on them and check they stay building. If you maintain a package and are interested in the list of dependencies, you'd also need to maintain to get it working, let me know and I can link it in from Factory. However, be aware that significant parts of the perl, python and ruby language stacks etc aren't packaged yet. Also in the spirit of lighter desktops i'd like to get sway packaged as well as it will give a good indication of whats needed for the other smaller wayland desktops.
The name is something else to consider, should we just use Leap for the open source builds of SUSEs ALP products, should we do something else entirely? Given that SUSE is using names of alps as release code names I chose to do something similar but different, This project is meant to be less extreme then a trip up into the alps, more like a relaxing picnic or stroll through the hills so this prototypes codename is Grassy Knoll because it sounds cool and maybe I've been playing too much dwarf fortress. Either way, it may not be the best name for the project long term.
FAQ:
- Why didn't we look at KDE? - KDE has a much larger packet set, Also part of my initial goal was to create something small enough that if I needed to maintain it with a couple of people mostly for our own personal usecases we'd be able to. KDE doesn't fit within that scope, however from the testing we have done this week if someone wanted to maintain KDE, it shouldn't require too many changes from the packages in Tumbleweed and may provide a good way to do KDE going forward with ALP but i'll leave that decision with the KDE Maintainers
Finally a massive thanks to the other members of this hackweek team: Maurizio Galli, Lubos Kocman and Valentin Lefebvre. They took a concept I had in my head and helped transform it into a functioning prototype. Also a big thanks to Fabian Vogt for answering all my "why won't kiwi build this"-questions.
If you have questions thoughts or suggestions feel free to reach out to us via email or in the openSUSE-ALP channels on Discord / IRC / Matrix. we will also work on getting this information into the wiki.
- https://build.opensuse.org/project/show/home:simotek:GrassyKnoll:Backports
- https://en.opensuse.org/User:Simotek:GrassyKnoll
- https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnoll:/Images/images/
- https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnoll:/Images/images/iso/
-
-
about 1 month ago by michals | Reply
Looks like the image builds have bitrotten, and the base project name changed from ALP to SLFO.
Also there is some effort to bootstrap Leap 16.0 now, perhaps based on the experiences with Grassy Knoll to some extent.
Would be nice if somebody who has some idea what the current state is update the wiki page or posted a summary somewhere.
-
about 1 month ago by simotek | Reply
This project was started back when ALP wasn't going to have a mutable variant, to show it was possible to create a "Leap 16" from ALP. Now that we have a SLE-16, Lubos is working directly on creating Leap-16 from the SLE-16 codebase. This project is kinda now no longer needed, it served its purpose of showing it was possible without too much work, the only reason I still have the repo's around is I needed to find older revisions of some certain packages to get x11 working so I kept them around.
-
-
about 1 month ago by lkocman | Reply
https://news.opensuse.org/2024/10/07/leap-16-0-prealpha
If anybody wants to contribute ensure that your favorite packages including all dependencies are submitted to https://build.opensuse.org/project/show/openSUSE:Leap:16.0.
If you're participating on larger enablement effort like Xfce/wayland and you want to enable that option in agama installer, then https://github.com/agama-project/agama/blob/master/products.d/leap_160.yaml is your friend.
You can also experiment with it by forking agama-products and agama-installer-Leap packages from Leap 16.0 project in your home project.
Similar Projects
This project is one of its kind!