July 2007 - YaST Development - openSUSE Mailing Lists

[yast-devel] yast2-devtools: make %{?jobs:-j%jobs} ins slide-show
by Karl Eichwalder 30 Jul '07

30 Jul '07

The tools used to merge the slide-show translations do not seem to be thread-safe. xml2po, part of the gnome-doc-utils package, seems to be guilty. Thus make %{?jobs:-j%jobs} fails. As long as xml2po is not fixed, we must use -j 1 . We either need to enhance yast2-devtools or I must use a hard-coded "@BUILD@ resp. %build section in yast2-slide-show.spec.in -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 2

[yast-devel] Installing Patterns
by Benji Weber 30 Jul '07

30 Jul '07

Hi, I have been trying to install patterns using Pkg::ResolvableInstall( patternName, `pattern ); Is this supposed to work? It seems to always fail here, and I can't see why. I also found this in AutoinstClone.ycp: /* FIXME: if this would work, it would be the better solution foreach(string p, patterns, ``{ Pkg::ResolvableInstall( p, `pattern ); }); Pkg::PkgSolve(false); */ Which wasn't encouraging. Adrian has requested Pattern installation should work for the Metapackage handler, and it would if this ReolvableInstall would work. _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1

[yast-devel] MetaPackage status
by Benji Weber 28 Jul '07

28 Jul '07

