March 2017 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 310163] Remove Welcome Screen on OpenSUSE KDE
by fate_noreply＠suse.de 25 May '17

25 May '17

Feature added by: Andres Silva (anditosan) Feature #310163, revision 1 Title: Remove Welcome Screen on OpenSUSE KDE openSUSE-11.4: Unconfirmed Priority Requester: Desirable Requested by: Andres Silva (anditosan) Description: Hey you all. I would first like to thank all of you who have visited this website and looked at the ideas I have posted. I am deeply honored that many of you too have considered these ideas worthwhile and would like to see them implemented. Well, here comes a good one I think. As I was talking to some people on the KDE IRC channel yesterday, there was a comment made about a possible way to orient new KDE users on how to use the desktop. However, I believe that users should be left clues to discover their desktop on their own. There should not be an intro popup or anything like that. Ponder about this for a moment. What can you say, for example, about paintings. Paintings are not "explained" to anyone. You look at it and you get it in your own particular way. That is enough for you and you know what it means. The clues left by the artist are clear enough to your mind that you find meaning in the painting. You intuitively "know" what the purpose of the painting is. Reflect for a moment on this Cezanne and know what it means... REMOVE KDE WELCOME POPUP SCREEN anditosan.blogspot.com -- openSUSE Feature: https://features.opensuse.org/310163

1 8

[New: openFATE 312876] Deny individual users' access to screen-saver settings
by fate_noreply＠suse.de 25 May '17

25 May '17

Feature added by: Per Jessen (pjessen) Feature #312876, revision 1 Title: Deny individual users' access to screen-saver settings openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Per Jessen (pjessen) Partner organization: openSUSE.org Description: This is an extension of feature#312871, but because it's a little more involved than changing a simple default, I thought it would be better to have a separate feature request. The screen-saver settings for time-out and "require password" are security settings that really should not be freely available to the individual user. I propose that we 1) set a reasonable default (60sec, 15sec, always require passwd) (see feature#312871) and 2) only let these settings be modified by someone with root-access. To a regular user, the timeout and "require password" settings should appear "greyed out", clearly indicating "not available". Use Case: Office user - the user is able to select a screen-saver, but the other settings cannot be accessed, accidentally or otherwise. The install or admin person need not change anything to get a sane security setup for the desktop. SOHO or home users - same as above, but the default screen-saver settings may be changed by switching to root access. Business case (Partner benefit): openSUSE.org: This is simply a reasonable security measure, fitting nicely into the overall security-conscious profile of openSUSE. Security measures (firewall, apparmor, encryption etc) are typically accessible only with root-access; it's only sensible that we apply this principle to the screen-saver settings too. -- openSUSE Feature: https://features.opensuse.org/312876

1 10

[New: openFATE 312337] clear /tmp-dir at bootup
by fate_noreply＠suse.de 25 May '17

25 May '17

Feature added by: M K (tux93) Feature #312337, revision 1 Title: clear /tmp-dir at bootup openSUSE Distribution: Unconfirmed Priority Requester: Neutral Requested by: M K (tux93) Partner organization: openSUSE.org Description: Please clear the /tmp-dir at boot-up per default. At the moment this has to be activated manually with every new installation, is there a reason for not doing this out of the box? -- openSUSE Feature: https://features.opensuse.org/312337

1 6

[New: openFATE 309487] Clean out X11 keyboard configuration in YaST
by fate_noreply＠suse.de 24 May '17

24 May '17

Feature added by: Jiří Suchomel (jsuchome) Feature #309487, revision 1 Title: Clean out X11 keyboard configuration in YaST Requested by: Jiří Suchomel (jsuchome) Developer: (Novell) Developer: (Novell) Description: Currently, 'yast2 keyboard' is using kind of strange way of determining which X11 keyboard layout to use. There's a map of internal YaST keyboard names, to which the list of kbd console maps is mapped (like, us.map.gz). Such console map is taken as a parameter for calling /usr/sbin/xkbctrl script, which returns the informations about corresponding X11 keyboard layout (usable for setxkbmap). One problem is that not for all languages, there's a sense to have console map, and because of this situation in YaST, we are using files like ar.map.gz, which are only links to us.map.gz. Other part is that the list of X11 keyboard layouts is part of sax2-tools package which we probably want to drop. New solution would mean that YaST has all the information currently provided by xkbctrl: either by building its own data structure (if there's no other application using it), or using a better way to get the data YaST needs to know. References: https://bugzilla.novell.com/show_bug.cgi?id=603950 https://bugzilla.novell.com/show_bug.cgi?id=601587 -- openSUSE Feature: https://features.opensuse.org/309487

1 16

