August 2012 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 314335] Continue packaging where it failed
by fate_noreply＠suse.de 15 Aug '12

15 Aug '12

Feature added by: Sven Burmeister (rabauke) Feature #314335, revision 1 Title: Continue packaging where it failed Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Sven Burmeister (rabauke) Partner organization: openSUSE.org Description: Simple use case: A user compiles a new version of some big app, e.g. an office suite. This will take hours of obs resources. Now the new version includes some new files or lacks some which are part of the spec file. The packaging will fail and after the user has changed the spec, the whole package is re-compiled although this would not be necessary. In fact, since the user changes some part of the spec file, he will get an instant rebuild on obs, due to the current scheduling algorithm. There are other possible, comparable packaging failures as well. So the question is how this can be handled in a smarter way, i.e. how to avoid re-compiling the whole source if it is not necessary. This involves balacing resource wasting due to keeping a failed build alive and wasting resources because of having to recompile everything. -- openSUSE Feature: https://features.opensuse.org/314335

1 1

[New: openFATE 313842] auto sleep on login screen with kdm
by fate_noreply＠suse.de 13 Aug '12

13 Aug '12

Feature added by: Philippe Baril Lecavalier (p_barill) Feature #313842, revision 1 Title: auto sleep on login screen with kdm openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Philippe Baril Lecavalier (p_barill) Partner organization: openSUSE.org Description: Any multi-user machine is prone to spend a fair amount of time on the login screen. How come there are no power management settings for this situation? If a user leaves a computer unattended for a few minutes while logged in, it will go to sleep after some minutes. Not so if it stays on the login screen. In this case and with kdm, the user must manually "suspend to RAM", and know the difference between this and "suspend to disk". Besides, I observed that the procedure to initiate sleep on the kdm login screen is quite involved for someone with a low computer literacy: Click on menu > shutdown > hold suspend > select "suspend to RAM" Clicking on "suspend" defaults to hibernate (I think the default should be sleep, not hibernate). Personally, I don't mind. But it's involved enough that some people told me "I got to write that down". There are some ways to automatically logout users after some period of inactivity. This can be justified to avoid waste of network resources. Similarly, the idea of enabling "sleep after x minutes" on the login screen is to save power and avoid unnecessary wear. I do not dare annoy you with yet another default setting request, but a simple way to turn this on. This could be useful in a variety of environments, such as home computers and computer labs with low usage rates (and reduce cooling bills too!). Obviously I deduce little need for this on a single-user machine. The only time I see the login screen is when I boot. Thus my logoff=shutdown. This is primarily about kdm. This follows a discussion from the forum: http://forums.opensuse.org/english/get-technical-help-here/install-boot-log… -- openSUSE Feature: https://features.opensuse.org/313842

1 2

[New: openFATE 311132] Compile Mesa and x-server with --enable-glx-tls
by fate_noreply＠suse.de 13 Aug '12

13 Aug '12

Feature added by: Iaroslav Andrusiak (pontostroy) Feature #311132, revision 1 Title: Compile Mesa and x-server with --enable-glx-tls Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Iaroslav Andrusiak (pontostroy) Partner organization: openSUSE.org Description: Most famous Linux distributions are compile Mesa and x-server with --enable-glx-tls. -- openSUSE Feature: https://features.opensuse.org/311132

1 4

[openFATE 306315] Improve PK/zypper/YaST Big Lock
by fate_noreply＠suse.de 11 Aug '12

11 Aug '12

Feature changed by: Sławomir Lach (Lachu) Feature #306315, revision 17 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: Evaluation by engineering manager Priority Requester: Important Projectmanager: Important Requested by: Federico Lucifredi (flucifredi) Product Manager: Federico Lucifredi (flucifredi) 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 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. -- openSUSE Feature: https://features.opensuse.org/306315

1 0

[openFATE 306315] Improve PK/zypper/YaST Big Lock
by fate_noreply＠suse.de 09 Aug '12

09 Aug '12

Feature changed by: Michael Calmer (mcalmer) Feature #306315, revision 16 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: Evaluation by engineering manager Priority Requester: Important Projectmanager: Important Requested by: Federico Lucifredi (flucifredi) Product Manager: Federico Lucifredi (flucifredi) 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 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. - -- openSUSE Feature: https://features.opensuse.org/306315

1 0

[New: openFATE 313038] Remove "tracker" from lxde
by fate_noreply＠suse.de 09 Aug '12

09 Aug '12

Feature added by: Lutz Thuns (lOtz1009) Feature #313038, revision 1 Title: Remove "tracker" from lxde openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Lutz Thuns (lotz1009) Partner organization: openSUSE.org Description: As LXDE is intended to provide a LEIGHTWEIGHT desktop environment, unnecessary bloats like tracker should not be provided with it. Unfortunately the openSUSE pattern for LXDE contains Brasero, which automatically brings tracker as a dependency. Business case (Partner benefit): openSUSE.org: We want to keep a L ightweight- X - D esktop- E nvironment LIGHTWEIGHT. -- openSUSE Feature: https://features.opensuse.org/313038

