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 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
Hi,
TLDR: Travis/Github Actions are broken right now, ignore the failures :-/
The Tumbleweed distro upgraded Glibc to version 2.33. This uses a new syscall
(faccessat2) which requires a newer kernel (5.8+) and some support in Docker.
Unfortunately these are not present in the Ubuntu workers running at GitHub
or Travis so the result is many EPERM exceptions or not found file errors.
The bad part is that we cannot do much about it :-(
Either TW disables that syscall or Github/Travis upgrades the workers to support that.
The only workaround would be to use the Leap 15.3 as the base distro for CI.
So far there should not big differences so that should work fine, at least for some
time. We could use it until the issue is resolved, later we can switch back to TW.
BTW the same problem also happens in other distros and in other systems (even WSL has
been reported). This clearly shows the disadvantage of containers. Even if we bundle
our complete openSUSE user space stack (down to glibc) we still rely on the host
kernel (Ubuntu in this case) and this might cause some incompatibilities... :-/
Some links:
https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/…https://github.com/microsoft/WSL/issues/6562https://docs.docker.com/engine/release-notes/#security-1
--
Ladislav Slezák
YaST Developer
SUSE LINUX, s.r.o.
Corso IIa
Křižíkova 148/34
18600 Praha 8
As likely everybody in this list knows, we changed the user interface of
the Partitioner because it was impossible to add more functionality to
the previous havoc of (dis)appearing menu-buttons.
The changes were summarized in the description of this pull request that
was then linked in our usual blog posts:
https://github.com/yast/yast-storage-ng/pull/1157
The point is that we are getting quite some bug reports from people who
didn't expect the change and who cannot find their way through the new
UI. That includes people claiming the Partitioner is not longer
displaying the partitions (because they are now nested in the tables
within their corresponding disk) or claiming than a given options has
disappeared (because it has been moved to the new menu).
That opens a question - what can we do to prevent our users to get lost
in the new UI? For me, that actually splits in two questions:
1) What can we adjust in the UI to make the transition smoother and/or
to improve usability in general?
2) What can we do to communicate the change better to all possible users?
The Partitioner is not the only part of YaST under heavy revamping, so
whatever are the answers I expect them to be useful in general for YaST.
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Linux GmbH
I has been trying today to customize a bit the help dialog of the
Partitioner, which is based on CWM:Dialog, which is then based on the
ubiquitous Yast::Wizard.
I'm collecting my findings here so other with more knowledge can point
where I'm wrong. So take all this with a grain of salt, is meant for
corrections.
TL;DR
The only reasonable option of having a good control on how the help
pop-up behaves in a Yast::Wizard is defining from scratch all the wizard
buttons like it's done here:
https://github.com/yast/yast-services-manager/blob/b00e038670d2381ac38bb726…
Now, the longer version pulling the thread from the Partitioner and
CWM::Dialog.
By default, CWM::Dialog just calls Yast::Wizard.CreateDialog which
offers zero possibilities regarding how to customize the behavior of the
help button.
The standard help button provided by most kinds of Wizard-based dialogs
opens a pop-up whose shape and behavior is defined by the QY2HelpDialog
class. That class comes straight from libyui. I didn't find any
reasonable mechanism to customize how QY2HelpDialog works (eg. adding
the possibility to do something if the user clicks in some hyperlink
within the help text).
In theory, one could use Yast::Wizard.OpenCustomDialog instead of
CreateDialog. But that functionality is currently broken. Is based on
the existence of a replace point called "helpSpace" that is not present
in the Wizards anymore. Fun enough, the only remaining occurrence of
that replace point is in Yast::Wizard.GenericTreeDialog, another old
function that doesn't seem to be used anymore (the Wizard module is a
code cemetery).
That leaves us only with the option discussed on TL;DR, which implements
a custom button labeled "Help" that opens a simple regular pop-up to
display the help text (eg. no searching box). For that, it uses the
commodity method Yast::Wizard.ShowHelp, which does simply that - opening
a regular pop-up (not based on QY2HelpDialog) to display some text. That
ShowHelp method is not connected to the default mechanism of the
standard "Help" buttons. It's only executed if called explicitly and
only displays the passed text. It's used seldomly to create custom
additional "Help" buttons (eg. in a pop-up that is not really part of
the Wizard).
I was kind of tempted to test the Services Manager approach in order to
add limited hyperlinks support for the Partitioner help... but I'm not
convinced it's worth it.
Still, the investigation was interesting and I'm writing my findings
here for my future self.
Cheers.
--
Ancor González Sosa
YaST Team at SUSE Software Solutions
Hi,
after quite long playing with achieving layout[1] I decide to write down what I found.
Short Version
-------------
To get nice box centered at middle of screen, but content in box left aligned use
HBox(
HStretch,
VBox(
VStretch,
Left(<content>),
VStretch
),
HStretch
)
Long Version
------------
It start with feature to adapt theme and our designed team found some strange alignment that they want to change in dialog layout.
So I start with trivial idea to have something like `Center(VBox(Left(*content)))` This sadly does not work as it in
the end create box over whole place and everything is ugly on left side. which looks strange ( see screenshots in [1]).
So next attempt with a bit of help is MarginBox. It looks fine and is shrinkable, so even on very small screen in ncurses
looks fine, but in qt it is hard to pick good sizes as with different resolutions it is never on center for all resolutions.
So good to make some spacing, but not to align box.
The proper solution is to use that stretches around that create spacing around box that is proportional and content in Box
then can left alignment with proper position.
Pro tip: If you do not want center but e.g. in one third, it is possible to use Weight to stretch. See documentation at [2]
Josef
[1] https://github.com/yast/yast-registration/pull/519
[2] https://yast-ui-bindings.surge.sh/classYWeight.html