August 2015 - 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 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 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 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