January 2009 - openSUSE Features - openSUSE Mailing Lists

[openFate 305400] kerneloops.org for openSuSE
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305400, revision 3 Title: kerneloops.org for openSuSE openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Brandon Philips (philipsb) + Partner organization: openSUSE.org Description: Desktop integration: Stephan Kulow reported that the kerneloops-applet doesn't work under KDE. I will look into this and fix it. Installer integration: Stanislav Visnovsky suggested that Kerneloops opt-in be done in the same way as the smolt opt-in. I think this is the way to go. References: http://kerneloops.org https://bugzilla.novell.com/show_bug.cgi?id=388570 Business case (Partner benefit): - Allows us to see trends in kerneloopses in our community releases on - kerneloops.org and thereby improve our SLE releases. + openSUSE.org: Allows us to see trends in kerneloopses in our community + releases on kerneloops.org and thereby improve our SLE releases. Eventually we could have the daemon report to an encrypted private internal server so we can get Kernel oops reports from enterprise customers. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305400

1 0

[openFate 305403] Bootloader beep configuration
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305403, revision 8 Title: Bootloader beep configuration - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Jiri Srain (jsrain) + Partner organization: openSUSE.org Description: Allow to configure whether the acoustic signal should be used for installed bootloader. Acoustic signal is valuable for visually impaired people, while it may be disturbing e.g. in libraries. Discussion: #1: Jiri Srain (jsrain) (2008-11-12 15:58:43) Default can be set depending on whether braille display was found or whether text-to-speech in isolinux was used. #2: Stefan Behlert (sbehlert) (2008-11-12 17:15:07) Is this feature meant as 'allow atuomatic setting of'? The beep is afaik already configurable to be 'off'. If not, this would be a bug. #3: Stefan Seyfried (seife) (2008-11-12 18:09:40) Please reject this feature. This is seriously overengineered. The beep now defaults to off int the installed system. If somebody wants to enable it, he can do so with gfxboot --change-config "boot::beep=1" Marco only needs to document that for his customers and everything is fine. Please, no YaST module for that. #4: Jiri Srain (jsrain) (2008-11-13 09:39:44) (reply to #3) It's not about a new module, just about a check box in the bootloader configuration. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305403

1 0

[openFate 305443] Support of Bluetooth Mouse and Keyboard on installation
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305443, revision 5 Title: Support of Bluetooth Mouse and Keyboard on installation - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Vladimir Botka (vbotka) + Partner organization: openSUSE.org Description: On Installation the user should be able to decide to use the bluetooth mouse/keyboard. Maybe just in the case that no other mouse/keyboard is detected. Relations: - Bluetooth mouse not detected (novell/bugzilla/id: 445583) https://bugzilla.novell.com/show_bug.cgi?id=445583 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305443

1 0

[openFate 305473] virt-manager: add option to set the keymap via UI for every VM
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305473, revision 6 Title: virt-manager: add option to set the keymap via UI for every VM openSUSE-11.2: New Priority Requester: Important Requested by: Michael Calmer (mcalmer) + Partner organization: openSUSE.org Description: If the default keyboard mapping does not work, it is difficult to set the keymap manual. A option in virt-manager to change the keymap setting via the UI for a single VM would be good to have. See also Bug #444632 Relations: - Wrong default keymap configured. Cannot enter important chars with vncviewer (novell/bugzilla/id: 444632) https://bugzilla.novell.com/show_bug.cgi?id=444632 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305473

1 0

[openFate 305474] provide reliable suspend-on-lid-close
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #305474, revision 3 Title: provide reliable suspend-on-lid-close - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Juergen Weigert (jnweiger) + Partner organization: openSUSE.org 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. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305474

1 0

[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