- Alp-community-wg

zypper Updates
by Rubens Carlos 05 Sep '23

05 Sep '23

Hello team I have this problem when applying zypper update http://en.opensuse.org/Zypper/Troubleshooting Unexpected exception. Receive: script died unexpectedly History: - [11-Resource temporarily unavailable] I tried this below it didn't work /usr/sbin/registercloudguest --force-new sudo SUSEConnect -list-extensions zypper refresh --force zypper clean --all zipper ref

1 0

zypper Updates
by Rubens Carlos 05 Sep '23

05 Sep '23

Hello, Team. when i try to run zypper updates i get the following message on screen http://en.opensuse.org/Zypper/Troubleshooting Unexpected exception. Receive: script died unexpectedly History: - [11-Resource temporarily unavailable] I tried this below it didn't work /usr/sbin/registercloudguest --force-new sudo SUSEConnect -list-extensions zypper refresh --force zypper clean --all zipper ref

1 0

Proposal: Creating a Leap replacement based on ALP.
by Simon Lees 03 Feb '23

03 Feb '23

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. 1. https://build.opensuse.org/project/show/home:simotek:GrassyKnoll:Backports 2. https://en.opensuse.org/User:Simotek:GrassyKnoll 3. https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnoll… 4. https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnoll… -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

1 0

GUI Package Manager Unable To Install Opensuse Micro OS packages
by Mason Mullins 06 Aug '22

06 Aug '22

If this has already been addressed, I apologize as I didn't find it. When attempting to install Micro OS packages such as Virtualbox or VLC from the GUI Package Manager it fails with the error: can't create transaction lock on /usr/lib/sysimage/rpm/.rpm.lock (Read-only file system) I installed the VLC flatpack from the GUI no problem. As there is no flatpack for Virtualbox I then tried to install Virtualbox via cli transactional-update and it installed.

1 1

GRUB2 Configuration
by Mason Mullins 05 Aug '22

05 Aug '22

Decided to install the Micro OS Desktop Gnome. First thing I notice is that during the installation GRUB fails to detect and configure for other operating systems, in this case Windows 10 (yeah, I know but I need it for certain tasks), so there is no GRUB boot menu item for the other OS. I ran the installation twice just to be sure I didn't miss anything. Fortunately, I can still boot that by entering my BIOS boot menu, but that's an unnecessary additional step IMHO.

1 0

Meeting minutes from discussion with ALP Lifecycle WG and Product
by Lubos Kocman 04 Aug '22

04 Aug '22

All meeting minutes can be found here: https://etherpad.opensuse.org/p/ReleaseEngineering-meeting Meeting is hosted here https://meet.opensuse.org/ReleaseEngineeringMeeting ## Attendees lkocman, coolo, sbehlert Topics: Simon Lees's email after the frist Lifecycle WG meeting: Some of the lifecycle changes being proposed here have some pretty significant impacts on the future of openSUSE's stable distro. The current plan being discussed seems to be only offering the "fasttrack" option for the community. Which would make it basically a copy of centos-stream which as we know didn't go down well in that community and I don't think it would go down well in ours. Lubos to invite Stefan Kulow to the next regular Community WG meeting (done, let's see if he accepts). Stephan pointed me to PM Stefan B. Understanding of ALP lifecycles Stefan B.: No lifecycle is being pushed by SUSE on the community, and since ALP will be built in public, we're free to select what works for the community the best with available resources (specifically also maintenance team), etc. Stefan B. : The mentioned FastTrack - when there is a new version, think about Leap as we have it nowadays. Stefan B.: think about the decoupling of the lifecycle per "component". Unlike in current Leap / SLES some of the components will be delivered as flatpaks and containers, and these can have various lifecycles. lkocman: That also depends on where we consume individual blocks, e.g., the desktop. If it's flathub, then the lifecycle is given by whoever maintains the flathub application. On the other side, we would have a bit more flexibility if it's an OBS "flatpak" repo. lkocman: In the context of base-os, we'd probably have to follow the "basic" lifecycle of SLES. Similar to Leap nowadays with small overlap (1/2 of the release cadence e.g., 12+6 months or 6+3 months as in SLE Micro, that's to be discussed. lkocman: mentioned that original proposals were offering Leap

