July 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306897] PHP5.3
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Ralf Becker (RalfBeckerKL) Feature #306897, revision 1 Title: PHP5.3 openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Ralf Becker (ralfbeckerkl) Description: I would love to see php5.3 included in the next openSUSE release (11.2). It' included many useful new features and openSUSE could be one of the first distros to include it. EGroupware (www.egroupware.org) is working with php5.3. Ralf -- openSUSE Feature: https://features.opensuse.org/306897

1 1

[openFATE 306462] Evaluate distributability of MPEG container codecs
by fate_noreply＠suse.de 12 Aug '09

12 Aug '09

Feature added by: Stanislav Brabec (sbrabec) Feature #306462, revision 1, last change by Title: Evaluate distributability of MPEG container codecs openSUSE-11.2: New Priority Requester: Desirable Requested by: Stanislav Brabec (sbrabec) Description: Due to uncertain legal status of MPEG stream and transport stream format decoders, its implementation is not part of our products. It would be nice to evaluate its legal status and make possible to decode MPEG2/4 videos using free video and audio codecs, for example Dirac video. Decoding a video requires finding of synchronization points (transport stream decoding, for a stream broadcasting) demultiplexing (stream decoding), then decoding video (passing video sub-stream to the video codec) and audio (passing sound sub-stream to the sound codec). It is known, that video codecs for MPEG-2/4 are part of MPEG LA (http://www.mpegla.com/) patent portfolio. It is known, that audio codecs for MPEG-2/4 are part of VIA Licensing (http://www.vialicensing.com/) and Thomson (http://mp3licensing.com/) patent portfolios. Legal status of the stream operations (transport stream synchronization, multiplexing and demultiplexing) is not known. It may be covered by some patents, but it is possible that there are no patents covering the stream container formats. References: https://bugzilla.novell.com/show_bug.cgi?id=483592 -- openSUSE Feature: https://features.opensuse.org/306462

1 2

[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 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 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 306503] LiveCD: Save installer settings in case of abort and rerun
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Jakub Rusinek (liviopl) Feature #306503, revision 1 Title: LiveCD: Save installer settings in case of abort and rerun openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Jakub Rusinek (liviopl) Description: Some people may encounter problems using installer and abort installation and rerun it later. Installer should remember settings to make their lives easier. -- openSUSE Feature: https://features.opensuse.org/306503

1 2

[openFATE 306366] Need ability to add business case during fate creation over web.
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Joe Harmon (jaharmon) Feature #306366, revision 1, last change by Title: Need ability to add business case during fate creation over web. openFATE: Unconfirmed Priority Requester: Important Requested by: Joe Harmon (jaharmon) Description: When creating a new feature using fate.novell.com you have the ability to create a use case, test case, but not the ability to add a business case. Can we get that option added as well? -- openSUSE Feature: https://features.opensuse.org/306366

1 8

[openFATE 306595] Yast2 package manager: Save package selection on abort/cancel, recover/resume at
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Vincent Petry (PVince81) Feature #306595, revision 1 Title: Yast2 package manager: Save package selection on abort/cancel, recover/resume at openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Vincent Petry (pvince81) Description: >From bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=506968 In the following cases, I happen to cancel a long yast installation/update:1) When I figure out I forgot to select a package for the big install/update.2) When I want to install a small package, but can't because yast is lockingrpm/zypper.3) When the internet connection is too slow, and I'd like to cancel it for nowand try again later.4) When I figure out the install will take longer than planned, and I want toturn the computer off and resume the install the next day.After each of these possible cases, I wish I could simply resume theinstallation from where it was stopped, or at least recover the packageselection I made, especially if it took me a long time to pick the packages.Steps to Reproduce:1. Open yast2 and "Install software"2. Spend some time select a lot of packages to install3. Click "Ok", and let the install run.4. At some time cancel the installation5. Restart Yast "Install software"Actual Results: Frustraction, because at step 5, the package selection is gone (especially ifyou took a long time to pick them), and even though some of the packages havealready been installed, the rest of the selection (from step 2) must be doneagain.Expected Results: When clicking on "Cancel" at step 4, yast saves the current package selection(or the to-be-installed list) into a temporary file.At step 5, when restarting yast, it tells that an install has been aborted andlets the user choose to recover the package selection from that point.Possible variations:1) When yast starts, don't ask anything, but provide a menu item or button toreload the backed-up package selection.2) When cancelling, the dialog could ask the user if he/she wishes to resumethe installation later. If yes, the package selection is saved, else it is justforgotten. -- openSUSE Feature: https://features.opensuse.org/306595

