June 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 303460] Redesign of Sound Card Module
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #303460, revision 19 Title: Redesign of Sound Card Module openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-03-26 16:04:06 reject reason: Out of time for 11.0. Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-06-25 15:09:08 reject reason: Postponing, out of focus. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Desirable Requested by: Martin Schmidkunz (mschmidkunz) Description: Currently the sound card module in YaST hides many options within an "Others" menu button. When adding a sound card the user needs to choose between three configuration ways: automatic, normal and advanced. It is very difficult for the user to choose the appropriate way for him. Ideas for Improvement: * Moving "Volume" and "Start Sequencer" to the "Edit" section. * "Set As Primary Card" is now visible at once to the user * "Play Test Sound" is integrated into the "Edit" section Workflow for "Add" a new sound card: * The user chooses only the vendor and the model. * All the other settings (volume and some advanced settings) can be adjusted via "Edit". * Joystick settings can be done in the "Joystick" module. Mock ups for the redesign are available at: http://en.opensuse.org/Usability/Sound Relations: - feature/id: 304936 Discussion: #2: Guy Lunardi (glunardi) (2008-05-19 00:50:40) mschmidkunz: I believe that re-designing this module is probably a good idea. I hate to mix technology in design and feature discussions but in this case... I wonder if we need to make the module Pulse audio aware. #3: Matthias Eckermann (mge1512) (2008-06-17 17:28:14) (reply to #2) I agree. Just open another FATE regarding Pulse Audio awareness of the YaST module in addition to this one, ...:-) #4: Guy Lunardi (glunardi) (2008-06-18 09:44:48) (reply to #3) Done, I have created 304936 to track the pulse-audio need in YaST. #5: Stephan Kulow (coolo) (2009-04-16 13:37:20) looking for community volunteers -- openSUSE Feature: https://features.opensuse.org/303460

1 0

