August 2013 - YaST Development - openSUSE Mailing Lists

[yast-devel] Some YaST Packages Will Be Out of Maintenance Soon
by Lukas Ocilka 08 Aug '13

08 Aug '13

Hi, We'd like to stop maintaining some of the old YaST packages in both openSUSE and SLE in the near future because there are more important tasks we should focus on. This means that the current YaST Team will not take care of them anymore: add features, fix bugs, submit to Factory, etc. We have a few options what we could do depending on the fact whether the openSUSE community wants to keep them: - Remove from GitHub completely (not a good option) - Delete all files from master branch and add README that would state that $this package is free for taking over - Move to openSUSE project and add some README without removing files from the master branch, and also removing from openSUSE - Offer these YaST modules to community at opensuse-factory In all cases, we should replace the current MAINTAINER with some generic (opensuse-factory?) mailing-list. Packages in question (examples) - yast2-phone-services - yast2-modem - yast2-x11 - yast2-mouse - yast2-irda - yast2-fingerprint-reader Let's discuss the possibilities and then let's decide which one is the best. Thanks 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

4 4

[yast-devel] YaST Ruby final conversion & integration - DONE
by David Majda 08 Aug '13

08 Aug '13

Hi, we are pleased to announce that the final Ruby conversion of YaST YCP code to Ruby is over. The converted source was committed to Git [1], passed through Jenkins and builds successfully in YaST:Head [2]. YaST version was increased to 3.0.0. We also sent submit requests to Factory (not accepted yet). ** YaST Git repositories are open for development again. ** Thanks everybody for patience and welcome to the new Ruby era :-) Technical Details ----------------- In all affected Git repositories, we used the following Git tags to mark the conversion: * good-bye-ycp -- last commit before the conversion * hello-ruby -- last commit of the conversion You can use them to see the changes the conversion did, e.g.: https://github.com/yast/yast-yast2/compare/good-bye-ycp...hello-ruby The amount of converted code is quite impressive: * 4204 files * 594680 lines of YCP deleted * 724687 lines of Ruby added Issues ------ There are few small issues that remain to be solved: * There were problems running tests on Jenkins for several packages. We solved them temporarily by fiddling with the test scripts, but we need to fix them more properly. Josef & Martin will look into that. Note the tests still pass correctly in when building in the OBS. * Module "iplb" is currently broken -- it wasn't converted, but its tests don't work after converting "testsuite" into Ruby. We need to clarify status of this module and fix it or drop it. Next Steps ---------- In the coming days and weeks, we would like to do the following: 1. Publish a document describing what the conversion changed (and how) and what remained the same. This will make starting with Ruby YaST easier for everybody who was not involved in the conversion. 2. Publish a document describing how to best handle YaST maintenance fixes in the old YCP code base which will need to be applied back to Ruby. 3. Decide on how exactly to do documentation and testing. 4. Update the skeleton that shows how to create a new YaST module to Ruby and describe the best practices. 5. Initiate a discussion about further changes and improvements in YaST architecture, which would allow us simplify it even more and make YaST even more attractive to contributors. [1] https://github.com/yast/ [2] https://build.opensuse.org/project/show/YaST:Head -- 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

8 12

[yast-devel] Results after upgrading yast to ruby-yast in 12.3
by Manu Gupta 08 Aug '13

08 Aug '13

Hey All I am using ruby-yast now, when I run yast from the terminal I get the following output linux-6gy3:~ # yast terminate called after throwing an instance of 'YUIPluginException' what(): Couldn't load plug-in ncurses YaST got signal 6 at YCP file /usr/share/YaST2/clients/menu.rb:193 /sbin/yast: line 431: 28057 Aborted $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS seems like ncurses is not loaded, is this is a known bug or what can i do enable more logs -- Regards Manu Gupta -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

4 3

[yast-devel] BuildRequires cleanup, check your *.spec files
by Ladislav Slezak 07 Aug '13

07 Aug '13