Greetings all, I've just finished re-writing the MetaPackage handler for installation of software from webpages. Martin has kindly agreed to help package it as next week I am away on holiday Monday-Friday. The UI has only minor cosmetic changes and: - Introduction of a welcome screen displaying overall details of the metapackage, using the new name/summary/description elements Adrian requested. - Introduction of Simple/Advanced modes. - Addition of warning dialogue before installation to attempt to ensure users review the changes. - More detailed status reporting. See http://benjiweber.co.uk/OCI/screenshots/ for a tour. This version of the MetaPackage handler is almost a complete re-write. It is now using the new schema that is the outcome of various discussions over the past few weeks. See http://en.opensuse.org/Standards/One_Click_Install The only feature that I have not been able to test as working is the Pattern installation, see my other mail about that. I have also tried to make it easier to extend & maintain, and work around some of the limitations of YaST to allow - Separation of UI & logic. - Easy XML handling. - Privilege Escalation mid process. - Communication of detailed status. The design I have decided upon eventually is possibly best illustrated by a diagram: http://benjiweber.co.uk/OCI/OCI-design.png I have used perl-xml-xpath as this seems to allow XML to be handled fairly easily from within YCP. One can simply select any data out of the XML document which is itself handled by Perl. This also avoids requiring lots of custom Perl or YCP. I have utilised the existing yast2-xml support for marshalling/unmarshalling YCP datatypes to and from XML to transfer state between limited-user and root instances of YaST. The invocation of the root instance is performed using xdg-su so it will work on either KDE or GNOME. The basic workflow is: 1) User opens metapackage 2) User reviews changes that will be made, and commits/makes changes/aborts. 3) Installation is performed as root 4) Status is displayed to user. Which expands to: 1) User clicks a ymu link on a webpage, or clicks on a ymp file. 2) OneClickInstallUI is invoked with the metapackage uri as a parameter, this downloads the xml file if necessary and asks OneClickInstall module to load it. 3) OneClickInstall module parses the XML, picks out the relevant data based on what product & language the user is using. This is stored in its own internal format. 4) User interacts with the OneClickInstallUI user interface, this adjusts values in OneClickInstall depending on what the user selects. 5) OneClickInstall state is persisted to temporary file. 6) Root instance of OneClickInstallWorker is invoked. 7) OneClickInstall state is recovered from temporary file. 8) Installation is performed, results are stored in OneClickInstallWorkerResponse module. 9) OneClickInstallWorkerResponse state is persisted back to the temporary file. 10) OneClickInstallWorkerResponse running as the user restores its state from the temporary file. 10) OneClickInstallUI running as the user displays the status by querying the response. A summary of each file and its purpose: OneClickInstallUI.ycp : Wizard User Interface. This is pretty much only the User Interface, it interacts with the other components to do things. OneClickInstallUrlHandler.ycp : Simple additional stage that allows for the additional level of indirection of the YMUs, this is required to allow embedding of just the URL itself in a webpage. OneClickInstallWorker.ycp : Performs the actual installation. This contains just the installation logic. OneClickInstall.ycp : Responsible for most of the logic. Can load an XML document in the metapackage format, select the appropriate data from it and store it in its own internal format. Provides an interface for the User interface and install worker to obtain the information they require. Provides ToXML and FromXML methods for transfering state between the limited user instance and the root instance. OneClickInstallWorkerResponse.ycp : Responsible for storing installation status & error messages. Provides ToXML and FromXML methods for transferring state between the limited user instance and the root instance. YPX.pm : Thin wrapper around the Perl::XML::XPath, allows querying of data out of an XML document without requiring lots of ugly YCP or Perl code. ==Installation== The installation instructions are relatively similar to the existing handler, so hopefully the existing spec can be adjusted. There is a new dependency on Perl-XML-XPath, instead of Perl-XML-Simple. So this will need to be packaged. Using the perl xpath library actually makes consuming XML from within YCP itself quite simple, instead of ugly solutions, or needing to use lots of perl. Until this is packaged you can install the XPath library by running cpan as root and typing: "install XML::XPath" If you are using 10.2 rather than factory (I have not tested this on factory yet) you will need to install xdg-su which you can get from http://benjiweber.co.uk/OCI/xdg-utils-1.0.1-45.noarch.rpm Grab http://benjiweber.co.uk/OCI/deploy.tar.gz and copy the contents of the modules directory to /usr/share/YaST2/modules, copy the contents of the clients directory to /usr/share/YaST2/clients. You can test whether it is working by running "/sbin/YaST2 OneClickInstallUI http://benjiweber.co.uk/OCI/test-tuxsaver.ymp" in a terminal. N.B. Mimetypes & Programme names have both changed so the associations will need to be re-created, once this is done you can test the link at http://benjiweber.co.uk/OCI/test.html =KDE/Konqueror= Replace all instances of ~/.kde/share/ in these instructions with `kde-config --prefix`/share/ for systemwide installation. Copy the two files from http://benjiweber.co.uk/OCI/mimelnk to ~/.kde/share/mimelnk/text Copy the two files from http://benjiweber.co.uk/OCI/applnk to ~/.kde/share/applnk/.hidden Add the following sections to ~/.kde/share/config/profilerc -- [text/x-suse-ymp - 1] AllowAsDefault=true Application=kde-yast2-ymp.desktop GenericServiceType=Application Preference=1 ServiceType=text/x-suse-ymp [text/x-suse-ymu - 1] AllowAsDefault=true Application=kde-yast2-ymp.desktop GenericServiceType=Application Preference=1 ServiceType=text/x-suse-ymu -- Add the following lines to ~/.kde/share/config/konquerorc in the [Notification Messages] section: -- askEmbedOrSavetext/x-suse-ymp=no askEmbedOrSavetext/x-suse-ymu=no askSavetext/x-suse-ymp=no askSavetext/x-suse-ymu=no -- Kill all instances of konqueror and restart it. =Firefox= We have to use a wrapper script for firefox as it doesn't support associating things with a command + parameters. Save the following as /sbin/OneClickInstallUrlHandler , and make it executable. -- #!/bin/bash /sbin/YaST2 OneClickInstallUrlHandler $@ -- Add the following to mimeTypes.rdf (~/.mozilla/firefox/..profilename../mimeTypes.rdf if you're installing just for your user). Just below the opening element. -- <RDF:Description RDF:about="urn:mimetype:externalApplication:text/x-suse-ymu" NC:path="/sbin/OneClickInstallUrlHandler" NC:prettyName="OneClickInstallUrlHandler" /> <RDF:Description RDF:about="urn:mimetype:text/x-suse-ymu" NC:value="text/x-suse-ymu" NC:editable="true" NC:description="" > <NC:handlerProp RDF:resource="urn:mimetype:handler:text/x-suse-ymu"/> </RDF:Description> <RDF:Description RDF:about="urn:mimetype:handler:text/x-suse-ymu" NC:alwaysAsk="false" NC:saveToDisk="false" NC:useSystemDefault="false" NC:handleInternal="false"> <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:text/x-suse-ymu"/> </RDF:Description> -- A sample complete mimeTypes.rdf follows -- <?xml version="1.0"?> <RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#" xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <RDF:Description RDF:about="urn:mimetype:externalApplication:text/x-suse-ymu" NC:path="/sbin/OneClickInstallUrlHandler" NC:prettyName="OneClickInstallUrlHandler" /> <RDF:Description RDF:about="urn:mimetype:text/x-suse-ymu" NC:value="text/x-suse-ymu" NC:editable="true" NC:description="" > <NC:handlerProp RDF:resource="urn:mimetype:handler:text/x-suse-ymu"/> </RDF:Description> <RDF:Description RDF:about="urn:mimetype:handler:text/x-suse-ymu" NC:alwaysAsk="false" NC:saveToDisk="false" NC:useSystemDefault="false" NC:handleInternal="false"> <NC:externalApplication RDF:resource="urn:mimetype:externalApplication:text/x-suse-ymu"/> </RDF:Description> <RDF:Description RDF:about="urn:mimetypes"> <NC:MIME-types RDF:resource="urn:mimetypes:root"/> </RDF:Description> </RDF:RDF> -- _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] ruby bindings
by Duncan Mac-Vicar P. 27 Jul '07

