June 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] Innovation time: A repository with AutoYaST XML profiles (PoC )
by Ladislav Slezak 03 May '21

03 May '21

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

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] Very late updates for yast2-trans
by José Iván López González 07 Jul '20

07 Jul '20

Hi all, Recently, a bug report [1] was filed because translation updates are taken quite long to reach the product. It seems that it took almost 1 year and 4 months to get an updated yast2-trans package into Leap 15.2. Do you know the source of the problem? Could we do anything to improve it? Thanks! [1] https://bugzilla.suse.com/show_bug.cgi?id=1172874 -- 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

2 3

[yast-devel] Storage Wizards
by Arvin Schnell 02 Jul '20

02 Jul '20

Hi, the YaST team has the idea to make some storage tasks simpler to use by introducing storage wizards. Attached are the first brain storming results. Feedback is wanted. ciao Arvin -- Arvin Schnell, <aschnell(a)suse.com> Senior Software Engineer, Research & Development SUSE Software Solutions Germany GmbH Maxfeldstraße 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

3 16

[yast-devel] ruby2.7 issue with $LOAD_PATHS
by José Iván López González 30 Jun '20

30 Jun '20

Hi all, Most likely you already know about our crazy bug in the Tumbleweed installer that was reported some weeks ago [1]. Basically, the problem was raised because a same ruby file was "loaded" twice after requiring it for second time. Obviously this should not happen because Kernel#require method prevents that [2]. As the documentation states: "The absolute path of the loaded file is added to $LOADED_FEATURES. A file will not be loaded again if its path already appears in $LOADED_FEATURES". So, why is a file loaded twice in YaST? TL;DR: because ruby2.7 has a bug when requiring files from symlinks. In general, ruby expands the absolute path of a loaded file by following the symlink, so the $LOAD_FEATURES would contain the path of the real file instead of the symlink path. For example: # There is a symlink like # # /usr/share/foo --> /mnt/foo $LOAD_PATH.append("/usr/share/foo/lib") require "foobar" $LOADED_FEATURES.grep(/foobar/) # => "/mnt/foo/lib/foobar.rb" But there is a corner case in ruby2.7. Ruby tracks the file by using the symlink path when: * a new directory is added to the beginning of $LOAD_PATH and * any parent of the added directory is a symbolic link. # There is a symlink like # # /usr/share/foo --> /mnt/foo $LOAD_PATH.append("/usr/share/foo/lib") require "foobar" $LOADED_FEATURES.grep(/foobar/) # => "/mnt/foo/lib/foobar.rb" But: $LOAD_PATH.prepend("/usr/share/foo/lib") require "foobar" $LOADED_FEATURES.grep(/foobar/) # => "/usr/share/foo/lib/foobar.rb" Note the difference of the $LOADED_FEATURES when the path is added at the beginning of the list and at the end. And also note that this does not happen when the new added load path is a symlink itself: # There is a symlink like # # /usr/share/foo/lib --> /mnt/foo/lib $LOAD_PATH.append("/usr/share/foo/lib") require "foobar" $LOADED_FEATURES.grep(/foobar/) # => "/mnt/foo/lib/foobar.rb" And: $LOAD_PATH.prepend("/usr/share/foo/lib") require "foobar" $LOADED_FEATURES.grep(/foobar/) # => "/mnt/foo/lib/foobar.rb" All this is very unexpected, and only happens in ruby2.7. This weird behavior was making YaST to fail, see [3] for more details. I have prepared an script to automatically reproduce this issue (see the attached file). You can use it to see the difference with ruby2.7 and previous versions. Do you think this is actually a bug in ruby2.7? Or am I doing something wrong? Should we report a bug? For the time being, we have found a workaround to avoid the failure in YaST side. Regards, Iván [1] https://bugzilla.suse.com/show_bug.cgi?id=1172898 [2] https://apidock.com/ruby/Kernel/require [3] https://bugzilla.opensuse.org/show_bug.cgi?id=1172898#c20 -- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez

1 0

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

