July 2009 - openSUSE Features - openSUSE Mailing Lists

[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