January 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 302446] Power consumption gauge
by fate_noreply＠suse.de 29 Jan '09

29 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #302446, revision 19 Title: Power consumption gauge openSUSE-11.0: Rejected by Gary Ekker <gekker(a)novell.com> reject date: 2008-05-09 10:28:15 reject reason: Nothing done for 11.0. Priority Requester: Desirable openSUSE-11.1: Rejected by JP Rosevear <jpr(a)novell.com> reject date: 2008-09-10 16:50:33 reject reason: Dependent feature not complete. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Frank Seidel (fseidel) + Partner organization: openSUSE.org Description: Some kind of "power meter" would be good to have. It could be integrated into the system monitor applet or in kpowersave/gnome-power- manager (to be discussed). Its intent is to make the user aware when the system starts to hog power (e.g. after starting some bad behaving application that polls "expensive" hardware all the time). Some kind of "power meter" would be good to have. It could be integrated into the system monitor applet or in kpowersave/gnome-power-manager (to be discussed). Relations: - provide common source for a overall battery time information (feature/id: 303749) Documentation Impact: Needs to be documented Discussion: #1: Michael Loeffler (sprudel24) (2008-02-01 11:56:22) In regards of Green IT theme for SLE 11 this sounds like useful thing. #2: Stefan Behlert (sbehlert) (2008-05-29 23:23:48) (reply to #1) Right.. #4: JP Rosevear (jproseve) (2008-06-02 13:52:01) Christian, can we actually aggregate power consumption information from somewhere? If so, getting a gui on top of it should be straight forward. #5: Christian Zoz (zoz) (2008-06-19 15:03:57) Power consumption information is only available when the system runs on battery. But i guess on ac-power this info is less interesting anyway. We can get this information via ACPI. Not really power consumption, but power drain of each battery. I suggest that hal can provide individual drain and aggregate overall power consumption. For that have a look at feature: #303749: provide common source for a overall battery time information #6: Rodrigo Moya (rodrigomoya) (2008-09-08 14:43:35) For gnome-power-manager, we already have something like this (right- click -> power history), it shows lots of information about powe consumption. Isn't this enough? #7: JP Rosevear (jproseve) (2008-09-10 16:49:55) Fate 303749 is not complete, so I think I have to reject this. -- openSUSE Feature: https://features.opensuse.org/302446

1 0

[openFATE 305474] provide reliable suspend-on-lid-close
by fate_noreply＠suse.de 29 Jan '09

29 Jan '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305474, revision 4 Title: provide reliable suspend-on-lid-close openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Juergen Weigert (jnweiger) Partner organization: openSUSE.org Description: I suggest to have a configuration option cause a suspend on lid-close regardless of other circumstances. Currently * presence of AC-power, * the selected desktop KDE/Gnome/Text, and * presence of docking station all have influence on suspend. The exact logic is apparently changing between beta versions. I'd like to be able to configure a general and unconditional suspend on- lid-close function. -- openSUSE Feature: https://features.opensuse.org/305474

1 0

[openFATE 305686] gnome-screensaver does not respond to an expired password
by fate_noreply＠suse.de 29 Jan '09

29 Jan '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305686, revision 3 Title: gnome-screensaver does not respond to an expired password openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Important Requested by: Guy Lunardi (glunardi) Partner organization: openSUSE.org Description: Using novell-lum-2.2.0.11-0.1 1. Authenticate to eDir, 2. Wait until the desktop is locked with screensaver enabled 3. Expire the user's password 4. Attempt to enter user password to unlock the destkop 5. The screensaver just goes into thinking mode for about 30 seconds then re-prompts the user for the password. If I disable password expire then I am able to unlock the desktop. Am attaching the gnome-screensaver file from /etc/pam.d. Relations: - gnome-screensaver does not respond to an expired password (novell/bugzilla/id: 224690) https://bugzilla.novell.com/show_bug.cgi?id=224690 -- openSUSE Feature: https://features.opensuse.org/305686

1 0

[openFATE 305324] Netcontrol does not set up WLAN when kill switch activated
by fate_noreply＠suse.de 29 Jan '09

