June 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

Modified installation progress
by josef Reidinger 06 Jul '22

06 Jul '22

Challenge: ---------- Libzypp supports parallel download and install. Yast installation progress does not fit it at all [1]. Issues are secondary progress bar that does not work with parallel installation. Also there are overwhelming amount of information on screen that is quite distracting. That information is often wrong like time estimation. And also table for media is a bit useless nowadays as everything is on one iso/medium, so there is no need to see when cd switch will be needed. The details tab are the most visible as it is default one. Proposal: --------- Remove completely that details tab and keep just release notes one[2]. It contains release notes that contain useful information and also has just one progress bar. For that bar remove keep always just remaining size and count of packages, so user has idea how it does, but do not print what exactly is installing or any time estimation. If there are more release notes allow to switch between them. Also keep possibility to have slide show which we had in past for installation if someone create some ( when checked other OSes, the Ubuntu slide show during installation looks probably the best from user POV ). The same changes will apply to ncurses front end[3], we just need to check why formatting of release notes are so badly formatted. And same for opensuse[4] of course. Josef [1] https://pasteboard.co/cNBjER6SnLLT.png [2] https://pasteboard.co/WnI7wS7VVVqq.png [3] https://pasteboard.co/vzQvY1PaVDaD.png [4] https://pasteboard.co/FzEqcIN7Xnas.png

15 40

Pending Pull Requests
by yast-ci＠opensuse.org 27 Jun '22

27 Jun '22

This email is automatic generated from yast CI node. It lists of pull requests that have no activity more then three working days. If your module is listed, please check all pull request, why they are not merged yet. Pending requests in repository yast-devtools: - Sle15sp3 boo1199396 (47 days) https://github.com/yast/yast-devtools/pull/168 - Set %yast_icondir to /usr/share/icons/hicolor (bsc#1186066) (139 days) https://github.com/yast/yast-devtools/pull/161 Pending requests in repository yast-installation: - Do not restart services when the package is updated (10 days) https://github.com/yast/yast-installation/pull/1048 - Fixed a syntax error in the README (23 days) https://github.com/yast/yast-installation/pull/1047 - Remake some icons (104 days) https://github.com/yast/yast-installation/pull/1028 Pending requests in repository yast-kdump: - Implement KDUMP_AUTO_RESIZE (62 days) https://github.com/yast/yast-kdump/pull/123 Pending requests in repository yast-packager: - Remake some icons (123 days) https://github.com/yast/yast-packager/pull/603 Pending requests in repository yast-theme: - Add pantheon desktop support (208 days) https://github.com/yast/yast-theme/pull/154 Pending requests in repository yast-update: - [SP3] Use the "norecovery" mount option (bsc#1195894) (131 days) https://github.com/yast/yast-update/pull/179 Pending requests in repository yast-auth-server: - Remove Kerberos Functionality (17 days) https://github.com/yast/yast-auth-server/pull/74 - Fix log path (93 days) https://github.com/yast/yast-auth-server/pull/72 Pending requests in repository yast.github.io: - [dependencies] Bump nokogiri from 1.13.3 to 1.13.6 (38 days) https://github.com/yast/yast.github.io/pull/324 Pending requests in repository yast-journal: - Use Yast::Builtins.strftime in 'Change Filter' dialog (138 days) https://github.com/yast/yast-journal/pull/45 Pending requests in repository helper_scripts: - [dependencies] Bump nokogiri from 1.13.3 to 1.13.6 in /jekyll (38 days) https://github.com/yast/helper_scripts/pull/39 Pending requests in repository yast-samba-provision: - Sle15 sp1 update (37 days) https://github.com/yast/yast-samba-provision/pull/10 Pending requests in repository yast-sap-ha: - Sle 15 sp3 (6 days) https://github.com/yast/yast-sap-ha/pull/9

1 0

Using GitHub Releases
by Ladislav Slezák 21 Jun '22

21 Jun '22