27 Jul '07

Hi people I want to merge some changes I have in my machine to the ruby bindings, so I thought about moving them to trunk first. any objections? only one thing: they build with cmake Does it make sense to have a directory ruby-bindings and then python-bindings, or do we create a bindings directory and put them all there, including the perl ones? Duncan -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

6 10

[yast-devel] Privilege escalation within a YaST module.
by Benji Weber 25 Jul '07

25 Jul '07

Greetings all, For the one click install YaST module it is necessary to run the module first as a limited user, to display the details about the operation to be performed, and allow the user to customize it. The installation operation itself must then be performed as root. This is crucial to prevent malicious use of the feature to damage users' systems. At present I am achieving this by constructing a shell command to execute another YaST module as root, to perform the actual installation itself. This does work, but it has a number of problems, most significantly: * Using a shell command is potentially dangerous, I am stripping out special shell characters first, but it is still not ideal. * We cannot easily pass information back from the module running as root to the original module to display status. So my question to you is whether there is a better way to do privilege escalation from within a YaST module, or a better way to do inter-process communication between an instance of YaST running as a regular user, and an instance running as root. Many thanks _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] Privilege escalation within a YaST module.
by Benji Weber 25 Jul '07

25 Jul '07

Greetings all, For the one click install YaST module it is necessary to run the module first as a limited user, to display the details about the operation to be performed, and allow the user to customize it. The installation operation itself must then be performed as root. This is crucial to prevent malicious use of the feature to damage users' systems. At present I am achieving this by constructing a shell command to execute another YaST module as root, to perform the actual installation itself. This does work, but it has a number of problems, most significantly: * Using a shell command is potentially dangerous, I am stripping out special shell characters first, but it is still not ideal. * We cannot easily pass information back from the module running as root to the original module to display status. So my question to you is whether there is a better way to do privilege escalation from within a YaST module, or a better way to do inter-process communication between an instance of YaST running as a regular user, and an instance running as root. Many thanks _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] YCP syntax highlighting in kate
by Benji Weber 25 Jul '07

25 Jul '07

Hi all, I couldn't find any syntax highlighting rules for kate-part (used by kwrite, kate, kdevelop etc) so I created some. Perhaps some will find them useful. Screenshots from the YaST module tutorial YCP: http://benjiweber.co.uk/kateycp/one.png http://benjiweber.co.uk/kateycp/two.png To use, download http://benjiweber.co.uk/kateycp/ycp.xml to ~/.kde/share/apps/katepart/syntax or `kde-config --prefix`/share/apps/katepart/syntax _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 2

Re: [yast-devel] Let's make minimal system smaller :) (41 MB)
by Jiri Srain 24 Jul '07

24 Jul '07

Dne pondělí 23 červenec 2007 17:00 Stephan Kulow napsal(a): > Am Montag 23 Juli 2007 schrieb Lukas Ocilka: > > Jiri Srain wrote: > > > Are we really allowed to ship the package without the text of the > > > license? > > > > > > OTOH, currently there are two copies of the license in the package, and > > > (at least according to RPMlint) they can be replaced by a link to > > > package containing licenses. > > > > My patch didn't remove the license from the original yast2-installation > > > > :) The same (license) file is in both yast2-installation and > > > > yast2-installation-doc. > > It doesn't have to be in yast2-installation-doc - it has to be in the > sources and it's good to have it in one of the binary packages. It doesn't > have to be in every one of them. Do we want to call these packages -doc? It may be confusing, one may expect the end-user documentation in these packages, but what he finds is (mostly) the autogenerated documentation targeted for developers. We already have eg. the yast2-devel package which contains only documentation for developers. I'd find it consistent calling the packages this way (eg. yast2-installatoin-devel in thexample above). I checked with local packagers, there is no rule on how such packages should be caleld. There are already some -devel-doc packages in autobuild, but they are just about five. Any other ideas? Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain(a)suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz

4 3

[yast-devel] SLES10 SP1 YaST Documentation Available
by Lukas Ocilka 24 Jul '07

24 Jul '07

