November 2022 - YaST Development - openSUSE Mailing Lists

[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

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

ARIA and the D-Installer
by Ladislav Slezák 28 Nov '22

28 Nov '22

Hi all, recently I did some quick research about ARIA and how we should use it in the D-Installer. Here is a short summary. ARIA = Accessible Rich Internet Applications It's basically a set of attributes for making web applications accessible to people with disabilities. ARIA helps the assistive technologies (like screen readers) to better understand web pages. There is even a W3C specification for it, see [1]. But that is too low-level and boring to read (as specifications usually are). It is much better to start with the Mozilla documentation [2]. At the very begging it mentions two facts: 1. Prefer using semantic HTML elements (like <h?>, <input type="checkbox"> or <button>), these have implicit ARIA attributes and you do not need to specify them. You should use ARIA only for the generic tags (<div>, <span>) or if you use the semantic elements for different meaning (e.g. <ul> is often used for tabs). 2. No ARIA is better than bad ARIA. If you do it wrong then it makes the situation even worse. If you are not sure whether to use ARIA it is safer to NOT use it. I'd add one more fact: 3. Many CSS/JS frameworks define the ARIA attributes themselves (like the PatternFly used by the D-installer). If you use the provided elements properly then you should not need to add/change the ARIA attributes. If we sum up all these items then the result is that we should not take extra attention to the ARIA in the D-Installer unless we get a bug report or we spot a clear need for it. HTH Ladislav [1] https://www.w3.org/TR/wai-aria-1.0/ [2] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

1 0

D-Installer changelogs update
by Imobach Gonzalez Sosa 25 Nov '22

25 Nov '22

Hi all, To make testing easier, I would like to update D-Installer images after merging each PR. Of course, we could have a "blessed" version in the future for end-users, but I would like to start building the testing image as soon as possible. For that reason, I would like to kindly ask you to update the changes files in each PR. They are in the package/ directory of each module (service, web, cli, image). We do not need to update the version by now. I will do it manually. Regards, Imo -- Imobach González Sosa SUSE Linux LLC

1 0

yast2-theme & yast2-qt-branding-opensuse *require* two different font packages
by Felix Miata 24 Nov '22

24 Nov '22

6 different web browsers I tried won't display <https://fonts.google.com/specimen/Poppins:> "Something went wrong. Please try again soon." I tried <https://fonts.google.com/specimen/Open+Sans> in one browser and it does the same thing. yast2-theme requires google-poppins. yast2-qt-branding-opensuse requires google-opensans. Why are these two font packages required? Is there good reason? What does each font provide that the other doesn't? What do they provide that any other ttf or otf can't that justifies mandatory installation if QT YaST is installed? -- 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

3 2

D-Installer 0.5 released
by Imobach Gonzalez Sosa 21 Nov '22

21 Nov '22

Hi all, We have released a new version of D-Installer which includes quite a lot of changes and fixes: * Add support for basic network configuration, based on NetworkManager (gh#yast/d-installer#260, gh#yast/d-installer#292). * Improve the usability of the LUKS activation dialog (gh#yast/d- installer#253). * Prevent starting the installation with incomplete or wrong configuration (gh#yast/d-installer#299). * Use D-Bus activation instead of explicit service starting (gh#yast/d- installer#287). * Load the configuration from /etc/d-installer.yaml (gh#yast/d- installer#301). * Move D-Bus configuration to /usr/share (gh#yast/d-installer#254). * Extract questions and storage handling to separate services (gh#yast/d-installer#248). * Extend the D-Bus API for the storage proposal (gh#yast/d- installer#268). * Do not block after software installation if a package cannot be installed (gh#yast/d-installer#322). * Add support to install the Adaptable Linux Platform Host OS (gh#yast/d-installer#265). * Update Leap Micro to version 5.3 (gh#yast/d-installer#318). As usual, you can grab the new version from the YaST:Head:D-Installer project: https://build.opensuse.org/package/binaries/YaST:Head:D-Installer/d-install… Please, if you are interested, give the new version a try and report any problem to https://github.com/yast/d-installer Thanks in advance! Regards, Imo -- Imobach González Sosa SUSE Linux LLC

1 0

YaST Team: 11th development report of 2022
by Ancor Gonzalez Sosa 16 Nov '22

16 Nov '22

The YaST team keeps evolving D-Installer without forgetting about YaST itself. News on both fronts include: - Many improvements in D-Installer - The possibility to use SLED on WSL - AutoYaST support for the new security profiles feature - A new tool to visualize installation logs Check the full report at https://yast.opensuse.org/blog/2022-11-16/yast-report-2022-11 Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH

1 0

Re: Community Meeting / D-Installer Workshop: Week 45
by Luna Jernberg 11 Nov '22

11 Nov '22

Did another test with todays D-Installer and installation of Tumbleweed into Virtualbox still works with it :) On Thu, Nov 10, 2022 at 9:02 PM Luna Jernberg <droidbittin(a)gmail.com> wrote: > > Not joining the meeting today, got stuck in Ubuntu and Crystal Linux stuff > > On Mon, Nov 7, 2022 at 2:58 PM ddemaio <ddemaio(a)suse.de> wrote: > > > > Hi all, > > > > The Tuesday meeting tomorrow that takes place at 15:30 UTC will do a > > D-Installer Workshop. Info about this and testing the next gen installer > > can be found it this article > > https://news.opensuse.org/2022/10/27/call-for-testing-next-gen-installer/ > > > > The Community Meeting on Thursdays will take place at 20:00 UTC. > > > > Both meetings take place in https://meet.opensuse.org/meeting > > > > You can see the overview of meeting notes at > > https://etherpad.opensuse.org/p/weeklymeeting > > > > v/r > > Doug

1 0

Logging AutoYaST profile SHA1 checksum
by Ladislav Slezák 07 Nov '22

07 Nov '22

Hi all, recently I was debugging a reported bug in AutoYaST and it turned out that the YaST log does not match the used AutoYaST profile, the log complained about some wrong custom script but the attached profile did not define anything like that. In this case we could relatively easily find out that the attached profile was not the profile which was really used by AutoYaST. But in other cases it might be more difficult or even impossible. We cannot log the whole AY profile for security reasons (it might contain registration keys, user passwords or other sensitive data) so I slightly improved logging in the "master" branch. Now AutoYaST logs the SHA1 checksum of the profile and rules or classes files if they are used. Then you can easily get the checksum of the attached profile by using a command like "sha1sum autoyast.xml". The checksum must be the same as logged by YaST, simple "grep SHA1 y2log" should find it. If the checksum is not the same than the file used by YaST was different. (Note: This compares the files bitwise, e.g. adding a newline at the end of a XML file does not change the logical content but the SHA1 will be completely different. But as you cannot be sure what users actually changed it should be always a good idea to ask for the real file.) See more details in the GitHub pull request https://github.com/yast/yast-autoinstallation/pull/857 -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

1 0

Testing d-installer in qemu aarch emulation
by josef Reidinger 02 Nov '22

02 Nov '22

Hi, just if someone wants also give a try d-installer in qemu emulation. I tried it on my local machine and speed is not so bad, but it reveal a weak point which can maybe affect also other weaker machines when using d-installer. It failing in systemdd service and even if run manually with `d-installer`. If you run d-installer as one binary that start others with 1s delay[1] between services does not need to be enough and due to race condition some service can fail due to missing required dbus interface that is not yet exported. As workaround run each service separately and for each wait when it really start exporting interface. Maybe it is time to fix TODO and implement better way? It can help with low-end machines. And with workaround it works and I can reproduce issue on aarch64.[2] Josef [1] https://github.com/yast/d-installer/blob/master/service/bin/d-installer#L56 [2] https://github.com/yast/d-installer/issues/279#issuecomment-1299236944

3 2