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