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
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,
please add the new YaST package yast2-usbauth from
https://github.com/kochstefan/yast-usbauth or
https://build.opensuse.org/package/show/home:kochstefan/yast2-usbauth to
openSUSE Tumbleweed.
This work was initially created for SUSE in 2015. Part of it was the USB
interface authorization for the Linux kernel. It's contained in Linux
since kernel version 4.4. The packages libusbauth-configparser, usbauth
and usbauth-notifier are already part of openSUSE Tumbleweed.
packages from the usbauth development:
- libusbauth-configparser is a library that is used to parse the usbauth
config file.
- usbauth is a firewall against BadUSB attacks. It allows/denies USB
interfaces using a config file. The needed USB interface authorization
is part of Linux 4.4 and newer.
- usbauth-notifier is a graphical notifier for user interaction to allow
or deny USB devices.
- yast2-usbauth: is a YaST module to edit the usbauth configuration file
Thank you.
Best regards
Stefan Koch
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi all,
Short version:
Install the latest ruby2.5-rubygem-parallel_tests ruby2.5-rubygem-parallel_tests
packages from YaST:Head OBS and enjoy lightning fast "rake test:unit"
in yast2-storage-ng :-)
(The "devel_yast" pattern has been adapted, running "zypper dup" should be enough.)
Long version:
I have spent some time speeding up the unit tests in yast2-storage-ng package. The
reason was that running all tests took several minutes, about 3 minutes even on
a quite fast CPU. So after doing even a small change you would have to wait
several minutes to see whether you did not break something by mistake.
The main bottleneck was the sequential start of the tests, so even on a quad core CPU
only one CPU was actually used.
I have added parallel_test gem [1] support to "rake test:unit" and turned that
on in yast2-storage-ng package. (By default the standard sequential RSpec is used.)
It uses all available CPUs and scales almost linearly, the speed up is about
`nproc` times.
A similar approach I have used in Travis, originally we used license check, Rubocop,
yardoc, unit tests, package build, ... everything sequentially in one Travis job.
Fortunately Travis supports defining multiple jobs which run independently and are
started in parallel.
I have split the Travis work in yast2-storage-ng into three groups: unit tests,
rubocop and the rest (yardoc, package build...).
If you want to use a similar solution in your package then check the documentation
I wrote about this: the Travis [2], the unit tests [3].
Some real numbers to see the improvement:
- Running "rake test:unit" locally: from 2:47s to 0:38s (speedup ~4.3x on a quad
core CPU with HT on)
- Similar speed up in "rake osc:build" (it just additionally prepares the chroot)
- OBS package build: from 323s-505s to 102s-235s
(checked several builds, it highly depends on the speed of the worker)
- Travis speed up: from 8-10 minutes to 3-4 minutes (parallel jobs + parallel tests)
Enjoy!
[1] https://github.com/grosser/parallel_tests
[2] http://yastgithubio.readthedocs.io/en/latest/travis-integration/#parallel-b…
[3] http://yastgithubio.readthedocs.io/en/latest/how-to-write-tests/#parallel-t…
--
Best Regards
Ladislav Slezák
Yast Developer
------------------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: lslezak(a)suse.cz
Lihovarská 1060/12 tel: +420 284 028 960
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi all,
I am Joaquín and I am working on a rewrite of YaST keyboard module, info
here [1]. In a nutshell, I am writing a keyboard module for YaST with
ruby using OOD, with an implementation for SystemD.
Right now i am looking to map the code of every keyboard layout (for
example: us, es, us-dvorak) with their human readable translation (
“English (US)”, “Spanish”,...), but i have some questions about it.
I have taken a look to the existing code to try to use the same
translations. And i found two files, “keyboard_raw_opensuse.ycp” and
“keyboard_raw.ycp”. Also i found the part of the code that is using one
of these two files [2]. The only difference between these files i see,
is that in some cases, for a language one file uses a .map.gz file and
the other use a different .map.gz, for example with “spanish-lat” see
[3] and [4].
I think that with only one map for each code is enough for an
implementation with SystemD but i am not sure, because I don’t
understand the reason of these differences in the current module. It
would be nice if some of you can explain to me so i can understand it,
and apply a good solution in the project.
Also in the case that is only needed one mapping, which of those files
should i take as reference?
Thank you all,
Joaquín
[1] https://github.com/openSUSE/mentoring/issues/79
[2]
https://github.com/yast/yast-country/blob/master/keyboard/src/modules/Keybo…
[3]https://github.com/yast/yast-country/blob/master/keyboard/src/data/keyboa…
[4]https://github.com/yast/yast-country/blob/master/keyboard/src/data/keyboa…
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hello,
In order to allow to reuse our language-related database, I wonder why
we still have data partially in YCP, while some has been converted to
YML. Listing /usr/share/YaST2/data shows the mix.
Since converting a file as a one-shot task is a few lines of ruby code,
I wonder: should we do that for SP1?
One possible obstacle I could see are translations - we have them in
/usr/share/YaST2/data/languages/*
Thanks for your view,
Jiri
--
Regards,
Jiri Srain
Project Manager
---------------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: jsrain(a)suse.com
Krizikova 148/34 tel: +420 284 084 659
186 00 Praha 8 fax: +420 284 084 001
Czech Republic http://www.suse.com
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org