June 2009 - openSUSE Features - openSUSE Mailing Lists

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

05 Jun '09

Feature changed by: Michael Löffler (michl19) Feature #306404, revision 6 Title: Provide easily visible access to manuals - openSUSE-11.2: Unconfirmed + openSUSE-11.2: Evaluation Priority Requester: Important 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

[openFATE 306403] KOffice 2.1 in 11.2
by fate_noreply＠suse.de 05 Jun '09

05 Jun '09

Feature changed by: Michael Löffler (michl19) Feature #306403, revision 5 Title: KOffice 2.1 in 11.2 - openSUSE-11.2: Unconfirmed + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Jean Cayron (jeancayron) Developer: Stephan Binner (beineri) Description: KOffice 2.1 will be released in november 2009, at the same time than openSUSE 11.2 ( see release plan (http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.1/Release_Plan) ). Since the 2.0 will not be feature complete, it would be great for KDE4 integration to have the latest version on the official repositories (maybe do as Firefox the RC with later update). Let make the people choose their Office Suite. -- openSUSE Feature: https://features.opensuse.org/306403

1 0

[openFATE 306197] Ship multiple automake versions.
by fate_noreply＠suse.de 05 Jun '09

05 Jun '09

Feature added by: Luis Medinas (lmedinas) Feature #306197, revision 1, last change by Title: Ship multiple automake versions. openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Luis Medinas (lmedinas) Description: In order to build gnome from svn (probably other projects need it too) we need automake-1.4 1.7 1.8 and 1.9. It would be good if we deliver an option to work with update-alternatives to choose the automake version. This should really be integrated in the base system. This is a goal for 11.2 from the GNOME team, having gnome svn build without building from source this dependencies. Usually this tools are used by Gnome developers. -- openSUSE Feature: https://features.opensuse.org/306197

1 4

[openFATE 306436] Filter for Leaf Packages in Software Management
by fate_noreply＠suse.de 05 Jun '09

05 Jun '09

Feature changed by: Michael Löffler (michl19) Feature #306436, revision 4 Title: Filter for Leaf Packages in Software Management - openSUSE-11.2: New + openSUSE-11.2: Duplicate of #300758 Priority Requester: Mandatory - openSUSE-11.3: New + openSUSE-11.3: Duplicate of #300758 Priority Requester: Mandatory Requested by: Berthold Gunreben (azouhr) Description: I'd like to see a new Filter in the Software Management of YaST that enables the user to see "Leaf" packages that do not provide functionality needed by other packages. This would make it easier for customers to remove unneeded packages from the system. Discussion: #1: Rémy Marquis (spyhawk) (2009-05-15 16:50:20) Strongly related to Feature 300758 (orphaned packages). To be marked as a duplicate. See https://features.opensuse.org/300758 - -- openSUSE Feature: https://features.opensuse.org/306436

1 0

[openFATE 306327] Add DB2 Express-C
by fate_noreply＠suse.de 05 Jun '09

05 Jun '09

Feature changed by: Michael Löffler (michl19) Feature #306327, revision 9 Title: Add DB2 Express-C - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Robert Schweikert (rjschwei) Description: IBM is interested to providing an easy mechanism for users to install DB2 Express C, the free version of DB2. It would be nice if we could add DB2 Express C to the openSUSE non-oss repository. Relations: Discussion: #3: Glenn Doig (doiggl) (2009-04-24 06:16:56) http://www-01.ibm.com/software/data/db2/express/ http://www-01.ibm.com/software/data/db2/express/download.html #4: Pascal Bleser (pbleser) (2009-05-20 22:00:05) Why not, let's go for it. If IBM wants to see openSUSE as a vehicle to drive the adoption of their products, even if not opensource, and as long as it doesn't affect the license/EULA/redistribution of the distribution itself, I don't see any reason not to support that initiative. IBM can choose to either have it in the non-OSS repository, or host it in a repository of their own, with openSUSE builds. What is involved on our side of things ? #5: Robert Schweikert (rjschwei) (2009-05-28 09:21:00) - IBM has a distribution agreement that needs to be signed. In addition I think when somone installs DB2-Express C from the non-oss repo we should pop up a box telling them about the agreement if they intend to distribute DB2 Express with a product. No registration required for private use. #6: Robert Schweikert (rjschwei) (2009-05-28 09:22:04) Added attachment Distribution agreement (IBM_DB2_and_WAS_CE_Distribution_Form_and_Agreement_4_17_2009.pdf) -- openSUSE Feature: https://features.opensuse.org/306327

1 0

[openFate 305681] yast2 remote and vnc server
by fate_noreply＠suse.de 05 Jun '09

05 Jun '09

Feature added by: andrea florio (anubisg1) Feature #305681, revision 1, last change by Title: yast2 remote and vnc server openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: andrea florio (anubisg1) Partner organization: openSUSE.org Description: the remote yast module should start a vnc (and/or rdp) server too.. right now it simply open firewall ports, that means it is un-usefull like that... because it not allow you to control remotly the pc -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305681

1 4

[openFATE 305682] Implement the possibility to allow Add-on source from remote "Plain RPM directory"
by fate_noreply＠suse.de 05 Jun '09