1 3

[openFATE 313536] Get rid of SuSEconfig.fonts
by fate_noreply＠suse.de 08 Aug '12

08 Aug '12

Feature changed by: Petr Gajdos (pgajdos) Feature #313536, revision 20 Title: Get rid of SuSEconfig.fonts openSUSE Distribution: Implementation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: There is no point to run that code after installation of every package (and it's not run when you use zypper or 3rd party tools anyways). That code should be only run as a part of post-install of the fonts packages as only those are affected. Relations: - Remove SuSEconfig (feature/id: 100011) Discussion: #1: Petr Gajdos (pgajdos) (2012-07-03 17:13:23) Added "fontpackage" package to the M17N:fonts. fontpackage is intended to common runtime deps of every font package (e. g. /usr/share/fonts/truetype) and fontpackage-devel for buildtime dependency of every font package. fontpackage-devel contains only one file for now, which installs on /etc/rpm/macros.fonts-config. For details see osc cat M17N:fonts fontpackage rpm-macros.fonts-config Example of modified font package is M17N:fonts/xano-mincho-fonts. Could you please express your opinion on this plan? #2: Petr Gajdos (pgajdos) (2012-07-04 09:39:25) (reply to #1) After rethinking I've choosen fontpackages-runtime and fontpackages- devel. #3: Thorsten Kukuk (kukuk) (2012-07-06 14:37:38) I'm not a fonts expert, but looks good to me, beside one thing I don't really like: fontpackages-runtime contains only one directory. I think we should drop that package and package the directory inside of the RPMs which contains fonts. This has the big advantage, that RPM will take care of the directory itself, if the last package using it is removed. Or the directory should be added to filesystem directory, which includes already the parent directory. #4: Petr Gajdos (pgajdos) (2012-07-10 21:32:54) Ok, submitted fontpackages package into factory. sr#127540. #5: Petr Gajdos (pgajdos) (2012-07-11 13:47:20) As far as I can tell, M17N:fonts are ready for removing SUSEconfig. fonts. There are few packages using %run_suseconfig_fonts macro: 844- ksc-pcf (forgotten font package to be moved to M17N:fonts) daps fonts- config plotutils susedoc texlive-bin tv-fonts (package maybe to be moved to M17N:fonts) x3270 xmahjong xorg-x11-fonts xterm Also ghostcript-fonts package is subject to change in this regard (% run_suseconfig -m fonts). Unfortunately I can do anything until fontpackages package is in factory, so this process is blocked by license issue of our own code :- / (see declined sr#127540). Maybe we could consider to accept package as is for now and change license later (of course Novell replaced by SUSE LINUX Products GmbH, Nuernberg, Germany or something like that). #9: Petr Gajdos (pgajdos) (2012-08-07 08:53:26) (reply to #5) I have issued appropriate submitrequests for packages above. I didn't care about building for older distributions because I always try to not add if-suse_version-bloat when not needed. Failing build of packages can be easily fixed by adding new fontpackages (link to M17N: fonts/fontpackages) dependency into project where affected package is located. #6: Petr Gajdos (pgajdos) (2012-07-30 09:22:45) https://bugzilla.novell.com/show_bug.cgi?id=772595 #7: Thorsten Kukuk (kukuk) (2012-08-02 12:09:22) (reply to #6) "You are not authorized to access bug #772595." About what is the bug and why is access limited? #8: Petr Gajdos (pgajdos) (2012-08-02 12:17:48) (reply to #7) This is default policy for legal issues I think. I have added you to cc of this bug. + #10: Petr Gajdos (pgajdos) (2012-08-08 15:17:38) + Request: #130395 submit: home:pgajdos/rpm -> Base:System Message: - + remove %run_suseconfig_fonts macro (openFATE#313536); new macros using + fonts-config directly exist in M17N:fonts/fontpackages + State: new 2012-08-08T13:33:44 pgajdos Comment: <no comment> -- openSUSE Feature: https://features.opensuse.org/313536

1 0

[openFATE 313536] Get rid of SuSEconfig.fonts
by fate_noreply＠suse.de 07 Aug '12

07 Aug '12