[openFATE 302628] Access to encrypted devices/partitons by dongle
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #302628, revision 33 Title: Access to encrypted devices/partitons by dongle openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-03-31 10:53:14 reject reason: too late - and still lacking a real concept behind the full story. Priority Requester: Desirable openSUSE-11.1: Rejected by Stephan Kulow (coolo) reject date: 2008-08-07 16:27:08 reject reason: out of resources. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Stefan Fent (sfent) Description: Think of the following scenario: You store your files on an encrypted partition and if you want to access them you just insert your USB stick, flash card or whatever and gain access to your files. Another thought would be to encrypt the whole system and the only possibilty to access it is via dongle. Relations: - FATE#301352: Filesystem encryption using Smartcard certificate (feature/id: 301352) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2007-10-05 23:04:19) Michele (desktop) / Matthias (storage) what do you think about this? #2: Michael Löffler (michl19) (2008-01-02 18:27:26) Nice to have but I miss a business case. #3: Stephan Kulow (coolo) (2008-01-07 14:42:28) (reply to #2) the business case of such a feature only works if you have a company to sell those dongle sticks I'd say. And those dongle vendors prefer custom boot loaders from those I know. So I don't think a solution with a stick that can be easily copied by dd is preferrable and I would rather reject this. #4: Guy Lunardi (glunardi) (2008-01-18 19:46:42) It's my understanding that Chris' work would allow for this to happen. This would be very neat indeed, we have discussed this with several customers who expressed interest. Using a simple USB key would be one inexpensive way to make this work. One alternative that a customer asked was to have the ability to unlock the data using certificates strored within a smart card. #7: Stephan Kulow (coolo) (2008-06-27 11:23:16) (reply to #4) Chris work? I fail to see the context. #9: Guy Lunardi (glunardi) (2008-07-02 15:27:37) (reply to #7) I do believe that Chris' work would be good for us to leverage however I do not know the details and could be wrong since it has been a few months now since we last talked about this. Chris, would you be able to assist me with provide insights on ways we could address this? #11: Chris Rivera (chrismrivera) (2008-07-06 23:52:49) (reply to #9) If you setup an encrypted home directory with cryptconfig it defaults to creating an encrypted container and a key file. The key file can reside anywhere, including removable media. If you use removable media you need to setup an fstab entry using the device label or device UUID to ensure that the dongle gets mounted automatically and the key file is in the right location. #12: Stephan Kulow (coolo) (2008-08-07 16:26:44) (reply to #11) ok, just talked about with Chris about this feature. We have no resources for yast work any more and the work required seem to be this: "so it would just mean moving the .key file to the media, changing the . key file location in pam_mount.conf, and adding an fstab entry" (quoting Chris). So this would be either put in a README or we wait for SPx. #13: Stephan Kulow (coolo) (2009-03-04 11:39:07) (reply to #12) any objection against opening this to openSUSE.org? #14: Marcus Meissner (msmeissn) (2009-03-04 11:40:59) (reply to #13) no, done #5: Stephan Kulow (coolo) (2008-03-31 10:52:41) I still have no clear picture of what cryptfs setups we're going to support - there are various fate entries about it: e,g, 302981 and 301352. So I would like PM to sort this out - and I personally think it's too late for 11.0. #6: Matthias Eckermann (mge1512) (2008-04-01 01:35:14) In an ideal world we would support: * TPM (incl. fingerprint readers etc.) * Smart Cards * simple devices with key on (USB sticks, memory cards) * passphrase (as today) * (optional) integration with a directory (LDAP, eDirectory, ...) #15: Mario Goppold (mgoppold) (2009-03-29 22:26:03) Hi, because I just need to unlook my root partition via USB stick I have build an rpm for it: http://download.opensuse.org/repositories/home:/mgoppold/openSUSE_11.1/x86_… _SVNr46_luks_key-64.1.x86_64.rpm The main changes are in /lib/mkinitrd/scripts/{setup,boot}-luks.sh and the new /etc/sysconfig/initrd.luks_key. The LUKS-Keyfile should on an Labled or UUIDed USB-Stick. You can unlook all partitions with a master key or define a separate for every luks_device. The approach is certainly not the best but there is no keyscript in /etc/crypttab jet (why not?). #16: Ludwig Nussel (lnussel) (2009-03-30 09:13:46) (reply to #15) mind creating a patch against http://git.opensuse.org/?p=projects/boot.crypto.git;a=summary so I can have a look? I'm not really fond of supporting the keyscript option but since debian now uses that askpass program that I like to integrate we'd basically get keyscript support for free at least wrt boot.crypto. For YaST it would be between hard and impossible to support as one can never know what the keyscript does. #17: Mario Goppold (mgoppold) (2009-03-30 22:14:47) (reply to #16) Have a look at boot.crypto-035e11e5c04eb03ca972baf135a12b869e758f91. luks-key.dif (https://build.opensuse.org/package/view_file?file=boot.crypto-035e11e5c04eb… 3Amgoppold) an the new rpm Build 73 (https://api.opensuse.org/build/home:mgoppold/openSUSE_11.1/x86_64/cryptsetu… _SVNr46_luks_key-73.1.x86_64.rpm) #18: Mario Goppold (mgoppold) (2009-04-01 20:59:06) (reply to #16) I have made some little updates: * There is no need to add /dev/mapper/swap and /dev/mapper/what_else to setup-storage.sh. or /boot/grub/menu.lst * If the key-File is not within the luks-Container there is now a prompt fallback. * I added ext3 and jbd modules to have the Key on ext3 formatted USB- Sticks The new version is Build 77 (http://download.opensuse.org/repositories/home:/mgoppold/openSUSE_11.1/x86_…) -- openSUSE Feature: https://features.opensuse.org/302628

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository exists
by fate_noreply＠suse.de 24 Jun '09

24 Jun '09

Feature changed by: Ján Kupec (jkupec) Feature #305553, revision 13 Title: zypper: dist upgrade could error out if more than one repository exists openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. + #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) + Michael, is this still relevant? Is this related to the planned --from + option? -- openSUSE Feature: https://features.opensuse.org/305553

1 0

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

23 Jun '09

Feature changed by: Mario Moritz (eSsMario1st) Feature #304879, revision 80 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear (jproseve) 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) 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. + Use Case: + I will find this is really usefull. 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. #9: Ruurd Pels (rfpels) (2009-03-06 22:40:10) Seems to me now that we have 4.2 in FACTORY for 11.1 we can create and release an integration package there so we will be ready by the time SLES11 goes gold. #10: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:26:13) this would be nice for 11.2 #11: Karsten König (remur) (2009-06-15 15:23:55) Good news everybody! http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2009-06.html#2… (Just for tracking, most openfate users propably have seen this by now on planetsuse) #12: jimbo bigcreed (dimble_thricefoon) (2009-06-16 18:41:27) (reply to #11) dot.kde http://www.kdedevelopers.org/node/3983 KDE4 integration done by the kubuntu boys -- openSUSE Feature: https://features.opensuse.org/304879

1 0

[openFATE 306535] Make edirectory NCS Aware
by fate_noreply＠suse.de 22 Jun '09

22 Jun '09

Feature added by: uma santhanam (sumadevi) Feature #306535, revision 1 Title: Make edirectory NCS Aware Requested by: uma santhanam (sumadevi) Description: ndsd is not cluster aware. There is no supported fault tolerant mechanism for edirectory. NDSD needs to be cluster aware for DSfW to be cluster aware.. -- openSUSE Feature: https://features.opensuse.org/306535

