Hi all,
some time ago we discussed where and how we should share
"Tips&Tricks" for YaST users and developers.
IIRC there was no clear conclusion so I decided to start
a wiki [1] to collect all our tricks we know or use.
For now it's just a place for dumping your ideas, links, short
howtos, etc... When we collect enough data we can probably
split it to several categories or move it somewhere else.
We just need the data first.
I have added there some my tricks from my personal "knowledgebase"
file. If you have better tricks or find something wrong simply
change it, it's a wiki ;-)
Ladislav
[1] https://github.com/yast/yast.github.io/wiki/YaST-Tips-and-Tricks
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
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
Hi there!
In the context of revamping yast2-users[1], 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[2], 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[3].
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.
Thanks!
[1] "Revamping yast2-users" mailing list thread -
https://lists.opensuse.org/archives/list/yast-devel@lists.opensuse.org/thre…
[2] "UI library limitations"
https://github.com/yast/yast-users-ng/issues/8
[3] "Revamping yast2-users UI: an initial proposal"
https://github.com/yast/yast-users-ng/issues/6
--
David Díaz
YaST Team at SUSE LINUX GmbH
IRC: dgdavid
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
expert partitioner?
--
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 know there is already a #yast channel at libera. But so far I have
never seen more than 5-8 people there.
Now it seems it's kind of official that most openSUSE channels are being
moved.
What should we do?
Cheers.
-------- Forwarded Message --------
Subject: Moving from Freenode to Libera.Chat
Date: Thu, 27 May 2021 12:04:51 +0200 (CEST)
From: Gerald Pfeifer <gp(a)suse.com>
To: opensuse-project(a)opensuse.org, factory(a)lists.opensuse.org
Hi everyone,
as some of you noticed, lately there've been challenges around Freenode,
the IRC network that has been home to a number of openSUSE channels for
years.
See, for example,
https://arstechnica.com/gadgets/2021/05/freenode-irc-has-been-taken-over-by…https://news.itsfoss.com/freenode-controversy/
Approached by several of you we discussed this with those, the board,
and the weekly release meeting. There is consensus to move our channels
to Libera.Chat ( https://libera.chat ), a new network many other
projects are migrating to as well.
With help from Antonio and Sasi I already registered the openSUSE
project with Libera.Chat (which by itself is not a move yet) and Marcus
R. and others are ready to execute the move.
The plan of record is to move quickly. If you have any concerns or
questions, please advise as soon as possible. Likewise if you support.
Thanks,
Gerald
PS: https://code.opensuse.org/board/tickets/issue/4 publicly tracks this
matter on the openSUSE side; feel free to chime in there.
--
Dr. Gerald Pfeifer <gp(a)suse.com>, CTO @SUSE + chair @openSUSE
Hi all,
I (with Schubi's help) have added a new logging facility into the YaST installer. It
dumps some data in YAML format into the /var/log/YaST2/installation_info/ directory.
Currently YaST writes the new logs when starting the installation and when
that "No base product found" error happens (that was actually the original reason
for creating this logging functionality).
But you can easily create a dump whenever you need, usually when something goes wrong:
require "installation/installation_info"
::Installation::InstallationInfo.instance.write(
"Setting foo option failed",
additional_info: "File foo does not exist"
)
The default dump contains some basic data (repositories, products....) but you can
easily extend the dumped data by calling:
::Installation::InstallationInfo.instance.add_callback("my_module") do
{
"foo" => foo.value,
"bar" => bar.value
}
end
The data will be saved into the YAML file as key "my_module" with the data returned
by the block. The key should be unique to avoid collisions, a good idea is to use the
package name.
Note: avoid saving some sensitive private data like passwords or registration keys.
The dump files are also archived by the "save_y2logs" script and they might be
attached to bugzilla or sent my email...
Why using blocks? The block behaves like a callback, the advantage is that it is
evaluated at the time when writing the dump file. That ensures you always write the
current. Reading the y2log is difficult if user changes same values, goes
back and forth in the workflow..., having the current dump helps a lot in that cases.
That is also important for product selection because the libzypp products might
change whenever a repository is added or modified, the dependency solver might change
the selected products, etc...
See installation/installation_info.rb for more details:
https://github.com/yast/yast-yast2/blob/e9b29cf6ac80a2ef9148021c516f4e58e09…
Enjoy! :)
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
## Short version or Reminder
Any subclass that overrides 'eql?' should also override 'hash'
appropriately.
## Long version
Probably all of us will agree that equality is very important... but it
will vary depending on what we are trying to compare.
In ruby we have different methods to compare objects... (==, ===, eql?,
equal?), and it is very important to know their differences.
The '==' is the 'daily used one' and in descendant subclasses.
https://ruby-doc.org/core-2.5.3/BasicObject.html#method-i-3D-3D
As described in the documentation subclasses, For objects of class
Object, 'eql?' is synonymous with '==' and subclasses normally
continue this tradition by aliasing 'eql?' to the overriden '==' method.
We have done this in different places in YaST (just look for
'alias_method :eql?, :==').
But in most of the cases we have omitted the 'hash' method override
which could be a problem in case we use Hashes or Arrays.
And this is basically what has happened in a recent bug where the user
had 16 interfaces configured and adding one more deleted
all his routes. (What? 16 is fine but 17 is not?)
https://ruby-doc.org/core-2.7.0/Array.html#method-i-2Dhttps://github.com/ruby/ruby/blob/master/array.c
Basically the 'difference' or '-' methods use 'eql?' for comparing
elements when the array is smaller than 17 elements and the␣
'hash' when it is bigger.
Some Links:
- Recent bug https://bugzilla.suse.com/show_bug.cgi?id=1186082
-
https://github.com/yast/yast-storage-ng/pull/491/commits/1144a6ee3d88154f92…
- https://stevenharman.net/well-behaved-ruby-object-equality
--
Knut Alejandro Anderssen González
YaST Team at SUSE Linux GmbH
Hi!
In Tumbleweed they want to change the default permissions of the
/usr/share/icons/ directory. That makes troubles with YaST
packages as we also own that directory, this creates a conflict [1].
One possibility is to change the %{yast_icondir} macro to point to
/usr/share/icons/hicolor, see [2]. All YaST packages install the icons
to the "hicolor" subdirectory so this is a pretty safe change.
The advantage is that this fix is trivial (only one package affected),
the disadvantage is that the problem is just moved one level down,
in the future the same problem might appear with the "hicolor" subdirectory.
But that "hicolor" is owned by more than 270 packages (excluding YaST) so they
will not hurry with that change...
Dirk suggested a better solution, fix the spec files of the YaST packages
so the %{yast_icondir} is not owned, see example [3].
This example also fixes the same problem with the sysconfig fillup
templates.
The advantage is that this is a future proof change, the disadvantage is
that we will need to update many spec files. My quick grep reports more
than 70 spec files...
So the question is which way to go? The simple way or the more complex
one that might on the other hand save some time in the future?
[1] https://bugzilla.suse.com/show_bug.cgi?id=1186066
[2] https://github.com/yast/yast-devtools/pull/161
[3] https://github.com/yast/yast-bootloader/pull/642
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
While polishing the final details in the upcoming Leap 15.3, the YaST
team is also working in some interesting and varied topics like:
- Improvements in the AutoYaST ask-list functionality
- Better handling of path names in right-to-left languages
- Progress in the refactoring of YaST Users
- Possibility of installing with neither NetworkManager or wicked
See the full report at
https://yast.opensuse.org/blog/2021-05-17/sprint-123
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH