Skip to content

Instantly share code, notes, and snippets.

José Iván López joseivanlopez

Block or report user

Report or block joseivanlopez

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
View multi_state_selection_box.rb
# * [ok] Allow to select more than one item.
# * [ok] Multi state: no selected, selected, auto selected.
# * [ok] Enable/disable items.
# * [ok] Event over item title.
# * [ok] Automatic text wrapping.
# * [No] Auto-focus to the selected item.
# * [No] Event when moving with arrow up/down.
class MultiStateSelectionBox < CWM::RichText
def item(id)


SUSE Linux is moving from using single configuration files to using multiple files. Moreover, some typical configuration files placed at /etc are being moved to /usr/etc, see

All those changes could make YaST fails. For example, when a YaST module tries to reads/writes a file from /etc but that file is not there anymore.

The main problem for the YaST team is that nobody is noticing in advance when a package configured by YaST changes the location of its configuration files. Simply a new bug is reported to YaST when a YaST module fails because that. This approach would not be a big deal if all that kind of errors are detected by openQA, but we cannot ensure that is the case. Therefore, YaST needs an early defense barrier in order to prevent bug reports from final users as much as possible.

To fix this issue we would need:



The goal is to be able to add unit-test for snapper CLI commands. For example, check that user-given parameters are right, check that correct libsnapper calls are performed (e.g., a call for creating a snapshot would be perfomed), and check that commands returns expected output (e.g., with csv format, etc).

How to do it

To support unit-test we need to prepare the code for that. And we can do it at different layers. Very roughly, we can see these layers in the snapper code:



  • We cant to stay relevant
  • We want to be useful
  • We want to make things simple for our customers

Current status

  • Is YaST relevant yet? Why?
  • Nowadays, what is YaST most useful for?

Team Charter Template

Team Purpose (Mission)

A statement describing the reason that the team was created.

The YaST team was created to develop and maintain YaST2, the installation and configuration tool of openSUSE and the SUSE Linux Enterprise distributions.


A Team Charter Template is proposed here to help YaST team members to define the team chapter. Please, feel free to add/remove/modify the points in this team charter if you consider it.

Why a Team Charter

That is the first question everyone of us make to ourselves. But there are some good reasons to have one:



  • no dasds, bios raids, mds, strays, encryptions, bcaches, lvs

  • disks, multipaths

    • no partitions
    • not in vg, md, multipath, bcache, cset [+ btrfs]
    • not formatted
    • not mounted

Partitioner with multidevice BTRFS

  • Show multidevice BTRFS in the general list of devices.
  • Mount point and label is empty for the devices belonging to a multidevice BTRFS.

New Type column

Columns Type and Fs Type will be merged into a new Type column on steroids:

  • Blk Device without fs:

More Packages With Outdated Version

The following packages can be found in SCC with a very old version.

Yast-team is not the bugowner/maintainer for these packages. Should we bump them?

Package Version Bugowner Maintainer
yast2-rmt 1.2.1 scc_bugs
yast2-samba-provision 1.0.1 jmcdough hhetter123, jmcdough, npower, dmulder, aaptel, scabrero, pauloac, group:factory-maintainers
You can’t perform that action at this time.