1 1

[openFATE 306534] Remove Concurrent Patterns from Product
by fate_noreply＠suse.de 19 Jun '09

19 Jun '09

Feature added by: Ken Johnson (kenljohnson) Feature #306534, revision 1 Title: Remove Concurrent Patterns from Product Requested by: Ken Johnson (kenljohnson) Description: When SLERT 10 SP2 shipped (GA), Novell was still in partnership with Concurrent (ccur.com) and the product consisted of two media (CD) images. CD2 was dedicated to Concurrent's kernel flavors and tools... thus it provided the packages (RPMs) that belonged to the Concurrent patterns defined on CD1. Post SLERT 10 SP2 GA, Novell and Concurrent ended the partnership and Novell stopped distributing CD2 of the SLERT 10 SP2 media. The decision was made not to remaster the SLERT 10 SP2 media to remove references to CD2. The problem is that CD1 still contains all pattern definitions. This means customers still see the option to install the Concurrent specific patterns that existed on CD2. This has caused a lot of confusion for customers and caused support and engineering resources to be wasted on this issue. -- openSUSE Feature: https://features.opensuse.org/306534

1 0

[openFATE 305317] Default to hidden bootloader menu
by fate_noreply＠suse.de 18 Jun '09

18 Jun '09

Feature changed by: Jan Engelhardt (jengelh) Feature #305317, revision 14 Title: Default to hidden bootloader menu openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Jiri Srain (jsrain) Description: As long as there is no other operating system present (SUSE is the only system), it makes sense to default to hidden bootloader menu (and booting directly). References: http://www.gnu.org/software/grub/manual/grub.html#Hidden-menu-interface https://bugzilla.novell.com/show_bug.cgi?id=425717 Discussion: #1: Stephan Kulow (coolo) (2009-04-16 10:34:48) I like that idea. I guess it's a tiny change for bootloader, but has possibly some docu impact. #2: Stanislav Visnovsky (visnov) (2009-05-28 16:45:13) How should it behave with option to keep kernels from updates (libzypp option)? What about failsafe? #3: Jiri Srain (jsrain) (2009-06-01 11:21:11) From the GRUB documentation: When your terminal is dumb or you request GRUB to hide the menu interface explicitly with the command `hiddenmenu' (*note hiddenmenu::), GRUB doesn't show the menu interface (*note Menu interface::) and automatically boots the default entry, unless interrupted by pressing ESC. When you interrupt the timeout and your terminal is dumb, GRUB falls back to the command-line interface (*note Command-line interface::). This sounds to me like this GRUB feature is intended for different purpose, and the use case described here does not make much sense (unlike lowering the time-out to e.g. 1 second). Torsten, what is your view? According to the documentation, GRUB allows to display the boot menu via pushing the Escape button. #4: T. J. Brumfield (enderandrew) (2009-06-13 03:31:06) This option would only be utilized when no other OS is present, and you can still get back to the menu with Esc. This isn't that much different than needing F8 for the boot menu for Windows. It would speed up boot times. How is that a bad thing? + #5: Jan Engelhardt (jengelh) (2009-06-18 23:53:45) + Does not Fedora do something similar? -- openSUSE Feature: https://features.opensuse.org/305317

1 0

[openFATE 305324] Netcontrol does not set up WLAN when kill switch activated
by fate_noreply＠suse.de 18 Jun '09

18 Jun '09

Feature changed by: Jan Engelhardt (jengelh) Feature #305324, revision 6 Title: Netcontrol does not set up WLAN when kill switch activated openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Important Requested by: Marius Tomaschewski (mtomaschewski) Description: Provide udev rule to activate / deactivate WLAN interface based on killswitch event --- On my Lenovo ThinkPad T60p, the WLAN hardware kill switch doesn't work as expected. I am _NOT_ using NetworkManager, but the traditional ifup method. The problem seems to be, that the wlan interface is not properly brought up/down when I use the kill switch. --- This wont be fixed for 11.0, because there are different types of killswitch events for different drivers. And it works with NetworkManager. But for 11.1 we should be able to handle it more easily. There will be unified killswitch events. What we need is a additional udev rule that calls ifup for that event. Relations: - Netcontrol does not set up WLAN when kill switch activated (novell/bugzilla/id: 383309) https://bugzilla.novell.com/show_bug.cgi?id=383309 + Discussion: + #1: Jan Engelhardt (jengelh) (2009-06-18 23:52:42) + Is not the kill switch handled directly in the kernel? -- openSUSE Feature: https://features.opensuse.org/305324

1 0

[openFATE 306519] rpm support for new digest
by fate_noreply＠suse.de 18 Jun '09

