April 2020 - YaST Development - openSUSE Mailing Lists

[yast-devel] Pending Pull Requests
by yast-ci＠opensuse.org 20 Apr '20

20 Apr '20

This email is automatic generated from yast CI node. It lists of pull requests that have no activity more then three working days. If your module is listed, please check all pull request, why they are not merged yet. Pending requests in repository yast-apparmor: - Port to rake (310 days) https://github.com/yast/yast-apparmor/pull/40 Pending requests in repository yast-bootloader: - Fix resume with uuid partition (277 days) https://github.com/yast/yast-bootloader/pull/564 Pending requests in repository yast-core: - Fixes for gensalt handling with libxcrypt. (52 days) https://github.com/yast/yast-core/pull/144 Pending requests in repository yast-country: - Port to rake (277 days) https://github.com/yast/yast-country/pull/217 Pending requests in repository yast-devtools: - Y2logs analyzer (54 days) https://github.com/yast/yast-devtools/pull/149 - Supplement changes from YCC (82 days) https://github.com/yast/yast-devtools/pull/148 - Move desktop files (315 days) https://github.com/yast/yast-devtools/pull/143 Pending requests in repository yast-installation: - Stop plymouth splash to avoid serial terminal splutter. (38 days) https://github.com/yast/yast-installation/pull/841 - Demo: eager mode of zombie-killer 0.5 (528 days) https://github.com/yast/yast-installation/pull/761 Pending requests in repository yast-network: - network-ng: test cases document (draft) (150 days) https://github.com/yast/yast-network/pull/947 - add initial test cases document (276 days) https://github.com/yast/yast-network/pull/853 Pending requests in repository yast-nis-client: - fix build requires (41 days) https://github.com/yast/yast-nis-client/pull/47 Pending requests in repository yast-online-update-configuration: - drop old testsuite and convert to rake (24 days) https://github.com/yast/yast-online-update-configuration/pull/24 Pending requests in repository yast-packager: - Include some hints in the "Priority" label (bsc#1154693) (19 days) https://github.com/yast/yast-packager/pull/482 Pending requests in repository yast-pkg-bindings: - drop old empty testsuite (24 days) https://github.com/yast/yast-pkg-bindings/pull/127 Pending requests in repository yast-registration: - [SP3] Fix misleading default_skipping_text (BSC#1167795) (17 days) https://github.com/yast/yast-registration/pull/488 Pending requests in repository yast-sound: - drop old testsuite without replacement (24 days) https://github.com/yast/yast-sound/pull/36 Pending requests in repository yast-squid: - packaging: remove SuSEfirewall2 artifacts (268 days) https://github.com/yast/yast-squid/pull/30 Pending requests in repository yast-sudo: - WIP: Add a CFA model for handling the sudoers file (111 days) https://github.com/yast/yast-sudo/pull/12 Pending requests in repository yast-sysconfig: - Drop old testsuite (23 days) https://github.com/yast/yast-sysconfig/pull/30 Pending requests in repository yast-users: - Improve readme (74 days) https://github.com/yast/yast-users/pull/224 - Move back the UMASK default value to /etc/login.defs (bsc#1099153) (655 days) https://github.com/yast/yast-users/pull/161 Pending requests in repository yast-yast2: - Change the way groups are defined (314 days) https://github.com/yast/yast-yast2/pull/936 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (445 days) https://github.com/yast/yast-yast2/pull/894 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (445 days) https://github.com/yast/yast-yast2/pull/893 - [WIP] Firewalld fixes for the new UI (593 days) https://github.com/yast/yast-yast2/pull/813 - [WIP] Drop SuSEfirewall2 completely (578 days) https://github.com/yast/yast-yast2/pull/806 ERROR: API query limit exceeded -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

Re: [yast-devel] The (near) future of AutoYaST
by Lukas Ocilka 17 Apr '20

17 Apr '20

