January 2009 - openSUSE Features - openSUSE Mailing Lists

[openFate 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305503, revision 9 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Duncan Mac-Vicar (dmacvicar) + Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): - Sysadmins do not update ther systems without a strict process and - maximum care. Therefore it is very important to allow them to update - the system to fix a single issue. It would save them the time to look - that themselves package per package. + openSUSE.org: Sysadmins do not update ther systems without a strict + process and maximum care. Therefore it is very important to allow them + to update the system to fix a single issue. It would save them the time + to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305503

1 0

[openFate 305551] Document YaST RELAX NG Schema
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305551, revision 4 Title: Document YaST RELAX NG Schema - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Thomas Schraitle (thomas-schraitle) + Partner organization: openSUSE.org Description: According to bnc#455994 (comment #17) Lukas Ocilka suggested to create a FATE entry for this purpose. Background: The YaST DTD for /etc/YaST2/firstboot.xml and the like is outdated and lead to invalid XML files. The DTD is/was rewritten as a RELAX NG Schema but elements, attributes, and attribute values are not documented yet. Business case (Partner benefit): + openSUSE.org: * Documented RNG schema supports XML editors in showing tool tips during the writing of a XML file. * WIth the help of XSLT a summary can be created automatically. > reduces costs Discussion: #1: Lukas Ocilka (locilka) (2009-01-16 16:32:28) The XML format of a control file is currently documented at http://forgeftp.novell.com/yast/doc/SL11.1/tdg/inst_in_general_chap.html (generated from manually written docbook file) nevertheless this means that it has to be done at two places at once: the RELAX NG schema and its documentation itself. Having the documentation source insite the RELAX NG schema would halp to keep the documentation in sync. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305551

1 0

[openFate 305552] Support in YaST for public directories in encrypted home directories
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305552, revision 5 Title: Support in YaST for public directories in encrypted home directories - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Tim Lee (timl33) Partner organization: openSUSE.org Description: A follow on feature to #301923. There should be a way in the YaST users module to specify directories to make accessable in an encrypted home directory when the user is not logged in. See bug #446317. I would suggest an editable list of directories to exclude from the encrypted image, with a reasonable set of defaults. Examples of directories to exclude ~/.vacation, ~/.procmail, ~/.forward, ~/public_html and ~/.ssh References: https://bugzilla.novell.com/show_bug.cgi?id=446317 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305552

1 0

[openFate 305552] Support in YaST for public directories in encrypted home directories
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305552, revision 4 Title: Support in YaST for public directories in encrypted home directories openSUSE-11.2: New Priority Requester: Important Requested by: Tim Lee (timl33) + Partner organization: openSUSE.org Description: A follow on feature to #301923. There should be a way in the YaST users module to specify directories to make accessable in an encrypted home directory when the user is not logged in. See bug #446317. I would suggest an editable list of directories to exclude from the encrypted image, with a reasonable set of defaults. Examples of directories to exclude ~/.vacation, ~/.procmail, ~/.forward, ~/public_html and ~/.ssh References: https://bugzilla.novell.com/show_bug.cgi?id=446317 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305552

1 0