18 Jun '09

Feature added by: Thomas Biege (thomasbiege) Feature #306519, revision 1 Title: rpm support for new digest openSUSE-11.2: New Priority Requester: Important Requested by: Thomas Biege (thomasbiege) Partner organization: openSUSE.org Description: The signed rpm file is the only line of defense we have to protect our packages against tampering while in transit from us to the user/customer. This line gets thinner because the successful attacks against SHA1 and MD5 continue and tools exists that allow easy manipulation since about a year. The good news is that we use MD5 and SHA1 together and not one of this weak algorithms alone. It is only a matter of time until somebody will be able to create a rpm file that fooles MD5 as well as SHA1. If this happens the rpm files of already released and still supported products are vulnerable to manipulation. rpm version 4.6.0 was released this month and support alternative algorithms. We should switch to this version as early as possible to avoid uneccesary costs in the future. Business case (Partner benefit): openSUSE.org: Example: Crypto-analysis scientists improve their attacks and will be able to bypass MD5/SHA1 (hybrid) signatures at 2012. This means we have to adapt rpm, zypp and other tools to support SHA256 bring this new base utils to the customer and re-release the packages with a new signature. Additionally we run in a hen-egg-problem because with the vulnerable libzypp/rpm tools at the client system it is not possible to guarantee the integrity of the new libzypp/rpm packages. This will cause trouble and will cost valueable time. The risk and cost rises the longer we wait because more prodcuts will be affected more likely. Therefore it would be good to adapt the new rpm version for 11.2. If it is too late to make this change it would be wise to deliver the new tools (rpm 4.6.0, what else?) additionally to the tools we need now to avoid the hen-egg-problem. -- openSUSE Feature: https://features.opensuse.org/306519

1 5

[openFATE 303532] Reduce size of updates for openSUSE Factory
by fate_noreply＠suse.de 17 Jun '09

17 Jun '09

Feature changed by: Piotrek Juzwiak (BenderBendingRodriguez) Feature #303532, revision 26 Title: Reduce size of updates for openSUSE Factory Buildservice: Evaluation Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-06-06 09:06:29 reject reason: not really attached to a specific openSUSE version Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter (adriansuse) reject date: 2008-11-06 16:10:03 reject reason: This is a build service feature, but no distribution feature. Priority Requester: Important Projectmanager: Important Requested by: Michael Löffler (michl19) Description: Each update currently is around 2GB which is already much for broadband bandwith. For user with less bandwith it's by and large impossible to use Factory. Goal is to reduce size of updates and stay with frequent updates to offer latest software to the user. As we want more people using Factory it's usage needs to be conveniant. Discussion: #1: Stephan Kulow (coolo) (2008-03-27 16:48:43) According to discussions with Rudi and mls, the delta setup on dist need to be changed to also contain the rpm header and the deltas need to be indexed in a way that zypp will see them. So we can still use drpmsync for internal distribution and put the deltas only in instsource for mirrors. #2: Duncan Mac-Vicar (dmacvicar) (2008-04-22 13:28:56) This will happen automatically once the remaining parts of libzypp deltarpm handling are finished. We only need to agree on the format. I will propose something today. #3: Duncan Mac-Vicar (dmacvicar) (2008-05-26 17:09:31) ZYpp side is done. The only thing that needs to be done is to generate the deltarpm metadata in factory. I will post link to documentation and examples shortly. #4: Gerald Pfeifer (geraldpfeifer) (2009-01-03 14:54:00) Opening this up for openSUSE.org. #5: Stephan Kulow (coolo) (2009-01-16 08:24:42) ok, we discussed this a bit further. We plan to throw away builds that are equal to the previous build and publish deltas generated by the build clients if they are not equal. If a build is equal is to be defined, for now it's a shell script that checks various properties - and works acceptable for now. I rebuild a good portion of 11.1 without further changes and get 7345 binary rpms (including all subpackages). 5666 are considered equal by my current script (based on work by Michael Matz). And many of other packages are possible to fix, so they are equal too. So this gives for uneffected rebuilds a huge reduction of updates. The kernels and kmps are currently seen as !equal after an uneffected rebuild as they put the %release (rebuild counter) in many places. Not sure how much the script should work around such cases. But even for those the download size would reduce: kernel-default.i586 (with base and extra): 25.7MB to download deltas of it: 6.7MB (I think the kernel puts a lot of "rebuild on" info in the code) + #6: Piotrek Juzwiak (benderbendingrodriguez) (2009-06-17 17:29:42) + As an addition to that it would be great if the older package would + stay until the second rebuild so that if something breaks we could go + back to the previous version and report that something's wrong with the + new one. -- openSUSE Feature: https://features.opensuse.org/303532

1 0