October 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 308132] Need feature bookmark like "watch" in build service
by fate_noreply＠suse.de 25 Oct '09

25 Oct '09

Feature added by: Jigish Gohil (cyberorg) Feature #308132, revision 1 Title: Need feature bookmark like "watch" in build service openFATE: Unconfirmed Priority Requester: Important Requested by: Jigish Gohil (cyberorg) Description: It becomes difficult to keep track of all the features we are interested, feature like bookmark or watch will help us keep all the features we are interested accessible from one place, preferable at the bottom of front page. -- openSUSE Feature: https://features.opensuse.org/308132

1 2

[openFATE 300689] TabletPC: Support Touchscreen and Wacom decives during installation
by fate_noreply＠suse.de 24 Oct '09

24 Oct '09

Feature changed by: Daniel FAIVRE (geomaticien) Feature #300689, revision 42 Title: TabletPC: Support Touchscreen and Wacom decives during installation openSUSE-10.3: Rejected by Stephan Kulow (coolo) reject date: 2007-08-03 09:39:40 reject reason: installation is frozen Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-16 09:02:38 reject reason: Postponing. Out of resources. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Michael Löffler (michl19) reject date: 2009-04-16 12:28:26 reject reason: out of scope for 11.2 Priority Requester: Important Projectmanager: Important openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: 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 no keyboard and no (pohysical) mouse device, only the touchscreen. We should on TabletPCs automatically recognize that it is a TabletPC and configure the Wacom or other Touchscreen device where possible. Thus would enhance the usability of the product on TabletPCs. Discussion: #1: Gary Ekker (gekker) (2007-07-17 11:24:05) Stefan, do you see this as work that your team would do, something that needs to be done by the YaST installer, or both? #6: Matthias Nagorni (mnagorni) (2009-08-24 13:17:30) As long as there is a different way to install it, this appears only like a "nice to have". #7: Daniel FAIVRE (geomaticien) (2009-10-24 07:03:07) There's now really few things to do that for 11.2 : see http://en.opensuse.org/SDB:Howto_install_OpenSuSE_on_HP_tx2-xxxx_laptops Furthermore, for 11.3, it should be mandatory ! To get this support for 11.1 or 11.2, we need to : - replace hid-ntrig.c from 2.6.31 kernel by the up-to date version : just copy/paste. - patching linuxwacom : 4 lines to change. - adding a sax2 profile for these devices in the sax2 cdb file. (11.1 needs a kernel upgrade to a kernel from HEAD repository before) + #8: Daniel FAIVRE (geomaticien) (2009-10-24 07:28:09) (reply to #7) + Read too fast : my post concern support AFTER installation. Please take + care. -- openSUSE Feature: https://features.opensuse.org/300689

1 0

[openFATE 300689] TabletPC: Support Touchscreen and Wacom decives during installation
by fate_noreply＠suse.de 24 Oct '09

24 Oct '09

Feature changed by: Daniel FAIVRE (geomaticien) Feature #300689, revision 41 Title: TabletPC: Support Touchscreen and Wacom decives during installation openSUSE-10.3: Rejected by Stephan Kulow (coolo) reject date: 2007-08-03 09:39:40 reject reason: installation is frozen Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-16 09:02:38 reject reason: Postponing. Out of resources. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Michael Löffler (michl19) reject date: 2009-04-16 12:28:26 reject reason: out of scope for 11.2 Priority Requester: Important Projectmanager: Important openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: 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 no keyboard and no (pohysical) mouse device, only the touchscreen. We should on TabletPCs automatically recognize that it is a TabletPC and configure the Wacom or other Touchscreen device where possible. Thus would enhance the usability of the product on TabletPCs. Discussion: #1: Gary Ekker (gekker) (2007-07-17 11:24:05) Stefan, do you see this as work that your team would do, something that needs to be done by the YaST installer, or both? #6: Matthias Nagorni (mnagorni) (2009-08-24 13:17:30) As long as there is a different way to install it, this appears only like a "nice to have". + #7: Daniel FAIVRE (geomaticien) (2009-10-24 07:03:07) + There's now really few things to do that for 11.2 : see http://en.opensuse.org/SDB:Howto_install_OpenSuSE_on_HP_tx2-xxxx_laptops + Furthermore, for 11.3, it should be mandatory ! + To get this support for 11.1 or 11.2, we need to : + - replace hid-ntrig.c from 2.6.31 kernel by the up-to date version : + just copy/paste. + - patching linuxwacom : 4 lines to change. + - adding a sax2 profile for these devices in the sax2 cdb file. + (11.1 needs a kernel upgrade to a kernel from HEAD repository before) -- openSUSE Feature: https://features.opensuse.org/300689

1 0

[openFATE 308201] Place openSUSE 11.2 GNOME and KDE Quick Start Cards on Desktop
by fate_noreply＠suse.de 23 Oct '09

