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 all!
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
autoyast=https://raw.githubusercontent.com/yast/autoyast-profiles-test/mast…
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
autoyast=https://autoyast.github.io/mini/sles15.xml
or
autoyast=https://autoyast.github.io/mini/leap15.xml
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?
--
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 all,
I have improved the Y2Packager::Resolvable call (and the internally used
Pkg.Resolvables call) to allow searching by RPM dependencies (provides, obsoletes,
conflicts, requires, recommends, suggests, supplements, enhances).
Examples:
Just use the dependency name as the additional parameter:
Y2Packager::Resolvable.find(kind: :package, provides: "application()")
This searches for the exact string. Optionally you can use a regular expression,
just add the "_regexp" suffix to the dependency name:
Y2Packager::Resolvable.find(kind: :package, obsoletes_regexp: "^yast2-config-")
The regular expression is a POSIX extended regular expression, not a Ruby
regular expression! The regexp parameter is just passed to the underlying
libzypp/libsolv. The filtering happens directly on the C++ level so it's much faster
than filtering on the Ruby level.
Do not forget to escape regexp metacharacters like []()
# seach for autoyast() supplements
Y2Packager::Resolvable.find(kind: :package, supplements_regexp: "^autoyast\\(.*\\)")
If an invalid regexp is passed then the ArgumentError exception is raised.
You can combine more dependencies like "provides" and "obsoletes" in one call (if
that makes sense). The result is logical AND, all dependencies must match.
To use this new feature you need yast2-pkg-bindings-4.3.0 and yast2-4.3.21
(or newer).
The old Pkg.PkgQueryProvides() call has been marked as obsolete. The enhanced
Pkg.Resolvables() call is more powerful as it covers also the other dependencies than
"Provides" and allows using a regexp.
Enjoy! :)
--
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
As you all know, we recently got to the conclusion of adding a menu bar
to the YaST Partitioner and getting rid of several entries we have in
the left-hand tree. Check
https://github.com/yast/yast-storage-ng/blob/master/doc/partitioner_ui.md#a…
We are in the process of implementing that, but we are not sure how to
represent the screens that are now a misplaced entry in the tree: Device
Graphs, Installation Summary and Settings.
Option 1: as pop-ups (even if they are full-screen pop-ups)
In this option, "Settings" will be likely accessible through the
"System" menu (which we are considering to rename to "Partitioner") and
the other two would live in a "View" menu. See screenshot at
https://github.com/yast/yast-storage-ng/pull/1120
We would consider that the normal view is the one with the devices tree
at the left, the tables of devices at the right and the menu at the top.
The other three views (settings, graph and summary) would be rendered on
top of the normal one (if we use classic pop-ups) or hiding it (if we
use the current approach of full-screen pop-ups). The menu bar would not
be accessible from such views and the user would need to close the
(maybe full-screen) pop-up using an "Ok" button to get back to the
normal view.
In the current Partitioner, double-clicking in a node of the Device
Graph takes you to the entry of such device in the tree. I guess it
would keep doing the same, so it would be an alternative way of closing
the pop-up.
Option 2: as four first-class citizen views
In this option, there would be a "View" menu with four entries: Devices,
Device Graph, Installation Summary and Settings. The "Devices" view
would be equivalent to the normal one in the previous option. All the
others would use the full screen (no left tree) and will still provide
access to the menu bar. They would need no specific button to be closed.
Instead, the user would use "View -> Devices" (or any other view, since
all of them are equally important in this interface).
The main advantage of this option is that we wouldn't need to change how
the current Device Graphs, Summary or Settings screens work. For
example, no need to add a button to save the new settings and close or
another to quit the settings dialog without applying.
Which option do you think would be better?
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
as my today innovation time I spend couple of hours with installing our new server in NUE. For access please see https://wiki.suse.net/index.php/YaST/team-it-infrastructure#Our_Servers ( internal only! ).
Few my notes I observe during it:
1. it uses BMC to initial access to machine. Java applet version with openJDK was disaster, HTML5 version works surprising well.
2. PXE in NUE works quite fine, it just needs tuning of kernel parameter.
3. installation without ssh was not possible. I am not sure what UI is picked, but it does not show anything in console. So I do ssh installation.
4. suggested ssh -X was quite slow. Probably ssh -XYC will be faster, but I do not try it.
5. System is SLE 15 SP2 and I picked system role KVM virtualization host and configuration looks reasonable.
6. partitioning needs tunning. It wants to use just one of SSD, but guided setup with using both disk and LVM create good proposal ( reasonable system and maximum /var/lib/libvirt for images )
7. I keep rest of defaults as it looks reasonable.
So what now? Current there are only my ssh keys, but I already ask infra team to add machine to their salt slaves and apply ssh for yast team members same as we have in prague server. connection via libvirt works well for me. No VM is there yet, but maybe we can migrate our german IBS workers.
Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
if you are interested tomorrow is free ruby virtual conference.
See https://noruko.org/
Some talks can be interesting, maybe mvidner find Sorbet presentation interesting. Matz will talk about ruby 3.0 and more.
Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Although the YaST team is focusing on bugfixing in this summer season,
we still have three interesting features to share with our fellow
chameleons:
- New menu bar widget in libYUI. Check the screenshots in the blog post.
- Configuration of the firewall in AutoYaST moved to the first stage.
- Preliminary support to mark the packages affected by BootHole and show
a warning message if such old packages are going to be installed.
Check the extended versions with links at
https://yast.opensuse.org/blog/2020-08-17/sprint-106
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org