29 Jan '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305324, revision 4 Title: Netcontrol does not set up WLAN when kill switch activated openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Important Requested by: Marius Tomaschewski (mtomaschewski) Partner organization: openSUSE.org Description: Provide udev rule to activate / deactivate WLAN interface based on killswitch event --- On my Lenovo ThinkPad T60p, the WLAN hardware kill switch doesn't work as expected. I am _NOT_ using NetworkManager, but the traditional ifup method. The problem seems to be, that the wlan interface is not properly brought up/down when I use the kill switch. --- This wont be fixed for 11.0, because there are different types of killswitch events for different drivers. And it works with NetworkManager. But for 11.1 we should be able to handle it more easily. There will be unified killswitch events. What we need is a additional udev rule that calls ifup for that event. Relations: - Netcontrol does not set up WLAN when kill switch activated (novell/bugzilla/id: 383309) https://bugzilla.novell.com/show_bug.cgi?id=383309 -- openSUSE Feature: https://features.opensuse.org/305324

1 0

[openFATE 305715] Package event framework
by fate_noreply＠suse.de 29 Jan '09

29 Jan '09

Feature changed by: Michael Schröder (mlschroe) Feature #305715, revision 8 Title: Package event framework openSUSE-11.2: New Priority Requester: Desirable Requested by: Andreas Gruenbacher (agruen) Partner organization: openSUSE.org Description: The installation, upgrade, or removal of several packages triggers actions such as running ldconfig, rebuilding the initrd, or similar. Those actions are not specific to the package at hand, but either global with a system-wide effect (such as running ldconfig), or they affect a group of packages (such as all kernel (sub-)packages of a specific version, including all KMPs affectiong it). Those actions need to be run eventually (with order restrictions relative to other package installs, upgrades, or removals), but running them again and again for each package is wasteful. In former days, SuSEconfig was used for some of those tasks, but it turned into a major nightmare (perhaps due to its design). It would be nice if we could come up with a framework in which packages can trigger events and define which actions they need to be run, and rpm will then perform those actions in an appropriate order, avoiding repeating the same action unnecessarily. (The dependencies between actions and package installs/upgrades/removals are somewhat complex, but I think they are manageable.) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 18:09:34) This is desirable only as it happens within RPM's framework (or if the additions are "candy" that does not affect the actual result). This includes upstreaming. I do not want to comment besides the RPM requirement until Engineering determines how (and if) to proceed. There are too many factors involved. Stano, Needinfo me back when you guys have a settled position or decide to postpone this one given the other priorities. #2: Klaus Kämpf (kwk) (2009-01-29 12:45:22) Actually, there is probably litte engineering can do or decide here imho. It very much depends on PMs long-term strategy for RPM. There are currently two options * One is to stay with rpm 4.x and keep the status quo. * The other is to move up to rpm5 and try to influence its development. Upstream implementation of the feature request can only happen within rpm5. Adopting rpm5 for the distribution has several prerequisites: * Investment into rpm5 development. * Getting more distributions to adopt rpm5. * Influencing Linux Standards Base to accept rpm5. Given recent comments from RedHat/Fedora, widespread rpm5 adoption looks rather unlikely. + #3: Michael Schröder (mlschroe) (2009-01-29 12:50:19) (reply to #2) + That sounds like rpm-4 doesn't get new features at all, which is simply + not true. Actually I think it's probably easier to get new features + into rpm-4, because it's very hard to convince Jeff of something he + doesn't like, whereas Panu is more open. -- openSUSE Feature: https://features.opensuse.org/305715

1 0

[openFATE 305715] Package event framework
by fate_noreply＠suse.de 29 Jan '09

29 Jan '09