29 Jun '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 (380 days) https://github.com/yast/yast-apparmor/pull/40 Pending requests in repository yast-autoinstallation: - Find the Base Product (55 days) https://github.com/yast/yast-autoinstallation/pull/599 Pending requests in repository yast-bootloader: - Efi dos label (6 days) https://github.com/yast/yast-bootloader/pull/609 - Fix resume with uuid partition (347 days) https://github.com/yast/yast-bootloader/pull/564 Pending requests in repository yast-core: - Fixes for gensalt handling with libxcrypt. (122 days) https://github.com/yast/yast-core/pull/144 Pending requests in repository yast-country: - Port to rake (347 days) https://github.com/yast/yast-country/pull/217 Pending requests in repository yast-devtools: - Y2logs analyzer (124 days) https://github.com/yast/yast-devtools/pull/149 - Supplement changes from YCC (152 days) https://github.com/yast/yast-devtools/pull/148 - Move desktop files (385 days) https://github.com/yast/yast-devtools/pull/143 Pending requests in repository yast-installation: - clarify that ssh_import processes host keys (bsc#1172400) (24 days) https://github.com/yast/yast-installation/pull/860 - Demo: eager mode of zombie-killer 0.5 (598 days) https://github.com/yast/yast-installation/pull/761 Pending requests in repository yast-network: - network-ng: test cases document (draft) (220 days) https://github.com/yast/yast-network/pull/947 - add initial test cases document (346 days) https://github.com/yast/yast-network/pull/853 Pending requests in repository yast-packager: - Include some hints in the "Priority" label (bsc#1154693) (89 days) https://github.com/yast/yast-packager/pull/482 Pending requests in repository yast-yast2: - Bnc#1081441 (74 days) https://github.com/yast/yast-yast2/pull/1047 - [WIP] CWM improvements (75 days) https://github.com/yast/yast-yast2/pull/1044 - Change the way groups are defined (384 days) https://github.com/yast/yast-yast2/pull/936 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (515 days) https://github.com/yast/yast-yast2/pull/894 - save_y2logs: save kernel messages and udev log (bsc#1089647, bsc#1085… (515 days) https://github.com/yast/yast-yast2/pull/893 - [WIP] Firewalld fixes for the new UI (663 days) https://github.com/yast/yast-yast2/pull/813 - [WIP] Drop SuSEfirewall2 completely (648 days) https://github.com/yast/yast-yast2/pull/806 Pending requests in repository yast-ycp-ui-bindings: - [WIP] Support bold font inside tables (675 days) https://github.com/yast/yast-ycp-ui-bindings/pull/35 Pending requests in repository yast-ruby-bindings: - Fixes for gensalt handling with libxcrypt. (122 days) https://github.com/yast/yast-ruby-bindings/pull/239 - [WIP] Don't crash on NoMethodError when Perl is involved (178 days) https://github.com/yast/yast-ruby-bindings/pull/224 - log method name (762 days) https://github.com/yast/yast-ruby-bindings/pull/216 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 102
by Ancor Gonzalez Sosa 24 Jun '20

24 Jun '20

The YaST Team is back with another development digest... but this time we need your help! Please, visit our blog post and give us feedback using the poll embedded there. It's just three questions and it would help us a lot to define the future of our development reports. https://yast.opensuse.org/blog/2020-06-23/sprint-102 Of course, apart from the poll itself, our report includes pointers to a broad range of topics. - Validation of the AutoYaST profile during installation https://github.com/yast/yast-autoinstallation/pull/624 - More robust and complete support for AutoYaST's user scripts https://github.com/yast/yast-autoinstallation/pull/612 - Improvements in AutoYaST error handling and reporting https://github.com/yast/yast-autoinstallation/pull/625 - Improved handling of systemd services in some corner cases https://github.com/yast/yast-yast2/pull/1059 - Better detectionand and more accurate boot check for XEN https://github.com/yast/yast-yast2/pull/1062 https://github.com/yast/yast-storage-ng/pull/1102 - More explanatory labels in repositories management during upgrade https://github.com/yast/yast-installation/pull/863 - Compatibility of Snapper rollbacks with transactional servers https://github.com/openSUSE/snapper/pull/540 - Better management of automatic text wrapping in LibYUI https://github.com/libyui/libyui/pull/165 Looking forward to your feedback, see you in two weeks. -- 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] Partitioner UI: next round
by Ancor Gonzalez Sosa 22 Jun '20

22 Jun '20

I have documented the outcome of our recent meeting to come up with a new concept for the UI of the Partitioner. See the result here: https://github.com/yast/yast-storage-ng/blob/master/doc/partitioner_ui.md#a… We will use that as a base for upcoming tasks in our development sprints, but feel free to also use it as a base to bring new ideas we may have overlooked during the meeting. 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

3 3