I found a quite interesting tool called Overcommit .
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  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.
Appliance department / YaST Developer
190 00 Prague 9 / Czech Republic
tel: +420 284 028 960
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
recently I fixed a small bug in cockpit . The fix is rather trivial but it was
quite difficult to test it and verify that it really fixes the problem.
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
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.
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 email@example.com:cockpit-project/cockpit.git
and checkout the version used in ALP
git checkout -b 276
Check https://build.opensuse.org/package/show/SUSE:ALP/cockpit, it might change in
To build the sources use:
# this installs the npm packages using "npm install"
# 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
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:
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 firstname.lastname@example.org: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
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
mount -t overlay overlay -o
Then the /usr will become writable, see more details in
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
SUSE LINUX, s.r.o.
18600 Praha 8
Helping out :)
On Thu, Oct 27, 2022 at 1:33 PM ddemaio <ddemaio(a)suse.de> wrote:
> Hi all,
> I wanted to bring your attention to an article I just posted about the
> next generation installer. The team is looking to have people test out
> the images. There is a guide to walk you through it should you be
> interested in testing it.
Reading YaST logs, especially from installation or upgrade might be very
difficult. The log is very long and contains every detail of the YaST run. Even a
default openSUSE Leap 15.4 installation where you basically just press Next, Next,...
produces about a 13MB log file (uncompressed) with more than 80.000 lines!
Navigating in such a log is very difficult, you can see every tiny detail what was
done, but it is hard to see the big picture, why was that happening, what was
Also some code parts are repeated during the installation. For example evaluating
the base product is done several times during installation, in the self-update step,
when displaying the base product license, when registering the system... So if you
see in the log the base product evaluation you cannot be sure to which step that
To improve the situation I have implemented two things:
- enhanced logging
- a new log viewer
I have added a new logger call to YaST, "log.group" call. It logs special markers
around the passed code block:
log.group "Description of the group" do
Then you can easily know where that block started and where it finished.
The groups can be nested, you can have a big group consisting of several
See more code examples in  or .
You can add this call to your code to structure the log better.
Here are some real examples which show using the new call in two packages.
- ProductControl - controls the installation workflow, now each installation
step is wrapped in a separate log group 
- Registration - each registration step now has separate log group 
To take advantage of the new log messages we need a new log viewer.
I created an experimental web based log viewer at
It can load a local y2log file or an archive created by the "save_y2log" script
(a *.tar.(bz2|gz|xz) file). It can also load a remote file from a specified URL.
It provides basic filtering functions so you can hide some messages depending on the
log lever or the component. Click the "Filter" button in the top right corner.
It is a static web page and it uses some HTML5 features, the files are processed
completely locally. See the notes on the main page.
(Note: Martin found out that it cannot read tarballs in FireFox, reading plaing text
logs works fine. Use Chrome/Chromium browser, that works fine. Later I'll look at
The source code is available in , ideas or pull requests with improvements will be
So far it is hosted in my GitHub account, if it is useful I can move it to the
"yast" organization later.
I uploaded an example log with the new features so you can see how it looks in
the new viewer. See link  below, click the "Load URL" button, scroll to the
bottom to see the new grouped sections.
SUSE LINUX, s.r.o.
18600 Praha 8
Here it comes another bunch of news from the YaST Team trenches including:
- Several news about D-Installer
- An update about the new Security Policies in the YaST installer
- An effort to streamline a bit the YaST container
- Some polishing of Podman checkpoints for Tumbleweed and ALP
Check the full report at
Ancor González Sosa
YaST Team at SUSE Linux GmbH