January 2017 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306528] Info banner for projects/packages
by fate_noreply＠suse.de 12 Mar '17

12 Mar '17

Feature added by: Jan-Simon Möller (dl9pf) Feature #306528, revision 1 Title: Info banner for projects/packages Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Jan-Simon Möller (dl9pf) Description: I'd propose to add an info banner (as on the monitor page - aka "Adrians Blog" ;) ) to the projects or even packages. This would allow the new groups of packagers to leave status messages right in place for the projects. -- openSUSE Feature: https://features.opensuse.org/306528

1 4

[New: openFATE 322299] please update lighttpd package to lighttpd 1.4.44
by fate_noreply＠suse.de 12 Mar '17

12 Mar '17

Feature added by: Glenn Strauss (gstrauss) Feature #322299, revision 1 Title: please update lighttpd package to lighttpd 1.4.44 openFATE: Unconfirmed Priority Requester: Important Requested by: Glenn Strauss (gstrauss) Partner organization: openSUSE.org Description: Please update lighttpd package to lighttpd 1.4.44 for OpenSUSE Leap and OpenSUSE Tumbleweed, and maybe also consider for OpenSUSE 13.2 and SUSE SLE-12. lighttpd 1.4.37 is over a year old and is missing a number of security fixes, including protection against HTTPoxy and XSS fixes. lighttpd 1.4.44 builds fine on various OpenSUSE platforms. I am one of the developers of lighttpd, as is stbuehler, who builds (unofficial) packages for opensuse at https://build.opensuse.org/package/show/home:stbuehler:lighttpd-1.4.x/light… Future looking, what is the process for getting new lighttpd releases into Tumbleweed? Thank you. -- openSUSE Feature: https://features.opensuse.org/322299

1 3

[New: openFATE 321407] Add support for dnscrypt and dnssec
by fate_noreply＠suse.de 20 Feb '17

20 Feb '17

Feature added by: Alfredo Amaya (alfre2) Feature #321407, revision 1 Title: Add support for dnscrypt and dnssec Requested by: Alfredo Amaya (alfre2) Partner organization: openSUSE.org Description: You need to add an third party repository to install dnscrypt and dnssec for encrypting and validating DNS queries. The main repository lacks both packages. Business case (Partner benefit): openSUSE.org: Encrypting DNS queries is an important step forward for improving privacy. It's a reliable and fast service nowadays and is becoming popular. Besides, DNSSEC acts as a complement ensuring the content of these queries. Right now there's an unofficial repository providing these packages: http://download.opensuse.org/repositories/server:/dns/openSUSE_42.1/ -- openSUSE Feature: https://features.opensuse.org/321407

1 2

[New: openFATE 320755] Warn the user with a popup that the profile A2DP is required for HIFI
by fate_noreply＠suse.de 19 Feb '17

19 Feb '17

Feature added by: Stakanov Schufter (stakanov) Feature #320755, revision 1 Title: Warn the user with a popup that the profile A2DP is required for HIFI openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Stakanov Schufter (stakanov) Partner organization: openSUSE.org Description: Currently when connecting a BT headset they do default to HSP/HFP. This will be O.K. if the user wants to use VOIP. However the main part of BT Headsets support now the profile A2DP. While it may be to early to default to it, it would be good to have a pop-up when pairing or an explanation in BT setup that for HIFI you have to set the profile to A2DP. Otherwise you will get a garbled output. Besides on my machine it was necessary to first pair, restart one time the system and then only it was possible to change the profile to A2DP. So at least for leap, the support and switching to A2DP should be looked after too. Use Case: consumer connects a BT headset Business case (Partner benefit): openSUSE.org: A first time BT user could think that a) linux cannot provide hifi output to BT headsets b) will not find easily the solution if not explained because users do not find / know about audio profiles c) may have a negative use experience for a longer time period BT Headset should be "pair-and-you-go" as much as possible. -- openSUSE Feature: https://features.opensuse.org/320755

1 1

[New: openFATE 319627] Minimal KDE and GNOME installation option
by fate_noreply＠suse.de 19 Feb '17

19 Feb '17

Feature added by: Arnold Mesper (amesper) Feature #319627, revision 1 Title: Minimal KDE and GNOME installation option openSUSE Distribution: Unconfirmed Priority Requester: Mandatory Requested by: Arnold Mesper (amesper) Partner organization: openSUSE.org Description: The installer must provide an option to install a minimal KDE and a minimal GNOME desktop in addition to the current KDE and GNOME desktop options, which install a lot of software. A minimal GNOME desktop should, for example, only install the software necessary to boot the system, login into GNOME and the GNOME shell. In addition it should include drivers only for hardware that is available on the system and corresponding configuration software (e.g. network manager if network card is installed) and the package manager in order to install additional software as required either from DVD or via internet. It must also include and enable security software (e.g. AppArmor, Firewall), thus the system is secured from the beginning. What a minimal GNOME desktop should not have: - hardware drivers for hardware that is not available (e.g. bluetooth) or has been disabled in the BIOS (e.g. WLAN, web cam, etc.) - software that can be easily installed afterwards (e.g. office suite, web browser, e-mail client, chat client, terminals, file managers, text editors, character maps, etc.) - software which is not intended for a minimal desktop (e.g. server software, development software) - Java, Flash There is also a grey zone of software, that might be useful, but should not be mandatory part of a minimal install (e.g. Avahi). Here the user should be shown with a list of software recommendations (with description) during the installation, which he must explicitly enable to be installed. Use Case: Use Case 1: Install a clean GNOME or a clean KDE desktop as a host for virtual machines. After installing the minimal desktop, the user only needs to install VirtualBox. Use Case 2: Install a clean GNOME or a clean KDE desktop as a virtual machine guest and install the required software afterwards. E.g. easily install a web browser VM or a mail client VM or an office VM. Business case (Partner benefit): openSUSE.org: For novice users the current desktop options full with software are good choice as they do not need to think about what to install. For expert users the openSUSE has the wonderful possibility to customize the system to be installed by selecting / deselecting software. I think this is the biggest plus of openSUSE in comparison to other distributions. But what is lacking is an interim solution for advanced users, that only want to install a clean KDE or GNOME desktop and decide on what additional software to install afterwards. This is especially when working with virtual machines, it is very useful to have an option to install a clean desktop without much effort. -- openSUSE Feature: https://features.opensuse.org/319627

