April 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305474] provide reliable suspend-on-lid-close
by fate_noreply＠suse.de 26 Apr '10

26 Apr '10

Feature changed by: Martin Seidler (pistazienfresser) Feature #305474, revision 10 Title: provide reliable suspend-on-lid-close openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Juergen Weigert (jnweiger) Description: I suggest to have a configuration option cause a suspend on lid-close regardless of other circumstances. Currently * presence of AC-power, * the selected desktop KDE/Gnome/Text, and * presence of docking station all have influence on suspend. The exact logic is apparently changing between beta versions. I'd like to be able to configure a general and unconditional suspend on- lid-close function. Discussion: #1: Axel Braun (docb) (2009-04-27 13:06:57) Good idea! That would allow a laptop to close even if you are on the login-screen. + #2: Martin Seidler (pistazienfresser) (2010-04-26 13:52:45) + Only suspend to RAM (sleep)? Could suspend to disk cause problems + (especially with dual boot systems)? -- openSUSE Feature: https://features.opensuse.org/305474

1 0

[openFATE 303793] Mount /var/run as tmpfs
by fate_noreply＠suse.de 26 Apr '10

26 Apr '10

Feature changed by: Dirk Mueller (dirkmueller) Feature #303793, revision 53 Title: Mount /var/run as tmpfs openSUSE-11.2: Rejected by Matthias Eckermann (mge1512) reject date: 2009-07-16 11:42:53 reject reason: Rejected on request of Engineering. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Kay Sievers (kay_sievers) Developer: (Novell) - Developer: (Novell) Description: /var/run should be mounted as tmpfs. This would avoid the cleaning of stale files or sockets on bootup and avoid atime updates of any mounted filesystems. This is required for eg powermanagement, which currently wakes up the system from any idle states for a socket operation. Services must be modified not to depend on a preexisting content in /var/run upon startup. RPMs must be modified to not place anything there. Discussion: #2: Federico Lucifredi (flucifredi) (2008-07-08 19:30:23) somehow SLES/SLED got out of sync here. Matching. #4: Duncan Mac-Vicar (dmacvicar) (2008-07-14 15:30:03) There are no resources for this feature. Please postpone, (as agreed with MgE) #5: Duncan Mac-Vicar (dmacvicar) (2008-07-14 15:46:55) Just as a side note this feature will require an effort of aprox. 1 week, together with #303810 (they averlap about 95%) #10: Arvin Schnell (aschnell) (2009-02-04 10:50:32) Any requirements on the size for the tmpfs or should the default of tmpfs be used? #11: Arvin Schnell (aschnell) (2009-02-05 19:27:03) (reply to #10) Kay replied by personal mail: Size doesn't matter. /var/lock should also be on tmpfs. #12: Duncan Mac-Vicar (dmacvicar) (2009-06-02 11:22:49) Christoph, please reject with openSUSE 11.2, because disk encryption we can't promise this feature for 11.2. It may get done as bonus if encryption gets done earlier than expected, but we can't commit to it (which is what rejection means, which does not mean we may work on it). It is the next thing we will work on after encryption support. + #32: Dirk Mueller (dirkmueller) (2010-04-26 12:08:04) + rpmlint check implemented (badness 900) -- openSUSE Feature: https://features.opensuse.org/303793

1 0

[openFATE 306476] Install boot entry configurable in kernel git file
by fate_noreply＠suse.de 24 Apr '10

24 Apr '10

