YaST Development July 2007

yast-devel@lists.opensuse.org

24 participants
29 discussions

[yast-devel] yast2-devtools: make %{?jobs:-j%jobs} ins slide-show

by Karl Eichwalder

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

13 years, 12 months

[yast-devel] Installing Patterns

by Benji Weber

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

13 years, 12 months

[yast-devel] MetaPackage status

by Benji Weber

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

13 years, 12 months

[yast-devel] ruby bindings

by Duncan Mac-Vicar P.

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

13 years, 12 months

[yast-devel] Privilege escalation within a YaST module.

by Benji Weber

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

14 years

[yast-devel] Privilege escalation within a YaST module.

by Benji Weber

14 years

[yast-devel] YCP syntax highlighting in kate

by Benji Weber

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

14 years

Re: [yast-devel] Let's make minimal system smaller :) (41 MB)

by Jiri Srain

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

14 years

[yast-devel] SLES10 SP1 YaST Documentation Available

by Lukas Ocilka

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

14 years

[yast-devel] Let's make minimal system smaller :) (41 MB)

by Lukas Ocilka

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

14 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

YaST Development July 2007