Hi all, after converting YaST to Ruby we do not compile YCP modules to YBC binary files anymore. The compilation required all imported modules to be present in the system during build. With Ruby it's not needed. The result is that some packages can be possibly removed from BuildRequires. Of course, if an external module is needed for running the tests then it still must be present [1]. In extreme cases all Yast packages (besides yast2-devtools) can be removed from BuildRequires. Even yast2 and yast2-core, see this [2]. The list of packages which can be removed depends on what's tested. Or you might need some file from other package during build, therefore the cleanup cannot be done automatically. So please, check your *.spec files and think about possible obsolete BuildRequires and remove them. If you are unsure just try removing it and build the package locally using "osc". If it succeeds then it's not needed :-) Sometimes you need to modify the configure.in.in file, there might be a check which tests some package/library/file/... presence but it's actually not used later. If you need some help just ask here.... Removing an unnecessary BuildRequire means that less package rebuilds will be needed in OBS and the rebuilds will be faster after updating a package. Also local builds will be faster (less packages to download and install). Thanks! Ladislav [1] This could be potentially avoided by mocking the imports and module calls via 'mocha' gem. Later I'd like to create some example... [2] https://github.com/yast/yast-bootloader/pull/22 -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

[yast-devel] YCP -> Ruby translation - known issues
by David Majda 07 Aug '13

07 Aug '13

Hi, FYI I created a page in YCP Killer wiki that collects known issues with the YCP -> Ruby translation: https://github.com/yast/ycp-killer/wiki/Known-Issues The intent is to have one canonical place when one can look in case of suspicion that something doesn't work right after the conversion. Right now, there is just one known issue, but it is possible that the list will expand in the future. -- 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

1 0

[yast-devel] Discussion - How should look new module written in ruby
by Josef Reidinger 07 Aug '13

07 Aug '13

Hi, we have now ruby and it brings a lot of features for free. I want to write example refactoring and new skeleton for new module. And I would like to discuss here what we should use. I think that now is good time, because before conversion we are forced to write it itself, but now we can choose from existing solution that is already implemented in ruby. 1) for skeleton I think that skeleton should be as small as possible, so move all repeating code to own method provided by a module (that is nice feature of rails, you can start really quickly ). And I think we should make clear difference between leaf module and module that can be reused by other modules. Because often there are Yast modules that have modules, but they use it themself exclusivelly. For such case now should be "lib" directory where is private Yast module code such us specific configuration logic or module specific dialogs. Advantage of such step is that you need not care about backward compatibility, as there is no public API and we can use all ruby features. 2) When module need to provide API for other modules ( so API should be based on requirements from other modules ) it should follow simple ruby - "Tell, don't ask" [1]. That helps with reducing of data leaks often seen in Yast ( when you change a map structure, you have problem because some modules depends on exact map structure ). The second nice benefit is that API will be easy to go via component system as there is almost no data flow. 3) No includes. Includes is relict from ycp and it should be moved to lib as common ruby class or modules. ( perl and python also doesn't have it ) 4) Exceptions. Ruby language provide us exceptions that can really simplify method code-flow. If there is error and it is reported by return value, then you need to explicitelly check it and go up if needed. Exception allow to handle it when you need it and if you don't handle it, then quickly recognize it[1b]. Current solution is that ruby-bindings catch exceptions when exception is catch between languages when calling modules ( so if both modules are in ruby, then it is passed ) and when use WFM::Call ( in case of exception, it is catched and return nil ). 5) testing framework. We definitively need new one, old one is really horrible to use and fragile. Ruby provide a lot of nice test frameworks, the well known are Test:Unit[2] ( classical test unit framework with asserts ) and RSpec that is designed to fit nice for TDD [3]. I personally use for a long time Test:Unit and try RSpec few months ago and I really like RSpec, especially how tests looks like and how nice is its output. 6) Documentation. For code documentation we translate comments to YARD[4]. But there is also documentation that sits around in docbook format. I found quite hard to write new parts of documentation and keep it up-to-date. I found tool that can convert docbook to textual based markdown format[5]. And I also thing that documentation should be together with code and also examples should live with code. YARD support it in quite nice way (support inlined markdown). See e.g. documentation of ActiveRecord::Base which lives together code and how it can look like [6]. 7) Continuous integration. We found that our jenkings node how few drawbacks, so we should also improve it. Lslezak have nice proposal how to simplify it. We can just package new commit and and call `osc build` and if it succeeds then submit new package to YaST:Head. Also if we improve our testing we can use e.g. travis and integrate it to test all of our pull request if it breaks test [7]. If we improve it, we can then verify also our maintenance branches and we can share load between more runners and dependency is mainly osc and what we need to package sources. 8) build program. YaST currently use autotools. It has few drawbacks - it is written in different language then rest of plugins ( M4 versus ruby now ), not so popular today ( so less people understand it, especially in ruby community ) and not so easy to share functionality ( currently we use Makefile.am.common and other tricks ). Common ruby build tool is Rake[8], question is if we want use it. I welcome any comments, suggestions or counter-proposal. Josef [1] http://pragprog.com/articles/tell-dont-ask [1b] http://nedbatchelder.com/text/exceptions-vs-status.html [2] http://www.ruby-doc.org/stdlib-2.0/libdoc/test/unit/rdoc/Test/Unit/Assertio… [3] http://rspec.info/ [4] http://yardoc.org/ [5] http://daringfireball.net/projects/markdown/syntax [6] http://api.rubyonrails.org/classes/ActiveRecord/Base.html [7] http://about.travis-ci.org/blog/2012-09-04-pull-requests-just-got-even-more… [8] http://rake.rubyforge.org/ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

