March 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306760] upgrade dmraid to RC16
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature added by: Marcin Labun (mlabun) Feature #306760, revision 1 Title: upgrade dmraid to RC16 openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Marcin Labun (mlabun) Description: RC16 version of dmraid (not yet published) will include following features/bug fixes (full description of bugs can be RH BZ): 479419 [SEC] OROM/DMRAID metadata inconsistency 479425 Incorrect status displayed when disk is missing [status] 483282 dmraid -r will falsely toggle the OROM back to 'normal' status after a failed rebuild 481735 [SEC] dmraid does not allow to activate RAID arrays in degraded state 481749 [SEC] DMRAID does not receive and process kernel events for active devices 505005 dmraid always creates error mapping for the last device in an isw RAID5 set 505007 dmraid regression on raid45 target kernel status interface 506893 Segmentation fault for RAID5 when starting manual rebuild 473282 [SEC] Include support for compatibility with IMSM 9.0 metadata in dmraid 505011 dmraid doesn't update isw metadata to OK during rebuild -- openSUSE Feature: https://features.opensuse.org/306760

1 1

[openFATE 306600] A small change that would make openSUSE a bit easier to use
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature added by: Glöm Det (Searching_for_Answers) Feature #306600, revision 1 Title: A small change that would make openSUSE a bit easier to use openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Glöm Det (searching_for_answers) Description: I'm not the most exprienced Unix/Linux user and as a nuub I see how you could make it easier for other nuubs coming from Windows. When I look at the openSUSE directory(is it shared with Linux and Unix?) I see alot complicated abbriviations like sbin, var, opt, mnt, proc and stuff. Now I could google what they stand for and what types of files are in there but it would be easier if I didn't have too. There for I suggest that you rename... DON'T GIVE UP... those files to their full extension names. I know this wouldn't work out well since it might be important for developers and the speed of terminal writing that the remain as they are. Instead here is my solution. Keep the directory as it is but add this feature too openSUSE. When you hold/right click your mouse over the folder the full name appears. If you for exampel hold it over the lib folder the full name of library appears and a short description telling what kinds of files that are stored here. When you comes to making your own folders you are are able too write description and the full name if you want. That can't be too complicated to make right. It is a small change that will make it alot better. But maybe I'm not asking the right persons here. Maybe Dolphin the file manager's crew is the one to tell about this suggestions. In that case or if you have any questions. Send a private message to Searching_for_answers . P.S. I discoverd this Use and Test cases now. I don't know what they're for so I leave them blank -- openSUSE Feature: https://features.opensuse.org/306600

1 7

[openFATE 308626] Snapshot/Rollback interface to the ZYpp stack
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature changed by: Andreas Jaeger (a_jaeger) Feature #308626, revision 6 Title: Snapshot/Rollback interface to the ZYpp stack - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Ability for libzypp and exposed via zypper to snapshot either automatically or explicitly the system before commit happens, plus an interface to revert the system. The interface should be generic and allow for different possible implementations which should be offered depending on the context: * btrfs based if /root is btrfs * simple based on package list before commit, plus package history and current package list to determine diff last transaction * two root partitions, where the interface would clone root filesystem before commit and switch them at rollback time. The feature includes the concept, and a working implementation with one or more of the strategies described before. References: https://fedoraproject.org/wiki/Features/SystemRollbackWithBtrfs http://dev.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autou… http://wiki.rpath.com/wiki/Conary:conary_rollback Documentation Impact: Requires description of the functionality in zypper options Test Case: zypper install foo bar zypper rollback System should be as before the installation. Corner cases are not important. Use Case: Administrator installs a bunch of updates, which leaves the system in an an unworkable state. He types zypper rollback to undo the changes. Business case (Partner benefit): openSUSE.org: * Customer asked about snapshoting during our last meeting. * Feature parity with Solaris which is implementing package rollback based on ZFS * RHEL goes the same route, announced btrfs rollbacks in yum * We can do better, offering something more flexible and not btrfs dependent to support different scenarios: SLES (btrfs), Appliances (dual system partition), openSUSE (simple package list) -- openSUSE Feature: https://features.opensuse.org/308626