1 4

[New: openFATE 322201] deny updates through nonroot user
by fate_noreply＠suse.de 11 Feb '17

11 Feb '17

Feature added by: Nick Levinson (NickLevinson) Feature #322201, revision 1 Title: deny updates through nonroot user openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Nick Levinson (nicklevinson) Partner organization: openSUSE.org Description: An account meant for use by guests should not allow updates to be applied to the whole operating system and other applications, some of which may be intentionally invisible to nonroot users but are exposed to them by the update information. Which user accounts have the authority to update all of the software should be by options set in advance by root, and probably preset by defaults. I previously asked about this at the Bugzilla (https://bugzilla.opensuse.org/show_bug.cgi?id=1012283) where I was referred to here, and in a support forum (https://forums.opensuse.org/showthread.php/520485-deny-amp-hide-updates-thr…) where a suggestion was a CLI non-GUI method, which I started to try, but which is apparently seriously complex and not exactly clear. I will likely make the setting only once; I don't run a complex network with many changes. Thus, this should be in a GUI. Two options for each nonroot user account, set only by root, would be helpful: * Allow updates from the current (nonroot) user account. * Allow notification of available updates in the current (nonroot) user account, although availability may be limited to another user. The defaults should be to deny both options for every nonroot user. Of course, in root, both options would always be allowed unless the OS is being run from read-only media. -- openSUSE Feature: https://features.opensuse.org/322201

1 1

[New: openFATE 313272] zypper: Display vendor when newer package is offered by different vendor
by fate_noreply＠suse.de 11 Feb '17

11 Feb '17

Feature added by: Richard Bos (rbos) Feature #313272, revision 1 Title: zypper: Display vendor when newer package is offered by different vendor openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Richard Bos (rbos) Partner organization: openSUSE.org Description: >From the output below it is not clear which other vendor offers the newer package version: # zypper in curl Loading repository data... Reading installed packages... 'curl' is already installed. There is an update candidate for 'curl', but it is from different vendor. Use 'zypper install curl-7.23.1-72.1.x86_64' to install this candidate. Resolving package dependencies... Nothing to do. It is useful to know which other vendor(s) offers the newer package to dertermine if the package should be used. 2) Is it possible to devide the string over 2 lines, it is now 1 long line, like this: There is an update candidate for 'curl', but it is from different vendor. Use 'zypper install curl-7.23.1-72.1.x86_64' to install this candidate. With 2 lines it becomes: There is an update candidate for 'curl', but it is from different vendor. Use 'zypper install curl-7.23.1-72.1.x86_64' to install this candidate. Use Case: zypper up shows: zyp up Loading repository data... Reading installed packages... The following package updates will NOT be installed: ..extreme-tuxracer...<many other packages> Nothing to do. Select extreme-tuxracer to investigate why they are not installed: # zyp in extreme-tuxracer Loading repository data... Reading installed packages... 'extreme-tuxracer' is already installed. There is an update candidate for 'extreme-tuxracer', but it is from different vendor. Use 'zypper install extreme-tuxracer-0.4-118.1.x86_64' to install this candidate. Resolving package dependencies... Nothing to do. One details is missing the name of the vendor. Business case (Partner benefit): openSUSE.org: Give the user the necessary information to be able to judge if he / she wants this newer package version from the other vendor or not. -- openSUSE Feature: https://features.opensuse.org/313272

1 1

[New: openFATE 308685] Gnome Slab's More Applications not open another Window
by fate_noreply＠suse.de 11 Feb '17

11 Feb '17

Feature added by: Drew Kwashnak (dragonbite) Feature #308685, revision 1 Title: Gnome Slab's More Applications not open another Window Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Drew Kwashnak (dragonbite) Partner organization: openSUSE.org Description: In the Gnome Slab, if the Application has not been pinned to the Favorites you are forced to click "More Applications" and it opens up a Window. Maybe this could open a window like Windows XP does? Or can slide to the side like KDE 4 does? Something should be in place by default. Is there something called "Lancelot" which would apply here, or is just KDE? Business case (Partner benefit): openSUSE.org: The opened window may get lost in Windows, can be easily pushed behind something else or a pushy application that finally loads may pop-up over it and otherwise be annoying. -- openSUSE Feature: https://features.opensuse.org/308685

1 4

[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