4 6

Micro OS, a short first impression
by Mathias Homann 02 Aug '22

02 Aug '22

I just tried Micro OS as a desktop for ... i admit, not long, maybe an hour, because I just found it to be *unusable* as a desktop for anyone who does not know all the differences between a transactional OS and a traditional Linux OS. To be frank and outright: While I believe that there definitely is a place for such a thing as transactional OS updates and package installations, that place is not on a desktop. At least not unless the user is actually *told about it* at first login. I installed µOS as "Plasma Desktop" in a VM, and was greeted after login with a plain Plasma Desktop with almost no apps, and no YaST either. And after finding discover I found that every installation process after the first failed without telling me why. Yes, I know, transactional, yadda yaddda - but the user needs to KNOW that each install needs a REBOOT (hello, windows 98) to be able to install another application - and the easiest way to be sure that the user knows that is what? Guess? Yep, telling them. which µOS does not, as of 20220718. So - begone for now. I'll have another look in a while(or maybe use it for the kind of stuff where it makes sense, like kubernetes workers or something like that). If this comes across as a bit harsh: what can I say, that was a bit disappointing after 25 years of (almost) nothing but positive experiences with SuSE and later openSUSE products. Cheers MH

6 6

My 2 cents on MicroOS
by Promet 25 Jul '22

25 Jul '22

Just gave MicroOS a try. As a person who tried Silverblue & Kionite before, I must say the experience with MicroOS is, wow, much better! I am a traditional Chinese user (and know a bit Japanese) and I have struggled to get Chinese/Japanese input installed and utilized in these two. But CJK input in MicroOS works like a charm. Related packages are installed already once you selected your language during installation, all I need to do is add the input methods that I have always been using. Multimedia also works out of the box as I went to HTML5 video test page with Firefox and saw no problems with playing the video. I'm always a KDE supporter when using SUSE, coz I love how polish KDE is under SUSE. But GNOME looks gd as well. The only thing looks weird is it lacks YaST, I only noticed that when others pointed out. It's not SUSEish once there's no YaST, right? ;) But I guess YaST modules wouldn't be that useful in MicroOS as everything in the system is read-only? Software installation is the most confusing thing for me. I figure out there are 3 ways to install software under MicroOS: 1. transactional-update pkg install Pretty much like traditional zypper in but needs to reboot every time, it makes the concept of immutable OS irrelevant if you install everything this way 2. toolbox More like the traditional way than 1 actually. My understanding is that it installs software in a separate container? 3. flatpak No explanations needed I guess? I still have to think and choose from the above 3 ways when installing software. For example, I am a heavy user of the Telegram messenger. I wanted to get Telegram installed, and I have to think: Method 1? No, it's not a system software. 2? May be, let's give a try...only I've installed bunch of dependencies I realized that Telegram is a desktop software so Flatpak is obviously the best answer! It's a bit confusing tbh, if MicroOS is the new stable release in future, surely users need time to adapt. At this time I still haven't tried system-wide update as there are no new snapshots for TW, not sure if the GUI way works (I found on the net that GUI update seems waiting to be finished but the QA list does mention about the test of GUI update?) From my short experience I think MicroOS is an interesting concept, it's a funny project and I am looking forward to its development, but I think it has a long way to go to replace Leap.

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 24 Jul '22

24 Jul '22

Jiri Slaby <jslaby(a)suse.cz> writes: > On 05. 07. 22, 17:46, Dan Čermák wrote: >> we have mostly focused this week's meeting on how the ALP Desktop is >> going to look like and how we can dispel fears around flatpaks and >> containers when it comes to the ALP desktop. > > I have never looked into this container stuff in more detail. But one of > the concerns I was always afraid of was how this behaves WRT shared > libraries and their memory footprint? IOW, containers kill the purpose > of shlibs completely and one has to hold all of the versions (per each > container on the top of ones from the base system) in memory, right? > This sounds as if using static libraries. A small follow up on this one, more in the context of flatpaks though. The question has been raised, whether flatpaks sharing a runtime would benefit from memory deduplication of shared libraries in the common runtime. The short answer is: yes. The longer and much more elaborate answer can be found in this great reply from upstream: https://github.com/flatpak/flatpak/issues/4997#issuecomment-1192616912 So as long as we don't stop dynamically linking, there shouldn't be any huge memory penalties for flatpak applications. Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