23 Oct '09

Feature added by: Praveen Kunjapur (stilo_vingyou) Feature #308201, revision 1 Title: Place openSUSE 11.2 GNOME and KDE Quick Start Cards on Desktop openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Praveen Kunjapur (stilo_vingyou) Description: In openSUSE 11.2 LiveCDs, by default, the GNOME and KDE Quick Start Cards should be placed on the Desktop in GNOME and on the Desktop Folder in KDE as that allows me to quick start with openSUSE in one second rather than four seconds if they were placed in Computer-Places-Home in GNOME and Kickoff-Computer-Home in KDE. -- openSUSE Feature: https://features.opensuse.org/308201

1 0

[openFATE 305561] Install Debuginfo Package by build-id
by fate_noreply＠suse.de 23 Oct '09

23 Oct '09

Feature changed by: Stephan Kulow (coolo) Feature #305561, revision 15 Title: Install Debuginfo Package by build-id openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Jan Blunck (janblunck) Developer: Jan Blunck (jblunck) 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 Test Case: * make sure you don't have the debuginfo * run gdb * gdb will output the command line for missing debug infos, e.g. zypper install -C "debuginfo(build-id) =41d4f203d690d7db47fbcc38c3f47a2cdcc6848f" Discussion: #1: Stephan Kulow (coolo) (2009-02-17 11:17:46) Not sure why agruen is set as engmgr, this is simply some rpm hackery. Put a debuginfo.prov script in place, that checks the file list given and give it all /usr/lib/debug/.build-id files. And it will transform /usr/lib/debug/.build- id/00/d9cff1044033b4781ab47388b422b07cb72708.debug into debuginfo (d9cff1044033b4781ab47388b422b07cb72708). After that you can use zypper install -C "debuginfo (d9cff1044033b4781ab47388b422b07cb72708)" and you get kdepim4-debuginfo installed (11.1-x86_64 example). This is an effort of half an hour without testing. #2: Andreas Gruenbacher (agruen) (2009-02-17 16:15:18) (reply to #1) This should work, and the debug info repository metadata should still remain reasonably small. #3: Stephan Kulow (coolo) (2009-04-16 10:43:47) the debuginfo meta data for 11.2 and sle11 contain the build ids. Zypper support is not implemented, but I don't think it's needed as it requires a 10 line shell script wrapper that can live very well in ptools #4: Stephan Kulow (coolo) (2009-08-18 15:07:42) state in factory: gdb will output the command line for missing debug infos, e.g. zypper install -C "debuginfo(build-id) =41d4f203d690d7db47fbcc38c3f47a2cdcc6848f" #5: Alexander Orlovskyy (aorlovskyy) (2009-10-23 14:50:46) Hi Stephan , can you add an example for missing debug infos? + #6: Stephan Kulow (coolo) (2009-10-23 14:59:33) (reply to #5) + no, you can't use a generic example. you will have to try to debug + something. gdb /bin/ls will do. It will output something like this (in + 11.2): + Reading symbols from /bin/ls...Missing separate debuginfo for /bin/ls + Try: zypper install -C "debuginfo(build-id) + =f2ec11f6e0cb0b5306e5f07fd763063747484bf6" (no debugging symbols + found)...done. + This zypper command should work. -- openSUSE Feature: https://features.opensuse.org/305561

1 0

[openFATE 305561] Install Debuginfo Package by build-id
by fate_noreply＠suse.de 23 Oct '09

23 Oct '09

Feature changed by: Alexander Orlovskyy (aorlovskyy) Feature #305561, revision 14 Title: Install Debuginfo Package by build-id openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Jan Blunck (janblunck) Developer: Jan Blunck (jblunck) 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 Test Case: * make sure you don't have the debuginfo * run gdb * gdb will output the command line for missing debug infos, e.g. zypper install -C "debuginfo(build-id) =41d4f203d690d7db47fbcc38c3f47a2cdcc6848f" Discussion: #1: Stephan Kulow (coolo) (2009-02-17 11:17:46) Not sure why agruen is set as engmgr, this is simply some rpm hackery. Put a debuginfo.prov script in place, that checks the file list given and give it all /usr/lib/debug/.build-id files. And it will transform /usr/lib/debug/.build- id/00/d9cff1044033b4781ab47388b422b07cb72708.debug into debuginfo (d9cff1044033b4781ab47388b422b07cb72708). After that you can use zypper install -C "debuginfo (d9cff1044033b4781ab47388b422b07cb72708)" and you get kdepim4-debuginfo installed (11.1-x86_64 example). This is an effort of half an hour without testing. #2: Andreas Gruenbacher (agruen) (2009-02-17 16:15:18) (reply to #1) This should work, and the debug info repository metadata should still remain reasonably small. #3: Stephan Kulow (coolo) (2009-04-16 10:43:47) the debuginfo meta data for 11.2 and sle11 contain the build ids. Zypper support is not implemented, but I don't think it's needed as it requires a 10 line shell script wrapper that can live very well in ptools #4: Stephan Kulow (coolo) (2009-08-18 15:07:42) state in factory: gdb will output the command line for missing debug infos, e.g. zypper install -C "debuginfo(build-id) =41d4f203d690d7db47fbcc38c3f47a2cdcc6848f" + #5: Alexander Orlovskyy (aorlovskyy) (2009-10-23 14:50:46) + Hi Stephan , can you add an example for missing debug infos? -- openSUSE Feature: https://features.opensuse.org/305561

