March 2020 - YaST Development - openSUSE Mailing Lists

[yast-devel] Overcommit - automatic checks via Git hooks
by Ladislav Slezak 21 Dec '22

21 Dec '22

Hi, I found a quite interesting tool called Overcommit [1]. It provides an easy way for setting up Git commit hooks and provides some basic checking plugins. The nice feature of the Git commit hooks is that you can run some checks automatically and early in the development. For example with the commit hooks you can run Rubocop check automatically whenever a commit is created. And if the check fails the commit is not created. I can see "make Rubocop happy" commits quite often (happens to me as well), with Overcommit you can easily avoid that. I have tried several Overcommit checks: - Rubocop - runs Rubocop at "commit" - Rspec - runs the tests before "push" - Branch blacklist - can forbid direct commits to configured branches, e.g. "master" (forces using pull requests, avoids commits to master my mistake) - Commit message spellcheck - warns when there is a possible typo Check my blog post [2] for the details, esp. watch the recorded screencast where I wanted to show some mistakes which it can catch. The tool looks promising, I'll try using it for some time. If you want to try it as well check the blog post for the installation steps. Enjoy! [1] https://github.com/brigade/overcommit [2] http://blog.ladslezak.cz/2016/06/06/overcommit/ -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak(a)suse.com SUSE -- 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] 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

[yast-devel] VirtualBox: Using Shared Folders for Development
by Stefan Hundhammer 23 Mar '20

23 Mar '20

Since nobody on our IRC channel seemed to know this and it took me quite a while to figure out, I thought I'd write this up for the benefit of others: I wanted to use a shared folder in a VirtualBox Linux VM where I can edit source files on my host system, yet build inside the VM with a well-defined development environment. By default, VirtualBox uses bizarre permissions that won't let you do very much; but that can be hammered into shape to become useful: https://github.com/shundhammer/huha-linux-tips/blob/master/doc/virtualbox-t… Kind regards -- Stefan Hundhammer <shundhammer(a)suse.de> YaST Developer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- 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 23 Mar '20

23 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 (282 days) https://github.com/yast/yast-apparmor/pull/40 Pending requests in repository yast-bootloader: - Fix resume with uuid partition (249 days) https://github.com/yast/yast-bootloader/pull/564 Pending requests in repository yast-core: - Fixes for gensalt handling with libxcrypt. (24 days) https://github.com/yast/yast-core/pull/144 Pending requests in repository yast-country: - Port to rake (249 days) https://github.com/yast/yast-country/pull/217 Pending requests in repository yast-devtools: - Y2logs analyzer (26 days) https://github.com/yast/yast-devtools/pull/149 - Supplement changes from YCC (54 days) https://github.com/yast/yast-devtools/pull/148 - Move desktop files (287 days) https://github.com/yast/yast-devtools/pull/143 Pending requests in repository yast-installation: - Stop plymouth splash to avoid serial terminal splutter. (10 days) https://github.com/yast/yast-installation/pull/841 - Demo: eager mode of zombie-killer 0.5 (500 days) https://github.com/yast/yast-installation/pull/761 Pending requests in repository yast-network: - network-ng: test cases document (draft) (122 days) https://github.com/yast/yast-network/pull/947 - add initial test cases document (248 days) https://github.com/yast/yast-network/pull/853 Pending requests in repository yast-nis-client: - fix build requires (13 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) (149 days) https://github.com/yast/yast-packager/pull/482 Pending requests in repository yast-squid: - packaging: remove SuSEfirewall2 artifacts (240 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 (83 days) https://github.com/yast/yast-sudo/pull/12 Pending requests in repository yast-users: - Improve readme (46 days) https://github.com/yast/yast-users/pull/224 - Move back the UMASK default value to /etc/login.defs (bsc#1099153) (627 days) https://github.com/yast/yast-users/pull/161 Pending requests in repository yast-yast2: - Change the way groups are defined (286 days) https://github.com/yast/yast-yast2/pull/936 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (417 days) https://github.com/yast/yast-yast2/pull/894 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (417 days) https://github.com/yast/yast-yast2/pull/893 - [WIP] Firewalld fixes for the new UI (565 days) https://github.com/yast/yast-yast2/pull/813 - [WIP] Drop SuSEfirewall2 completely (550 days) https://github.com/yast/yast-yast2/pull/806 Pending requests in repository yast-ycp-ui-bindings: - [WIP] Support bold font inside tables (577 days) https://github.com/yast/yast-ycp-ui-bindings/pull/35 Pending requests in repository yast-ruby-bindings: - Fixes for gensalt handling with libxcrypt. (24 days) https://github.com/yast/yast-ruby-bindings/pull/239 - [WIP] Don't crash on NoMethodError when Perl is involved (80 days) https://github.com/yast/yast-ruby-bindings/pull/224 - log method name (664 days) https://github.com/yast/yast-ruby-bindings/pull/216 Pending requests in repository yast-rake: - Switch desktop directory (287 days) https://github.com/yast/yast-rake/pull/70 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] Innovation Time: libyui-ruby-bindings
by josef Reidinger 20 Mar '20

