November 2016 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 312602] Add NTP.br in openSUSE Linux 12.1
by fate_noreply＠suse.de 16 Nov '16

16 Nov '16

Feature added by: Genix Info (genixinfo) Feature #312602, revision 1 Title: Add NTP.br in openSUSE Linux 12.1 openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Genix Info (genixinfo) Partner organization: openSUSE.org Description: Add NTP.br in openSUSE Linux 12.1: http://www.ceptro.br/CEPTRO/EnglishHome#NTP_br_Brazilian_Legal_Time_over (http://www.ceptro.br/CEPTRO/EnglishHome#NTP_br_Brazilian_Legal_Time_over) -- openSUSE Feature: https://features.opensuse.org/312602

1 13

[openFATE 306315] Improve PK/zypper/YaST Big Lock
by fate_noreply＠suse.de 16 Nov '16

16 Nov '16

Feature changed by: Karl Cheng (qantas94heavy) Feature #306315, revision 21 Title: Improve PK/zypper/YaST Big Lock openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 11:45:36 reject reason: no resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Rejected by Duncan Mac-Vicar (dmacvicar) reject date: 2013-03-05 15:41:44 reject reason: not done in 11.3 Priority Requester: Important Projectmanager: Important openSUSE Distribution: Implementation Priority Requester: Important Requested by: Stephan Kulow (coolo) Partner organization: openSUSE.org Description: Currently, execution of any action by one of the package management tools blocks all others, in a "big lock" fashion". This is entirely acceptable when I am doing something with YaST, or running the PK applet, but it is very fastidious when it is due to background activity. Running zypper and seeing that lock message when nothing is being run by the user is very annoying (and is really the same for Yum on RHEL - but it still sucks :-) Can we improve the way PK refreshing causes everything else to lock up? I must say I expect upstream to be doing something about this... At the very least (and that's the M below for 11.3) we should inclrease the interval with which PK grabs the Big Lock. References: http://lists.opensuse.org/zypp-devel/2008-03/msg00075.html https://bugzilla.novell.com/show_bug.cgi?id=551761 + Relations: + - Suggest packagekit to quit when it conflicts with yast sw_single + (feature/id: https://features.opensuse.org/309367) Business case (Partner benefit): openSUSE.org: The lock interferes with Administrator activity at random moments, and is very aggravating. It would be a competitive detail over RHEL, as well as a customer satisfaction item. Discussion: #1: Federico Lucifredi (flucifredi) (2009-03-30 21:13:47) I am somewhat reluctant to give this an M, as I do not know if something can actually be done to improve this. It would certainly warrant an M if a good solution can be devised, as this is really annoying on both SLES and RHEL, and it would make us look good in the comparison. #2: Ján Kupec (jkupec) (2009-11-06 10:30:50) Even if one zypp app is running, one should still be able to use the other in read-only mode (searching, reporting needed updates from current metadata, etc.). #3: Ralph Ulrich (ulenrich) (2009-11-07 01:01:08) This would be really cheap a read only zypper: rypper: only read only action enabled Benefit: I can do some working tasks with zypper and while this works I am able to inform myself using: rypper se -s something #4: Federico Lucifredi (flucifredi) (2009-11-10 04:29:58) Probably looking at the frequancy with which PK grabs the Big Lock is worth doing... I don't care to be notified by a popup within five minutes of an update being released if that means that most of the time my zypper calls bump into the big-lock-surprise. Yast is a non-issue, people can figure out to close it. it is the PK grabbing that is annoying, and is equally on RHEL (YUM) and SLES (zypper), we should tone down the frequency of its checks. #5: Juergen Weigert (jnweiger) (2010-06-21 17:24:41) Rypper would not get my votes as a stand-alone tool. It requires the user to know its existance and purpose. Zypper having an exception handler and falling back to readonly mode by itself would get my vote, though. Another option could be to allow zypper to do a 'killall packagekit' when needed. BNC#456165 indicates no downsides for this 'suggested' approach. Lowering the frequency of PK runs eases the symptoms, but does not cure the issue. Giving user-triggered-actions priority over system- background-tasks cures it. #6: Sławomir Lach (lachu) (2012-08-11 11:36:22) Instead of locking whole packaging stack we can lock only packages. Dependency and packages, which are touching by translation can be locked. #7: Duncan Mac-Vicar (dmacvicar) (2013-03-05 15:44:20) Michael already started to work in a global lock that allows for read- only actions to happen without locking other read-only actions (eg. search). Once in place we will need to see what other non-read-only action can happen in parallel if they don't share protected resources (rpm database, solv files, etc). -- openSUSE Feature: https://features.opensuse.org/306315

1 0

[New: openFATE 309840] Supress verbose messages after Grub
by fate_noreply＠suse.de 15 Nov '16