[openFate 305584] Do not assume fixed and contiguous device numbers in installation and management tools for storage
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305584, revision 8 Title: Do not assume fixed and contiguous device numbers in installation and management tools for storage openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Requested by: Tejun Heo (teheo) + Partner organization: openSUSE.org Description: Subject: [Research] head up on upcoming extended block devt change - To: research(a)suse.de From: Tejun Heo <tj(a)kernel.org> Date: Thu, 18 Dec 2008 12:59:21 +0900 Reply-To: research(a)suse.de Hello, all. From soon to be released 2.6.28, the kernel contains extended block devt support, which basically allocates block device numbers dynamically from major number 259 (might expand to other major numbers if ever necessary). This means that device numbers belonging to the same device become non-contiguous and can be on different major numbers. This will remove the 15 partition limit on /dev/sdX's and increase the total number of supported SCSI disks considerably. Also, it's used by md to allow partitioning of /dev/mdX's thus removing the distinction of partitionable and non-partitionable md devices. For example, /dev/sda with 60 partitions can look like as follows. # cat /proc/partitions major minor #blocks name 8 0 156290904 sda 8 1 8001 sda1 8 2 8032 sda2 8 3 8032 sda3 8 4 1 sda4 ... 8 15 8001 sda15 259 0 8001 sda16 259 1 8001 sda17 259 2 8001 sda18 ... 259 43 8001 sda59 259 44 8001 sda60 For detailed overview, please take a look at the following message. http://article.gmane.org/gmane.linux.kernel/701825 As device node creation is completely dynamic these days, installed systems usually can cope fine with this change; however, in installation and management tools, there seem to be many places which assume fixed and contiguous device numbers. To ease hunting down those areas, a debug option is available which forces every block device to be allocated on the dynamic major non-consecutively. With the debug option turned on, the above disk will look like the following. # cat /proc/partitions major minor #blocks name 8 0 156290904 sda 259 262144 8001 sda1 259 786432 8032 sda2 259 131072 8032 sda3 259 655360 1 sda4 259 393216 8001 sda5 259 917504 8001 sda6 259 65536 8001 sda7 ... 259 114688 8001 sda55 259 638976 8001 sda56 259 376832 8001 sda57 259 901120 8001 sda58 259 245760 8001 sda59 259 770048 8001 sda60 So, the installation / management tools need to follow /sys/block/*/device/driver to determine which type of device it is and use /sys/block/*/dev to determine its device number. I'll add a kernel parameter (say, block.force_ext_devt) so that this debug option can be turned on and off during boot so that people who don't work on related subsystems don't have to suffer. I'm not sure how and when to proceed with this yet but I definitely think we'll need plenty of time to sort this out completely. Any ideas on how to proceed on this? Thanks. -- tejun Discussion: #1: Tejun Heo (teheo) (2008-12-22 13:31:11) So... when and how do we proceed with things like this? I wanna enable it in HEAD but SLES11 hasn't branched out from HEAD yet but I don't think we should wait till SLES11 is released. #2: Matthias Eckermann (mge1512) (2008-12-22 10:24:58) (reply to #1) SLE 11 has precedence over anything else we currently do - with respect to focus and time spent on it. Thus we should concentrate on SLE 11 and wait with those changes after release of SLE 11. There are more than enough P1 and P2 issues with the SLE 11 kernel to work on, ... Vojtech? #3: Vojtech Pavlik (vojtech_pavlik) (2008-12-22 12:14:19) I agree, Matthias, and I see no reason why this couldn't wait until SLES11 branches out of HEAD. #4: Tejun Heo (teheo) (2008-12-23 11:52:19) Alright, then. I'll enable it when SLES11 branches out. Thanks. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305584

1 0

