- openSUSE Features

[openFate 300688] Show virtual keyboard on TabletPC during installation
by fate_noreply＠suse.de 14 Jan '09

14 Jan '09

Feature changed by: Michael Loeffler <michl(a)novell.com> Feature #300688, revision 38 Title: Show virtual keyboard on TabletPC during installation openSUSE-10.2: Rejected by Jiri Srain <jsrain(a)novell.com> reject date: 2006-09-25 14:06:21 reject reason: Not enough resources. Priority Requester: Desirable Projectmanager: Desirable - openSUSE-10.3: Rejected by Edith Parzefall <emap(a)novell.com> + openSUSE-10.3: Rejected by Edith Parzefall + <emapedl@please-enter-an-email-address> reject date: 2007-07-24 14:21:32 reject reason: Sorry, not doable for 10.3. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Michael Loeffler <michl(a)novell.com> reject date: 2008-01-11 16:39:04 reject reason: out of scope for openSUSE Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Stefan Behlert (sbehlert) Interested: Gary Ekker (gekker) Interested: Jiri Srain (jsrain) Interested: Stefan Behlert (sbehlert) Description: Tablet PCs are normally produced in two kinds of flavours: Convertibles, which have a keyboard, and Slates, which have none (only pens or touchscreens). If a user installs a Slate, he has to press e.g. buttons without having a keyboard to do it. Additionally he has no mouse device (except his pen) to press buttons. To do so, two ways are possible: Either using some kind of graffiti scribbling, which makes entering e. g. the password an adventure, or by providing a virtual keyboard where the user can select the characters. The second possibility is far superior and also used by Windows. It should be simply to blend xvkbd into the screen. Only possible problems: If a 800x600 resolution is used, the display is really small for both Yast and the keyboard. Discussion: #3: Edith Parzefall (emapedl) (2006-09-20 17:04:28) Jiri, do you see any chance to have it done in your team? Otherwise, I'd reject it. #6: Stephan Kulow (coolo) (2008-01-11 13:50:29) I would think that such devices are out of context for openSUSE 11.0, but asking Michl. How would this look like? Would the xvkbd always be visible and yast screen reduced accordingly? #7: Michael Loeffler (sprudel24) (2008-01-11 16:38:08) As long as this is not required by SLED this is out of scope for openSUSE. #10: Guy Lunardi (glunardi) (2008-01-18 17:34:09) Gartner projects 5% to 20% market penetration for Tablet PCs in the Healthcare. It is positioned as: "Tablet PCs meet all the criteria for a notebook PC and are equipped with a pen and an on-screen digitizer". "The tablet PC is solid and mature for vertical applications where it solves a specific problem. Of course there are 2 kinds of tablets, with physical keyboard and without (slab). I had to install openSUSE 10.3 on a slab myself and must admit that on-screen would have been nice. Is there an engineering effort estimate that could be looked at before we reject it for SLED11? #11: Stefan Behlert (sbehlert) (2008-05-21 21:39:58) (reply to #10) Duncan, any effort estimation? #13: Guy Lunardi (glunardi) (2008-06-23 11:44:51) (reply to #11) As we discussed, support for tablet is primarly critical at runtime. if we can add support for the install, that would be great even for accessibility reasons. I think we should focus our resources on making sure that tablets work well once the system is installed. #14: Duncan Mac-Vicar (dmacvicar) (2008-11-18 13:38:12) (reply to #13) Sure, but this was rejected because there are no resources to do it. So what did we had to drop in order to make it? Without reprioritization there is nothing we can do. I will provide an effort estimation for a next cycle. Estimating the effort here means basically prototyping it, and that just can't be done. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=300688

1 0

[openFate 305561] Install Debuginfo Package by build-id
by fate_noreply＠suse.de 13 Jan '09

13 Jan '09

Feature changed by: Michael Loeffler <michl(a)novell.com> Feature #305561, revision 2 Title: Install Debuginfo Package by build-id - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Mandatory SLES-11-SP1 Requested by: Jan Blunck (janblunck) Description: Since SLE11 we embed build-ids into all binaries. This build-id can be used to match the corresponding debuginfo to a binary file, a running process or a core file. To make it easy for user to install the correct debuginfo, he should be able to run the following command to get the correct debuginfo package installed: zypper install debuginfo-build-id- eb49eeaf82eff32cfbf44d94f9aa8e3cdcf0e461 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305561

1 0

[openFate 305543] software mute not in sync with hardware sync
by fate_noreply＠suse.de 13 Jan '09

