June 2019

[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 … [View More]

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 "… [View More]

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] … [View More]

4 3

[yast-devel] consistent indentation with https://editorconfig.org/
by Martin Vidner 08 Jul '19

08 Jul '19

Hi, some time ago I started using a new code editor[1], and I found that unlike my other editor[2] it has difficulties in divinating the indentation styles of various code bases. Fortunately, a reasonable standard has emerged that lets a code base declare how to indent, in a way that editors can easily understand: https://editorconfig.org/ Here's a declaration I've been using for our Ruby code: # top-most EditorConfig file root = true # 2 space indentation [*.rb] … [View More]

3 2

[yast-devel] Hackweek project: Welcome New Rubocop
by Josef Reidinger 28 Jun '19

28 Jun '19

Hi, for those who are not interested in details just quick summary. There is new shared defaults for rubocop and it is also automatic detected. So how to quickly switch from old rubocop to new one? change ``` inherit_from: /usr/share/YaST2/data/devtools/data/rubocop_yast_style.yml ``` to: ``` inherit_from: /usr/share/YaST2/data/devtools/data/rubocop-0.71.0_yast_style.yml ``` And then fix deprecations in old rubocop config and handle new issues arise. To run new rubocop locally … [View More]install rubygem-rubocop-0_71 and then it is handled by update alternatives or use rake check:rubocop with the latest rubygem-yast-rake. Hint: If you want to have one cop per commit, then run rubocop, pick one of cop that failing and run `rubocop --only <cop>` and fix all instances and commit. So now longer story with more technical details and impressions. Feel free to use this as part of blog post. ## Motivation So lets start with motivation. For me the biggest one is that rubocop in version we used to use support only ruby 2.2, so we cannot use in code any new features of ruby like &. or dig. Of course another one is that previously it was quite old version and newer ones have many new features like more auto corrections, new cops and so on. ## Examples I start with two well tested (bootloader[1], storage-ng[2]) modules to catch possible buggy transformations and with two modules full of ancient converted code ( yast2[3], packager[4]). Feel free to discuss exact configuration of cops so the final yast style fits at least majority of team taste. Ideally we should tune cops instead of disable, so our code is consistent and please always document reasoning for tuning. [1] https://github.com/yast/yast-bootloader/pull/572 [2] https://github.com/yast/yast-storage-ng/pull/934 [3] https://github.com/yast/yast-yast2/pull/946 [4] https://github.com/yast/yast-packager/pull/455 ## Impressions I found some cops really useful especially for killing some y2r zombies like multiline trailing if [1] or identical content in conditional branches [2]. Of course, there is also cops that prefers usage of new features like indented heredoc[3] or safe navigation operator[4]. What also helps me is restriction on short method param names[5] to have meaningful names in method definition as it usually have long scope. The best example is in Progress module parameter "st" which means in half of methods "step" and in second half "stage". Also I learn something new about ruby. As there is now cops that check for void context and this failing in storage-ng which do some fancy things in assign operator. Se let me write here demonstration code: class C def a=(v) "5" end end c = C.new a = C.a = "7" a # is now "7" and not "5" So as you can see return value of writer methods is ignored same as e.g. return value of initialize method. Another cop e.g. warn that URI.escape is deprecated and will be removed, so we can also react to it(sadly in packager I have to disable it as escaping libzypp repo path is more tricky and probably deserve own class).[6] So I think we should more regularly update rubocop as it also prepares us for next ruby versions. [1] https://github.com/yast/yast-yast2/pull/946/commits/5a25810718cb00e5ba567c0… [2] https://github.com/yast/yast-yast2/pull/946/commits/af60b295e0e383010c676e3… [3] https://github.com/yast/yast-yast2/pull/946/commits/9c0fb602be0964d3d69aa37… [4] https://github.com/yast/yast-yast2/pull/946/commits/96a3ce46ddbfa7e7e97dd6e… [5] https://github.com/yast/yast-yast2/pull/946/commits/4d02ff2410173f5851aed8f… [6] https://ruby-doc.org/stdlib-2.4.1/libdoc/uri/rdoc/URI/Escape.html#method-i-… ## Known Issues I found some possible issues. The first one is endless loop auto correct with our combination of cops and having access modifier as first element ( which is done surprising often in storage-ng ). So far I workaround it by using different access modifier indentation in storage-ng[1]. Another endless loop of auto-correct detected by rubocop can be easily fixed manually. The second issue is that using frozen string literal directive which is now encouraged can lead to exceptions. So for yast2 I do not enable it, but for bootloader and storage-ng due to their good test coverage I try to enable it. For bootloader[2] it needs just some small adaptation, but for storage-ng it will need more work as it failing in storage wrapper. It need some code modification. You can ask here why not disable it for all code? Reason is that it will be standard in ruby 3.0 which will arrive soon, so it is more like preparation for future, so whenever it is possible to do, it is good to do it. The third one is found in storage-ng where it tries to change `!(a == b)` but a is self, so it cause ruby endless loop, see [3]. And the forth is more common, now it is preferred to use more secure Yaml.safe_load which do not allow to load classes dump. But we sometimes use it for testing purpose, so it needs to be disabled for that cases[4] [1] https://github.com/yast/yast-storage-ng/pull/934/files#diff-11a0d7906801d9d… [2] https://github.com/yast/yast-bootloader/pull/572/commits/7477371f1f092b74c5… [3] https://github.com/yast/yast-storage-ng/pull/934/files#diff-e1e2b727919857c… [4] https://github.com/yast/yast-storage-ng/pull/934/files#diff-e1e2b727919857c… ## Removal of SUSE Style Guide SUSE style guide was removed few months ago with reasoning that we (as SUSE) should follow upstream and if we do not like something, try to convince rubocop default configuration to contain it. So I removed all links from YaST style guide to SUSE one and keep it as YaST tuning. Maybe it is also good time to revisit all things we inherit from SUSE style guide and check if it still fits our needs or if we want to follow upstream. I hope you find new rubocop as useful as me and feel free to comment it as much as you want. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org [View Less]