1 0

[openFATE 305574] Integrate ftrace
by fate_noreply＠suse.de 23 Oct '09

23 Oct '09

Feature changed by: Alexander Orlovskyy (aorlovskyy) Feature #305574, revision 9 Title: Integrate ftrace openSUSE-11.2: Done Priority Requester: Mandatory Requested by: Jan Blunck (janblunck) Description: The ftrace infrastructure currently available in upstream kernels comes with different tracers. Having these tracers general available would enable us to find performance and functional regressions more easily during development and in support. Some of them need further work to be included in production kernels (so they don't depend on frame pointers etc.). Discussion: #1: Greg Kroah-Hartman (gregkh) (2009-01-20 05:11:51) We will get these automatically with the 11.2 release, so I don't see this as a big issue at all. Is there something different that we need to do to support these tracers? #2: Stephan Kulow (coolo) (2009-06-24 12:21:35) (reply to #1) ok, so I set this to done #4: Thorsten Kukuk (kukuk) (2009-08-18 10:55:27) Userland ftrace tool: The URLs I found with help of google all don't work. Kernel module: Either we got it with an aggressive upgrade, but we will not backport. + #5: Alexander Orlovskyy (aorlovskyy) (2009-10-23 12:41:55) + Thorsten , how to test this feature? -- openSUSE Feature: https://features.opensuse.org/305574

1 0

[openFATE 120340] Run download and install in parallel
by fate_noreply＠suse.de 22 Oct '09

22 Oct '09

Feature changed by: Michael Kromer (mkromer) Feature #120340, revision 114 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf (kwk) reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:43:03 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 #14: Chris Hills (chaz6) (2009-02-16 16:42:06) Is there a feature request to install using both the base and updates repo so that the latest packages available at install-time are used, thus saving bandwidth? #15: Jiri Srain (jsrain) (2009-02-17 08:45:38) (reply to #14) This is how it works for quite some time. Repositories providing patches also provide the packages so that they can be installed directly from the update repositories (provided they contain newer version). #16: Duncan Mac-Vicar (dmacvicar) (2009-06-02 15:18:00) For 11.2 we will focus on flexibility of the download and install order (like installing after everything is downloaded), however parallel stuff should be done after we have this in place. Please reject. #20: Jörn Knie-von Allmen (phisiker) (2009-08-05 12:12:29) (reply to #16) Please do not reject. With a downloadprotocol this should be solvable. The Installtask can poll an that protocol (or be informed by a Signal when a download has ended. This is better then polling. Or if prefering an IPC-Framework: D-BUS. Never mind!). Such problems I had some times often to solve (but in Java) and generally, it isn't so dificult. #21: Ralph Ulrich (ulenrich) (2009-08-05 13:03:25) (reply to #20) Please reject forever: As operating system are sort of highly integrated databases there should be a commit like funcutionality: First download then install (like debian). Otherwise repositories representing a rolling release (factory) will potentially break an updating system. #22: Reinhard Max (rmax) (2009-08-06 16:18:54) (reply to #21) Yes, there are situations where this (optional) feature should better not be used, but that does not mean it should not be implemented, because there are many situations where it can be very useful. BTW, how would "download then install" give you anything near commit- like functionality? Factory could still change on the server while you are downloading and packages could still fail during installation, leaving you with an inconsistent installation. #24: Ralph Ulrich (ulenrich) (2009-08-11 23:42:59) (reply to #22) Yes, "still fail during installation": there is no commit-like functionality But in case of a changed Factory repository there would be an error: zypper dup --download-then-install || ( zypper ref && zypper dup) || ... In this more often case there would be a commit-like functionality #25: Reinhard Max (rmax) (2009-08-12 11:22:08) (reply to #24) I think the most common case is end users installing from mostly static repositories such as the original release and the official updates. That's what I had in mind when I first suggested this feature many many years ago when there was no openSUSE or Factory. So, please don't insist in this feature being rejected just because you don't have a usecase for it yourself. Nobody will force you to use it if you don't want to. #23: Reinhard Max (rmax) (2009-08-06 16:20:58) (reply to #16) As I've explained in comment #9, the different modes of operation would have been possible with a single implementation and different runtime parameters. I think this would actually be easier than implementing the different modes separately, so why hasn't it been considered? #17: Michal Papis (mpapis) (2009-07-04 20:58:23) I think great example here may be Gentoo, there You can chose the way of getting packages, by default download and installation go in paraler, but it is possible to get first sources and then run build/installation. If you are on the default and something breaks, ex. network, Yuo can always resume the last download&installation task. #18: Giuseppe Salinaro (superpeppo89) (2009-07-16 19:37:27) (reply to #17) This idea of gentoo is good... #19: Ján Kupec (jkupec) (2009-07-20 10:59:31) (reply to #18) Guys, as Duncan wrote in c#16, we are already developing the "download all, install all" mode (currently we only have "download one, install one, ..."), and yes, users will be able to choose one of these. This particular feature would be an improvement of the current mode: "download one, install one while downloading others, ...". I hope this clarifies the current status a bit. #26: Eduard Avetisyan (dich) (2009-09-15 09:16:15) (reply to #19) Sorry Jan, I think both "download one, install one, download next, install next..." and " download all, install all" are both MUCH slower than " download one, install one, download next in parallel ". Come on guys, you focused on two SLOW modes and left the only fast one for future, and that's since 5 versions! Why not reserve a couple of hundred MB (customizable) of diskspace and cache the downloads there while installing in the meantime. Hope it's not too late to think of it for os11.2... + #27: Michael Kromer (mkromer) (2009-10-23 01:11:45) (reply to #26) + Absolutely: I agree with you Eduard. The optimized way is to run a + download process while rpm -{i,U} is running in the background, as all + resources (Disk I/O, CPU, Net) can get used parallel. The only trick is + to keep the installation of following packages on hold, if there is + some kind of package which takes longer (like kernel-{default,source}; + to keep --requires safe; example: kmp's which rely on the specific + kernel version to be installed first, however even this could be + developed in an optimized way, as package lists and therefore also + package requirements are available at time of download). I think there + would even be real great customization options possible like an option + such as --download-threads. So if the installation/upgrade can keep up + with the downloadspeed you will get *significant* performance. And even + if not -> it could never get slower. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

