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
Douglas DeMaio asked if me or any other YaST developer was planning to
give a talk at openSUSE Summit Dublin[1]. I have to admit that was out
of my radar. That summit is a small event that takes place right after
SUSECON[2] in the same location, reusing part of its infrastructure. So
it sounds like a nice place to meet people who are both openSUSE
enthusiasts and SUSE customers.
To be honest, YaST had almost not presence In the latest openSUSE
Conference and that felt pretty wrong. Imo and me tried to fix that with
some lighting talks but, although they were well received locally, there
is no online record of those.
I'm not sure whether I will be personally able to attend, but I think
that at least one member of the YaST Team should be there presenting all
the new stuff that debuted in 15.1 (we can extend my lighting talk about
it) or what we are working on.
Being visible is one of our strategies, after all.
Cheers.
[1] https://events.opensuse.org/conferences/Dublin
[2] https://www.susecon.com/
--
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
I've gone through the full list of bugs assigned to the YaST Team or
some of its members with the intention of closing obsolete stuff that
are not real issues anymore.
In the process I found out there are some YaST modules or areas that
have quite some open bugs. Some of them are modules that never receive
attention (no-man shows, as HuHa likes to call them).
Localization bugs (mainly problems with non-latin languages):
22 open bugs
dns-server && dhcp-server (they are so related that even share bugs):
20 open bugs, aprox.
NTP: 13 open bugs
Bootloader: 20 open bugs, aprox.
NFS: 12 open bugs, I already plan to focus the firepower of the storage
squad here for the following sprint(s).
Storage: 30 open bugs, aprox. but they are under control ;-)
Network: hard to say, at least 50.
If reducing the number of bugs is a goal, I think it would be worth to
create small groups of 2-3 developers to focus on a given module for a
month or two. That would be enough time to gather the knowledge about
the topic and refactor the most important parts (those modules are
usually not that big). In some cases, that can mean up to 20 bugs solved
and a more sane codebase (plus some refreshed knowledge) for the future.
Let's assume two small refactoring squads (2-3 people each) working in
parallel. I think that, for example, DNS+DHCP+NFS+NTP could all be
brought into shape in less than two months. That would be around 45
fewer bug reports.
What do you think?
Cheers
PS.- Network is, of course, a completely different story. I hope we can
close many bugs as obsolete in something like two years from now, when
network-ng would had already replaced the current implementation.
--
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
The Problem of the Day
======================
In the last few days we were reviewing and merging Rodion's changes to the
libyui packages for the REST API and better testability.
The Recurring Problem
=====================
We found out (again) that it's a very painful and error-prone process to get
a green build from Travis and to submit all those libyui packages; the
library SO version had to be bumped from 10 to 11 to ensure binary
compatibility, so Rodion had to touch every single one of all those libyui
packages and create pull requests for each one:
- libyui
- libyui-rest-api
- libyui-qt
- libyui-qt-rest-api
- libyui-qt-pkg
- libyui-graph
- libyui-ncurses
- libyui-ncurses-rest-api
- libyui-ncurses-pkg
...and later even the externally maintained ones:
- libyui-gtk
- libyui-gtk-pkg
- ... (?)
The Annoyance
=============
This is error-prone and tedious; there were build problems in the in-between
stages all the time, and they are not easy to resolve, and we had one pretty
unhappy Dimstar who saw failing things all around him.
Only for the very first of those PRs there is a realistic chance for a green
Travis build; for all subsequent ones, there is only the (now outdated)
docker image that also includes those libyui packages. That image needs to be
rebuilt, but that fails because now there is a libyui with a higher SO
number, but no matching libyui-something packages.
The Pragmatic Brute-Force Fix
=============================
So the only way out is to brute-force merge despite red Travis and hope for
the best. And to do this a couple of times until it gets green in Jenkins and
in OBS.
This is a mess. There must be a better way; a way without very unhappy
release managers that are confronted with half-ready UI stuff that breaks all
kinds of other packages.
The Future
==========
So, what can we do?
Is it really a wise idea to have all those UI packages fragmented into so
many different source repositories?
Unify the Fragments?
=====================
Would it be better to have one large libyui repo that contains the base
libyui, and also most of the others (except libyui-gtk* ?) and create all the
binary packages that we have now from that single source repo?
That would give us a chance to do atomic changes; a transaction with a
well-defined "before" and "after" state and no in-between mess.
We'd have ONE pull request for all the different subpackages. We could review
that as a whole and not get into a PR frenzy when things need to happen
quickly to avoid undefined in-between states.
Of course we could still work separately in the different UI parts (Qt,
NCurses) with different people. We could still do PRs for those parts
separately if we want to.
But we could (and should) have one central place where things like the UI so
number is defined. Not sure, but maybe we should also have one single
consistent package version number for all the subpackages (libyui, libyui-qt,
libyui-ncurses, ...).
What do you think?
Does anybody have a better idea?
Or is there some killer argument against this?
Kind regards
--
Stefan Hundhammer <shundhammer(a)suse.de>
YaST Developer
SUSE Software Solutions Germany GmbH
Geschäftsführer: Felix Imendörffer HRB 36809 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
The YaST Team is about to enter hibernation mode for a couple of weeks.
But before that, let’s take a look to the most important features and
bugfixes we implemented in the last sprint of 2019. That includes:
- bringing back to life some sections of the Software Manager,
- implementing system upgrade with the new SLE media types,
- making the installation in Raspberry Pi and IBM Z System even better,
- improving usability of encryption,
- reducing the footprint of the Snapper plugin for ZYpp,
- and, as always, many other small improvements and fixes.
Check the whole report at:
https://lizards.opensuse.org/2019/12/18/yast-sprint-91/
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
Hi guys,
I just would like to inform you about interesting tool. Today I want to answer some email about yast and need to know what is current state of LOC of YaST. So I do a bit search as output of find and wc -l was not enough for me.
And found interesting tool cloc[1]. I install it with npm method with `sudo npm install -g cloc`. And how looks output now for yast (my own checkout without snapper, libstorage-ng and some others)? like this ( sorry for broken formating, but email are not perfect for ascii output ). I expect many HTML is generated doc, btw our biggest ruby file is [2]:
jreidinger@linux-vvcf:~/prace/yast> cloc .
16111 text files.
14565 unique files.
5948 files ignored.
github.com/AlDanial/cloc v 1.85 T=20.84 s (515.5 files/s, 132408.6 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
HTML 1628 468135 1247 705188
Ruby 4281 104886 150083 573752
C++ 726 40778 31679 143555
XML 359 3236 5807 97274
Python 280 3174 2397 61881
Perl 188 10166 7772 45276
YAML 676 2259 1381 40101
Markdown 361 10707 1 34282
C/C++ Header 640 18259 38038 30950
JSON 9 0 0 24797
SVG 281 76 170 14525
Sass 100 1595 1889 8431
C 31 1261 474 6648
TeX 59 1575 85 6423
make 360 2520 1825 6372
CMake 140 769 631 4332
diff 96 933 3028 4257
Bourne Again Shell 68 830 2009 4252
XSLT 21 569 531 3922
CSS 17 546 302 3785
JavaScript 65 504 382 3658
Bourne Shell 192 808 1232 2910
SWIG 24 288 169 1647
Cucumber 18 159 13 1254
Expect 52 504 440 1218
Qt 5 0 0 1077
Lisp 4 49 56 412
vim script 2 31 36 381
Dockerfile 47 47 24 290
ERB 7 31 20 173
m4 2 26 7 117
XSD 1 0 0 95
Tcl/Tk 1 22 32 57
PO File 2 5 16 40
Clojure 1 4 0 9
--------------------------------------------------------------------------------
SUM: 10744 674752 251776 1833341
--------------------------------------------------------------------------------
[1] https://github.com/AlDanial/cloc
[2] https://github.com/yast/yast-ycp-ui-bindings/blob/master/examples/Tree-recu…
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org