1 0

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

28 Jun '19

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-add-on: - Unify labels (bsc#1123679) (108 days) https://github.com/yast/yast-add-on/pull/69 Pending requests in repository yast-apparmor: - Port to rake (13 days) https://github.com/yast/yast-apparmor/pull/40 Pending requests … [View More]

1 0

[yast-devel] Build Times Strikes Back
by Josef Reidinger 27 Jun '19

27 Jun '19

Hi, today when I am waiting for OBS to build new ci container for testing new rubocop I check how situation changes after our last effort to reduce build time of yast stack. I use our old tool [1] and there is also old data[2]. So I can compare critical path ( which is the most interesting, as it count minimum time needed to build yast stack if we have same machines, but in unlimited amount ). So how it changes? critical path: - total time: 1780 + total time: 3452 path: - - yast2-… [View More]schema [141s] - - autoyast2 [168s] - - yast2-update [143s] - - yast2-packager [75s] - - yast2-storage [226s] - - yast2-perl-bindings [236s] - - yast2-ruby-bindings [181s] - - yast2-ycp-ui-bindings [107s] - - yast2-core [426s] - - yast2-devtools [77s] + - yast2-schema [134s] + - yast2-ntp-client [93s] + - autoyast2 [723s] + - yast2-installation [721s] + - yast2-network [171s] + - yast2-packager [93s] + - yast2-storage-ng [186s] + - libstorage-ng [1331s] The first think that is visible immediatelly that it increase a lot. From cca 30 minutes to almost 60 minutes ( so no surprise I am waiting for new release :) So I check more deeply some values, as some times looks strange. Sometimes it looks like strange behavior of OBS because total time is much bigger then steps like for yast2-installation[3] or autoyast2[4], but for libstrorage-ng it looks like real data[5]. So I check if libstorage-ng is not unlucky and simply does not hit weak machine, but it builds with -j6 which is not bad from my POV. So I do quick analyse where it spends time ( from log [6]): total: 1327s unpacking: 1s compilation (configure + make all): 921s ( doxygen: 10s, translations: 0s, bindings: 542s, ) install: 8s deduplication: 2s tests: 260s To compare, old libstorage need in total 549 seconds. So there is really slow down in build time. Question is how to speed up building process? Any ideas? I think 20 minutes for the initial building stone of all yast modules is too much. Few wild ideas: - create libstorage-ng-bootstrap that will be used for building yast2-storage-ng. That bootstrap will skip tests and pythong bindings and maybe even compile with less aggresive g++ options, which should help a lot. And of course then proper package is build that will have all this. - build python and ruby bindings in parallel. Is it doable? Or ideally do it in parallel to other compilation tasks. ( not sure if it does not hit us back with disk seeking ). Here non-recursive feature of autotools can help[7]. Any other idea that can help? Josef [1] https://github.com/mvidner/rpm-build-dependencies [2] https://github.com/mvidner/rpm-build-dependencies/blob/master/yast_deps.yaml [3] https://build.opensuse.org/package/statistics/YaST:Head/yast2-installation/… [4] https://build.opensuse.org/package/statistics/YaST:Head/autoyast2/openSUSE_… [5] https://build.opensuse.org/package/statistics/YaST:Head/libstorage-ng/openS… [6] https://build.opensuse.org/build/YaST:Head/openSUSE_Factory/x86_64/libstora… [7] https://autotools.io/automake/parallel.html -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org [View Less]

4 7

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

27 Jun '19

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-add-on: - Unify labels (bsc#1123679) (107 days) https://github.com/yast/yast-add-on/pull/69 Pending requests in repository yast-apparmor: - Port to rake (12 days) https://github.com/yast/yast-apparmor/pull/40 Pending requests … [View More]

1 0

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

26 Jun '19

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-add-on: - Unify labels (bsc#1123679) (106 days) https://github.com/yast/yast-add-on/pull/69 Pending requests in repository yast-apparmor: - Port to rake (11 days) https://github.com/yast/yast-apparmor/pull/40 Pending requests … [View More]

1 0

[yast-devel] YaST: highlights of development sprint 71 and 72
by Ancor Gonzalez Sosa 25 Jun '19

25 Jun '19

May and June have been, so far, interesting months for the YaST Team. Many things happening... which had the drawback of keeping us too busy to publish our usual sprint reports. But we are back with a looong report trying to summarize the latest three development sprints, namely the 77th, 78th and 79th. So take a cup of your favorite drink and dive into... https://lizards.opensuse.org/2019/06/25/yast-sprints-77-79/ As special bonus, it includes a link to the our recent blog post titled "… [View More]

1 1

Main

Development

Information

Community

Social Media

Other

YaST Development