1 0

[openFate 305724] Allow to take over old users by home directory
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature added by: Jiří Suchomel (jsuchome) Feature #305724, revision 1, last change by Title: Allow to take over old users by home directory openSUSE-11.2: New Priority Requester: Neutral Requested by: Jiří Suchomel (jsuchome) Partner organization: openSUSE.org Description: (from bug reporter:) I have a seperate /home partition and whenever I reinstall/upgrade I just set up the same user as before and he gets assigned the same uid (1000) so nothing gets broken. But I guess with more users and corresponding home directories this aproach begs for wrong permissions, so I suggest the following: In case /home isn't empty it could take all directories available and list them as users to specify their data (Name, login, passwort etc as usual) and then assign corresponding uid. References: https://bugzilla.novell.com/show_bug.cgi?id=464238 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305724

1 7

[openFATE 305572] Extend dwarfextract for generic distro packages
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305572, revision 13 Title: Extend dwarfextract for generic distro packages - openSUSE-11.2: Rejected by (cthiel1) + openSUSE-11.2: Rejected by Jan Blunck (cthiel1) reject date: 2009-12-03 11:41:26 reject reason: not done in time. Priority Requester: Important Projectmanager: Desirable - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Important Requested by: Jan Blunck (janblunck) Description: dwarfextract is a tool to postprocess debuginfo. The tools removes duplicate type information caused by linking different compilation units. Currently the tool has only been used to work on the debuginfo of the kernel package. The tools should be extended so that it can be used in the buildsystem to postprocess any applications debuginfo (like C++ debuginfo etc.). Tools that use debuginfo like GDB need to tested and fixed accordingly. Relations: - Based on work for this FATE (feature/id: 304323) Discussion: #1: Andreas Jaeger (a_jaeger) (2009-06-09 14:24:16) Let's only do this, if it brings us more than 10 % of space saving. Jan, can you give any numbers from the kernel? #3: Jan Engelhardt (jengelh) (2009-12-05 13:41:43) (reply to #1) Any space saving is a space saving (well, for large values of "space") - there are about 14GB in /debug/dist/11.2/repo/oss, and even if the saving was somewhat less than 1.4GB (=10%), say 5% instead, it would seem worthwhile. -- openSUSE Feature: https://features.opensuse.org/305572

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository with a base product exists
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305553, revision 38 Title: zypper: dist upgrade could error out if more than one repository with a base product exists openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: 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? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) OK, so this should not be too much work. So to sum it up: * zypper: show a warning in 'dup' if there are multiple base repos with different CPEids enabled. * metadata: check/include the CPEid in product metadata (who should do this?) #16: Ján Kupec (jkupec) (2009-07-27 17:30:09) (reply to #14) Rudi, please look at c#14 and 15 #17: Ján Kupec (jkupec) (2009-07-29 19:04:40) Current status: * TODO: put CPE IDs to content/prodcuts.xml metadata (still nobody assigned to do this!) * TODO: satsolver will need to parse the above (or is this ready already?) * PROBLEM: we need to figure out which repos don't go together for dup. I proposed to compare CPEs of 'base' or 'platform' repos, but we have no 'isBase' flag in product or repo metadata. Simply checking for different CPEs is not enough (think of one base product and one addon - two different CPEs, but 'dup' is OK with them). * PROBLEM: even if we'll have the 'isBase' flag, we'll be stuck in case of two different, but compatible bases, like e.g. SLES and SLED could be used standalone or with SLED as an add-on to SLES in the past. Do we still allow this? Any ideas? #18: Ruediger Oertel (oertel) (2009-07-30 17:20:05) adding more data (like the CPE-ids) is not a big issue. the problem for me is rather how to obtain a CPE-id #19: Marcus Meissner (msmeissn) (2009-08-04 17:55:08) CPE ids can be defined by the vendor as I udnerstand ;) I mailed Jan and Rudi. my suggestions would be: cpe:/o:opensuse:opensuse:11.1 cpe:/o:novell:suse_linux_enterprise:11:ga:server cpe:/o:novell: suse_linux_enterprise:10:sp2:desktop #20: Ralph Ulrich (ulenrich) (2009-08-05 13:25:05) (beginners question) Why products at all. Debian/Ubuntu do have so called meta-packages , which are normal package that pull in stuff: minimal, standard ...etc Without products you would loose an additional level of complication? #21: Ján Kupec (jkupec) (2009-08-05 15:02:36) (reply to #20) Using metapackages for puling stuff does not exlude using of CPE ID. It's just means to uniquely identify a product and can be used by Debian's metapackages as well. Other than that, your question is not related to this FATE, and is more appropriate for opensuse-softwaremgmt(a)opensuse.org mailing list. But you might find the answer also here http://en.opensuse.org/Product_Management #22: Ján Kupec (jkupec) (2009-08-19 17:25:34) We still need to do the TODOs and resolve the issues from c#17 here. If you have an idea, please speak up. #23: Klaus Kämpf (kwk) (2009-08-25 09:36:05) I believe the request title is wrong and should be adapted. Indeed 'distribution upgrade' is special, as it considers one repo to be 'authorative' and thus dictating package versions, which might result in a version downgrade. 'zypper dup' should provide support for this and, in case of multiple 'product' (resp. base) repositories request a decision from the user. There are two things to be solved from my pov * Detection of a 'base' vs. 'addon' repo. Could be done by looking at a 'product' resolvable. * Specifying the 'authorative' repo in case of dist upgrade. ie. passing a '--product foo' or '-to repo' to zypper. #24: Ján Kupec (jkupec) (2009-11-18 15:59:55) (reply to #23) Detection of base vs. addon is what we currently lack. The authoritative repo can now be selected using --from option. 'zypper dup --from repo-oss'. #26: Ján Kupec (jkupec) (2009-11-20 15:29:56) Following Jiri's suggestion, i've done this the simple way for now: if --repo or --from are not used, and multiple repos are enabled, 'zypper dup' will show a warning and a hint that the user should check the repo list for incompatible repos. #27: Jiri Srain (jsrain) (2009-11-25 13:55:01) (reply to #26) This is all we could do for SP1. Keeping open for further enhancements for SP2 and/or 11.3. -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305547] Support for ECDSA in yast2 ca_mgm
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305547, revision 19 Title: Support for ECDSA in yast2 ca_mgm 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 - openSUSE-11.3: New + openSUSE-11.3: Evaluation 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 305546] Support for NTLM authentication (proxy) in YaST and libzypp
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305546, revision 16 Title: Support for NTLM authentication (proxy) in YaST and libzypp openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 18:02:44 reject reason: out of context for openSUSE. Priority Requester: Desirable Projectmanager: Desirable - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Desirable Requested by: Katarina Machalkova (kmachalkova) Partner organization: openSUSE.org Description: YaST and libzypp should work in an environment with proxy server requiring NTLM authentication. The feature consists of two parts: 1) YaST proxy module has to provide UI to let user choose NTLM and write configuration file (/root/.curlrc) accordingly 2) libzypp media backend needs to be adapted to read and understand such configuration( that is, accept also --proxy-ntlm option instead of bare --proxy only) References: https://bugzilla.novell.com/show_bug.cgi?id=440296 https://bugzilla.novell.com/show_bug.cgi?id=412137 Business case (Partner benefit): openSUSE.org: Significant for adoption in mixed datacenters where the proxy infrastruture is on MSFT assets. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:57:23) Sadly, there is a realistic business case for this in mixed datacenters. Some odd people like to use NTLM proxies, I will never understand why. this will be a headache to do :-/ #2: Mark Muhlestein (mmuhlestein) (2010-01-13 18:10:39) Many of the engineers at Dell Computer in Austin want to use openSUSE 11.2 on their desktop machines. Dell uses a NTLM proxy on their corporate network so a lack of this functionality is keeping them from doing so. This group of engineers are very loyal SUSE/Novell folks who are trying very hard to help a SUSE desktop make inroads into Dell's corporate environment. Current number of engineers who cannot use the product is 50 - 60 On a side note, they see this a glaring problem. I don't know how many corporations use NTLM proxies but the gents at Dell seem to think it is quite a lot. #3: Katarina Machalkova (kmachalkova) (2010-01-14 15:03:36) I was wondering whether aria2c can handle NTLM auth. curl certainly does, but it's not our default downloader anymore. I googled a bit and found this table (http://curl.haxx.se/docs/comparison-table.html) and it doesn't look too positive :( #4: Duncan Mac-Vicar (dmacvicar) (2010-01-14 16:51:17) Because we are now using aria2 (however ZYpp stll can fall back to curl) I asked aria2 author if he planned something in the direction. He does not, however he will look into the protocol. The problem, appart of the time, is that he does not have a server to test. He pointed me to http://ntlmaps.sourceforge.net/ which allows to authenticate against a NTLM server acting as a normal proxy server. I have never tested this, but I wonder if companies really need support for this protocol in the tooling. #5: Michael Calmer (mcalmer) (2010-01-14 16:57:35) (reply to #4) I would say yes. I see sometimes logs from the registration where is a proxy is in use with NTLM authentication. I think this is some kind of Windows Server which is doing the authentication and automatically support NTLM. If possible, we should have a way to support this. -- openSUSE Feature: https://features.opensuse.org/305546

