February 2016 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 313282] Full automated setup for printers in the network
by fate_noreply＠suse.de 20 Mar '17

20 Mar '17

Feature added by: Johannes Meixner (jsmeix) Feature #313282, revision 1 Title: Full automated setup for printers in the network openSUSE Distribution: Unconfirmed Priority Requester: Neutral Requested by: Johannes Meixner (jsmeix) Partner organization: openSUSE.org Description: I would like to have it evaluated whether or not and/or to what extent it is possible to setup printer devices which are accessible via network in a full automated way. The basic idea behind: For locally connected USB printers there is already full automated setup. I would like to have it evaluated if and/or to what extent this could be extended reagarding printer devices which are accessible via network. FYI: For printer devices which are accessible via a CUPS server there is nothing to do because this works already via the so called "CUPS Browsing". Some use cases: Network printer) A network printer is a printer with a built-in network interface so that the printer device is directly accessible via network. The problem regarding full automated setup is how to autodetect the printer model so that the right driver for this model can be set up. Therefore the problem is how to autodetect the parinter model on a printer device which is directly accessible via network. Usually this is possible via some generic SNMP query. The CUPS tool "lpinfo -l -v" results this for the "socket" device URI e.g.: # lpinfo -l -v Device: uri = socket://10.10.2.92 make-and-model = HP LaserJet 4050 Series Device: uri = lpd://10.10.4.4/ make-and-model = Kyocera FS-C5100DN SMB) A printer device which is accessible via a SMB printer share: In this case the client system must submit readymade printer specific data to the SMB share (i.e. there is no so called "filtering" on a SMB print server). Therefore on the client system usually a printer driver must run. If it is a PostScript printer, the client must at least provide generic PostScript (e.g. when printing image data it must be converted into PostScript on the client system). The problem regarding full automated setup is how to autodetect the printer model so that the right driver for this model can be set up but the printer device is "hidden" behind the SMB share. Therefore the problem is how to autodetect the parinter model via a SMB share. -- openSUSE Feature: https://features.opensuse.org/313282

1 10

[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 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 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

[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 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