I want to fix yast2-slide-show for SLE11 SP3. Which git commands do I
have to use, please?
Thus far, I have checked out trunk only.
--
Karl Eichwalder SUSE LINUX Products GmbH
R&D / Documentation Maxfeldstraße 5
90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (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
Hi,
Last week, I've decided to start a pilot project: YaST Runlevel written
completely in Ruby. I've just got it to the state when I dare to publish
it :) Please try...
See the project here: https://github.com/kobliha/yast-runlevel-ruby
How to run
sudo cp src/runlevel-ruby.rb /usr/share/YaST2/clients/
sudo yast2 runlevel-ruby
Right now, it
- lists services you can modify (enabled or disabled)
- shows their current state
- offers to start/stop or disable/enable them
- can save the current configuration
What is missing
- dependencies: install yast2.rpm from YaST:Head:ruby at
build.opensuse.org
- whole packaging into RPM/Gem
- setting the default target (default runlevel)
Comments and patches are welcomed! :) It was really easy to write such
YaST module in Ruby. I'll blog about it later.
Bye
Lukas
--
Lukas Ocilka, Cloud & Systems Management Department
SUSE LINUX s.r.o., Praha
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
in the YCP Killer project we are currently working on transferring
comments from YCP to Ruby. One part of that work is transferring
documentation comments. This brings up the question of what
documentation tool we want to use for YaST code in Ruby in general.
There are two main contenders:
* RDoc [1]
* YARD [2]
RDoc is a used since the very early days of Ruby. It is well known and
its is somewhat a standard tool.
YARD is a newer, backward compatible with RDoc, but with more
capabilities. It generates nicer documentation and its syntax is more
similar to the current YaST one (it uses @tags). It can use widespread
markup languages (like Markdown) instead of inventing its own wiki-style
markup (like RDoc). It is extensible and it allows quick development by
running a local server and seeing changes instantly (you just run "yard
server --reload" and edit your files).
The killer feature of YARD is however the RubyDoc server [3]. There you
can find documentation to many Ruby-based projects. You can add your own
easily (which basically gives you a documentation hosting for free on a
place expected by Ruby community). One great future is integration with
GitHub, so you can see documentation of the development version of your
project online immediately.
Because of all these features, most new Ruby projects choose YARD as
their code documentation tool.
From the above, I guess it's obvious that I would like Ruby code in
YaST to use YARD too. Do you agree with that, or do you have any better
ideas?
[1] http://rdoc.sourceforge.net/
[2] http://yardoc.org/
[3] http://rubydoc.info/
--
David Majda
SUSE Studio developer
http://susestudio.com/
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
I would like to discuss one think that is related to creating UI in
YaST in ruby. In YCP it uses terms. In ruby generic terms looks like:
term(:VBox,...)
but it is not much nice for me, so I create few shortcuts for known UI
elements and it looks like this:
VBox(...)
There is a problem. In UI is often used terms `id and `opts, but it
doesn't start with uppercase and there is high chance to collide with
existing methods ( beside id collide with ruby id method ). So I
propose to translate it to
ID(:id) and OPTS(:strechable,:notify)
alternative can be Opts and Id.
what is your opinion?
Thanks
Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
I've just finished a simple WYSIWYG Editor for YCP to Ruby translation
requested by David. Editor is still quite dumb:
- It can translate only one file (well, of course)
- You can't define path to y2r yet (will come tomorrow)
How to install and use it should be in README. See
https://github.com/kobliha/y2r-tools/
Fork, clone, enhance! :)
Bye
Lukas
--
Lukas Ocilka, Cloud & Systems Management Department
SUSE LINUX s.r.o., Praha
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
As already announced last week, I've created a pure Ruby module as a
replacement for YaST Runlevel called YaST Services Manager. For a pure
Ruby module, I wanted to use a pure Ruby testing.
See the example here
https://github.com/kobliha/yast-services-manager/blob/master/test/unit/syst…
Now we don't need to define a full SCR hash but we can simply mock the
the returning values on-the-fly. Any function or method can be mocked
and they can return different object/values in different states (1st
call, 2nd call, 3rd call...).
What we can mock with mocha can be found here:
http://jamesmead.org/blog/2006-09-01-mocha-quickstart
Of course, you can do even more. If you are interested, fork the
yast-services-manager project and try to create your own testsuite (then
make a pull request). For instance, you can test Starting and Enabling
services. It's easy, it's fun! :)
Thanks and Bye
Lukas
--
Lukas Ocilka, Cloud & Systems Management Department
SUSE LINUX s.r.o., Praha
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
As I've been implementing new module written in Ruby only
(https://github.com/kobliha/yast-services-manager), I've found out I
actually can't use many generic libraries because they access the system
directly omitting SCR.
SCR is a layer that basically allows us to read and write configuration
and call commands independently on the fact whether it is bound to
current or chrooted system. SCR has the knowledge about the current
target built-inside and it can switch targets on-the-fly. This is
especially needed for installation. There are some want-to-haves:
- Installed system as small as possible (no YaST installed at all)
- Using as much upstream (Ruby) libraries as possible
- We must not take care about the target path itself, that can be set
or changed by installer almost anywhere
Do you have any idea how we could achieve that with the new YaST? I'd
like to have something like:
SCR.Run do
<ruby code>
end
Any ideas how to implement this?
Thanks in advance
Lukas
--
Lukas Ocilka, Cloud & Systems Management Department
SUSE LINUX s.r.o., Praha
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
I see that ruby bindings have multiple source files. Probably there is
problem with not cleaning package directory in build subdirectory for
cmake. Is possible to fix it?
https://build.opensuse.org/package/show?package=yast2-ruby-bindings&project…
Thanks
Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org
Hi,
I have cloned the latest source from the snapper git repo recently and
use it to create and manage snapshots on thin volume created by
dm-thin modules. Everything works perfectly until I want to allow
users of group "Domain/Backup Operators" to create snapshot on this
thin volume. I cannot set the ALLOW_GROUP parameter in the snapper
config file to "Domain/Backup Operators", since snapper takes space as
the separator between groups. Therefore, "Domain/Backup Operators"
will be processed as two separate groups "Domain/Backup" and
"Operators". Is it possible to allow such group in snapper config
file?
Any help would be grateful.
Dennis
--
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org