1 0

[openFATE 305351] pam_mount update to latest stable version
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305351, revision 13 Title: pam_mount update to latest stable version - openSUSE-11.2: Rejected by (cthiel1) + openSUSE-11.2: Rejected by Johannes Meixner (cthiel1) reject date: 2009-10-27 16:00:56 reject reason: postpone, config file changes were to risky Priority Requester: Important Projectmanager: Important - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Important Requested by: Michael Calmer (mcalmer) Description: The author of pam_mount declared the current version 0.X as unsupported. We should update 11.2 to the newest version. We can also think about an update for SLE11 SP1 if possible. The problem here are massive changes in the configuration file again. A clean and safe convert of the configuration might not be possible. Relations: - pam_mount: update to latest (novell/bugzilla/id: 438457) https://bugzilla.novell.com/show_bug.cgi?id=438457 Discussion: #2: Jan Engelhardt (jengelh) (2009-03-01 16:34:42) Anything but the latest two top releases are basically unsupported. The config file has been stripped of most built-in defaults that nobody ever changes anyway. For a conversion, just strip everything but < mntoptions>, <volume> and <luserconf>. -- openSUSE Feature: https://features.opensuse.org/305351

1 0

[openFATE 305307] Desktop neutral notification
by fate_noreply＠suse.de 02 Mar '10

