April 2020 - YaST Development - openSUSE Mailing Lists

[yast-devel] Yast XML parser and strictness
by josef Reidinger 08 Apr '20

08 Apr '20

Hi, as you can read in previous mails, I am playing with xml parser used in YaST. Nokogiri looks like the best option due to its relax ng support and its availability in SLE (used in SLES-HA). And nokogiri has also one interesting feature and that is relaxed parsing that tries hard to parse document even when it is malformed[1] ( but you can still log errors). Example that nokogiri can parse: <test> <not_closed> <not_closed2> value </not_opened> </test> which results in something like test -> not_closed -> not_closed2 -> value tree I check old yast yast parser and it is strict here and return nil and set error. Question is should we keep old behavior or try to relax it and just logs errors and warnings? For working profiles nothing changes. Josef [1] https://nokogiri.org/tutorials/ensuring_well_formed_markup.html -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

3 3

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

06 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 (296 days) https://github.com/yast/yast-apparmor/pull/40 Pending requests in repository yast-bootloader: - Fix resume with uuid partition (263 days) https://github.com/yast/yast-bootloader/pull/564 Pending requests in repository yast-core: - Fixes for gensalt handling with libxcrypt. (38 days) https://github.com/yast/yast-core/pull/144 Pending requests in repository yast-country: - Port to rake (263 days) https://github.com/yast/yast-country/pull/217 Pending requests in repository yast-devtools: - Y2logs analyzer (40 days) https://github.com/yast/yast-devtools/pull/149 - Supplement changes from YCC (68 days) https://github.com/yast/yast-devtools/pull/148 - Move desktop files (301 days) https://github.com/yast/yast-devtools/pull/143 Pending requests in repository yast-installation: - Stop plymouth splash to avoid serial terminal splutter. (24 days) https://github.com/yast/yast-installation/pull/841 - Demo: eager mode of zombie-killer 0.5 (514 days) https://github.com/yast/yast-installation/pull/761 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: highlights of development sprint 96
by Ancor Gonzalez Sosa 03 Apr '20

03 Apr '20

While many activities around the world slow down, we are proud to say the YaST development keeps going at full speed. Check it in the latest report of the YaST Team activity, including: * More news about the new Online Search functionality * Improvements in the user interface to configure NTP * Progress in the support of Secure Boot for s390 mainframes * Better reporting in AutoYaST * Some bugfixes related to the handling of storage devices * And a bonus: our new tool for mass review of GitHub pull requests Find the whole report at https://yast.opensuse.org/blog/2020-04-02/sprint-96 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

1 0

[yast-devel] Handling sysctl config in yast2-security
by Knut Alejandro Anderssen González 02 Apr '20

02 Apr '20

In this sprint I'm working on a bug reported against yast2-security module. This module manage some YaST sysctl config file attributes [1]. ## Problem After modifying the settings it does not apply the network changes to the running system. In the past that responsibility was handle by boot.ipconfig which it is not the case anymore once we moved to systemd. Currently, if there is at least a conflict [2] with other sysctl config files, the error is reported but the changes are not written as you can check in the code: https://github.com/yast/yast-security/blob/master/src/modules/Security.rb#L… https://github.com/yast/yast-yast2/pull/1021/files#diff-4216cbac8e98ed10343… Thus, the changes done in the UI are lost, and need to be modified manually later. ## Proposed Solution - The sysctl changes made by the module should be written always to not lost them. - If there is some sysctl config change, then the changes will be applied to the running system. In case of a conflict it will be reported and the changes will be applied system wide (sysctl --system), which means that higher precedence values will be applied instead of the yast ones, but no conflicting attributes will be applied fine. Basically the same that would be applied by rebooting the system. In case of no conflict, then, only the changes of the yast sysctl config file will be applied (sysctl -p /etc/sysctl.d/70-yast.conf). This is faster, and should be safe enough. You can check the proposed solution in this PR: https://github.com/yast/yast-security/pull/67 ## Feeback We would like to know what do you thing about the proposed approach and if you prefer to solve it in other way. Thanks in advance ;) [1] Attributes handling by the module: See https://github.com/yast/yast-security/blob/master/src/modules/Security.rb#L… - kernel.sysrq - net.ipv4.tcp_syncookies - net.ipv4.ip_forward - net.ipv6.conf.all.forwarding [2] A conflict means that there is at least one attribute handled in the yast sysctl config file which is also handled in a file with high precedence than the yast config file See https://github.com/yast/yast-yast2/blob/master/library/general/src/lib/cfa/… -- Knut Alejandro Anderssen 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

2 2

[yast-devel] Permission issues at Travis
by Ladislav Slezak 01 Apr '20

01 Apr '20

Hi all, Some Travis builds might be failing with a permission error, the workaround is to add "--privileged" option to the "docker run" command, like here https://github.com/openSUSE/linuxrc/pull/217/commits/a2457839d53d1631f98443… Some details: I have not found the real cause for this, the Docker at Travis has not been updated, that should not be a problem. But I found that the problem happens also with the official TW image: docker run --rm -it opensuse/tumbleweed bash -c "touch /tmp/test; ls /tmp/test" ls: cannot access '/tmp/test': Operation not permitted So the problem is not specific only to the our YaST images. Interestingly, this happens only in the Travis Docker, in my Leap 15.1 Docker it works as expected. Also using the yastdevel/ruby image from Docker Hub (which is based on opensuse/tumbleweed !!) is fine at Travis... :-o But as both failing images are built by OBS and the images built by the Docker Hub are fine (even the images based on the OBS base images!) my suspicion is that the OBS images are somehow not fully compatible with all Docker clients... -- 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] 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