YaST Development March 2020

yast-devel@lists.opensuse.org

16 participants
26 discussions

[yast-devel] YaST Tips&Tricks
by Ladislav Slezak 25 Jan '22

25 Jan '22

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

2 1

[yast-devel] Reminder: verify_partial_doubles is not default
by Josef Reidinger 03 Dec '20

03 Dec '20

Hi, again I hit by thinking that verify_partial_doubles is now default in rspec3. It is not and will be in rspec4. So what it means? rspec does not check if mocked methods exists at all and it can result in many not so funny errors in test suite. I am just faced it in network, so I create non trivial commit[1] that enables it there. It includes also how to avoid failures on mocked class[2] which avoided build dependencies. From list of errors it can check is typos[3], mocking of wrong class[4] and mocking non-existing methods[5]. So feel free to take it as inspiration and enable it also in your test helper. Josef [1] https://github.com/yast/yast-network/pull/830/commits/e18da64fce25242a51710… [2] https://github.com/yast/yast-network/pull/830/commits/e18da64fce25242a51710… [3] https://github.com/yast/yast-network/pull/830/commits/e18da64fce25242a51710… [4] https://github.com/yast/yast-network/pull/830/commits/e18da64fce25242a51710… [5] https://github.com/yast/yast-network/pull/830/commits/e18da64fce25242a51710… -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

4 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] 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

[yast-devel] correction on http://yast.opensuse.org/contact
by Bryan Gartner 01 Apr '20

01 Apr '20

FYI, On the $subject cited web page, the link to Bugzilla seems to be outdated, yielding: Sorry, either the product openSUSE Factory does not exist or you aren't authorized to enter a bug into it. After a bit of browsing found the following https://bugzilla.suse.com/show_bug.cgi?id=906727, so suggest updating the link via s/openSUSE+Factory/openSUSE+Tumbleweed/ P.S. the context around this is to submit feature requests for YaST, so hoping that bugzilla is the right answer -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 1

[yast-devel] Improving the YaST self-update
by Ladislav Slezak 01 Apr '20

01 Apr '20

Hi all, I'm improving the YaST self-update [1] to avoid applying wrong patches to the installer (i.e. using the SP1 or SP3 update repository in the SP2 installer). I have already implemented the downgrade check [2] (e.g. using the SP1 updates in SP2), now I'd like to also implement the other check (using the future SP3 updates in SP2). However, this case is a bit more complicated, we need to somehow differ between the "new" (a valid update) and "too new" (update for a newer SP release) packages. And we need some reliable solution for that to avoid false errors. Here is a summary of my ideas, please comment them or add your own. 1. Compare the major and minor YaST package versions As the YaST package versions are bound to specific SP release (e.g. 4.1.x for SP1, 4.2.x for SP2) we could simply check that the updated package version has the same major and minor version as the installed one. I.e. allow a difference only in the patch number. But unfortunately this is not bullet-proof, we still have some YaST packages in version 4.1.x even in SP2. That should be hopefully fixed during branching SP2 in Git but it still shows that it's not 100% percent reliable. 2. The RPM "Distribution" value Every package has a "Distribution" flag (check with "rpm --queryformat '%{DISTRIBUTION}' -q ..." command). Unfortunately even for the SP2 the value is still "SUSE Linux Enterprise 15" so we cannot differ between the GA/SP1/SP2/... packages. :-/ And I think it would not work well with unofficial testing packages built in your OBS branch project as the "Distribution" then contains the "home:..." prefix. So testing would be more difficult. 3. Custom provides flag We could possibly use some custom RPM flag, something like "Provides: yast-self-update-version(15.2)" added when releasing a self-update. We could compare it with the value stored in the /etc/os-release file in the inst-sys. Because it's enough to have this flag only once in the self-update repository we would add it just to the first YaST package released as a self-update. The other package updates released later would not need to have this flag. I deliberately selected the "15.2" value which corresponds to the "VERSION_ID" tag in the /etc/os-release file because this is the same for both SLE-15-SP2 and Leap 15.2 so we could easily build the same self-update packages also for Leap 15.2 if needed. Any comments, ideas? Thank you in advance! [1] https://github.com/yast/yast-installation/blob/master/doc/SELF_UPDATE.md [2] https://github.com/yast/yast-installation/pull/842 -- 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

3 6

[yast-devel] Innovation time: ghreview - Mass pull request reviews from command line
by Ladislav Slezak 31 Mar '20

31 Mar '20