02 Mar '10

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305307, revision 17 Title: Desktop neutral notification openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-09-02 18:49:19 reject reason: no resources. Priority Requester: Important Projectmanager: Desirable - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Important Requested by: Stanislav Brabec (sbrabec) Description: Up to 11.0, powersave-notify provided desktop neutral notification. Since 11.1, there is no way, how daemons can notify desktop users about fatal issues. Examples: smartd needs to notify about dying disc nut and apcupsd need to notify about failing power (hal power management cannot be used yet, as many UPS devices are not auto- detectable, hal static-config-based prober does not exist yet, nut-hal supports ony HID devices and apcupsd has no hal connector at all). References: https://bugzilla.novell.com/show_bug.cgi?id=230267 Discussion: #1: Holger Macht (hmacht) (2008-09-17 17:27:33) This should be added to a bakend like the HAL database so that desktop applets can catch the information and show them to the user. We already have something like this for "defective batteries" gnome-power-managar shows to the user. #2: Stanislav Brabec (sbrabec) (2008-12-16 11:48:45) Virtual console may be another way to implement it: http://gxconsole.sourceforge.net/ But such simple implementation does not allow i18n. #4: Klaas Freitag (kfreitag) (2009-09-02 17:21:13) Please reject for now, but I like the idea of the common desktop initiative. -- openSUSE Feature: https://features.opensuse.org/305307

1 0