Hello community,
here is the log from the commit of package yast2-installation for
openSUSE:Factory checked in at 2014-12-03 22:52:14
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/yast2-installation (Old)
and /work/SRC/openSUSE:Factory/.yast2-installation.new (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "yast2-installation"
Changes:
--------
--- /work/SRC/openSUSE:Factory/yast2-installation/yast2-installation.changes
2014-11-18 22:55:55.000000000 +0100
+++
/work/SRC/openSUSE:Factory/.yast2-installation.new/yast2-installation.changes
2014-12-03 22:52:16.000000000 +0100
@@ -1,0 +2,6 @@
+Wed Nov 26 16:53:17 UTC 2014 - [email protected]
+
+- Added more debug information in order to track bnc#897091
+- 3.1.122
+
+-------------------------------------------------------------------
Old:
----
yast2-installation-3.1.121.tar.bz2
New:
----
yast2-installation-3.1.122.tar.bz2
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ yast2-installation.spec ++++++
--- /var/tmp/diff_new_pack.yy5GQm/_old 2014-12-03 22:52:17.000000000 +0100
+++ /var/tmp/diff_new_pack.yy5GQm/_new 2014-12-03 22:52:17.000000000 +0100
@@ -17,7 +17,7 @@
Name: yast2-installation
-Version: 3.1.121
+Version: 3.1.122
Release: 0
BuildRoot: %{_tmppath}/%{name}-%{version}-build
++++++ yast2-installation-3.1.121.tar.bz2 -> yast2-installation-3.1.122.tar.bz2
++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/yast2-installation-3.1.121/doc/Makefile.am
new/yast2-installation-3.1.122/doc/Makefile.am
--- old/yast2-installation-3.1.121/doc/Makefile.am 2014-11-14
18:39:11.000000000 +0100
+++ new/yast2-installation-3.1.122/doc/Makefile.am 2014-11-26
16:03:23.000000000 +0100
@@ -1,4 +1,4 @@
-SUBDIRS = autodocs proposal
+SUBDIRS = autodocs
doc_DATA = *.html
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/yast2-installation-3.1.121/doc/proposal/Makefile.am
new/yast2-installation-3.1.122/doc/proposal/Makefile.am
--- old/yast2-installation-3.1.121/doc/proposal/Makefile.am 2014-11-14
18:39:11.000000000 +0100
+++ new/yast2-installation-3.1.122/doc/proposal/Makefile.am 1970-01-01
01:00:00.000000000 +0100
@@ -1,27 +0,0 @@
-
-xml_files = $(wildcard *.xml)
-
-html_DATA = $(wildcard html/*.html) \
- html/yast2docs.css
-
-all-local: html/index.html
-
-html/index.html: proposal-API-doc.xml
- XML_CATALOG_FILES=@XML_CATALOG@ \
- @XSLTPROC@ @XSLTPROC_FLAGS@ --xinclude \
- @STYLESHEET_HTML@ $<
-
-html/yast2docs.css: html/index.html
- cp @STYLESHEET_CSS@ html
- cp -a `pkg-config --variable=yast2dir
yast2-devtools`/data/docbook/images html
-
-EXTRA_DIST = $(xml_files) dummy_proposal.rb
-
-CLEANFILES = $(html_DATA)
-
-clean-local:
- rm -rf html
-
-install-data-local:
- mkdir -p $(DESTDIR)$(htmldir)
- cp -a $(srcdir)/html/images $(DESTDIR)$(htmldir)
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/yast2-installation-3.1.121/doc/proposal/dummy_proposal.rb
new/yast2-installation-3.1.122/doc/proposal/dummy_proposal.rb
--- old/yast2-installation-3.1.121/doc/proposal/dummy_proposal.rb
2014-11-14 18:39:11.000000000 +0100
+++ new/yast2-installation-3.1.122/doc/proposal/dummy_proposal.rb
1970-01-01 01:00:00.000000000 +0100
@@ -1,78 +0,0 @@
-# encoding: utf-8
-
-# Module: proposal_dummy.ycp
-#
-# $Id$
-#
-# Author: Stefan Hundhammer <[email protected]>
-#
-# Purpose: Proposal function dispatcher - dummy version.
-# Use this as a template for other proposal dispatchers.
-# Don't forget to replace all fixed values with real
values!
-#
-# See also file proposal-API.txt for details.
-module Yast
- class DummyProposalClient < Client
- def main
- textdomain "installation"
-
- @func = Convert.to_string(WFM.Args(0))
- @param = Convert.to_map(WFM.Args(1))
- @ret = {}
-
- if @func == "MakeProposal"
- @force_reset = Ops.get_boolean(@param, "force_reset", false)
- @language_changed = Ops.get_boolean(@param, "language_changed", false)
-
- # call some function that makes a proposal here:
- #
- # DummyMod::MakeProposal( force_reset );
-
- # Fill return map
-
- @ret = {
- "raw_proposal" => [
- "proposal item #1",
- "proposal item #2",
- "proposal item #3"
- ],
- "warning" => "This is just a dummy proposal!",
- "warning_level" => :blocker
- }
- elsif @func == "AskUser"
- @has_next = Ops.get_boolean(@param, "has_next", false)
-
- # call some function that displays a user dialog
- # or a sequence of dialogs here:
- #
- # sequence = DummyMod::AskUser( has_next );
-
-
- # Fill return map
-
- @ret = { "workflow_sequence" => :next }
- elsif @func == "Description"
- # Fill return map.
- #
- # Static values do just nicely here, no need to call a function.
-
- @ret = {
- # this is a heading
- "rich_text_title" => _("Dummy"),
- # this is a menu entry
- "menu_title" => _("&Dummy"),
- "id" => "dummy_stuff"
- }
- elsif @func == "Write"
- # Fill return map.
- #
-
- @ret = { "success" => true }
- end
-
- deep_copy(@ret)
- end
- end
-end
-
-Yast::DummyProposalClient.new.main
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/yast2-installation-3.1.121/doc/proposal/proposal-API-doc.xml
new/yast2-installation-3.1.122/doc/proposal/proposal-API-doc.xml
--- old/yast2-installation-3.1.121/doc/proposal/proposal-API-doc.xml
2014-11-14 18:39:11.000000000 +0100
+++ new/yast2-installation-3.1.122/doc/proposal/proposal-API-doc.xml
1970-01-01 01:00:00.000000000 +0100
@@ -1,38 +0,0 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"/usr/share/xml/docbook/schema/dtd/4.2/docbookx.dtd"[
-
-
-<!ENTITY proposal-section SYSTEM "proposal-API-section.xml">
-<!ENTITY proposal-reference SYSTEM "proposal-API-reference.xml">
-
-
-
-]>
-<book>
- <bookinfo>
- <title>YaST2 Proposal API</title>
- <subtitle>API for YaST2 installation proposal</subtitle>
- <authorgroup>
- <author>
- <firstname>Stefan</firstname>
- <surname>Hundhammer</surname>
- <affiliation>
- <orgname> SUSE Linux AG</orgname>
- </affiliation>
- </author>
- </authorgroup>
- <corpauthor>SUSE Linux AG</corpauthor>
- <copyright>
- <year>2004</year>
- <holder> SUSE Linux AG</holder>
- </copyright>
- </bookinfo>
-
-
- <toc>
- </toc>
-
- &proposal-section;
- &proposal-reference;
-</book>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/yast2-installation-3.1.121/doc/proposal/proposal-API-reference.xml
new/yast2-installation-3.1.122/doc/proposal/proposal-API-reference.xml
--- old/yast2-installation-3.1.121/doc/proposal/proposal-API-reference.xml
2014-11-14 18:39:11.000000000 +0100
+++ new/yast2-installation-3.1.122/doc/proposal/proposal-API-reference.xml
1970-01-01 01:00:00.000000000 +0100
@@ -1,454 +0,0 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-<section id="proposal_api_reference">
- <title>Proposal API Reference</title>
-
- <para><!-- FIXME: explanatory para --></para>
-
- <section id="proposal_MakeProposal">
- <title>MakeProposal</title>
- <subtitle>Make proposal for installation.</subtitle>
-
- <para>
- <emphasis>map</emphasis> <literal>MakeProposal</literal>(
- <emphasis>boolean</emphasis> <literal>force_reset</literal>,
- <emphasis>boolean</emphasis> <literal>language_changed</literal> )
- </para>
-
- <section>
- <title>Parameters</title>
-
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>boolean</emphasis> <literal>force_reset</literal>
- </para>
- <para>
- If 'true', discard anything that may be cached and start over from
- scratch. If 'false', use cached values from the last invocation if
- there are any.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>boolean</emphasis> <literal>language_changed</literal>
- </para>
- <para>The installation language has changed since the last call of
- <literal>MakeProposal</literal>. This is important only if there
- is a language change mechanism in one of the other submodules.
- If this parameter is "true", any texts the user can see in
- the proposal need to be retranslated. The internal translator mechanism
- will take care of this itself if the corresponding strings are once more
- put through it (the <literal>_("...")</literal> function). Only very few
- submodules that translate any strings internally based on internal maps
- (e.g., keyboard etc.) need to take more action.
- </para>
- </listitem>
-
- </itemizedlist>
- </section>
-
- <section>
- <title>Return Values</title>
- <para>
- <literal>MakeProposal()</literal> returns a map containing:
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>list<string></emphasis> <literal>links</literal>
- </para>
- <para>
- A list of additional hyperlink ids used in summaries returned by this
- section. All possible values must be included.
- </para>
- <para>Example:</para>
- <programlisting>["device_enable", "device_test"]</programlisting>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>string</emphasis> <literal>preformatted_proposal</literal>
- (optional)
- </para>
- <para>
- Human readable proposal preformatted in HTML.
- </para>
- <note>
- <para>
- You can use the HTML:: module for such formatting.
- </para>
- </note>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>list</emphasis> <literal>raw_proposal</literal>
- </para>
- <para>
- (only used if 'preformatted_proposal' is not present in the result map)
- </para>
- <para>
- Human readable proposal, not formatted yet. The caller will format each
- list item (string) as a HTML list item
- <literal>( "<li> ... </li>" )</literal>.
- </para>
- <para>
- The proposal can contain hyperlinks with ids listed in the list
- <literal>links</literal>.
- </para>
- <para>
- The caller will make a HTML unsorted list of this, e.g.:
- </para>
- <programlisting><ul>
-<li>string from list element #1</li>
-<li>string from list element #2</li>
-<li>string from list element #3</li>
-...
-</ul></programlisting>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>string</emphasis> <literal>warning</literal> (optional)
- </para>
- <para>
- Warning in human readable format without HTML tags other
- than <br>.
- </para>
- <para>
- The warning will be embedded in appropriate HTML format specifications
- according to 'warning_level' below.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>symbol</emphasis> <literal>warning_level</literal> (optional)
- </para>
- <para>
- Determines the severity and the visual display of the warning.
- Valid values:
- </para>
- <itemizedlist>
- <listitem>`notice</listitem>
- <listitem>`warning (default)</listitem>
- <listitem>`error</listitem>
- <listitem>`blocker</listitem>
- <listitem>`fatal</listitem>
- </itemizedlist>
- <para>
- <emphasis>`blocker</emphasis> will prevent the user from continuing the
- installation. If any proposal contains a `blocker warning, the "accept"
- button in the proposal dialog will be disabled - the user needs to fix
- that blocker before continuing.
- </para>
- <para>
- <emphasis>`fatal</emphasis> is like `blocker but also stops building
- the proposal
- </para>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>boolean</emphasis> <literal>language_changed</literal>
- (optional)
- </para>
- <para>
- This module just caused a change of the installation language. This is
- only relevant for the "language" module.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>boolean</emphasis> <literal>mode_changed</literal> (optional)
- </para>
- <para>
- This module just caused a change of the installation mode. This is only
- relevant for the "inst mode" module.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>boolean</emphasis> <literal>rootpart_changed</literal>
- (optional)
- </para>
- <para>
- This module just caused a change of the root partition. This is only
- relevant for the "root part" module.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>string</emphasis> <literal>help</literal>
- (optional)
- </para>
- Helptext for this module which appears in the standard dialog
- help (particular helps for modules sorted by presentation order).
- <para>
- </para>
- </listitem>
-
- </itemizedlist>
- </section>
- </section>
-
- <section id="proposal_AskUser">
- <title>AskUser</title>
- <subtitle>Run an interactive workflow</subtitle>
-
- <para>
- <emphasis>map</emphasis> <literal>AskUser</literal>(
- <emphasis>boolean</emphasis> <literal>has_next</literal>,
- <emphasis>string</emphasis> <literal>chosen_id</literal> )
- </para>
-
- <section>
- <title>Parameters</title>
-
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>boolean</emphasis> <literal>has_next</literal>
- </para>
-
- <para>
- Use a "next" button even if the module by itself has only one step, thus
- would normally have an "OK" button - or would rename the "next" button
- to something like "finish" or "accept".
- </para>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>string</emphasis> <literal>chosen_id</literal>
- </para>
-
- <para>
- If a section proposal contains hyperlinks and user clicks on one of them,
- this defines the id of the hyperlink. All hyperlink IDs must be set in
- the map retuned by <literal>Description</literal>. If a user didn't click
- on a proposal hyperlink, this parameter is not defined.
- </para>
- </listitem>
-
- </itemizedlist>
- </section>
-
- <section>
- <title>Description</title>
-
- <para>
- Run an interactive workflow - let user decide upon values he might want
- to change. May contain one single dialog, a sequence of dialogs or one
- master dialog with one or more "expert" dialogs. The module is responsible
- for controlling the workflow sequence (i.e., "next", "back" buttons etc.).
- </para>
-
- <para>
- Submodules don't provide an "abort" button to abort the entire
- installation. If the user wishes to do that, he can always go back to
- the main dialog (the installation proposal) and choose "abort" there.
- </para>
- </section>
-
- <section>
- <title>Return Values</title>
-
- <para>
- <literal>AskUser()</literal> returns a map containing:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <emphasis>symbol</emphasis> workflow_sequence
- </para>
-
- <itemizedlist>
- <listitem>
- <para>
- <literal>`next</literal> (default)
- </para>
- <para>
- Everything OK - continue with the next step in workflow sequence.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>`back</literal>
- </para>
- <para>
- User requested to go back in the workflow sequence.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>`again</literal>
- </para>
- <para>
- Call this submodule again (i.e., re-initialize the submodule)
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>`auto</literal>
- </para>
- <para>
- Continue with the workflow sequence in the current direction
- - forward if the last submodule returned `next, backward otherwise.
- </para>
- </listitem>
-
- <listitem>
- <para>
- <literal>`finish</literal>
- </para>
- <para>
- Finish the installation. This is specific to "inst_mode.ycp" when
- the user selected "boot system" there.
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>boolean</emphasis> language_changed (optional)
- </para>
- <para>
- This module just caused a change of the installation language. This is
- only relevant for the "language" module.
- </para>
- </listitem>
-
- </itemizedlist>
- </section>
- </section>
-
- <section id="proposal_Description">
- <title>Description</title>
- <subtitle>Return human readable titles both for the RichText (HTML) widget
- and for menuentries.</subtitle>
-
- <para>
- <emphasis>map</emphasis> <literal>Description</literal>()
- </para>
-
- <section>
- <title>Return Values</title>
- <para>Returns a map containing:</para>
- <itemizedlist>
-
- <listitem>
- <para>
- <emphasis>string</emphasis> <literal>rich_text_title</literal>
- </para>
- <para>
- (Translated) human readable title for this section in
- the <literal>RichText</literal> widget without any HTML formatting.
- This will be embedded in
- </para>
- <screen><h3><a href="???"> ... </a></h3></screen>
- <para>
- so make sure not to add any additional HTML formatting.
- </para>
- <para>
- Keyboard shortcuts are not (yet?) supported, so don't include
- any '&' characters.
- </para>
- <para>Example:</para>
- <programlisting>"Input devices"</programlisting>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>string</emphasis> <literal>menu_title</literal>
- </para>
- <para>
- (Translated) human readable menuentry for this section. Must contain
- a keyboard shortcut ('&'). Should NOT contain trailing periods
- ('...') - the caller will add them.</para>
- <para>Example:</para>
- <programlisting>"&Input devices"</programlisting>
- </listitem>
-
- <listitem>
- <para>
- <emphasis>string</emphasis> <literal>id</literal>
- </para>
- <para>
- Programmer readable unique identifier for this section. This is not
- auto-generated to keep the log file readable.</para>
- <para>Example:</para>
- <programlisting>"input_dev"</programlisting>
- </listitem>
- </itemizedlist>
-
- <para>
- This map may be empty. In this case, this proposal section will silently
- be ignored. Proposals modules may use this if there is no useful proposal
- at all. Use with caution - this may be confusing for the user.
- </para>
-
- <note>
- <para>
- In this case, all other proposal functions must return a useful success
- value so they can be called without problems.
- </para>
- </note>
- </section>
- </section>
-
- <section id="proposal_Write">
- <title>Write</title>
- <subtitle>
- Write the proposed (and probably modified) settings to the system.
- </subtitle>
-
- <para>
- <emphasis>map</emphasis> <literal>Write</literal>()
- </para>
-
- <section>
- <title>Description</title>
-
- <para>
- Write the proposed (and probably modified) settings to the system.
- It is up to the proposal dispatcher how it remembers the settings.
- The errors must be reported using the Report:: module to have
- the possibility to control the behaviour from the main program.
- </para>
-
- <para>
- This Write() function is optional. The dispatcher module is required
- to allow this function to be called without returning an error value
- if it isn't there.
- </para>
- </section>
-
- <section>
- <title>Return Values</title>
-
- <para>Returns a map containing:</para>
- <itemizedlist>
-
- <listitem>
- <para>
- <emphasis>boolean</emphasis> <literal>success</literal>
- </para>
- <para>
- Returns true, if the settings were written successfully.
- </para>
- </listitem>
-
- </itemizedlist>
- </section>
- </section>
-</section>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/yast2-installation-3.1.121/doc/proposal/proposal-API-section.xml
new/yast2-installation-3.1.122/doc/proposal/proposal-API-section.xml
--- old/yast2-installation-3.1.121/doc/proposal/proposal-API-section.xml
2014-11-14 18:39:11.000000000 +0100
+++ new/yast2-installation-3.1.122/doc/proposal/proposal-API-section.xml
1970-01-01 01:00:00.000000000 +0100
@@ -1,164 +0,0 @@
-<?xml version="1.0" encoding="ISO-8859-1"?>
-<section id="proposal_api">
- <title>
- API for YaST2 installation proposal
- </title>
-
- <section id="proposal_api_motivation">
- <title>Motivation</title>
-
- <para>
- After five releases, YaST2 is now smart enough to make reasonable
proposals for
- (near) every installation setting, thus it is no longer necessary to ask
the
- user that many questions during installation: Most users simply hit the
[next]
- button anyway.
- </para>
-
- <para>
- Hence, YaST2 now collects all the individual proposals from its
submodules and
- presents them for confirmation right away. The user can change each
individual
- setting, but he is no longer required to go through all the steps just to
- change some simple things. The only that (currently) really has to be
queried
- is the installation language - this cannot reasonably be guessed (yet?).
- </para>
-
- <para>
- The new YaST2 installation includes the following steps:
- </para>
- <itemizedlist>
- <listitem><para>(Minimal) hardware probing - no user interaction
- required</para></listitem>
- <listitem><para>Language selection - user picks installation
- language</para></listitem>
-
- <listitem><para>Installation proposal - very much like the old
installation summary just
- before the real installation started, only this time the user CAN
change
- settings by clicking into the summary (or via a separate menu as a
- fallback).</para></listitem>
-
- <listitem><para>Create / format partitions according to proposal / user
selection - no user
- interaction required</para></listitem>
-
- <listitem><para>Install software packages from CD / DVD / other
installation
- media</para></listitem>
- </itemizedlist>
-
- <para>
- After this, all that is remained left is basic system configuration like:
- </para>
-
- <itemizedlist>
- <listitem><para>X11</para></listitem>
- <listitem><para>Network interface(s)</para></listitem>
- <listitem><para>Network services</para></listitem>
- <listitem><para>Additional hardware (printer, sound card, scanner,
...)</para></listitem>
- </itemizedlist>
-
- </section>
- <section id="proposal_api_overview">
- <title>Overview</title>
- <para>YaST2 installation modules should cooperate with the main program in
a
- consistent API. General usage:</para>
-
- <itemizedlist>
-
- <listitem><para>inst_proposal (main program) creates empty dialog with
- RichText widget</para></listitem>
-
- <listitem><para>inst_proposal calls each sub-module in turn to
- make proposal</para></listitem>
-
- <listitem><para>user may choose to change individual settings
- (i.e., clicks on a hyperlink)</para></listitem>
-
- <listitem><para>inst_proposal starts that module's sub-workflow which
runs independently.
- After this, inst_proposal tells all subsequent (all?) modules to check
- their states and return whether a change of their proposal is
necessary
- after the user interaction.</para></listitem>
-
- <listitem><para>main program calls each sub-module to write the settings
to the
- system</para></listitem>
- </itemizedlist>
-
-
- </section>
- <section id="proposal_api_dispatcher_interface">
- <title>The Dispatcher Interface</title>
- <para>
- Each submodule provides a function dispatcher that can be called with
- 'CallFunction()'. The function to be called is passed as a parameter to
this
- dispatcher. Parameters to the function are passed as another parameter
in a
- map. The result of each call is a map, the contents of which depend on
the function
- called.</para>
- <para>
-
- The reason for this additional overhead is to provide extensibility and
- reusability for the installation workflow: A list of submodules to be
called is
- read from file. This requires, however, that no explicit 'mod::func()'
calls
- are used in 'inst_proposal.ycp'. Rather, the list contains the name of
the
- submodule. Since each submodule is required to provide an identical API,
this
- is sufficient.</para>
-
- <example>
- <title>Proposal Example</title>
- <para>
- Proposal is to call
- </para>
-
- <itemizedlist>
- <listitem><para>input_devices (keyboard, mouse)</para></listitem>
- <listitem><para>partitioning</para></listitem>
- <listitem><para>software_selection</para></listitem>
- <listitem><para>boot_loader</para></listitem>
- <listitem><para>timezone</para></listitem>
- </itemizedlist>
-
-
- <para>inst_proposal calls</para>
- <programlisting>
- map result = CallFunction (input_devices( "MakeProposal", $[
"force_reset" : false,
- "language_changed": false ] ) );
- map result = CallFunction (partitioning ( "MakeProposal", $[
"force_reset" : false,
- "language_changed": false ] ) );
- ...
-
- </programlisting>
- <para>
- If the user clicks on the hyperlink on "input_devices" in the proposal
display,
- inst_proposal calls:</para>
-
- <programlisting>
-
- map result = CallFunction (input_devices( "AskUser", $[ "has_next":
true ] ) );
- </programlisting>
- </example>
-
- </section>
- <section id="proposal_api_functions">
- <title>API functions</title>
- <note>
- <para>
- If any parameter is marked as "optional", it should only be specified if
- it contains a meaningful value. Don't add it with a 'nil' value.</para>
- </note>
-
- <para>The dispatcher provides the following functions:</para>
-
- <itemizedlist>
- <listitem id="proposal_MakeProposal">MakeProposal</listitem>
- <listitem id="proposal_AskUser">AskUser</listitem>
- <listitem id="proposal_Description">Description</listitem>
- <listitem id="proposal_Write">Write</listitem>
- </itemizedlist>
- </section>
- <section id="proposal_api_dummy_proposal">
- <title>Dummy Proposal</title>
- <programlisting>
-
- <xi:include href="dummy_proposal.rb" parse="text"
- xmlns:xi="http://www.w3.org/2001/XInclude"/>
-
- </programlisting>
- </section>
-
-</section>
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/yast2-installation-3.1.121/doc/proposal_api.md
new/yast2-installation-3.1.122/doc/proposal_api.md
--- old/yast2-installation-3.1.121/doc/proposal_api.md 1970-01-01
01:00:00.000000000 +0100
+++ new/yast2-installation-3.1.122/doc/proposal_api.md 2014-11-26
16:03:23.000000000 +0100
@@ -0,0 +1,167 @@
+# API for YaST2 installation proposal
+## Motivation
+After five releases, YaST2 is now smart enough to make reasonable proposals for
+(near) every installation setting, thus it is no longer necessary to ask the
+user that many questions during installation: Most users simply hit the [next]
+button anyway.
+
+Hence, YaST2 now collects all the individual proposals from its submodules and
+presents them for confirmation right away. The user can change each individual
+setting, but he is no longer required to go through all the steps just to
+change some simple things. The only that (currently) really has to be queried
+is the installation language - this cannot reasonably be guessed (yet?).
+
+## Overview
+YaST2 installation modules should cooperate with the main program in a
consistent API. General usage:
+
+* inst_proposal (main program) creates empty dialog with RichText widget
+
+* inst_proposal calls each sub-module in turn to make proposal
+
+* user may choose to change individual settings (i.e., clicks on a hyperlink)
+
+* inst_proposal starts that module's sub-workflow which runs independently.
+ After this, inst_proposal tells all subsequent (all?) modules to check their
+ states and return whether a change of their proposal is necessary after the
+ user interaction.
+
+* main program calls each sub-module to write the settings to the system
+
+## API functions
+If any parameter is marked as "optional", it should only be specified if
+it contains a meaningful value. Do not add it with a `nil` value.
+
+It is recommended to use Installation::ProposalClient as base class for new
clients.
+This base class, implemented in yast2-yast, provides automatic method
dispatching.
+
+### MakeProposal
+Makes proposal for installation.
+
+#### Parameters
+
+* _boolean_ `force_reset` If `true`, discard anything that may be cached and
+ start over from scratch. If `false`, use cached values from the last
+ invocation if there are any.
+
+* _boolean_ `language_changed` The installation language has changed since the
last call of
+ `MakeProposal`. This is important only if there is a language change
mechanism in one of the other submodules.
+ If this parameter is "true", any texts the user can see in
+ the proposal need to be retranslated. The internal translator mechanism
+ will take care of this itself if the corresponding strings are once more
+ put through it (the `_("...")` function). Only very few
+ submodules that translate any strings internally based on internal maps
+ (e.g., keyboard etc.) need to take more action.
+
+#### Return Values
+`MakeProposal()` returns a map containing:
+* _list\<string\>_ `links` A list of additional hyperlink ids used in
summaries returned by this
+ section. All possible values must be included.
+
+* _string_ `preformatted_proposal` (optional) Human readable proposal
preformatted in HTML. It is possible to use the HTML:: module for such
formatting.
+
+* _list_ `raw_proposal` (only used if 'preformatted_proposal' is not present
in the result map). Human readable proposal, not formatted yet. The caller will
format each
+ list item (string) as a HTML list item `( "<li> ... </li>" )`. The
proposal can contain hyperlinks with ids listed in the list `links`.
+* _string_ `warning` (optional) Warning in human readable format without HTML
tags other than `<br>`. The warning will be embedded in appropriate HTML format
specifications
+ according to 'warning_level' below.
+
+* _symbol_ `warning_level` (optional) Determines the severity and the visual
display of the warning.
+ Valid values:
+
+ * `:notice`
+ * `:warning (default)`
+ * `:error`
+ * `:blocker`
+ * `:fatal`
+
+ _:blocker_ will prevent the user from continuing the installation. If any
proposal contains a `:blocker` warning, the "accept"
+ button in the proposal dialog will be disabled - the user needs to fix that
blocker before continuing.
+
+ _:fatal_ is like `blocker but also stops building the proposal
+
+* _boolean_ `language_changed` This module just caused a change of the
installation language. This is only relevant for the "language" module.
+* _boolean_ `mode_changed` (optional) This module just caused a change of the
installation mode. This is only
+ relevant for the "inst mode" module.
+
+* _boolean_ `rootpart_changed` (optional) This module just caused a change of
the root partition. This is only
+ relevant for the "root part" module.
+
+* _string_ `help` (optional) Helptext for this module which appears in the
standard dialog
+ help (particular helps for modules sorted by presentation order).
+
+### AskUser
+Run an interactive workflow - let user decide upon values he might want to
change.
+May contain one single dialog, a sequence of dialogs or one master dialog with
+one or more "expert" dialogs. It can be also non-interactive click on
hyperlink.
+The module is responsible for controlling the workflow sequence (i.e., "next",
+"back" buttons etc.).
+
+Submodules do not provide an "abort" button to abort the entire installation.
If
+the user wishes to do that, he can always go back to the main dialog (the
+installation proposal) and choose "abort" there.
+
+#### Parameters
+
+* _boolean_ `has_next` Use a "next" button even if the module by itself has
only one step, thus
+ would normally have an "OK" button - or would rename the "next" button to
something like "finish" or "accept".
+
+* _string_ `chosen_id` If a section proposal contains hyperlinks and user
clicks on one of them,
+ this defines the id of the hyperlink. All hyperlink IDs must be set in the
map retuned by `Description`. If a user did not click
+ on a proposal hyperlink, this parameter is not defined.
+
+#### Return Values
+`AskUser()` returns a map containing:
+
+* _symbol_ workflow_sequence with possible values:
+
+ * `:next` (default) Everything OK - continue with the next step in workflow
sequence.
+
+ * `:back` User requested to go back in the workflow sequence.
+
+ * `:again` Call this submodule again (i.e., re-initialize the submodule)
+
+ * `:auto` Continue with the workflow sequence in the current direction
+ - forward if the last submodule returned `next, backward otherwise.
+
+ * `:finish` Finish the installation. This is specific to "inst_mode.ycp" when
+ the user selected "boot system" there.
+
+* _boolean_ language_changed (optional) This module just caused a change of
the installation language. This is
+ only relevant for the "language" module.
+
+### Description
+Return human readable titles both for the RichText (HTML) widget and for
menuentries.
+
+#### Return Values
+Returns a map containing:
+
+* _string_ `rich_text_title` (Translated) human readable title for this
section in
+ the `RichText` widget without any HTML formatting. This will be embedded in
+ `<h3><a href="#???"> ... </a></h3>` so make sure not to add any additional
HTML formatting.
+ Keyboard shortcuts are not (yet?) supported, so do not include any `&`
characters.
+
+* _string_ `menu_title` (Translated) human readable menuentry for this
section. Must contain
+ a keyboard shortcut ('&'). Should NOT contain trailing periods ('...') - the
caller will add them.
+
+* _string_ `id` Programmer readable unique identifier for this section. This
is not
+ auto-generated to keep the log file readable.
+
+
+This map may be empty. In this case, this proposal section will silently
+be ignored. Proposals modules may use this if there is no useful proposal
+at all. Use with caution - this may be confusing for the user.
+
+In this case, all other proposal functions must return a useful success
+value so they can be called without problems.
+
+### Write
+Write the proposed (and probably modified) settings to the system.
+It is up to the proposal dispatcher how it remembers the settings.
+The errors must be reported using the Report:: module to have
+the possibility to control the behaviour from the main program.
+
+This Write() function is optional. The dispatcher module is required
+ to allow this function to be called without returning an error value
+ if it is not there.
+
+#### Return Values
+Returns true, if the settings were written successfully.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/yast2-installation-3.1.121/package/yast2-installation.changes
new/yast2-installation-3.1.122/package/yast2-installation.changes
--- old/yast2-installation-3.1.121/package/yast2-installation.changes
2014-11-14 18:39:11.000000000 +0100
+++ new/yast2-installation-3.1.122/package/yast2-installation.changes
2014-11-26 18:26:08.000000000 +0100
@@ -1,4 +1,10 @@
-------------------------------------------------------------------
+Wed Nov 26 16:53:17 UTC 2014 - [email protected]
+
+- Added more debug information in order to track bnc#897091
+- 3.1.122
+
+-------------------------------------------------------------------
Fri Nov 14 09:51:04 UTC 2014 - [email protected]
- Merging changes from 3.1.116.1 (SLE12 maintenance branch)
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/yast2-installation-3.1.121/package/yast2-installation.spec
new/yast2-installation-3.1.122/package/yast2-installation.spec
--- old/yast2-installation-3.1.121/package/yast2-installation.spec
2014-11-14 18:39:11.000000000 +0100
+++ new/yast2-installation-3.1.122/package/yast2-installation.spec
2014-11-26 18:26:08.000000000 +0100
@@ -17,7 +17,7 @@
Name: yast2-installation
-Version: 3.1.121
+Version: 3.1.122
Release: 0
BuildRoot: %{_tmppath}/%{name}-%{version}-build
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/yast2-installation-3.1.121/src/clients/copy_logs_finish.rb
new/yast2-installation-3.1.122/src/clients/copy_logs_finish.rb
--- old/yast2-installation-3.1.121/src/clients/copy_logs_finish.rb
2014-11-14 18:39:11.000000000 +0100
+++ new/yast2-installation-3.1.122/src/clients/copy_logs_finish.rb
2014-11-26 18:26:08.000000000 +0100
@@ -32,6 +32,8 @@
#
module Yast
class CopyLogsFinishClient < Client
+ include Yast::Logger
+
def main
Yast.import "UI"
@@ -54,9 +56,9 @@
end
end
- Builtins.y2milestone("starting copy_logs_finish")
- Builtins.y2debug("func=%1", @func)
- Builtins.y2debug("param=%1", @param)
+ log.info "starting copy_logs_finish"
+ log.debug "func=#{@func}"
+ log.debug "param=#{@param}"
if @func == "Info"
return {
@@ -75,6 +77,8 @@
)
Builtins.foreach(@log_files) do |file|
+ log.debug "Processing file #{file}"
+
if file == "y2log" || Builtins.regexpmatch(file, "^y2log-[0-9]+$")
# Prepare y2log, y2log-* for log rotation
@@ -98,6 +102,7 @@
Directory.logdir,
target_basename
)
+ log.debug "Compress command: #{compress_cmd}"
WFM.Execute(path(".local.bash"), compress_cmd)
elsif Builtins.regexpmatch(file, "^y2log-[0-9]+\\.gz$")
target_no = Ops.add(
@@ -119,17 +124,16 @@
end
end
- WFM.Execute(
- path(".local.bash"),
- "/bin/cp /var/log/pbl.log
'#{Installation.destdir}/#{Directory.logdir}/pbl-instsys.log'"
- )
+ copy_cmd = "/bin/cp /var/log/pbl.log
'#{Installation.destdir}/#{Directory.logdir}/pbl-instsys.log'"
+ log.debug "Copy command: #{copy_cmd}"
+ WFM.Execute(path(".local.bash"), copy_cmd)
else
- Builtins.y2error("unknown function: %1", @func)
+ log.error "unknown function: #{@func}"
@ret = nil
end
- Builtins.y2debug("ret=%1", @ret)
- Builtins.y2milestone("copy_logs_finish finished")
+ log.debug "ret=#{@ret}"
+ log.info "copy_logs_finish finished"
deep_copy(@ret)
end
end
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/yast2-installation-3.1.121/src/include/installation/misc.rb
new/yast2-installation-3.1.122/src/include/installation/misc.rb
--- old/yast2-installation-3.1.121/src/include/installation/misc.rb
2014-11-14 18:39:12.000000000 +0100
+++ new/yast2-installation-3.1.122/src/include/installation/misc.rb
2014-11-26 18:26:08.000000000 +0100
@@ -125,17 +125,10 @@
end
def InjectFile(filename)
+ command = "/bin/cp #{filename} #{Installation.destdir}#{filename}"
Builtins.y2milestone("InjectFile: <%1>", filename)
- WFM.Execute(
- path(".local.bash"),
- Ops.add(
- Ops.add(
- Ops.add(Ops.add("/bin/cp ", filename), " "),
- Installation.destdir
- ),
- filename
- )
- )
+ Builtins.y2debug("Inject command: #{command}")
+ WFM.Execute(path(".local.bash"), command)
nil
# this just needs too much memory
@@ -145,25 +138,14 @@
def InjectRenamedFile(dir, src_name, target_name)
- Builtins.y2milestone(
- "InjectRenamedFile: <%1/%2> -> <%3/%4/%5>",
- dir,
- src_name,
- Installation.destdir,
- dir,
- target_name
- )
- WFM.Execute(
- path(".local.bash"),
- Builtins.sformat(
- "/bin/cp %1/%2 %3/%4/%5",
- dir,
- src_name,
- Installation.destdir,
- dir,
- target_name
- )
- )
+ src = "#{dir}/#{src_name}"
+ target = "#{Installation.destdir}/#{dir}/#{target_name}"
+ command = "/bin/cp #{src} #{target}"
+
+ Builtins.y2milestone("InjectRenamedFile: <%1> -> <%2>", src, target)
+ Builtins.y2debug("Inject command: #{command}")
+
+ WFM.Execute(path(".local.bash"), command)
nil
end
--
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
