December 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 307423] clone_system client should accept a list of modules
by fate_noreply＠suse.de 24 Mar '10

24 Mar '10

Feature added by: Uwe Gansert (ug) Feature #307423, revision 1 Title: clone_system client should accept a list of modules openSUSE-11.2: New Priority Requester: Mandatory Requested by: Uwe Gansert (ug) Description: the clone_system client that was actually invented only for AutoYaST internal purposes is used quite often by customers too on the command line. Currently the client reads the list of modules to clone from the control.xml file. It would be nice if that list could be passed via command line too. -- openSUSE Feature: https://features.opensuse.org/307423

1 3

[openFATE 307424] invent an "ask"-rule for AutoYaST
by fate_noreply＠suse.de 24 Mar '10

24 Mar '10

Feature added by: Uwe Gansert (ug) Feature #307424, revision 1 Title: invent an "ask"-rule for AutoYaST openSUSE-11.2: New Priority Requester: Mandatory Requested by: Uwe Gansert (ug) Description: two customers had an idea for a new feature for the rule-mechanism for AutoYaST. It would be nice if AutoYaST could ask for the files to merge. So that it looks which XML snippets are available and presents them in some kind of dialog to choose from. -- openSUSE Feature: https://features.opensuse.org/307424

1 3

[openFATE 306192] Make BuildService accessible for anonymous users
by fate_noreply＠suse.de 22 Mar '10

22 Mar '10

Feature added by: Michal Vyskocil (mvyskocil) Feature #306192, revision 1, last change by Title: Make BuildService accessible for anonymous users Buildservice: Unconfirmed Priority Requester: Important Requested by: Michal Vyskocil (mvyskocil) Description: We hides many useful information about our distribution behind a Novell login, which makes a participation harder. Other distributions are much more opened even for anonymous users, so you can browse source codes, patches, changelogs, build logs, ... even if you are an anonymous users. We should be opened as much as possible if we want to be a community based distribution. Some examples: * Fedora CVS (http://cvs.fedoraproject.org/viewvc//) expose all Fedora packages with full history and for anonymous users * kojibuild info (http://koji.fedoraproject.org/koji/buildinfo?buildID=81815) - you have a full access to building informations from koji system and some of them are not available for OBS users at all. * Debian changelog browsing (http://packages.debian.org/changelogs/pool/main/c/cdbs/cdbs_0.4.52/changelog) Debian offers a changelog browsing (they don't use a centralized VCS) without registration. * lintian reports (http://lintian.debian.org/maintainer/build-common-hackers@lists.alioth.debi…) you can see a lintian issues for every package. * Debian build log (http://buildd.debian.org/pkg.cgi?pkg=libmatthew-java) Debian also offers an access to a build log of package. * Gentoo package information (http://packages.gentoo.org/package/app-office/nostaples?ts=2009-03-11T05:57…) Gentoo offers many information about package Those examples are only for illustrate of other approaches. I don't try to tell we must implement CVS because Fedora has it. And some issues like an alternative of Gentoo package view should be implemented in upcoming Software Portal. We should publish (at least for openSUSE:* projects) sources of packages and a build logs. -- openSUSE Feature: https://features.opensuse.org/306192

1 25

[New: openFATE 308453] Integrate patch (update) into software management module
by fate_noreply＠suse.de 15 Mar '10

15 Mar '10

Feature added by: Todd R (TheBlackCat) Feature #308453, revision 1 Title: Integrate patch (update) into software management module openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Todd R (theblackcat) Description: Currently there are two different modules for managing software, the software management module and the online update module. They are mostly the same in terms of the user interface, you can search and install software, browse patterns, groups, repositories, and more or less do most common package management tasks from both. The only major differences that I can see are that the software management module does not let you install patches, the online update module has an extra menu (patch, which just has duplicates of most of the actions in the "package" menu), and online update does not display as much information when doing the installation (like a remaining time estimate). I think this is a fairly redundant approach, there is really no reason I can think of why the software management module can't have the patches tab, and why patches can't use the same menu as packages since they have mostly the same items. So I think combining them into a single module would be more efficient and easier to maintain. You could still have the two modules listed in YaST if you want, clicking on the "software managment" module would just start you off in the search tab while the "online update" module would start you off in the patches tab. But I think it would be better still if you just had one module. When the software management module opens it checks if there are any patches, if there are it displays them and if not it goes straight to the "search" tab (or your last-used tab). -- openSUSE Feature: https://features.opensuse.org/308453

1 1

[openFATE 306852] YaST2 screen title needs a machine-name in it
by fate_noreply＠suse.de 15 Mar '10

15 Mar '10