1 3

[openFATE 306596] Yast2 package manager: Select/taboo packages by feature/provides/hardware
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Vincent Petry (PVince81) Feature #306596, revision 1 Title: Yast2 package manager: Select/taboo packages by feature/provides/hardware openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Vincent Petry (pvince81) Description: >From bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=506970 I have no bluetooth devices, so it would be convenient to prevent/taboo anybluetooth package to become automatically installed on the system. I have an intel GPU, but it didn't prevent the Xorg packages for radeon andunichrome to get automatically installed (suggested packages?). It would be convenient to have a way to select or taboo packages by feature orhardware availability. It could look like a metapackage or an option that couldbe selected, like: "Bluetooth -> Never install" "Graphics driver - Intel -> Selected" "Graphics driver - Radeon -> Never install" -- openSUSE Feature: https://features.opensuse.org/306596

1 3

[openFATE 306645] Secure home directory permissions by default
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Jan Engelhardt (jengelh) Feature #306645, revision 1 Title: Secure home directory permissions by default openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Jan Engelhardt (jengelh) Description: Also see https://bugzilla.novell.com/show_bug.cgi?id=518550 . The default for home directories is 0755 (umask 022 in login.defs), and here's the fate entry to change it to 0711 (umask 066). -- openSUSE Feature: https://features.opensuse.org/306645

1 8

[openFATE 306653] Default confirmation in zypper should be set to No
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Luc de Louw (delouw) Feature #306653, revision 1 Title: Default confirmation in zypper should be set to No openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Luc de Louw (delouw) Description: At the moment when doing zypper remove whatever the default of the confimation is set to YES. This is quite dangerous because dependencies will also be removed. I suggest to set all default confirmation answers to NO to prevent unintended actions when accidentialy pressing the enter key in the wrong terminal or similar Murphy occurences. -- openSUSE Feature: https://features.opensuse.org/306653

1 5

[openFATE 306171] openfate login is not usual novell one
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature added by: Jean-Daniel Dodin (jdd_sysop) Feature #306171, revision 1, last change by Title: openfate login is not usual novell one openFATE: Unconfirmed Priority Requester: Important Requested by: Jean-Daniel Dodin (jdd_sysop) Description: The openfate login is unusual. It's not recognised by Firefox. Usual Novell login don't have fields in the source page, but only a login one that send to the novell page. Here I have to key in login/pass then I go to an other page and have to rekey why? -- openSUSE Feature: https://features.opensuse.org/306171

1 2

[openFATE 305866] osc/obs: load Packages from every Project without Link
by fate_noreply＠suse.de 10 Aug '09

10 Aug '09

Feature added by: Sascha Manns (saigkill) Feature #305866, revision 1, last change by Title: osc/obs: load Packages from every Project without Link Buildservice: Unconfirmed Priority Requester: Neutral Requested by: Sascha Manns (saigkill) Description: If i build Packages with OBS/OSC, i must link Packages from other Project to my own. I wish me, that future Releases from OBS/OSC solve the depencies automaticly, and load the Packages from every Repository. Other Way, is if we give Repositories an Priority Number. So the OSC/OBS works first with the high Priority Repos. -- openSUSE Feature: https://features.opensuse.org/305866

1 8

[openFATE 306195] Add DPI option to SaX2
by fate_noreply＠suse.de 06 Aug '09