Feature changed by: Stefan Dirsch (sndirsch) Feature #306476, revision 21 Title: Install boot entry configurable in kernel git file openSUSE-11.2: Rejected by Stefan Dirsch (sndirsch) reject date: 2010-01-10 10:12:41 reject reason: Obviously this has not been implemented for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Thomas Renninger (trenn) Developer: (Novell) Developer: (Novell) Description: Provide a file in the kernel git which describes an installation boot entry including: - help/description - specific boot parameters - active on which arch The installation image (e.g. DVD) will then provide these specific boot entries to make it easy for: - kernel developers to add critical boot parameters required for specific HW for booting - users by providing a meaningful help at boot loader start up Currently most important settings that are coming to my mind are: - apic=bigsmp (for i386 machines with a lot cores might require that) - disable Kernel Mode Settings -> disable kernel graphics parts which won't work on all HW if set by default soon The idea originally comes from Bernhard Walle. Steffen and myself discussed that already and agreed that it makes sense to do that. On longterm it would be great to get rid of the "Failsafe" Yast boot loader functionality. This would not be necessary anymore then. This currently totally useless and outdated anyway. With the new approach, soon as one successfully booted an entry from the installation image, these boot options will be the default forever (or manually adjusted). Discussion: #1: Stefan Dirsch (sndirsch) (2009-06-22 10:09:05) I think the X' team' would like to get involved here WRT KMS. Also I believe we still want to have a possibility to detect that the user wants to start the Xserver from installation (usually fbdev driver) instead of the apparently broken native X driver. This was boot param 'x11failsafe' in the past. #2: Thomas Renninger (trenn) (2009-06-22 14:27:39) Yeah, in this case we probably need some advise from the X guys which boot params have to be passed, eventually other extra quirks are needed for KMS, no idea. But in general the responsibility and possibilty to generate/modify extra boot entries and with them passing extra kernel boot parameters and a description when to use them should rely in the kernel teams hands and thus the config file should lie in the kernel repo. Coolo, can you set this fate entry a project manager state, so that we can finally work on that at some time, thanks. #3: Stefan Dirsch (sndirsch) (2009-06-22 14:52:39) Probably the modeset option needs to be used for all relevant KMS capable DRM modules, like i915, radeon. Possibily also radeonhd (still to be implemented) and nouveau (in case it's installed, we don't ship it). So something like this: i915.modeset=0, radeon.modeset=0, radeonhd. modeset=0, nouveau.modeset=0. #5: Andreas Jaeger (a_jaeger) (2009-07-10 11:47:39) I'm a bit confused what you want to do here. What advantage will this bring us? #6: Andreas Jaeger (a_jaeger) (2009-07-14 15:13:04) (reply to #5) Just talked with Thomas: The idea is to safe the information about kernel-parameters as part of the kernel package and let the installation get this information from there - instead of hardcoding it in the installation workflow. Also the kernel would provide different options that the developers think make sense. #8: Michal Marek (michal-m) (2009-09-04 13:05:51) Adding such file(s) to git and packaging them in the binary rpms is not a problem, I think this is mainly a feature for installation images build to get the configuration from the kernels and use it when generating the menu. Steffen, what do you think? #9: Thomas Renninger (trenn) (2009-09-04 13:47:04) Yep. Steffen and I already fiddled out a config file format. It's mainly on me to add an example file to our git repo. Steffen then can implement the installation image part. I just did not found the time (and wanted to poke graphics guys about sane KMS kernel boot params to provide which should be most important for 11.2). #10: Stefan Dirsch (sndirsch) (2009-12-12 07:14:04) About KMS integration for openSUSE 11.3 and SLE11-SP1, please see Bug #560438. #11: Stefan Dirsch (sndirsch) (2010-04-03 11:47:31) Not sure if this one is still interesting for X developers. KMS integration is now fully done in SLE11-SP1 and openSUSE 11.3. + #12: Stefan Dirsch (sndirsch) (2010-04-24 16:20:47) (reply to #11) + I believe it isn't. -- openSUSE Feature: https://features.opensuse.org/306476

1 0

[New: openFATE 309014] Move Request
by fate_noreply＠suse.de 23 Apr '10

23 Apr '10

Feature added by: Andreas Jaeger (a_jaeger) Feature #309014, revision 1 Title: Move Request Buildservice: Evaluation Priority Requester: Important Requested by: Andreas Jaeger (a_jaeger) Description: If you want to move a package from one project to another, you need to do a submitrequest and then add again maintainer/bugowner, redirect the location of the devel package and also delete the old package. These are a lot of individual steps and I propose to implement a move request that does these actions as a single step. -- openSUSE Feature: https://features.opensuse.org/309014

1 5

[New: openFATE 309330] Make OBS interconnect non-blocking the scheduler
by fate_noreply＠suse.de 23 Apr '10

23 Apr '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #309330, revision 1 Title: Make OBS interconnect non-blocking the scheduler Buildservice: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Adrian Schröter (adriansuse) Developer: (Novell) Description: Scheduler should just notify rep server to download needed resources from remote instance in the background and not wait for it. -- openSUSE Feature: https://features.opensuse.org/309330