Hi, I've just built the YaST documentation for SLES10 SP1. You can find it here: http://forgeftp.novell.com/yast/doc/SLES10SP1/ Have a nice day Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

1 0

[yast-devel] Let's make minimal system smaller :) (41 MB)
by Lukas Ocilka 23 Jul '07

23 Jul '07

Hi, Despite the fact that I don't want to be called "the one who reinvented the wheel", I'm still writing this mail :) I've found that some YaST packages have a huge amount of documentation but honestly, who reads such documentation and how often? Do we really want to have all this data in a minimal installation? This script checks all yast2* packages for size of their documentation and prints a sum at the end: SUM=0; for size in `du -s /usr/share/doc/packages/yast2* | \ sed 's/$[^ \t]*$.*/\1/'`; do \ echo $size; SUM=`expr 0${SUM} + ${size}`; done; \ echo; echo "Sum: ${SUM}" My system has about 58 MB of YaST documentation written in HTML. These are the biggest sinners: du -s /usr/share/doc/packages/yast2* | \ sort --general-numeric-sort | tail -n 10 646 /usr/share/doc/packages/yast2-repair 694 /usr/share/doc/packages/yast2-bootloader 737 /usr/share/doc/packages/yast2-nis-server 740 /usr/share/doc/packages/yast2-installation 1030 /usr/share/doc/packages/yast2-pkg-bindings 1073 /usr/share/doc/packages/yast2-network 1710 /usr/share/doc/packages/yast2-printer 2619 /usr/share/doc/packages/yast2 12372 /usr/share/doc/packages/yast2-storage 23191 /usr/share/doc/packages/yast2-core Sizes are in kilobytes. ------------------------------------------------------------------------ The best solution could be creating YaST "${name}-doc" packages containing only the documentation. They could be installed by default on a normal KDE/GNOME installation but not selected for a minimal installation. ------------------------------------------------------------------------ It seems to be quite easy change in an RPM .spec file... At least these packages should be split into ${name} and ${name}-doc: yast2-installation (0.7 MB), yast2-pkg-bindings (1 MB), yast2-network (1 MB), yast2-printer (1.7 MB), yast2 (2.6 MB), yast2-storage (12 MB), and yast2-core (22.6 MB) Only these can save up to 41 MB. What do you think of that? -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

5 6

[yast-devel] Re: [opensuse-fr] Re: [opensuse-doc] How to name that thing? Repository/installation source/Catalog...
by Pascal Bleser 23 Jul '07

23 Jul '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 jdd wrote: > Andreas Jaeger wrote: >> The decision was to use "repository". Other names considered where >> "installation source" and "catalog". > > could you also ask your translation team to give the official translation. > > At least in french, repository is not easy to translate. The very same > word exists but is completely obsolete (repositoire - meaning the place > where you store dead human corpse to family last visit :-()). > > http://fr.opensuse.org/Glossaire_d'équivalences_entre_l'anglais_et_le_français > > the best word seems to be "dépôt", but "Réserve" may be better. Package > repository gives "Réserve de paquetages", "Dépôt de paquetages" > (paquetage is very odd in french, but most used anyway) "Dépôt" is the adequate term IMO. - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGpH0fr3NMWliFcXcRAtiqAKCeXZpW5YE1eKXH7AP25iSHPQPkmQCfdNw6 XHLcxkTxklZMJoFCmtIhyAk= =raN+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] New repository filter in YaST ncurses - request for testing ;-)
by Katarina Machalkova 19 Jul '07

19 Jul '07

Hello! I've added a new feature to YaST ncurses UI - a list of all available repositories + related filtering of packages according to which repository they belong to. You may know this filter well from Qt UI, in ncurses it's brand new. Since no 'class recycling' could be used ;-) (I've written entirely new class for the filter from scratch) and since new zypp repository handling code has been used (and I'm not a zypp developer), I'd like to ask you for trying and testing this feature. If you do so, please report any segfaults ;-) missing repository information, even ugly dialog layout to me (in Bugzilla, assign to kmachalkova). The first one reporting a bug will receive a beer (or a chocolate, if (s)he prefers that) ;-) How to test: just install new yast2-ncurses 2.15.21and go to Filter->Repositories Thanks frozenB. P.S. Code review is also welcome, the whole thing is pretty well commented and documented -- \\\\\ Katarina Machalkova \\\\\\\__o YaST developer __\\\\\\\'/_ & hedgehog painter -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] Re: [yast-announce] First translation round starts this week
by Jiri Srain 19 Jul '07

19 Jul '07

