YaST Development December 2022

yast-devel@lists.opensuse.org

7 participants
9 discussions

Codebase(s) and Branch(es)
by Lukas Ocilka 02 Jan '23

02 Jan '23

Hi there, Our current approach so far was to keep all the development in a single branch. This also conforms to the Factory First Policy. This meant Tumbleweed, Leap 15.5, SLE 15 SP5, and also ALP I've learned, that we need to make incompatible changes because of, e.g., dropping Wicked from ALP and Tumbleweed and replacing all with NetworkManager. This would mean splitting into two codestreams and two branches: Edge: Tumbleweed, ALP (Factory First) Stable: Leap 15.5, SLE 15 SP5 (No Factory) We still expect that there will be quite some development in the Stable branch for some time. Of course, bugfixes go to all "applicable" branches where it makes sense anyway. So, is this doable? Do we have resources to keep them in "sync" - but already different? Can we keep both installers at the same time in Edge till D-Installer is mature enough? Thx Lukas -- Lukas Ocilka, Systems Mgmt & Consulting Team Leader & YaST Product Owner SLE Department, SUSE Linux

2 4

Data conversions for AutoYaST profiles
by Ladislav Slezák 22 Dec '22

22 Dec '22

Hello, If you use new data types in the XML profile like <confirm t="boolean">true</confirm> then such profile does not work in SLE15-SP2 and older, it only accepts the old format <confirm config:type="boolean">true</confirm> It would be nice to have some automatic conversion so I created simple XSL transformations for converting between these types. See more details in the documentation https://github.com/yast/yast-autoinstallation/blob/master/doc/profile_conve… Enjoy! :-) Ladislav -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

3 2

[yast-devel] Overcommit - automatic checks via Git hooks
by Ladislav Slezak 21 Dec '22

21 Dec '22

Hi, I found a quite interesting tool called Overcommit [1]. It provides an easy way for setting up Git commit hooks and provides some basic checking plugins. The nice feature of the Git commit hooks is that you can run some checks automatically and early in the development. For example with the commit hooks you can run Rubocop check automatically whenever a commit is created. And if the check fails the commit is not created. I can see "make Rubocop happy" commits quite often (happens to me as well), with Overcommit you can easily avoid that. I have tried several Overcommit checks: - Rubocop - runs Rubocop at "commit" - Rspec - runs the tests before "push" - Branch blacklist - can forbid direct commits to configured branches, e.g. "master" (forces using pull requests, avoids commits to master my mistake) - Commit message spellcheck - warns when there is a possible typo Check my blog post [2] for the details, esp. watch the recorded screencast where I wanted to show some mistakes which it can catch. The tool looks promising, I'll try using it for some time. If you want to try it as well check the blog post for the installation steps. Enjoy! [1] https://github.com/brigade/overcommit [2] http://blog.ladslezak.cz/2016/06/06/overcommit/ -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak(a)suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

3 3

RFC: New D-Installer CLI
by José Iván López González 21 Dec '22

21 Dec '22

Hi all! This year draws to a close, but that does not stop us continuing innovating and evolving our projects. And from the YaST team we want to wish you merry Christmas and a happy new year with a gift you will enjoy for sure: a RFC for the new D-Installer [1] CLI! Please, have a look to our proposal in this gist [2]. We are open to suggestions and new ideas. Don't hesitate to comment either directly in the gist or answering to this mail. Thanks a lot!! Iván [1] https://github.com/yast/d-installer [2] https://gist.github.com/joseivanlopez/808c2be0cf668b4b457fc5d9ec20dc73 -- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez

1 0

Cockpit development
by Ladislav Slezák 20 Dec '22

20 Dec '22

