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
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
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
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
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
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
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.pnghttp://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
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
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
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