[New: openFATE 320834] Create a /var/cache subvolume
by fate_noreply＠suse.de 17 May '17

17 May '17

Feature added by: Thorsten Kukuk (kukuk) Feature #320834, revision 1 Title: Create a /var/cache subvolume Requested by: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: On the openSUSE Factory list, somebody found a valid bug in our current setup for snapshots: /var/cache is part of the snapshot. This means: all RPMs used for an update are part of the snapshot and will be deleted only afterwards. This is a big problem if you regular update online, it will eat up your diskspace very fast. We need to add /var/cache to the list of directories, for which we create a subvolume with btrfs. And (that's why I created a FATE and no bug) we need to add something to the release notes, so that customers are aware of this and can create the subvolume at their own for existing installations. Business case (Partner benefit): openSUSE.org: Save disk space by excluding irrelvant/outdated cached data from snapshots. -- openSUSE Feature: https://features.opensuse.org/320834

1 28

[New: openFATE 320819] DHCPv6-PD - wicked
by fate_noreply＠suse.de 11 May '17

11 May '17

Feature added by: James Knott (james_knott) Feature #320819, revision 1 Title: DHCPv6-PD - wicked openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: James Knott (james_knott) Partner organization: openSUSE.org Description: With more & more ISPs providing IPv6 via DHCPv6, DHCPv6-PD support is essential. This is how a router determines the assigned prefix via DHCP. Later versions of dhcpc support DHCPv6-PD, but wicked apparently doesn't. https://tools.ietf.org/html/rfc3633 -- openSUSE Feature: https://features.opensuse.org/320819

1 3

[New: openFATE 319119] drop not functional yast2-ca-management
by fate_noreply＠suse.de 08 May '17

08 May '17

Feature added by: Michael Calmer (mcalmer) Feature #319119, revision 1 Title: drop not functional yast2-ca-management Requested by: Michael Calmer (mcalmer) Partner organization: openSUSE.org Description: yast2 ca-management cannot be maintained anymore. No resources. So let's drop it. -- openSUSE Feature: https://features.opensuse.org/319119

1 12

[New: openFATE 322036] Move logrotate.status to /var/lib/misc
by fate_noreply＠suse.de 19 Apr '17

19 Apr '17

Feature added by: Thorsten Kukuk (kukuk) Feature #322036, revision 1 Title: Move logrotate.status to /var/lib/misc Requested by: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: logrotate.status is in /var/lib. Which is a problem if the root filesystem is read-only like for CASP. Making /var/lib read-write is impossible without breaking snapshots, rollback and transactional updates on all products, not only CASP. According to FHS/LSB, no application is allowed to create single files in /var/lib anyways, the correct directory is /var/lib/misc. Which is writeable. So the logrotate.status file should be moved. -- openSUSE Feature: https://features.opensuse.org/322036

1 5

[New: openFATE 309353] Make hermes working on local OBS installations
by fate_noreply＠suse.de 18 Apr '17

18 Apr '17

Feature added by: Adrian Schröter (adrianSuSE) Feature #309353, revision 1 Title: Make hermes working on local OBS installations Buildservice: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Adrian Schröter (adriansuse) Description: We need to * be able to run without iChain * package Hermes * configure it to be easy usable with OBS. -- openSUSE Feature: https://features.opensuse.org/309353

1 2

[openFATE 307597] Courgette
by fate_noreply＠suse.de 18 Apr '17

18 Apr '17

Feature added by: T. J. Brumfield (enderandrew) Feature #307597, revision 1 Title: Courgette openFATE: Unconfirmed Priority Requester: Important Requested by: T. J. Brumfield (enderandrew) Description: Utilize Courgette for binary diff packages. * This will save on bandwidth costs for Novell and mirrors. * This will make updating quicker and easier for end-users. * This will especially benefit users who have capped bandwidth for downloading updates from their ISPs. * By making the update process easier, it encourages users to stay up-to-date, making systems more secure. http://dev.chromium.org/developers/design-documents/software-updates-courge… (http://dev.chromium.org/developers/design-documents/software-updates-courge…) -- openSUSE Feature: https://features.opensuse.org/307597

1 7

[New: openFATE 309701] osc blame
by fate_noreply＠suse.de 18 Apr '17

18 Apr '17

Feature added by: Ludwig Nussel (lnussel) Feature #309701, revision 1 Title: osc blame Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Ludwig Nussel (lnussel) Description: a feature like "osc blame" or "osc annotate" would be nice to find out who changed what and when -- openSUSE Feature: https://features.opensuse.org/309701

1 3

[New: openFATE 323215] Remove binutils dependency from
by fate_noreply＠suse.de 31 Mar '17

31 Mar '17

