November 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 307197] Mencoder Graph Client
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Flex Liu (winddss) Feature #307197, revision 1 Title: Mencoder Graph Client Requested by: Flex Liu (winddss) Description: This is a front-end of the "mencoder" ( a video & audio encode transfer tools. based on gtk & gnome-desktop. you'll use it to change the video or audio encode easier than the command line mode. -- openSUSE Feature: https://features.opensuse.org/307197

1 4

[openFATE 306910] Add the possibility to enable Roaming Home Directories in the YaST Samba Client
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Andreas Schneider (gladiac) Feature #306910, revision 1 Title: Add the possibility to enable Roaming Home Directories in the YaST Samba Client openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Andreas Schneider (gladiac) Description: There should be the possibility to enable Roaming Home Directories with pam_csync in the YaST2 Samba Client module. pam-config has support to setup pam_csync. The YaST module has to change the config file (ini) from pam_csync and run pam-config. Test Case: Login to your Active Directory account. Check if the configuration files have been synchronized to the ADS. Use Case: Roaming Home Directories is the missing piece of the SUSE Active Directory Integration. This feature was planned already for SLE10 and should be possible in one of the next SUSE products. -- openSUSE Feature: https://features.opensuse.org/306910

1 2

[openFATE 307415] Back to the old GDM 2.20 branch, the version with gdmsetup
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Everaldo Canuto (ecanuto) Feature #307415, revision 1 Title: Back to the old GDM 2.20 branch, the version with gdmsetup openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Everaldo Canuto (ecanuto) Partner organization: openSUSE.org Description: The new GDM is ugly and miss lots of features available in previous versions, look at web gdm web site (http://live.gnome.org/GDM) we can see that old branch still maintained: "A rewrite of GDM is underway. On 15 October 2007, the new design replaced the existing SVN.w/ gdm-setup) trunk At the moment, this rewrite provides a functional login program, but is missing some features which are in the last stable (2.20) branch. It would be great if more people could get involved to help complete the rewrite. The existing stable branch will continue to be maintained with bug fixes until the rewrite is ready. Apologies for any inconveniences this causes while we are working on this rewrite." So, why we dont get back to old branch and wait until "rewrite" get done. Business case (Partner benefit): openSUSE.org: Because new GDM used in openSUSE 11.1 and openSUSE 11.2 lack lots of features already available in old versions of openSUSE. Also, lots of people what to have gdm-setup back, artists want to make new gdm themes and well, new gdm just sucks and is ugly. -- openSUSE Feature: https://features.opensuse.org/307415

1 6

[openFATE 306992] Zypper dup needs a --lock-vendor <vendor> switch
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Dave Plater (plater) Feature #306992, revision 1 Title: Zypper dup needs a --lock-vendor <vendor> switch openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Dave Plater (plater) Description: When using zypper dup it is very difficult and sometimes impossible to prevent certain packages from changing vendor. I propose a switch which will prevent certain vendors from being changed. Packman for instance has kaffeine and cairo. You have packman kaffeine installed and you wish to stay with the packman version but you wish cairo to stay opensuse. You can either give packman repo a higher priority in which case your cairo will change vendor or you can give opensuse repo a higher priority in which case your kaffeine will change vendor. Performing a "zypper dup --lock-vendor packman" will enable you to have a higher priority opensuse but still keep your packman packages and update with newer packman packages. -- openSUSE Feature: https://features.opensuse.org/306992

1 6

[openFATE 307189] Keyboard variants during setup and Euro sign
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Peter Tselios (tpe) Feature #307189, revision 1 Title: Keyboard variants during setup and Euro sign openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Peter Tselios (tpe) Description: A nice to have feature for future versions of openSuse would be the option to add more than one keyboard layouts during setup. Additionally, it would be nice to automatically (during setup) configure the X and console in order to be ready to use the Euro sign. This could be done either by the language selection (not very safe because some people use English anyways) or (more precise and safe) by the timezone selected by user. I believe that this feature would be helpful for European users. -- openSUSE Feature: https://features.opensuse.org/307189

1 1

[openFATE 306994] Create a strong DE-neutral system/profiles
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: dmitry serpokryl (dmitry_serpokryl) Feature #306994, revision 1 Title: Create a strong DE-neutral system/profiles openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: dmitry serpokryl (dmitry_serpokryl) Description: it's just a response to the (http://lizards.opensuse.org/2009/07/31/openfate-feature-306967-kde-default) yet another proposed feature which i hope never will be accepted as a default. my response is in the 3-rd comment. suppose that the creation of a more flexible and DE-neutral system/settings/presets could benefit to all SLE/SUSE Users. examples: * pure GTK Desktop * pure Qt Desktop (why not?) * no Mono preset (we can easily use Tracker instead of Beagle and at least gNote/others to wipe out the Tomboy+Company) * no Java preset (mostly targeted to the OOo replacement option by Gnumeric+AbiWord) * Wicd instead of NM * more attention to the low-level core components like kernel, drivers, basic libs and so on. -- openSUSE Feature: https://features.opensuse.org/306994

1 2