New users for the MicroOS Desktop test for ALP documentation
by Syds Bearda 22 Jul '22

22 Jul '22

Hi, I'm looking forward to everyone test driving (and staying afterwards with) MicroOS, but please make sure you know what you are in for. MicroOS Desktop is not ready for a full release to the public. Gnome is currently RC and KDE is still Alpha. Both should be changed soon enough to a further state, but when installed today, these are the facts. Please refer to the official documentation for MicroOS to understand MicroOS overall [1] and MicroOS Desktop in particular [2]. Happy testing! /Syds [1] https://en.opensuse.org/Portal:MicroOS [2] https://en.opensuse.org/Portal:MicroOS/Desktop

2 2

A Noob's MicroOS Experience (aka, Toolbox tutorial wen?)
by Gordon Leung 22 Jul '22

22 Jul '22

Hi, I saw the announcement about sending MicroOS reviews here so since I tried it out a month or two ago so I guess I will share my thoughts here. I think MicroOS could benefit a lot from a toolbox tutorial in a new user welcome pop up, because when I tried out MicroOS I had only heard of the name "toolbox", but never knew what it could do at all. Toolbox makes doing "normal" Linux distro things such as installing devel packages or something else temporarily pretty painless, but because I had no idea it could do that, I was just restarting my computer every time I was trying to figure out what devel packages I needed to build a C program. Also, some other tutorials such as how to use Distrobox to simulate entire other Linux distributions could be a neat bonus. People unfamiliar with immutable distros such as myself don't know what we need, so by the time I looked up how those tools worked, I was already back to using plain vanilla Tumbleweed. Gordon Leung

3 3

Re: High-Impact ALP workgroups
by Dan Čermák 14 Jul '22

14 Jul '22

Hi Dirk, Dirk Müller <dmueller(a)suse.de> writes: > On Dienstag, 12. Juli 2022 17:40:17 CEST Dan Čermák wrote: > >> we have identified your workgroups [1] to have a potential high impact >> on the community of ALP and would thus like to encourage you to start >> publishing your workgroup reports on the factory[2] and alp[3] mailinglists >> as well as to the openSUSE wiki[4]. > > Hi Dan, > > are you looking for that being published as unstructured meeting minutes or do > you plan to setup a more targetted process like for example > > https://en.opensuse.org/openSUSE:OSEP_0001 We don't have a specific template in mind and I don't think that a formal template is really in place here, because it goes against how the openSUSE community works. I think it would be valuable to start posting your minutes to the wiki after a general introduction to the community so that interested contributors can follow your progress and provide feedback. > where we could have a more targetted proposal discussion? > > I think for some of the more controversial changes it would be good to > document rationale, chosen option and alternatives to structure potential > feedback or discussion accordingly. I'll think of a template that can be used for communicating change proposals and will find a way how you can ask for feedback that will be (hopefully) useful and will not overwhelm the workgroup. Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

High-Impact ALP workgroups
by Dan Čermák 12 Jul '22

12 Jul '22

Dear ALP workgroup leads, we have identified your workgroups [1] to have a potential high impact on the community of ALP and would thus like to encourage you to start publishing your workgroup reports on the factory[2] and alp[3] mailinglists as well as to the openSUSE wiki[4]. It would be very nice if we could start involving community feedback in the development of ALP, so that the whole does not feel like SUSE is throwing stuff over the wall. If you would like help with publishing and involving the community, then feel free to ask us for help, as this is what we are here for ;-) Thanks, Dan Footnotes: [1] https://en.opensuse.org/openSUSE:ALP/Workgroups/Community#Workgroup_impact [2] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/ [3] https://lists.opensuse.org/archives/list/alp-community-wg@lists.opensuse.or… [4] https://en.opensuse.org/openSUSE:ALP/Workgroups -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 07 Jul '22

07 Jul '22

