October 2016 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 312871] Auto-lock with password when screen saver kicks in.
by fate_noreply＠suse.de 11 Feb '17

11 Feb '17

Feature added by: Per Jessen (pjessen) Feature #312871, revision 1 Title: Auto-lock with password when screen saver kicks in. openSUSE 12.1: Unconfirmed Priority Requester: Important Requested by: Per Jessen (pjessen) Partner organization: openSUSE.org Description: * Enable automatic screen-lock with password required. E.g. after 5mins and 10seconds respectively. * add a default "lock" button to the GUI taskbar Business case (Partner benefit): openSUSE.org: To increase security. We have many and varied security-related features and policies. Requiring a password when the screen auto-locks is just common sense. An easily accessible lock button makes it more likely that a user will use it when he leaves his desk. These both ought to be the default setup. -- openSUSE Feature: https://features.opensuse.org/312871

1 8

[New: openFATE 312873] Login screen after lock screen
by fate_noreply＠suse.de 11 Feb '17

11 Feb '17

Feature added by: Christian Giorgio galeffi (gallochri) Feature #312873, revision 1 Title: Login screen after lock screen openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Christian Giorgio galeffi (gallochri) Partner organization: openSUSE.org Description: Why does not require a password to unlock the screen with the same login screen of KDM or GDM, instead of a dialog box? Such as Windows XP. -- openSUSE Feature: https://features.opensuse.org/312873

1 4

[New: openFATE 320696] Provide interface to show worker capabilities
by fate_noreply＠suse.de 27 Jan '17

27 Jan '17

Feature added by: Adrian Schröter (adrianSuSE) Feature #320696, revision 1 Title: Provide interface to show worker capabilities Buildservice: New Milestone: 2.8 Priority Requester: Important Requested by: Adrian Schröter (adriansuse) Requested by: Adrian Schröter (adriansuse) Partner organization: openSUSE.org Description: To be able to define proper constraints it is important which capabilities exists. The minimum approch would be to provide the data from /srv/obs/workers directory via the api. Means listing the workers and offer to show (a filtered?) the list of capabilities. A webui for this would be very nice too. -- openSUSE Feature: https://features.opensuse.org/320696

1 2

[New: openFATE 309393] Make "unpublish" files and removing files from :full tree easy
by fate_noreply＠suse.de 27 Jan '17

27 Jan '17

Feature added by: Adrian Schröter (adrianSuSE) Feature #309393, revision 1 Title: Make "unpublish" files and removing files from :full tree easy Buildservice: New Priority Requester: Important Requested by: Adrian Schröter (adriansuse) Description: Currently it is quite complex to remove build results from public repo or :full repo tree, if you do not want to remove the source package. We need to extend wipebinaries call with a target for :full and :repo dir and make this easy accessable via osc and webui. -- openSUSE Feature: https://features.opensuse.org/309393

1 6

[New: openFATE 321753] working dmesg in installer
by fate_noreply＠suse.de 17 Jan '17

17 Jan '17

Feature added by: Michal Suchanek (michals) Feature #321753, revision 1 Title: working dmesg in installer Requested by: Michal Suchanek (michals) Partner organization: openSUSE.org Description: In the installer dmesg buffer is empty. This is different from every Linux and BSD distribution I tried so far, even installers. In order to not alienate people who are not running SUSE from the very start the kernel messages should be left in said buffer for everyone to look at when needed. Supposedly there are these messages on virtual terminal 4 and /var/log/boot.msg Virtual terminal 4 is not accessible when installing - over ssh - over serial console - over IPMI which are probably scenarios for which SUSE should care more than most distributions out there given the focus on server. /var/log/boot.msg is either misnamed or it contains only the kernel messages from system startup and not messages which result from inserting a device for example. -- openSUSE Feature: https://features.opensuse.org/321753

1 1

[New: openFATE 313441] Easy Upgrade
by fate_noreply＠suse.de 10 Jan '17

10 Jan '17

Feature added by: Mário Castanheira (SpeccyMan) Feature #313441, revision 1 Title: Easy Upgrade openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Mário Castanheira (speccyman) Partner organization: openSUSE.org Description: An easy way to allow users to make upgrades (e.g.: changing from version 12.1 to version 12.2) as easy as they can in Ubuntu. Something like one-click, instead of having to deal whit the work of disable and update of the repositories manually. Would be good if all this would be automatic and maybe even integrated it into the new Software Center. Use Case: User gets notified that there's a new version of opensuse available and it is asked if he wishes to upgarde. If he selects "upgrade" the system should ask for permissions and then start upgrading itself. (pretty much like in ubuntu). Nothing else required! Business case (Partner benefit): openSUSE.org: Because it will invite users to keep their distro in it's last version, even if they don't understand much about computers! And because it's something all Ubuntu users keep saying it's one of their loved features. -- openSUSE Feature: https://features.opensuse.org/313441