06 Aug '09

Feature added by: Vitaliy Tomin (HighwayStar) Feature #306195, revision 1, last change by Title: Add DPI option to SaX2 openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Vitaliy Tomin (highwaystar) Description: DPI are very important thing for good font rendering, it always should be equal horizontal and vertical means. Now SaX have option for set display size in millimeters, but it not usefull. By automatic detection SaX make strange DPI means like 95x101 or 84x91 or something else. This values produce ugly font rendering. I suggest to make an option to set fixed DPI for screen, or easier set of physycal screen size in millimetrs to make an wanted DPI like 96, that mean DPI : 96x96 -- openSUSE Feature: https://features.opensuse.org/306195

1 5

[openFATE 306772] kernel update only with kernel header
by fate_noreply＠suse.de 06 Aug '09

06 Aug '09

Feature added by: Matteo Zuliani (tekkkkkk) Feature #306772, revision 1 Title: kernel update only with kernel header openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Matteo Zuliani (tekkkkkk) Description: hi every time kernel update is without kernel headers. This cause some problems if on computer is present virtual machine or graphic drivers that require partial recompile Sorry for my english -- openSUSE Feature: https://features.opensuse.org/306772

1 2

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

30 Jul '09

Feature changed by: Ruediger Oertel (oertel) Feature #305553, revision 22 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 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 -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 30 Jul '09

30 Jul '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305168, revision 26 Title: default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) 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: Evaluation Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) 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 + Documentation Impact: + Needs to be documented in release notes 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. #3: Stephan Kulow (coolo) (2009-05-08 16:51:21) Matthias, I would think the easiest solution is replacing the current checkbox "use noatime" with "use relatime" and make it default (possibly per product). atime is a major pain for many systems where powersave and co are affected. #4: Matthias Eckermann (mge1512) (2009-05-11 15:52:11) (reply to #3) I am not perfectly happy, as a system crash could invalide the "atime"s with "relatime" switched on; looking for supporting information though, it seems, the broader Linux community is in favour of "relatime" (with remarkable exceptions); thus I propose: * introduce "relatime" as an independend parameter * keep the "noatime" checkbox in YaST * make "relatime" default on SSDs automatically * introduce a generic switch in YaST "defaultrelatime", which can be switched on/off per product * make "relatime" default "on" for the openSUSE product Does that help? #5: Jan Kara (jankara) (2009-05-11 16:33:11) This is a bit separate to how it will all look in Yast but I wanted to point out that in current Linus's tree (going to be 2.6.30) is a patch which changes kernel's default to 'relatime'. So unless we change something, all filesystems on this or newer kernel are going to be mounted as relatime (you have to specify 'strictatime' mount option if you really wish to keep atime). #6: Stephan Kulow (coolo) (2009-05-12 10:36:27) (reply to #5) then we can leave everything as it is actually and the feature is Done once we switch to 2.6.30 #7: Jan Kara (jankara) (2009-05-12 13:08:05) (reply to #6) Yes, the original request will be fulfilled. But I believe it would be good to have a selection in partitioner tool like: "Access time behavior: <relatime|noatime|strictatime>" anyway and make 'relatime' default. Also it is a question how to behave on update - the safest would be to add 'strictatime' to filesystems that don't have any atime setting but realistically it is probably better to ask user whether he agrees to switching to relatime and default to "yes". #9: Stephan Kulow (coolo) (2009-05-12 13:45:51) (reply to #7) completely different feature IMO and way more complex (and definitely over the top of openSUSE 11.2) #10: Duncan Mac-Vicar (dmacvicar) (2009-05-12 14:00:25) (reply to #7) Do we really need this extra options really? Is there a good usecase for it? I don't want to bring something to implementation because it is "good", "cool" or "nice to have". #11: Jan Kara (jankara) (2009-05-12 15:50:33) (reply to #10) User can always edit /etc/fstab by hand so strictly speaking it's not necessary. About the usecase - there really are people who want 'strictatime' for various reasons (well, most often they are just afraid that something can break). From my POV that is enough for substituting that 'noatime' checkbox we have currently with the selection I suggested but I admit I'm not the one who'll have to implement it ;-). Regarding the update - silently changing the behavior of atime seems kind of rough to users to me. At least we should warn them (release notes?) that this is happening and that they can add 'strictatime' to /etc/fstab if they have problems with the change. #12: Andreas Jaeger (a_jaeger) (2009-06-09 15:36:15) (reply to #11) Let's add something to the release notes for those updating - and not do any other changes. #13: Arvin Schnell (aschnell) (2009-07-29 15:14:15) (reply to #12) With 2.6.30 in factory this isn't a feature for yast2-storage anymore. Andreas, if something should be added to the release notes please assigned to approptiate people. + #14: Andreas Jaeger (a_jaeger) (2009-07-30 10:06:20) + Karl, could you add something, please? + Arvin, I agree. -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 306983] Create a Single way of Managing NIC Devices
by fate_noreply＠suse.de 30 Jul '09