Lars Vogdt <lars(a)linux-schulserver.de> writes: > Hi > > On Wed, 06 Jul 2022 12:50:18 +0200 Dan Čermák wrote: >> >>> 1) What are the advantages of flatpak/container vs RPM? >> >> That's what will happen. Currently we distribute software for every >> code stream and with flatpaks we hope to reduce the burden on our >> maintainers and allow them to distribute it only once. > > For me this kind of means we retire from the current way to deliver well > tested (but maybe older) software to Leap users and deliver the latest > and greatest stuff to Tumbleweed users. > > 13) How can someone decide to use an older, but known to be stable > version of a package (say: Libreoffice 7.2.7 instead of Libreoffice > 7.3.4) in ALP? We haven't made any decisions in this regard (like with a lot of other stuff), but with flatpaks we could deliver a org.opensuse.libreoffice-stable, org.opensuse.libreoffice-beta, org.opensuse.libreoffice-nightly, etc. co running "streams". With containers we could go the already established tag route, i.e. registry.opensuse.org/opensuse/libreoffice:stable registry.opensuse.org/opensuse/libreoffice:beta registry.opensuse.org/opensuse/libreoffice:nightly Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 07 Jul '22

07 Jul '22

Jiri Slaby <jslaby(a)suse.cz> writes: > On 05. 07. 22, 17:46, Dan Čermák wrote: >> we have mostly focused this week's meeting on how the ALP Desktop is >> going to look like and how we can dispel fears around flatpaks and >> containers when it comes to the ALP desktop. > > I have never looked into this container stuff in more detail. But one of > the concerns I was always afraid of was how this behaves WRT shared > libraries and their memory footprint? IOW, containers kill the purpose > of shlibs completely and one has to hold all of the versions (per each > container on the top of ones from the base system) in memory, right? > This sounds as if using static libraries. A lot of the containerized software is written in Go and that is already statically linked, so my guess is that no one really looked at this so far. However with flatpaks the situation is different and it would be theoretically possible to deduplicate shared runtimes of flatpaks. Unfortunately I don't know whether that is actually done in practice or even feasible. > And what about userspace live patching? Would we provide it for SLE for > all the containers? Or don't you expect these continaers to be available > on SLE (which would be against the advertised purpose, it seems)? This would be a question for Libor, who is driving the Kernel and Live Patching WG. Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Lubos Kocman 07 Jul '22

07 Jul '22

Hello openSUSE! I'm happy to see these discussions, and this is precisely why we need to plan in an open way! I have an understanding of many concerns which are being raised here. Just an idea that I discussed with Dominique a few days ago. My first-time personal experience with our current "Immutable Desktop" was quite good, but not perfect. I definitely would have some RFEs, which seem to be relatively low-hanging fruits that would improve my day-to-day experience by a lot (mostly default configuration) I can see how the entry barrier may appear too high to people meeting such a concept for the first time. I'm thinking of an idea to make a "workshop" where users would install MicroOS Desktop and try to use it for a week, and then we'd meet to talk about the user experience, both good and bad). I think people liked our last *workshop. We've had around 50 visitors in total. We could start putting together known issues (FAQ), try to propose some changes, and make sure they're being tracked for ALP GA. Thoughts? [0]https://en.opensuse.org/openSUSE:ALP/Workgroups/Community/Workshops/LeapD…

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 06 Jul '22

06 Jul '22

