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
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]
indent_style = space
indent_size = 2
And here's the one from libstorage-ng, capturing the not-quite-trivial rules
of "the Tab key indents 4 columns, but compress 8 spaces into Tab characters"
# https://EditorConfig.org -*- ini -*-
# This is a unified way to tell all your editors
# about the proper indentation style in this repo.
#
# Emacs: https://github.com/editorconfig/editorconfig-emacs#readme
# Vim: https://github.com/editorconfig/editorconfig-vim#readme
# VS Code: https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConf…
# don't continue looking in upper directories, this is the top level
root = true
[*.{h,cc}]
indent_style = tab
indent_size = 4
tab_width = 8
I've added it to a couple of repos so far, where I needed it.
1. Should we improve these declarations? (Add
trim_trailing_whitespace[3], insert_final_newline)
2. Should we add a master copy to yast-devtools? (It would need to be copied
manually, but it would serve as the representation of the current best
practice)
[1]: https://en.wikipedia.org/wiki/Visual_Studio_Code
[2]: https://en.wikipedia.org/wiki/GNU_Emacs
[3]: https://github.com/yast/yast-packager/pull/441#discussion_r294163050
thanks to Lada for prompting this
--
Martin Vidner, YaST Team
http://en.opensuse.org/User:Mvidner
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 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
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-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
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
"Getting Further with Btrfs in YaST", in case you missed that announcement.
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