15 Nov '16

Feature added by: Anshul Jain (anshuljain) Feature #309840, revision 1 Title: Supress verbose messages after Grub openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Anshul Jain (anshuljain) Description: In the current bootsplash scenario, after we select the kernel version (or by default starts to boot with the only available kernel), it gives a brief 3-4 second verbose message on the screen.. something on the lines of "Uncompressing Kernel...<and the kernel options parameters>". It then proceeds to the bootsplash screen of openSUSE that we're all familiar with. This is elegantly supressed under Ubuntu through a patch called quiet.diff. I've added this patch to the grub SRPM and successfully built and installed it on my laptop (its available in my OBS at :- http://download.opensuse.org/repositories/home:/anshuljain/openSUSE_11.2_Up…). I'd appreciate if the official maintainer of Grub can add this patch so that the boot can be a lot more elegant than what it is right now. -- openSUSE Feature: https://features.opensuse.org/309840

1 8

[New: openFATE 310666] More modern sound theme for KDE4
by fate_noreply＠suse.de 15 Nov '16

15 Nov '16

Feature added by: Otso Rajala (daedaluz) Feature #310666, revision 1 Title: More modern sound theme for KDE4 openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Otso Rajala (daedaluz) Partner organization: openSUSE.org Description: Let's face it: the default soundscape provided by upstream KDE4 release is far from ideal. Majority of sounds in it are too long (default login/logout sounds, anyone?) and they do sound very old-fashioned (plain piano) while desktop itself is the most advanced available. I propose that we adopt some of the other, more modern sounding open licence sound schemes around to fix this issue. My personal favourite from OpenDesktop.org is Feather sound set, fail.wmv omitted completely, incoming_call.wmv cut in half with Audacity and used as login sound and finally opening.wav used as logout. http://opendesktop.org/content/show.php/Feather+Sound+Set?content=90916 I welcome every suggestion into this discussion. Business case (Partner benefit): openSUSE.org: It provides the whole desktop enviroment with a much more modern feel while requiring minimal amount of work to alter upstream release. -- openSUSE Feature: https://features.opensuse.org/310666

1 4

[openFATE 307769] remove X-KDE-SubstituteUID and edit Exec on YaST2 .dekstop files
by fate_noreply＠suse.de 15 Nov '16

15 Nov '16

Feature added by: andrea florio (anubisg1) Feature #307769, revision 1 Title: remove X-KDE-SubstituteUID and edit Exec on YaST2 .dekstop files openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: andrea florio (anubisg1) Partner organization: openSUSE.org Description: All YaST .destop files in /usr/share/applications/YaST2 use the "X-KDE-SubstituteUID" to make them running as root. X-KDE-SubstituteUID is a KDE only "workaround" for that only KDE is supposed to be able to understand. Really, also GNOME as very famous DE understand that. All the others DE like XFCE, LXDE, Icewm and so on do not understand that (and they are not supposed to do that) so they run all yast2 modules as NON root user. all that Desktop files should edit their exec line and maybe remove X-KDE-SubstituteUID exactly as has been done with /usr/share/applications/YaST.desktop into yast2-control-center package. /usr/share/applications/YaST.desktop content: [Desktop Entry] X-SuSE-translate=true Type=Application Categories=Settings;System;SystemSetup;X-SuSE-Core-System;X-SuSE-ControlCenter-System; Name=YaST Icon=yast GenericName=Administrator Settings Exec=/usr/bin/xdg-su -c /sbin/yast2 #OnlyShowIn=KDE;GNOME; #X-KDE-SubstituteUID=true X-KDE-RootOnly=true X-KDE-System-Settings-Parent-Category=system X-KDE-ServiceTypes=KCModule Encoding=UTF-8 as you can see use /usr/bin/xdg-su -c in Exec line, made the .desktop file DE independent Test Case: https://bugzilla.novell.com/show_bug.cgi?id=540627 Use Case: any user running a DE different that KDE/GNOME will run al yast2 modules as non root user with all the warnings/errors that came from that Business case (Partner benefit): openSUSE.org: That will increase openSUSE usability for users running a different DE like XFCE and LXDE, and will be a great step to have that feature: https://features.opensuse.org/307729 perfectly working -- openSUSE Feature: https://features.opensuse.org/307769

1 3

[New: openFATE 312750] Make Yast2 stay open after installing packages
by fate_noreply＠suse.de 15 Nov '16

15 Nov '16

