December 2009 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308478] Smart card support module yast2
by fate_noreply＠suse.de 06 Dec '09

06 Dec '09

Feature added by: Erik Winands (ewinands) Feature #308478, revision 1 Title: Smart card support module yast2 openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Erik Winands (ewinands) Description: I would be nice to add a smart cart install/config module to the yast2 interface. -- openSUSE Feature: https://features.opensuse.org/308478

1 0

[New: openFATE 308476] Make text cell interpretation configurable
by fate_noreply＠suse.de 06 Dec '09

06 Dec '09

Feature added by: Kohei Yoshida (kohei_yoshida) Feature #308476, revision 1 Title: Make text cell interpretation configurable Requested by: Kohei Yoshida (kohei_yoshida) Description: For xls compatibility reasons, we modify the formula calculation so that * text cells in an addition throw an error e.g. =A1+B1 where B1 is a text cell. * text cells in SUM are interpreted as 0 e.g. =SUM(A1:B1) where B1 is a text ell. But some users don't like these behaviors since they are "inconsistent" with each other. We probably therefore make these configurable, perhaps in the 'Formula' option page. -- openSUSE Feature: https://features.opensuse.org/308476

1 1

[New: openFATE 308475] Rework applications menu structure to avoid patching upstream desktop files
by fate_noreply＠suse.de 06 Dec '09

06 Dec '09

Feature added by: Vincent Untz (vuntz) Feature #308475, revision 1 Title: Rework applications menu structure to avoid patching upstream desktop files openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Description: Right now, we have an applications menu structure that is specific to openSUSE. This has two direct results: * because of some checks in brp-check, we have to make sure we use the categories specified in http://en.opensuse.org/SUSE_Package_Conventions/Desktop_Menu, and used them in the way that is descrived there. This is not good because this means we're doing it in a different way from what the xdg menu specification recommends (we're requiring stuff that is not required there). * we have to change the categories in many .desktop files, which results either in patches or usage of %suse_update_desktop_file which then goes unnoticed with time (which can be an issue when upstream adds/removes categories from the upstream .desktop file). And often we just use some random categories to make the above check happy, while this doesn't match the reality of the application. This will require some discussion between the GNOME and KDE packagers -- as far as I can tell, the KDE packagers seem happy this way, but the GNOME packagers dislike what's going on. It might be hard to agree on a different way to handle the menu structure, but it's relatively common sense that at least all our .desktop file changes should be right, and should be sent upstream. -- openSUSE Feature: https://features.opensuse.org/308475

1 0

[openFATE 308183] Hdd Label
by fate_noreply＠suse.de 06 Dec '09

06 Dec '09

Feature added by: andrea martin (Il_Cjargnel) Feature #308183, revision 1 Title: Hdd Label openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: andrea martin (il_cjargnel) Description: Is posible in yast2-->partitioner make a boxtest for canghe a label of hard disk / partition? Thank's by Andrea -- openSUSE Feature: https://features.opensuse.org/308183

1 1

[New: openFATE 308249] ability of disable IPv6 auto-configuration
by fate_noreply＠suse.de 05 Dec '09

05 Dec '09

Feature added by: Per Jessen (pjessen) Feature #308249, revision 1 Title: ability of disable IPv6 auto-configuration openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Per Jessen (pjessen) Partner organization: openSUSE.org Description: Add a setting in /etc/sysconfig/network/ifcfg-XXXX to specify "Do not auto-configthis interface for IPv6". Business case (Partner benefit): openSUSE.org: It would appear that other distros, e.g. CentOS, have the ability to specify that a network interface should not be auto-configured for IPv6. This is useful when the interface will not be used for IPv6, e.g. for PPPOE. -- openSUSE Feature: https://features.opensuse.org/308249

1 1

[openFATE 306404] Provide access to manuals
by fate_noreply＠suse.de 05 Dec '09

05 Dec '09