Hi all, I'd like to shortly mention the GitHub Releases here, just in case you do not know this GitHub feature... GitHub can not only host the sources for your project, but it can be also used for distributing the built binaries. For YaST that is not much useful as we use OBS for that, but many upstream projects use this. I tried to use this feature for publishing a testing DUD with a fix. Of course, you can always attach the DUD to bugzilla. But that's not easy to use, you have to download and host the file on some server [1]. That's annoying. Example: -------- I built a testing DUD which can be used directly from GitHub with this boot option: dud=https://github.com/yast/yast-update/releases/download/bsc_1200127/dud.c… You do not need to download anything, it just works! The only minor drawback is that the URL is pretty long and you need to carefully write that on the boot command line. You might use an URL shortener service, it tried to minify the URL to dud=https://bit.ly/3OoevuJ and it works fine. But you should be careful when using shortened URLs, you do not know where they actually point to. And even if it looks OK the author can later edit it and change the target to point to some malicious file... Note: In this particular case I did it mainly for testing purpose, this proposed fix is for just one customer so it does not make much sense to publish it at GitHub. They will most likely use the DUD from bugzilla. But if you have a bug fix which will be used by more users then this GitHub feature can be very useful. How to use it? -------------- 1. Go to the main GitHub page of the project, click the "Releases" section header in the right side bar 2. Clink the "Create a new release" button 3. Select the Git branch name and tag to which this release will be bound to. A tag is required, if the respective tag does not exit just write some, GitHub will automatically create it from the selected branch 4. At the bottom there is an area for attaching the binaries, just click it and select the built files to upload 5. If this is just a testing build (code not merged yet), select the "pre-release" option so the users know this is not the final version and might be changed later 6. Press "Publish release"... and that's it! Enjoy! :-) GitHub Packages Note -------------------- There is a similar feature called GitHub Packages. But that supports only releasing "packages" in some special registry services, like container registry, npm registry, rubygem registry, etc... That cannot host arbitrary packages or files. See [2] for more details. Ladislav [1] For testing purposes you can always use something trivial like ruby -run -ehttpd . -p8000 and use the http://<your_IP>:8000/ or http://localhost:8000/ URL [2] https://docs.github.com/en/packages/learn-github-packages/introduction-to-g… -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

1 0

Pending Pull Requests
by yast-ci＠opensuse.org 20 Jun '22

20 Jun '22

This email is automatic generated from yast CI node. It lists of pull requests that have no activity more then three working days. If your module is listed, please check all pull request, why they are not merged yet. Pending requests in repository yast-devtools: - Sle15sp3 boo1199396 (40 days) https://github.com/yast/yast-devtools/pull/168 - Set %yast_icondir to /usr/share/icons/hicolor (bsc#1186066) (132 days) https://github.com/yast/yast-devtools/pull/161 Pending requests in repository yast-installation: - Fixed a syntax error in the README (16 days) https://github.com/yast/yast-installation/pull/1047 - Remake some icons (97 days) https://github.com/yast/yast-installation/pull/1028 Pending requests in repository yast-kdump: - Implement KDUMP_AUTO_RESIZE (55 days) https://github.com/yast/yast-kdump/pull/123 Pending requests in repository yast-packager: - Remake some icons (116 days) https://github.com/yast/yast-packager/pull/603 Pending requests in repository yast-python-bindings: - Sle15 sp1 examples fixup (30 days) https://github.com/yast/yast-python-bindings/pull/42 Pending requests in repository yast-schema: - bsc#1198848: simplify online_update_configuration format (23 days) https://github.com/yast/yast-schema/pull/138 Pending requests in repository yast-theme: - Add pantheon desktop support (201 days) https://github.com/yast/yast-theme/pull/154 Pending requests in repository yast-update: - [SP3] Use the "norecovery" mount option (bsc#1195894) (124 days) https://github.com/yast/yast-update/pull/179 Pending requests in repository yast-auth-server: - Remove Kerberos Functionality (10 days) https://github.com/yast/yast-auth-server/pull/74 - Fix log path (86 days) https://github.com/yast/yast-auth-server/pull/72 Pending requests in repository yast.github.io: - [dependencies] Bump nokogiri from 1.13.3 to 1.13.6 (31 days) https://github.com/yast/yast.github.io/pull/324 Pending requests in repository yast-journal: - Use Yast::Builtins.strftime in 'Change Filter' dialog (131 days) https://github.com/yast/yast-journal/pull/45 Pending requests in repository helper_scripts: - [dependencies] Bump nokogiri from 1.13.3 to 1.13.6 in /jekyll (31 days) https://github.com/yast/helper_scripts/pull/39 Pending requests in repository yast-samba-provision: - Sle15 sp1 update (30 days) https://github.com/yast/yast-samba-provision/pull/10 Pending requests in repository yast-sap-ha: - Sle 15 sp3 (6 days) https://github.com/yast/yast-sap-ha/pull/9

1 0

Porting an YaST module to container
by Ladislav Slezák 17 Jun '22

17 Jun '22

Hi all, as already mentioned, we are experimenting with the containerized YaST. Not all modules work out of box in that environment, some need small adjustments. To make it easier I created a short document which might help with porting: https://github.com/yast/yast-in-container/wiki/Porting-YaST-Modules-to-Cont… If you have any comments, questions just ping me. If you have some tips or you want to add something, then do not hesitate to edit the page, it's a wiki! ;-) Ladislav -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

1 0

Re: YaST in a YaST-less system
by Ancor Gonzalez Sosa 14 Jun '22

14 Jun '22