Feature changed by: Klaus Kämpf (kwk) Feature #305715, revision 7 Title: Package event framework openSUSE-11.2: New Priority Requester: Desirable Requested by: Andreas Gruenbacher (agruen) Partner organization: openSUSE.org Description: The installation, upgrade, or removal of several packages triggers actions such as running ldconfig, rebuilding the initrd, or similar. Those actions are not specific to the package at hand, but either global with a system-wide effect (such as running ldconfig), or they affect a group of packages (such as all kernel (sub-)packages of a specific version, including all KMPs affectiong it). Those actions need to be run eventually (with order restrictions relative to other package installs, upgrades, or removals), but running them again and again for each package is wasteful. In former days, SuSEconfig was used for some of those tasks, but it turned into a major nightmare (perhaps due to its design). It would be nice if we could come up with a framework in which packages can trigger events and define which actions they need to be run, and rpm will then perform those actions in an appropriate order, avoiding repeating the same action unnecessarily. (The dependencies between actions and package installs/upgrades/removals are somewhat complex, but I think they are manageable.) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 18:09:34) This is desirable only as it happens within RPM's framework (or if the additions are "candy" that does not affect the actual result). This includes upstreaming. I do not want to comment besides the RPM requirement until Engineering determines how (and if) to proceed. There are too many factors involved. Stano, Needinfo me back when you guys have a settled position or decide to postpone this one given the other priorities. + #2: Klaus Kämpf (kwk) (2009-01-29 12:45:22) + Actually, there is probably litte engineering can do or decide here + imho. It very much depends on PMs long-term strategy for RPM. + There are currently two options + * One is to stay with rpm 4.x and keep the status quo. + * The other is to move up to rpm5 and try to influence its development. + Upstream implementation of the feature request can only happen within + rpm5. Adopting rpm5 for the distribution has several prerequisites: + * Investment into rpm5 development. + * Getting more distributions to adopt rpm5. + * Influencing Linux Standards Base to accept rpm5. + Given recent comments from RedHat/Fedora, widespread rpm5 adoption + looks rather unlikely. -- openSUSE Feature: https://features.opensuse.org/305715

1 0

[openFATE 305491] package names should also be binary names
by fate_noreply＠suse.de 28 Jan '09

28 Jan '09