On 4/17/20 10:05 AM, Bernd Ritter wrote: > Hi there, > > thanks something I can second. I've had some runs to get to use AutoYaST > but if I remember correctly I was overwhelmed but the amount of XML that > is necessary to make a plain install. Yes, you have to write quite deep-structured XML file in order to define anything. It's basically because of two things 1. YaST in general uses a very special XML (Josef currently works on a project to simplify that if possible) 2. YaST has too many options to use. Of course, you can usually omit almost everything and use the defaults BTW, the really minimal AutoYaST profile contains just the root user/password. This is the only thing we can't guess (use the defaults). > It would be perfect to have a default installation that represents about > the experience when installation through the graphical installer. It must be already two years since I was trying to somehow push for a simple plain file describing the expected setup. Markdown, YAML, JSON ... anything like that could be used. There wasn't a need for that so far. What would be your use case? PLS share some info :) > Yet the GUI has always been faster than to get into AutoYaST and make a > working config file. Looks like we've failed to educate our users, there are really simple ways how to make it work with some tools we provide with AutoYaST. Thx Lukas -- Lukas Ocilka, Systems Management Team Leader & YaST Product Owner SLE Department, SUSE Linux 🌲 Please consider the environment before printing this e-mail ☂ Handle with care - Your reply can be stored in the cloud 😱 Pie-chart is just a representation of randomly chosen data ⚠ IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please, notify the sender immediately and do not disclose the contents to anyone or make copies of thereof. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

5 5

Re: [yast-devel] The (near) future of AutoYaST
by Lukas Ocilka 17 Apr '20

17 Apr '20

On 4/17/20 2:16 PM, josef Reidinger wrote: >> BTW, the really minimal AutoYaST profile contains just the root >> user/password. This is the only thing we can't guess (use the defaults). > > not needed, you can specify it on cmdline - https://en.opensuse.org/SDB:Linuxrc key RootPassword Ah, I forgot about it. Which actually shows how simple is to start with AY and how we fail to sell that :) Anyway, the major thingy I wanted to say is that AY really needs just a little information to start with and then it can propose anything using defaults and/or the currently found hardware. -- Lukas Ocilka, Systems Management Team Leader & YaST Product Owner SLE Department, SUSE Linux 🌲 Please consider the environment before printing this e-mail ☂ Handle with care - Your reply can be stored in the cloud 😱 Pie-chart is just a representation of randomly chosen data ⚠ IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please, notify the sender immediately and do not disclose the contents to anyone or make copies of thereof. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

[yast-devel] (Un)used YaST Modules
by Ladislav Slezak 17 Apr '20

17 Apr '20

Hi all, As we do not have any YaST usage statistics I wrote a simple script which extracts the number of fixed bugs and implemented features in each YaST package. See the results in https://gist.github.com/lslezak/ed9d54b91dc3cdec865ce289d01ac0c2 TL;DR it seems that there is some correlation between the number of implemented features and the number of fixed bugs. ;-) -- 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

1 0

[yast-devel] Installation without recommends resp excludedocs?
by Ludwig Nussel 17 Apr '20

17 Apr '20

Hi, Does YaST already support installation without Recommends resp exluding Documentation? Can system roles switch that on and off? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 2

Re: [opensuse-factory] Re: [yast-devel] The (near) future of AutoYaST
by Imobach González Sosa 17 Apr '20

17 Apr '20