Feature changed by: Petr Gajdos (pgajdos) Feature #313536, revision 19 Title: Get rid of SuSEconfig.fonts openSUSE Distribution: Implementation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: There is no point to run that code after installation of every package (and it's not run when you use zypper or 3rd party tools anyways). That code should be only run as a part of post-install of the fonts packages as only those are affected. Relations: - Remove SuSEconfig (feature/id: 100011) Discussion: #1: Petr Gajdos (pgajdos) (2012-07-03 17:13:23) Added "fontpackage" package to the M17N:fonts. fontpackage is intended to common runtime deps of every font package (e. g. /usr/share/fonts/truetype) and fontpackage-devel for buildtime dependency of every font package. fontpackage-devel contains only one file for now, which installs on /etc/rpm/macros.fonts-config. For details see osc cat M17N:fonts fontpackage rpm-macros.fonts-config Example of modified font package is M17N:fonts/xano-mincho-fonts. Could you please express your opinion on this plan? #2: Petr Gajdos (pgajdos) (2012-07-04 09:39:25) (reply to #1) After rethinking I've choosen fontpackages-runtime and fontpackages- devel. #3: Thorsten Kukuk (kukuk) (2012-07-06 14:37:38) I'm not a fonts expert, but looks good to me, beside one thing I don't really like: fontpackages-runtime contains only one directory. I think we should drop that package and package the directory inside of the RPMs which contains fonts. This has the big advantage, that RPM will take care of the directory itself, if the last package using it is removed. Or the directory should be added to filesystem directory, which includes already the parent directory. #4: Petr Gajdos (pgajdos) (2012-07-10 21:32:54) Ok, submitted fontpackages package into factory. sr#127540. #5: Petr Gajdos (pgajdos) (2012-07-11 13:47:20) As far as I can tell, M17N:fonts are ready for removing SUSEconfig. fonts. There are few packages using %run_suseconfig_fonts macro: 844- ksc-pcf (forgotten font package to be moved to M17N:fonts) daps fonts- config plotutils susedoc texlive-bin tv-fonts (package maybe to be moved to M17N:fonts) x3270 xmahjong xorg-x11-fonts xterm Also ghostcript-fonts package is subject to change in this regard (% run_suseconfig -m fonts). Unfortunately I can do anything until fontpackages package is in factory, so this process is blocked by license issue of our own code :- / (see declined sr#127540). Maybe we could consider to accept package as is for now and change license later (of course Novell replaced by SUSE LINUX Products GmbH, Nuernberg, Germany or something like that). + #9: Petr Gajdos (pgajdos) (2012-08-07 08:53:26) (reply to #5) + I have issued appropriate submitrequests for packages above. I didn't + care about building for older distributions because I always try to not + add if-suse_version-bloat when not needed. Failing build of packages + can be easily fixed by adding new fontpackages (link to M17N: + fonts/fontpackages) dependency into project where affected package is + located. #6: Petr Gajdos (pgajdos) (2012-07-30 09:22:45) https://bugzilla.novell.com/show_bug.cgi?id=772595 #7: Thorsten Kukuk (kukuk) (2012-08-02 12:09:22) (reply to #6) "You are not authorized to access bug #772595." About what is the bug and why is access limited? #8: Petr Gajdos (pgajdos) (2012-08-02 12:17:48) (reply to #7) This is default policy for legal issues I think. I have added you to cc of this bug. -- openSUSE Feature: https://features.opensuse.org/313536

1 0

[New: openFATE 311028] Add "Enable/disable numlock at startup" option to installer and YaST
by fate_noreply＠suse.de 04 Aug '12

04 Aug '12

Feature added by: Pieter De Decker (pdedecker) Feature #311028, revision 1 Title: Add "Enable/disable numlock at startup" option to installer and YaST openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: Pieter De Decker (pdedecker) Partner organization: openSUSE.org Description: Related thread: https://features.opensuse.org/310152 Some people who don't have a QWERTY layout can't use the numbers on the top of the keyboard. I'm an AZERTY user (http://en.wikipedia.org/wiki/File:Belgian_pc_keyboard.svg) so I have to hold Shift to use the numbers on top of the keyboard. Therefore I usually prefer using the numpad, but that isn't possible if the numlock is switched off. Auto-enabling numlock at startup would be a huge time-saver. Some people on the other hand prefer having numlock switched off. Quoting Ned Ulbricht: "Enabling NumLock at boot would be very annoying on ThinkPads (and possibly other laptops) that overlay the numeric keypad on top of the alphabetic keys." I think the best way to resolve this little annoyance is to offer the user a choice during install as to what the default setting should be. Or even better: if it's possible to auto-detect which numlock setting is most desirable depending on the keyboard, the user doesn't even need to be presented this option. Additionally, I'd like to see this option added to the "System Keyboard Layout" applet in YaST. Business case (Partner benefit): openSUSE.org: This satisfies people who need to disable numlock for their keyboard to work properly and people who prefer using the numpad. -- openSUSE Feature: https://features.opensuse.org/311028

1 3

[openFATE 307254] Use POSIX capabilities instead of suid
by fate_noreply＠suse.de 04 Aug '12

04 Aug '12

Feature added by: Pascal Bleser (pbleser) Feature #307254, revision 1 Title: Use POSIX capabilities instead of suid openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Pascal Bleser (pbleser) Description: Use POSIX file capabilities instead of suid processes and running e.g. Apache as root: * http://www.nuxified.org/blog/dear-distributors (http://www.nuxified.org/blog/dear-distributors) * http://www.friedhoff.org/posixfilecaps.html (http://www.friedhoff.org/posixfilecaps.html) * https://www.redhat.com/archives/fedora-devel-list/2009-July/msg01568.html (https://www.redhat.com/archives/fedora-devel-list/2009-July/msg01568.html) -- openSUSE Feature: https://features.opensuse.org/307254

1 23