March 2011 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308472] switch from XDM to LXDM for XFCE and "X minimal installation"
by fate_noreply＠suse.de 10 Jul '11

10 Jul '11

Feature added by: andrea florio (anubisg1) Feature #308472, revision 1 Title: switch from XDM to LXDM for XFCE and "X minimal installation" openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: andrea florio (anubisg1) Description: xdm is a very lightweight login manager, but it's actually really ugly and not easy to use. i suggest to switch to LXDM as default login manager. it's lightweight (LXDE default one) and depends only on gtk pam and ConsoleKit. lxdm also allow to create a branding package to customize the apperence -- openSUSE Feature: https://features.opensuse.org/308472

1 7

[New: openFATE 308693] support keyboard layout switching in initrd
by fate_noreply＠suse.de 04 Jul '11

04 Jul '11

Feature added by: Ludwig Nussel (lnussel) Feature #308693, revision 1 Title: support keyboard layout switching in initrd openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Ludwig Nussel (lnussel) Description: When using an encrypted root partition only plain ASCII characters are possible as passphrase. International users may want to also use special characters though. https://bugzilla.novell.com/show_bug.cgi?id=547923 -- openSUSE Feature: https://features.opensuse.org/308693

1 3

[openFATE 306410] Guest session
by fate_noreply＠lists4.suse.com 29 Jun '11

29 Jun '11

Feature added by: Vincent Untz (vuntz) Feature #306410, revision 1, last change by Title: Guest session openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Vincent Untz (vuntz) Description: It'd be nice to provide a guest session, for people using a computer that is not their computer. This guest session would: * require no password * would cleanup itself on logout/login * be easily accessible from the login manager It should of course be easy to disable it, for people who don't want this. -- openSUSE Feature: https://features.opensuse.org/306410

2 1

[New: openFATE 309326] Make Attributes storable on more items
by fate_noreply＠suse.de 24 Jun '11

24 Jun '11

Feature added by: Adrian Schröter (adrianSuSE) Feature #309326, revision 1 Title: Make Attributes storable on more items Buildservice: New Priority Requester: Desirable Requested by: Adrian Schröter (adriansuse) Description: Attributes should be stored on * Repositories * binary packages (md5sum ?) -- openSUSE Feature: https://features.opensuse.org/309326

1 1

[New: openFATE 309308] spectool in buildservice?
by fate_noreply＠suse.de 24 Jun '11

24 Jun '11

Feature added by: Robert Xu (bravoall1552) Feature #309308, revision 1 Title: spectool in buildservice? Buildservice: Unconfirmed Priority Requester: Important Requested by: Robert Xu (bravoall1552) Description: I'm marking this as important because it really is. As you know, we can put URLs in spec files. The tool spectool can parse spec files and automatically download the Sources and Patches into the desired directories. So why don't we just integrate this into OBS? it's easier than just uploading one by one or using osc. Not only that, everytime the spec file is changes, any sources that have been deleted can be deleted by obs after a period (probably 3 days) and any new sources can be retrieved immediately! -- openSUSE Feature: https://features.opensuse.org/309308

1 2

[New: openFATE 310925] Increase of the appliance's hard drive size
by fate_noreply＠suse.de 24 Jun '11

24 Jun '11

Feature added by: Gregor Dschung (chkpnt) Feature #310925, revision 1 Title: Increase of the appliance's hard drive size Buildservice: Unconfirmed Priority Requester: Important Requested by: Gregor Dschung (chkpnt) Partner organization: openSUSE.org Description: The appliance's hard drive is too small. There is only less than 200MB free space left. Business case (Partner benefit): openSUSE.org: I wanted update my appliance with "zypper patch", because "zypper lp" listed several security related patches. But the command wasn't successfull, because the root partition went out of space. I wasn't able to resize the partition with VMware vSphare, so I had to exchange the appliance's vmdk-Image. This means, every configuration done in /srv/www/obs is lost and needs to be reconfigured (like LDAP settings, etc.). -- openSUSE Feature: https://features.opensuse.org/310925

1 2

[New: openFATE 311355] add LDFLAGS=-fuse-linker-plugin to %configure
by fate_noreply＠suse.de 24 Jun '11

24 Jun '11

