August 2011 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 310365] Light CD for older computers
by fate_noreply＠suse.de 30 Aug '11

30 Aug '11

Feature added by: Anomyous Anomyous (jcat123) Feature #310365, revision 1 Title: Light CD for older computers openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Anomyous Anomyous (jcat123) Description: A "Light CD" of openSUSE would be excellent for older computers. It would be a CD with LXDE, OpenOffice, the SUSE Base system, Test-Install YaST, and some basic tools. With this CD, older computers would be able to run openSUSE at a reasonable speed, have YaST and openSUSE community support\updates, legacy drivers, and some basic tools. With this CD edition avalible for download, you could have openSUSE on every old computer. -- openSUSE Feature: https://features.opensuse.org/310365

1 8

[New: openFATE 312715] openSUSE Linux 12.1: Create a new YaST.
by fate_noreply＠suse.de 30 Aug '11

30 Aug '11

1 7

[New: openFATE 312765] Blacklist the pcspkr module by default
by fate_noreply＠suse.de 30 Aug '11

30 Aug '11

Feature added by: Damien Radtke (kog13) Feature #312765, revision 1 Title: Blacklist the pcspkr module by default openSUSE.org: Unconfirmed Priority Requester: Important Requested by: Damien Radtke (kog13) Partner organization: openSUSE.org Description: The pcspkr module is used to control the computer's internal speaker, which is very rarely used on the desktop. It isn't strong enough to serve as a passable replacement for real sound devices, and it hurts the user experience more than it helps. I have openSUSE installed on two computers, my laptop and desktop (11.3 on the laptop, 11.4/Tumbleweed on the desktop), and on both computers I've had to disable the PC speaker because otherwise it would beep very loudly every time I would shut down or restart. It seems to me that this behavior was intended more for server than desktop use. Having to spend the time to learn what the speaker is, what drives it, and how to disable it is obviously not a great experience. I think it would be better for end users to have this module disabled by default, and if any seasoned admins really want it back, they know how to re-enable it. -- openSUSE Feature: https://features.opensuse.org/312765

1 9

[New: openFATE 312722] Provide i386 version of valgrind on amd64 hosts
by fate_noreply＠suse.de 28 Aug '11

28 Aug '11

Feature added by: Dino E (D_E) Feature #312722, revision 1 Title: Provide i386 version of valgrind on amd64 hosts openSUSE Distribution: Unconfirmed Priority Requester: Desirable Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Dino E (d_e) Partner organization: openSUSE.org Description: Current status: $ uname -m x86_64 $ valgrind ./a.out valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory -- openSUSE Feature: https://features.opensuse.org/312722

1 3

[New: openFATE 312757] please add elgg language packs to connect
by fate_noreply＠suse.de 28 Aug '11

28 Aug '11

Feature added by: Jos Poortvliet (jospoortvliet) Feature #312757, revision 1 Title: please add elgg language packs to connect openSUSE Infrastructure: Unconfirmed Priority Requester: Desirable Requested by: Jos Poortvliet (jospoortvliet) Partner organization: openSUSE.org Description: Talking to the openSUSE team in Taiwan, I learned that for quite a few of the local team members, language is a really strong barrier. I know this to be true for the people in Brazil as well and probably in other countries. To make connect more usable for local teams to organize things, we should make it possible for them to use it in their own language. The elgg website has many language packs so it shouldn't be too hard (I hope) to have connect translated... Use Case: For the local ambassador teams to organize themselves Connect can be really useful. It has calendar and discussion posibilities and shows the other communication channels. But language can be a barrier... Business case (Partner benefit): openSUSE.org: We want as many openSUSE ambassadors use Connect for local organizing as possible because they are the people who get the word out for us and if they use connect they not only can do a better job working together but we also have a way to communicate and interact with them. -- openSUSE Feature: https://features.opensuse.org/312757

1 3

[New: openFATE 311139] Merge YaST and Control Center
by fate_noreply＠suse.de 24 Aug '11

24 Aug '11