Lars Vogdt <lars(a)linux-schulserver.de> writes: >> > Please correct me, if my assumptions are wrong: >> > * A Flatpak will include all needed libraries, which will blow up >> > the needed (installation and mirror) space >> >> No, flatpaks support runtimes which would contain the required >> libraries and these are shared between different flatpaks. E.g. on >> flathub you already have a GNOME runtime and a KDE runtime. We could >> create our own openSUSE Tumbleweed runtime and base our flatpaks on >> that. > > This sounds to me like: "Flatpak is just another packaging format. But > instead to rely on packagers to provide Apparmor/SeLinux profiles, > Flatpaks are using cgroups from the beginning, which makes them more > secure." - Is that description close enough to the truth? As far as I know flatpak utilizes seccomp to achieve the isolation and not cgroups. Iirc cgroups are more for limiting resource usage and not security sandboxing, but this is really far outside of my knowledge. >> >> > 2) Will ALP still allow one 'zypper up' call to update all >> >> > software (container, flatpak, rpm) on a system? >> >> > >> >> > 3) Will OBS auto-convert current rpms to flatpaks? >> >> >> >> Theoretically that could be done, but I think that's at the moment >> >> out of scope. >> > >> > For 2, does this mean we loose the current benefit of updating a >> > whole system with just one single tool? >> > >> > So for 3, this currently means that packagers have more work, >> > because they need to provide the needed Flatpak build configuration >> > as well? >> >> Not really. Currently a packager has to provide a spec file for every >> code stream and maintain those independently and make them build. With >> flatpaks in the mix, you'd have to maintain a single code stream and a >> flatpak build description. > > IMHO this answer is wrong. Most packages in OBS are not using spec files > for every code stream, but include macros in one single spec file to > build for multiple code streams. In devel projects yes, but the actual package sources of the released code streams are separated and have often significantly diverged from the state in the devel project. > But this brings me to two other questions: > > 10) Is there something like _multibuild support planned for Flatpak? I cannot answer that, as I do not know what the Build Service team has planned here. > 11) Will there be a tool to convert spec files into Flatpak files? No, and that should really not be required. The idea is that you combine multiple rpms into a flatpak and not that you convert a rpm into a flatpak. > >> > How is a migration from RPM to Flatpak expected in this case? >> >> Afaik there are no plans to support a migration from SLE to ALP. > > Are there plans to support a migration from openSUSE to ALP? I don't think there are and imho the technical complexity of that would make such a migration next to impossible to pull of cleanly. Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 06 Jul '22

06 Jul '22

Jan Engelhardt <jengelh(a)inai.de> writes: > On Wednesday 2022-07-06 11:48, Dan Čermák wrote: >>> >>> 1) What are the advantages of flatpak/container vs RPM? >> >>Flatpaks support sandboxing when configured properly giving you greater >>security benefits in comparison to traditional rpms. > > But that is not inherent to the flatpaks themselves. As you say, > flatpaks are but a different method of _distributing_ software. And > so the critique becomes: stop distributing software twice. That's what will happen. Currently we distribute software for every code stream and with flatpaks we hope to reduce the burden on our maintainers and allow them to distribute it only once. > To make flatpaks (or, at this point: sandboxes) more widely accepted, > generate them on the fly from an existing system, i.e. from {an rpmdb > and loose files} rather than from a set of .rpm files. Sure, that would be nice to have. But creating such a system is a lot of work which is really hard to justify if there is already a perfectly functioning and widely adopted system in place. Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 06 Jul '22

06 Jul '22