Hello, recently I fixed a small bug in cockpit [1]. The fix is rather trivial but it was quite difficult to test it and verify that it really fixes the problem. ALP Prerequisites ================= 1. Install ALP from https://download.opensuse.org/repositories/SUSE:/ALP/images/, see the previous mails about the installation and configuration 2. Install cockpit with "transactional-update pkg install cockpit", then reboot the system (the backend packages are already preinstalled in the ALP image, this will install the web frontend) 3. Start the cockpit service: "systemctl enable --now cockpit.socket" Now you will have the standard cockpit installed and ready to run, you might test it by connecting to https://localhost:9090 Development =========== Note: I needed to patch a cockpit plugin which is basically a JS code + HTML + CSS. If you would need to patch the cockpit core (the C code) it would be more difficult, see the suggestion in the end. I did the development directly on my workstation (Leap 15.4), the ALP instance was running in a VM. Development Prerequisites ------------------------- For patching a cockpit plugin you should not need much libraries installed, but the the Makefile (generated by autotools) requires the libraries also for the C part. On my workstation I had to additionally install these packages: zypper install json-glib-devel krb5-devel sassc nodejs16 You might actually need some more libraries or tools (autotools), I use my workstation as a development machine and it already contains a lot of libraries. Check that nodejs and npm default versions are 16, esp. if you have multiple versions installed. Originally I probably did something wrong and got some strange failures... Then you can checkout the sources from GitHub git clone git@github.com:cockpit-project/cockpit.git and checkout the version used in ALP cd cockpit git checkout -b 276 Check https://build.opensuse.org/package/show/SUSE:ALP/cockpit, it might change in the future. To build the sources use: # this installs the npm packages using "npm install" ./autogen.sh # autogen.sh runs configure but it will very likely fail, by default it needs # some additional libraries, if you want to patch just a plugin then run ./configure --disable-doc --disable-ssh --disable-pcp --disable-polkit make Now the compiled plugins are available in ./dist/ subdirectory. Now we need to transfer these changed file to the ALP system. There are several possibilities to do this. You can run an "scp" command after each edit/build or you can use some network file system. I tested that with sshfs. The disadvantage is that the sshfs packages are not available for ALP, as a workaround I installed the "sshfs" and "fuse3" packages from Tumbleweed. That works currently because ALP is based on TW, but that will probably not work later when ALP is branched from TW. The clean solution would be to provide a container for that... To mount a directory over sshfs run sshfs <user>@<machine>:<path_to_git_checkout> /mnt Now we need cockpit to load the new files. Fortunately it can load the plugins from the user's $HOME: mkdir ~/.local/share/cockpit link the shared directory from the development machine ln -s /mnt/dist/networkmanager/ ~/.local/share/cockpit/networkmanager (You could link the whole /dist/ to override all plugins, but that could possibly have some side effects, I'd rather just override the updated plugin to be safe.) Then you can just reload the cockpit page in the web browser and that's it, you do not need to relogin or restart the cockpit service. Testing with the "main" branch ============================== Then I wanted to test my change also with the "main" branch to be sure it can be properly submitted to upstream. It turned out that they changed the way how the node modules are loaded. They do not run "npm install" anymore, but rather use Git submodules for that, the whole "node_modules" directory is a Git submodule. The problem is that the submodules are not checked out by default. If you want to use the "main" branch then do the initial checkout with git clone --recurse-submodules git@github.com:cockpit-project/cockpit.git or if you already have a clone without submodules then you can download them with git submodule update --init Be careful when switching the branches! When you later switch to an older version you might need to delete the "node_modules" directory and run ./autogen.sh to install them via npm otherwise you will end up with different modules and probably get some nasty errors! Patching the Core Cockpit ========================= If you need to patch the C part then you could just run "make" and copy the built binary to the ALP VM. The problem is that /usr is read-only in ALP. But you can create a writable overlay using overlayfs: mkdir /tmp/upperdir mkdir /tmp/workdir mount -t overlay overlay -o lowerdir=/usr,upperdir=/tmp/upperdir/,workdir=/tmp/workdir/ /usr Then the /usr will become writable, see more details in https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt Now you can easily rewrite or edit the files there cp /mnt/cockpit-tls /usr/libexec/cockpit-tls To take effect you need to restart the cockpit service systemctl restart cockpit HTH Ladislav [1] https://github.com/cockpit-project/cockpit/pull/17776 -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

2 2

Of D-Installer, xterms and YaST
by Ancor Gonzalez Sosa 20 Dec '22

20 Dec '22