13 Jan '09

Feature changed by: Michael Loeffler <michl(a)novell.com> Feature #305543, revision 3 Title: software mute not in sync with hardware sync - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Juergen Weigert (jnweiger) Description: the GUI is not in sync when pressing the mute button in order to unmute the system. Every user who recognizes that the system is not unmuted by pressing the mute button will surely press volume up. Once done, everything is fine again: system is being unmuted in hardware and the GUI is in sync again. it was like this before for ages. bugzilla#389178 was closed as wontfix, as this is not a regression. I'd appreciate that this be fixed some day. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305543

1 0

[openFate 305535] Improve samba yast modules
by fate_noreply＠suse.de 13 Jan '09

13 Jan '09

Feature changed by: Michael Loeffler <michl(a)novell.com> Feature #305535, revision 3 Title: Improve samba yast modules - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important SLED-11-SP1 SLES-11-SP1 Requested by: James McDonough (jmcdough) Interested: Jiří Suchomel (jsuchome) Interested: Lukas Ocilka (locilka) Description: Improve the design of the yast samba modules. More details to come. References: https://bugzilla.novell.com/show_bug.cgi?id=444603 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305535

1 0

[openFate 305571] Add SystemTap GUI
by fate_noreply＠suse.de 13 Jan '09

13 Jan '09

Feature changed by: Michael Loeffler <michl(a)novell.com> Feature #305571, revision 3 Title: Add SystemTap GUI - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important SLES-11-SP1 Requested by: Jan Blunck (janblunck) Description: SystemTap GUI is an application intended to ease in the use of the SystemTap tool for Linux. It is both an Integrated Development Environment for the SystemTap scripting language, as well as a data visualization and analysis tool. The GUI is targetted at System Administrators who want to get information out of their system using SystemTap, as well as Developers who wish to write new SystemTap scripts. It is an Eclipse-based application. Relations: - SystemTap GUI Homepage (url: http://stapgui.sourceforge.net/) -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305571

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 13 Jan '09

13 Jan '09

Feature changed by: JP Rosevear <jpr(a)novell.com> Feature #305634, revision 16 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Andre Duffeck (aduffeck) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) + Interested: JP Rosevear (jproseve) Interested: Klaus Kämpf (kwk) Interested: Matthias Eckermann (mge1512) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) Interested: Thorsten Kukuk (kukuk) Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 13 Jan '09

13 Jan '09

Feature changed by: Stanislav Visnovsky <visnov(a)novell.com> Feature #305634, revision 15 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Andre Duffeck (aduffeck) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: Klaus Kämpf (kwk) Interested: Matthias Eckermann (mge1512) Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) + Interested: Thorsten Kukuk (kukuk) Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

[openFate 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 13 Jan '09

13 Jan '09

Feature changed by: Stefan Behlert <behlert(a)novell.com> Feature #305634, revision 14 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) Interested: Andre Duffeck (aduffeck) Interested: Guy Lunardi (glunardi) Interested: Joe Brockmeier (jbrockmeier) Interested: Klaus Kämpf (kwk) Interested: Matthias Eckermann (mge1512) + Interested: Stefan Behlert (sbehlert) Interested: Stephan Binner (beineri) Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305634

1 0

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

12 Jan '09

Feature changed by: Pavol Rusnak <prusnak(a)novell.com> Feature #305491, revision 29 Title: package names should also be binary names openSUSE-11.2: Evaluation Priority Requester: Desirable SLED-11-SP1 SLES-11-SP1 Requested by: Juergen Weigert (jnweiger) Interested: Federico Lucifredi (flucifredi) Interested: Kai Dupke (kdupke) Interested: Marcus Kraft (marcuskraft) Interested: Stefan Behlert (sbehlert) 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305491

1 0

[openFate 305656] Make hyperlinks from source project names on 'My Projects' page
by fate_noreply＠suse.de 12 Jan '09

12 Jan '09

Feature changed by: Petr Uzel <puzel(a)novell.com> Feature #305656, revision 2 Title: Make hyperlinks from source project names on 'My Projects' page Buildservice: New Priority Requester: Desirable Requested by: Petr Uzel (puzel) + Partner organization: openSUSE.org Description: When I go to 'My Projects' page in OBS, there is a table with requests concerning me at the bottom of the page. For each request, the table contains source project name. I often need to go directly to that project to check the package. This would be much easier, if the project name were hyperlink to the OBS project. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305656

1 0