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
after quite long playing with achieving layout I decide to write down what I found.
To get nice box centered at middle of screen, but content in box left aligned use
It start with feature to adapt theme and our designed team found some strange alignment that they want to change in dialog layout.
So I start with trivial idea to have something like `Center(VBox(Left(*content)))` This sadly does not work as it in
the end create box over whole place and everything is ugly on left side. which looks strange ( see screenshots in ).
So next attempt with a bit of help is MarginBox. It looks fine and is shrinkable, so even on very small screen in ncurses
looks fine, but in qt it is hard to pick good sizes as with different resolutions it is never on center for all resolutions.
So good to make some spacing, but not to align box.
The proper solution is to use that stretches around that create spacing around box that is proportional and content in Box
then can left alignment with proper position.
Pro tip: If you do not want center but e.g. in one third, it is possible to use Weight to stretch. See documentation at 
There are many ways to teak the installer and people keep asking for more.
We are discussing use cases and ways to improve things on github:
If you have suggestions or more use cases or just want to stay in touch,
feel free to join the discussion.
2021 is here with a lot of interesting news, and YaST development is not
an exception. During the first sprint of the year we have worked on:
- Writing NetworkManager configuration during system installation
- Refining the mechanism to reuse existing EFI partitions
- Using better names to reference devices in the boot loader
- Improving AutoYaST behavior when no product has been specified
- Updating the roles offered by yast2-vm
- Many more small improvements here and there
Check the whole report at:
Ancor González Sosa
YaST Team at SUSE Linux GmbH
Today I opened an issue in yast2-installation for proposing to
(almost) start the installation process in the summary screen.
Benefits? Since the product control file of each product sets
reasonable defaults for most users (correct me if I'm wrong), the
installation steps could be shortened. Users should adjust just the
desired settings, nothing else. So, there is no reason for forcing them
to go through the whole installation options in a specific order
(unless, of course, for those dependent/coupled steps).
What do you think?
PS: I'm not sure if it has been discussed already in the past, but IMHO
it worth it to (re)evaluate it.
I've already mentioned this at some calls before, but this is actually
the right channel for discussing the idea.
I've seen many times before, that there is, for instance, a media layout
error, but we simply report that problem into the log and try to
continue. Usually it's nothing critical in our eyes. As an example,
we've recently seen that someone reported a missing Czech license in
installer. Ladislav found out that the license actually exists, but
wrongly uses "cz" instead of "cs" in its filename. The installer
actually reported a warning into the log. Something like "unknown
So, what is the problem? It could have been spotted 3 months earlier.
Plus it could have been fixed without us debugging the problem.
Proposed solution: In case of Y2DEBUG==1, raise an internal error or
rather show a pop-up error/warning message. This would not influence
common installations, but openQA would catch and record it. With a
little piece of work openQA could even skip it if needed. I would like
to have a separate Y2SOMETHING variable to control the behavior (by
default, X==1 in case of Y2DEBUG==1).
Obviously, this means more work now and from time to time for adding
such warning/error reports one by one. But that IMO pays off mid-to-long
term. At the end we could have more time to fix "our" bugs :)
What do you think?
As a result of small research about the current status of the YaST
Firstboot module, I have created a couple of issues in its Github
repository pointing out what I found wrong and my (sometimes wild)
ideas to fix/improve it.
I used the Github's issues feature to ease the interaction/discussion
since you can add there your thoughts/ideas as a comment. But, of
course, you can just reply to this thread if it is better for you.
So, let me invite you to follow the links you can find in the first
issue and give your feedback to both, commented gotchas and
openSUSE is looking for Google Summer of Code mentors again.
Just saying ;-)
-------- Forwarded Message --------
Subject: openSUSE - Google Summer of Code 2021
Date: Fri, 15 Jan 2021 14:55:59 +0100
From: ddemaio <ddemaio(a)suse.de>
To: opensuse-project(a)opensuse.org <opensuse-project(a)opensuse.org>
Applications for mentor organizations for the 2021 Google Summer of Code
will be from Jan. 29 - Feb. 19. The openSUSE Project has a long history
of participating as a mentor organization.
If you are interested in mentoring for your open source project, please
let me know so I can come up with a list of the people who are interested.
You would need to be committed to actively mentoring a student/s if
openSUSE becomes selected as a mentor organization.This will involve
keeping the student on task, actively communicating and mentoring them
and writing progress reports; I believe there are 2 reports the mentors
must write (mid-term review and final review).
If there are enough interested mentors to proceed with an application,
which I will let you know ASAP, potential mentors would need to update
the git repository (https://github.com/openSUSE/mentoring) for
https://101.opensuse.org, so I can submit the application.
If you have any questions, please let me know.