El vie, 17-04-2020 a las 10:34 +0200, aplanas escribió: > On 2020-04-17 09:51, Imobach González Sosa wrote: > > El vie, 17-04-2020 a las 09:28 +0200, Rodion Iafarov escribió: > > > Hi Imo, > > > As for the future, I have 2 ideas in mind. As yomi is out there > > > (https://github.com/openSUSE/yomi), maybe we should look into > > > developing > > > that solution further to replace autoyast. > > > > Sure, that's what I would expect to happen in the future. But as > > AutoYaST relies in YaST (and its proposals during installation), > > there > > might be some valid uses cases for AutoYaST even in the future. > > That is true. I want to comment random ideas here. > > Most of the complains about AutoYaST in relation with the management > of > the XML profile. Those are resolved in Yomi indirectly by having a > template engine. This engine is part of Salt (sort of), and can be > used > for the states but also for the pillars (that is the equivalent of > the > XML profile). So I wonder if adding ERB templates in the profile and > a > way to access to the public API of YaST can help here. That's interesting. Actually, there is an ongoing discussion about our XML parser[1][2]. I have been thinking even about some features that our documentation team uses (like conditional rendering depending on the attribute values). > Another comment is that Yomi have a very early prototype that > translate > the XML profile into the YAML pillar > (https://github.com/openSUSE/yomi/blob/master/autoyast2yomi). There > are > clear limitations, basically because YaST is doing a *lot* more > things. I sounds interesting, I will have a look. > One last comment, and call me crazy : D, is that lately I am > thinking > more about the ownership of Yomi as an openSUSE project. With YaST > supporting Salt formulas and AutoYaST integration with Salt, I am > wondering if the natural living place of Yomi is as a YaST > subproject. > Like a SaltYaST, or AutoYaST-Salt or something. Well, I am not sure. At this point, I consider them as separate projects (using different approaches, constraints, etc.) but I see a lot of space for collaborating and sharing ideas. Thanks a lot for your feedback, Alberto! Regards, Imo [1] https://lists.opensuse.org/yast-devel/2020-03/msg00036.html [2] https://lists.opensuse.org/yast-devel/2020-04/msg00002.html -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/

1 0

[yast-devel] The (near) future of AutoYaST
by Imobach González Sosa 17 Apr '20

17 Apr '20

Hi all, After rewriting our storage layer and, partially, our network stack, the YaST team is looking now to AutoYaST, which is showing its age. Just in case someone does not know, AutoYaST is a software component that, using an XML based description, orchestrates YaST modules to install/upgrade and configure the system in an unattended way. You might want to check the docs[1][2] for more information. We have started started to analyze and build a list of the things we would like to address, but we would love to hear your opinion. Do you have some use case you would like to see supported? Which problems have you faced when using AutoYaST? Which features do you miss? Do you have a different vision of what AutoYaST should be (we can learn from those opinions too)? Any idea/comment is welcome. Thanks a lot in advance! Regards, Imo [1] https://documentation.suse.com/sles/15-SP1/html/SLES-all/book-autoyast.html [2] https://doc.opensuse.org/projects/autoyast/ -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/

3 3

[yast-devel] SLE-15-SP2 branching
by David Díaz 16 Apr '20

16 Apr '20

Hi there! Is there any plan for starting the SLE-15-SP2 branching? Who? When? BTW, that's comes to my mind that Iván started some time ago (during HackWeek 18?) an script[2] to ease the version bumping of YaST modules. Unfortunately, it still as WIP/PoC. Regards. [1] https://github.com/joseivanlopez/yast-dev -- David Díaz González 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

3 4

[yast-devel] Pending Pull Requests
by yast-ci＠opensuse.org 13 Apr '20

13 Apr '20

This email is automatic generated from yast CI node. It lists of pull requests that have no activity more then three working days. If your module is listed, please check all pull request, why they are not merged yet. Pending requests in repository yast-apparmor: - Port to rake (303 days) https://github.com/yast/yast-apparmor/pull/40 Pending requests in repository yast-bootloader: - Fix resume with uuid partition (270 days) https://github.com/yast/yast-bootloader/pull/564 Pending requests in repository yast-core: - Fixes for gensalt handling with libxcrypt. (45 days) https://github.com/yast/yast-core/pull/144 Pending requests in repository yast-country: - Port to rake (270 days) https://github.com/yast/yast-country/pull/217 Pending requests in repository yast-devtools: - Y2logs analyzer (47 days) https://github.com/yast/yast-devtools/pull/149 - Supplement changes from YCC (75 days) https://github.com/yast/yast-devtools/pull/148 - Move desktop files (308 days) https://github.com/yast/yast-devtools/pull/143 Pending requests in repository yast-installation: - Stop plymouth splash to avoid serial terminal splutter. (31 days) https://github.com/yast/yast-installation/pull/841 - Demo: eager mode of zombie-killer 0.5 (521 days) https://github.com/yast/yast-installation/pull/761 Pending requests in repository yast-network: - network-ng: test cases document (draft) (143 days) https://github.com/yast/yast-network/pull/947 - add initial test cases document (269 days) https://github.com/yast/yast-network/pull/853 Pending requests in repository yast-nis-client: - fix build requires (34 days) https://github.com/yast/yast-nis-client/pull/47 Pending requests in repository yast-online-update-configuration: - drop old testsuite and convert to rake (17 days) https://github.com/yast/yast-online-update-configuration/pull/24 Pending requests in repository yast-packager: - Include some hints in the "Priority" label (bsc#1154693) (12 days) https://github.com/yast/yast-packager/pull/482 Pending requests in repository yast-pkg-bindings: - drop old empty testsuite (17 days) https://github.com/yast/yast-pkg-bindings/pull/127 Pending requests in repository yast-registration: - [SP3] Fix misleading default_skipping_text (BSC#1167795) (10 days) https://github.com/yast/yast-registration/pull/488 Pending requests in repository yast-sound: - drop old testsuite without replacement (17 days) https://github.com/yast/yast-sound/pull/36 Pending requests in repository yast-squid: - packaging: remove SuSEfirewall2 artifacts (261 days) https://github.com/yast/yast-squid/pull/30 Pending requests in repository yast-sudo: - WIP: Add a CFA model for handling the sudoers file (104 days) https://github.com/yast/yast-sudo/pull/12 Pending requests in repository yast-sysconfig: - Drop old testsuite (16 days) https://github.com/yast/yast-sysconfig/pull/30 Pending requests in repository yast-users: - Improve readme (67 days) https://github.com/yast/yast-users/pull/224 - Move back the UMASK default value to /etc/login.defs (bsc#1099153) (648 days) https://github.com/yast/yast-users/pull/161 Pending requests in repository yast-yast2: - Change the way groups are defined (307 days) https://github.com/yast/yast-yast2/pull/936 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (438 days) https://github.com/yast/yast-yast2/pull/894 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (438 days) https://github.com/yast/yast-yast2/pull/893 - [WIP] Firewalld fixes for the new UI (586 days) https://github.com/yast/yast-yast2/pull/813 - [WIP] Drop SuSEfirewall2 completely (571 days) https://github.com/yast/yast-yast2/pull/806 ERROR: API query limit exceeded -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

[yast-devel] YaST XML Parser
by josef Reidinger 09 Apr '20

09 Apr '20

Hi, I am currently working on research how to improve XML parser in YaST. What we have nowadays is libxml2 based c++ parser ( that almost noone use directly ) and XML module ( module as a code, not YaST module :). I check usage of XML module and main usage is data to XML and back ( with variant xml as string or xml as file ). There is just two additional functionality. One is checking xml error ( almost noone use it ) and setting metadata for generated xml ( bad API as it should be part of that data to XML method ). So my question is what we would like to have better? One thing for sure that hit us often is optional schema validation ( as some XML is prevalidated like control files for products of roles, but autoyast is user generated/written ). Also some nicer error reporting would be nice because current XMLError method is almost never used (and yes, you should read nicer as using exception that can/have to be catched otherwise it report popup with internal error and not cause some strange error later ). Do you think that it makes sense at all to have own module as ruby, perl and also python, for whose we currently have bindings, all have own good ( good as better then our ) parser. So does it makes sense to have own XML parser beside backward compatibility and for new stuff as already seen on some places just use rexml or nokogiri that e.g. already have support for relax ng validation[1]? Or do we have some functionality that we would like to have on top of standard parsers? Only thing that current parser have on top of generic xml parsers is understanding of type attribute that do automatic type conversion so `<a type="boolean>true</a>` is returned as `true` and not `"true"`. But this magic is also source of some bugs as e.g. hash does not have this type attribute and result is that `<a><key>b</key>c</a>` is returned as `"c"` and not hash, which cause many recent failures we get with typos in autoyast profiles. And as bonus we do not specify this types in schema, so during validation if you omit type it is still valid xml, but it crashes in code as it expect different type. I would welcome any suggestions or ideas how your ideal xml parser should look like. Thanks Josef [1] https://stackoverflow.com/questions/913489/how-do-i-validate-xml-via-relax-… -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

5 11