Feature changed by: Matthias Eckermann (mge1512) Feature #305491, revision 31 Title: package names should also be binary names - openSUSE-11.2: Evaluation + openSUSE-11.2: Duplicate of #303730 Priority Requester: Desirable Requested by: Juergen Weigert (jnweiger) Partner organization: openSUSE.org Description: Many packages providing command line applications do so with commands named different than the package Random examples: install cpuset but call cset; install lvm2 but call lvm; install MPlayer but call mplayer, install MozillaFirefox but call firefox, install NetworkManager-kde but call knetworkmanager; install OpenOffice_org but call soffice/ooffice/oowriter I suggest to create one shell script per package, that is named exactly as the package is named, which tells the user how to use the package (unless a binary with that name already exists). This script could point to existing binaries, print documentation, or simply be a symlink to an existing binary if there is one prominent user callable entry point, whatever makes sense. Discussion: #2: Thorsten Kukuk (kukuk) (2008-11-25 05:58:17) Veto. We decided to name RPMs after the name of the upstream package, especially to be in sync with other distributions and don't confuse ISVs and customers completlty. I don't see any benefit for customers, but only disadvantages for everybody. Between, business case for this very cost-intensiv feature is missing. #3: Thorsten Kukuk (kukuk) (2008-11-25 05:59:18) How would you call "pwdutils"? "useradd"? "userdel"? "passwd"? Split them in 100 little RPMs? #10: Thomas Schmidt (digitaltomm) (2008-11-26 12:00:29) This could be added to the command-not-found tool (http://en.opensuse.org/Scout , don't know whether this is available on SLES). When a command is not found, but scout sees a RPM with exactly this name installed it could display a list of the included binaries. This way no packages would need to be changed, it's only an enhancement to command-not-found. #11: Kai Dupke (kdupke) (2008-11-26 12:43:29) (reply to #10) scout is part of the SLES media. Looks like an answer on how to handle this. Not sure if we install this by default. #14: Pavol Rusnak (prusnak) (2009-01-09 15:56:02) (reply to #11) I and mvyskocil are creators and maintainers of scout. All you need to do is to issue (after installing scout of course): $ scout bin firefox repository | binary | path | package --------------------+---------+----------+---------------- zypp (11.1-oss) | firefox | /usr/bin | MozillaFirefox What else needs to be done? #16: Pavol Rusnak (prusnak) (2009-01-09 15:57:33) (reply to #14) I forgot to note that scout is automatically installed in base system in openSUSE 11.1. #17: Juergen Weigert (jnweiger) (2009-01-09 16:43:41) (reply to #11) Hey, thanks for creating scout. This is very helpful. Currently, I can map from binary to package, by using 'scout bin' This feature is about the reverse, mapping from package to binary. Can this be added to scout? Integration with /usr/bin/command-not-found would be very helpful then. E.g. bash$ MPlayer Package MPlayer includes the following binaries: repository | binary | path | package ---------------------------+---------+----------+--------- zypp (Packman Repository) | mplayer | /usr/bin | MPlayer How do we educate our users about the existance of scout? #19: Pavol Rusnak (prusnak) (2009-01-09 17:30:10) (reply to #17) After discussion with Michal, we'll add -p parameter to each module, which will indicate that package name is provided, not search_term. All modules will benefit from that change, not only "bin", so user could also list all java classes from java package and so on. I'm not quite sure about the command-not-found integration. There are some people who don't like the speed of handler and another extra search will add another fractions of seconds. If user wants that feature, he'll just types: $ scout bin -p MPlayer #20: Pavol Rusnak (prusnak) (2009-01-12 17:58:19) (reply to #19) I pushed change into scout git repo which adds -p option to all modules. Updated packages are also available from home:prusnak:scout repository. Feel free to test. $ scout bin mplayer repository | package | path | binary ----------------+---------+----------+--------- zypp (packman) | MPlayer | /usr/bin | mplayer $ scout bin -p MPlayer repository | package | path | binary ----------------+---------+----------+---------- zypp (packman) | MPlayer | /usr/bin | mplayer zypp (packman) | MPlayer | /usr/bin | gmplayer zypp (packman) | MPlayer | /usr/bin | mencvcd zypp (packman) | MPlayer | /usr/bin | mencoder #15: Michael Loeffler (sprudel24) (2009-01-09 15:58:57) (reply to #10) The Scout way sounds like a good solution. #21: Federico Lucifredi (flucifredi) (2009-01-23 15:18:04) Wow. What a discussion. Stano, we spoke with Michal last year about adopting someone's Hack Week work to provide hinting just the way Ubuntu does (when typing a command name that is not in the system, suggest " zypper in [packagename]" with the appropriate package. This is a duplicate of another feature, and something already agreed on. Package renaming seems unlikely, but hinting was in the list since 11.0. Stano, can you please give us the status on that, and close this feature as duplicate if you can find the other ? -- openSUSE Feature: https://features.opensuse.org/305491

1 0

[openFate 302963] Rating support for FATE
by fate_noreply＠suse.de 28 Jan '09

28 Jan '09

