July 2009 - openSUSE Features - openSUSE Mailing Lists

[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

[openFATE 306844] In-line spell check in katepart
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature added by: Thijs Heus (thijsdetweede) Feature #306844, revision 1 Title: In-line spell check in katepart openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Thijs Heus (thijsdetweede) Description: http://bugs.kde.org/show_bug.cgi?id=33857 Katepart (i.e., kate, kwrite and most notably kile) finally features inline spellchecking. But since this feature will only arrive in KDE4.4, openSUSE 11.2 won't see it. It seems a shame to let a feature that is so eagerly awaited lie until a year from now. Is it possible to backport it to KDE 4.3.x/openSUSE 11.2? -- openSUSE Feature: https://features.opensuse.org/306844

1 4

[openFATE 306476] Install boot entry configurable in kernel git file
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature changed by: Stephan Kulow (coolo) Feature #306476, revision 9 Title: Install boot entry configurable in kernel git file openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Thomas Renninger (trenn) Description: Provide a file in the kernel git which describes an installation boot entry including: - help/description - specific boot parameters - active on which arch The installation image (e.g. DVD) will then provide these specific boot entries to make it easy for: - kernel developers to add critical boot parameters required for specific HW for booting - users by providing a meaningful help at boot loader start up Currently most important settings that are coming to my mind are: - apic=bigsmp (for i386 machines with a lot cores might require that) - disable Kernel Mode Settings -> disable kernel graphics parts which won't work on all HW if set by default soon The idea originally comes from Bernhard Walle. Steffen and myself discussed that already and agreed that it makes sense to do that. On longterm it would be great to get rid of the "Failsafe" Yast boot loader functionality. This would not be necessary anymore then. This currently totally useless and outdated anyway. With the new approach, soon as one successfully booted an entry from the installation image, these boot options will be the default forever (or manually adjusted). Discussion: #1: Stefan Dirsch (sndirsch) (2009-06-22 10:09:05) I think the X' team' would like to get involved here WRT KMS. Also I believe we still want to have a possibility to detect that the user wants to start the Xserver from installation (usually fbdev driver) instead of the apparently broken native X driver. This was boot param 'x11failsafe' in the past. #2: Thomas Renninger (trenn) (2009-06-22 14:27:39) Yeah, in this case we probably need some advise from the X guys which boot params have to be passed, eventually other extra quirks are needed for KMS, no idea. But in general the responsibility and possibilty to generate/modify extra boot entries and with them passing extra kernel boot parameters and a description when to use them should rely in the kernel teams hands and thus the config file should lie in the kernel repo. Coolo, can you set this fate entry a project manager state, so that we can finally work on that at some time, thanks. #3: Stefan Dirsch (sndirsch) (2009-06-22 14:52:39) Probably the modeset option needs to be used for all relevant KMS capable DRM modules, like i915, radeon. Possibily also radeonhd (still to be implemented) and nouveau (in case it's installed, we don't ship it). So something like this: i915.modeset=0, radeon.modeset=0, radeonhd. modeset=0, nouveau.modeset=0. #5: Andreas Jaeger (a_jaeger) (2009-07-10 11:47:39) I'm a bit confused what you want to do here. What advantage will this bring us? #6: Andreas Jaeger (a_jaeger) (2009-07-14 15:13:04) (reply to #5) Just talked with Thomas: The idea is to safe the information about kernel-parameters as part of the kernel package and let the installation get this information from there - instead of hardcoding it in the installation workflow. Also the kernel would provide different options that the developers think make sense. -- openSUSE Feature: https://features.opensuse.org/306476

1 0

[openFATE 305807] Make cleanup in applications and Control Center
by fate_noreply＠suse.de 29 Jul '09

29 Jul '09

Feature added by: Piotrek Juzwiak (BenderBendingRodriguez) Feature #305807, revision 1, last change by Title: Make cleanup in applications and Control Center openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Piotrek Juzwiak (benderbendingrodriguez) Description: What i find every time very irritating is the idea behind Control Center and applications. It should be clearly differed. After a clean install there are too many configuration tools in the applications browser what makes it difficult to browse (despite having an option to search, of course if You know what You are searching for). Not everyone knows how to clean everything up, in my example most configuration tools are in the Control Center what makes A LOT more room for applications in Application Browser what makes it easier to browse for apps. SO: make a clear distinction of what is a configuration tool and what is an application. -- openSUSE Feature: https://features.opensuse.org/305807

1 6

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

28 Jul '09

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

1 0

[openFATE 306615] My openSUSE
by fate_noreply＠suse.de 28 Jul '09

28 Jul '09

Feature added by: Cornelius Schumacher (cschum) Feature #306615, revision 1 Title: My openSUSE Requested by: Cornelius Schumacher (cschum) Description: Write a portal which integrates all the different openSUSE services and shows a personal view on what's going on in openSUSE. Services to integrate could be the Build Service, openFATE, Bugzilla, openSUSE News, Planet openSUSE, SUSE Studio, Wikis, the software portal, forums, mailing lists, upstream development sites, etc. -- openSUSE Feature: https://features.opensuse.org/306615

1 11