1 1

[New: openFATE 309341] Make new status for "unsigned"
by fate_noreply＠suse.de 23 Apr '10

23 Apr '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #309341, revision 1 Title: Make new status for "unsigned" Buildservice: New Priority Requester: Desirable Requested by: Adrian Schröter (adriansuse) Description: Give status of "unsigned" instead of just "finished" in case scheduler waits for signing. -- openSUSE Feature: https://features.opensuse.org/309341

1 1

[openFATE 306517] Read access control to obs projects
by fate_noreply＠suse.de 21 Apr '10

21 Apr '10

Feature changed by: Adrian Schröter (adrianSuSE) Feature #306517, revision 7 Title: Read access control to obs projects - Buildservice: Evaluation + Buildservice: Candidate Priority Requester: Mandatory - Projectmanager: Desirable + Projectmanager: Mandatory Requested by: Scott Bahling (sbahling) + Developer: (Novell) Partner organization: openSUSE.org Description: A project owner defines which other projects are granted read access to this project. Let's call the projects with read access the 'reader list' of the project. Only other projects on the reader list are allowed to use sources or build results from this project; repositories share the permissions of their respective projects. Individual users act on behalf of projects. Thus they gain read access either by being member of the project or by being mamber of a project on the reader list. This is needed to manually build packages locally. When a project or a user has no read access, the project will not be visible. Any links seem to be broken, pointing to an inexistent object. Any read access control failures must pretend this, because project names already can reveal upcoming product properties. For the same reason, the reader list must only be accessible to project members. If read access is withdrawn from a project, already built results must no longer be accessible to the now unauthorized projects and their members. So semantically, a cached expanded source link or a built binary 'knows' which other projects have been used for its creation; read access is only granted to the intersection of the reader lists of all these projects at the time of the access. Obviously this can be cached, too, until the read access is updated. The read access is discretionary. This means, if a user has gotten hold of a source or a binary while she had access to it, she has the data on her disk and the obs will not provide means to take it back if read access should be withdrawn. For that reason, a 'which users and projects dos this reader list expand to' function must be provided, to make things obvious and to allow for what-if probes before changing the reader list. For reliable testing of build results, it's desirable to have the result of publishing available even for read access restricted projects. This would simplify and harden testing, giving testers a most end user like experience. For the record, it has been discussed to introduce 'real ACLs', allowing to withdraw access from some individuals or projects before granting access to a superset. It also has been proposed to optionally 'include' the acl from another project. And it has been proposed to add user groups in addition to projects. These three proposals at frist glance seem to simplify administration, but they also increase complexity of the read access and make it quickly obscure and non- obvious. This proposal here tries to keep it short and simple. References: http://wiki.opensuse.org/openSUSE:Build_Service_Concept_ACL#Adding_code_for… Business case (Partner benefit): openSUSE.org: Component vendors and system vendors consider it a significant competitive advantage to hide technical details about upcoming products until the product is publicly released. Thus privacy control is crucial for a self serviced operation of a driver build. Discussion: #1: Adrian Schröter (adriansuse) (2010-02-19 10:56:40) Diserable for our 2.0 release. Mandatory for ISV build. #2: Adrian Schröter (adriansuse) (2010-04-19 09:44:40) (reply to #1) k, LF want to do an extra release just for this feature (1.8). This feature is currently implemented by Martin Moring and Jan-Simon Möller from LinuxFoundation. + #3: Adrian Schröter (adriansuse) (2010-04-21 17:22:15) + EngManager and Developer is actual "Martin Mohring", but fate does not + know him. -- openSUSE Feature: https://features.opensuse.org/306517

1 0

[openFATE 306517] Read access control to obs projects
by fate_noreply＠suse.de 21 Apr '10

21 Apr '10

