December 2009 - openSUSE Features - openSUSE Mailing Lists

[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

[New: openFATE 308402] Add init script for timidity
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature added by: Michal Seben (mseben) Feature #308402, revision 1 Title: Add init script for timidity openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Michal Seben (mseben) Description: Add init script to timidity daemon (Ubuntu already do this) -- openSUSE Feature: https://features.opensuse.org/308402

1 8

[New: openFATE 308432] VIA EPIA card support
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature added by: Lars Koraeus (koraeus) Feature #308432, revision 1 Title: VIA EPIA card support openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Lars Koraeus (koraeus) Partner organization: openSUSE.org Description: Why not distribute openchrome as other distribution does. This will support all the VIA EPIA mainboards.with CN700, CX700 and CX700M2 chipset. Business case (Partner benefit): openSUSE.org: The applications are more demanding and we need to use all the facilities of the graphics and not only fbdev. -- openSUSE Feature: https://features.opensuse.org/308432

1 0

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

01 Dec '09

Feature changed by: Wang Lance (lzwang) Feature #305686, revision 25 Title: [beta1] gnome-screensaver does not respond to an expired password openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-09-08 20:39:08 reject reason: too late for that. Priority Requester: Mandatory Projectmanager: Important Requested by: Guy Lunardi (glunardi) Description: Using novell-lum-2.2.0.11-0.1 1. Authenticate to eDir, 2. Wait until the desktop is locked with screensaver enabled 3. Expire the user's password 4. Attempt to enter user password to unlock the destkop 5. The screensaver just goes into thinking mode for about 30 seconds then re-prompts the user for the password. If I disable password expire then I am able to unlock the desktop. Am attaching the gnome-screensaver file from /etc/pam.d. Relations: - gnome-screensaver does not respond to an expired password (novell/bugzilla/id: 224690) https://bugzilla.novell.com/show_bug.cgi?id=224690 Discussion: #2: Stefan Behlert (sbehlert) (2009-08-31 11:09:17) Marcus, can you give me an opinion from a security point-of-view? For me that sounds like a correct behavior. I'm wondering how other OSes handle this. #3: Marcus Meissner (msmeissn) (2009-09-07 16:32:41) (reply to #2) I think the reporter means that GNOME screensaver should show a message about the expiredness instead of "nothing". This probagly needs to be implemented in gnome-screensaver. #4: Stefan Behlert (sbehlert) (2009-09-08 20:40:02) (reply to #3) Ah, ok, I had a different understanding, but you are right, a message would be good enough. Alex, could someone from your team look at that? #5: Alex Chun Yin Lau (allau) (2009-09-17 17:29:57) Lance, why don't you take a look and see how difficult to add this message in to the screensaver. #9: Wang Lance (lzwang) (2009-11-25 12:10:27) Hi * I found that this feature is related to security. GS implemented three methods for authorization in source level. They are forking a process to call /sbin/unix2_chkpwd, directly calling pam API, and directly accessing system password database. But only one of them can be compiled in GS finally. Currently in SLED the default method is using the unix2_chkpwd helper. * I also found that the function of this feature has been implemented in the method of directly calling pam API. And it is not possible to implement the feature by avoiding modifying the source of /sbin/unix2_chkpwd which is a part of the package pam. Beause the unix2_chkpwd returns nothing about the expired password. * So I made a rpm with the method of directly calling pam API. However it need to change the default configuration about GS in /etc/pam.d. I do not kown, if it is OK. * I think maybe we need security team to look this part. * And this is the URL of new packages https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… Thanks Lance Wang #10: Marcus Meissner (msmeissn) (2009-11-30 10:10:25) (reply to #9) He asked me directly... quoting: The feature I am working on need to change the default pam configration of +gnome-screensaver. In /etc/pam.d/gnome-screensaver the original settings are auth include common-auth account include common-account password include common-password session include common-session and the settings I changed to are auth required pam_env.so auth optional pam_gnome_keyring.so auth required pam_unix.so sha512 shadow nullok try_first_pass use_authok account include common-account password include common-password session include common-session #11: Marcus Meissner (msmeissn) (2009-11-30 10:12:49) (reply to #10) I do not think this will work. common-auth is there for a reason, namely you can switch authentication methods. YOu are overriding it to hard and fixed new method. also with fixed password crypt method. I do not see how this can change the timeout behaviour I also do not know if gnome-screensaver is able to do that anyway due to its simple method of chceking passwords. Ludwig or Thorsten , any comment? #12: Thorsten Kukuk (kukuk) (2009-11-30 11:23:21) (reply to #10) This settings doesn't make any sense and I fail to see why this changes do fix the issue. This changes can only fix the issue of the analysis of the problem is completly wrong. Expires is only checked in acct, so why does gnome-screensaver calles accounting at all? If gnome-screensaver should not check accounting, don't call that modules. If it should check accounting, the current behavior is exactly what you want. #13: Ludwig Nussel (lnussel) (2009-11-30 12:02:10) (reply to #12) Actually gnome-screensaver does not check accounting when using unix2_chkpwd as unix2_chkpwd doesn't check accounting. This can be seen when using a local user and expiring it's shadow info. I guess the eDir server actually locks the account or the pam module that authenticates with the eDir server gets it wrong. FWIW even if gnome-screensaver is compiled without unix2_chkpwd ie does the pam conversation itself and does call pam_acct_mgmt the expiry info gets lost. gnome-screensaver doesn't check the return value of pam_acct_mgmt... #14: Thorsten Kukuk (kukuk) (2009-11-30 12:05:42) (reply to #13) Ok, then my analysis is the following: - Problem only happens with novell-lum - gnome-screensaver, unix2_chkpwd and pam_unix2 do all ignore accounting => novell-lum checks accounting in auth phase, too. This is a novell- lum bug and should be handled via bugzilla, but nothing we can change on SLE* #15: Thorsten Kukuk (kukuk) (2009-11-30 12:07:39) (reply to #14) And this explains why the modified pam config file "fixes" the issue: it removes novell-lum. Removing novell-lum from common-auth would have the same effect. + #16: Wang Lance (lzwang) (2009-12-01 04:46:50) + I am sorry. I lost a lot of the details about the way of modifying. + 1. I know little about lum or eDir. + 2. According comment 3 and 4, I just want gnome-screensaver to show + a message instead of no response. + 3. The return of the unix2_chkpwd is just only Yes or NO. But the + return of directly calling pam includes all kinds of errors. And the + errors already can be shown in the dialog according the source code. So + I change the way from unix2_chkpwd to directly calling pam. + 4. With the pam module compiled in, gnome-screensaver could not make + successful auth as the default configuration of /etc/pam.d/gnome- + screensaver needs privilege rights. So I change the default + configuration. + 5. I do not known if it is OK to change the default configuration, + so I ask Marcus. + 6. Because I konw little about eDir, so I comment the package URL + hoping anyone can test it with the eDir configuration. + Hope you can understand. + After reading your comments I am also sure that the reason is at novell- + lum. Beause checking expiration is in account management stage of pam. + Anyway I think it is better use the way directly calling pam instead of + unix2_chkpwd as the former can return more info than the latter. + And another request if anyone could tell me that is there any message + shown when the gnome-screensaver compiled with pam is under the + configuration of eDir and the password is expired. + Thanks, + Lance Wang -- openSUSE Feature: https://features.opensuse.org/305686

1 0

[New: openFATE 308420] define and use repo index service for opensuse
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature added by: Josef Reidinger (jreidinger) Feature #308420, revision 1 Title: define and use repo index service for opensuse openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Josef Reidinger (jreidinger) Description: Hi, we should define Repo index service for opensuse ( http://en.opensuse.org/Standards/Repository_Index_Service ). advantage: - easy upgrade via zypper and other services - easy to testing latest snapshot - very easy to do it disadvantage: - I don't see anything There should be 2 services. 1) default one is opensuse_release...it defined repository for latest stable repository, so now 11.2 oss, non-oss, debug and update and after we release 11.3 then it switch to 11.3 repositories and user just need to refresh service and run zypper dup 2) testing for opensuse snapshot. It points to snapshot of development version of opensuse, so user could easy switch between alpha2 and alpha3 just updating repository and run zypper dup. Use Case: User A want update from 11.1 to 11.2. Now he must update manually all repositories and run zypper dup. Afterwards, it is enough to refresh service and run zypper dup, which is more easy. -- openSUSE Feature: https://features.opensuse.org/308420

1 4