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,
As you may know, we introduced automatic profile validation in AutoYaST for
SLE 15 SP3 and Tumbleweed. When the profile is not correct, AutoYaST complains
at the beginning of the autoinstallation. So, as expected, we are getting
regular bug reports from openQA.
In some cases, the profile is just wrong. However, we have detected several
problems in yast2-schema.
Although you can disable this feature at boot time (setting
YAST_SKIP_XML_VALIDATION to 1), I fear that we are going to get a ton of
errors from our users and customers.
So I was considering whether we should disable this feature by default,
although in that case I would ask openQA to enable it so we can improve yast2-
schema quality.
What is your point of view?
Regards,
Imo
--
Imobach González Sosa
YaST Team at SUSE LLC
https://imobachgs.github.io/
The YaST Team continues focusing on improving both AutoYaST and the
management of storage devices. Let's take a quick glance at some of the
results.
- New YaST test client to check AutoYaST dynamic profiles.
- Improved detection of which YaST package is needed to process each
section of the profile, relying on RPM’s supplement information.
- First steps to annotate the documentation of AutoYaST with better
information about the corresponding version for each feature.
- Final design of the new Partitioner user interface.
- Improved automatic submission of translations to Leap and SLE.
Check the whole report at
https://yast.opensuse.org/blog/2020-09-29/sprint-109
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 I now work on merging various pull requests, it often lives in own forks, where I do not have permissions and I am looking for the easiest way to make them again mergeable and sometimes adapt it to our needs.
what works best for me is e.g. for this pr: https://github.com/yast/yast-ruby-bindings/pull/239
```shell
git checkout master && git pull && git checkout -b my_branch
wget https://github.com/yast/yast-ruby-bindings/pull/239.patch # notice .patch suffix
git am -3 239.patch # and then solve conflicts and branch is ready for new pr
```
Do you know easier way? This way it is for me like good old kernel mailing lists where you get set of patches that you can apply.
Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
after our final drop of old testsuite nothing prevent to merge [1]. So now we will have in y2log also method names, so I hope easier grepping.
Example how it changed:
- 2018-05-28 13:10:29 <1> linux-vvcf.privatesite(12728) [Ruby] y2storage/dump_manager.rb:230 Devicegraph dump directory: /var/log/YaST2/storage
- 2018-05-28 13:10:29 <1> linux-vvcf.privatesite(12728) [Ruby] y2storage/dump_manager.rb:264 Dumping Devicegraph to 01-probed
+ 2018-05-28 13:25:35 <1> linux-vvcf.privatesite(20263) [Ruby] y2storage/dump_manager.rb(lazy_init):230 Devicegraph dump directory: /var/log/YaST2/storage
+ 2018-05-28 13:25:35 <1> linux-vvcf.privatesite(20263) [Ruby] y2storage/dump_manager.rb(dump_internal):264 Dumping Devicegraph to 01-probed
Of course we are not necessary limited to that change and we can change more as we need, so I welcome any feedback. One idea I have is to replace that "Ruby" component by real components e.g. by matching component and gettext domain. so in this case it can be "storage".
Josef
[1] https://github.com/yast/yast-ruby-bindings/pull/216
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org