I'm implementing some new AutoYaST feature and I found out that it's not easy
to test the AutoYaST functionality.
1. Even for testing a trivial scenario you have to write your own XML file.
If you do not have much experience with AutoYaST you have to read the
documentation, search the internet, etc... Cloning your current system helps
a bit but usually the cloned profile contains too many options so you still need
to polish it a bit...
2. When you have your profile ready you have to host it at some HTTP/FTP/NFS/...
server so AutoYaST can use it for installation. I usually run simple
"ruby -run -ehttpd" command to have a web server quickly, but that's quite
tricky for people not familiar with Ruby.
My idea is to have some repository with example XML profiles which would be
publicly available and ready for instant use. We already have some XML files in the
autoyast-profiles-test Git repository but writing something like
on boot command line is a real pain. We could use some URL shortening service
but I do not like that much. Shortened URLs do not look nice and it's not
obvious where they point to (security). I'd like to have some nice URLs...
So my proposal is to use the GitHub pages for building an AutoYaST profile
repository. Then you could use
for testing a minimal SLES/Leap profile.
Actually these URLs already work! :-) You can give it a try. Most likely you will
need additional "netsetup=dhcp" boot option for configuring network.
The profiles would be well described (what they do) and well commented (so the users
can easily adapt them to their needs).
The profiles could be automatically validated (via Travis) and it would be nice
to use them also in openQA tests to be sure they really work.
We could also link this repository from the official SUSE documentation.
The proof of concept is available at https://autoyast.github.io, please check it.
It is still just a concept for getting early feedback, there is a lot of work to do.
See the README file in https://github.com/autoyast/autoyast.github.io
What do you think about it?
SUSE LINUX, s.r.o.
18600 Praha 8
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
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.