I have enabled RSpec verifying doubles in all remaining YaST unit tests where they
were not used. The advantage is that RSpec checks that the mocked methods really
exist in the original class. Without it if you make a typo in a method call in the
code and make the same typo in the unit test mock then the test will pass but the
code will actually crash at run time.
So ideally we should enable this feature everywhere.
But in the YaST unit test we quite often replace some YaST modules with an empty
class to avoid too long or cyclic build dependencies. If you mock an YaST module
completely then you have the same problem back as the dummy methods are really
defined there so even RSpec verifying doubles will not catch the problems there.
To use advantages from the both worlds I have created a new
Yast::RSpec::Helpers.define_yast_module helper method. 
It tries to load the requested YaST module via the usual YaST.import call. If that
fails then it defines a dummy replacement for it. So if the module is present in the
system, like when you run the unit tests locally on your machine or when running in
GitHub Actions where most of the modules are present, then it will load the real
modules and the verifying doubles will fully work.
In RPM build it will create dummy modules and the build dependencies can be avoided.
# defined here, needs yast2-ruby-bindings >= 4.4.7
# if you do not mock the module methods in the tests you can use
# this simple variant
# if you mock some methods then they must be defined in the mocked class
# so the verifying doubles check does not fail
Yast::RSpec::Helpers.define_yast_module("Profile", methods: [:current])
# note: for simplification all mocked methods accept any number of parameters,
# the real parameters should be verified when running against the real modules
# you can also pass a block which is evaluated in the context of the created class
# so you can define some defaults, in theory you could define also some logic there
# but I'd avoid it, the mocked logic might easily go out of sync with the real module
# the default
Then if you run "rake test:unit" locally the modules will be loaded from system when
found. If you want to force creating the mocked modules even when they are present in
the system then just set the YAST_FORCE_MODULE_STUBS environment variable, e.g.:
YAST_FORCE_MODULE_STUBS=1 rake test:unit
This is useful if you want to test locally how it will work in RPM build, whether
your mocks implement all the methods used in the tests.
You can check some real examples in  and .
And interestingly enabling verifying doubles found a real bug in the code! 
SUSE LINUX, s.r.o.
18600 Praha 8
I created an empty testing RPM repository  which might be easily used in some tests.
Advantage of an empty repository is that it cannot affect the installed packages or
cause any conflicts. It can be also used with any product in any version.
The most important feature of this particular repository is that it is signed by the
official SUSE GPG keys! So YaST or zypper will not complain about unknown or missing
GPG signatures and it can be easily used in automated tests.
SUSE LINUX, s.r.o.
18600 Praha 8
I have added another Docker image into the YaST:Head OBS project. It's a Ruby image
based on Leap 15.4.
The reason is that Leap 15.4 contains Ruby 2.5 (just like SLE), the original image
based on Tumbleweed contains Ruby 3.0 now (3.1 soon...).
The goal is to run CI using both images so we can be sure the YaST packages work
properly in both Tumbleweed and SLE/Leap. Another goal is to run Rubocop and Yardoc
in the Ruby 2.5 image as they do not work properly in Ruby 3.x.
I have adapted all YaST repositories which use our Ruby Docker image in the GitHub
Actions. See  as an example.
- Only the unit tests and package build jobs run in both images, the rest (Rubocop,
Yardoc, ...) run in just one image, that should be enough.
- Code coverage is sent only from the Tumbleweed build to avoid race conditions
and possibly inconsistent results.
- The YAML files were automatically patched by a script (in 120 Git repositories!)
but I did a manual review of each change and did some manual tweaks in some cases
(e.g. it does no make sense to build the TW control file in Leap, or the other way
round, the SLES control file does not make sense to build in TW).
- If you think some builds or some changes do not make sense, or the other way round,
something is missing feel free to fix that. The config is not set in a stone. :-)
If you have any questions just ping me.
SUSE LINUX, s.r.o.
18600 Praha 8
This has been going on too many releases to remember when it started. The FG/BG
contrast on the (active) Next button is low. The BG color seems lighter than the
what appears should be the matching color elsewhere. It might not seem so if only
the FG was #FFF or #000 instead of gray. It seems as if the Next button is colored
to indicate something else needs to be done before it can be selected to proceed.
The other buttons' dark gray on light gray seems could stand to have improved
contrast too. More contrast should help make up for fuzziness on lower resolution
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!
Now that we are toying with the idea of yastd and a web interface to it,
maybe we have a mentorship opportunity there.
-------- Forwarded Message --------
Subject: openSUSE - Google Summer of Code 2022
Date: Tue, 11 Jan 2022 17:06:41 +0100
From: ddemaio <ddemaio(a)suse.de>
Applications for mentor organizations for the Google Summer of Code
2022, will be from February 7 - 21, 2022. The openSUSE Project has a
long history of participating as a mentor organization, and we hope to
do so again this year!
If you are interested in mentoring for your open source project, please
let us know so that we can come up with a list of interested mentors,
and can move forward with our application.
As a mentor you would be committed to actively mentoring a student(s)
if/when openSUSE becomes selected as an organization.This would involve
keeping the student(s) on task, actively communicating with them and
writing progress reports; there are 2 reports that mentors must write (a
midterm and final review). The timeline for GSoC can be found at
<https://developers.google.com/open-source/gsoc/timeline>, along with
other relevant information on roles and responsibilities for both
mentors and students.
If there are enough interested mentors to proceed with an application,
which we will let you know ASAP, potential mentors would need to update
the git repository (https://github.com/openSUSE/mentoring
<https://github.com/openSUSE/mentoring>) for https://101.opensuse.org
<https://101.opensuse.org>, so that we can submit the application.
If you have any questions, please let us know.
New rubocop in testing. New shared config is done and also demonstrated on three example modules. Speak now or complain later.
PR with new shared rubocop including reasoning: https://github.com/yast/yast-devtools/pull/163
PR with adaptation of picked modules:
Long Version and Observations
TW now uses ruby 3.0 and will be soon using 3.1. The bad part is that our ancient versions of rubocop does not work with new ruby. So we had two options either patch old rubocop or adapt to new one. After discussion we decide for the second option as even our older version had problem with some ruby 2.3 syntax.
- new rubocop has safe and unsafe auto corrections. --auto-correct do only safe ones. -A does both. It is useful when doing adaptation as I usually do safe first and then carefully review rest of changes done by -A
- rubocop --only is useful to fix just set of cops if you have huge list of issues. I do it, when I want to do manual cops one per commit
- redundant branch cop has issue with some workflow encoded in elsifs..as two branches looks identical, but it is under chain of previous condition . In general problem mainly in uterly old ugly code and it is quite rare
- similar issue applies to new combinable loops cop. As a loop can modify itself or order is important like in this case of storage-ng https://github.com/yast/yast-storage-ng/pull/1278/commits/e1d9020409409f0b5…
- new cop to check if important methods like constructor call super is quite useful and reveal some real bugs in storage-ng code ( like using nil as widget ID for Empty object ). I think majority of issues needs fix in https://github.com/yast/yast-storage-ng/pull/1278/commits/14ca4c6f4544362d5… as trivial fix was not enough and I overlook it at first.
- also Lint/DuplicateElsifCondition find real bug in yast2 - https://github.com/yast/yast-yast2/pull/1230/commits/6866413d9fdfc94619d823…
So please comment in pull request or directly as answer here to email. I think quick discussion can happen on review meeting.