Hi! Since we change the terminology of the installation sources/catalogs, please, try to adapt at least some of the texts ASAP. Find the result of grep through the .pot-files atatched to this mail (probably not complete :-( ). I will generate the .pot-files for first translation round in a few hours. Thanks! Jiri Dne úterý 17 červenec 2007 09:18 Jiri Srain napsal(a): > Hi! > > The first translation round is starting this week. I will generate > the .pot-files for translators this week on Thursday afternoon. Please, get > as many new texts as possible to the subversion repository by Thursday noon > CEST. > > Thanks! > > Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain(a)suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz

1 0

[yast-devel] Re: [yast-commit] r39517 - in /trunk/gtk: ChangeLog po/ po/pt.po src/YGPackageSelector.cc
by Jiri Srain 19 Jul '07

19 Jul '07

Hi Ricardo! Dne čtvrtek 19 červenec 2007 06:27 jste napsal(a): > Author: rpmcruz > Date: Thu Jul 19 06:27:59 2007 > New Revision: 39517 > > URL: http://svn.opensuse.org/viewcvs/yast?rev=39517&view=rev > Log: > * src/YGPackageSelector.cc: Jiri has added gettext support (not sure > if it is completed as I don't see the place for PO files and the rules > to compile them), so set package selector strings as translatable _( ... > ). You don't have to care about it at all. I will create the .pot-file today afternoon (as stated at yast-announce(a)opensuse.org) and it will be passed to the trandslators. After translated to individual lnaguages, it will be packaged into yast2-trans-XX. It doesn't require any work from your side, since yast2-gtk is already part of the Alpha snapshots. > * po/pt.po: created this translation; dunno how to make the thing > being used now... It can be removed, see above. However, I will grab this file to save the work of translatores since it is already done. Of course, volunteers for translations are always wellcome :-) Jiri Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain(a)suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz

1 0

[yast-devel] Is this a bug of SUSE? Cannot load autoyast profile from harddisk,
by Da Shuang He 19 Jul '07

19 Jul '07

I make a bootable disk, and I can start to install the SUSE, but when it tries to find the autoyast file, it can't find it, and I write the kernel parameter like this : title SUSE 10 Installation root (hd0,0) kernel /boot/linux root=/dev/sda1 ramdisk_size=8192 install=hd://sda1/SUSE autoyast=device://sda1/autoinst.xml splash=silent showopts initrd /boot/initrd When I try autoyast=device://sda1/autoinst.xml, the error is , "An error occurred while fetching the profile: File /tmp/Yast2-02878-KeDBUh/tmp_mount/autoinst.xml cannot be found" And when I use file:///autoinst.xml and default, the error is, "An error occurred while fetching the profile: Reading file on /var/adm/mount//autoinst.xml failed. Reading file on /autoinst.xml failed. Reading file on CD failed. Path /tmp/Yast2-02878-KeDBUh/tmp_mount/autoinst.xml" And when I try to use hd://sda1/autoinst.xml It tells me hd is unknown protocol, Can someone tell how should I write the parameter for autoyast, or do you know somebody else can help me on this ? Or this is a bug of SUSE? -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] Next hackweek project done ... ycp-to-ruby-translator
by Klaus Kaempf 18 Jul '07

18 Jul '07

Hi, Cornelius hackweek proposal of a ycp-to-ruby-translator (see http://idea.opensuse.org/content/ideas/ycp-to-ruby-translator) was an itch I had to scratch sooner or later. So I spent some spare time and did a couple of late night hacks to make the translator real. It is based on an XML representation of the abstract syntax tree produces by the YCP scanner and parser within libycp. So its a pure syntax translator with only very, very limited knowledge of the semantics. The resulting Ruby code does pass the Ruby syntax checker, though. Combined with Duncans Ruby-YCP bindings, translating ycp to Ruby should be quite useful as we try to provide support for more widespread scripting languages. The translator is available at http://svn.opensuse.org/svn/yast/trunk/yxmlconv You need a recent version of yast2-core, which supports XML output and the '-x' parameter of ycpc. Then run ycpc -c -x file.ycp -o file.xml to convert YCP code to XML. Now use the xml-ruby translator as cd yxmlconv ruby src/converter.rb file.xml > file.rb Klaus P.S.: It's fairly straightforward to change the translator to output e.g. Python or Java or C# or ... --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 2

[yast-devel] YaST Icons
by Lukas Ocilka 18 Jul '07

18 Jul '07

Hi, I've found out that some YaST modules use icons that are not present in the "current" YaST theme. Because it's seemed to be impossible to find all manually (and it also didn't make any sense) I wrote a script that runs through all .ycp and .desktop files for "Icon". When the list of used icons is created, it searches for used icons in the current theme on the disk or in the directory provided as the first script parameter. The script doesn't work with Perl modules so it needn't check all icons used... Please, check your YaST modules for missing icons, thanks. See the attached script plus an example of script-output: /yast/test/iconcheck.sh /yast/CODE10/SL_10.3/source/theme/openSUSE/icons --- cut --- Icons will checked against /yast/CODE10/SL_10.3/source/theme/openSUSE/icons Checking files in directory: /yast/CODE10/SL_10.3/source/ca-management Processing file ./src/crl.ycp Processing file ./src/new_cert_items.ycp ... shortened ... Processing file ./src/wizards.ycp Processing file ./src/util.ycp All used icons (in YCP): ca-management No such file: /yast/CODE10/SL_10.3/source/theme/openSUSE/icons/22x22/apps/ca-management.png (yast-ca-management.png) No such file: /yast/CODE10/SL_10.3/source/theme/openSUSE/icons/32x32/apps/ca-management.png (yast-ca-management.png) No such file: /yast/CODE10/SL_10.3/source/theme/openSUSE/icons/48x48/apps/ca-management.png (yast-ca-management.png) Processing file ./src/ca_mgm.desktop Processing file ./src/common_cert.desktop All used icons (in desktop files): yast-ca_mgm yast-common_cert --- cut --- Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

2 1

[yast-devel] test suite not run
by Martin Vidner 16 Jul '07

16 Jul '07

Hi hackers, thanks to a watchful user I noticed that one of my packages was not running the test suite while building. The problem is that if dejagnu is not installed, automake only prints this warning and goes on: WARNING: could not find `runtest' Simply add "BuildRequires: dejagnu" to *.spec.in (and then fix the test cases that broke in the meantime, bother...) These packages are affected*: libzypp-testsuite-tools yast2-ca-management yast2-ncurses yast2-online-update yast2-pkg-bindings yast2-slp *: cd /work/built/dists/all/i386/packs-i386; find . -maxdepth 3 -name Logfile.\* | LANG=C sort | xargs grep '^WARNING.*runtest' -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] Postponing metapackage/single click install to post 10.3
by Benji Weber 13 Jul '07

13 Jul '07

Greetings all, I unfortunately don't think it is going to be possible to get the metapackage handler / single click install feature ready for 10.3. The current situation is: - There is a version in factory with major bugs and incomplete functionality. - There is a version I'm working on using the new specification [http://en.opensuse.org/Standards/One_Click_Install] which I am unlikely to have time to complete within the next 2 weeks, as I am still working full time and moving house. As I understand it, alpha 6 (final alpha) freeze is this Friday. This is entirely my fault as I drastically underestimated the amount of time I would require to complete the implementation of the handler for the finalised specification of the metapackages, and consequently wasted too much time working on a ycp -> codedom project. I have hit a number of problems that have delayed me considerably, particularly as with mvidner away there is no YCP guru on IRC. Causing me particular delays at present are: - Buggy/undefined behaviour of yast2-pkg-bindings, particularly deleting packages and some of the resolvable functions seem to not be working properly at all, but debugging these is slow. I will post testcases when I have them. - YCP's lack of object orientation means even the simplest additional feature in the XML tends to lead to a ballooning of fragile logic within the handling code. Even with the YCPXML helper to hide the lists of maps of lists mess it is taking me far too long just to write code that works at all, let alone robust or testable. There is also a considerable amount of work to do even if development were complete, for example chasing getting mimetype associations into each browser package. Given the problems I am encountering and given our timescales I think the only option now may be to delay inclusion of this to post-10.3 and re-think the design. Probably implement the XML handling and communication with package manager in some other language/platform and possibly use YCP/YaST just for the GUI. We can also watch what ubuntu are doing with their similar project [http://www.cypherbios.org/blog/?p=41&language=en] and see if we can learn any lessons. Any advice is appreciated. _ Benjamin Weber -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 4

[yast-devel] shell menu generation
by Scott Reeves 11 Jul '07

11 Jul '07

GNOME uses the freedesktop menu and .desktop spec standards to generate all it's menus - the traditional menu, the application browser and the control center. This method uses a .menu file and the Category= line from .desktop files to determine which menu entry a .desktop file falls into. AFAIK KDE also uses this for it's main top level menu. As of sp1 we added the yast2 control center which also uses this method. I was not involved in the very start of this so I don't want to speak incorrectly but I think a .menu file was generated that simply contained all the menu categories that currently showed in the qt shell. Then it used the already existing Categories= lines in .desktop files like /usr/share/applications/YaST2/users.desktop Unfortunately, that means there is currently two ways to generate the yast2 menus - the yast2 specific way using the X-SuSE-YaST-Group key and the Category= way. Towards the end of SP1 we ran into some issues with this. Using the .menu/.desktop specs to generate the menus means we get common code shared between all the menus and we can use the standard gmenu library to parse all the relevant information from the .desktop files including supporting all the other tags such as OnlyShowIn, Hidden, ... Could we move to supporting the .menu/.desktop spec way of generating menus for the yast shells – given that almost all of the existing .desktop files contain some sort of “Categories=X-SuSE-YaST-*” line it appears something along that lines is already under way. -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 6

[yast-devel] yast-kdump screen shots
by Maneesh Soni 09 Jul '07

09 Jul '07

Hi Jozef There are few more changes which I think would be good to have. Please let me know if these are possible to make or not. 1. Start-up ----------- Please move the "kdump memory" settings from "Dumping" screen to "Start up". As, IMHO, the start-up setting should have the minimum things which are absolutely necessary for enabling kdump service. Without reserving memory one cannot enable kdump. 2. Save Dump Image ----------------- IMHO, we can rename the tittle to something like "Dump Target Settings". The other options looks great. Only a couple of issues, firstly, in case of "Raw Disk", I think the "Directory for saving Dumps" is not needed. Secondly, for NFS, I think "Share" is not needed. 3. Expert Settings ------------------ IMHO, this tab should contain all the settings which normally user will not change. Apart from kdump kernel command like options, we can move the setting wrt "No. of Old Dumps" from "Dumping" screen to expert settings. Also can we put one more option to use a custom kdump kernel initrd which can be used save/process the dump. 4. Dump-filtering ----------------- I think we should either merge this with "Dump Target Settings" or if there is not much space left there, then a separate screen. Please let me know if these make sense or not. Regards Maneesh -- Maneesh Soni Linux Technology Center, IBM India Systems and Technology Lab, Bangalore, India -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 21

[yast-devel] Submitted libzypp-3.11.1 and yast2-qt-2.15.6 to BETA
by Michael Andres 09 Jul '07

09 Jul '07

yast2-qt-2.15.6 in BETA is ready to be tested. Esp. the former InstSource view - now 'repository'. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma(a)novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

2 1

[yast-devel] Changing YaST Packages in Autobuild
by Lukas Ocilka 09 Jul '07

09 Jul '07

Hi, It happens time to time that someone needs to urgently change some YaST package in autobuild. This is actually possible but you should know that autobuild is not the primary source of YaST packages. Our primary source is our SVN: http://svn.opensuse.org/svn/yast/ First, you had better contact the MAINTAINER of the package and consult the change with him/her. You can change the package in autobuild but you need to send a diff file to the maintainer or change SVN as well. Please, NEVER submit a changed package to autobuild without announcing the change to the maintainer of the package and without providing the patch or changing the source directly in SVN. Thanks & Bye Lukas -- Lukas Ocilka, YaST Developer (xn--luk-gla45d) ----------------------------------------------------------------- SUSE LINUX, s. r. o., Lihovarska 1060/12, Praha 9, Czech Republic

1 0

[yast-devel] Submitting libzypp-3.11.0 to BETA
by Michael Andres 05 Jul '07

05 Jul '07

- Package::location is now returns an OnMediaLocation - ResObject::archivesize() renamed to downloadSize() At least the above requires changes to zypper, kg-bindings and the UIs. - Allow to iterate all Repositories that contribute Resolvables to the Pool. - MediaSetAccess::provideDir added - remove useless url check - add old-api-style wrapper - Add MediaProducts class - revision 5892 - version 3.11.0 -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma(a)novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] [RFC] QueryBuilder and (Resolvable)Query
by Jan Kupec 05 Jul '07

05 Jul '07

Hi! Here is my proposal of a new libzypp API for various metadata queries. It should be useful for YaST package managers, zypper, YaST online update and maybe others. Pease see attached QueryBuilder.h file and comment on the design and usability. QueryBuilder is meant to build an sqlite query for libzypp's metadata cache database and to be used by ResolvableQuery::query(QueryBuilder,ProcessingFunctor) function (or other Query class) to do complex resolvable data queries. Result of these queries will be processed by ProcessingFunctor (read on). The reason to create such an API is to have a convenient API for coding various kinds of user queries, so that apps using libzypp don't have to code the functionality by themselves by traversing the resolvable pool. And since we (will hopefully) have the new metadata cache database, there is another reason: to make use of the database to speed up the search and save memory requirements (don't load the pool, just query the database). I would have to code it once in zypper anyway, so this way it can be reused by others as well. CODE EXAMPLE: //////// code START ///////////////////////////////////////// bool is_regexp; // treat the search string as regexp? bool search_summaries; // search also in summaries? string search_string; // user given search string Resolvable::Kind kind; // the result will be limited to this kind <snip> zypp::cache::QueryBuilder builder; builder.addName(search_string, is_regexp); if (search_summaries) builder.addAttribute(zypp::cache::attrResObjectSummary(), search_string, is_regexp); builder.addKind(kind); zypp::cache::ResolvableQuery resquery; resquery.query(builder, processing_functor); //////// code END ///////////////////////////////////////// (the functor is function<bool( const data::RecordId &, data::ResObject_Ptr )> we can provide one which would use Selectables (or NameKindProxy) for yast as well) FEATURES - search by name, any cache attribute, kind, (future: installed status), version - uses simple strings or regexes - search by dependencies (select resolvables which are required by e.g. pattern X) - use multiple search conditions and choose to require all or any of them satisfied. IMPLEMENTATION - based on given arguments and options, an sqlite command will be built This command will be executed by a ResolvableQuery::query() or another Query class (see attachment - just a stub). - i decided to write field values into the sqlite command string itself. Using variable names and bind values to them would be too complex. - regexes - sqlite's REGEXP keyword will be used, bound to user (libzypp) defined regexp matching function of our liking. ISSUES - what regexp syntax do we want to support? - something missing/to be changed in the API? Cheers, Jano

5 9

[yast-devel] Changeset 39159 adds XML representation to YCP
by Klaus Kaempf 05 Jul '07

05 Jul '07

As part of hackweek project http://idea.opensuse.org/content/ideas/ycp-to-ruby-translator I just committed changeset #39159 to yast-core on svn trunk. This changeset adds toXml() methods to all YCP and YCode classes, giving all ycp code and data structures a representation as XML. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

3 6

[yast-devel] pkg-bindings in BETA - status
by Ladislav Slezak 04 Jul '07

04 Jul '07

Hi all, I just have submitted yast2-pkg-bindings to BETA. Many bindings have partial or empty implementation and it's completely untested. But it at least compiles and we should be able to see really failing packages in BETA (the failures which are not caused by dependency to pkg-bindings). It needs the latest libzypp from SVN, it might be still failing in autobuild until libzypp is submitted. If anybody is interested in fixing/improving pkg-bindings just check it out from http://svn.opensuse.org/svn/yast/branches/REFACTORING-10_3/pkg-bindings/ Look for '#warning', 'TODO' and 'FIXME' strings for missing functionality. (BTW I'll be out of office until the next Monday.) Ladislav -- 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 For additional commands, e-mail: yast-devel+help(a)opensuse.org

1 0

[yast-devel] Regarding "Installation source" vs "Repository"
by Andreas Jaeger 04 Jul '07

04 Jul '07

Hi Guys, there have been quite some discussions regarding the terms "Installation Source", "Repository" and "Catalogs". Product Management had decided that for SLES10 and SLED10 - and products based on that the term "Catalogs" is to be used. We want to use the same name in all cases and therefore consider changing it for our products and this involves some discussions. There was no management decision at all to use "Catalog" for future products, Rebecca seems to have misunderstood something. As you've noticed, there's some confusion on how to move forward. I'm travelling right now and will continue this discussion to get everybody - both you as community and us Novell folks - aligned on this. I'm sorry for how this currently pops up and I'm not happy about it. Regards, Andreas P.S. As I'm travelling I haven't had time to read the complete discussion. Please bear with me - I might not be online before tuesday again. -- Andreas Jaeger, aj(a)suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

1 2

[yast-devel] Wizard dialogs without help?
by Johannes Meixner 03 Jul '07

03 Jul '07

Hello, for HackWeek I am working on an experimental YaST module, see http://idea.opensuse.org/content/ideas/usable-printer-setup-tool Currently I use for the dialogs something like -------------------------------------------------------------- Wizard::SetContentsButtons ( caption, contents, HELPS["basic_add_dialog"]:"", Label::BackButton(), Label::NextButton() ); -------------------------------------------------------------- Is it possible to get Wizard dialogs without help sub-window? I.e. have full-screen contents? Reason 1: My superb new innovative dialogs (TM) are fully self-explanatory so that there is no need for any help text at all. Reason 2: I read in books from usability experts that a UI is very likely bad designed when explanation texts (aka. help texts) are needed. Reason 3: My superb new innovative dialogs (TM) are perfectly designed ;-) Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: yast-devel+help(a)opensuse.org

9 21