20 Mar '20

Hi, today I use my innovation time to check possible improvements for UI. After yesterday discussion I start with checking at first what we already have - libyui ruby bindings. It is just thin layer on top of libyui, but it is already there. As starting point I do two things that we can use to start discussion: 1. fix libyui-bindings to provide usable rpm ( do not create project yet in OBS ) - simply run `rake osc:build` to get rpm that you can install.[1] 2. try to port one real dialog. I pick very simple one because I do not want to face layers built on top of UI module and also because I expect obstacles.[2] So how it ends? libyui-bindings looks working for me in ncurses. In qt I am getting segfaults and also for examples in libyui-bindings itself. From a quick view it looks like for me again some pain with a way how we destruct objects. It need probably some expert view why it segfaulting as I do not see anything obvious using gdb or valgrind. Adapted dialog in yast2-cio ( you can try it yourself if you use manual_run directory and do some symlinking to bin as with recent secure change to drop custom PATH it does not longer works out of box ) looks reasonable simple for me. Only bigger code is for replace widget which is implemented in ycp-ui-bindings and is non-trivial operation. Maybe something to backport to libyui itself? So if you are interested please see both pull requests and try to use it yourself. And if there is qt expert, then checking why ruby bindings segfault would be useful. Josef [1] https://github.com/libyui/libyui-bindings/pull/32 [2] https://github.com/yast/yast-cio/pull/34 -- 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] yupdate - an alternative to DUD
by Ladislav Slezak 20 Mar '20

20 Mar '20