Feature added by: Thorsten Kukuk (kukuk) Feature #323215, revision 1 Title: Remove binutils dependency from Requested by: Thorsten Kukuk (kukuk) Partner organization: openSUSE.org Description: dracut requires binutils only for the strip command to strip kernel modules. For JeOS, CaaSP and similar minimal installations, the customer requirements are "less than 500MB". binutils is already 36MB and most of it is not needed on a normal server installation. Business case (Partner benefit): openSUSE.org: More and more partners and customers require a minimal Host OS less than 500MB, currently we are at 800MB, so removing binutils would make already 10%. And binutils is the biggest package after kernel in such installations. -- openSUSE Feature: https://features.opensuse.org/323215

1 2

[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 313143] YaST LDAP client refactor/cleanup
by fate_noreply＠suse.de 15 Mar '17

15 Mar '17

Feature changed by: Milisav Radmanic (radmanic) Feature #313143, revision 28 Title: YaST LDAP client refactor/cleanup openSUSE Distribution: Evaluation by product manager Priority Requester: Mandatory - Projectmanager: Important + Projectmanager: Neutral Requested by: Ralf Haferkamp (rhafer) Developer: Christian Kornacker (ckornacker) Partner organization: openSUSE.org Description: Jiri (jsuchome) and I recently discussed some cleanup work we'd like to see in the YaST ldap-client module. This feature lists the main items we'd like to see reworked to improve the Module: Remove no longer needed UI elements Candidates are: * The TLS/SSL checkbox (sssd has a hard requirement for SSL/TLS) * The "LDAP Version 2" checkbox in the advanced settings. (there is AFAIK no LDAPv2-only Server implementation left) * The "Use LDAP but Disable Login" Radio Button Restrict the UI to handle only really LDAP client related things Currently the UI contains quite some settings which are not strictly related to LDAP client (nss/pam) setup. Over the year ldap-client became a bit of a disposal site for all kinds of LDAP related things, which made the UI a bit hard to understand. We should move some things to YaST modules where make a better fit. This is mostly about the settings currently available in the "Administration Settings" Tab (in "Advanced Configuration") * The Password Policies settings seem to fit better into the ldap- server module which already contains some of this functionality * Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. When a specific service still requires those configuration objects the YaST module for that service should be able to handle those objects it self (we could still offer utils API for that in yast2-ldap/ldap-client). E.g. the user management related object should be configured from inside the yast2-users module. yast2- ldap-server could offer to create default objects during the initial LDAP server setup. * The Home Directories on This Machine checkbox seems to be better suite in the Users module as well. * The rest of the values which go to /etc/sysconfig/ldap could be written by yast2-ldap-servers. We still need to figure out how to setup /etc/sysconfig/ldap on machines which to not run the LDAP Server but need access to those settings. (yast2-mail, -dns-server, -dhcp-server) * Adapt the API: move the LDAP* functions from ldap-client (impact on other modules!) Relations: - related feature (feature/id: 313142) Discussion: #1: Jiří Suchomel (jsuchome) (2012-01-19 10:15:11) 1. Removing TLS/SSL is based on assumption that we configure SSSD only, which is feature 313142. 2. About The "Use LDAP but Disable Login" Radio Button: did we agree on some replacement of it? I cannot remember... #2: Jiří Suchomel (jsuchome) (2012-01-23 16:25:33) Added attachment proposal for simplified first screen (ldap-client- redesign2.png) #3: Jiří Suchomel (jsuchome) (2012-02-21 09:26:08) yast2-ldap-client-2.22.3 only offers SSSD configuration in UI, and the option to turn off TLS/SSL was removed. #5: Jiří Suchomel (jsuchome) (2012-02-21 11:37:45) (reply to #3) yast2-ldap-client-2.22.4 has the password policy configuration removed. Some parts were moved to yast2-ldap-server code (just svn), some other parts need to be added there. I've created a bug report to track it, see bnc#748004. #4: Jiří Suchomel (jsuchome) (2012-02-21 10:26:39) Default Configuration Objects for other YaST modules (e.g. mail, dns, dhcp). Where possible the need for those special configuration objects should be removed. Ralf, do you have any idea where it could/should be removed? Who can decide it? #6: Jiří Suchomel (jsuchome) (2012-04-19 08:52:07) OK, I've made most of the required changes in yast2-ldap-client, yast2- users and yast2-ldap-server. Ralf, could you take a look at current (Factory) versions of these and comment what else should be done? I mean mostly UI-wise, that API transition was not done. #7: Lukas Ocilka (locilka) (2013-07-30 14:38:43) (reply to #6) Ralf: ping #8: Ralf Haferkamp (rhafer) (2013-08-05 10:43:08) (reply to #7) Peter, could you take a look a this. I don't have any time left for this currently. #9: Joachim Werner (joachimwerner) (2013-08-08 12:45:24) Moving this forward for SLE 12. But important-only. We have a clear policy to focus on the new installer for GA and only improve YaST modules when time permits. #10: Jiri Srain (jsrain) (2013-08-08 12:49:58) (reply to #9) Agreed. This is definitely worth to spend spare cycles on. #11: Lukas Ocilka (locilka) (2013-09-09 16:41:11) Back to PjM: We currently don't have any LDAP expert available in team. Peter or Ralf could possibly work on that if they had time but they are not in Yast team. #12: Jiri Srain (jsrain) (2013-09-10 15:05:18) (reply to #11) Mili, any chance Ralf or Peter could implement this feature? #13: Milisav Radmanic (radmanic) (2013-09-18 11:14:25) I think Peter Varkoly should be able to take care of this feature. -- openSUSE Feature: https://features.opensuse.org/313143