4 5

[yast-devel] Kudos to the Yast text mode developers
by Alex Armstrong 06 Aug '13

06 Aug '13

I recently had occasion to use the YaST ncurses interface over ssh. I was very please that the ability existed, and quite impressed by well it worked. Keep up the good work, Alex Armstrong -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

[yast-devel] Rake tasks for Yast
by Vladimir Moravec 06 Aug '13

06 Aug '13

Hi, as it was discussed here last week, ruby ecosystem provides a build tool called Rake [1]. Rake makes use of 'tasks' which define in standard Ruby syntax and Rake DSL various specific goals, e.g. running the tests, metrics or creating the ruby gem or rpm package. To easily share the tasks' code between yast modules it would be good to have a single repository/package/gem with all common tasks, including constants and helper methods. I would propose to call it yast-rake-tasks , repository skeleton draft is available here [2] . The first tasks for tests and metricstogether with updated README file will follow soon. We have been using such approach with webyastalready [3] and it provedvery useful. There is an another repo providingpackaging tasks available here [4] . Any comments and suggestions are welcome. Vlado [1] http://rake.rubyforge.org/ [2] https://github.com/vmoravec/yast-rake-tasks [3] https://github.com/webyast/webyast/tree/master/webyast-tasks [4] https://github.com/openSUSE/packaging_tasks

1 0

[yast-devel] YaST in Ruby and string to be translated
by Andrea Turrini 06 Aug '13

06 Aug '13

Hi all, I send this mail to both os-translation and yast-devel ML since it addresses both yast development and translation, so take care of these two ML when you reply. I have just noted that the POT files for YaST have been updated, probably as the result of the conversion of YaST in Ruby. As a result, the msgid strings now contain "\\n" instead of "\n" to denote the new line inside the same msgid. For instance, in printer.pot, the current string is msgid "Started the CUPS daemon.\\nWaiting half a minute for the CUPS daemon to get ready to operate...\\n" while before it was msgid "" "Started the CUPS daemon.\n" "Waiting half a minute for the CUPS daemon to get ready to operate...\n" Now, the question is: is this change expected and wanted? Note that now we have around 3310 fuzzy and 40 untranslated strings so I think it is better to be sure that all these fuzzy strings are correct before starting fixing their translations. Best, Andrea -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

5 4

[yast-devel] YCP -> Ruby in "Press"
by Lukas Ocilka 05 Aug '13

05 Aug '13

