August 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306461] Evaluate distributability of AC3/A52
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Stanislav Brabec (sbrabec) Feature #306461, revision 1, last change by Title: Evaluate distributability of AC3/A52 openSUSE-11.2: New Priority Requester: Desirable Requested by: Stanislav Brabec (sbrabec) Description: It would be nice to have AC3/A52 codecs enabled in our multimedia applications. Now it's disabled due to its uncertain legal status. The issue need a legal research. Some resources on the internet mention Dolby Laboratories, Inc. as a patent holder. But there is no mention of patents is on their web, no mention whether "AC-3" (which this particular decoder uses to indicate the decoding and downmix methods) is a trademark. Maybe Dolby owns patent to technology, maybe only copyright on implementation. It is also possible, that all relevant patens already expired. A/52 / AC3 is the ATSC's (Advanced Televison Systems Commitee's) audio codec standard for HDTV. Coincidentally, it's also used for DVDs. Also known as ATSC A/52, Digital Audio Compression (AC-3), United States Advanced Television Committee. References: https://bugzilla.novell.com/show_bug.cgi?id=483592 -- openSUSE Feature: https://features.opensuse.org/306461

1 2

[openFATE 307194] Making Gnome Power Manager more customisable
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Marcel Müller (open_assistant) Feature #307194, revision 1 Title: Making Gnome Power Manager more customisable openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Marcel Müller (open_assistant) Description: In the Gnome power manager the lowest time to turn the desktop automatically off is 11 minutes, I think it should be able to choose a lower time. -- openSUSE Feature: https://features.opensuse.org/307194

1 6

[openFATE 306623] Integrate openFATE with Bugzilla
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Andrés G. Aragoneses (knocte) Feature #306623, revision 1 Title: Integrate openFATE with Bugzilla openFATE: Unconfirmed Priority Requester: Important Requested by: Andrés G. Aragoneses (knocte) Description: I really don't understand why we are using openFATE instead of bugzilla for tracking features... But anyway, I think we can live in both worlds. Just make openFATE indeed by a Bugzilla frontend for enhancements and we're ready to go. Of course this requires a serious re-architecture of openFATE codebase, but it would please the community around both projects and it would merge feedback mechanisms. -- openSUSE Feature: https://features.opensuse.org/306623

1 4

[openFATE 306304] support "Obsolete this by another package"
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Stanislav Brabec (sbrabec) Feature #306304, revision 1, last change by Title: support "Obsolete this by another package" openSUSE-11.2: New Priority Requester: Desirable Requested by: Stanislav Brabec (sbrabec) Partner organization: openSUSE.org Description: If third party wants to terminate a temporary branch of a package, which should is obsoleted by the mainline, adding Obsoletes: foo-old-branch into the mainline package is not an option (it's possible only for official packages). Support for an Obsolete tag counterpart initiated by the existing package would fix this situation. Example: Name: gimp-unstable Version: 2.5.23 Provides: gimp = %{version} ObsoleteBy: gimp >= 2.6 It would allow to provide mainline gimp packages without Obsoletes: gimp-unstable < 2.6 and even allow thitd partines to create temporary branches of packages. Business case (Partner benefit): openSUSE.org: Providing a significantly modified packages, that are known to be obsolete after upgrade to the -- openSUSE Feature: https://features.opensuse.org/306304

1 6

[openFATE 305547] Support for ECDSA in yast2 ca_mgm
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305547, revision 8 Title: Support for ECDSA in yast2 ca_mgm - openSUSE-11.2: New + openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) + reject date: 2009-08-12 10:12:58 + reject reason: Too late for 11.2 Priority Requester: Mandatory Requested by: Vit Pelcak (vpelcak) Description: It would be good if yast2 ca_mgm supported ECDSA keys. This feature is necessary to support RFC 4869. Currently only RSA is supported. Discussion: #1: Andreas Jaeger (a_jaeger) (2009-06-09 14:22:26) What is the advantage here? From the description I'm not seeing any benefit of implementing this. #2: Vit Pelcak (vpelcak) (2009-07-01 08:24:04) (reply to #1) This feature request came out from discussion with Marius Tomaschewski when I was testing one feature about ipsec, IKEv2 and ECDSA in RFC 4869. We came to conclusion that it would be good if it would be implemented in Yast2. -- openSUSE Feature: https://features.opensuse.org/305547

1 0