Feature changed by: Jan Engelhardt (jengelh) Feature #306404, revision 28 Title: Provide access to manuals openSUSE-11.2: Evaluation Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Frank Sundermeyer (fsundermeyer) Description: In openSUSE 11.1 it is almost impossible for a regular user to access the official manuals. By default, only the complete set of HTML manuals is installed, while the PDFs are not installed by default. There is no way of easily locating the packages containing them unless you know the package names. In order to improve this * the term "manual" has to appear in the package name or at least in the summary of the package * a Pattern "Manuals" is needed Theoretically the HTML manuals should be accessible via the KDE or GNOME help center. In the past the help centers have made lots of trouble when integrating the manuals, so they almost always were either not available in KDE or GNOME. Since the release of KDE4, for example, they can no longer be integrated into the KDE help center. Apart from that, the help center has certain disadvantages: * no proper search within the manuals * too many clicks are needed to access a manual * not printable * users of other GUIs have no easy access to the manuals (via the filesystem only) Therefore the PDFs have to be installed by default, too. Additionally an entry "Manuals" with links to the PDFs has to be added to the main menus of the GUIs (KDE, GNOME, XFCE,...). Documentation Impact: Evaluate if RPMs can postinstall the unpacked PDFs from the install- Media Discussion: #1: Michael Löffler (michl19) (2009-06-05 16:15:21) Having the manuals accessible in the Help Center is sufficient, adding pdfs imo just nice to have. #2: Frank Sundermeyer (fsundermeyer) (2009-12-01 16:39:11) (reply to #1) As I pointed out in the initial description: Since the release of KDE4 the manuals are no longer available from the KDE help center. #3: Juergen Weigert (jnweiger) (2009-12-01 17:26:58) This request comes from doc-team and doc-team will implement it. The request is only here to synchronize efforts. I see the following defects: - we obsolete old docu packages with opensuse-manuals_en, but do not require the set of new packages. So nothing is currently installed. - user has to guess package names and activly hunt for the packages. do we have a reason for not installing docs? Disc space should not be a limitation. - installation manual should also be unpacked in the root directory of the install medium. RPM package for the installed system also has a copy of this. Look into a more clever RPM package. - create appropriate mene entries. (desktop files?) - place a doc-icon on the plasma desktop (decide if we have PDF or HTML there?) - integrate searchable docs in the startup menue search engine. I see no reasons for not doing any of the above. PM, please advise. #4: Karl Eichwalder (keichwa) (2009-12-02 08:04:28) HTML in KDE4: According to https://bugzilla.novell.com/show_bug.cgi?id=391185 it finally worked on 11.1 (maybe, there is still a confusion with KDE3 and KDE4). A KDE expert must check this please and tell us how the desktop files must look alike and where we should install them. Installing PDF by default: Sometime ago we were told that we should not clutter the user's disk with install two falors of our manuals and that HTML would be the better choice. In earlier times the PDFs used to be unpackaged on the media, though. Aside: I'd rather prefer Info files (and PDFs), but that's a different story. Invisibility of the docs: There is quite some noise about the books in the wiki (and on novell.com/documentation) If you ask google about "opensuse documentation" or "docs", en.opensuse.org/Documentation is the first hit. It looks a little bit different, if you use "manuals" instead of "Documentation", but still fine. Label or Summary of the package description: I just stick with the book title (modulo bugs). Everything else will lead to confusion. These days, package metadata are either kept in BS config files or in our special attributes" files. I would be fine with me, if some human being or an automatic make command would maintain the attributes file. #7: Juergen Weigert (jnweiger) (2009-12-03 19:24:29) (reply to #5) I added SP1 - I know this is a late feature, and I should file such requests. Sorry. Let us please have some improvement to the current situation in SP1. Minimum effort for SP1 is adding appropriate desktop files. Do we have approval here? #6: Karl Eichwalder (keichwa) (2009-12-03 14:13:31) This is a related feature: fate#306322 Accessing PDFs from within the help centers #10: Juergen Weigert (jnweiger) (2009-12-04 15:24:27) Karl, Stefan pointed me to /work/SRC/all/sled-gnome-cbt_en/ *.spec cbt. desktop implements an icon on the GNOME desktop. Is this helpful? Are *. desktop files menat to be KDE or GNOME specific... ? :-( + #11: Jan Engelhardt (jengelh) (2009-12-05 13:50:14) + This looks solved to me -- openSUSE 11.2 installs openSUSE-manual_en- + pdf by default, even for a Minimal install chosen in yast. -- openSUSE Feature: https://features.opensuse.org/306404

1 0

[openFATE 305572] Extend dwarfextract for generic distro packages
by fate_noreply＠suse.de 05 Dec '09

05 Dec '09

Feature changed by: Jan Engelhardt (jengelh) Feature #305572, revision 12 Title: Extend dwarfextract for generic distro packages openSUSE-11.2: Rejected by (cthiel1) reject date: 2009-12-03 11:41:26 reject reason: not done in time. Priority Requester: Important Projectmanager: Desirable openSUSE-11.3: New Priority Requester: Important Requested by: Jan Blunck (janblunck) Description: dwarfextract is a tool to postprocess debuginfo. The tools removes duplicate type information caused by linking different compilation units. Currently the tool has only been used to work on the debuginfo of the kernel package. The tools should be extended so that it can be used in the buildsystem to postprocess any applications debuginfo (like C++ debuginfo etc.). Tools that use debuginfo like GDB need to tested and fixed accordingly. Relations: - Based on work for this FATE (feature/id: 304323) Discussion: #1: Andreas Jaeger (a_jaeger) (2009-06-09 14:24:16) Let's only do this, if it brings us more than 10 % of space saving. Jan, can you give any numbers from the kernel? + #3: Jan Engelhardt (jengelh) (2009-12-05 13:41:43) (reply to #1) + Any space saving is a space saving (well, for large values of "space") + - there are about 14GB in /debug/dist/11.2/repo/oss, and even if the + saving was somewhat less than 1.4GB (=10%), say 5% instead, it would + seem worthwhile. -- openSUSE Feature: https://features.opensuse.org/305572

1 0

[openFATE 305294] [beta1]Support Rotation hotkey in tablets (RANDR 1.2)
by fate_noreply＠suse.de 04 Dec '09