30 Jul '09

Feature added by: Scott Couston (zcnnnnzc) Feature #306983, revision 1 Title: Create a Single way of Managing NIC Devices openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Scott Couston (zcnnnnzc) Description: In Opensuse 11.1 the decision was made to remove Yast controll of Network Manager. This created 2 semi-dependant ways of managing Network Interface Cards, that in retrospect offered poor or impossible singular control. This decision may have had technical merit however it created a huge deal of complication and bugs as a result. At this time KDE4 NM was not available and KDE3 NM was the only form of NM available to this version of openSuse. In the case where NM is selected over IFUP, other dependant Yast Applications offered no control over the NIC and IP itself. Take the small example of the Yast Firewall. If NM was selected over IFUP, the Yast Firewall offered NO contol over the IP. If NM is selected over IFUP, the NIC(s) as a devices, offered no controll as Yast defines all dependancies over NIC(s) as a device or multiple devices. If NM is selected over IFUP during Installation, there was no facility to input static IP's or effect any controll over NM as Installation only offered the user to choose the alternate NM but not configure it. Poor or No testing of a PC that was on a LAN where NO DHCP Services were offered was obvious. Without DHCP Servies, it was not possible to Install updates as IFUP could not provide nominated DNS Services. IFUP could only set a static IP, but failed to provide DNS Services despie being present in IFUP's configuration. NM also suffered at the fate of DHCP Services. Despite Static Services being present in NM, the presence of DHCP Services overruled static entries in NM as thease were ignored. NM only provided static services so configured, when DHCP Services were Not present. The control over NIC cards became a total IF issue. Any variant from IFUP using DHCP Services and the LAN also providing them, meant we lost control over the NIC(s).* We need to decide IF we need to maintain both IFUP and NM for control over NIC(s) as of 11.1 we offer almost NO control over any variant so configured* The downline application to configure WIFI, VPN, IPV6 etc are all compromised. 2 totally different methods of appling downline services need provision for the rest of further developements. I do not think it is realistic for us to continue to maintain both IFUP and NM as the down line repercusions are so huge and without control over an IP and DNS we might as well stop developement. It is not sufficant to depend on DHCP Services always being present as we then assume a condition that may not be set. This would be akin to stating in the"Installation Requirements" and adding a line stating that OpenSuse requires DHCP Services to be present for the software to "Install and Function Correctly" Either we dump NM or IFUP. Certainly unless Yast can controll NM it must go OR if we want to take the other downline services of VPN, WIFI, IPV6; IFUP must go. Request for Comment neeeds to start, both in the technical requirements of a singular control and the userability of same. The above statments are all suypported by various bugs, mostly opened by the author. Any Commnts please? -- openSUSE Feature: https://features.opensuse.org/306983

1 0