[openFATE 120340] Run download and install in parallel
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature changed by: Ralph Ulrich (ulenrich) Feature #120340, revision 100 Title: Run download and install in parallel openSUSE-10.2: Rejected by Klaus Kämpf (kwk) reject date: 2006-08-09 11:36:10 reject reason: Not possible in 10.2 timeframe Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:25:01 reject reason: Out of time. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:56:11 reject reason: Out of resources for 11.0. Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 12:06:35 reject reason: This needs to wait. Postponing. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-03 08:43:03 reject reason: No resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Klaus Kämpf (kwk) Requested by: Peter Poeml (poeml) Requested by: Reinhard Max (rmax) Description: Network installation could be improved by running package download and package installation in parallel. References: https://bugzilla.novell.com/show_bug.cgi?id=60844 https://bugzilla.novell.com/show_bug.cgi?id=209799 https://bugzilla.novell.com/show_bug.cgi?id=128050 https://bugzilla.novell.com/show_bug.cgi?id=370457 https://bugzilla.novell.com/show_bug.cgi?id=370054 https://bugzilla.novell.com/show_bug.cgi?id=385711 http://en.opensuse.org/Libzypp/Failover http://metalinker.org/ Fate #300660: Download package groups before install Discussion: #2: Klaus Kämpf (kwk) (2006-08-09 11:36:42) Michael already looked at this. Should be further evaluated for 10.3 #3: Edith Parzefall (emapedl) (2007-07-31 16:56:12) Problem is: what do we do if we lost the network connection when only half the packages are installed? #7: Reinhard Max (rmax) (2008-04-10 11:42:43) (reply to #3) I think this is a general problem for network based installations. Can you elaborate if/why you see this as a special problem when download and installation are running in parallel? #8: Peter Poeml (poeml) (2008-05-19 14:49:53) (reply to #7) For reliable operation of a business critical server, it is a must that packages are downloaded first, before the installation/update is started. Otherwise a network outage can lead to a broken system which is half updated. So if parallel download/install is implemented (for desktop users, maybe...) then please make sure that it is possible to disable it. #9: Reinhard Max (rmax) (2008-05-19 16:01:15) (reply to #8) As we just sorted out on IRC, the current implementation also doesn't allow to complete download before starting installation and the feature proposed here wouldn't make this worse. But as the wish of server admins to have all packages downloaded before starting to install them is very valid, I think we should extend this feature request to contain that requirement as well, and probably rename it to "decouple download and installation". If download and installation are properly decoupled, it should just be a matter of the parameters the algorithm is called with to get one of the following behaviours: * Download and install packages one by one (as it is now) * Keep downloading subsequent packages while installing (as originally proposed here) * Use a fixed-size download cache for flow control between download an installations (in situations where download is faster than installation and disk space is limited) * Download all packages of an update or installation and install them afterwards (as requested by Peter for server admins) #10: Jiri Srain (jsrain) (2008-05-20 10:22:10) (reply to #9) We already do have similar feature: #300660: Download package groups before install #4: Edith Parzefall (emapedl) (2007-07-31 16:57:22) Please reject for 10.3. #5: Duncan Mac-Vicar (dmacvicar) (2008-01-10 16:23:46) This is included in the ZYpp plan for 11.0, however implementation will start after beta. Will keep in evaluation, it depends on other milestones for beta1 #14: Chris Hills (chaz6) (2009-02-16 16:42:06) Is there a feature request to install using both the base and updates repo so that the latest packages available at install-time are used, thus saving bandwidth? #15: Jiri Srain (jsrain) (2009-02-17 08:45:38) (reply to #14) This is how it works for quite some time. Repositories providing patches also provide the packages so that they can be installed directly from the update repositories (provided they contain newer version). #16: Duncan Mac-Vicar (dmacvicar) (2009-06-02 15:18:00) For 11.2 we will focus on flexibility of the download and install order (like installing after everything is downloaded), however parallel stuff should be done after we have this in place. Please reject. #20: Jörn Knie-von Allmen (phisiker) (2009-08-05 12:12:29) (reply to #16) Please do not reject. With a downloadprotocol this should be solvable. The Installtask can poll an that protocol (or be informed by a Signal when a download has ended. This is better then polling. Or if prefering an IPC-Framework: D-BUS. Never mind!). Such problems I had some times often to solve (but in Java) and generally, it isn't so dificult. #21: Ralph Ulrich (ulenrich) (2009-08-05 13:03:25) (reply to #20) Please reject forever: As operating system are sort of highly integrated databases there should be a commit like funcutionality: First download then install (like debian). Otherwise repositories representing a rolling release (factory) will potentially break an updating system. #22: Reinhard Max (rmax) (2009-08-06 16:18:54) (reply to #21) Yes, there are situations where this (optional) feature should better not be used, but that does not mean it should not be implemented, because there are many situations where it can be very useful. BTW, how would "download then install" give you anything near commit- like functionality? Factory could still change on the server while you are downloading and packages could still fail during installation, leaving you with an inconsistent installation. + #24: Ralph Ulrich (ulenrich) (2009-08-11 23:42:59) (reply to #22) + Yes, "still fail during installation": there is no commit-like + functionality + But in case of a changed Factory repository there would be an error: + zypper dup --download-then-install || ( zypper ref && zypper dup) || + ... + In this more often case there would be a commit-like functionality + #23: Reinhard Max (rmax) (2009-08-06 16:20:58) (reply to #16) As I've explained in comment #9, the different modes of operation would have been possible with a single implementation and different runtime parameters. I think this would actually be easier than implementing the different modes separately, so why hasn't it been considered? #17: Michal Papis (mpapis) (2009-07-04 20:58:23) I think great example here may be Gentoo, there You can chose the way of getting packages, by default download and installation go in paraler, but it is possible to get first sources and then run build/installation. If you are on the default and something breaks, ex. network, Yuo can always resume the last download&installation task. #18: Giuseppe Salinaro (superpeppo89) (2009-07-16 19:37:27) (reply to #17) This idea of gentoo is good... #19: Ján Kupec (jkupec) (2009-07-20 10:59:31) (reply to #18) Guys, as Duncan wrote in c#16, we are already developing the "download all, install all" mode (currently we only have "download one, install one, ..."), and yes, users will be able to choose one of these. This particular feature would be an improvement of the current mode: "download one, install one while downloading others, ...". I hope this clarifies the current status a bit. -- openSUSE Feature: https://features.opensuse.org/120340