Hi all, testing fixes or new features is quite easy in an installed system, usually just running "sudo rake install" is enough for Ruby packages. However, if you need to test something in installation then the things gets more complicated. If it is just one-liner you can modify the file locally before running the installer. If it is more complicated you can build a Driver Update Disk. But that's not trivial and takes some time. You also need to somewhere publish the built DUD so the installer can download it, you need to configure an HTTP/FTP/NFS server... If you need to fix several packages it gets even more complicated. Therefore I have implemented the "yupdate" helper script which makes the modifications to inst-sys much easier. You need to start the installation with "start_shell=1" boot parameter to apply the changes before starting the installer. Documentation ============= The latest documentation is always available here: [1] https://github.com/yast/yast-installation/blob/master/doc/yupdate.md [2] https://github.com/yast/yast-rake/#server What it can do? ================ 1. Install the sources from GitHub ----------------------------------- It can install the sources directly from GitHub, just specify the GitHub repository name and the branch to apply. Run in the inst-sys: yupdate patch yast-yast2 master This will install the latest "yast2" package from the "master" branch. You can also use your fork, just use the full name including the user name like "user/yast-yast2". If the user name is missing it uses the "yast" organization by default. 2. Install from a local Git checkout ------------------------------------ Committing and pushing every single change to GitHub is a bit annoying if you are just adding debug messages or experimenting with the code. Therefore I have implemented a simple HTTP server which serves the local sources in a similar way as GitHub. Just run "rake server" in an YaST Git checkout to start it. To use the sources from your server run in the inst-sys: yupdate patch my_machine.suse.com Replace the "my_machine.suse.com" with your host name or IP address. (If the firewall is running you need to open the port for server, the [2] documentation for details.) 3. Install from multiple local Git checkouts -------------------------------------------- If you need to update several YaST packages, then just run "rake server" in each of them and use the same "yupdate" command. The HTTP server provides a simple introspection which lists all running "rake server" servers and the "yupdate" script applies the sources from each of them one-by-one. 4. Additional commands ----------------------- The "yupdate" script supports some more commands, see the documentation. I'd just mention here the "yupdate overlayfs reset" which removes all changes and resets the inst-sys to the original state. This can be useful if you mess up the inst-sys and you want to start from scratch. Notes ===== Logging ------- The "yupdate" logs to the standard y2log file so you can see there which files have been modified. When reading an y2log you can easily find out that the inst-sys was not the same as on the installation medium. Self Update ----------- After installing an update the "yupdate" script disables the YaST self-update feature because there is a conflict. If you need the self-update installed then start the installer, let the self-update proceed, abort the installation and then use the "yupdate" script. Limitations ------------ Of course, nothing is perfect so also this approach has some disadvantages: - Works only for packages which use the Rake tool for installation (it cannot work with the autotools based packages simply because the autoconf, automake and their dependencies are missing in the inst-sys) - Works only for Ruby packages (more exactly for packages which do not have any special build dependencies, e.g. do not require a C++ compiler). - Does not work for some specific packages which do some additional magic in the *.spec file after running "rake install". For example the yast-theme package does not work because of that. 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

1 0

[yast-devel] Looking for good UI API
by josef Reidinger 20 Mar '20

20 Mar '20

Hi, as tomorrow is innovation time, I would like to look to a good UI/widget API. Backend is not important, it can be even for windows UI. Also language is not important, I can get inspiration even from C# :) I mainly want some inspiration what works well and what not and also what is architecture and general ideas. API should be ideally really high level, as I would like to ideally use it for new API we use in YaST in ruby. Thanks for any tips for libraries or frameworks. Josef -- 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] YaST: highlights of development sprint 95
by Imobach González Sosa 19 Mar '20

19 Mar '20

Hi all, The YaST team has published another sprint report. Given that Lizards[1] is now considered as deprecated, we have migrated our blog to the project's website[2]. In this report, we have focused on: * New possibilities for pervasive encryption. * Improvements in the mechanism to install missing packages during storage system analysis. * Better handling of some conflicting attributes in AutoYaST. * Several usability improvements in the iSCSI LIO Server module. You can find the whole report at https://yast.opensuse.org/blog/2020-03-19/sprint-95 Regards, Imo PS: we will finish the migration of the old content as soon as possible. [1] https://lizards.opensuse.org/ [2] https://yast.opensuse.org -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/

1 0

[yast-devel] Early detection of usr etc config files
by José Iván López González 16 Mar '20

16 Mar '20

Hi all, As you probably know, SUSE/openSUSE is moving config files from /etc to /usr/etc. This could make some YaST modules to fail, so we need to find a way to early detect when a package configured by YaST is doing such change. Right now we (YaST team) are noticed when we receive a bug report. But that approach is risky if the bug is not detected by openQA but a final user. I have described a possible solution here https://gist.github.com/joseivanlopez/bcf7185904922afae7d93f7518192864. Feedback is welcome. CU -- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez -- 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] Pending Pull Requests
by yast-ci＠opensuse.org 16 Mar '20