On 6/13/22 18:45, Jan Engelhardt wrote: > On Monday 2022-06-13 18:16, Ancor Gonzalez Sosa wrote: > > # zypper in yast > [...] > > 26 new packages to install. > Overall download size: 11.5 MiB. Already cached: 0 B. After the operation, additional 27.6 MiB will be used. > > # zypper in podman > [...] > > 9 new packages to install. > Overall download size: 25.0 MiB. Already cached: 0 B. After the operation, additional 113.9 MiB will be used. > > So instead of having to install yast2 (zypper tells me 11 MB), I now have to > podman (25 MB). The outcome of those two commands heavily depend on the system you execute them. What you show is the result in a traditional openSUSE in which the software is delivered as packages directly installed in the system (the paradigm I personally use and love). But that's not the only reality we find out there nowadays. You and me, who still enjoy the traditional model of Linux distributions, will still install YaST directly in the system. That's perfectly fine and will always be possible, of course. But the new containerized YaST broadens the usefulness of YaST to also cover other scenarios in which installing RPM packages is only done as a last resort and containers are the preferred way to distribute and consume software. >> those new commands grab YaST and run it in a container that will >> be transparently used to administer the host system. > > It's logically backwards that one is supposed to run Y2 in a > container, only to have it go outside again. Containers are not > supposed to affect the host system. Actually privileged containers can affect the host system. And they have existed for years. Isolating the base system from the software running inside the containers is only one of the possible goals of containers. In some environments, containers are the main mechanism to distribute and execute software since they represent a way to bundle several software pieces (traditionally RPM packages) in a self-contained format. Now YaST is an option also in those environments. Although I expect YaST to be used seldom there - basically to cover situations in which other tools fall short in functionality or to ease transition for administrators of traditional (open)SUSE distributions. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions

1 0

Re: YaST in a YaST-less system
by Ladislav Slezák 13 Jun '22

13 Jun '22

Dne 13. 06. 22 v 18:45 Jan Engelhardt napsal(a): > So instead of having to install yast2 (zypper tells me 11 MB), I now have to > podman (25 MB). Of course, using containers is not for free, it needs some container runtime. It depends what you already have installed in your system. If you already have Ruby (e.g. because you develop a Ruby on Rails app) then the needed YaST size would even go down. Similarly with podman. But it seems that the future is in containerization of apps, so podman (or a similar tool) will be very likely installed anyway. > It's logically backwards that one is supposed to run Y2 in a container, only to > have it go outside again. Containers are not supposed to affect the host system. It depends what you want to do. Usually you want a container to work in isolated environment. But running YaST in an isolated container (without host system interaction) is pointless. And there are already some other tools which run in a container but affect the host system, e.g. the Portainer (https://www.portainer.io/) which is a Docker manager running inside a Docker container managing the host Docker instance. So this approach is not that unusual as it might seem on the first sight. > So you have to widen the namespace to the point that it _is_ the host system, > mounts included, at which point you could have just installed Y2. Um, yes. But the point is that the YaST dependencies cannot collide with the system. SLES still ships with Ruby 2.5, in theory the YaST container could use newer Ruby 3.1 and we could use some new Ruby features there. And that applies to any other used library. Also the host system could contain even less packages, for example you do not need zypper/libzypp in the host system, even rpm (!) itself is not required if you run the YaST package manager in a container. (I have tested this in real!) Another advantage is that you can get rid of YaST just with a simple "docker/podman rmi" command and you can be sure it won't break any system dependencies or uninstall something you actually need (like Ruby for your Ruby on Rails app). Containerization has both pros and cons. But we think the pros will be more important in the future and the cons will be just minor issues or completely disappear.... -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8

1 0

Re: YaST in a YaST-less system
by Andrei Borzenkov 13 Jun '22

13 Jun '22

On 13.06.2022 19:45, Jan Engelhardt wrote: > > > So instead of having to install yast2 (zypper tells me 11 MB), I now have to > podman (25 MB). > But if you already have podman but not yast ... > >> those new commands grab YaST and run it in a container that will >> be transparently used to administer the host system. > > It's logically backwards that one is supposed to run Y2 in a > container, only to have it go outside again. Containers are not > supposed to affect the host system. > Ever heard about toolbox container for SUSE MicroOS? What about firewalld container? What about VPN containers? And this can continue ... Containers can be used just for application delivery, they are not restricted to application isolation. > So you have to widen the namespace to the point that it _is_ > the host system, mounts included, at which point you could have > just installed Y2. May be not often, but for one off task this could be quite handy. Or read-only root where you simply cannot install anything ...

1 0

YaST in a YaST-less system
by Ancor Gonzalez Sosa 13 Jun '22

13 Jun '22

The YaST Team has been recently playing with a fun concept. What about running YaST inside a container to manage a system without having YaST or any of its dependencies installed? Turns out it works and we plan to go further! Learn more at https://yast.opensuse.org/blog/2022-06-13/yastless-yast Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH

1 0