1 0

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

11 Aug '09

Feature changed by: Mario Goppold (mgoppold) Feature #302628, revision 40 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 #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_…) #19: Marcus Meissner (msmeissn) (2009-06-24 15:12:33) (reply to #18) Mario, It would really help us if you could provide a patch against the current git state. The patch does not aspply to current :( (Ludwig is not in the office this and next week, will get back in 2 weeks.) #20: Mario Goppold (mgoppold) (2009-08-11 09:38:09) (reply to #19) The new patch against the boot.crypto- 2acb4efc564ca9af8e97162110987289f1206f11.tar.gz from 13.07.2009 is done. You can find it in my OBS: boot.crypto-0_200907131030.luks-key.dif (https://build.opensuse.org/package/view_file?file=boot.crypto-0_20090713103… 3Amgoppold) Unfortunately it don't build successfully on Factory. There are some echos for debugging they should remove before commit. Now setup-luks.sh uses the /etc/crypttab file and therefore my patch don't need the /etc/sysconfig/initrd anymore.The root device was found by setup-luks.sh automatically and all other devices e.q. home goes to the /etc/cryptab file: home /dev/sda2 none luks,initrd Are there any helful suggestions? + #21: Mario Goppold (mgoppold) (2009-08-11 17:42:20) (reply to #20) + Now, it builds on Factory too. -- openSUSE Feature: https://features.opensuse.org/302628

1 0

[openFATE 305844] osc changelog support
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305844, revision 3 Title: osc changelog support - Buildservice: New + Buildservice: Evaluation Priority Requester: Mandatory Requested by: Adrian Schröter (adriansuse) Description: We need changelog support in osc. A possible way to implement this can happen on submit request create: * Show all comments in commit history since last sr * Offer to edit them in editor * Offer extra lines for adding bugzilla and fate numbers and create correct syntax. -- openSUSE Feature: https://features.opensuse.org/305844

1 0

[openFATE 306533] automatic mailinglists for projects
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Ludwig Nussel (lnussel) Feature #306533, revision 1 Title: automatic mailinglists for projects Buildservice: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Description: In order do coordinate between different people in a obs project itwould be nice if the buildservice automatically providedmaillinglists for each project. Something likePROJECTNAME(a)build.opensuse.org orPROJECTNAME+PACKAGE(a)build.opensuse.org. Mails to such addressesshoudl be forwarded to the project/package maintainers. That way theproject and user list would not have to be synced between the buildservice and a separate mailinglist manager.In a further step the build service could allow interested personsthat are not maintainers to sign up as well. -- openSUSE Feature: https://features.opensuse.org/306533

1 4

[openFATE 306237] YaST Textmode: Display Release Notes
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #306237, revision 11 - Title: yast textmode: displaying release notes + Title: YaST Textmode: Display Release Notes openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Karl Eichwalder (keichwa) Description: In YaST ncurses UI, even if the screen is large (more than 100 characters), do not use more than 79/80 width for displaying the frame containing the release notes text. Lines longer than 80 characters are hard to read. Relations: Discussion: #2: Gabriele Mohr (gabi2) (2009-03-25 14:41:44) I have discussed with Karl. The problem also exits for Qt. Therefore a change in YCP layout is necessary. I have attached a suggestion for a layout change in inst_release_notes.ycp. I have used `Empty and `HWeight to add a margin at the left and right side of the text. This approach works for Qt and ncurses. Karl agrees that a stretchable text (width changes depending on total size) is better than a fix width. #4: Karl Eichwalder (keichwa) (2009-03-25 15:16:03) (reply to #2) Thanks, Gabi! > Karl agrees that a stretchable text (width changes depending on total size) is better than a fix width. Yes, at least, it looks better for normal use cases. The patch will probably improve the readability for most users. #3: Gabriele Mohr (gabi2) (2009-03-25 14:43:38) Added attachment patch for inst_release_notes.ycp (HWeight.diff) -- openSUSE Feature: https://features.opensuse.org/306237

1 0