16 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 (275 days) https://github.com/yast/yast-apparmor/pull/40 Pending requests in repository yast-bootloader: - Fix resume with uuid partition (242 days) https://github.com/yast/yast-bootloader/pull/564 Pending requests in repository yast-core: - Fixes for gensalt handling with libxcrypt. (17 days) https://github.com/yast/yast-core/pull/144 Pending requests in repository yast-country: - Port to rake (242 days) https://github.com/yast/yast-country/pull/217 Pending requests in repository yast-devtools: - Y2logs analyzer (19 days) https://github.com/yast/yast-devtools/pull/149 - Supplement changes from YCC (47 days) https://github.com/yast/yast-devtools/pull/148 - Move desktop files (280 days) https://github.com/yast/yast-devtools/pull/143 Pending requests in repository yast-installation: - Demo: eager mode of zombie-killer 0.5 (493 days) https://github.com/yast/yast-installation/pull/761 Pending requests in repository yast-network: - network-ng: test cases document (draft) (115 days) https://github.com/yast/yast-network/pull/947 - add initial test cases document (241 days) https://github.com/yast/yast-network/pull/853 Pending requests in repository yast-nis-client: - fix build requires (6 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) (142 days) https://github.com/yast/yast-packager/pull/482 Pending requests in repository yast-squid: - packaging: remove SuSEfirewall2 artifacts (233 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 (76 days) https://github.com/yast/yast-sudo/pull/12 Pending requests in repository yast-users: - Improve readme (39 days) https://github.com/yast/yast-users/pull/224 - Move back the UMASK default value to /etc/login.defs (bsc#1099153) (620 days) https://github.com/yast/yast-users/pull/161 Pending requests in repository yast-yast2: - Change the way groups are defined (279 days) https://github.com/yast/yast-yast2/pull/936 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (410 days) https://github.com/yast/yast-yast2/pull/894 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (410 days) https://github.com/yast/yast-yast2/pull/893 - [WIP] Firewalld fixes for the new UI (558 days) https://github.com/yast/yast-yast2/pull/813 - [WIP] Drop SuSEfirewall2 completely (543 days) https://github.com/yast/yast-yast2/pull/806 Pending requests in repository yast-ycp-ui-bindings: - [WIP] Support bold font inside tables (570 days) https://github.com/yast/yast-ycp-ui-bindings/pull/35 Pending requests in repository yast-ruby-bindings: - Fixes for gensalt handling with libxcrypt. (17 days) https://github.com/yast/yast-ruby-bindings/pull/239 - [WIP] Don't crash on NoMethodError when Perl is involved (73 days) https://github.com/yast/yast-ruby-bindings/pull/224 - log method name (657 days) https://github.com/yast/yast-ruby-bindings/pull/216 Pending requests in repository yast-samba-client: - Master bsc1158916 (6 days) https://github.com/yast/yast-samba-client/pull/81 - Do not stop nmbd while running nmbstatus (6 days) https://github.com/yast/yast-samba-client/pull/80 - Use kerberos authentication by default during join (123 days) https://github.com/yast/yast-samba-client/pull/79 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] Time to decide on new priorities for next sprints
by Lukas Ocilka 13 Mar '20

13 Mar '20

Hi guys, Me and Ancor have been maintaining a long list of big topics, such as features, refactoring, wishes, future needs etc., but this list reflects the current situation trying to address all the needs from various sources at the time. I'd like to ask for your personal view now: What do you feel is important to do, let's say mid to long-term, and also why? To spoil the fun a bit, I'll use an example... ~~~~~ We've been postponing some refactoring in Packages/Patterns/Extensions/Add-Ons/Registration because we always felt it was going to change once more and thus it's not wort the effort of the refactoring. We've created a technical debt there. In fact, we should have done the refactoring even earlier exactly because we knew it was going to change again and again. The refactoring in this area is utterly needed to, e.g., split classes into smaller ones to have a simple responsibility, to increase the test coverage, to implement some realy object-oriented code, ... to be more flexible - prepared for changes to come (this real example has been written with a huge help from Imo and Ancor :)) ~~~~~ Obviously we already have many topics, but it's never too late to learn that there are even some more and more important just behind the corner :) Please, share your opinion. Thanks in advance 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

4 3

[yast-devel] Time to branch the repositories?
by Ancor Gonzalez Sosa 12 Mar '20

12 Mar '20