[openFATE 306350] Implement Debian's Kaboom KDE Migration-Tool
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature added by: Maximilian Maher (maxmaher) Feature #306350, revision 1, last change by Title: Implement Debian's Kaboom KDE Migration-Tool openSUSE-11.2: New Priority Requester: Mandatory Requested by: m m (mmaher) Description: kaboom is tool for migrating your KDE user settings and data files from KDE 3 to KDE 4. Depending on the options you choose, you may: 1. Use you current KDE 3 settings as initial for KDE 4. 2. Use your existing KDE 4 settings and replace current KDE 3 settings. 3. Merge current KDE 4 settings with current KDE 3 settings (experimental). 4. Start KDE with defaults settings and data. http://pkg-kde.alioth.debian.org/kaboom.html -- openSUSE Feature: https://features.opensuse.org/306350

1 7

[openFATE 305899] Package Locking
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature added by: Will Stephenson (wstephenson) Feature #305899, revision 1, last change by Title: Package Locking Buildservice: Unconfirmed Priority Requester: Important Requested by: Will Stephenson (wstephenson) Description: * Lock a package ** osc co -l checks out and locks * Anyone can unlock a package (to prevent deadlock) but it has to be explicit ** https://build.opensuse.org/project/monitor to show locks and lock owners -- openSUSE Feature: https://features.opensuse.org/305899

1 8

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

29 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305553, revision 21 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 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? -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature changed by: Arvin Schnell (aschnell) Feature #305168, revision 25 Title: default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) 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: Evaluation Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) 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. #3: Stephan Kulow (coolo) (2009-05-08 16:51:21) Matthias, I would think the easiest solution is replacing the current checkbox "use noatime" with "use relatime" and make it default (possibly per product). atime is a major pain for many systems where powersave and co are affected. #4: Matthias Eckermann (mge1512) (2009-05-11 15:52:11) (reply to #3) I am not perfectly happy, as a system crash could invalide the "atime"s with "relatime" switched on; looking for supporting information though, it seems, the broader Linux community is in favour of "relatime" (with remarkable exceptions); thus I propose: * introduce "relatime" as an independend parameter * keep the "noatime" checkbox in YaST * make "relatime" default on SSDs automatically * introduce a generic switch in YaST "defaultrelatime", which can be switched on/off per product * make "relatime" default "on" for the openSUSE product Does that help? #5: Jan Kara (jankara) (2009-05-11 16:33:11) This is a bit separate to how it will all look in Yast but I wanted to point out that in current Linus's tree (going to be 2.6.30) is a patch which changes kernel's default to 'relatime'. So unless we change something, all filesystems on this or newer kernel are going to be mounted as relatime (you have to specify 'strictatime' mount option if you really wish to keep atime). #6: Stephan Kulow (coolo) (2009-05-12 10:36:27) (reply to #5) then we can leave everything as it is actually and the feature is Done once we switch to 2.6.30 #7: Jan Kara (jankara) (2009-05-12 13:08:05) (reply to #6) Yes, the original request will be fulfilled. But I believe it would be good to have a selection in partitioner tool like: "Access time behavior: <relatime|noatime|strictatime>" anyway and make 'relatime' default. Also it is a question how to behave on update - the safest would be to add 'strictatime' to filesystems that don't have any atime setting but realistically it is probably better to ask user whether he agrees to switching to relatime and default to "yes". #9: Stephan Kulow (coolo) (2009-05-12 13:45:51) (reply to #7) completely different feature IMO and way more complex (and definitely over the top of openSUSE 11.2) #10: Duncan Mac-Vicar (dmacvicar) (2009-05-12 14:00:25) (reply to #7) Do we really need this extra options really? Is there a good usecase for it? I don't want to bring something to implementation because it is "good", "cool" or "nice to have". #11: Jan Kara (jankara) (2009-05-12 15:50:33) (reply to #10) User can always edit /etc/fstab by hand so strictly speaking it's not necessary. About the usecase - there really are people who want 'strictatime' for various reasons (well, most often they are just afraid that something can break). From my POV that is enough for substituting that 'noatime' checkbox we have currently with the selection I suggested but I admit I'm not the one who'll have to implement it ;-). Regarding the update - silently changing the behavior of atime seems kind of rough to users to me. At least we should warn them (release notes?) that this is happening and that they can add 'strictatime' to /etc/fstab if they have problems with the change. #12: Andreas Jaeger (a_jaeger) (2009-06-09 15:36:15) (reply to #11) Let's add something to the release notes for those updating - and not do any other changes. + #13: Arvin Schnell (aschnell) (2009-07-29 15:14:15) (reply to #12) + With 2.6.30 in factory this isn't a feature for yast2-storage anymore. + Andreas, if something should be added to the release notes please + assigned to approptiate people. -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 306356] Icons in YaST: Use /usr/share/icons/hicolor/ as a fallback
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature changed by: Katarina Machalkova (kmachalkova) Feature #306356, revision 9 Title: Icons in YaST: Use /usr/share/icons/hicolor/ as a fallback openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Lukas Ocilka (locilka) Partner organization: openSUSE.org Description: YaST icons are expected to be in /usr/share/YaST2/theme/current/icons/ directory but the list of icons is fixed because the current is a symlink to the currently installed and selected theme-directory which is different for openSUSE or SLES. If another (e.g., 3rd party) YaST module wants to add its own icon, it has to put it into the current directory which will change when using another YaST theme. The proposal is simple: If an icon is not found in the current theme, try to use /usr/share/icons/hicolor/ as a fallback. Business case (Partner benefit): openSUSE.org: 3rd party add-ons with YaST modules, Our own add-ons with YaST modules (SMT, OES)... Discussion: #1: Christoph Thiel (cthiel1) (2009-04-20 17:30:28) Makes a lot of sense to me with regard to appliances and custom YaST themes. #2: Katarina Machalkova (kmachalkova) (2009-07-29 13:00:38) Done in yast2-control-center-qt + #3: Katarina Machalkova (kmachalkova) (2009-07-29 13:09:14) + Done also in yast2-libyui and yast2-qt. Instead of one global icon + search path there can now be several search paths and they're traversed + until the correct icon is found. This is done transparently for UIs on + libyui level (for selection-like widgets). + Note I've kept the global search path in mostly for compatibility + reasons, in order not to break Gtk UI (since I don't speak Gtk and + can't adjust the code myself) but I'd like to drop it eventually. Also + icons in IconButton type of widget currently do not work in Gtk, but + that does not matter, as they're not used anywhere in YaST. + Once the Gtk part is settled, we can set this to 'done' -- openSUSE Feature: https://features.opensuse.org/306356