[openFATE 306373] revival of openCA
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Stephan Kulow (coolo) Feature #306373, revision 1, last change by Title: revival of openCA openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Hans Witvliet (digi_hans) Description: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060425 SUSE/1.5.0.3-7 Firefox/1.5.0.3 Any chance of reviving OpenCA? In the security manuals, chapter x509, it says that the yast-module for maintaing certificates is nice for small set-up's, but not intented for large roll-outs. OpenCA seems to be right for that job, with (poosible) seperate CA, RA, OSCP, support for smartcards and LDAP, mysql. If i'm not mistaken, Adrian maintained some time ago an old version of OpenCA for openSuSE_10.3. Hence my question: is it possible to re-create it for the 1.0.2 (ten-ten) version of openCA, preferably for openSUSE_11.1 and SLES-11 ? It seems that current verion of OpenCA does build on older versions of openSUSE, but fails to compile on 11.1. (not yet tried on sles11, but expect same results) Relations: - revival of openCA (novell/bugzilla/id: 491024) https://bugzilla.novell.com/show_bug.cgi?id=491024 Discussion: #1: Stephan Kulow (coolo) (2009-04-08 09:11:05) if you can't even get it to compile, it doesn't seem to be that well maintained. So I would think it's not good to rely on security of it. #2: Hans Witvliet (digi_hans) (2009-04-08 16:19:04) To put in perspective... I couldn't complete a compile of the latest version on 11.1. openca offers binaries for fedora, centos, ubuntu and open slowaris. I just tried it on 32/64-bit versions of 11.1, I can try it aagain on older versions. Allthough i just upgraded our whole environment, using our install server with xen farm wouldn't take too long. At work i've got a tough job keeping all the noses point to one direction. But it would be hard to defend sticking with open/sles with considerable effort if it compiles flawless (I kow: seeing is believing..) with others. It seems that OpenCA is the only opensource product in this class, comparing with CASA, yaST, tinyCA, pyCA that are only intended for small scale deployment. And for this particular assigment was specifically asked to evaluate OpenCA, regardless of the environment it runs in, though my first choice would be a sles11-cluster and secondly an open-11.1 cluster. #3: Stephan Kulow (coolo) (2009-04-08 23:58:21) you have two options: a) the openSUSE way: you're free to maintain it in openSUSE:Factory:Contrib (see en.opensuse.org/Contrib) b) the SLES way: you convince your presales contact person that there is no way around The "file an enhancement bug against openSUSE to get a SLES feature" does not work. #4: Hans Witvliet (digi_hans) (2009-04-09 15:22:41) Sorry, if i gave you the wrong impression. imho, openca looks great (from the docu and the live-version) It used to be included 10.0 - 10.3 with the distro itself, and later on it became also available on the OBS (Adrian). I presume that if you got someone who has spent some time before on it, it would be the first one to humbly ask to have a look again, instead of re-inventing the wheel. Personnaly, i work on the R&D department, only doing prototypes and prove-of-concepts and i am happy using openSuSE. Our production department however is using the official SLES-9 and now SLES-10 version. a) So if there is a version on the OBS for open_11.1 i would be happy. b) If it could be incorporated in the list of packages for SLE it would make you happy (sales) c) If the OBS could hold versions for 11.1 and SLE, you would be happier, (sales but no additional packages to officially maintain) Final word about the code: Yes, it is _old_ code, but the only thing that comes close with regards with its features, is the code that comes from AOL: http://www.redhat.com/certificate_system/ And i'm neither eager to switch to rh/fc/ct, nor to suggest a re-write of the 10MB from openCA. Hence my req to revive it on the OBS, anyone would benefit. Or do you have plans to "adopt" the above mentioned GPL-ed java code ;=) -- openSUSE Feature: https://features.opensuse.org/306373

1 3

[openFATE 307257] Default kdesu to use sudo and not su
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Bill P (google01103) Feature #307257, revision 1 Title: Default kdesu to use sudo and not su openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Bill P (google01103) Description: as described in the article http://www.benkevan.com/blog/default-kdesu-to-use-sudo-and-not-su/ -- openSUSE Feature: https://features.opensuse.org/307257

1 1

[openFATE 306779] a better support for Wlan driver
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Claus Rebler (Zunami) Feature #306779, revision 1 Title: a better support for Wlan driver openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Claus Rebler (zunami) Description: i have always a problem to install wlan drivers on opensuse i hab 1 acer laptop 1 hp laptop 1 asus latop and always the sam problem. the system have not the divers. i must after the system installation (opensuse 11.1) over again to install the driver. and then i must hope to find my network (next problem). when i install kubuntu i have no this problem. please make a easy or better wlan support. and after the installtion the system must be run -- openSUSE Feature: https://features.opensuse.org/306779

1 2

[openFATE 307171] Use Device Manager instead of the standard Device Notifier
by fate_noreply＠suse.de 15 Nov '10

15 Nov '10

Feature added by: Robert Erne (Jeremay) Feature #307171, revision 1 Title: Use Device Manager instead of the standard Device Notifier openFATE: Unconfirmed Priority Requester: Desirable Requested by: Robert Erne (jeremay) Description: I think Device Manager has a lot of interesting and nice features. It`s rather stable and makes a good impression. -- openSUSE Feature: https://features.opensuse.org/307171

1 3