February 2017 - 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 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 322611] fcitx update
by fate_noreply＠suse.de 03 Mar '17

03 Mar '17

Feature added by: Ludwig Nussel (lnussel) Feature #322611, revision 1 Title: fcitx update Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: Forwarding request from openSUSE/upstream side to upgrade fcitx in SP3 https://build.opensuse.org/request/show/458967 Since qt4's webkit is not being maintained anymore. For security reason, we need to move to qt5's webengine (or the qtwebkit-ng, but it's not mature yet) and the only config ui that uses qtwebkit is inside fcitx-libpinyin. For a long time there's no real motivation to port the gui-wrapper to qt5 because there's no plugin use it. So this change forces we to port the gui wrapper to qt5, which is also not a bad thing. Thanks to Xu Zhao's work, and we now have a gui wrapper in qt5. The new version of kcm and configtool also contain the necessary changes to adopt this new wrapper. Also, there's some technical reason that kcm can't simply embed the qt5 plugin, because webengine loading from plugin need to execute some code before QApplication constructs, which we don't have control. So it goes a step back, to the old fashioned configtool way by launching gui wrapper directly. In short, for packagers, make sure you have these four package update at the same time: fcitx-configtool 0.4.9 fcitx-libpinyin 0.5.0 fcitx-qt5 1.1.0 kcm-fcitx 0.5.4 -- openSUSE Feature: https://features.opensuse.org/322611

1 4

[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

[openFATE 322038] cloud-init: add zypp repo support
by fate_noreply＠suse.de 16 Feb '17

16 Feb '17

Feature changed by: Thorsten Kukuk (kukuk) Feature #322038, revision 7 Title: cloud-init: add zypp repo support Requested by: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: If customers don't want to register every system, we need another why to add update repositories to the system. cloud-init can add yum repos, it is quite easy to adopt that for zypp repos. Documentation Impact: Installation Guide? + See FATE#321107, we should document how to add the pool and update + channels from a SMT server -- openSUSE Feature: https://features.opensuse.org/322038

1 0

[openFATE 322038] cloud-init: add zypp repo support
by fate_noreply＠suse.de 13 Feb '17

13 Feb '17

Feature changed by: Frank Sundermeyer (fsundermeyer) Feature #322038, revision 6 Title: cloud-init: add zypp repo support Requested by: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: If customers don't want to register every system, we need another why to add update repositories to the system. cloud-init can add yum repos, it is quite easy to adopt that for zypp repos. + Documentation Impact: + Installation Guide? -- openSUSE Feature: https://features.opensuse.org/322038

1 0

[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