Feature added by: Christopher Yeleighton (yecril71pl) Feature #311355, revision 1 Title: add LDFLAGS=-fuse-linker-plugin to %configure Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Christopher Yeleighton (yecril71pl) Partner organization: openSUSE.org Description: openSuSE uses GCC as the compiler of choice. The compiler uses a link editor to build executable objects; the default link editor is called collect2 and collect2 uses ld to perform the final link. However, the GCC suite distributes another linker called gold. Gold replaces collect2. It is enabled by telling gcc to -fuse-linker-plugin; this is not the default. The default settings for the GNU build system on openSuSE are provided in an RPM macro called %configure. My suggestion is to add LDFLAGS=-fuse-linker-plugin to this macro. Test Case: == ImageMagick == Try to build ImageMagick using the specification file from the upstream tarball (version 6.6.7-7). The packager fails because the PERL extension Magick.so contains an RPATH declaration. == Qt == Try to build Qt from source in a KDE session with 1 GB physical RAM. The traditional link editor never halts because it does not have enough RAM. Business case (Partner benefit): openSUSE.org: === RPATH === The traditional link editor ld adds an RPATH header in ELF executeable objects. Such objects are considered a security threat by the tool brp-rpath and binary packages containing them fail to build. The header is injected when the object is linked against a shared library that is not placed in a standard operating system directory; this may happen during a package build when a library and a dependent executable are built together and a library is located by means of the environment variable $LD_RUN_PATH. The gold link editor does not have this problem because it is unaffected by the value of $LD_RUN_PATH. == EFFICIENCY == The gold link editor performs better and requires less system resources than the traditional link editor ld. -- openSUSE Feature: https://features.opensuse.org/311355

1 2

[New: openFATE 310292] TOMOYO YaST Integration
by fate_noreply＠suse.de 23 Jun '11

23 Jun '11

Feature added by: Martyn Hare (NthDeGeek) Feature #310292, revision 1 Title: TOMOYO YaST Integration openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Martyn Hare (nthdegeek) Partner organization: openSUSE.org Description: Add TOMOYO as an option for security on OpenSuSE's YaST. It offers more features than AppArmor and with the correct YaST integration it can be made to work in the same "targeted" way as AppArmor does by default, offering powerful features to less experienced users without causing system-wide changes. It is pathname based just like AppArmor but also provides domain separation based upon execution history. Just like AA it offers an extensive learning mode which is simple to use and policies are human readable. Use Case: Derek wants a system where only applications with a created policy may execute according to principle of least authority. With AppArmor he can only lock down specific applications, and SELinux uses a complex labelling system (and doesn't offer POLA). With TOMOYO he can apply learning mode to analyse normal behaviour system-wide, then tweak human-readable policy to run as enforced. Suzie runs a server where remote access is limited but local access is intended to be unimpeded. TOMOYO would differentiate between a local login shell and remote login shell by the execution history, resulting in a restricted shell remotely but not locally without the need to create hard links or use alternative user accounts. John wants to limit who can directly connect to his P2P client, but needs to keep the port randomised to avoid conflicts with others on his residential network, but has other applications listening on ports too - TOMOYO allows him to restrict what direct inbound connections are accepted by the P2P application. Business case (Partner benefit): openSUSE.org: Benefits to OpenSuSE: * The ability for an end-user to lock down the whole system if he/she chooses in addition to the ability to lock down individual applications * Conditional checking of permissions based on whether file is owned and/or what user is accessing files * Control over listening, sending and receiving over the network per-process on a per-port and/or per-IP basis * Enhanced control over the use of capabilities on a global and/or per-app basis * Security which can be LSM or non-LSM (1.x has out-of-tree patches, 2.x which is in-tree uses LSM) * If using 1.x the end-user may run TOMOYO in parallel with either AppArmor or SELinux (this may allow SELinux policies to get additional testing!) * Hard link security bypassing resolved through control over the ability to create and/or use hard links -- openSUSE Feature: https://features.opensuse.org/310292

1 15

[New: openFATE 310665] Keep the current kernel when doing a kernel update through yast
by fate_noreply＠suse.de 21 Jun '11

21 Jun '11

Feature added by: Wilfred van Velzen (wvv) Feature #310665, revision 1 Title: Keep the current kernel when doing a kernel update through yast openSUSE-11.4: Unconfirmed Priority Requester: Desirable Requested by: Wilfred van Velzen (wvv) Partner organization: openSUSE.org Description: See this discussion on the forum: http://forums.opensuse.org/english/get-help-here/install-boot-login/447030-… Summary: Keeping the current kernel installed should be the default and automatic behaviour for a kernel update through Yast! (Provided there is enough space on the partition that holds /boot). Or it could be a setting somewhere to keep the last X number of previous installed kernels (where X should default to 1). Business case (Partner benefit): openSUSE.org: When the newly installed kernel doesn't work or has some issues. The user has an easy way to boot into a previous kernel, so he still has a working system. -- openSUSE Feature: https://features.opensuse.org/310665

1 11

[New: openFATE 310232] kde addressbook integration in openoffice
by fate_noreply＠suse.de 19 Jun '11

19 Jun '11

Feature added by: Denny Beyer (lumnis) Feature #310232, revision 1 Title: kde addressbook integration in openoffice openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Denny Beyer (lumnis) Partner organization: openSUSE.org Description: It would be desireable to have a working addressbook connection/access between openoffice and kde addressbooks out of the box. Business case (Partner benefit): openSUSE.org: As openoffice is the choice for most users and the only option with regards to more advanced features, core functionality needed in an office environment is still missing. Like addressbooks being available across applications to be used in e.g. mail merge. -- openSUSE Feature: https://features.opensuse.org/310232

1 10