1 0

[openFATE 306356] Icons in YaST: Use /usr/share/icons/hicolor/ as a fallback
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature changed by: Katarina Machalkova (kmachalkova) Feature #306356, revision 8 Title: Icons in YaST: Use /usr/share/icons/hicolor/ as a fallback openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Lukas Ocilka (locilka) Partner organization: openSUSE.org Description: YaST icons are expected to be in /usr/share/YaST2/theme/current/icons/ directory but the list of icons is fixed because the current is a symlink to the currently installed and selected theme-directory which is different for openSUSE or SLES. If another (e.g., 3rd party) YaST module wants to add its own icon, it has to put it into the current directory which will change when using another YaST theme. The proposal is simple: If an icon is not found in the current theme, try to use /usr/share/icons/hicolor/ as a fallback. Business case (Partner benefit): openSUSE.org: 3rd party add-ons with YaST modules, Our own add-ons with YaST modules (SMT, OES)... Discussion: #1: Christoph Thiel (cthiel1) (2009-04-20 17:30:28) Makes a lot of sense to me with regard to appliances and custom YaST themes. + #2: Katarina Machalkova (kmachalkova) (2009-07-29 13:00:38) + Done in yast2-control-center-qt -- openSUSE Feature: https://features.opensuse.org/306356

1 0