May 2023 - YaST Development - openSUSE Mailing Lists

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