As Lukas mentioned in another thread, it's time to start looking to the next big topic(s). And, while there are still some bugs to fix before the release of SLE-15-SP2 / Leap 15.2, we should be very conservative about what we modify there. So, in my opinion, it's time to create the SLE-15-SP2 branches in all the YaST repositories, so we can "go wild" in the master branch without affecting 15.2 and be more selective about what we submit to that release (to not invalidate all the testing done already). Anyone against it? If not, I would do the branching on Monday, so next sprint can already be planned with that separation in mind. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions -- 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] JFYI: libyzpp 17.23.2 switches from using -std=c++14 to c++17
by Michael Andres 09 Mar '20

09 Mar '20

Hi. This switch alone should not have impact on the apps linking against libzypp. But Future APIs may make use of new stl types like std::string_view or the filesystem library, ..... You won't be able to use them if you stay with an older standard. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres, E&I, ma(a)suse.com, Phone: ++49 (0)911 - 74 053-0 +------------------------------------------------------------------+ SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg Germany, (HRB 36809, AG Nürnberg) Geschäftsführer: 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

1 0

[yast-devel] YaST: highlights of development sprint 94... and Hack Week
by Ancor Gonzalez Sosa 06 Mar '20

06 Mar '20

After a month of silent work, the YaST Team is back with some news about the latest development sprint. Those news include: - Enabling YaST on the Windows Subsystem for Linux - Usability improvements for the Online Search, the Partitioner and the Kdump module - Better control of overridden sysctl configuration values - Improvements in the default selections of the upcoming SLE-15-SP2 installer - New features for zSeries mainframes like Secure Boot and I/O devices auto-configuration - A couple of Hack Week projects related to YaST, Ruby and Crystal As you can see, there is a little bit of everything in the menu. Dive into the details at https://lizards.opensuse.org/2020/03/06/yast-sprint-94/ 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] GitHub template repository
by Ladislav Slezak 04 Mar '20

04 Mar '20

Hi all, when reading the GitHub documentation I came across this "creating template repository" [1] documentation and how to use it [2]. A template repository is basically similar to forks, but unlike forks which link to the original repository and are mainly used for upstream contribution, the templates are used for starting a new completely separated project, just with some initial content from the template. We could create a template repository for a generic YaST module, to answer the common question "I want to create my own YaST module, where should I start?". Or maybe we could simply enable using the existing journalctl tutorial [3] as a template? What do you think about it? [1] https://help.github.com/en/github/creating-cloning-and-archiving-repositori… [2] https://help.github.com/en/github/creating-cloning-and-archiving-repositori… [3] https://github.com/yast/yast-journalctl-tutorial -- 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] Unifying YaST Contributing Guidelines
by David Díaz 04 Mar '20

04 Mar '20

Hi! As you probably know ;) we have more than 100 repositories. There fore, we have more than 100 CONTRIBUTING.md files, all of them with (in theory) the same content. That's means that we need to do more than 100 commits and pull requests for every little change in that file. Like now, that we should fix the broken Bugzilla link[1] fixing the product param. So, I'd like to propose having the full content only in the yast-yast2/CONTRIBUTING.md file[2] and a link to this file in the rest of them. What do you think? Do you have a better idea? Thank you! [1] https://github.com/yast/yast-yast2/issues/682 [2] https://github.com/yast/yast-yast2/blob/master/CONTRIBUTING.md -- David Díaz González YaST Team at SUSE Linux GmbH

4 5

[yast-devel] Discussing another usability problem in YaST
by Ancor Gonzalez Sosa 04 Mar '20

04 Mar '20

Sending this to both Ken (SUSE's UX expert) and the yast-devel ML (for public scrutiny). We have recently implemented a new feature in YaST about installing packages that are needed to inspect the storage setup of a system. But we are not satisfied with the usability, so we wanted to have some feedback about how to do things better. Here you can find a description of the problem: https://gist.github.com/ancorgs/d2565bf505834329946a998500a326c8 Feel free to comment in that gist or via mail. Thanks. -- Ancor González Sosa YaST Team at SUSE Software Solutions -- 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] 15.2 enable online repositories?
by Felix Miata 02 Mar '20

02 Mar '20

Why, when attempting a NET upgrade, after selecting which installation to upgrade, is the subject question asked? Answering no causes a nothing to do result. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 1