Now that Hack Week 20 is over, the YaST team wants to share the projects they
were working on. It covers a wide range of topics: Sorbet, gfxboot2, QDirStat,
WebAssembly, a new configuration management tool (UCMT), Yast::Rake
improvements... and even horses GPS tracking!
If you are interested, please, have a look at https://yast.opensuse.org/blog/
Imobach González Sosa
YaST Team at SUSE LLC
I created a SLE-15-SP3 branch in all[*] YaST packages. The "master" branch is now
open for SLE-15-SP4/Tumbleweed changes!
The "rake osc:sr" in the SP3 branch will send a maintenance update.
If you need to submit a P1 fix to SP3:GA then use these commands:
# send the package to the Devel:YaST:SLE-15-SP3 project
# manually create the SR to SP3:GA
osc -A https://api.suse.de sr Devel:YaST:SLE-15-SP3 <package> SUSE:SLE-15-SP3:GA
NOTE 1: The branch has been created from the current "master", if some latest
changes are not accepted to SP3 we have to manually rollback the branch to
the latest accepted commit.
NOTE 2: "master" is SLE-15-SP4/Tumbleweed now, do not forget to bump
the version to 4.4.0 when adding SP4/TW only changes.
If you find any issues just ping me!
[*] Except of these packages:
Not maintained at github.com/yast:
We do not have any branches here:
This seems to be dropped:
SUSE LINUX, s.r.o.
18600 Praha 8
during hackweek I work on project ucmt . In this email I do not want to talk about project, but about experience with technologies I use during this work.
I use basically 4 libs/tools - ansible, salt, rubygem cheetah and rubygem optimist.
I use ansible for discovery and also as one of backend for write. For discovery it works nice and works even without root permissions, just with less data.
For writting it also quite good, but I feel more comfortable with salt.
I use salt for backend only. Discovery has problem that it is very slow and require always root. But write is quite plesant experience and I like its output of apply and dry run more then in ansible.
Well, I am co-author of gem, so it is quite familiar to me. What I really enjoy is error reporting which really helps with prototyping as I quickly get info if some command I use failed for whatever reason. And redirecting stdout works well with salt, so output is still colored.
Really nice gem for CLI. It is easy to use and still quite powerful. What is maybe not everyone taste is how much it forces conventions like like if you have :no_root as option, then in CLI it is --no-root. But it generates help, generates short options, support subcommands and so on, so in general I can quickly make quite nice API.
during HackWeek I improved a bit the Rake tasks we use in YaST, here is a short
summary of the changes.
Added osc:config Task
The packaging configuration might be complex and it might be quite difficult to find
where the package will be submitted with the osc:sr task in the end.
This task prints the summary of the packaging configuration:
Package directory: package
OBS instance: https://api.opensuse.org/
OBS project: devel:languages:ruby:extensions
OBS package name: rubygem-packaging_rake_tasks
OBS build target: openSUSE_Tumbleweed
OBS submit target: openSUSE:Factory
It also honors the YAST_SUBMIT variable:
YAST_SUBMIT=sle15sp1 rake osc:config
Package directory: package
OBS instance: https://api.suse.de/
OBS project: Devel:YaST:SLE-15-SP1
OBS package name: yast2
OBS build target: SUSE_SLE-15-SP1_Update
OBS submit target: SUSE:SLE-15-SP1:Update
Updated check:committed Task
The osc:build or osc:sr tasks check whether all changes have been committed to Git to
avoid missing files and changes. That's good. But if you are testing a fix it is
quite annoying that you have to commit every single change before running a testing
rake osc:build CHECK_MODIFIED=0
Note: We need to keep the check for *new* files because "rake package" archives only
the files known to Git, so the package build would miss them later.
Added run:container[client] Task
This is similar to the "run[client]" task, but it runs the client in a Docker
container. Because the Docker container environment is quite limited (no systemd, no
boot loader, no HW access) some modules will not work properly. But it works for some
modules/clients (like "repositories").
It uses the same container as specified in the GitHub Actions, see the "Options"
Added GitHub Action Tasks
These tasks allow running the GitHub Actions locally
actions:list - print the defined GitHub Action jobs
actions:details - print the details of the defined GitHub Action jobs
actions:run[job] - run the specified GitHub Action job locally,
if "job" is not specified then it runs all jobs
You can run the same[*] jobs as the GitHub Actions do on the server!
There are several options you can use in the "actions:run" and
KEEP_CONTAINER=1 - keeps the container running after finishing the job/client,
that might be useful for debugging or testing if something fails.
It prints the instructions how to connect to the container and remove it.
Do not forget to remove the container manually at the end otherwise it it will
keep running and consuming some (tiny) system resources!
DOCKER_IMAGE=<image> - it might be useful to use a different Docker image
than the one which is specified in the GitHub Actions. Of course, when using
a different image the result might be different than in real GitHub Actions.
But that might be useful in some cases, see the example below.
rake actions:run[Checks] KEEP_CONTAINER=1
# use the Leap 15.3 based Docker image if the latest TW image with glibc-2.33
# does not work with older Docker in your system
See the details in these pull requests:
[*] The Docker containers use the host kernel and depend on the Docker version
installed. So it is not 100% the same, but very very close...
SUSE LINUX, s.r.o.
18600 Praha 8
I have created a sample Yast Client with multiple Browse Buttons.
I have assigned a keyboard shortcut to the buttons,
but for one of the Browse button, the shortcut key is not getting assigned and on checking the logs :
2021-03-26 12:31:25 <0> blr8-117-110(12459) [ui-shortcuts] YShortcutManager.cc(checkShortcuts):119 Shortcut conflict: 'E' used for YPushButton "Browse" at 0x7f407c37aff0
2021-03-26 12:31:25 <0> blr8-117-110(12459) [ui-shortcuts] YShortcutManager.cc(checkShortcuts):119 Shortcut conflict: 'E' used for YQWizardButton "Release Notes" at 0x7f407c110c60
2021-03-26 12:31:25 <0> blr8-117-110(12459) [ui-shortcuts] YShortcutManager.cc(resolveAllConflicts):163 Resolving shortcut conflicts
2021-03-26 12:31:25 <0> blr8-117-110(12459) [ui-shortcuts] YShortcutManager.cc(resolveConflict):282 Keeping preferred shortcut 'E' for YQWizardButton "Release Notes" at 0x7f407c110c60
2021-03-26 12:31:25 <2> blr8-117-110(12459) [ui-shortcuts] YShortcutManager.cc(resolveConflict):292 Couldn't resolve shortcut conflict for YPushButton "Browse" at 0x7f407c37aff0 - assigning no shortcut
As we can see that there is a conflict for one of the shortcut 'E' which I assigned to one of the Browse Button but it is already assigned to "Release Notes".
On checking the widget tree there is Release Notes Button but it is not visible in UI :
2021-03-26 12:37:44 <1> blr8-117-110(12573) [ui] YWidget.cc(dumpWidget):709 Widget tree:
YQWizardButton "Release Notes" at 0x7f32bc1fbfa0 (widgetRep: 0x7f32bc142000)
Is there any way to remove the "Release Notes" from the Widget tree?
Sample Code : https://gist.github.com/gauti200/577b02777f84f5e064d791808f8e0b68
I am attaching the y2log after running "Y2DEBUG=1 yast2 sampleClient.rb" and the widget tree for the client.
it is a bit of follow-up of ancor playing with tk and its ruby DSL. I write idea that I like for UI design to use WYSIWYG instead of programmer created UI from programming language.
My previous experience was just with visual basic ( 20 years ago ) and netbeans one for swing ( 12 years ago ).
My quick search shows glade, qt designer and camelot.
Glade is for gtk and as we do not support now gtk backend I do not explore it too much. Camelot on other hand looks quite focused on database representation so also not much for us.
So I explore and play a bit with qt designer.
At first I was quite surprised that I do not find qt designer and it looks like it is now only part of qt creator ( qt IDE ), at least I do not find own rpm or how to start it.
So I create testing project and start. The output is ui file which is XML based, so quite easy to parse and hard to read for human. But looks quite promising for us to parse it and e.g. try to show ncurse equivalent.
Widgets in XML has its id, so it should be easy to connect widgets with actions in programming language as for us the direct connect in designer does not make much sense and I do not like it much. I think that GUI layout should be in WYSIWYG, but connection to data model should be in code.
I try layouts available and I am not sure if it is limitation of designer or qt, but all layouts are quite trivial and nothing like Spring Layout in Netbeans which allows to specify constrains on widgets like align left side to center of this widget and have right side align with left of different widget. Situation with layouts was even worse for me and I failed to create design that works well with resizing of window ( maybe issue was that I use MainDialog as base? ). Probably issue on my side, but it says something about usability of designer.
Nice feature is also builtin tooltips and translations, but I worry how easy will be to use gettext for translations instead of qt built-in localization.
There are some widgets that are currently not supported by libyui. What I like in designer is clear separation of input and display widgets. So it is clear which ones are for displaying info and which should be used for getting data.
I try to design more complex menu with submenus and it works nicely in designer.
Overall qt designer for me is comparable to visual basic experience 20 years ago and still not so nice experience as netbeans designer 12 years ago. So if you know better WYSIWYG designer that I overlook, please write it. But still it is better then write own one, so maybe in future I will try to write trivial ui file displayer in libyui bindings or directly in yast with ycp-ui-bindings.
As everyone in this list likely know, the two "official" channels used
by the YaST Team at SUSE to track changes requested to YaST are:
- https://bugzilla.suse.com (also available as
- https://jira.suse.com (also open for openSUSE feature requests)
We have well-established mechanisms to process the constant flow of
Bugzilla and Jira entries and to track them over time.
But since we are getting more and more request via Github issues, we
agreed to establish some procedure to try to ensure requests via Github
don't get overlooked and forgotten.
Today we decided we will create a few labels in all repositories under
the YaST organization at Github (we got a script to do perform such
batch creation in all repos) and we will use them to know if a given
issue needs attention.
So this mail is a RFC for the initial set of labels. Please feel free to
propose any enhancement, specially to the names of the labels that I
just made up.
We kind of agreed to start with these four:
1) Label "feedback"
To mark issues that are used to discuss future enhancements or
relatively general topics. Examples:
https://github.com/yast/yast-installation/issues/903 and all their
2) Label "tracked"
To mark bug reports or feature requests that are already processed by
someone in the team and have a counterpart in the official Bugzilla,
Jira or in the internal Trello board of the YaST Team. That would be the
equivalent of moving a bugzilla bug from
yast2-maintaners to yast-internal.
3) Label "other-maintainer"
To mark issues associated to YaST repositories and/or functionalities
that are not maintained by the core YaST Team. Examples:
4) Label "needinfo"
Similar to the corresponding flag in bugzilla. The main difference is
that the YaST Team will need to take full care of the label (eg.
removing it if the info was already provided) since not everyone will
have the rights to add/remove labels.
As said, feel free to propose any change (including names). We plan to
mass-create the tags tomorrow.
Ancor González Sosa
YaST Team at SUSE Software Solutions