Feature changed by: Adrian Schröter (adrianSuSE) Feature #306517, revision 6 Title: Read access control to obs projects Buildservice: Evaluation Priority Requester: Mandatory Projectmanager: Desirable Requested by: Scott Bahling (sbahling) Partner organization: openSUSE.org Description: A project owner defines which other projects are granted read access to this project. Let's call the projects with read access the 'reader list' of the project. Only other projects on the reader list are allowed to use sources or build results from this project; repositories share the permissions of their respective projects. Individual users act on behalf of projects. Thus they gain read access either by being member of the project or by being mamber of a project on the reader list. This is needed to manually build packages locally. When a project or a user has no read access, the project will not be visible. Any links seem to be broken, pointing to an inexistent object. Any read access control failures must pretend this, because project names already can reveal upcoming product properties. For the same reason, the reader list must only be accessible to project members. If read access is withdrawn from a project, already built results must no longer be accessible to the now unauthorized projects and their members. So semantically, a cached expanded source link or a built binary 'knows' which other projects have been used for its creation; read access is only granted to the intersection of the reader lists of all these projects at the time of the access. Obviously this can be cached, too, until the read access is updated. The read access is discretionary. This means, if a user has gotten hold of a source or a binary while she had access to it, she has the data on her disk and the obs will not provide means to take it back if read access should be withdrawn. For that reason, a 'which users and projects dos this reader list expand to' function must be provided, to make things obvious and to allow for what-if probes before changing the reader list. For reliable testing of build results, it's desirable to have the result of publishing available even for read access restricted projects. This would simplify and harden testing, giving testers a most end user like experience. For the record, it has been discussed to introduce 'real ACLs', allowing to withdraw access from some individuals or projects before granting access to a superset. It also has been proposed to optionally 'include' the acl from another project. And it has been proposed to add user groups in addition to projects. These three proposals at frist glance seem to simplify administration, but they also increase complexity of the read access and make it quickly obscure and non- obvious. This proposal here tries to keep it short and simple. + References: + http://wiki.opensuse.org/openSUSE:Build_Service_Concept_ACL#Adding_code_for… Business case (Partner benefit): openSUSE.org: Component vendors and system vendors consider it a significant competitive advantage to hide technical details about upcoming products until the product is publicly released. Thus privacy control is crucial for a self serviced operation of a driver build. Discussion: #1: Adrian Schröter (adriansuse) (2010-02-19 10:56:40) Diserable for our 2.0 release. Mandatory for ISV build. #2: Adrian Schröter (adriansuse) (2010-04-19 09:44:40) (reply to #1) k, LF want to do an extra release just for this feature (1.8). This feature is currently implemented by Martin Moring and Jan-Simon Möller from LinuxFoundation. -- openSUSE Feature: https://features.opensuse.org/306517

1 0

[New: openFATE 309371] Namespace-like console commands aliases
by fate_noreply＠suse.de 20 Apr '10

20 Apr '10

Feature added by: Yaroslav Kurlaev (Yareg) Feature #309371, revision 1 Title: Namespace-like console commands aliases openSUSE-11.3: Unconfirmed Priority Requester: Neutral Requested by: Yaroslav Kurlaev (yareg) Description: In all Linux systems we have a lot of console commands and it's sometimes not clear for new user which command to use in some case. To simplify all it we can make aliases like namespaces in programming languages. Something similar is already present in MS Powershell. It could be several global namespaces like adm, net, tools, multimedia, games etc. adm can contain users, services etc. tools can contain editor, that can contain vim, emacs, ed, nano etc., browser, that can contains lynx, links etc., and other categories. For example, in this notation useradd will become adm.users.add. Another possibility is to make some default or favorite application. For example, tools.editor can point to your favorite editor. It is similar to /etc/alternatives mechanism. Somebody can say, that it will make commands longer, but Tab-autocompletion can solve this problem. Another possible problem is mixing of standard commands and new namespaces, but it can be solved by adding some one-symbol prefix. Also, we can add gdb-like help. This idea was originally posted by user ls-h on linux.org.ru forum. It also have been posted in Fedora developer maillist ( http://lists.fedoraproject.org/pipermail/devel/2010-April/134922.html (http://lists.fedoraproject.org/pipermail/devel/2010-April/134922.html) ). -- openSUSE Feature: https://features.opensuse.org/309371

1 0

[New: openFATE 309364] automatic setup of necessary files when running a VM build (kvm or xen)
by fate_noreply＠suse.de 19 Apr '10

19 Apr '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #309364, revision 1 Title: automatic setup of necessary files when running a VM build (kvm or xen) Buildservice: Done Priority Requester: Important Requested by: Adrian Schröter (adriansuse) Description: build script creates automatically needed files on running a VM build the first time. -- openSUSE Feature: https://features.opensuse.org/309364

1 0