Feature added by: Greg Riedesel (Gracal) Feature #306852, revision 1 Title: YaST2 screen title needs a machine-name in it openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Greg Riedesel (gracal) Description: The nomenclature, "[YaST control panel] @ [machine name]' is very useful for figuring out which window belongs to which server. Especially if the managing workstation is also openSUSE. Formerly Bug 385625 Use Case: When managing openSUSE servers over X-forwarding via SSH, it is possible to have multiple YaST screens up at the same time, each belonging to a different remote server. Having a way to differentiate between YaST instances in the title-bar will reduce confusion, and help avoid config mistakes. -- openSUSE Feature: https://features.opensuse.org/306852

1 5

[openFATE 308204] Shibboleth web identity service
by fate_noreply＠suse.de 10 Mar '10

10 Mar '10

Feature added by: Markus Kuhn (m_kuhn) Feature #308204, revision 1 Title: Shibboleth web identity service Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Markus Kuhn (m_kuhn) Partner organization: openSUSE.org Description: Shibboleth (http://shibboleth.internet2.edu/) is currently (2009) being rolled out as the standard federated single-signon web user-authentication system in academic institutions in the UK, US, and many other countries. With it, web servers (especially at universities) can easily leave user authentication and authorization to the existing/emerging Shibboleth infrastructure. Of interest to: website operators, especially at universities Licence: Apache 2.0 It may be a good idea to split the Shibboleth Service Provider and the Shibboleth Identity Provider functions into two seperate RPMs, as the former will be used by a large number of sites, whereas the latter only by a small number (typically one per University). Test Case: https://sp.testshib.org/ Use Case: http://shibboleth.internet2.edu/uses.html Business case (Partner benefit): openSUSE.org: Shibboleth is security-critical, runs a server, is integrated with Apache, and depends on having very recent versions of a number of XML, SAML, and crypto libraries installed. Therefore it is not entirely trivial to install and maintain for every casual website administer and thus it would be extremely useful if you could add it as a standard package to the openSUSE and SLES distributions. -- openSUSE Feature: https://features.opensuse.org/308204

1 1

[openFate 305104] Provide possibility to configure WEP/WPA/WPA2/... at installation
by fate_noreply＠suse.de 09 Mar '10

09 Mar '10

Feature added by: Lukas Ocilka <locilka(a)novell.com> Feature #305104, revision 1, last change by Title: Provide possibility to configure WEP/WPA/WPA2/... at installation openSUSE-11.1: New Priority Requester: Desirable Requested by: Jim Creech <jacreech(a)suddenlink.net> Partner organization: openSUSE.org Description: It is possible to configure a network in the first stage installation but it is only possible to select DHCP or Static + configure proxy. It is impossible to configure a secure wireless connection. See also: Bug 293609 (https://bugzilla.novell.com/show_bug.cgi?id=293609) - No provision for entering WEP at installation -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305104

1 9

[New: openFATE 308384] Maven support
by fate_noreply＠suse.de 08 Mar '10

08 Mar '10

Feature added by: dilbert elbonia (100le) Feature #308384, revision 1 Title: Maven support Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: dilbert elbonia (100le) Partner organization: openSUSE.org Description: It would be great if we could install maven from the official repositories. Business case (Partner benefit): openSUSE.org: Maven is becoming more and more popular tool for java (and not only java) development. -- openSUSE Feature: https://features.opensuse.org/308384

1 2

[openFATE 306379] Use rsync when refreshing repositories
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature added by: Piotrek Juzwiak (BenderBendingRodriguez) Feature #306379, revision 1, last change by Title: Use rsync when refreshing repositories openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Piotrek Juzwiak (benderbendingrodriguez) Description: It would be a great idea to use rsync when refreshing repositories, one of the bad things is the refresh speed. It gets worse when people have many repositories. I'm not sure but it already compares if something has changed in the repo but to speed things up it would be great to use rsync. -- openSUSE Feature: https://features.opensuse.org/306379

1 14

[openFATE 307139] Enable KMS for Intel Graphics cards
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature added by: Kshitij Kulshreshtha (polyconvex) Feature #307139, revision 1 Title: Enable KMS for Intel Graphics cards openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Kshitij Kulshreshtha (polyconvex) Description: Since in the Intel Graphics Release 2009Q2 kernel modesetting is the recommended method, please enable CONFIG_DRM_I915_KMS in the kernel config. In the current factory kernel (August 03) CONFIG_DRM_RADEON_KMS is set even though the code is considered unstable and depends on CONFIG_STAGING, however the more stable and recommended CONFIG_DRM_I915_KMS is not set. Please enable this option too. -- openSUSE Feature: https://features.opensuse.org/307139

1 17