Feature changed by: Andre Duffeck (aduffeck) Feature #302963, revision 14 Title: Rating support for FATE openFATE: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: FATE is becoming a huge database of useless information. Most of this come to the fact that there is only syntantic checking but not social checking. Usecase: Searching and navigating produces lot of: * Duplicate features * Incomplete features (no use cases, examples) * Vague features (a.k.a "#xxxxx YaST should be improved" ) * copy and paste features Features should support rating in the slashdot way (Insightful, Interesting, Informative, Troll, Funny) and rating from 1 to 5. The rating could be used so the same people using FATE could score down low- quality features than only make the process of information flow more difficult. Score threshold could be set by people so only high quality, well specified features are shown. It is important that searching could be done using this ratings. It should be possible to generate rankings over this ratings. Current status FATE does not offer anything to filter low quality features User Experience Query dialog would gain an option for searching. Feature editor would gain a rating dialog where different people would express their rating. Search would be over an average or agregation of this scores. Scores should be saved per rater. Contingency Plan No contingency plan at the software level. At the process level, add comments to every feature lacking business case, detailed description, real benefits, and more important, scope. Documentation Impact: Only needs to be mentioned in the handbook. Test Case: * rate a feature in one or two dimensions (score and category) * search for features >= or <= certain rating Business case (Partner benefit): openSUSE.org: Threshold for feature processing should save thousands of dollars in wasted time doing ping pong, needinfos for features with incomplete information. Even engineering could be optimized when features with no real business case dissapear by social tagging. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2008-04-02 01:26:51) Sounds like an interesting idea for openSUSE. I am looking forward towards considering this for some Phase 2 or so once openFATE (or whatever the name is going to be) is up and running. #3: Stephan Binner (beineri) (2009-01-17 16:03:07) (reply to #1) openFATE is now up and running. Can this request be made public to openSUSE.org partner? #2: Gerald Pfeifer (geraldpfeifer) (2008-11-14 18:05:55) Michl, for the openFATE work. (For SLE, I expect the PMs to take on much of this.) #4: Francis Giannaros (apokryphos) (2009-01-28 16:04:18) This would be great to see. For reference, see https://blueprints.launchpad.net/ubuntu with some good ideas. Also a tag cloud like the build service has might be nice. + #5: Andre Duffeck (aduffeck) (2009-01-28 16:14:23) (reply to #4) + We will release a new openFATE version by the end of the week with both + voting and tagging support (including a cloud ;)) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302963

1 0

[openFate 302963] Rating support for FATE
by fate_noreply＠suse.de 28 Jan '09

28 Jan '09

Feature changed by: Francis Giannaros (apokryphos) Feature #302963, revision 13 Title: Rating support for FATE openFATE: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: FATE is becoming a huge database of useless information. Most of this come to the fact that there is only syntantic checking but not social checking. Usecase: Searching and navigating produces lot of: * Duplicate features * Incomplete features (no use cases, examples) * Vague features (a.k.a "#xxxxx YaST should be improved" ) * copy and paste features Features should support rating in the slashdot way (Insightful, Interesting, Informative, Troll, Funny) and rating from 1 to 5. The rating could be used so the same people using FATE could score down low- quality features than only make the process of information flow more difficult. Score threshold could be set by people so only high quality, well specified features are shown. It is important that searching could be done using this ratings. It should be possible to generate rankings over this ratings. Current status FATE does not offer anything to filter low quality features User Experience Query dialog would gain an option for searching. Feature editor would gain a rating dialog where different people would express their rating. Search would be over an average or agregation of this scores. Scores should be saved per rater. Contingency Plan No contingency plan at the software level. At the process level, add comments to every feature lacking business case, detailed description, real benefits, and more important, scope. Documentation Impact: Only needs to be mentioned in the handbook. Test Case: * rate a feature in one or two dimensions (score and category) * search for features >= or <= certain rating Business case (Partner benefit): openSUSE.org: Threshold for feature processing should save thousands of dollars in wasted time doing ping pong, needinfos for features with incomplete information. Even engineering could be optimized when features with no real business case dissapear by social tagging. Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2008-04-02 01:26:51) Sounds like an interesting idea for openSUSE. I am looking forward towards considering this for some Phase 2 or so once openFATE (or whatever the name is going to be) is up and running. #3: Stephan Binner (beineri) (2009-01-17 16:03:07) (reply to #1) openFATE is now up and running. Can this request be made public to openSUSE.org partner? #2: Gerald Pfeifer (geraldpfeifer) (2008-11-14 18:05:55) Michl, for the openFATE work. (For SLE, I expect the PMs to take on much of this.) + #4: Francis Giannaros (apokryphos) (2009-01-28 16:04:18) + This would be great to see. For reference, see + https://blueprints.launchpad.net/ubuntu with some good ideas. Also a + tag cloud like the build service has might be nice. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302963

1 0

[openFate 305296] Easy Way to Disable Beagle Completely During Installation
by fate_noreply＠suse.de 27 Jan '09

27 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305296, revision 7 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) + Partner organization: openSUSE.org Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305296

1 0