April 2013 - YaST Development - openSUSE Mailing Lists

[yast-devel] Fixing yast2-slide-show for SLE11 SP3
by Karl Eichwalder 16 Sep '15

16 Sep '15

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

2 7

[yast-devel] Automatical built of YaST packages
by Thomas Goettlicher 10 May '13

10 May '13

Developers, I'm happy to announce that YaST packages are built and submitted automatically now. For every change of a YaST package located in the git repo's master branch ( https://github.com/yast/ ) the package is build automatically. On success it's submitted to YaST:Head in the build service, otherwise an email on yast-commit(a)opensuse.org informs about the failure. Packages in YaST:Head still need to be submitted to Factory manually because we want to make sure not to break Factory by this automatism. Cheers, Thomas -- Thomas Goettlicher SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 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

6 9

[yast-devel] YCP-killer and YCP data files
by Ladislav Slezak 02 May '13

02 May '13

Hi all, as you know we are working on a "YCP-killer" project, which should translate all YCP files to ruby and then get rid of our specific YCP language. I found a problem related to reading data YCP files. The problem is that some modules have data in YCP files which are read at runtime via these SCR calls: SCR::Read(.target.yast2, "foo.ycp") SCR::Read(.target.ycp, "bar.ycp") We can convert that YCP files to ruby with the converter but the loading mechanism will not not work. And keeping the data files in YCP format is also not an option. There are basically two possibilities: - convert the YCP files to a different format (plain text, YML, XML...) - modify the YCP files so that they can be used as an include file (includes are converted to ruby files so there is no change needed after the conversion) Which solution is better depends on the data in the file, some non-structured data could be simply converted to a plain text file, converting structured data is usually more complex. The second solution is easier for structured data as the file itself can be more or less left untouched, only the loading mechanism needs to be changed to an include statement. The disadvantage of the second solution is that the data is loaded persistently to memory (as it actually becomes code) so for large data files it might not be a good idea. As a proof of concept I adapted two YCP modules and changed the data files to includes, see these pull requests: https://github.com/yast/yast-ntp-client/pull/5/files https://github.com/yast/yast-mouse/pull/2/files The mouse module is little bit tricky as the database contains translations. And they need to be translated dynamically to reflect possible language changes during installation proposal, therefore I added a wrapper function which always returns a fresh instance of the data with the current translations. Conslusion: If you have some spare time and want to help us with the ruby translation you can start removing the YCP data files. You can look at the pull requests above for a hint how to do that. Or just ask here or on the IRC. Thank you! -- 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

8 16

[yast-devel] XML to YCP Parser less strict than YCP Parser
by Thomas Fehr 30 Apr '13

30 Apr '13

Hi all, Last week I was confronted with an L3 from Intel regarding autoyast. After some investigations I found out it was caused by them using "<fstopt config:type="symbol">pri=1</fstopt>" instead of correct "<fstopt>pri=1</fstopt>" in partitioning section of autoyast xml code (since they let autoyast xml code itself been generated by scripts this was not completely easy to see). Ok, there are many ways to break an autoyast installation with wrong xml entries but the effects of above bug was quite surprising. YaST2 scr crashed at end of installation when autoyast writes autoyast settings with SCR::Write( .target.ycp, ...) into installed system. At this point in installation SCR has already been restarted below /mnt and the chrooted SCR gets the ycp code via parsing stdin. Here the problem really starts: Above xml leads to followingq map entry: $["fstopt" : `pri=1], but the YCP parser will not accept this. This leads to chrooted SCR at end of installation to crash which of course wreaks furter havoc afterwards. YCP parser in core/libycp/src/scanner.ll defines "SYMBOL ([[:alpha:]_][[:alnum:]_]+|[[:alpha:]][[:alnum:]_]*)". While xml/src/XmlAgent.cc accepts any string: else if (!xmlStrcmp(confAttr, (const xmlChar *)"symbol")) { y2debug("Symbol found"); YCPSymbol sym((const char *)lastChild->content); return YCPSymbol(sym); } IHMO, we should make that a little more robust. I am not sure if autoyast is the only part of yast2 where xml code provided by user is parsed into ycp. Any suggestions? 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

2 4

[yast-devel] Making systemd and Yast collaborate well
by Cristian Rodríguez 30 Apr '13

30 Apr '13

Hi: I just subscribed to this list in order to offer assistance in order to get Yast and systemd to interact in a nicer fashion. I will assist you with patches and a lot of suggestions after the decision of converting the YCP codebase into Ruby is taken and modules are translated. Here is the first and most important suggestion I have and I strongly suggest you to consider it while creating/migrating modules from YCP to Ruby. - You MUST NOT talk (I can't find a way to emphasize this) to any systemd component using systemctl, localectl, timedatectl or whatever other command line utility, those are *human interfaces* and not *programming interfaces*(exception "systemctl show") if you continue in the current direction, it will bite you and rip and piece of your skin pretty soon. Yast MUST communicate with systemd components using the respective D-BUS API.[1][2][3][4] [1] http://www.freedesktop.org/wiki/Software/systemd/dbus [2] http://www.freedesktop.org/wiki/Software/systemd/timedated [3] http://www.freedesktop.org/wiki/Software/systemd/localed [4] http://www.freedesktop.org/wiki/Software/systemd/hostnamed A little bit of googling shows that mvidner has a repo in github containing an implementation of ruby-dbus that will come handy for this purpose. That's all for now :-) Cheers! -- 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] YaST module for Puppet configuration
by Theo Chatzimichos 30 Apr '13

30 Apr '13

Hello, I'd like to add as GSoC idea the development of a YaST module for setting up and configuring Puppet Master and Agent. I can't mentor it though because I don't know anything about YaST development, anyone here willing to mentor? Theo

1 0

[yast-devel] Obsoleted modules - code cleanup in "master" branch
by Ladislav Slezak 17 Apr '13

17 Apr '13

Hi all, during our "Kill YCP" hackweek project [1] we found out that there are many obsoleted modules which are not developed anymore but still have some code in the master branch. This is confusing and might result in unnecessary extra work like - translators might still translate the texts (well, I don't know the process exactly so maybe not...) - refactoring can be harder - you may not remove old function Foo() defined in other module because it seems to be used there, changing a function might require more changes in other modules, etc. - grep in all Yast modules is slower as it has to check also the obsoleted files (well, actually it's that bad...) We marked such modules as "dropped" in our overview table [2]. So if you maintain such a module simply remove all files and put there a README.md file describing the state and the reason for removal. (Create a new branch before removing all files so the last state is available if somebody is interested in it.) If the code is still maintained in SLE11 mention that in the README file. You can look at bluetooth[3] and uml[4] modules to see how it could be done. Thanks! [1] : https://github.com/SUSE/hackweek/wiki/Kill-YCP-by-Mechanical-Translation [2] : https://docs.google.com/spreadsheet/ccc?key=0AqkGTJzxGJv8dFBKQ1JPeU96NWUxMW… [3] : https://github.com/yast/yast-bluetooth [4] : https://github.com/yast/yast-uml -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak(a)suse.com SUSE -- 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] Killing YCP
by David Majda 17 Apr '13

17 Apr '13

Hi, as many of you know, in January 2013 we started a project which played with an idea to automatically translate YCP portion of YaST codebase into Ruby. Me and Josef Reidinger worked on this and before Hack Week 9 [1] we reached a state where we were able to completely translate and run the "sysconfig" YaST module. During the Hack Week we decided to push for more. We assembled a team of 5 people (me, jreidinger, mvidner, lslezak, vmoravec) and tried to translate as much modules as possible. At the end of the Hack Week almost 60% of YaST's 150+ modules either compile to Ruby successfully, or we determined they don't need to be compiled at all (e.g. because they don't contain any runnable YCP code). I consider this a huge success. We also packaged some translated modules (e.g. "proxy" or "runlevel"). You can test them by downloading from our testing project: https://build.opensuse.org/project/show?project=YaST%3AHead%3Aruby For more details, see a video about our Hack Week project and its wiki page: http://www.youtube.com/watch?v=Bzgs1lmSKCw http://bit.ly/YPBW2Q ----- So far, the project to kill YCP was entirely unofficial. I'd like to use this opportunity to start a discussion about making it official and getting rid of YCP in openSUSE 13.1 timeframe (yes, I am that ambitious :-) From what I see, YCP is very simple and inflexible language. It doesn't support many useful concepts like OOP or exception handling, code written in it is hard to test, there are some annoying features (like a tendency to be "robust", which really means hiding errors) and YaST developers universally hate it (at least all the ones I talked to). More importantly, YCP is a language used only by YaST. This means the cost of its development and maintenance lies purely on SUSE/openSUSE. In practice, its development stagnated. There is also no community around the language and no external tools & libraries developed. As a result, every bit of code needs to be written by us and the tooling is weak. All this combined makes the cost (both financial and mental) of YaST development higher than if any other suitable high-level language was used, which limits YaST potential. Translating the code into Ruby would negate most of these disadvantages. We would be able to rely on a healthy ecosystem of tools and libraries (which are getting only better over time). There is a great pool of accumulated knowledge we can use. We would be also able to share code more efficiently with other SUSE/openSUSE projects written in Ruby, like WebYaST or SUSE Studio. We will have more flexibility in where to take YaST next. Last but not least, YaST developers would hate their jobs less :-) I think that rewriting YaST into Ruby makes sense. The Hack Week proved this is indeed doable and viable project, and my estimate is that it can be done in few months if we'll work hard enough (I can elaborate on this if needed). What do you think? ----- For the curious, the tool called "YCP Killer", which manages the translation, is available here: https://github.com/yast/ycp-killer The tool uses Y2R, a YCP -> Ruby transpiler: https://github.com/yast/y2r You can get the idea about what and how we translate from the spec (take this with a grain of salt, we want to improve the generated code *a lot* in the next weeks/months): https://github.com/yast/y2r/blob/master/spec/y2r_spec.md All this is very much work in progress, so please forgive any rough edges and lack of polish. -- 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

6 9

[yast-devel] problem with the yast gtk gui
by am_dxer 16 Apr '13

16 Apr '13

Yesterday, I was trying open suse 12.3 as I was thinking about upgrading my machines. I am totally blind and thus use the gnome version which provides a screen reader that provides blind users with speech and braille feedback of what is happening on their computer. Until yesterday I had no problems using the screen reader which is called orca with the gtk yast gui. When I launched modules from the yast control center in 12.2, accessibility worked and the screen reader read them well. however, in the new version, orca does not read the modules when they are launched from the control center. The only way to get them to read at this point is to type "su" and then run "yast --gtk <module-name>". My guess is that for some reason, the way the control center is launching the modules is not loading all the accessibility parts. I know this worked part way through the development cycle, because I tried the development milestones and things worked. Also this was after gnome 3.6 had migrated in. One thing worth noting is that the live installer on the live cd worked with the screen reader if launched from gnome-shell, however, when launched from the control center, this did not read either. However, the usual workaround of running it with root privilages in the terminal made this module read as well. Does anyone have any suggestions or have any ideas of changes to the gtk yast that could have broken accessibility? Thanks in advance for the help. -- 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] Managing SUSE translations in unified way
by Tomáš Chvátal 09 Apr '13

09 Apr '13

Hello guys, Let me tell you a "shorty" bit about my hackweek project. Currently our translation repositories are stored in internal svn and split by branches per release. I want to tackle the issue where translations are inconsistent among supported releases and also somehow consolide all the stuff we are providing to have only one input channel with less space for contributor confusion. As I described this in my previous mail [1] I want to fire up the weblate instance with help from Michal Cihar. But as people complained against web translations only we will simply list the git repositories with access to allow them merge requests on github or use the weblate only as interface to obtain the .po files. Items currently stored in svn [2]: yast - obvious, in github webyast - obvious, in github lcn - merged repository for various tools zypper/bootloader/... packages - repository for cd descs/etc... Some of the packages do not have suse upstream (eg special kde translations and so on). These will be migrated in the end to new github project (eg. openSUSE/translations-3rdparty.git; if you have cooler name we will use it :P). Also I bet we already have some projects that should be translated and are not. If you happen to be aware of such project we can also add it to the toolkit, just reply to this mail with its name and git repo. List of tasks to get this working ------------------------------------------- Infrastructure side: Deprecate translations mailinglists to keep only the opensuse-translation where everyone should discuss, with per language lists the problem is if the team goes inactive nobody notices, and we can have more active list where we ingore threads that do not bother us. Eg we can have them prefixed by lang if they matter only for those ([ru] Unable to translate foo due to xyz). [[Who can actually sent deprecation mails and mark them read only?]] Create new documentation on i18n which will contain the weblate instance and provide links to git repositories and pull requests description for contributors not wanting to use the weblate. Suspending the translation repositories to read-only until migration is complete. Note for translators, you can translate your stuff even in read-only mode. Merging then will be possible in weblate or by hand into the new location which will be described in the new repository listing. IMPORTANT: this must be done ASAP, because without the disabled write access we shouldn't start moving the files around. Upstream/developers side: Take the translations from the svn repository and create po/ folder in your project root. Structure looks like this (some projects already have po folder but the translations are in tarball, just throw away the tarball and unpack it): <snip> yast2-network/po/cs.po yast2-network/po/de.po yast2-network/po/yast2-network.pot </snip> Modify spec-file of the package to count with the translations from here (I am well aware it will create collisions in the start with the generic l10n packages we will remove later on, so we should obsolete them and make the lang pkg recommended). Create new hook that updates the .pot file with each commit and regenerates the .po files. I bet Michal already have some nice hook at phpmyadmin and he can provide it so we don't need to write one stock each time. Remove hooks that push into svn if there are some and it is not cron-based server side. [[Anyone knows how this is done?]] Update buildscripts to generate .mo files and to install them into right place. Easy in distutils, for autotools you need gettext Makefile.in.in, I will provide help and do the work where needed. After we fire up testing weblate we will also need to add weblate key to be able push to the repository. [[Michal could you please elaborate here how this taks need to be done?]] Of course you are not the ones who have to do the work, I will do the task if asked/allowed to touch your repos (scarabeusiv account at github). I am just pretty sure I will not be able to migrate all 205 repos in one week without screwing up somewhere, so any help will be highly appreciated, specially when you guys know your project much more than I do :-) Packaging side: We need to update the .spec files of the various translation modules like yast2-translations to be split into specified packages (yast2-network-lang,...) Packages that will be obsoleted and split are: yast2-translations [[I suck at searching in obs so if you see more of those that should be adjusted please reply here and I will do whats needed]] Possible future task that would make people happy: Allow translations of wiki pages instead of having separate wiki instances for each language. This stuff is messy and using weblate here would be so awesome. Cheers Tom PS: keep reply-to on opensuse-translation so we don't clutter the discussion on multiple places. PPS: this is quite lengthy mail so if I forgot to mention something just slap me and ask for more informations. [1] http://lists.opensuse.org/opensuse-translation/2013-04/msg00000.html [2] http://svn.opensuse.org/svn/opensuse-i18n/

3 4