Feature added by: Enea George (premamotion) Feature #311139, revision 1 Title: Merge YaST and Control Center openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Enea George (premamotion) Partner organization: openSUSE.org Description: Merge YaST and Control Center together, and make this more structurate.. many similar settings are present here and there... Business case (Partner benefit): openSUSE.org: For a new openSUSE user, settings can be confusing... -- openSUSE Feature: https://features.opensuse.org/311139

1 1

[New: openFATE 312760] osc: Decouple chroot creation with package building
by fate_noreply＠suse.de 24 Aug '11

24 Aug '11

Feature added by: Duncan Mac-Vicar (dmacvicar) Feature #312760, revision 1 Title: osc: Decouple chroot creation with package building Buildservice: New Priority Requester: Desirable Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: I normally need for development to build a package from source code (not using spec files). To do ths on older distros I need to create a chroot which I do now having tons of scripts which contain duplicated information that I have to maintain. Example: create-chroot-zypp-sle-10-sp4.sh Calls zypper addrepo with SDK, SP4, and then install the libzypp buildrequires, which are copy pasted from the spec file. The build service already knows what it needs to build the environment for libzypp on SP4 if knowing the base project and the package name, however this is used on build, and there is no way to tell him: build the chroot and stop. If I could say osc buildchroot SUSE:SLE-11-SP1 libzypp $targetdir I could use osc in conjuntion with schroot to quickly create the build environment without needing to maintain fake spec files or create zypper scripts. Use Case: John Doe needs to fix a bug in zypper for Factory. He is not running Factory. He does osc buildchroot openSUSE:Factory zypper /tmp/chroot He checkouts the code into /tmp/chroot and then chroot inside and builds from source. He fixes the bug using his favorite editor from outside the chroot. He did not need to create fake-spec files or create scripts with hardcoded build-requires and repositories to achieve this. Business case (Partner benefit): openSUSE.org: As a developer, it would improve my productivity when backporting or fixing old products/Factory bugs by 42%. -- openSUSE Feature: https://features.opensuse.org/312760

1 0

[New: openFATE 312723] Provide i386 version of valgrind on amd64 hosts.
by fate_noreply＠suse.de 20 Aug '11

20 Aug '11

Feature added by: An Na (elrprt) Feature #312723, revision 1 Title: Provide i386 version of valgrind on amd64 hosts. openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: An Na (elrprt) Partner organization: openSUSE.org Description: Current status: $ uname -m x86_64 $ valgrind ./a.out valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such file or directory -- openSUSE Feature: https://features.opensuse.org/312723

1 3

[New: openFATE 312322] cups-pdf Drucker wieder per default installieren
by fate_noreply＠suse.de 20 Aug '11

20 Aug '11

Feature added by: Karl Sinn (karlsinn) Feature #312322, revision 1 Title: cups-pdf Drucker wieder per default installieren openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Karl Sinn (karlsinn) Partner organization: openSUSE.org Description: Hi, I think that openSUSE should install a pdf-printer as default again. All the best Karl -- openSUSE Feature: https://features.opensuse.org/312322

1 7

[New: openFATE 312731] Change the name and brand of SuSE Linux to SUSE Linux.
by fate_noreply＠suse.de 19 Aug '11

19 Aug '11

Feature added by: Genix Info (genixinfo) Feature #312731, revision 1 Title: Change the name and brand of SuSE Linux to SUSE Linux. openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Genix Info (genixinfo) Partner organization: openSUSE.org Description: I understand what he said Andreas Jaeger: SuSE itself should indeed not be used but let's not change everything for the sake of it. Here: https://features.opensuse.org/310156 (../310156) The migration of brand name and of SuSE Linux to openSUSE Linux around the world, would have a strong impact on SUSE Linux Enterprise, openSUSE Linux while, this impact will not be felt. Thinking in Linux and openSUSE and SUSE Linux Enterprise and was based on feature 312629 (../312629) , I suggest, a migration of name and brand of SuSE Linux to SUSE Linux, here: http://www.novell.com/ (http://www.novell.com/) here: http://en.opensuse.org/ (http://en.opensuse.org/) and here: http://www.suse.com/ (http://www.suse.com/) . -- openSUSE Feature: https://features.opensuse.org/312731

1 5