- YaST Development

GitHub CI - "leap_latest" updated to Leap 15.5
by Ladislav Slezák 20 Jun '23

20 Jun '23

Hi all, I have updated the "leap_latest" container used in GitHub CI from openSUSE Leap 15.4 to Leap 15.5. You do not need to do any changes, just be prepared that the new CI runs will use Leap 15.5 as the base system. There should be minimal changes between 15.4 and 15.5 so I expect everything should work just fine. However, if you see some related problem just ping me. Ladislav -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

1 0

YaST:Head - added Leap 15.5, removed Leap 15.3
by Ladislav Slezák 20 Jun '23

20 Jun '23

Hello! I have added the openSUSE Leap 15.5 build target to YaST:Head OBS project. (https://build.opensuse.org/project/show/YaST:Head) And I removed the openSUSE Leap 15.3 build target because it is out of support (already for ~6 months) and to save some build resources. Enjoy :-) Ladislav -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

1 0

New Agama OBS Projects systemsmanagement:Agama:Staging and systemsmanagement:Agama:Devel
by Ladislav Slezák 13 Jun '23

13 Jun '23

Hi all, I created new OBS projects for developing the Agama installer: https://build.opensuse.org/project/show/systemsmanagement:Agama:Staging https://build.opensuse.org/project/show/systemsmanagement:Agama:Devel The old YaST:Head:Agama project is not updated anymore and will be removed at some point. Do not use it. I also added the Agama containers from YaST:Head:Containers there. Staging ------- The systemsmanagement:Agama:Staging project contains the latest packages built from the "master" branch in Git. This project contains unstable development version of Agama. It is intended for development or testing new unfinished features. The packages are automatically updated whenever the master branch is changed. Devel ----- The systemsmanagement:Agama:Devel project contains the latest released version of the Agama project. The packages should be more stable than in the Staging project. It is intended for testing. These packages are updated automatically when a new version is released. Documentation ------------- You can find some more details in the documentation: https://github.com/openSUSE/agama/blob/master/doc/obs_integration.md -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

1 0

Report from openSUSE Conference 2023
by Ancor Gonzalez Sosa 31 May '23

31 May '23

Already in my way back from oSC'23, so let's write some notes before I forget. I could feel a lot of interest in Agama even since before the conference itself started, in the welcome party. There was only another topic that looked more important for basically everyone there - the question I was asked 10+ times per day from Thursday to Sunday: Where is the rest of Canary gang? oSC feels incomplete without them! About the second more important topic (apparently), I can say our presentation was extremely well received. Most people looked genuinely interested, not to say excited, about Agama. And looking at the kind of questions I got before the presentation and the feedback I got afterwards, I would say the talk addressed its goal pretty well and there are more people now with a proper understanding of Agama and the installation process in general. And there are people already having ideas about how to contribute, adapt it or adopt it. I saw a lot of interest from the community for adopting Agama as default official installer in a relatively short time frame. Unless we screw things up, I would say Agama will be the official installer for Leap 16. What "Leap 16" means exactly regarding the calendar? Well, nothing is set in stone but my assumption after several conversations is that there will be a Leap 15.6 at some point in the future (still using YaST). So Leap 16 will not arrive before 2024. Gradual integration with Tumbleweed may start a bit in advance. Based on those same conversations, I would also expect openSUSE use Agama as a multi-product installer. As LCP pointed to me, that implies we need to resurrect at some point the theming and branding topic. Other area in which we could get some contributions is the initialization process (everything that happens until the point in which Agama takes over). Some people was curious about that and wanted to try their own ideas. I also had some conversations with Uyuni/SUSE Manager developers. They like the part about being able to track the installation process, but they are not so sure our current solution based on D-Bus would suffice to them. Some extra work is still needed to close the gap (hopefully without blowing up the memory consumption). But now that we have a common understanding and some foundations, we can build from there. Some people even tried to hack a bit on Agama, although not very successfully. We may need to check if our current documentation in that regard is in good shape. I'm likely forgetting several conversations and details, but I think the main topics are covered. Do not hesitate to ask for more details in any of them. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions

3 3

OBS + Git Integration
by Ladislav Slezák 29 May '23

29 May '23

Hi all, Last Friday I watched the "Introduction to OBS Gitlab/Github CI Integration" openSUSE conference presentation [1]. It was quite interesting so I'm sharing some details about it here. Later a recording of the presentation should be available, but the slides [1] and the OBS documentation [2] should be enough. Some additional information is available in the OBS blog [3]. This OBS integration allows automatic update and rebuild of a package whenever a source Git repository is updated (Github or Gitlab are currently supported). Optionally it can also also branch a package if you open a pull (merge) request. For YaST we already do the synchronization by using Jenkins CI. But this OBS integration allows to directly setup the communication between Git and OBS without any 3rd tool in the middle. It looks interesting because with this approach we could quite easily set up automatic update of the Agama packages in some OBS staging project... Ladislav [1] https://events.opensuse.org/conferences/oSC23/program/proposals/4211 [2] https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.scm_ci_wor… [3] https://openbuildservice.org/2021/11/09/scm-integration-documentation/ -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

1 0

Multibuild package
by Ladislav Slezák 19 May '23

19 May '23

Hello! I have updated the yast2-schema package to use the multibuild [1] OBS feature. This allows building multiple binary packages from the same sources. The reason is that OBS is switching the backend VCS system to Git [2] and it cannot support the OBS links which are usually used for building multiple packages. The yast2-schema sources builds two binary packages: yast2-schema-default (with the full schema) and yast2-schema-micro (with schema subset used for "micro" products installer with limited functionality). OBS Multibuild -------------- Multibuild in OBS can be use in two ways: - Separate .spec file for each package (we already use it in libyui [3]) - Single .spec file with %if conditions which modify the build process for each multibuild flavor For yast2-schema I used the second approach because the yast2-schema-default and the yast2-schema-micro are very similar, the only difference is that the "micro" package has less build dependencies, the rest is the same. So I merged yast2-schema-default.spec and yast2-schema-micro.spec files into a single yast2-schema.spec file. This makes also maintenance much easier as it avoids duplicates and inconsistencies. You can find more details and an example of using multibuild in a presentation by Max [4]. Building the Package Locally ---------------------------- For building a multibuild package locally using "osc" you need to use the "-M" option with the name of the multibuild flavor you want to build. In YaST we usually use the Rake "osc:build" task for building. Fortunately it accepts additional parameters which are passed to the "osc" tool. So for building the yast2-schema-micro package run this command: rake "osc:build[-M micro]" Adapting CI ----------- Obviously modifying the packaging also affects the related tasks like CI or package submission process. In GitHub Action we basically run simple "rpmbuild *.spec" which unfortunately does not support multibuild packages. The workaround is to manually generate a separate .spec file for each multibuild flavor. See [5] for more details. Adapting Jenkins Jobs --------------------- The "rake osc:sr" command works fine with a multibuild package, it correctly submits the package to the target OBS project. However, it only builds the package for one empty ("") multibuild flavor. The workaround is to explicitly build all multibuild flavors before the package submission: rake "osc:build[-M default]" && rake "osc:build[-M micro]" && rake osc:sr So the package is submitted only if all flavors are successfully built. Notes ----- So far we use multibuild only in one YaST package, when we use it more we could update some tools or scripts to handle multibuild better without that manual workarounds described above. I think currently it does not pay off to add more logic just because of a single package. Also keep in mind that in theory there might be "sle", "leap" or "tumbleweed" flavors designed just for a specific product. In that case building all flavors unconditionally might not be a good idea as the build might even fail if running against an incorrect target. So it depends on the future use cases... Ladislav [1] https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.multibuild… [2] https://bugzilla.suse.com/show_bug.cgi?id=1211319 [3] https://github.com/libyui/libyui/tree/master/package [4] https://www.slideshare.net/suselab/convert-your-package-to-multibuild-on-op… [5] https://github.com/yast/yast-schema/blob/f6e28741a7a178f24ba4fff23c4a06e839… -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

1 0

SLE-15-SP5 branch is autosubmitted to SUSE:SLE-15-SP5:Update
by Ladislav Slezák 11 May '23

11 May '23

Hi all, I have updated the Jenkins jobs to autosubmit the packages from the SLE-15-SP5 branch to the SUSE:SLE-15-SP5:Update OBS project. If you need to submit a blocker bug fix for GM (SUSE:SLE-15-SP5:GA) then you need to submit it manually. ("YAST_SUBMIT=sle_latest rake osc:sr"). -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

1 1

[yast][TW] WARNING: Nokogiri was built against libxml version 2.10.3, but has dynamically loaded 2.10.4
by Felix Miata 02 May '23

02 May '23

# yast2 bootloader & [1] 1134 # Command: /sbin/yast2 bootloader & WARNING: Nokogiri was built against libxml version 2.10.3, but has dynamically loaded 2.10.4 /usr/lib64/ruby/gems/3.2.0/gems/ruby-augeas-0.5.0/lib/augeas.rb:48: warning: undefining the allocator of T_DATA class Augeas # pinxi -Saz --vs --zl --hostname pinxi 3.3.26-29 (2023-04-28) System: Host: e6400 Kernel: 6.2.12-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.0.1 parameters: root=/dev/disk/by-label/h6p09stw net.ifnames=0 5 ipv6.disable=1 consoleblank=0 mitigations=none noresume Desktop: KDE Plasma v: 5.27.4 tk: Qt v: 5.15.9 wm: kwin_x11 vt: 7 dm: 1: KDM 2: XDM Distro: openSUSE Tumbleweed 20230428 # I opened yast2 in order to update bootloader, not something I often do. Is the Nokogiri message something that needs a bug report? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

2 1

RE: Trying a faster linker for Rust
by Imobach Gonzalez Sosa 28 Apr '23

28 Apr '23

Hi, Thanks for the suggestion, William. I tried sccache[1] and it reduced the build time of the whole project to half of the time. We might consider adding it to GitHub Actions[2]. Regards, Imo [1] https://github.com/mozilla/sccache [2] https://github.com/mozilla/sccache/blob/main/docs/GHA.md ________________________________ De: William Brown <william.brown(a)suse.com> Enviado: jueves, 27 de abril de 2023 23:04 Para: Imobach Gonzalez Sosa <IGonzalezSosa(a)suse.com> Cc: YaST-devel <yast-devel(a)lists.opensuse.org> Asunto: Re: Trying a faster linker for Rust You can also setup sccache both locally and in OBS - they help a ton. With GNU ld and no sccache a Rust compiler build takes ~2 hours on my 8 core xeon With lld and no sccache it takes ~1 hour. With sccache warmed it takes 10 minutes. It's worth looking into :) > On 27 Apr 2023, at 15:59, Imobach Gonzalez Sosa <IGonzalezSosa(a)suse.com> wrote: > > Hi all, > > When working with a compiled language (like Rust, in this case), you must often rebuild the project to test your changes. On my system, after a small change, rebuilding Agama takes around 4 seconds[1]. TIL that most of the time is spent by the linker, and you can switch to a faster one if you wish. In my case, the build time was reduced to around 1.6 seconds. > > AFAIK, you have two options: lld[2] and mold[3], and both of them are available in openSUSE Tumbleweed. > > You need to install "clang" and "lld" or "mold" packages. Then, add the following lines to your ~/.cargo/config.toml file: > > [target.x86_64-unknown-linux-gnu] > rustflags = ["-C", "linker=clang", "-C", "link-arg=-fuse-ld=lld"] > > Replace "lld" with "mold" if you prefer. And that's all 🙂 > > PS: you can want to know how much time it takes to compile each crate, try "cargo build --timings" and check the generated report. > > Regards, > Imo > > [1] Bear in mind that a complete rebuild takes around 35-40 seconds if the dependencies are already downloaded, but that's a different history. > [2] https://lld.llvm.org/ > [3] https://github.com/rui314/mold -- Sincerely, William Brown Senior Software Engineer, Identity and Access Management SUSE Labs, Australia

1 0

Trying a faster linker for Rust
by Imobach Gonzalez Sosa 27 Apr '23

27 Apr '23

Hi all, When working with a compiled language (like Rust, in this case), you must often rebuild the project to test your changes. On my system, after a small change, rebuilding Agama takes around 4 seconds[1]. TIL that most of the time is spent by the linker, and you can switch to a faster one if you wish. In my case, the build time was reduced to around 1.6 seconds. AFAIK, you have two options: lld[2] and mold[3], and both of them are available in openSUSE Tumbleweed. You need to install "clang" and "lld" or "mold" packages. Then, add the following lines to your ~/.cargo/config.toml file: [target.x86_64-unknown-linux-gnu] rustflags = ["-C", "linker=clang", "-C", "link-arg=-fuse-ld=lld"] Replace "lld" with "mold" if you prefer. And that's all 🙂 PS: you can want to know how much time it takes to compile each crate, try "cargo build --timings" and check the generated report. Regards, Imo [1] Bear in mind that a complete rebuild takes around 35-40 seconds if the dependencies are already downloaded, but that's a different history. [2] https://lld.llvm.org/ [3] https://github.com/rui314/mold

2 1