04 Dec '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305294, revision 30 Title: [beta1]Support Rotation hotkey in tablets (RANDR 1.2) - openSUSE-11.2: Candidate + openSUSE-11.2: Rejected by (sbehlert) + reject date: 2009-12-04 15:29:05 + reject reason: obviously not in 11.2 Priority Requester: Important Projectmanager: Important Requested by: Federico Mena Quintero (federico-mena) Description: Tablet notebooks (especially the fancy new ones with Wacom pressure- sensitive screens) have a physical button to rotate the screen, in case you want to hold the tablet in portrait/landscape mode. We need to capture the XF86RotateWindows keysym, and rotate the laptop's display. Relations: - gnome-settings-daemon-fate305294-xf86rotatewindows.diff (url: http://www.gnome.org/~federico/misc/gnome-settings-daemon-fate305294-xf86ro…) Discussion: #1: Federico Mena Quintero (federico-mena) (2008-09-12 13:32:48) I just started a wiki page to track the status of support for laptops/tablets with these hotkeys: http://en.opensuse.org/Laptop_hotkeys_for_RANDR #2: Stefan Dirsch (sndirsch) (2009-04-15 17:16:00) Don't know how I can help here. #3: Stefan Dirsch (sndirsch) (2009-06-06 12:36:15) This is more for the RANDR >= 1.2 tool developers I would say. #5: Federico Mena Quintero (federico-mena) (2009-09-02 20:26:09) I'll take care of this. #6: Klaas Freitag (kfreitag) (2009-09-02 21:01:09) Great, thanks. Assuming you do it for both SLE and openSUSE I set it to implementation for both platforms. -- openSUSE Feature: https://features.opensuse.org/305294

1 0

[openFATE 306404] Provide access to manuals
by fate_noreply＠suse.de 04 Dec '09

04 Dec '09

Feature changed by: Juergen Weigert (jnweiger) Feature #306404, revision 27 Title: Provide access to manuals openSUSE-11.2: Evaluation Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Frank Sundermeyer (fsundermeyer) Description: In openSUSE 11.1 it is almost impossible for a regular user to access the official manuals. By default, only the complete set of HTML manuals is installed, while the PDFs are not installed by default. There is no way of easily locating the packages containing them unless you know the package names. In order to improve this * the term "manual" has to appear in the package name or at least in the summary of the package * a Pattern "Manuals" is needed Theoretically the HTML manuals should be accessible via the KDE or GNOME help center. In the past the help centers have made lots of trouble when integrating the manuals, so they almost always were either not available in KDE or GNOME. Since the release of KDE4, for example, they can no longer be integrated into the KDE help center. Apart from that, the help center has certain disadvantages: * no proper search within the manuals * too many clicks are needed to access a manual * not printable * users of other GUIs have no easy access to the manuals (via the filesystem only) Therefore the PDFs have to be installed by default, too. Additionally an entry "Manuals" with links to the PDFs has to be added to the main menus of the GUIs (KDE, GNOME, XFCE,...). Documentation Impact: Evaluate if RPMs can postinstall the unpacked PDFs from the install- Media Discussion: #1: Michael Löffler (michl19) (2009-06-05 16:15:21) Having the manuals accessible in the Help Center is sufficient, adding pdfs imo just nice to have. #2: Frank Sundermeyer (fsundermeyer) (2009-12-01 16:39:11) (reply to #1) As I pointed out in the initial description: Since the release of KDE4 the manuals are no longer available from the KDE help center. #3: Juergen Weigert (jnweiger) (2009-12-01 17:26:58) This request comes from doc-team and doc-team will implement it. The request is only here to synchronize efforts. I see the following defects: - we obsolete old docu packages with opensuse-manuals_en, but do not require the set of new packages. So nothing is currently installed. - user has to guess package names and activly hunt for the packages. do we have a reason for not installing docs? Disc space should not be a limitation. - installation manual should also be unpacked in the root directory of the install medium. RPM package for the installed system also has a copy of this. Look into a more clever RPM package. - create appropriate mene entries. (desktop files?) - place a doc-icon on the plasma desktop (decide if we have PDF or HTML there?) - integrate searchable docs in the startup menue search engine. I see no reasons for not doing any of the above. PM, please advise. #4: Karl Eichwalder (keichwa) (2009-12-02 08:04:28) HTML in KDE4: According to https://bugzilla.novell.com/show_bug.cgi?id=391185 it finally worked on 11.1 (maybe, there is still a confusion with KDE3 and KDE4). A KDE expert must check this please and tell us how the desktop files must look alike and where we should install them. Installing PDF by default: Sometime ago we were told that we should not clutter the user's disk with install two falors of our manuals and that HTML would be the better choice. In earlier times the PDFs used to be unpackaged on the media, though. Aside: I'd rather prefer Info files (and PDFs), but that's a different story. Invisibility of the docs: There is quite some noise about the books in the wiki (and on novell.com/documentation) If you ask google about "opensuse documentation" or "docs", en.opensuse.org/Documentation is the first hit. It looks a little bit different, if you use "manuals" instead of "Documentation", but still fine. Label or Summary of the package description: I just stick with the book title (modulo bugs). Everything else will lead to confusion. These days, package metadata are either kept in BS config files or in our special attributes" files. I would be fine with me, if some human being or an automatic make command would maintain the attributes file. #7: Juergen Weigert (jnweiger) (2009-12-03 19:24:29) (reply to #5) I added SP1 - I know this is a late feature, and I should file such requests. Sorry. Let us please have some improvement to the current situation in SP1. Minimum effort for SP1 is adding appropriate desktop files. Do we have approval here? #6: Karl Eichwalder (keichwa) (2009-12-03 14:13:31) This is a related feature: fate#306322 Accessing PDFs from within the help centers + #10: Juergen Weigert (jnweiger) (2009-12-04 15:24:27) + Karl, Stefan pointed me to /work/SRC/all/sled-gnome-cbt_en/ *.spec cbt. + desktop implements an icon on the GNOME desktop. Is this helpful? Are *. + desktop files menat to be KDE or GNOME specific... ? :-( -- openSUSE Feature: https://features.opensuse.org/306404

1 0

[openFATE 306404] Provide access to manuals
by fate_noreply＠suse.de 03 Dec '09

03 Dec '09

Feature changed by: Juergen Weigert (jnweiger) Feature #306404, revision 23 Title: Provide access to manuals openSUSE-11.2: Evaluation Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Frank Sundermeyer (fsundermeyer) Description: In openSUSE 11.1 it is almost impossible for a regular user to access the official manuals. By default, only the complete set of HTML manuals is installed, while the PDFs are not installed by default. There is no way of easily locating the packages containing them unless you know the package names. In order to improve this * the term "manual" has to appear in the package name or at least in the summary of the package * a Pattern "Manuals" is needed Theoretically the HTML manuals should be accessible via the KDE or GNOME help center. In the past the help centers have made lots of trouble when integrating the manuals, so they almost always were either not available in KDE or GNOME. Since the release of KDE4, for example, they can no longer be integrated into the KDE help center. Apart from that, the help center has certain disadvantages: * no proper search within the manuals * too many clicks are needed to access a manual * not printable * users of other GUIs have no easy access to the manuals (via the filesystem only) Therefore the PDFs have to be installed by default, too. Additionally an entry "Manuals" with links to the PDFs has to be added to the main menus of the GUIs (KDE, GNOME, XFCE,...). Documentation Impact: Evaluate if RPMs can postinstall the unpacked PDFs from the install- Media Discussion: #1: Michael Löffler (michl19) (2009-06-05 16:15:21) Having the manuals accessible in the Help Center is sufficient, adding pdfs imo just nice to have. #2: Frank Sundermeyer (fsundermeyer) (2009-12-01 16:39:11) (reply to #1) As I pointed out in the initial description: Since the release of KDE4 the manuals are no longer available from the KDE help center. #3: Juergen Weigert (jnweiger) (2009-12-01 17:26:58) This request comes from doc-team and doc-team will implement it. The request is only here to synchronize efforts. I see the following defects: - we obsolete old docu packages with opensuse-manuals_en, but do not require the set of new packages. So nothing is currently installed. - user has to guess package names and activly hunt for the packages. do we have a reason for not installing docs? Disc space should not be a limitation. - installation manual should also be unpacked in the root directory of the install medium. RPM package for the installed system also has a copy of this. Look into a more clever RPM package. - create appropriate mene entries. (desktop files?) - place a doc-icon on the plasma desktop (decide if we have PDF or HTML there?) - integrate searchable docs in the startup menue search engine. I see no reasons for not doing any of the above. PM, please advise. #4: Karl Eichwalder (keichwa) (2009-12-02 08:04:28) HTML in KDE4: According to https://bugzilla.novell.com/show_bug.cgi?id=391185 it finally worked on 11.1 (maybe, there is still a confusion with KDE3 and KDE4). A KDE expert must check this please and tell us how the desktop files must look alike and where we should install them. Installing PDF by default: Sometime ago we were told that we should not clutter the user's disk with install two falors of our manuals and that HTML would be the better choice. In earlier times the PDFs used to be unpackaged on the media, though. Aside: I'd rather prefer Info files (and PDFs), but that's a different story. Invisibility of the docs: There is quite some noise about the books in the wiki (and on novell.com/documentation) If you ask google about "opensuse documentation" or "docs", en.opensuse.org/Documentation is the first hit. It looks a little bit different, if you use "manuals" instead of "Documentation", but still fine. Label or Summary of the package description: I just stick with the book title (modulo bugs). Everything else will lead to confusion. These days, package metadata are either kept in BS config files or in our special attributes" files. I would be fine with me, if some human being or an automatic make command would maintain the attributes file. + #7: Juergen Weigert (jnweiger) (2009-12-03 19:24:29) (reply to #5) + I added SP1 - I know this is a late feature, and I should file such + requests. Sorry. Let us please have some improvement to the current + situation in SP1. Minimum effort for SP1 is adding appropriate desktop + files. Do we have approval here? #6: Karl Eichwalder (keichwa) (2009-12-03 14:13:31) This is a related feature: fate#306322 Accessing PDFs from within the help centers -- openSUSE Feature: https://features.opensuse.org/306404

1 0

[New: openFATE 308460] Auto-select dependency resolution when only 1 option
by fate_noreply＠suse.de 03 Dec '09

03 Dec '09

Feature added by: Todd R (TheBlackCat) Feature #308460, revision 1 Title: Auto-select dependency resolution when only 1 option openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Todd R (theblackcat) Description: When you get a dependency conflict in the software management module you are provided with a list of options. You then click a radio button to select the option you want to use to resolve the problem. However, in many cases you will end up with only one option. In that case I think that option should automatically have its radio button selected. I should emphasize that I am not saying that the error message should not appear. What I am saying is that the user should not have to click the radio button when there is only one radio button to click, the radio button would automatically be selected (or maybe not have a radio button at all since it ie meaningless, just have YaSt tell the user what it is going to do). The user would still have to click the "ok" or "cancel" button. to approve the action It is a waste of a user's time to make them click the radio button when they have no choice in the matter. -- openSUSE Feature: https://features.opensuse.org/308460

1 1

[openFATE 306976] Incluir Firefox en qt4 en forma predeterminada
by fate_noreply＠suse.de 03 Dec '09

03 Dec '09

Feature added by: Luis Bodino (luigi_bodino) Feature #306976, revision 1 Title: Incluir Firefox en qt4 en forma predeterminada openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Luis Bodino (luigi_bodino) Description: Propongo que se use la versión qt de firefox para una mejor integración con kde -- openSUSE Feature: https://features.opensuse.org/306976

1 9

[openFATE 306404] Provide access to manuals
by fate_noreply＠suse.de 03 Dec '09

03 Dec '09

Feature changed by: Karl Eichwalder (keichwa) Feature #306404, revision 22 Title: Provide access to manuals openSUSE-11.2: Evaluation Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Frank Sundermeyer (fsundermeyer) Description: In openSUSE 11.1 it is almost impossible for a regular user to access the official manuals. By default, only the complete set of HTML manuals is installed, while the PDFs are not installed by default. There is no way of easily locating the packages containing them unless you know the package names. In order to improve this * the term "manual" has to appear in the package name or at least in the summary of the package * a Pattern "Manuals" is needed Theoretically the HTML manuals should be accessible via the KDE or GNOME help center. In the past the help centers have made lots of trouble when integrating the manuals, so they almost always were either not available in KDE or GNOME. Since the release of KDE4, for example, they can no longer be integrated into the KDE help center. Apart from that, the help center has certain disadvantages: * no proper search within the manuals * too many clicks are needed to access a manual * not printable * users of other GUIs have no easy access to the manuals (via the filesystem only) Therefore the PDFs have to be installed by default, too. Additionally an entry "Manuals" with links to the PDFs has to be added to the main menus of the GUIs (KDE, GNOME, XFCE,...). Documentation Impact: Evaluate if RPMs can postinstall the unpacked PDFs from the install- Media Discussion: #1: Michael Löffler (michl19) (2009-06-05 16:15:21) Having the manuals accessible in the Help Center is sufficient, adding pdfs imo just nice to have. #2: Frank Sundermeyer (fsundermeyer) (2009-12-01 16:39:11) (reply to #1) As I pointed out in the initial description: Since the release of KDE4 the manuals are no longer available from the KDE help center. #3: Juergen Weigert (jnweiger) (2009-12-01 17:26:58) This request comes from doc-team and doc-team will implement it. The request is only here to synchronize efforts. I see the following defects: - we obsolete old docu packages with opensuse-manuals_en, but do not require the set of new packages. So nothing is currently installed. - user has to guess package names and activly hunt for the packages. do we have a reason for not installing docs? Disc space should not be a limitation. - installation manual should also be unpacked in the root directory of the install medium. RPM package for the installed system also has a copy of this. Look into a more clever RPM package. - create appropriate mene entries. (desktop files?) - place a doc-icon on the plasma desktop (decide if we have PDF or HTML there?) - integrate searchable docs in the startup menue search engine. I see no reasons for not doing any of the above. PM, please advise. #4: Karl Eichwalder (keichwa) (2009-12-02 08:04:28) HTML in KDE4: According to https://bugzilla.novell.com/show_bug.cgi?id=391185 it finally worked on 11.1 (maybe, there is still a confusion with KDE3 and KDE4). A KDE expert must check this please and tell us how the desktop files must look alike and where we should install them. Installing PDF by default: Sometime ago we were told that we should not clutter the user's disk with install two falors of our manuals and that HTML would be the better choice. In earlier times the PDFs used to be unpackaged on the media, though. Aside: I'd rather prefer Info files (and PDFs), but that's a different story. Invisibility of the docs: There is quite some noise about the books in the wiki (and on novell.com/documentation) If you ask google about "opensuse documentation" or "docs", en.opensuse.org/Documentation is the first hit. It looks a little bit different, if you use "manuals" instead of "Documentation", but still fine. Label or Summary of the package description: I just stick with the book title (modulo bugs). Everything else will lead to confusion. These days, package metadata are either kept in BS config files or in our special attributes" files. I would be fine with me, if some human being or an automatic make command would maintain the attributes file. + #6: Karl Eichwalder (keichwa) (2009-12-03 14:13:31) + This is a related feature: fate#306322 Accessing PDFs from within the + help centers -- openSUSE Feature: https://features.opensuse.org/306404

1 0

[openFATE 305572] Extend dwarfextract for generic distro packages
by fate_noreply＠suse.de 03 Dec '09

03 Dec '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305572, revision 11 Title: Extend dwarfextract for generic distro packages - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by (cthiel1) + reject date: 2009-12-03 11:41:26 + reject reason: not done in time. Priority Requester: Important Projectmanager: Desirable + openSUSE-11.3: New + Priority + Requester: Important Requested by: Jan Blunck (janblunck) Description: dwarfextract is a tool to postprocess debuginfo. The tools removes duplicate type information caused by linking different compilation units. Currently the tool has only been used to work on the debuginfo of the kernel package. The tools should be extended so that it can be used in the buildsystem to postprocess any applications debuginfo (like C++ debuginfo etc.). Tools that use debuginfo like GDB need to tested and fixed accordingly. Relations: - Based on work for this FATE (feature/id: 304323) Discussion: #1: Andreas Jaeger (a_jaeger) (2009-06-09 14:24:16) Let's only do this, if it brings us more than 10 % of space saving. Jan, can you give any numbers from the kernel? -- openSUSE Feature: https://features.opensuse.org/305572

1 0

[New: openFATE 308454] Multi-axis (gamepad) support for joystick module
by fate_noreply＠suse.de 03 Dec '09

03 Dec '09

Feature added by: Todd R (TheBlackCat) Feature #308454, revision 1 Title: Multi-axis (gamepad) support for joystick module openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Todd R (theblackcat) Description: Currently the joystick module in YaST only supports single axis joystick, which are your stanard flight stick-style joystick. However, another popular form of game controller is the game pad, which nowadays often has two or more independent axes (for instance a dual-shock style dual analog stick). I think having support for an arbitrary number of axes on a joystick is useful since these sorts of controllers seem pretty popular. -- openSUSE Feature: https://features.opensuse.org/308454

1 0

[openFATE 303678] New yast module - LIRC configuration
by fate_noreply＠suse.de 03 Dec '09

03 Dec '09

Feature changed by: Todd R (TheBlackCat) Feature #303678, revision 26 Title: New yast module - LIRC configuration openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-06-24 15:31:30 reject reason: More urgent stuff to cover. Priority Requester: Desirable openSUSE-11.2: Rejected by Stanislav Visnovsky (visnov) reject date: 2009-02-02 13:29:45 reject reason: Out of scope. Postponing. Priority Requester: Desirable openSUSE-11.3: New Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) Description: Create a new Yast module for configuring IR receivers and remote controls. * irrecord support * ir-kbd-i2c, ir-kbd-gpio support as in tv module already * reading users' config to find out what buttons were defined (only if /home partition left from last installation) * support for lirc's options in /etc/sysconfig See bug https://bugzilla.novell.com/show_bug.cgi?id=381641 Discussion: #4: Dean Hilkewich (deanjo13) (2009-11-04 06:28:29) I really hope this accepted with 11.3. It just took me a couple of hours to realize that my old lirc config wouldn't work in 11.2 that I used in 11.1. The device was now /dev/lirc0 instead of /dev/lirc like it was in 11.1. + #5: Todd R (theblackcat) (2009-12-03 04:57:52) + I think this is pretty important. LiRC is one of the last classes of + common hardware that cannot be configured using a GUI in openSUSE. -- openSUSE Feature: https://features.opensuse.org/303678

1 0

[openFATE 303873] Reducing pop ups during installation
by fate_noreply＠suse.de 02 Dec '09

02 Dec '09

Feature changed by: Robert Davies (robopensuse) Feature #303873, revision 18 Title: Reducing pop ups during installation openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 11:01:26 reject reason: This can wait. Postponing. Priority Requester: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 17:47:05 reject reason: out of resources for 11.2. Priority Requester: Important Projectmanager: Desirable openSUSE-11.3: New Priority Requester: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: Before installing the system the user is asked to confirm various licenses. Each license is presented via pop up. Depending on the selected packages the user might be forced to accept quite a lot of them. This is quite unusable and we should think about how to reduce these. One idea might be: http://en.opensuse.org/Image:Installation_nopopups.png Not for SLES: Furthermore after accepting all these licenses the user has to confirm the installation in an extra pop up. I do not see the necessity for that pop up as users made the experience with other operating systems who do not ask the user for comfirmation (Apple Mac OS, MS Windows, Ubuntu, Red Hat Enterprise Linux, Fedora) that installation means that something will happen to their hard drive. Discussion: #1: Matthias Eckermann (mge1512) (2008-05-15 12:10:27) I agree with and like: http://en.opensuse.org/Image:Installation_nopopups.png But the extra pop-up for "YES, I really want to wipe my harddisk" must remain, as it is a security and safetiness issue. Marking this part of the idea as "Not for SLES". Federico, what is your opinion here? #2: Michael Löffler (michl19) (2008-05-15 12:27:44) Ciaran can you give the view from a legal perspective? #3: Ciaran Farrell (babelworx) (2008-05-16 11:51:38) I like the setup described in the screenshot and believe that it certainly gives the person installing the opportunity to review every license individually. In fact, I'm going to suggest to Patrick Mc Bride that this could be a default license acceptance method as it is far better than what we currently have available (i.e. all or nothing system). I'll ask Christopher De Nicolo for his opinion (from a german legal perspective). #4: Federico Lucifredi (flucifredi) (2008-05-22 15:47:44) I just went through the 11.0 beta 3 workflow, and I am satisfied with the current state. the mock-up is ok, but consider this: while it is true that you get prompted 5 times to approve licenses, if there is something that users are trained to do, in all platforms, is precisely click accept :-) I would say we can proceed with it, but I don't consider it a major issue, and not a usability problem. by the way, the 11.0 install workflow rocks :-) #5: Robert Davies (robopensuse) (2009-11-30 17:48:32) Recent installs of oS (11.[12] feature few license agreements, surely user pays price for an addiction to proprietary software if they get very many. There would seem to be other areas in YaST UI which would give majority more benefit than a rarely used license overview of type shown (though it looks nice). A way package installation history springs to mind. + #6: Robert Davies (robopensuse) (2009-12-02 19:29:22) (reply to #5) + Did one today, no popups for licenses (just Novell) on initial install, + 2 pop ups on first update, for Adobe Flashplayer and MS web + fonts. Not exactly onerous. -- openSUSE Feature: https://features.opensuse.org/303873

1 0

[openFATE 306404] Provide access to manuals
by fate_noreply＠suse.de 02 Dec '09

02 Dec '09

Feature changed by: Karl Eichwalder (keichwa) Feature #306404, revision 20 Title: Provide access to manuals openSUSE-11.2: Evaluation Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Frank Sundermeyer (fsundermeyer) Description: In openSUSE 11.1 it is almost impossible for a regular user to access the official manuals. By default, only the complete set of HTML manuals is installed, while the PDFs are not installed by default. There is no way of easily locating the packages containing them unless you know the package names. In order to improve this * the term "manual" has to appear in the package name or at least in the summary of the package * a Pattern "Manuals" is needed Theoretically the HTML manuals should be accessible via the KDE or GNOME help center. In the past the help centers have made lots of trouble when integrating the manuals, so they almost always were either not available in KDE or GNOME. Since the release of KDE4, for example, they can no longer be integrated into the KDE help center. Apart from that, the help center has certain disadvantages: * no proper search within the manuals * too many clicks are needed to access a manual * not printable * users of other GUIs have no easy access to the manuals (via the filesystem only) Therefore the PDFs have to be installed by default, too. Additionally an entry "Manuals" with links to the PDFs has to be added to the main menus of the GUIs (KDE, GNOME, XFCE,...). Documentation Impact: Evaluate if RPMs can postinstall the unpacked PDFs from the install- Media Discussion: #1: Michael Löffler (michl19) (2009-06-05 16:15:21) Having the manuals accessible in the Help Center is sufficient, adding pdfs imo just nice to have. #2: Frank Sundermeyer (fsundermeyer) (2009-12-01 16:39:11) (reply to #1) As I pointed out in the initial description: Since the release of KDE4 the manuals are no longer available from the KDE help center. #3: Juergen Weigert (jnweiger) (2009-12-01 17:26:58) This request comes from doc-team and doc-team will implement it. The request is only here to synchronize efforts. I see the following defects: - we obsolete old docu packages with opensuse-manuals_en, but do not require the set of new packages. So nothing is currently installed. - user has to guess package names and activly hunt for the packages. do we have a reason for not installing docs? Disc space should not be a limitation. - installation manual should also be unpacked in the root directory of the install medium. RPM package for the installed system also has a copy of this. Look into a more clever RPM package. - create appropriate mene entries. (desktop files?) - place a doc-icon on the plasma desktop (decide if we have PDF or HTML there?) - integrate searchable docs in the startup menue search engine. I see no reasons for not doing any of the above. PM, please advise. + #4: Karl Eichwalder (keichwa) (2009-12-02 08:04:28) + HTML in KDE4: According to + https://bugzilla.novell.com/show_bug.cgi?id=391185 it finally worked on + 11.1 (maybe, there is still a confusion with KDE3 and KDE4). A KDE + expert must check this please and tell us how the desktop files must + look alike and where we should install them. + Installing PDF by default: Sometime ago we were told that we should + not clutter the user's disk with install two falors of our manuals and + that HTML would be the better choice. In earlier times the PDFs used to + be unpackaged on the media, though. Aside: I'd rather prefer Info files + (and PDFs), but that's a different story. + Invisibility of the docs: There is quite some noise about the books in + the wiki (and on novell.com/documentation) If you ask google about + "opensuse documentation" or "docs", en.opensuse.org/Documentation is + the first hit. It looks a little bit different, if you use "manuals" + instead of "Documentation", but still fine. + Label or Summary of the package description: I just stick with the + book title (modulo bugs). Everything else will lead to confusion. These + days, package metadata are either kept in BS config files or in our + special attributes" files. I would be fine with me, if some human being + or an automatic make command would maintain the attributes file. -- openSUSE Feature: https://features.opensuse.org/306404

1 0

[openFATE 307381] Include PDF Mod
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature added by: Gabriel Burt (gabrielburt) Feature #307381, revision 1 Title: Include PDF Mod openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Gabriel Burt (gabrielburt) Description: PDF Mod is a new tool for doing simple manipulations to PDF documents, including removing, rotating, and extracting pages. -- openSUSE Feature: https://features.opensuse.org/307381

1 10

[openFATE 306404] Provide access to manuals
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature changed by: Juergen Weigert (jnweiger) Feature #306404, revision 18 Title: Provide access to manuals openSUSE-11.2: Evaluation Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Frank Sundermeyer (fsundermeyer) Description: In openSUSE 11.1 it is almost impossible for a regular user to access the official manuals. By default, only the complete set of HTML manuals is installed, while the PDFs are not installed by default. There is no way of easily locating the packages containing them unless you know the package names. In order to improve this * the term "manual" has to appear in the package name or at least in the summary of the package * a Pattern "Manuals" is needed Theoretically the HTML manuals should be accessible via the KDE or GNOME help center. In the past the help centers have made lots of trouble when integrating the manuals, so they almost always were either not available in KDE or GNOME. Since the release of KDE4, for example, they can no longer be integrated into the KDE help center. Apart from that, the help center has certain disadvantages: * no proper search within the manuals * too many clicks are needed to access a manual * not printable * users of other GUIs have no easy access to the manuals (via the filesystem only) Therefore the PDFs have to be installed by default, too. Additionally an entry "Manuals" with links to the PDFs has to be added to the main menus of the GUIs (KDE, GNOME, XFCE,...). Documentation Impact: Evaluate if RPMs can postinstall the unpacked PDFs from the install- Media Discussion: #1: Michael Löffler (michl19) (2009-06-05 16:15:21) Having the manuals accessible in the Help Center is sufficient, adding pdfs imo just nice to have. #2: Frank Sundermeyer (fsundermeyer) (2009-12-01 16:39:11) (reply to #1) As I pointed out in the initial description: Since the release of KDE4 the manuals are no longer available from the KDE help center. + #3: Juergen Weigert (jnweiger) (2009-12-01 17:26:58) + This request comes from doc-team and doc-team will implement it. The + request is only here to synchronize efforts. + I see the following defects: - we obsolete old docu packages with + opensuse-manuals_en, but do not require the set of new packages. So + nothing is currently installed. - user has to guess package names and + activly hunt for the packages. do we have a reason for not installing + docs? Disc space should not be a limitation. - installation manual + should also be unpacked in the root directory of the install medium. + RPM package for the installed system also has a copy of this. Look into + a more clever RPM package. - create appropriate mene entries. (desktop + files?) - place a doc-icon on the plasma desktop (decide if we have PDF + or HTML there?) - integrate searchable docs in the startup menue search + engine. + I see no reasons for not doing any of the above. PM, please advise. -- openSUSE Feature: https://features.opensuse.org/306404

1 0

[openFATE 306404] Provide access to manuals
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature changed by: Frank Sundermeyer (fsundermeyer) Feature #306404, revision 17 Title: Provide access to manuals openSUSE-11.2: Evaluation Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Frank Sundermeyer (fsundermeyer) Description: In openSUSE 11.1 it is almost impossible for a regular user to access the official manuals. By default, only the complete set of HTML manuals is installed, while the PDFs are not installed by default. There is no way of easily locating the packages containing them unless you know the package names. In order to improve this * the term "manual" has to appear in the package name or at least in the summary of the package * a Pattern "Manuals" is needed - The HTML set is either accessible via the KDE or GNOME help center. - This has certain disadvantages: + Theoretically the HTML manuals should be accessible via the KDE or + GNOME help center. In the past the help centers have made lots of + trouble when integrating the manuals, so they almost always were either + not available in KDE or GNOME. Since the release of KDE4, for example, + they can no longer be integrated into the KDE help center. Apart from + that, the help center has certain disadvantages: * no proper search within the manuals * too many clicks are needed to access a manual * not printable * users of other GUIs have no easy access to the manuals (via the filesystem only) - * in the past the help centers have made lots of trouble when - integrating the manuals - on openSUSE 11.1, for example, the manuals - are not displayed at all in the KDE4 help center, so being unaccessible - for KDE4 users Therefore the PDFs have to be installed by default, too. Additionally an entry "Manuals" with links to the PDFs has to be added to the main menus of the GUIs (KDE, GNOME, XFCE,...). Documentation Impact: Evaluate if RPMs can postinstall the unpacked PDFs from the install- Media Discussion: #1: Michael Löffler (michl19) (2009-06-05 16:15:21) Having the manuals accessible in the Help Center is sufficient, adding pdfs imo just nice to have. #2: Frank Sundermeyer (fsundermeyer) (2009-12-01 16:39:11) (reply to #1) As I pointed out in the initial description: Since the release of KDE4 the manuals are no longer available from the KDE help center. -- openSUSE Feature: https://features.opensuse.org/306404

1 0

[openFATE 306404] Provide access to manuals
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature changed by: Frank Sundermeyer (fsundermeyer) Feature #306404, revision 15 Title: Provide access to manuals openSUSE-11.2: Evaluation Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Frank Sundermeyer (fsundermeyer) Description: In openSUSE 11.1 it is almost impossible for a regular user to access the official manuals. By default, only the complete set of HTML manuals is installed, while the PDFs are not installed by default. There is no way of easily locating the packages containing them unless you know the package names. In order to improve this * the term "manual" has to appear in the package name or at least in the summary of the package * a Pattern "Manuals" is needed The HTML set is either accessible via the KDE or GNOME help center. This has certain disadvantages: * no proper search within the manuals * too many clicks are needed to access a manual * not printable * users of other GUIs have no easy access to the manuals (via the filesystem only) * in the past the help centers have made lots of trouble when integrating the manuals - on openSUSE 11.1, for example, the manuals are not displayed at all in the KDE4 help center, so being unaccessible for KDE4 users Therefore the PDFs have to be installed by default, too. Additionally an entry "Manuals" with links to the PDFs has to be added to the main menus of the GUIs (KDE, GNOME, XFCE,...). Documentation Impact: Evaluate if RPMs can postinstall the unpacked PDFs from the install- Media Discussion: #1: Michael Löffler (michl19) (2009-06-05 16:15:21) Having the manuals accessible in the Help Center is sufficient, adding pdfs imo just nice to have. + #2: Frank Sundermeyer (fsundermeyer) (2009-12-01 16:39:11) (reply to + #1) + As I pointed out in the initial description: Since the release of KDE4 the + manuals are no longer available from the KDE help center. -- openSUSE Feature: https://features.opensuse.org/306404

1 0

[openFATE 306404] Provide access to manuals
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature changed by: Juergen Weigert (jnweiger) Feature #306404, revision 14 Title: Provide access to manuals openSUSE-11.2: Evaluation Priority Requester: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Frank Sundermeyer (fsundermeyer) Description: In openSUSE 11.1 it is almost impossible for a regular user to access the official manuals. By default, only the complete set of HTML manuals is installed, while the PDFs are not installed by default. There is no way of easily locating the packages containing them unless you know the package names. In order to improve this * the term "manual" has to appear in the package name or at least in the summary of the package * a Pattern "Manuals" is needed The HTML set is either accessible via the KDE or GNOME help center. This has certain disadvantages: * no proper search within the manuals * too many clicks are needed to access a manual * not printable * users of other GUIs have no easy access to the manuals (via the filesystem only) * in the past the help centers have made lots of trouble when integrating the manuals - on openSUSE 11.1, for example, the manuals are not displayed at all in the KDE4 help center, so being unaccessible for KDE4 users Therefore the PDFs have to be installed by default, too. Additionally an entry "Manuals" with links to the PDFs has to be added to the main menus of the GUIs (KDE, GNOME, XFCE,...). + Documentation Impact: + Evaluate if RPMs can postinstall the unpacked PDFs from the install- + Media Discussion: #1: Michael Löffler (michl19) (2009-06-05 16:15:21) Having the manuals accessible in the Help Center is sufficient, adding pdfs imo just nice to have. -- openSUSE Feature: https://features.opensuse.org/306404

1 0

[openFATE 306404] Provide access to manuals
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature changed by: Juergen Weigert (jnweiger) Feature #306404, revision 13 - Title: Provide easily visible access to manuals + Title: Provide access to manuals openSUSE-11.2: Evaluation Priority Requester: Important + openSUSE-11.3: Evaluation + Priority + Requester: Mandatory Requested by: Frank Sundermeyer (fsundermeyer) Description: In openSUSE 11.1 it is almost impossible for a regular user to access the official manuals. By default, only the complete set of HTML manuals is installed, while the PDFs are not installed by default. There is no way of easily locating the packages containing them unless you know the package names. In order to improve this * the term "manual" has to appear in the package name or at least in the summary of the package * a Pattern "Manuals" is needed The HTML set is either accessible via the KDE or GNOME help center. This has certain disadvantages: * no proper search within the manuals * too many clicks are needed to access a manual * not printable * users of other GUIs have no easy access to the manuals (via the filesystem only) * in the past the help centers have made lots of trouble when integrating the manuals - on openSUSE 11.1, for example, the manuals are not displayed at all in the KDE4 help center, so being unaccessible for KDE4 users Therefore the PDFs have to be installed by default, too. Additionally an entry "Manuals" with links to the PDFs has to be added to the main menus of the GUIs (KDE, GNOME, XFCE,...). Discussion: #1: Michael Löffler (michl19) (2009-06-05 16:15:21) Having the manuals accessible in the Help Center is sufficient, adding pdfs imo just nice to have. -- openSUSE Feature: https://features.opensuse.org/306404

1 0

[New: openFATE 308436] zypper/YaST2: update only major revisions of packages
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature added by: Tristan Miller (psych0naut) Feature #308436, revision 1 Title: zypper/YaST2: update only major revisions of packages openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Tristan Miller (psych0naut) Description: To update my system I often use "zypper up" or "Package->All Packages->Update if newer version available" in YaST2's Software Management applet. However, many of the updates available are only minor revisions to the RPM packaging rather than updates to the software itself (new features, bug fixes, etc.). That is, for a package foo-x.y.z-a.b.x86_64, the available updates increment only a.b rather than x.y.z. Please add a feature to zypper and/or YaST2 which will update only those packages which have updates for the software itself. -- openSUSE Feature: https://features.opensuse.org/308436

1 0