Hi all,
Recently, a bug report [1] was filed because translation updates are
taken quite long to reach the product. It seems that it took almost 1
year and 4 months to get an updated yast2-trans package into Leap 15.2.
Do you know the source of the problem? Could we do anything to improve it?
Thanks!
[1] https://bugzilla.suse.com/show_bug.cgi?id=1172874
--
José Iván López González
YaST Team at SUSE LINUX GmbH
IRC: jilopez
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
the YaST team has the idea to make some storage tasks simpler to
use by introducing storage wizards.
Attached are the first brain storming results. Feedback is
wanted.
ciao
Arvin
--
Arvin Schnell, <aschnell(a)suse.com>
Senior Software Engineer, Research & Development
SUSE Software Solutions Germany GmbH
Maxfeldstraße 5
90409 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Hi all,
Most likely you already know about our crazy bug in the Tumbleweed
installer that was reported some weeks ago [1].
Basically, the problem was raised because a same ruby file was "loaded"
twice after requiring it for second time. Obviously this should not
happen because Kernel#require method prevents that [2]. As the
documentation states: "The absolute path of the loaded file is added to
$LOADED_FEATURES. A file will not be loaded again if its path already
appears in $LOADED_FEATURES".
So, why is a file loaded twice in YaST?
TL;DR: because ruby2.7 has a bug when requiring files from symlinks.
In general, ruby expands the absolute path of a loaded file by following
the symlink, so the $LOAD_FEATURES would contain the path of the real
file instead of the symlink path. For example:
# There is a symlink like
#
# /usr/share/foo --> /mnt/foo
$LOAD_PATH.append("/usr/share/foo/lib")
require "foobar"
$LOADED_FEATURES.grep(/foobar/) # => "/mnt/foo/lib/foobar.rb"
But there is a corner case in ruby2.7. Ruby tracks the file by using the
symlink path when:
* a new directory is added to the beginning of $LOAD_PATH and
* any parent of the added directory is a symbolic link.
# There is a symlink like
#
# /usr/share/foo --> /mnt/foo
$LOAD_PATH.append("/usr/share/foo/lib")
require "foobar"
$LOADED_FEATURES.grep(/foobar/) # => "/mnt/foo/lib/foobar.rb"
But:
$LOAD_PATH.prepend("/usr/share/foo/lib")
require "foobar"
$LOADED_FEATURES.grep(/foobar/) # => "/usr/share/foo/lib/foobar.rb"
Note the difference of the $LOADED_FEATURES when the path is added at
the beginning of the list and at the end.
And also note that this does not happen when the new added load path is
a symlink itself:
# There is a symlink like
#
# /usr/share/foo/lib --> /mnt/foo/lib
$LOAD_PATH.append("/usr/share/foo/lib")
require "foobar"
$LOADED_FEATURES.grep(/foobar/) # => "/mnt/foo/lib/foobar.rb"
And:
$LOAD_PATH.prepend("/usr/share/foo/lib")
require "foobar"
$LOADED_FEATURES.grep(/foobar/) # => "/mnt/foo/lib/foobar.rb"
All this is very unexpected, and only happens in ruby2.7. This weird
behavior was making YaST to fail, see [3] for more details.
I have prepared an script to automatically reproduce this issue (see the
attached file). You can use it to see the difference with ruby2.7 and
previous versions.
Do you think this is actually a bug in ruby2.7? Or am I doing something
wrong? Should we report a bug?
For the time being, we have found a workaround to avoid the failure in
YaST side.
Regards,
Iván
[1] https://bugzilla.suse.com/show_bug.cgi?id=1172898
[2] https://apidock.com/ruby/Kernel/require
[3] https://bugzilla.opensuse.org/show_bug.cgi?id=1172898#c20
--
José Iván López González
YaST Team at SUSE LINUX GmbH
IRC: jilopez
I have documented the outcome of our recent meeting to come up with a
new concept for the UI of the Partitioner. See the result here:
https://github.com/yast/yast-storage-ng/blob/master/doc/partitioner_ui.md#a…
We will use that as a base for upcoming tasks in our development
sprints, but feel free to also use it as a base to bring new ideas we
may have overlooked during the meeting.
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 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
On Wed, 10 Jun 2020 20:32:25 -0600
"David Benjamin" <dbenjamin(a)ontario.k12.or.us> wrote:
> Thank you.
>
> So CWM is good? I thought I read it is being phased out.
>
> Thanks again,
> David.
Well, it is not perfect and we are experimenting how to have object UI without need to load and store values, but for now I think it is the best representation of the object based UI.
So we have two concepts there:
1. event based UI where you have defined how UI looks and event loop which react on user actions for whole dialog. Its advantage is that everything is together. Disadvantage is very low re-usability as it is all or nothing and often lead to just copy pasting of same code.
Example in more modern code is in yast2-journal - https://github.com/yast/yast-journal/blob/master/src/lib/y2journal/query_di…
2. widget based UI ( represented by object CWM ) which define each widget as object that itself handle user input on that widget. Its advantage is re-usability as you can you can just reuse widget that you need in different dialog. Disadvantage is that on dialog level you do not see immediatelly how it will react and need to check each widget.
Example is e.g. bootloader module - widgets at https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/grub… and dialog at https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/conf…
Sadly we do not have now the one best way how to write UI and sometime we suffer from it as those two concepts is not so easy to mix.
Josef
>
>
>
>
>
> >>> josef Reidinger <jreidinger(a)suse.cz> 06/10/20 4:29 PM >>>
> On Wed, 10 Jun 2020 12:21:06 -0600
> "David Benjamin" <dbenjamin(a)ontario.k12.or.us> wrote:
>
> > Hello everyone,
> >
> > I have data from a file that was parsed using CFA::AugeasParsser.
> >
> > Can it be used in a dialog without translating from CFA::AugeasTree it to Yast::Term.Tree?
>
> Hi David,
> sadly(?) it cannot be done. Usual work-flow is to have own model class that is child of CFA::BaseModel that provide access to variables you are interested ( as usually you do not want to present user everything in file to not overwhelm him ).
>
> This model is then used as backend and in frontend you use various terms to represent widgets. As beside parsing, config file values often have its semantic and you want to help user to fill it correct. So e.g. for variables that are on/off you want to use checkbox,
> if it is local path, you want input field with Browse button that allows to select file on system, or int field for integer values. Also often configuration files has dependent values, like if value A is true, then value A1 is used, but if it is false, it is ignored.
> You can represent it in frontend by event handling that disable widget for A1 if A is unselected.
>
> If you are interested in example code, just write and I can point you to some. ( also nowadays we use quite lot CWM widgets, which is object oriented way how to write widgets, so if you are interested, I can also point you to some examples and code ).
>
> >
> > Thanks,
> > David.
> >
>
> Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org