[openFATE 308142] debfoster / deborphan for openSUSE
by fate_noreply＠suse.de 21 Oct '09

21 Oct '09

Feature added by: Andrew Jorgensen (ajorgensen) Feature #308142, revision 1 Title: debfoster / deborphan for openSUSE openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Andrew Jorgensen (ajorgensen) Partner organization: openSUSE.org Description: Debian / Ubuntu have a package called debfoster (also a similar one called deborphan) which aids the administrator in cleaning up unneeded packages from their system. We could do something similar for SUSE. 1) Generate trees of package dependencies 2) Ask the user if he wants to keep the package that's holding the most packages in (offer to keep, remove the parent, or purge the whole tree) 3) Ask the user about the next one and so on until we have a list of all the packages the user wants to keep For SUSE we could probably use the satsolver to build the trees. We could also use installed patterns and products as parents of trees to greatly simplify the process. Business case (Partner benefit): openSUSE.org: Trying out a new package can be frustrating because if I later decide that I don't want that package installed I have to figure out what other packages it pulled in that I also don't want installed. On debian-based systems I can try something and then remove the whole dependency chain easily when I'm done trying. Ubuntu also has a GUI program that does similar things called "Computer Janitor". -- openSUSE Feature: https://features.opensuse.org/308142

1 5

[openFate 305730] Add Package-Wishlist as 'Products' Component
by fate_noreply＠suse.de 21 Oct '09

21 Oct '09

Feature added by: Lars Vogdt (lrupp) Feature #305730, revision 1, last change by Title: Add Package-Wishlist as 'Products' Component openFATE: Unconfirmed Priority Requester: Important Requested by: Lars Vogdt (lrupp) Partner organization: openSUSE.org Description: So current solution for openSUSE users to suggest new packages for inclusion in openSUSE is a bit complicated and diverted in many places: * see the Wislists (http://en.opensuse.org/Wishlist) in the Wiki * see the Bugzilla (http://devzilla.novell.com/education/) of openSUSE-Education * see Novells Bugzilla (https://bugzilla.novell.com/) * see the openSUSE-Forums and Mailinglists... A possible solution with the new openFATE could be to unify the process to request new packages for openSUSE on one single place: openFATE! To make requests of new packages easy, someone should be able to file a request against a "Product" named "New packages" or "Package Wishlist". Perhaps it's possible to create a simple Wizard for this special product in the future, including: * At least two mandatory fields for packagename and upstream URL * and a simple "search for pending requests" after entering the two mandatory fields to avoid duplicates. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305730

1 7