Hi, I've been searching for some "random" opinions on the YCP -> Ruby conversion to get more feedback on what's not explained well enough, what users might feel as a possible problem, etc. Here's the list: YaST is being rewritten in Ruby; Geeko gets a nosejob [nice blog post, mostly useful comments] http://opensuseadventures.blogspot.ca/2013/06/yast-is-being-rewritten-in-ru… Suse 13.1: Yast goes Ruby [German only, summary of the "Geeko gets a nosejob"] http://www.linux-magazin.de/NEWS/Suse-13.1-Yast-goes-Ruby OpenSUSE 13.1 Switching To Ruby-Based YaST [article is just a summary, posts in forum indicate it wasn't well understood] http://www.phoronix.com/scan.php?page=news_item&px=MTM4NTI http://phoronix.com/forums/showthread.php?81155-OpenSUSE-13-1-Switching-To-… Yast is being autotranslated from YCP into Ruby [forum, useful, a bit of useless posts] http://forums.opensuse.org/english/get-technical-help-here/pre-release-beta… YaST se automaticky přepisuje v Ruby [Czech only, mostly not useful] http://www.root.cz/zpravicky/yast-se-automaticky-prepisuje-v-ruby/ From my POV, the feedback is quite good and some people see a lot new potential in our move from YCP -> Ruby. On the other hand, there are many questions mostly raised because of not enough information provided from our side. We can fix this by blogging about this theme a bit more. Thanks && 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

2 1

[yast-devel] Problem with Ruby YaST bootloader module
by Freek de Kruijf 01 Aug '13

01 Aug '13

I generated a native system using the iso with the Ruby YaST modules. The basic generation went well. When I boot my system now I get the 13.1M3 system. However I want to boot my original 12.3 system as the default system. So I started the YaST module bootloader, but it crashed with the following message: YaST got signal 6 at YCP file /usr/share/YaST2/modules/Wizard.rb:857 /sbin/yast2: regel 431: 1732 Afgebroken $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS Unable to load library icui18n "Cannot load library icui18n: (icui18n: kan gedeeld objectbestand niet openen: Bestand of map bestaat niet)" Do I need to file a bug report in bugzilla? -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

2 2

[yast-devel] Dropping yast2-dbus-client?
by Ladislav Slezak 01 Aug '13

01 Aug '13

Hi, I just have noticed this great pull request: https://github.com/yast/yast-storage/pull/8 It replaces the dbus agent (from yast2-dbus-client) by native Ruby DBus bindings (ruby-dbus). It looks that the agent was used only at this single place and we could drop it completely now. Do anybody else use the DBus agent? If not I vote for dropping it. -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

1 0

[yast-devel] Slight incompatibility between Ruby and YCP
by Thomas Fehr 01 Aug '13

01 Aug '13

Hi, I think I found a slight incompatibility between Ruby and YCP in YCP, I have the following code: map btrfs = GetTargetMap()["/dev/btrfs"]:$[]; map ret = filter( map p, btrfs["partitions"]:[], ``(p["uuid"]:""==uuid))[0]:$[]; which, in case of an empty list returned by filter call, relies on default parameter "$[]" after index operation. In RUby this is: btrfs = Ops.get(GetTargetMap(), "/dev/btrfs", {}) ret = Ops.get( Builtins.filter(Ops.get_list(btrfs, "partitions", [])) do |p| Ops.get_string(p, "uuid", "") == uuid end, 0, {} ) This works as before in assigning empty map to ret, but it now has the side effect of a line being written to y2log stating: [Ruby] yast/ops.rb:62 Index 0 is out of array size while the equivalent YCP code did not create any y2log entries. Is this intentional? Depending on the number of occurrences of such accesses in YCP code it could clutter y2log a lot. Tschuess, Thomas Fehr -- Thomas Fehr, SuSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Tel: +49-911-74053-0, Fax: +49-911-74053-482, Email: fehr(a)suse.de GPG public key available. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org To contact the owner, e-mail: yast-devel+owner(a)opensuse.org

3 3