Merge branch 'SLE-12-SP2' into proposal_store_fix

CONTRIBUTING.md

@@ -3,7 +3,7 @@ YaST Contribution Guidelines
 
 YaST is an open source project and as such it welcomes all kinds of
 contributions. If you decide to contribute, please follow these guidelines to
-ensure the process is effective and pleasant both for you and YaST maintainers.
+ensure the process is effective and pleasant both for you and the YaST maintainers.
 
 There are two main forms of contribution: reporting bugs and performing code
 changes.
@@ -17,13 +17,11 @@ or [GitHub issues](../../issues). (For Bugzilla, use the [simplified
 registration](https://secure-www.novell.com/selfreg/jsp/createSimpleAccount.jsp)
 if you don't have an account yet.)
 
-If you find a problem, please report it either using
-[Bugzilla](https://bugzilla.suse.com/) or GitHub issues. We can't guarantee
-that every bug will be fixed, but we'll try.
-
 When creating a bug report, please follow our [bug reporting
 guidelines](http://en.opensuse.org/openSUSE:Report_a_YaST_bug).
 
+We can't guarantee that every bug will be fixed, but we'll try.
+
 Code Changes
 ------------
 
@@ -44,25 +42,29 @@ follows:
      to the [Ruby style
      guide](https://github.com/SUSE/style-guides/blob/master/Ruby.md).
 
-  4. Make sure your change didn't break anything by building the RPM package
+  4. Update the package version (in `packages/*.spec`, usually by
+     `rake version:bump`) and add a new entry to the `package/*.changes` file
+     (by `osc vc package`).  
+     For bigger changes or changes which need longer discussion it is advised to
+     add this as a separate last commit so it can be easily updated when another
+     change is merged in the meantime.
+
+  5. Make sure your change didn't break anything by building the RPM package
      (`rake osc:build`). The build process includes running the full testsuite.
 
-  5. Publish the branch and create a pull request.
+  6. Publish the branch and create a pull request.
 
-  6. YaST developers will review your change and possibly point out issues.
+  7. YaST developers will review your change and possibly point out issues.
      Adapt the code under their guidance until they are all resolved.
 
-  7. Finally, the pull request will get merged or rejected.
+  8. Finally, the pull request will get merged or rejected.
 
 See also [GitHub's guide on
 contributing](https://help.github.com/articles/fork-a-repo).
 
 If you want to do multiple unrelated changes, use separate branches and pull
 requests.
 
-Do not change the `VERSION` and `*.changes` files as this could lead to
-conflicts.
-
 ### Commits
 
 Each commit in the pull request should do only one thing, which is clearly

Rakefile

@@ -1,5 +1,7 @@
 require "yast/rake"
 
+Yast::Tasks.submit_to :sle12sp2
+
 Yast::Tasks.configuration do |conf|
   # lets ignore license check for now
   conf.skip_license_check << /.*/

doc/SELF_UPDATE.md

@@ -18,8 +18,36 @@ These are the basic steps performed by YaST in order to perform the update:
    containing the updates.
 2. If updates are available, they will be downloaded. Otherwise, the process
    will be silently skipped.
-3. The update will be applied to the installation system.
-4. YaST will be restarted and the installation will be resumed.
+3. The updates will be applied to the installation system.
+4. YaST will be restarted to reload the modified files and the installation
+   will be resumed.
+
+### Language Selection
+
+The self-update step is executed before selecting the language
+(`inst_complex_welcome` client). That means the self-update progress and
+the errors which happens during the self-update process are by default displayed
+in English.
+
+To use another language also for the self-update press `F2` in the DVD boot menu
+and select the language from the list. Or use the `language` boot option, e.g.
+`language=de_DE`.
+
+If you want to use a different keyboard layout for the console then use the
+[`keytable`](https://en.opensuse.org/SDB:Linuxrc#p_keytable) boot option.
+
+## Network Setup
+
+Obviously, for downloading the installer updates YaST needs network.
+
+YaST by default tries using DHCP on all network interfaces. If there is
+a DHCP server in the network then network is configured automatically.
+
+If you need static IP setup in your network then use the
+`ifcfg=<interface>=<ip_address>,<gateway>,<nameserver>` boot option, e.g.
+`ifcfg=eth0=192.168.1.101/24,192.168.1.1,192.168.1.2`.
+See the [Linuxrc documentation](https://en.opensuse.org/SDB:Linuxrc#Network_Config)
+for more details.
 
 ## Update Format
 
@@ -31,11 +59,22 @@ handled in a different way:
   are executed.
 * No dependency checks are performed. RPMs are added in alphabetical order.
 
+The rpm-md repository is required by SMT ([SUSE Subscription Management Tool](
+https://www.suse.com/products/subscription-management-tool))
+as this is the only format which it supports for data mirroring.
+
+The files from the packages override the files from the original inst-sys.
+That means the update packages might not need to contain all files,
+it is enough to include only the changed files which are different than
+in the original inst-sys. The unchanged files can be omitted to save memory
+and the download bandwidth.
+
 ## Where to Find the Updates
 
 The URL of the update repository is evaluated in this order:
 
-1. The `SelfUpdate` boot option
+1. The `self_update` boot option  
+   (Note: `self_update=0` completely disables the self-update!)
 2. The AutoYaST profile - in AutoYaST installation only, use the
    `/general/self_update_url` XML node:
 
@@ -44,13 +83,19 @@ The URL of the update repository is evaluated in this order:
      <self_update_url>http://example.com/updates/$arch</self_update_url>
    </general>
    ```
-3. Registration server (SCC/SMT), not available in openSUSE. The URL of the
-   registration server which should be used is determined via:
-   1. AutoYaST profile ([reg_server element](https://www.suse.com/documentation/sles-12/singlehtml/book_autoyast/book_autoyast.html#CreateProfile.Register)).
-   2. The `regurl` boot parameter
+3. Registration server ([SCC](https://scc.suse.com) or
+   [SMT](https://www.suse.com/products/subscription-management-tool)), not
+   available in openSUSE. The URL of the registration server which should
+   be used is determined via:
+   1. The `regurl` boot parameter
+   2. AutoYaST profile ([reg_server element](https://www.suse.com/documentation/sles-12/singlehtml/book_autoyast/book_autoyast.html#CreateProfile.Register)).
    3. SLP lookup (this behavior applies to regular and AutoYaST installations):
-      * If one server is found, it will be used automatically.
-      * If more than one server is found, it will ask the user to choose one.
+      * If at least one server is found it will ask the user to choose one.
+      * In AutoYaST mode SLP is skipped unless enabled in the profile in the
+        registration section (see [documentation](https://www.suse.com/documentation/sles-12/singlehtml/book_autoyast/book_autoyast.html#idm140139881100304)).
+        AutoYaST expects that only one server is reported by SLP, if more
+        servers are found it is considered as an error and user interaction is
+        required just like in manual installation.
    4. Default SUSE Customer Center API (`https://scc.suse.com/`).
 4. Hard-coded in the `control.xml` file on the installation medium (thus it
    depends on the base product):
@@ -63,20 +108,59 @@ The URL of the update repository is evaluated in this order:
 
 The first suitable URL will be used. There are two exceptions:
 
-* Of course, if no update URL is found then the self update is skipped.
-* If SCC/SMT provides multiple URLs, they will be all used.
+* If no update URL is found then the self-update is skipped.
+* If SCC/SMT provides multiple URLs, they will be all used. Currently this is
+  the only way how to use more update repositories.
+
+### Downloading the AutoYaST Profile
+
+As mentioned above, the self-update repository URL might be stored also in the
+AutoYaST installation profile.
+
+However, the self-update runs at the very beginning when some hardware might
+not be initialized yet and therefore in some rare cases it might happen that the
+self-updater is not able to load the profile eventhough it can be loaded
+by the usual AutoYaST workflow later.
+
+If that is the case you need to specify the custom update URL via `self_update`
+boot option instead of specifying it in the profile.
+
+### Manual SLP Discovery
+
+If you want to check which SMT servers are announced locally via SLP you can
+run this command: `slptool findsrvs registration.suse`.
+
+Make sure the SLP communication is not blocked by firewall. Open UDP source port
+427 if the firewall is running.
+
+### Disabling SSL Certificate Check for SMT Server
+
+When the used SMT server uses a self-signed SSL certificate for HTTPS conntections
+YaST will ask to import that certificate. In that case you should verify the
+certificate fingerprint before importing it.
+
+If there are other issues with the certificate (signed by an unknown certificate
+authority, expired certificate, ...) then you can disable the SSL check by
+the `ptoptions=reg_ssl_verify reg_ssl_verify=0` boot options. But this is
+a security risk and should be used only in a trusted network, using a valid
+SSL certificate should be preferred.
+
+### Variable Expansion
 
 The URL can contain a variable `$arch` that will be replaced by the system's
-architecture, such as `x86_64`, `s390x`, etc. You can find more information
-in the [Arch module](http://www.rubydoc.info/github/yast/yast-yast2/Yast/ArchClass).
+architecture, such as `x86_64`, `i586`, `s390x`, etc.
+
+YaST uses [libzypp](https://github.com/openSUSE/libzypp/blob/e68b5df6c96e3f1d140ba15e2a9e85a990210f37/zypp/ZConfig.cc#L63)
+for detecting the system architecture so the `$arch` expansion is compatible
+with the expansion used in usual repository URLs.
 
 ### Actual URLs
 
 When using registration servers, the regular update URLs have the form
 `https://updates.suse.com/SUSE/Updates/$PRODUCT/$VERSION/$ARCH/update` where
 - PRODUCT is like OpenStack-Cloud, SLE-DESKTOP, SLE-SDK, SLE-SERVER,
 - VERSION (for SLE-SERVER) is like 12, 12-SP1,
-- ARCH is one of aarch64 i586 ia64 ppc ppc64 ppc64le s390x x86_64
+- ARCH is one of `aarch64` `ppc64le` `s390x` `x86_64`
 
 For the self-update the *PRODUCT* is replaced
 with *PRODUCT*-INSTALLER, producing these repository paths
@@ -89,10 +173,27 @@ under https://updates.suse.com/
 
 ## Security
 
+### Package Integrity
+
 Updates signatures will be checked by libzypp. If the signature is not
 correct (or is missing), the user will be asked whether she/he wants to apply
 the update (although it's a security risk).
 
+When using AutoYaST, this behavior can be modified including the
+[/general/signature-handling](https://www.suse.com/documentation/sles-12/singlehtml/book_autoyast/book_autoyast.html#idm140139881381840)
+section in the profile.
+
+### SLP Discovery
+
+If SLP discovery is enabled, a popup is displayed to choose the server to use.
+SLP by default does not use any authentication, everybody on the
+local network can announce a registration server so it must be confirmed by user.
+
+In AutoYaST mode SLP discovery must be enabled in the profile (in the
+registration section) and it is expected that only one SLP server is present
+in the network. If more servers are found the selection popup is displayed
+even in the AutoYaST mode.
+
 ## Self-update and User Updates
 
 Changes introduced by the user via Driver Updates (`dud` boot option) will take
@@ -101,18 +202,23 @@ self-update is performed).
 
 However, the user changes will be re-applied on top of the installer updates.
 
-## Resume installation
+## Resuming Installation
 
-Any client called before the self update step is responsible to remember its state (if
+Any client called before the self-update step is responsible to remember its state (if
 needed) and automatically going to the next dialog after the YaST restart.
-Once the self update step is reached again it will remove the restarting flag.
+Once the self-update step is reached again it will remove the restarting flag.
+
+The self-update step is called very early in the workflow, for the self-update
+step only configured network is needed. That is configured either by `linuxrc`
+or by the `setup_dhcp` YaST client which does not need to remember any state.
+
+## Supported URL Schemes
 
-Currently there is no API available for remembering the client states. The easiest
-way is to store the configuration into an YAML file and load it when restarting the
-installer. See the [example](https://github.com/yast/yast-installation/pull/367/files#diff-4c91d6424e08c9bef9237f7d959fc0c2R48)
-in the `inst_complex_welcome` client.
+Currently only HTTP/HTTPS and FTP URL schemes are supported for downloading
+the updates. Some additional schemes might work but are not tested and therefore
+not supported.
 
-## Error handling
+## Error Handling
 
 Errors during the installer update are handled as described below:
 
@@ -122,6 +228,8 @@ Errors during the installer update are handled as described below:
   * in a regular installation/upgrade, YaST2 will offer the possibility
     to check/adjust the network configuration.
   * in an AutoYaST installation/upgrade, a warning will be shown.
+* If SCC/SMT is used and it returns no URL or fails then the fallback URL from
+  `control.xml` is used.
 * If the updates repository is found but it is empty or not valid:
   * in the case that the URL was specified by the user (using the *SelfUpdate* boot
     option or through the *self_update_url* element in an AutoYaST profile), an

package/yast2-installation.changes

@@ -1,8 +1,44 @@
 -------------------------------------------------------------------
-Thu Aug 18 11:52:39 UTC 2016 - jreidinger@suse.com
+Tue Sep 13 12:37:57 UTC 2016 - jreidinger@suse.com
 
 - fix skipping of proposal returning empty hash otherwise it
   creates non sense proposal entry in UI (bnc#994127)
+- 3.1.215
+
+-------------------------------------------------------------------
+Tue Aug 30 06:55:13 UTC 2016 - lslezak@suse.cz
+
+- Display a warning popup when the installer self-update uses
+  the fallback URL instead of the selected SMT or the default SCC
+  server (bsc#996179)
+- Do not contact the registration server in self-update when
+  network is not running, skip self-update completely
+- 3.1.214
+
+-------------------------------------------------------------------
+Thu Aug 25 14:23:20 UTC 2016 - lslezak@suse.cz
+
+- Move the installer self update step earlier in the workflow
+  so the user entered values are not lost after restart and avoid
+  repeating some steps again (bsc#985055)
+- This also fixes losing some values due to restaring YaST (bsc#993690),
+  (bsc#992608)
+- Improved the self update URL handling - the boot parameter has
+  the highest priority, always ask user when a SLP service is found,
+  in AutoYaST mode SLP needs to be enabled in the profile
+- Display progress when downloading and applying the updates
+- 3.1.213
+
+-------------------------------------------------------------------
+Wed Aug 25 12:51:45 UTC 2016 - cwh@suse.com
+
+- Replace unicode bullet char by asterisk for ncurses (bsc#995082)
+- 3.1.212
+
+-------------------------------------------------------------------
+Thu Aug 25 07:33:10 UTC 2016 - jreidinger@suse.com
+
+- fix writing proposals (bnc#994127)
 - 3.1.211
 
 -------------------------------------------------------------------

package/yast2-installation.spec

@@ -17,7 +17,7 @@
 
 
 Name:           yast2-installation
-Version:        3.1.211
+Version:        3.1.215
 Release:        0
 
 BuildRoot:      %{_tmppath}/%{name}-%{version}-build
@@ -63,8 +63,8 @@ Conflicts:	yast2-mouse < 2.18.0
 # Lazy loading in ProductLicense
 Requires:	yast2-packager >= 3.1.113
 
-# Yast::Storage.multipath_off?
-Requires:	yast2-storage >= 3.1.97
+# Storage::GetDetectedDiskPaths
+Requires:	yast2-storage >= 2.24.1
 
 # use in startup scripts
 Requires:	initviocons