January 2010 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308474] Only install a recommended subset of screensavers by default
by fate_noreply＠suse.de 07 Apr '10

07 Apr '10

Feature added by: Vincent Untz (vuntz) Feature #308474, revision 1 Title: Only install a recommended subset of screensavers by default openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Description: At the moment, a default openSUSE install gets all the screensavers from xscreensaver. While it's quite nice, for most people, that's way too much. I believe a selection of 10-15 screensavers should be made, and then the xscreensaver package should be split in: * xscreensaver: would contain the binary, and its data files * xscreensaver-recommended: would contain the recommended screensavers * xscreensaver-extras: would contain all the other screensavers Note that we'll also need to adapt the gnome-screensaver packaging for this, but that should be easy. Also, this would make it possible to install xscreensaver-recommended without xscreensaver itself, which is useful for GNOME, but probably also for KDE. -- openSUSE Feature: https://features.opensuse.org/308474

1 2

[New: openFATE 308598] Samba Description Field
by fate_noreply＠suse.de 31 Mar '10

31 Mar '10

Feature added by: Malvern Star (Solaris444) Feature #308598, revision 1 Title: Samba Description Field openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Malvern Star (solaris444) Description: The Samba Server YaST UI should allow users to edit the description field that is visible to the network for each machine. The Samba Server configuration component in YaST allows users to set shares, workgroup, netbios identifier and WINS server for the machine, however it does not allow the user to set the description field. The is somewhat inconvenient as the default description is always the Samba version string, meaning that Windows machines (which display the description string FIRST when viewing the network) will group all Linux machines on the network together. It would be helpful to be able to set this field without enabling swat or editing the Samba config file. -- openSUSE Feature: https://features.opensuse.org/308598

1 2

[openFATE 307552] Cups 1.4 RPM's
by fate_noreply＠suse.de 30 Mar '10

30 Mar '10

Feature added by: Dean Hilkewich (deanjo13) Feature #307552, revision 1 Title: Cups 1.4 RPM's Package Wishlist: Unconfirmed Priority Requester: Important Requested by: Dean Hilkewich (deanjo13) Description: It would be nice if the cups packages could be upgraded to 1.4 in 11.2. I realize it's a bit late in the development stage but it just went final on Aug 28th and does carry a large number of improvements. http://www.cups.org/documentation.php/whatsnew.html -- openSUSE Feature: https://features.opensuse.org/307552

1 5

[New: openFATE 308407] Simplify debranding in Kiwi and SUSE Studio
by fate_noreply＠suse.de 29 Mar '10

29 Mar '10

Feature added by: M. Edward (Ed) Borasky (znmeb) Feature #308407, revision 1 Title: Simplify debranding in Kiwi and SUSE Studio openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: M. Edward (Ed) Borasky (znmeb) Description: I build appliances based on openSUSE. I've done some of them in SUSE Studio, and some of them on my workstation using Kiwi, VirtualBox OSE, Xen or VMware Workstation. I am starting to get some that I'd like to distribute. In order to distribute them, I need to be able to re-brand some packages - remove the openSUSE branding and replace it with upstream branding or my own. See http://en.opensuse.org/Making_a_SUSE_based_distribution (http://en.opensuse.org/Making_a_SUSE_based_distribution) for the details. I've tried to do this using SUSE Studio, since it's a lot more convenient, but I have been unable to create a de-branded appliance because of package conflicts in the built-in patterns. See http://n2.nabble.com/Branding-distributing-etc-tp4030350p4030350.html (http://n2.nabble.com/Branding-distributing-etc-tp4030350p4030350.html) The essential difficulty, both in SUSE Studio and in Kiwi is that the base patterns which define package lists contain unremovable branding packages. For these patterns, I need to 1) Find a list of all the packages in the patterns and their dependencies 2) Acquire the source for the branded packages, de-brand them at the source level, and then rebuild binary RPMs. That's a significant amount of labor with no value added to the recipients of the redistributed software. So what I am requesting is that the openSUSE project 1) Make the base patterns ("default", "kde4", "gnome", "xfce", etc.) branding-free, and create a new "branding-openSUSE" pattern to replace the upstream branding with openSUSE branding, and 2) Create de-branded RPMs for the few packages that don't have a "branding-upstream" equivalent. I haven't done the research to identify all of these, but I believe most of them are in the YaST infrastructure. -- openSUSE Feature: https://features.opensuse.org/308407

1 4

[New: openFATE 308344] archive mounter
by fate_noreply＠suse.de 24 Mar '10

24 Mar '10

Feature added by: Andrew Jorgensen (ajorgensen) Feature #308344, revision 1 Title: archive mounter openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Andrew Jorgensen (ajorgensen) Description: GVFS supports mounting archives like iso, zip, tar.gz, etc. Making a menu entry to mount archives is trivial. Ubuntu has had this for a while now and it's very handy. -- openSUSE Feature: https://features.opensuse.org/308344

1 3

[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

[New: openFATE 308758] bs_worker shall support rpm caching also for product builds
by fate_noreply＠suse.de 15 Mar '10

15 Mar '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #308758, revision 1 Title: bs_worker shall support rpm caching also for product builds Buildservice: New Priority Requester: Important Requested by: Adrian Schröter (adriansuse) Description: A remote bs_worker (means not on main server), which builds products is not able to cache the rpm binaries atm. This makes it in-efficient to build products and we can't build up dedicated image build hosts atm. Caching for this mode shall get implemented. -- openSUSE Feature: https://features.opensuse.org/308758

1 4