I'm lately a bit busy to take what we, at the YaST Team, call a "learning & innovation day". So I decided to write here a brain-dump of the things I would like to try so others can explore the ideas. First of all, it would be cool to somehow add to D-Installer the possibility to trigger an in-browser terminal like the one offered by Cockpit. When you are using the test ISO you can simply do ctrl+alt+F1. But wouldn't it be cool to have it better integrated and to be able to use it even when you are remotely accessing the web interface of D-Installer (maybe from a tablet or any other system in which you don't have a capable ssh client)?. Moreover, that would imply you would be able to use YaST with its n-curses interface. That should never be needed once D-Installer is feature complete but... let's say you need to format a DASD device to then use it during installation. D-Installer does not yet offer DASD management. Wouldn't be cool to do something like this? 1) Access to D-Installer web interface 2) Open the in-browser terminal 3) Run "yast dasd" there to comfortably manage devices 4) Trigger a device re-scan in D-Installer UI (we don't have such a button yet, but we will need it sooner than later). 5) Adjust the D-Installer storage settings to install in a fresh DASD. The only missing parts would be the terminal (which looks easy to implement using[1] and taking inspiration from Cockpit) and the re-scan button at storage. But, why to stop there? ;-) What if we could make it possible to run YaST modules in a way that is better integrated with D-Installer? I know it's a much crazier idea that makes little sense but, what if I could execute the YaST Partitioner in a terminal in a way in which the resulting staging devicegraph is reflected in the instance of D-Installer (that is, effectively configuring D-Installer storage setup from YaST). Ok, enough. I will go back to work. ;-) Cheers [1] https://www.npmjs.com/package/xterm -- Ancor González Sosa YaST Team at SUSE Software Solutions

3 3

D-Installer: manual testing on bare metal
by José Iván López González 12 Dec '22

12 Dec '22

Hi! I did some manual testing of the live ALP ISO image [1] on real hardware. I am using a Dell XPS 13 laptop. I have tried the 4 possible variants the current storage proposal admits: a) Installing over partitions b) Installing over encrypted partitions c) Installing over LVM volumes d) Installing over encrypted LVM volumes The installation was successful for all them, but I saw some details. With the option b) the web UI gets stuck when there are 47 remaining packages to install. I tried it twice with the same result. Anyway, the installation actually finishes and the system boots. And with option d), the encryption password is requested twice (by grub and kernel). I think this is expected because, as far as I know, the patched grub in ALP only supports the encrypted partitions scenario. I will do more testing with encrypted partitions, because in some test the system did not boot. Regards, Iván [1] https://build.opensuse.org/package/binaries/YaST:Head:D-Installer/d-install… -- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez

2 2

D-Installer: status and call for help with the live ISO
by Ancor Gonzalez Sosa 06 Dec '22

06 Dec '22

D-Installer development is going fine but we need help in some areas. For those who don't know, D-Installer is a project by the YaST Team to create an universal installer for (open)SUSE operating systems. It uses the power of YaST under the hood and can be controlled via a D-Bus API, a command-line interface or a modern web front-end. Check our latest blog post to learn more about the status of the project (with fresh screenshots!) and how you can help. Programming skills not needed. https://yast.opensuse.org/blog/2022-12-05/d-installer-needs-you Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH

1 0

Re: [oS-en] What is the meaning of the moon in YaST
by Luna Jernberg 01 Dec '22

01 Dec '22

Hey! The Moon there is to change the Stylesheet/Theme in YaST for Dark Mode or Accessibility modes etc On Thu, Dec 1, 2022 at 1:56 PM Carlos E. R. <robin.listas(a)telefonica.net> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Hi > > When I open the YaST software manager I see at the top right corner, a > moon crescent or wanning (Leap 15.4) > > What is its meaning? > > - -- > Cheers > > Carlos E. R. > (from 15.4 x86_64 at Telcontar) > > > -----BEGIN PGP SIGNATURE----- > > iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCY4ikahwccm9iaW4ubGlz > dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVjKcAn1yNZKpq4mv/gnYPZzYJ > YdyoTzdHAJ9bUnEvw4OcnRF3SCRXLCeVydPkXw== > =2tXb > -----END PGP SIGNATURE-----

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

YaST Development December 2022