Lars Vogdt <lars(a)linux-schulserver.de> writes: > Am Wed, 06 Jul 2022 11:48:07 +0200 > schrieb Dan Čermák <dcermak(a)suse.com>: >> > 1) What are the advantages of flatpak/container vs RPM? >> >> Flatpaks support sandboxing when configured properly giving you >> greater security benefits in comparison to traditional rpms. >> >> The main benefit however is that we would be able to build certain >> desktop applications (e.g. Firefox, Thunderbird, LibreOffice, etc.) >> only on top of Tumbleweed, put them into a flatpak and distribute >> them to Tumbleweed, Leap and ALP users. This is something that is >> impossible to achieve with RPMs unless you bundle *everything* into a >> single RPM and even then it will probably not work. So this will save >> our packagers a tremendous amount of work. > > While I understand that this makes the live of a packager easier (at > least in the future, when we got rid of all the old-school > distributions), I think that we loose a big benefit of the current > way to do it. > > Please correct me, if my assumptions are wrong: > * A Flatpak will include all needed libraries, which will blow up the > needed (installation and mirror) space No, flatpaks support runtimes which would contain the required libraries and these are shared between different flatpaks. E.g. on flathub you already have a GNOME runtime and a KDE runtime. We could create our own openSUSE Tumbleweed runtime and base our flatpaks on that. > * We need to find a way to track, if a Flatpak contains a vulnerable > library and push out security updates for all involved Flatpak > (containers). I think/hope, that OBS can help us here? The plan is to build *everything* inside OBS. So updates will be distributed the same way as they are currently, only the artifact at the end will change. > * For any library update, we increase the needed space on all mirror > servers and also require much more bandwidth from all endusers - as > they need to download a whole copy of all Flatpaks with all their > in-tree libraries. > -> Is there already a project like "deltarpm", which might help to > reduce the amount of 'need to be transferred' Flatpak content for > any update? Again, this would go into the runtime, which would be shared by all flatpaks. I must admit that I am not familiar with the flatpak distribution method enough, thus I cannot answer whether there is something like deltarpm. >> > 2) Will ALP still allow one 'zypper up' call to update all software >> > (container, flatpak, rpm) on a system? >> > >> > 3) Will OBS auto-convert current rpms to flatpaks? >> >> Theoretically that could be done, but I think that's at the moment out >> of scope. > > For 2, does this mean we loose the current benefit of updating a whole > system with just one single tool? > > So for 3, this currently means that packagers have more work, because > they need to provide the needed Flatpak build configuration as well? Not really. Currently a packager has to provide a spec file for every code stream and maintain those independently and make them build. With flatpaks in the mix, you'd have to maintain a single code stream and a flatpak build description. > >> > 4) Will there still be some kind of repo (incl. package >> > informations like version-release, changelog, etc.) for flatpaks? >> > >> > 5) Will Yast-Software manage all these different kind of formats >> > (container, flatpak, rpm) transparently for the enduser? >> >> I don't know what the plans of the Yast team wrt flatpaks are, but >> GNOME Software center supports flatpaks and rpms seamlessly. > > So this means more work for the Yast team. > Are they aware of this? > Did they maybe even already agreed to implement this in the near future > (before the first official release of ALP)? I have CC'd the Yast ML to get their take on this. >> > 6) Can configuration still be expected at the usual places >> > ($HOME/.config/ : /etc : /usr/etc/)? >> >> That depends on the flatpak, but generally flatpaks put their >> configuration into ~/.var/app/ > > How is a migration from RPM to Flatpak expected in this case? Afaik there are no plans to support a migration from SLE to ALP. > Are we expecting all our users to manually copy their ~/.config/* into > the new ~/.var/app/* place? As you'd have to reinstall the system anyway, you'd have to move your configs into different places. > Are there maybe even internal differences (YAML vs INI-Style)? Any internal differences would be caused by the packaged application itself. Flatpaks do not mandate any type of configuration format, as at the end of the day they are just archives that get unpacked on your file system (just like rpms…). Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 06 Jul '22

06 Jul '22

"jdd(a)dodin.org" <jdd(a)dodin.org> writes: > Le 06/07/2022 à 11:04, Lars Vogdt a écrit : >> Am 5. Juli 2022 15:46:29 UTC schrieb "Dan Čermák" <dcermak(a)suse.de>: >>> tl;dr; Fear not, you will not be forced to download random flatpaks or >>> containers from dockerhub/flathub. We (probably) just change the deliver >>> method, but the packaging workflow will stay the same. >> >> 1) What are the advantages of flatpak/container vs RPM? >> > > and the disadvantages :-( > > for example: will we have to load in ram all the libraries for each > application launched? What about old computers with 2Gb or even 4Gb ram > and 256Go disk/ssd? (that works without problem with 15.3) Flatpaks are very good when it comes to deduplication, at least of libraries on the disk. I would expect that they perform similarly when loading them to RAM, but I have not verified that. This sounds like something that we definitely have to take into account and potentially fix upstream. Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

Re: ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 06 Jul '22

06 Jul '22

Hi Lars, Lars Vogdt <lars(a)linux-schulserver.de> writes: > Am 5. Juli 2022 15:46:29 UTC schrieb "Dan Čermák" <dcermak(a)suse.de>: >>tl;dr; Fear not, you will not be forced to download random flatpaks or >>containers from dockerhub/flathub. We (probably) just change the deliver >>method, but the packaging workflow will stay the same. > > 1) What are the advantages of flatpak/container vs RPM? Flatpaks support sandboxing when configured properly giving you greater security benefits in comparison to traditional rpms. The main benefit however is that we would be able to build certain desktop applications (e.g. Firefox, Thunderbird, LibreOffice, etc.) only on top of Tumbleweed, put them into a flatpak and distribute them to Tumbleweed, Leap and ALP users. This is something that is impossible to achieve with RPMs unless you bundle *everything* into a single RPM and even then it will probably not work. So this will save our packagers a tremendous amount of work. > 2) Will ALP still allow one 'zypper up' call to update all software (container, flatpak, rpm) on a system? > > 3) Will OBS auto-convert current rpms to flatpaks? Theoretically that could be done, but I think that's at the moment out of scope. > 4) Will there still be some kind of repo (incl. package informations like version-release, changelog, etc.) for flatpaks? > > 5) Will Yast-Software manage all these different kind of formats (container, flatpak, rpm) transparently for the enduser? I don't know what the plans of the Yast team wrt flatpaks are, but GNOME Software center supports flatpaks and rpms seamlessly. > 6) Can configuration still be expected at the usual places ($HOME/.config/ : /etc : /usr/etc/)? That depends on the flatpak, but generally flatpaks put their configuration into ~/.var/app/ > 7) Are current backups (rsync, Bareos) and configuration management (ansible, Salt) still be supported? > > 8) Will the whole delivery chain stay secure (signing of flatpaks, SSL, DNSSec, ...)? Yes. This is one of the strict requirements to ALP. > 9) Will autoyast still allow automated deployment? > > Regards, > Lars -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

1 0

ALP WG Meeting minutes - July 5th 2022
by Dan Čermák 05 Jul '22

05 Jul '22

Hi everyone, we have mostly focused this week's meeting on how the ALP Desktop is going to look like and how we can dispel fears around flatpaks and containers when it comes to the ALP desktop. tl;dr; Fear not, you will not be forced to download random flatpaks or containers from dockerhub/flathub. We (probably) just change the deliver method, but the packaging workflow will stay the same. long version: Desktop in ALP (topic for next official ALP update at news-o-o) How can we dispell fears of users that we will shove containers & flatpacks down their throats: - we will use flatpak/containers as a distribution format, the packaging model will not change, only the format - the fear is not necessarily flatpaks (probably), but the fear that you'll have to pull everything from flathub/docker hub => stress out that you won't have to pull $randomStuff from the internet, you'll get audited software as you were before Questions that lkocman would ask Yi Fan on the meeting would be: * Some users are concerned that everything on their desktop will run in a container. Can you address these fears? - flatpak/containers just a distribution mechanism, packaging not going to change - ALP is still in flux, nothing set in stone - aim: provide a good desktop for a ALP but don't duplicate work for maintainers (they don't want to ship rpms & containers/flatpak) - possible solution for display manager & lower level things: https://github.com/fcrozat/gdm-container - will allow seamless updates with flatpaks installed on the host * Desktop not being part of PoC, but can we "tentatively" expect it in any snapshot after (Dec, May)? - gdm container makes good progress - good progress with Wayland issues like remote desktop (also upstream involvement) - maybe even have rough prototype in the PoC, will have more info this or next week * I'd really love to see desktop image that you simply dump to disk e.g. with self-install and first-boot wizzard that lets user to configure system. What's YiFan opinion about this? (SUSE IT wants this approach). - no concrete plans here yet - PoC will not have an installer, just a disk image will be the deliverable -> need to figure out how to run an installer or what to use here - Ancor is driving a workgroup to look into the traditional installation -> https://en.opensuse.org/index.php?title=openSUSE:ALP/Workgroups/Installation * Any tips, best practices for how to start with Desktop app development (Including things like Desktop Managers like XFce, Elightenment etc) in "openSUSE ALP" (Current reference for community part of ALP based distro, based on top of "base install image of ALP"). - for info, message Yifan directly (yfjiang(a)suse.com) or the ALP matrix room https://matrix.to/#/#alp:opensuse.org - currently focusing on upstream contributions (-> GNOME upstream) - downstream contributions go into Tumbleweed - for container specific stuff, maybe later, currently too much in flux - look into building flatpaks on OBS, this will become important very soon, so get started beforehands -> help OBS handling flatpaks & container images * Preferred way to distribute apps we know there will be ALP flathub repo in OBS, I think we could have something like "Community version of it". But we should be really smart about this, as the same app could work on top of (Community) ALP as well as Tumblweed. - would be possible to create * How many desktop environments will there be for ALP? Just GNOME like with SLED? - first focus on GNOME, might consider alternatives afterwards - will learn from going with GNOME first and apply this to others later on Maybe publish the Desktop WG results to the openSUSE Wiki as well And that's it for this week, see you again next week with Luboš back in the driver seat! Cheers, Dan -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

2 1

Interview with Yi Fan on next CWG meeting (after hackweek)
by Lubos Kocman 27 Jun '22

27 Jun '22

Hello team, I've invited Yi Fan to our Next ALP community WG meeting on Tuesday after hackweek. This weeks meeting is cancelled due to mentioned hackweek. However there is a problem, due to one fella who was burnt alive in 1415, CZ has a public holiday on next Tuesday/Wednesday and my wife wants to go for a trip to Prague. I originally expected to be at home and connect at 16:30 CEST, but this is no longer the case. Would you be okay, with having the interview without me? Questions that I'd ask Yi Fan on the meeting would be: * Desktop not being part of PoC, but can we "tentatively" expect it in any snapshot after (Dec, May)? * I'd really love to see desktop image that you simply dump to disk e.g. with self-install and first-boot wizzard that lets user to configure system. What's YiFan opinion about this? (SUSE IT wants this approach). * Any tips, best practices for how to start with Desktop app development (Including things like Desktop Managers like XFce, Elightenment etc) in "openSUSE ALP" (Current reference for community part of ALP based distro, based on top of "base install image of ALP"). * Preferred way to distribute apps we know there will be ALP flathub repo in OBS, I think we could have something like "Community version of it". But we should be really smart about this, as the same app could work on top of (Community) ALP as well as Tumblweed. Thoughts? Lubos

2 2

ALP Community WG meetings will be on Tuesdays 14:30 UTC
by Lubos Kocman 23 May '22

23 May '22

Hello openSUSE! Tuesdays 16:30 CEST / 14:30 UTC will be our regular slot for regular ALP Community WG meetings. It won 12:9 on votes at https://doodle.com/meeting/organize/id/b68562Ve Details and how to join the meeting can be found here: https://en.opensuse.org/openSUSE:ALP/Workgroups/Community See you tomorrow! Thank you!

1 0

Vote for the CWG meeting slot. First ALP status report is today
by Lubos Kocman 18 May '22

18 May '22

Hello CWG! I'd like to ask you to vote for our regular meeting slot https://doodle.com/meeting/organize/id/b68562Ve As of now it's either existing Tuesday or Thursday community weekly session. https://etherpad.opensuse.org/p/weeklymeeting We'll meet either weekly and bi-weekly. Aside from that the Adaptable Linux Platform has first status report today. Report for this week on behalf of our group is following https://etherpad.opensuse.org/p/weeklymeeting20220519#L86 Lubos

1 0

Results from Leap Desktop Workshops
by Lubos Kocman 13 May '22

13 May '22

Hello openSUSE! Big thanks to everyone who participated on the Leap Desktop workshop on Tuesday and Thursday. I've seen many familiar faces and there were also a few new friends who are just starting with openSUSE. Both workshops slightly varied in topics which is a good thing. There was certainly an overlap with topics like brand recognition, central place for documentation, marketing, and flatpak support. I felt that Both Scott and Yi Fan from Desktop Workgroup working on the next Generation Desktop got a lot of valueable input. Big thanks to both for being with us on the workshop. Top items from both sessions are on a single *wiki page with references to original **lucidchart boards that should be accessible by everyone. I couldn't upload the exported svgs to the wiki due to 2MB upload limit (already filed a ticket for Heroes to bump it). [0] https://en.opensuse.org/openSUSE:ALP/Workgroups/Community/Workshops/LeapDes… [1] https://lucid.app/lucidspark/9491ef81-067a-4b7f-82c6-2a8fc2839705/edit?invi… [2] https://lucid.app/lucidspark/7a812695-e7ad-4d0e-9c33-74cdb86a92db/edit?invi…

1 0

First!
by Lubos Kocman 12 May '22

12 May '22

Welcome to the Adaptable Linux Community Work group We're currently still in the state "FORMING". Our initial scope will be mainly communication outside, provide status on ALP to community and also initial marketing. For a start please subscribe to https://lists.opensuse.org/archives/list/alp-community-wg@lists.opensuse.or… And watch following page https://en.opensuse.org/openSUSE:ALP/Workgroups/Community Thank you Lubos

1 0