In the context of revamping yast2-users, I spent some days looking
for an alternative layout that could help to improve the current UI by
reducing the number of tabs and grouping form fields to make better use
of available space.
However, due to our resolution constraints (UI must fit well in an
80x24 terminal) and some UI library limitations, looks like there is
not too much room for big changes and our best bet is to keep the
layout almost as it is, just making some necessary adjustments.
Summarizing them a lot, those changes will consist of adding a top menu
bar for making easier the user navigation, moving all settings to the
same dialog, improving filters by using a popup, making small changes
in forms, and adding some summary views.
Of course, nothing is written in stone and it would be nice to know
your feedback and/or ideas too. So, please, keep reading the following
links if you are interested and tell us what do you think. Is there
anything we overlooked? Some other ideas we should evaluate?
Remember that you can reach us by email, on IRC, or even by directly
leaving a comment in those Github issues.
 "Revamping yast2-users" mailing list thread -
 "UI library limitations"
 "Revamping yast2-users UI: an initial proposal"
YaST Team at SUSE LINUX GmbH
NameScheme=by-label on installer cmdline has had no effect I have observed for a
lot longer than I can remember, several years at least, continuing in 15.3 build
117.13. Has it been removed and the linuxrc page need matching update? Is this a
broken installer option? Am I not understanding why it's listed on the linuxrc
page? Shouldn't it prevent me from needing to change default mount by in the
Evolution as taught in public schools, like religion,
is based on faith, not on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
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
TLDR: For next Leap 15.4/SLE 15-SP4 we need to bump all package versions to 4.4.x.
Unfortunately we forgot to do that in 15.3/SP3 so not all YaST packages have version
4.3.x there. :-( So to avoid this situation again we did the version bump right now.
**All YaST packages have been updated to 4.4.0 unless they already use
a 4.4.x version.**
The skelcd-control-* and system-role-* packages use the product version so I updated
them to version 15.4.0.
skelcd-control-suse-manager-proxy, skelcd-control-suse-manager-server - these
packages use the SUSE Manager version
yast-rake - this is a Ruby gem, not an YaST module, it uses usual semantic versioning
patterns-yast-20201210 - it uses date as the version
These packages do not use 4.x version so I kept them untouched,
they are maintained by other teams and I do not know their versioning schema:
If you do not have any particular reason for that versioning it would be
nice if you unified the package versions to 4.4.x. Then next time the version bump
would happen globally with the other YaST packages.
If you have any questions, just ping me.
SUSE LINUX, s.r.o.
18600 Praha 8
After Hack Week and some irregular sprints, the YaST Team is ready to
restore the traditional cadence of one report every two weeks. Let's
take a look to the topics we have been working lately.
- Reduction of the memory consumption during installation.
- New option to enable installation in systems with small RAM.
- Improvements in the NetworkManager support.
- Polishing of the upcoming releases, AutoYaST and hardware enablement.
- A new extend parameter in linuxrc to help openQA.
- More consistent and polished LibYUI development.
- Research and open discussion about the current state and future of:
* YaST Firstboot,
* YaST Users,
* the installation workflow.
Check the whole report at:
Ancor González Sosa
YaST Team at SUSE Linux GmbH
For more than a month I'm having a crash problem with the kernel 5.11. It boots up, but when loadaded the display manager (tried SDDM and GDM), the system freezes. It occurs in a Dell Inspiron laptop with AMD GPU Radeon R7.
Well, I finally found a solution in the Bugzilla of kernel [https://bugzilla.kernel.org/show_bug.cgi?id=212133].
The solution is add the 'modprobe.blacklist=amdgpu 3' parameter to the GRUB kernel line. It works! The only problem is having to start the graphical server manually.
I opened this thread to make developers aware of the problem, if they are not already.
I am hopeful for a better and definitive solution soon.
Recently, we got a bug report about YaST crashing when the BOOTPROTO value
in an ifcfg-* file is invalid. How to handle this situation?
1) We could detect that problem and inform the user through the Yast::Report
module but, to be honest, I do not like having calls to Yast::Report.Error all
over the place (we are somehow mixing business and UI logic).
2) We could raise an exception and report it to the user. But 1) it stops the
workflow, and 2) we will raise an exception for each error we find. Moreover,
sometimes you can recover from the error easily (but you might want to tell
the user about it).
So I thought it would be nice to have something similar to the AutoinstIssues
mechanism. Basically, you register any error you find and, at the end of
the process, you report all the problems to the user at a single point.
I have written some details and many open questions in a pull request. I
think the error classes (we might need a better name) should live in
yast2.rpm, but for the discussion, let's keep everything in the same
Anyone interested, please, have a look at the pull request and add your
thoughts about it.
Imobach González Sosa
YaST Team at SUSE LLC
As you probably already know, in the YaST team we sometimes dedicate
part of our human resources to improve some key modules. For example,
yast-storage was rewritten from scratch as yast-storage-ng. Other
examples are yast-network and autoYaST, which were heavily refactored.
That effort on improving the code base has allowed us to prepare the
field in order to bring new great features. And of course, as result, we
have a better designed code, with good unit tests coverage.
Now we are focusing on yast-users. This module takes care of managing
users, not only local ones but also NIS, LDAP, Samba, Kerberos, etc. And
we want to revamp it. As part of this work we would like to redesign its
UI completely, and integrate it with some functionalities like sudo. We
are now in a research phase, where we are trying to understand all the
supported use-cases and how the module integrates with other modules
like yast-samba-server or yast-auth-server. And of course, we would like
to hearing from you too. So, please, tell us what use-cases you want to
see in the new yast-users. Is there anything that you miss now? What
use-cases would you like to keep? We would be very appreciated with your
You can tell us your suggestions by email, on IRC or even by opening an
issue in this repo . Whatever better fits to you.
Thanks a lot!
The YaST Team
José Iván López González
YaST Team at SUSE LINUX GmbH