[openFate 305641] Bring Puppet to fully supportable status
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305641, revision 5 Title: Bring Puppet to fully supportable status openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Federico Lucifredi (flucifredi) + Partner organization: openSUSE.org Description: Dedicate a developer for the duration of the 11.2 cycle to shaking out Puppet on openSUSE, contribute patches upstream correcting integration with our base system, and analyzing what future integration areas (particularly with YaST, but not limited) appear promising. The objective is to walk through the Puppet documentation (http://reductivelabs.com/trac/puppet/wiki/DocumentationStart), Turnbull's book (ISBN 159059978), and test out that things work as they should, patching and sending upstream when they do not. Finally, contribute a small "Puppet on SUSE" document to the community detailing any platform- specific factors (you will see there are a number for other distors already). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-08 16:25:48) . -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305641

1 0

[openFate 305660] more options for LDAP browser
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305660, revision 2 Title: more options for LDAP browser - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Jiří Suchomel (jsuchome) + Partner organization: openSUSE.org Description: In YaST LDAP browser, allow: * deleting objects * renaming objects * editing opbejcClass attribute * creating new objects References: https://bugzilla.novell.com/show_bug.cgi?id=443715 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305660

1 0

[openFate 305682] Implement the possibility to allow Add-on source from remote "Plain RPM directory"
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305682, revision 2 Title: Implement the possibility to allow Add-on source from remote "Plain RPM directory" - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stefan Assmann (assmannst) + Partner organization: openSUSE.org Description: During installation when configuring an add-on product there is an option called "Local Directory". If you choose that the next window will have a checkbox "Plain RPM Directory" which allows to add a directory that only contains RPMs as an add-on source. Unfortunately this seems not to be available if you try to configure an add-on product that is not stored locally. Neither FTP, HTTP, SMB, NFS etc... have an option to add a "Plain RPM Directory". This is really useful for exchanging single or multiple RPMs during development without the need to wait for the next development snapshot to verify changes made to the RPMs install fine. Support for this should be implemented into autoyast as well. Gives the opportunity to automatically configure a plain rpm update add-on source for easy exchange of RPMs. Business case (Partner benefit): - Improves development process because developers can test the influence - of their changes to RPMs during installation without having to wait for - the next development snapshot. + openSUSE.org: Improves development process because developers can test + the influence of their changes to RPMs during installation without + having to wait for the next development snapshot. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305682

1 0

[openFate 305686] gnome-screensaver does not respond to an expired password
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305686, revision 2 Title: gnome-screensaver does not respond to an expired password - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Guy Lunardi (glunardi) + Partner organization: openSUSE.org Description: Using novell-lum-2.2.0.11-0.1 1. Authenticate to eDir, 2. Wait until the desktop is locked with screensaver enabled 3. Expire the user's password 4. Attempt to enter user password to unlock the destkop 5. The screensaver just goes into thinking mode for about 30 seconds then re-prompts the user for the password. If I disable password expire then I am able to unlock the desktop. Am attaching the gnome-screensaver file from /etc/pam.d. Relations: - gnome-screensaver does not respond to an expired password (novell/bugzilla/id: 224690) https://bugzilla.novell.com/show_bug.cgi?id=224690 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305686

1 0

[openFate 305701] allow more customization in "Automatic Configuration" installation mode
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305701, revision 2 Title: allow more customization in "Automatic Configuration" installation mode - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Stefan Assmann (assmannst) + Partner organization: openSUSE.org Description: In openSUSE 11.1 there's this feature called "Use Automatic Configuration" which saves you a lot of time during second stage of the installation. However it makes some decisions which you might want to make yourself. This could be further improved, explanation following. In the first stage we have the global overview called "Installation Settings" where you can ultimately revise your settings. In case of an "automatic configuration" this panel should also allow to customize: * basic network settings * firewall At the moment the behavior is that network will be configured somehow YaST thinks it should be right in the second stage and the firewall will always be turned on, allowing no ssh login after installation. That gives the good idea of "Automatic Configuration" a bad after- taste. Having this customizable during first stage is a good step further down the road of an easy, well integrated installation process -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305701

1 0

[openFate 301038] Improved performance in main menu, app browser and control center
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #301038, revision 38 Title: Improved performance in main menu, app browser and control center openSUSE-10.2: Rejected by JP Rosevear <jpr(a)novell.com> reject date: 2006-10-17 08:30:51 reject reason: Performance bottlenecks are mostly remaining in some lower level libraries that need review. Priority Requester: Desirable Projectmanager: Important openSUSE-10.3: Rejected by Gary Ekker <gekker(a)novell.com> reject date: 2007-09-12 11:10:12 reject reason: Nothing done for 10.3. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Done Priority Requester: Important Projectmanager: Important openSUSE-11.1: Done Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Nat Friedman (natfriedman) + Partner organization: openSUSE.org Description: Improved performance in main menu, app browser and control center Discussion: #1: Gary Ekker (gekker) (2006-08-17 09:56:56) Anna, can we get more info on this? #2: Anna Dirks (annadirks) (2006-09-21 16:49:05) (reply to #1) Improved performace sounds to me like it means more quick and responsive. This would be an issue for Jim Krehl to manager I believe; the feedback which I have received regarding Main Menu/AB/CC performance centers around the menu taking a while to appear, and the AB/CC not necessarily defaulting to the best behavior when one searches for an launches an item. #3: JP Rosevear (jproseve) (2007-01-10 21:40:13) We didn't do anything major here for SP1, and with no PM priority I think its safe to reject. #4: Jared Allen (jpallen) (2007-09-12 11:59:45) Actually, Jimmy developed a muti-threaded model and re-worked the tiles for both the app browser and the main menu. This should improve performance. He did no do anything for the control center. #5: JP Rosevear (jproseve) (2008-04-08 16:04:35) Federico did a good amount of performance improvements in the main-menu for 11.0. #6: Guy Lunardi (glunardi) (2008-06-23 13:53:50) (reply to #5) Great to hear, this remains a big issue for our preloads, especially on slower systems like thin clients and low-cost PC. #7: JP Rosevear (jproseve) (2008-09-11 17:05:34) Thumbnailing was removed, but beyond that nothing more happened. Hard to say when this is done exactly. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=301038

1 0

[openFate 300763] Warn about services using old libraries
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #300763, revision 44 Title: Warn about services using old libraries openSUSE-10.2: Rejected by Edith Parzefall <emapedl@please-enter-an-email-address> reject date: 2006-10-02 16:05:01 reject reason: Not enough time for 10.2, rejecting with TPM approval. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-07-31 12:35:05 reject reason: Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-11-21 12:16:55 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Federico Lucifredi <flucifredi(a)novell.com> reject date: 2008-08-01 18:25:29 reject reason: Cutting scope to match project schedule. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Martin Vidner (mvidner) + Partner organization: openSUSE.org Description: Fou4s has a useful feature: after installing updates, it runs "lsof | grep RPMDELETE" to see processes that are accessing the old libraries and recommends to restart them. Our update stack should do this as well, and notify users of processes that need to be restarted. I see this as both a zypper feature and a PK-UI pop-up. Documentation Impact: Software management documentaiton needs to be updated. Discussion: #5: Stanislav Visnovsky (visnov) (2006-09-06 10:57:53) Edith, Jiri, feel free to postpone this for 10.3 if out of resources. #6: Edith Parzefall (emapedl) (2007-07-31 11:49:06) Sorry, we had no time to look into this. Please reject for 10.3. #8: Federico Lucifredi (flucifredi) (2008-06-12 20:52:41) I like this. Stano, Klaus, please sanity-check. #9: Jiri Srain (jsrain) (2008-07-07 09:03:59) Jiri, please, add the check into YaST online update (I must admit that the suggested command didn't work for me, thus some investigation may be needed). Duncan, please, assign the applets. #10: Jiří Suchomel (jsuchome) (2008-07-14 15:55:27) Uhm, what should be the output of "lsof | grep RPMDELETE" and what should actually YaST do with the result? Or, if we use the command from comment 4: what should YaST do with these results? #11: Martin Vidner (mvidner) (2008-07-16 09:52:28) When packages are updated, the effect of the update may not be yet realized because the system is still using the old files (they are unlinked but still in use). A well known case is the kernel which needs a reboot (or kexec or ksplice...). For the apps, we can ask (in zypp app layer?) about all open files which are already unlinked. Then we can say "Updates will not take effect until these processes are restarted: sshd (pid 42), apache2 (pid 31337). If you are unsure, rebooting will do the job.". There can be a Details button or a reference to "zypper checkdeleted" (TODO) to show the gory details. It seems that RPMDELETE no longer works, but there is a simple fix (http://archives.neohapsis.com/archives/linux/suse/2006-q1/0034.html) for that. This thread (http://lists.opensuse.org/opensuse/2002-09/msg00532.html) shows how fou4s presents the info. Marcus has good points in comment 4 but we can address them when we have a prototype working. #12: Jiří Suchomel (jsuchome) (2008-07-16 10:04:16) (reply to #11) IMHO such check belongs to zypp, YaST/zypper/applets should show the results. Duncan, is it possible to assign this to someone from the zypp team? #13: Duncan Mac-Vicar (dmacvicar) (2008-07-30 17:09:22) (reply to #12) yes, will be done as part of the commit refactoring. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=300763

1 0

[openFate 305591] Define purpose for each project
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Martin Vidner (mvidner) Feature #305591, revision 5 Title: Define purpose for each project Buildservice: New Priority Requester: Important Requested by: Pavol Rusnak (prusnak) Partner organization: openSUSE.org Description: + define purpose for each project, like: + * add-on package + * fresh packages + libraries (eg. games) + * bleeding edge packages (eg. zypp:svn) + * backports for older distributions (eg. zypp:Backport) + * playground (eg. all home projects) + So, + * this sets users expectations + * purpose could be indicated by naming conventions, or even better by + project flags + * purpose must be shown in the search result for this method to work + References: http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00056.html - * define purpose for each project, like: - * add-on package * fresh packages + libraries (eg. games) * bleeding - edge packages (eg. zypp:svn) * backports for older distributions (eg. - zypp:Backport) * playground (eg. all home projects) - this sets users - expectations - purpose could be indicated by naming conventions, or - even better by project flags - purpose must be shown in the search - result for this method to work -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305591

1 0

[openFate 305500] User has no way to switch compiz on / off
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305500, revision 6 Title: User has no way to switch compiz on / off openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Juergen Weigert (jnweiger) + Partner organization: openSUSE.org Description: I searched Yast, SAX, gnome-display-properties, and did a desktop search for 'compiz'. The switch is not well advertised, it is here: computer -> System: control-Center -> Look and Feel: Desktop Effects -> [ ] enable desktop effects. -> Close Command line: simple-ccsm, but not ccsm. I suggest to enhance yast to allow compiz switching, using the above information. And/or include package fusion-icon. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305500

1 0

[openFate 302311] Handle Bluetooth network in Networkmanager
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #302311, revision 13 Title: Handle Bluetooth network in Networkmanager openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Stefan Behlert (sbehlert) + Partner organization: openSUSE.org Description: Networks created over Bluetooth should be handled in Networkmanager, too. This includes WiNet (UWB) References: http://bugzilla.gnome.org/show_bug.cgi?id=432774 Discussion: #1: JP Rosevear (jproseve) (2008-07-14 20:40:48) Bastien N. at RedHat has done some work here now after the somewhat failed initial upstream attempt. #2: JP Rosevear (jproseve) (2008-07-21 13:42:26) (reply to #1) Taking this only if upstream provides it. #3: JP Rosevear (jproseve) (2008-09-08 09:38:29) (reply to #2) Upstream has not provided it in time. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302311

1 0

[openFate 302923] handle redirection to mirrors robustly
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Peter Poeml (poeml) Feature #302923, revision 20 Title: handle redirection to mirrors robustly openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-11-28 15:42:20 reject reason: Out of scope for 11.0 Priority Requester: Neutral openSUSE-11.1: Rejected by Matthias Eckermann <mge(a)novell.com> reject date: 2008-07-22 23:04:50 reject reason: Postponing, will not be ready. Priority Requester: Neutral openSUSE-11.2: Evaluation Priority Requester: Neutral Requested by: Ján Kupec (jkupec) Partner organization: openSUSE.org Description: The proposal is to try other mirrors from a mirror list (from the redirector?) if an error occurs on some of the mirrors while providing a file from http/ftp repository. See the references for more details. References: https://bugzilla.novell.com/show_bug.cgi?id=337410 http://lists.opensuse.org/opensuse-buildservice/2007-10/msg00170.html http://en.opensuse.org/Libzypp/Failover http://code.google.com/soc/2008/suse/appinfo.html?csaid=6F1844AB23B67E06 Discussion: #1: Stephan Kulow (coolo) (2007-11-20 11:15:49) I would be strictly against having an own mirror list. The decision was to go with the redirector (or NCC for SLE) and be done with mirrors. If that does not work, then we have to do this whole thing again, not adding untested work arounds to the product. #2: Stephan Kulow (coolo) (2007-11-20 11:16:55) so I would reject this. But it's basically "Eval by Klaas" now #3: Klaas Freitag (kfreitag) (2007-12-03 09:49:44) I agree with Coolos and Peters statements, I would also reject. #4: Klaas Freitag (kfreitag) (2008-06-12 10:06:42) I have to revert my statement that I made before in comment #3, this problem is more serious than realised in the first look. First, it should be noted that we do not control mirrors nor we do have the chance to really influence them. That means that if a mirrors decides to not longer mirror or to switch off or whatever, we have to live with it. However if a customer is sticky to a mirror that is not longer available he would not get any packages from it and thus installation or update fails. The worst thing about that is that this seems to happen regularly but we do not realise that because we're not involved. A solution would be to have a list of possible mirrors that is used by the software installation stack to find a working mirror. Peter knows much more here. But I am not sure at the moment if not Yast/zypper already has this functionality in 11.0? #5: Peter Poeml (poeml) (2008-10-01 11:58:38) YaST/zypper in 11.1 will have preliminary support for this. The essential part of http://en.opensuse.org/Libzypp/Failover has been implemented during a GSoC project this year. See http://lists.opensuse.org/zypp-devel/2008-09/msg00142.html for the status. There is a number of things left to do, like * making it the default * better debuggability - show what it does * better progress report * testing * integration into the install system so it is available during installation Further features from the proposal (mirror preference, simultaneous downloads) are not tackled yet. #6: Federico Lucifredi (flucifredi) (2009-01-07 16:29:58) I would like to see robust redirection, if possible. The details about a list, probably should not be in the feature description. #7: Todd R (theblackcat) (2009-01-22 22:20:45) Would this also be able to handle changes in the Buildservice, like renaming or moving of a certain Buildservice repository? + #8: Peter Poeml (poeml) (2009-01-23 11:56:48) (reply to #7) + No, that is outside the scope. Changing repositories when the system is + upgraded to a next major version is also outside the scope. Maybe that + can be covered by + http://en.opensuse.org/Standards/Repository_Index_Service, if I am not + mistaking it. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302923

1 0

[openFate 302476] KDE notification for apparmor rejects
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #302476, revision 18 Title: KDE notification for apparmor rejects openSUSE-11.0: Rejected by Stephan Kulow <coolo(a)novell.com> reject date: 2008-03-26 17:30:24 Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.1: Rejected by JP Rosevear <jpr(a)novell.com> reject date: 2008-08-15 11:38:24 reject reason: Rejected due to lack of time. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Stephan Kulow (coolo) + Partner organization: openSUSE.org Description: fate #300563 added dbus event advertising. We'd need a KDE frontend for these dbus events that shows a notification of these events. Documentation Impact: Needs to be documented Discussion: #1: Stephan Binner (beineri) (2008-03-18 10:45:07) Just had a chat with Ludwig and Marcus about this topic (if it would be a nice SoC project) and they don't see much use in having such an applet on the desktop. #2: Marcus Meissner (msmeissn) (2008-03-20 14:52:14) (reply to #1) (background reasoning is: it would spend almost all of the time: doing nothing.) #4: Stephan Kulow (coolo) (2008-03-26 17:30:09) (reply to #2) such dbus callbacks are perfect kded modules - they would register a callback and be dead code after that and create a notification on callback. And it's half a day effort, not really SoC material. #3: Jared Allen (jpallen) (2008-03-20 13:56:50) I like the idea of using this as a SoC project. Let's consider this for openSUSE 11.1 #6: Stephan Binner (beineri) (2009-01-17 16:16:46) (reply to #3) Any objection to make this fate public for openSUSE.org partner and try to advertize it there? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302476

1 0

[openFate 305586] Desktop independent global notification framework
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305586, revision 13 Title: Desktop independent global notification framework openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Desirable Requested by: Stefan Assmann (assmannst) Partner organization: openSUSE.org Description: Our current desktop environments lack a good, configurable notification framework like Growl on Mac OS X. With D-BUS in place we could develop/integrate a framework that is desktop independent and could serve both KDE and GNOME applications the same way. This provides one step towards integrating both desktops more closely, thus making the user experience smoother. One such notification system is already in development. It's called mumbles (http://www.mumbles-project.org/) and provides lots of features similar to Growl. * It's customizable * Has theming support * Has plugin support * Desktop independent * Can use compiz for smooth display Using such a framework, more than just integrating desktops could be achieved: * Local notifications on hardware events * Remote notifications on login/hardware events * Easy scriptability for custom notifications Steps necessary to implement such a framework in openSUSE/SLE: * Install and configure framework by default * Integrate framework configuration in desktop environment * Make framework interactive so the user can react on events (optional) * Make applications D-Bus/Notification aware, so they send events, already available: Firefox, Thunderbird, Pidgin, several others Business case (Partner benefit): openSUSE.org: Such a framework would be a huge win for the general user experience, as it makes the desktop look more integrated and smooth. It's even a good idea for SLES, so administrators can be easily notified when events occur, without the hassle to set up syslog forwarding+parsing+notifying. Discussion: #2: Guy Lunardi (glunardi) (2008-12-18 08:32:18) I agree this is an important part of the desktop platform. How is this different from the libnotify solution which I believe we use for this purpose today? It is my PM understanding it does most everything you are describing including a CLI (notify-send). Applications such as NetworkManager, PowerManager, Pidgin and Banshee. Reading their FAQ, the reason for not using libnotify is that the author wanted to put more Python dependent software on their system :- ). Is this proposal about switching from libnotify to mumbles? (honestly asking, I have no opinion) #3: Stefan Assmann (assmannst) (2008-12-18 15:46:19) (reply to #2) Honestly I have not much insighted into libnotify myself. Talking to Alex Graf about this, we came up with the idea to teach the libnotify daemon how to forward messages to mumbles. It turns out that libnotify has support for theming, so it should be possible to create a theme that forwards all events to mumbles. Then we would not have to make a decision what we should use and could just switch and see what suits us best. This way we don't lose any functionality. In my opinion mumbles looks a lot smoother than the current libnotify messages. However I guess everything possible with mumbles could be tought to libnotify as well. Frankly said I don't want to make a decision here, what I care for is that the functionality described in this fate will be integrated into our products. #4: Stefan Assmann (assmannst) (2008-12-18 16:15:56) (reply to #3) Update: Talking to the developers I just learned that mumbles will intercept libnotify messages and handle them. There's a plugin for mumbles that does that. #5: Tejun Heo (teheo) (2008-12-22 13:28:54) I think that having the notion of what a "notification" is and how the user can take "action"s to it is quite important. There are multiple classes of notifications - some are ephemeral while others must get acknowledgement from the user. For example, download complete from firefox, new driver or codec installation suggestion and smartd reporting imminent disk failures can and probably should use the same notification mechanism but they need to be handled differently. For ephemeral notifications, I think what libnotify has been doing is fine but for anything else, we at least need a way for the user to ack or take actions accordingly and review and search unacked and acked notifications. I think having such notification mechanism will help us a lot as a distro as it will enable us to suggest things in not-too-intrusive yet friendly way. #6: M. S. (funkym) (2009-01-17 13:05:51) libnotify does all that and ontop is based on a desktop independent freedesktop specification (http://galago-project.org/specs/notification/index.php) for notifications to adopt by any desktop environment. It is written in C which is much more suitable for daemons and provides bindings for D- BUS, Mono, Python and Vala. Interactive notifications are already used widely; take PackageKit as an example. The developer of growl is also interested to improve libnotify as they are closely related and friends with the maintainer. A cross desktop friendly notifications utility in Python is the right thing to make things worse. If you want the bling just create a different theme for libnotify... What libnotify needs though is a bit of coding love to implement stuff like network notifications. Switch to Mumbles -> NO! Contribute to libnotify -> YES! $2c #7: Stefan Assmann (assmannst) (2009-01-19 09:55:39) (reply to #6) It's no longer the question whether to switch from one to the other. Mumbles is able to intercept libnotify messages so we can provide it "on top" and switch. Then it's a question of defaults and what we like this to become. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305586

1 0

[openFate 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Stefan Behlert (sbehlert) Feature #304879, revision 31 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear <jpr(a)novell.com> reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Mandatory Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? #8: Armin Moradi (amoradi) (2009-01-19 19:30:45) Excellent idea, again, this brings up the consistency issue with the rest of KDE4. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304879

1 0

[openFate 305543] software mute not in sync with hardware sync
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305543, revision 4 Title: software mute not in sync with hardware sync openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Juergen Weigert (jnweiger) Partner organization: openSUSE.org Description: the GUI is not in sync when pressing the mute button in order to unmute the system. Every user who recognizes that the system is not unmuted by pressing the mute button will surely press volume up. Once done, everything is fine again: system is being unmuted in hardware and the GUI is in sync again. it was like this before for ages. bugzilla#389178 was closed as wontfix, as this is not a regression. I'd appreciate that this be fixed some day. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305543

1 0

[openFate 305534] f-spot should use sqlite3 instead of sqlite2
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305534, revision 4 Title: f-spot should use sqlite3 instead of sqlite2 openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Desirable Requested by: Juergen Weigert (jnweiger) Partner organization: openSUSE.org Description: Currently sqlite2 ist installed per default (at least if user runs gnome). It would be much better to require sqlite3 and to phase out sqlite2 to those applications that really need the old-version- compatibility. f-spot was ported to sqlite3 in version 0.4.2, and supports the latest sqlite-3.6 since version 0.5.0.2. f-spot-0.5.0.3 is shipping with e.g. SLED 11 BETA6 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305534

1 0

[openFate 300689] TabletPC: Support Touchscreen and Wacom decives during installation
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Stefan Behlert (sbehlert) Feature #300689, revision 26 Title: TabletPC: Support Touchscreen and Wacom decives during installation openSUSE-10.3: Rejected by Stephan Kulow <coolo(a)novell.com> reject date: 2007-08-03 09:39:40 reject reason: installation is frozen Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-16 09:02:38 reject reason: Postponing. Out of resources. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Stefan Behlert (sbehlert) Partner organization: openSUSE.org Description: Tablet PCs are normally produced in two kinds of flavours: Convertibles, which have a keyboard, and Slates, which have none (only pens or touchscreens). If a user installs a Slate, he has no keyboard and no (pohysical) mouse device, only the touchscreen. We should on TabletPCs automatically recognize that it is a TabletPC and configure the Wacom or other Touchscreen device where possible. Thus would enhance the usability of the product on TabletPCs. Discussion: #1: Gary Ekker (gekker) (2007-07-17 11:24:05) Stefan, do you see this as work that your team would do, something that needs to be done by the YaST installer, or both? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=300689

1 0

[openFate 305336] [NONCODE] Ship man page for every executable
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Matthias Eckermann (mge1512) Feature #305336, revision 14 Title: [NONCODE] Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) + Partner organization: openSUSE.org Description: User / Administrator should find a dedicated man page for every executable in SLE 11 SP 1. This should be implemented starting with openSUSE 11.2. Business case (Partner benefit): - UNIX "parity". + openSUSE.org: UNIX "parity". Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305336

1 0

[openFate 305168] default to relatime
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Sven Burmeister (rabauke) Feature #305168, revision 10 Title: default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-09-10 10:20:17 reject reason: This is too late for openSUSE 11.1. Postponing. Priority Requester: Mandatory openSUSE-11.2: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: At least for desktops, we should reduce the memory and I/O thrash caused by atime updates, by using relatime. Relations: - bugreport from community (novell/bugzilla/id: 398616) https://bugzilla.novell.com/show_bug.cgi?id=398616 - Offers 'noatime' when 'relatime' is clearly better (novell/bugzilla/id: 461829) https://bugzilla.novell.com/show_bug.cgi?id=461829 Discussion: #1: Robert Davies (robopensuse) (2009-01-16 15:52:09) Bug #461829 is not requesting breaking POSIX semantics by default! relatime should replace noatime option in the mount options part of partioner tool, especially now it has been improved to update atime on file access if it's older than 24 hours. Standards are important, and LRU file caches cannot be relied on if noatime usage is common, or if poor backup software touches atimes, when reading files. + #2: Sven Burmeister (rabauke) (2009-01-23 01:09:47) + 11.1 is out and 11.2 getting started. Did anyone hear of ubuntu + suffering from using relatime by default? If not, it seems likely that + there are little to none issues. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305168

1 0

[openFate 302923] handle redirection to mirrors robustly
by fate_noreply＠suse.de 22 Jan '09

22 Jan '09

Feature changed by: Todd R (TheBlackCat) Feature #302923, revision 19 Title: handle redirection to mirrors robustly openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-11-28 15:42:20 reject reason: Out of scope for 11.0 Priority Requester: Neutral openSUSE-11.1: Rejected by Matthias Eckermann <mge(a)novell.com> reject date: 2008-07-22 23:04:50 reject reason: Postponing, will not be ready. Priority Requester: Neutral openSUSE-11.2: Evaluation Priority Requester: Neutral Requested by: Ján Kupec (jkupec) Partner organization: openSUSE.org Description: The proposal is to try other mirrors from a mirror list (from the redirector?) if an error occurs on some of the mirrors while providing a file from http/ftp repository. See the references for more details. References: https://bugzilla.novell.com/show_bug.cgi?id=337410 http://lists.opensuse.org/opensuse-buildservice/2007-10/msg00170.html http://en.opensuse.org/Libzypp/Failover http://code.google.com/soc/2008/suse/appinfo.html?csaid=6F1844AB23B67E06 Discussion: #1: Stephan Kulow (coolo) (2007-11-20 11:15:49) I would be strictly against having an own mirror list. The decision was to go with the redirector (or NCC for SLE) and be done with mirrors. If that does not work, then we have to do this whole thing again, not adding untested work arounds to the product. #2: Stephan Kulow (coolo) (2007-11-20 11:16:55) so I would reject this. But it's basically "Eval by Klaas" now #3: Klaas Freitag (kfreitag) (2007-12-03 09:49:44) I agree with Coolos and Peters statements, I would also reject. #4: Klaas Freitag (kfreitag) (2008-06-12 10:06:42) I have to revert my statement that I made before in comment #3, this problem is more serious than realised in the first look. First, it should be noted that we do not control mirrors nor we do have the chance to really influence them. That means that if a mirrors decides to not longer mirror or to switch off or whatever, we have to live with it. However if a customer is sticky to a mirror that is not longer available he would not get any packages from it and thus installation or update fails. The worst thing about that is that this seems to happen regularly but we do not realise that because we're not involved. A solution would be to have a list of possible mirrors that is used by the software installation stack to find a working mirror. Peter knows much more here. But I am not sure at the moment if not Yast/zypper already has this functionality in 11.0? #5: Peter Poeml (poeml) (2008-10-01 11:58:38) YaST/zypper in 11.1 will have preliminary support for this. The essential part of http://en.opensuse.org/Libzypp/Failover has been implemented during a GSoC project this year. See http://lists.opensuse.org/zypp-devel/2008-09/msg00142.html for the status. There is a number of things left to do, like * making it the default * better debuggability - show what it does * better progress report * testing * integration into the install system so it is available during installation Further features from the proposal (mirror preference, simultaneous downloads) are not tackled yet. #6: Federico Lucifredi (flucifredi) (2009-01-07 16:29:58) I would like to see robust redirection, if possible. The details about a list, probably should not be in the feature description. + #7: Todd R (theblackcat) (2009-01-22 22:20:45) + Would this also be able to handle changes in the Buildservice, like + renaming or moving of a certain Buildservice repository? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302923

1 0