1 0

[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 323053] switching virtual desktops left-right-up-down
by fate_noreply＠suse.de 10 Mar '17

10 Mar '17

Feature added by: x x (TuxSv748) Feature #323053, revision 1 Title: switching virtual desktops left-right-up-down openFATE: Unconfirmed Priority Requester: Desirable Requested by: x x (tuxsv748) Partner organization: openSUSE.org Description: there is no Default key Setting fopr switching virtual Desktops in KDE for directions left right up and down. Therefore I would recommend the following keysets: CTRL+ALT+<left,right,up,down> eg MAC is using CTRL+<left,right> to slide between virtual Desktops, so using Linux in an VM on a MAC does not Impact the native behavior, but imitates it similarily -- openSUSE Feature: https://features.opensuse.org/323053

1 1

[New: openFATE 323058] OBS support for source-level syncing between codestreams
by fate_noreply＠suse.de 10 Mar '17

10 Mar '17

Feature added by: Kristyna Streitova (kstreitova) Feature #323058, revision 1 Title: OBS support for source-level syncing between codestreams Buildservice: New Priority Requester: Desirable Requested by: Kristyna Streitova (kstreitova) Partner organization: openSUSE.org Description: Currently, there isn't any source-level auto syncing between codestreams for openSUSE:Leap packages on the condition that the package hasn't been changed over more codestreams. An example could be an openSUSE:Leap package that initially comes from openSUSE:Factory and then is always inherited from the previous openSUSE:Leap version to the next one. Let's assume that the package sources haven't been changed since it was added to openSUSE:Leap. Then if a packager wants to create a maintenance update, he/she has to treat each codestream separately even though all these 3 codestreams contain the same sources. This feature should probably be implemented in osc/OBS. When a packager uses 'osc mbranch' command, the codestreams containing the same package sources should be recognized, branched only once and make the others link to it. On submission, it would submit the changes to the rest of the targets with the identical package automatically. -- openSUSE Feature: https://features.opensuse.org/323058

1 0

[New: openFATE 323054] switching virtual desktops left-right-up-down
by fate_noreply＠suse.de 10 Mar '17

10 Mar '17

Feature added by: x x (TuxSv748) Feature #323054, revision 1 Title: switching virtual desktops left-right-up-down openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: x x (tuxsv748) Partner organization: openSUSE.org Description: there is no Default key Setting fopr switching virtual Desktops in KDE for directions left right up and down. Therefore I would recommend the following keysets: CTRL+ALT+<left,right,up,down> eg MAC is using CTRL+<left,right> to slide between virtual Desktops, so using Linux in an VM on a MAC does not Impact the native behavior, but imitates it similarily -- openSUSE Feature: https://features.opensuse.org/323054

1 1

[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 322957] Use DWZ to shrink the size of debuginfo
by fate_noreply＠suse.de 02 Mar '17

02 Mar '17

Feature added by: Richard Biener (rguenther) Feature #322957, revision 1 Title: Use DWZ to shrink the size of debuginfo Requested by: Richard Biener (rguenther) Partner organization: openSUSE.org Description: RPM can use DWZ (DWARF compressor) to shrink the size of debuginfo. This has the chance to shrink debuginfo to half or more dependent on how many libraries / binaries a package contains. DWZ generates regular DWARF, when applicable the consumers need to know about .gnu_debugaltlink which is eventually added to debuginfo objects to refer to another debuginfo object where common DWARF split out from multiple debuginfo objects is stored. Business case (Partner benefit): openSUSE.org: Smaller (debug-)media, less download time, smaller footprint on disk, faster gdb startup (parsing less dwarf). -- openSUSE Feature: https://features.opensuse.org/322957

1 1