1 34

[New: openFATE 310405] yast2 wagon should be a fully graphic upgrade tool
by fate_noreply＠suse.de 10 Jan '17

10 Jan '17

Feature added by: Greg Freemyer (gregfreemyer) Feature #310405, revision 1 Title: yast2 wagon should be a fully graphic upgrade tool openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Greg Freemyer (gregfreemyer) Description: I really like it that yast2-wagon exists for users to upgrade from release to release. It effectively does a zypper dup, but via a nicer gui interface. The trouble in my mind is that it still takes way to many seperate steps as is. Quoting just the top level details from http://old-en.opensuse.org/Wagon === 1) Ensure you have yast2-wagon installed 2) As of openSUSE 11.2 Wagon will update the upgrade stack as part of its automated process, so there is no need to ensure you have run zypper up or equivalent 3) Ensure you have the the correct repositories enabled 4) Start YaST2 wagon 5) Follow the dialogs 6) reboot === Taking those steps one at a time: 1) yast2-wagon should be part of the standand yast pattern in my opinion. It currently is not, so it has to be separately installed which makes little sense for a tool designed to simplify the upgrade process. 2) That was a great improvement that went into 11.2, so I'm happy. (Other than the current bugzilla against the yast2-wagon dependencies in the 11.3 release. I wish that would be fixed.) 3) It would be great if yast2-wagon would launch with a user selectable distro to upgrade to. Then once a user selected 11.4 as an example, it would walk the user through upgrading his repos to the 11.4 compatible ones. 4) Once 3) is incorporated it would be great to get a easy to click icon for wagon either within yast itself, or on the system menus. 5) This appears to be an effort to achieve automatic repo updates, but I'm not sure. Unfortunately, the above can be implemented for the 11.3 => 11.4 upgrade but only if the upgraded yast2-wagon is released via online update. That is because it involves updating the repo handling prior to pulling down a new copy of wagon from the 11.4 repos. -- openSUSE Feature: https://features.opensuse.org/310405

1 4

[openFATE 308189] Consolidating terminology: update and upgrade
by fate_noreply＠suse.de 10 Jan '17

10 Jan '17

Feature added by: Karl Eichwalder (keichwa) Feature #308189, revision 1 Title: Consolidating terminology: update and upgrade openSUSE-11.3: New Priority Requester: Mandatory Requested by: Karl Eichwalder (keichwa) Partner organization: openSUSE.org Description: In the past, we just used the term "update" for all update related things, because we were told "upgrade" is suitable for hardware related upgrades only. With the advent of zypper, the term "upgrade" (dup, dist-upgrade) is back for upgrading the system complete from one version "n" to the next version "n+1" (yes, you can "upgrade" within one version, but that's a special case...). The term is fine and I'd like us to use "upgrade" in YaST and everywhere else where suitable. Business case (Partner benefit): openSUSE.org: Avoid confusion. ATM, I'm force to use different terms in the chapter of the manual, if I describe the same task. -- openSUSE Feature: https://features.opensuse.org/308189

1 13

[New: openFATE 312799] Safer distribution updates
by fate_noreply＠suse.de 10 Jan '17

10 Jan '17

Feature added by: Duncan Mac-Vicar (dmacvicar) Feature #312799, revision 1 Title: Safer distribution updates openSUSE Distribution: New Priority Requester: Desirable Requested by: Duncan Mac-Vicar (dmacvicar) Product Manager: Michael Elliott (mge) Developer: ma ds (ma) Partner organization: openSUSE.org Description: Currently the documentation says that to do a distribution upgrade you should first update your software stack to the target distribution, then do a zypper dup. The software stack update can already kill your system. zypper could allow an option that makes it first install a miniroot containing the update stack itself, then automatically switch over to the miniroot to do the "zypper dup". Use Case: Bob wants to migrate his server from SLE12 to SLE13. Upgrading the package management stack fails, but he keeps his original system untouched. Business case (Partner benefit): openSUSE.org: Failsafe migrations for SLE -- openSUSE Feature: https://features.opensuse.org/312799

1 18

[openFATE 308147] Simplify "Online update" in Yast
by fate_noreply＠suse.de 10 Jan '17

10 Jan '17

Feature added by: Birger Kollstrand (MrKane) Feature #308147, revision 1 Title: Simplify "Online update" in Yast openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Birger Kollstrand (mrkane) Description: In 11.2 there are two Online Update applications - one for configuration of online update - one for doing a manual online update I suggest that this is merged to one application which looks mostly like todays "Online update configureation" but has an aditional button on the page that when pushed does an online update. This will simplify the Yast GUI. -- openSUSE Feature: https://features.opensuse.org/308147

1 1