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
I've found a way to prevent the crash, although I don't completely
understand why (or if this is correct).
If I initialize the UI like this prior to calling the Wizard via symbol
table lookups, etc (CallYCPFunction in the old python bindings):
YUILoader::loadUI();
init_ui(YSettings::loadedUI());
Then I see no crashes or gui artifacts during run, so stack corruption
seems resolved (init_ui() is same as from old python bindings).
Also, if I tear down YUIComponent when the python program completes (so,
prior to the ruby code tearing it down), then I don't see the crash at
shutdown, like this:
YUIComponent *c = YUIComponent::uiComponent();
if (c)
c->result(YCPVoid());
I noticed after loading the UI using YUILoader, that at shutdown I got a
segfault in ui_finalizer() (within ruby bindings Yast.cc). It appears
that the singleton still holds a pointer, but the pointer is invalid (so
it is not null, but the pointer is now invalid). Making that call early
resolves the crash.
On 10/09/2017 09:22 AM, David Mulder wrote:
> If you install my python bindings, it's easy to reproduce.
>
> To install the bindings, first install these dependencies:
> yast2-ycp-ui-bindings
> autoconf-archive
> swig
> yast2-core-devel
>
> Clone the repo:
> git clone https://github.com/dmulder/yast-python-bindings2.git
>
> Build/install:
> cd yast-python-bindings2
> autoreconf -if
> ./configure
> make && sudo make install
>
> Then you'll need to add libpy2UI to your path:
> LD_LIBRARY_PATH=$LD_LIBRARY_PATHPATH:/usr/lib64/YaST2/plugin
>
> Then to reproduce the failure, run `python` to open the interpreter, and
> run:
>
> import yast
> yast.init_ui('ncurses')
> yast.Wizard.CreateDialog()
> yast.UI.CloseDialog()
>
> It segfaults and generates a core dump.
>
> On 10/09/2017 09:08 AM, Josef Reidinger wrote:
>> V Mon, 9 Oct 2017 08:54:35 -0600
>> David Mulder <dmulder(a)suse.com> napsáno:
>>
>>>> Problem is that you do not use Yast component system. In general all
>>>> yast modules is attached to component system and you can call it
>>>> with it. Old python bindings implement it properly with
>>>>
>>>> https://github.com/yast/yast-python-bindings/blob/master/src/YCP.cc
>>> I added in use of the yast component system, for calling into the
>>> Wizard class in the ruby code (branch ruby_bind on the same project).
>>> This works, but there is now blatant stack corruption (crashing, UI
>>> artifacts, etc).
>>> Here is the crash at shutdown:
>>>
>>> #0 0x00007f7a704ad855 in ?? () from /usr/lib64/libruby2.2.so.2.2
>>> #1 0x00007f7a70389c4b in ?? () from /usr/lib64/libruby2.2.so.2.2
>>> #2 0x00007f7a7044029e in ?? () from /usr/lib64/libruby2.2.so.2.2
>>> #3 <signal handler called>
>>> #4 0x0000000000000000 in ?? ()
>>> #5 0x00007f7a732e3643 in YUIComponent::result(YCPValue const&) ()
>>> from /usr/lib64/YaST2/plugin/libpy2UI.so.2
>> This crash looks like somewhere in ycp-ui-bindings. It looks like null
>> pointer access. we probably need exact location in where in result it
>> failed. Can you add there some trivial example of such crash so I can
>> try it myself with all debug packages?
>>
>> Josef
>>
>>> #6 0x00007f7a6c58b4f0 in ?? () from
>>> /usr/lib64/ruby/vendor_ruby/2.2.0/x86_64-linux-gnu/yastx.so
>>> #7 0x00007f7a70496b4d in ?? () from /usr/lib64/libruby2.2.so.2.2
>>> #8 0x00007f7a704a78ce in ?? () from /usr/lib64/libruby2.2.so.2.2
>>> #9 0x00007f7a7049b3eb in ?? () from /usr/lib64/libruby2.2.so.2.2
>>> #10 0x00007f7a704a1224 in ?? () from /usr/lib64/libruby2.2.so.2.2
>>> #11 0x00007f7a704a5ffc in ?? () from /usr/lib64/libruby2.2.so.2.2
>>> #12 0x00007f7a704a6323 in ?? () from /usr/lib64/libruby2.2.so.2.2
>>> #13 0x00007f7a704a63f8 in ?? () from /usr/lib64/libruby2.2.so.2.2
>>> #14 0x00007f7a7039573c in ?? () from /usr/lib64/libruby2.2.so.2.2
>>> #15 0x00007f7a704a27e3 in ?? () from /usr/lib64/libruby2.2.so.2.2
>>> #16 0x00007f7a704a3a92 in ?? () from /usr/lib64/libruby2.2.so.2.2
>>> #17 0x00007f7a704a8bf0 in rb_eval_cmd ()
>>> from /usr/lib64/libruby2.2.so.2.2 #18 0x00007f7a703a0003 in ?? ()
>>> from /usr/lib64/libruby2.2.so.2.2 #19 0x00007f7a7038f55d in
>>> rb_protect () from /usr/lib64/libruby2.2.so.2.2 #20
>>> 0x00007f7a703a1376 in ?? () from /usr/lib64/libruby2.2.so.2.2 #21
>>> 0x00007f7a703ab3d4 in rb_gc_call_finalizer_at_exit ()
>>> from /usr/lib64/libruby2.2.so.2.2 #22 0x00007f7a709bb80d in
>>> YRuby::~YRuby() () from /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
>>> #23 0x00007f7a709bb8ee in YRuby::destroy() () from
>>> /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
>>> #24 0x00007f7a709b66cd in Y2RubyComponent::~Y2RubyComponent() ()
>>> from /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
>>> #25 0x00007f7a709b67c9 in Y2RubyComponent::~Y2RubyComponent() ()
>>> from /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
>>> #26 0x00007f7a709b5aa1 in Y2CCRuby::~Y2CCRuby() () from
>>> /usr/lib64/YaST2/plugin/libpy2lang_ruby.so
>>> #27 0x00007f7a84b4e638 in __run_exit_handlers () from /lib64/libc.so.6
>>> #28 0x00007f7a84b4e68a in exit () from /lib64/libc.so.6
>>> #29 0x00007f7a84b37471 in __libc_start_main () from /lib64/libc.so.6
>>> #30 0x000055950bf6c7fa in _start ()
>>>
>>> Any thoughts?
>>>> which adds to python ability to call rest of component system.
>>>> import is finding module like
>>>>
>>>> https://github.com/yast/yast-python-bindings/blob/master/src/YCP.cc#L107
>>>>
>>>> and call it with
>>>>
>>>> https://github.com/yast/yast-python-bindings/blob/master/src/YCP.cc#L1238
>>>>
>>>> so to call UI methods you need to import module "UI" and then with
>>>> that call use method you want from UI namespace.
>>>>
>>>>
>>>>>> 2. yast.py is basically reimplementation of yast stuff in python.
>>>>>> I am not sure if it is right way, as anything you will need you
>>>>>> have to reimplement
>>>>> Yes, the yast.py code is wrong. I'm trying to think of a good way
>>>>> to use the ruby Wizard code, etc. You mention there is a way to be
>>>>> able to call functions between yast modules?
>>>> yes, as I describe above.
>>>>
>>>>>> 3. your modules is not possible to call from rest of YaST. For
>>>>>> ycp, perl and ruby it is possible to call it from each other.
>>>>>>
>>>>>> So in short. Your approach is more like wrapper for c++ parts
>>>>>> ( currently only UI ) and rewrite for rest.
>>>>>>
>>>>>> In general if you need only UI from YaST, then I suggest to use
>>>>>> direct approach and use libyui python bindings -
>>>>>> https://github.com/libyui/libyui-bindings . But as I said this
>>>>>> approach prevent you to use any part written in ruby and also rest
>>>>>> of YaST cannot call your methods.
>>>>>>
>>>>>> It miss some layer from ycp-ui-bindings, but provide all needed to
>>>>>> build UI.
>>>>>>
>>>>>> Josef
>>>>>>
--
David Mulder
SUSE Labs Software Engineer - Samba
dmulder(a)suse.com
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
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:
- [WIP] Ask when the added repository is unsigned (bsc#1009127) (265 days)
https://github.com/yast/yast-add-on/pull/37
Pending requests in repository yast-bootloader:
- don't create grub_installdevice and let perl-Bootloader run grub2-install (209 days)
https://github.com/yast/yast-bootloader/pull/413
Pending requests in repository yast-installation:
- Disable plymouth by a no affend method, it will not block tty device activation at first time user login(bsc#1042554). (70 days)
https://github.com/yast/yast-installation/pull/584
Pending requests in repository yast-ldap:
- Manipulate system LDAP configuration rather than application LDAP configuration (209 days)
https://github.com/yast/yast-ldap/pull/26
Pending requests in repository yast-live-installer:
- - Use /etc/products.d/openSUSE.prod as /etc/products.d/baseproduct (138 days)
https://github.com/yast/yast-live-installer/pull/14
Pending requests in repository yast-mail:
- [WIP] return back MailTable to yast2-mail module from yast2 module (208 days)
https://github.com/yast/yast-mail/pull/25
Pending requests in repository yast-multipath:
- fix ycp killing bug with changing \r with space (126 days)
https://github.com/yast/yast-multipath/pull/19
Pending requests in repository yast-network:
- routing/firewall: no longer depend on SuSEfirewall2 for IPv4 forwarding (181 days)
https://github.com/yast/yast-network/pull/503
Pending requests in repository yast-packager:
- Remove xinetd from the list of VNC packages. (35 days)
https://github.com/yast/yast-packager/pull/286
- [WIP] Ask when the added repository is unsigned (bsc#1009127) (264 days)
https://github.com/yast/yast-packager/pull/230
Pending requests in repository yast-security:
- [WIP] refactoring autoconverted ruby code into ruby code (201 days)
https://github.com/yast/yast-security/pull/40
Pending requests in repository yast-storage:
- fixed missing changes (32 days)
https://github.com/yast/yast-storage/pull/292
- Bsc 1049108 sle12 sp3 (102 days)
https://github.com/yast/yast-storage/pull/283
Pending requests in repository yast-users:
- Reduce perl (209 days)
https://github.com/yast/yast-users/pull/137
ERROR: API query limit exceeded
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
ruby 2.5 is behind doors and here is a blog post about the most interesting changes there:
https://blog.jetbrains.com/ruby/2017/10/10-new-features-in-ruby-2-5/
Enjoy it,
Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Just for the wishlist or for the list of low hanging fruit -
when you install from a local repository, it would be really cool to
have the URLs of "Online Repositories" adjusted to point there too.
For instance,
I install from "opensuse.local.hbrz2", but the online repos remain
pointing to download.o.o.
I looked at this before YaST got converted to Ruby, and it seemed easy
to add a "base" url for the repos/.
Maybe availabillity of a repo could quickly be checked in the
background?
Thanks for maybe considering this
Per
--
Per Jessen, Zürich (10.2°C)
http://www.hostsuisse.com/ - dedicated server rental in Switzerland.
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
On 13.06.2017 13:14, Suresh K Hosamani wrote:
> Conclusion is, nothing can be done from yast install code or controls.xml to change the default root partition type from brtfs to ext3, only option left is to document it, saying for OES root partition needs to be created manaully with ext3 type.
I just checked again in the code where that Btrfs default comes from, and it
looks like it is ultimately read from /etc/sysconfig/storage :
...
...
## Type: string(ext2,ext3,ext4,xfs,btrfs)
# Default filesystem type.
DEFAULT_FS="btrfs"
...
This file exists in the inst-sys, too, so it might be possible to replace
this file with a driver update disk (DUD). If that works, you could integrate
that DUD into the ISO you ship as the base for your OES product.
Let me check that.
Kind regards
--
Stefan Hundhammer <shundhammer(a)suse.de>
YaST Developer
SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (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
Hi all,
We just released another report of YaST latest development sprint,
which keeps focused on the development the upcoming SUSE Linux
Enterprise (SLE) 15 products family and openSUSE Leap 15, with new
dialogs and system adaptations that these new products required.
https://lizards.opensuse.org/2017/10/25/highlights-of-yast-development-
sprint-45/
Enjoy it!
BRs,
Gilson
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