05 Jun '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305682, revision 7 Title: Implement the possibility to allow Add-on source from remote "Plain RPM directory" - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-06-05 15:10:52 + reject reason: Doesn't make sense from a technical point of view. Priority Requester: Important Requested by: Stefan Assmann (assmannst) Partner organization: openSUSE.org Description: During installation when configuring an add-on product there is an option called "Local Directory". If you choose that the next window will have a checkbox "Plain RPM Directory" which allows to add a directory that only contains RPMs as an add-on source. Unfortunately this seems not to be available if you try to configure an add-on product that is not stored locally. Neither FTP, HTTP, SMB, NFS etc... have an option to add a "Plain RPM Directory". This is really useful for exchanging single or multiple RPMs during development without the need to wait for the next development snapshot to verify changes made to the RPMs install fine. Support for this should be implemented into autoyast as well. Gives the opportunity to automatically configure a plain rpm update add-on source for easy exchange of RPMs. Business case (Partner benefit): openSUSE.org: Improves development process because developers can test the influence of their changes to RPMs during installation without having to wait for the next development snapshot. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 19:43:30) This is nice candy for developers. Good idea. #2: Christoph Thiel (cthiel1) (2009-05-28 14:30:47) (reply to #1) I'm unsure if remote plain rpm dirs make much sense. Directory listing + getting the metadata would be a pain. How about adding a hint on how to simply create a remote repo with just a few RPMs in there by running "createrepo" on that directory? #3: Jiri Srain (jsrain) (2009-06-02 10:52:31) (reply to #2) I agree with Christoph. Also remember that in general it is not possible to list directories on remote sources (e.g. HTTP/HTTPS). Add-on product consists of more than just the packages - it contains some additional metadata with product description etc. Therefore one needs to create some metadata anyway and plain directory cannot work as an add-on product. -- openSUSE Feature: https://features.opensuse.org/305682

1 0

[openFATE 305535] Improve samba yast modules
by fate_noreply＠suse.de 05 Jun '09

05 Jun '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305535, revision 12 Title: Improve samba yast modules - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-06-05 15:10:01 + reject reason: Missing details. Priority Requester: Important Requested by: James McDonough (jmcdough) Partner organization: openSUSE.org Description: Improve the design of the yast samba modules. More details to come. References: https://bugzilla.novell.com/show_bug.cgi?id=444603 Business case (Partner benefit): openSUSE.org: Many customers report difficulties with various areas of samba yast administration, both with new features requested and layout of current ones. Discussion: #1: Christoph Thiel (cthiel1) (2009-05-28 15:34:16) James, do you have more details yet? Otherwise, we'll have to reject it for openSUSE 11.2 right away. -- openSUSE Feature: https://features.opensuse.org/305535

1 0

[openFATE 305317] Default to hidden bootloader menu
by fate_noreply＠suse.de 05 Jun '09

05 Jun '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305317, revision 11 Title: Default to hidden bootloader menu openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Jiri Srain (jsrain) Description: As long as there is no other operating system present (SUSE is the only system), it makes sense to default to hidden bootloader menu (and booting directly). References: http://www.gnu.org/software/grub/manual/grub.html#Hidden-menu-interface https://bugzilla.novell.com/show_bug.cgi?id=425717 Discussion: #1: Stephan Kulow (coolo) (2009-04-16 10:34:48) I like that idea. I guess it's a tiny change for bootloader, but has possibly some docu impact. #2: Stanislav Visnovsky (visnov) (2009-05-28 16:45:13) How should it behave with option to keep kernels from updates (libzypp option)? What about failsafe? #3: Jiri Srain (jsrain) (2009-06-01 11:21:11) From the GRUB documentation: When your terminal is dumb or you request GRUB to hide the menu interface explicitly with the command `hiddenmenu' (*note hiddenmenu::), GRUB doesn't show the menu interface (*note Menu interface::) and automatically boots the default entry, unless interrupted by pressing ESC. When you interrupt the timeout and your terminal is dumb, GRUB falls back to the command-line interface (*note Command-line interface::). This sounds to me like this GRUB feature is intended for different purpose, and the use case described here does not make much sense (unlike lowering the time-out to e.g. 1 second). Torsten, what is your view? According to the documentation, GRUB allows to display the boot menu via pushing the Escape button. -- openSUSE Feature: https://features.opensuse.org/305317

1 0

[openFATE 305657] finer grained PolicyKit support for Networkmanager
by fate_noreply＠suse.de 05 Jun '09

05 Jun '09

Feature changed by: Michael Löffler (michl19) Feature #305657, revision 8 Title: finer grained PolicyKit support for Networkmanager - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Description: NetworkManager currently only supports one PolicyKit privilege. That is whether a user is allowed to modify administrator defined connections or not. There is no way to disallow users to define their own network configurations. NetworkManager should at least support one additional PolicyKit privilege that defines whether or not users are allowed to bring their own network configuration or whether they mere are allowed to use administrator defined ones. Use Case: - disallow workers on centrally administered machines to configure different network settings - protect home users that only ever connect to a few well known nets from accidently changing their setup -- openSUSE Feature: https://features.opensuse.org/305657

1 0