Hi all, A short version: see https://github.com/lslezak/ghreview The minimalistic version: "gem install ghreview" :-) Full version: Sometimes we need to do a simple change but in many Git repositories. Sometimes we need to touch *all* repositories, like when we need to change the CONTRIBUTION.md or some similar file. Approving several dozens of pull requests in the GitHub web UI is not easy or convenient so I have created a simple script which can approve the pull requests from command line. The tool is interactive, for each pull request is displays some details, the diff, the Travis status, etc... and then it asks for approval. If you accept it will approve the pull request at GitHub with the usual "LGTM" message. If there is an issue the review is skipped, you need to manually comment at the GitHub web UI. (There is no easy way for commenting a diff from command line.) For more details like usage and installation see https://github.com/lslezak/ghreview PS: So far there are no RPM packages provided, but you can convince me to build it in YaST:Head :-) -- 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] Pending Pull Requests
by yast-ci＠opensuse.org 30 Mar '20

30 Mar '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 (289 days) https://github.com/yast/yast-apparmor/pull/40 Pending requests in repository yast-bootloader: - Fix resume with uuid partition (256 days) https://github.com/yast/yast-bootloader/pull/564 Pending requests in repository yast-core: - Fixes for gensalt handling with libxcrypt. (31 days) https://github.com/yast/yast-core/pull/144 Pending requests in repository yast-country: - Port to rake (256 days) https://github.com/yast/yast-country/pull/217 Pending requests in repository yast-devtools: - Y2logs analyzer (33 days) https://github.com/yast/yast-devtools/pull/149 - Supplement changes from YCC (61 days) https://github.com/yast/yast-devtools/pull/148 - Move desktop files (294 days) https://github.com/yast/yast-devtools/pull/143 Pending requests in repository yast-installation: - Stop plymouth splash to avoid serial terminal splutter. (17 days) https://github.com/yast/yast-installation/pull/841 - Demo: eager mode of zombie-killer 0.5 (507 days) https://github.com/yast/yast-installation/pull/761 Pending requests in repository yast-network: - network-ng: test cases document (draft) (129 days) https://github.com/yast/yast-network/pull/947 - add initial test cases document (255 days) https://github.com/yast/yast-network/pull/853 Pending requests in repository yast-nis-client: - fix build requires (20 days) https://github.com/yast/yast-nis-client/pull/47 Pending requests in repository yast-packager: - Include some hints in the "Priority" label (bsc#1154693) (156 days) https://github.com/yast/yast-packager/pull/482 Pending requests in repository yast-squid: - packaging: remove SuSEfirewall2 artifacts (247 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 (90 days) https://github.com/yast/yast-sudo/pull/12 Pending requests in repository yast-users: - Improve readme (53 days) https://github.com/yast/yast-users/pull/224 - Move back the UMASK default value to /etc/login.defs (bsc#1099153) (634 days) https://github.com/yast/yast-users/pull/161 Pending requests in repository yast-yast2: - Change the way groups are defined (293 days) https://github.com/yast/yast-yast2/pull/936 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (424 days) https://github.com/yast/yast-yast2/pull/894 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (424 days) https://github.com/yast/yast-yast2/pull/893 - [WIP] Firewalld fixes for the new UI (572 days) https://github.com/yast/yast-yast2/pull/813 - [WIP] Drop SuSEfirewall2 completely (557 days) https://github.com/yast/yast-yast2/pull/806 Pending requests in repository yast-ycp-ui-bindings: - [WIP] Support bold font inside tables (584 days) https://github.com/yast/yast-ycp-ui-bindings/pull/35 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] SLE-15-SP2 branching
by Lukas Ocilka 25 Mar '20

25 Mar '20

Dne 24. 03. 20 v 19:43 Arvin Schnell napsal(a): > The POs should know what work is ahead. I'm afraid that there is a misunderstanding about our superpowers :) POs know which features are now requested, which P1s are mandatory to fix. POs even guess which features could be requested in the future if they are in JIRA already and they partly know what should be done based on their and the team experience, but - and that is the most important - POs don't, and never will be, able to "read" the future, e.g., how many, how important and how hard P1s are going to come tomorrow, or in a week or two. The same for L3s. We can only guess based on some old data, e.g., previous products. The decision when and how to branch is still on the team. I can only say that I'm going to plan for "the future" already. HTH 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

1 0

Re: [yast-devel] SLE-15-SP2 branching
by Lukas Ocilka 24 Mar '20

24 Mar '20

Dne 24. 03. 20 v 18:49 Arvin Schnell napsal(a): > I am working on SP2 so I suggest to still wait with creating the > branch. I'm afraid that most of the developers still work on SP2 fixes, but the point is that some (even the same ones) already started or want to start (or even have to start) working on new products. We can't really wait till SLE 15 SP2 is out. Or did I understand something incorrectly? 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

2 1

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

YaST Development March 2020