Feature added by: ursan marius bogdan (creatura85) Feature #312750, revision 1 Title: Make Yast2 stay open after installing packages openSUSE.org: Unconfirmed Priority Requester: Important Requested by: ursan marius bogdan (creatura85) Partner organization: openSUSE.org Description: As we all know YaST2 is the best control center around and as title says, can we make it even better by keeping it open after one or more packages are installed? (just like Synaptic for e.g.). I know this can be done adjusting some setting http://dl.dropbox.com/u/10573557/SUSE%20Misc/yast-at-close-action.jpeg but i was thinking if it is possible to make it a default setting for versions to come. Business case (Partner benefit): openSUSE.org: This feature will reduce the time of opening the package manager for any operations: install, delete and upgrade. -- openSUSE Feature: https://features.opensuse.org/312750

1 19

[New: openFATE 312647] Preserve Running Kernel On Kernel Update by Default
by fate_noreply＠suse.de 15 Nov '16

15 Nov '16

Feature added by: Robert Davies (robopensuse) Feature #312647, revision 1 Title: Preserve Running Kernel On Kernel Update by Default openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Robert Davies (robopensuse) Partner organization: openSUSE.org Description: My suggestion is to enable multiversion kernel & preserve running kernel for safer kernel updates, to reduce support problems when new kernels won't boot. This is now possible for 12.1 by 1 line change to zypp.conf. Since Online Update was first introduced (SuSE 7.1?) it replaced the running kernel by default, which can lead to problems booting. For a while multiversion kernel has been supported by libzypp (1 line edit in zypp.conf). The drawback with multiversion was manual deletion required of unwanted kernel packages (see http://lists.opensuse.org/opensuse-kernel/2011-07/msg00056.html). Now in Factory 12.1 M3 Michel Marek has included & announced - kernel package retention options (see http://lizards.opensuse.org/2011/07/14/improved-kernel-package-retention-in…). The default is sane, to preserve the Lastest & Running Kernels. So lets use it and make 12.1 kernel updates safer for all, and by default do the right thing! Use Case: End user upgrades kernel to Tumbleweed and it fails to boot. With kernel package retention, the running kernel was saved and recovery is simply a matter of choosing the "good" kernel from GRUB menu. Business case (Partner benefit): openSUSE.org: To reduce support caused by kernel upgrade "accidents". To encourage safer testing of Kernel Team "stable" & "HEAD" kernels. To correct a long standing risky choice, made for implementation convenience of deleting old kernel package, before the new was tested. -- openSUSE Feature: https://features.opensuse.org/312647

1 8

[New: openFATE 311388] openSUSE Sky
by fate_noreply＠suse.de 15 Nov '16

15 Nov '16

Feature added by: Timo Hoenig (thoenig) Feature #311388, revision 1 Title: openSUSE Sky openSUSE Distribution: Unconfirmed Priority Requester: Important openSUSE Infrastructure: Unconfirmed Priority Requester: Important Requested by: Timo Hoenig (thoenig) Partner organization: openSUSE.org Description: With this feature I am announcing openSUSE Sky. openSUSE Sky will bring our distribution to cloud environments by providing official images for both openSUSE releases and snapshots of current development versions. With openSUSE Sky running the latest and greatest snapshot of openSUSE will be as easy as a mouse click. This gives developers the most efficient way for reproducing bugs on vanilla snapshots. Cloud users will appreciate to have access to trusted built of our distribution without any unknown modifications (e.g. intentional backdoors). Target cloud platforms are Amazon EC2 (using EBS/S3) and Eucalyptus (Walrus). Target audience are cloud users and developers. -- openSUSE Feature: https://features.opensuse.org/311388

1 5

[New: openFATE 316224] Drop dhcpcd from distribution
by fate_noreply＠suse.de 15 Nov '16

15 Nov '16

Feature added by: Peter Varkoly (varkoly) Feature #316224, revision 1 Title: Drop dhcpcd from distribution Requested by: Peter Varkoly (varkoly) Partner organization: openSUSE.org Description: We are going to drop dhcpcd on SLES. There are more reasons: 1. We already have two alternate packages for dhcpcd: dhcp-client and wicked. 2. The actual version will not be maintained by upstream 3. An update to the actual dhcpcd version requires a lot of unneeded work. Stefan Winterfeld was informed and he knows that our initrd must be adapted. -- openSUSE Feature: https://features.opensuse.org/316224

1 6

[openFATE 320859] Weak dependency support
by fate_noreply＠suse.de 14 Nov '16

14 Nov '16

Feature changed by: Adrian Schröter (adrianSuSE) Feature #320859, revision 3 Title: Weak dependency support Buildservice: Evaluation by project manager Milestone: 2.8 Priority Requester: Important Projectmanager: Important Requested by: Adrian Schröter (adriansuse) - Partner organization: SUSE + Partner organization: openSUSE.org Description: We need support for weak dependencies inside of OBS backend. This is needed in first place for image building where recommended or suggested packages should be added as well. -- openSUSE Feature: https://features.opensuse.org/320859

1 0