May 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 303535] Use libnetapi to join Active Directory
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303535, revision 23 Title: Use libnetapi to join Active Directory openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 14:56:26 reject reason: Postponing. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Important Requested by: Ralf Haferkamp (rhafer) Description: Starting with 3.2.0 Samba will contain libnetapi, which is a C API providing features required to join an Active Directory Domain. The "Windows Domain Membership" YaST Module should switch to use this API instead of calling the "net" command. This should make the Module much easier to maintain Discussion: #9: Jiri Srain (jsrain) (2008-07-07 13:53:26) Stano, please, postpone. Minimal gain, it would requre to write a new C++ agent, and use code which has not been used before for this purpose. Let's stay with proven method and experiment with a new one for 11.2. #11: Matthias Eckermann (mge1512) (2008-07-14 20:37:06) Ralf and Samba-Team: is this reject acceptable for you - or will this have negative impact on AD integration? #12: Ralf Haferkamp (rhafer) (2008-07-28 11:51:48) (reply to #11) Jim, could you please answer Matthias' question I am not sure if libnetapi does provide anything that we need in SLED10, which is not provided by the "net" command. #13: James McDonough (jmcdough) (2008-07-29 07:22:45) (reply to #12) It is not advisable, but it is acceptable for now. Initially, it will simply mean that we are more exposed to the net command format changes, or any of the possible problems caused by running and interpreting output from external commands. Longer term, it should be done, as any new function will be implemented first through libnetapi, and not necessarily exposed through the net command. -- openSUSE Feature: https://features.opensuse.org/303535

1 0

[openFATE 305869] improve partioning UI during installation
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305869, revision 11 Title: improve partioning UI during installation openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: The partitioning dialog during installation is perceived as confusing (see Bug #461819) . The reasons for confusion are * button labeling * workflow A redesign could provide some improvement. A first idea could be: http://en.opensuse.org/Image:Partitioner_proposal_installation.png References: https://bugzilla.novell.com/show_bug.cgi?id=461819 http://en.opensuse.org/Image:Partitioner_proposal_installation.png Discussion: #1: Kevin Dupuy (kdupuy9) (2009-03-26 00:06:41) I like the proposal so far. Perhaps there could also be some improvements wrt the actual partitioning interface, similar to GParted or the Ubuntu partitioner. This way it's easier for people that need to make a small change to YaST's proposal can do it easily. GParted: http://kajar.files.wordpress.com/2009/02/gparted-gui.jpg Ubuntu: http://1.bp.blogspot.com/_MfwRx_4ERx8/Sa6_M2URLeI/AAAAAAAAAxA/rEcbk5uSrhA/s… #2: Martin Schmidkunz (mschmidkunz) (2009-03-26 16:35:44) (reply to #1) By talking about the "actual partitioning interface" do you refer to the (expert) partitioner module in YaST? (the one with the storage tree on the left pane :-)) There are some improvements planed for this interface. One of them refers to the use of the bar graph. In order to use some of the design ideas proposed by gparted we would need to extend bar graph widget at first (see FATE #303534: Extend BarGraph Widget). -- openSUSE Feature: https://features.opensuse.org/305869

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository exists
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305553, revision 11 Title: zypper: dist upgrade could error out if more than one repository exists openSUSE-11.2: Evaluation 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. -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305660] more options for LDAP browser
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305660, revision 5 Title: more options for LDAP browser - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-05-26 18:25:28 + reject reason: Let's not duplicate a complete ldap browser in YaST. We + need to focus our resources on more important tasks. Priority Requester: Important Requested by: Jiří Suchomel (jsuchome) Description: In YaST LDAP browser, allow: * deleting objects * renaming objects * editing opbejcClass attribute * creating new objects References: https://bugzilla.novell.com/show_bug.cgi?id=443715 + Discussion: + #1: Christoph Thiel (cthiel1) (2009-05-26 18:24:44) + Let's not duplicate a complete ldap browser in YaST. We need to focus + our resources on more important tasks. -- openSUSE Feature: https://features.opensuse.org/305660

1 0

[openFATE 305552] Support in YaST for public directories in encrypted home directories
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305552, revision 7 Title: Support in YaST for public directories in encrypted home directories - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-05-26 18:28:27 + reject reason: Postponed for 11.2. Priority Requester: Important + openSUSE-11.3: Evaluation + Priority + Requester: Important Requested by: Tim Lee (timl33) Description: A follow on feature to #301923. There should be a way in the YaST users module to specify directories to make accessable in an encrypted home directory when the user is not logged in. See bug #446317. I would suggest an editable list of directories to exclude from the encrypted image, with a reasonable set of defaults. Examples of directories to exclude ~/.vacation, ~/.procmail, ~/.forward, ~/public_html and ~/.ssh References: https://bugzilla.novell.com/show_bug.cgi?id=446317 -- openSUSE Feature: https://features.opensuse.org/305552

1 0

[openFATE 304970] YaST UI for pam_mount configuration
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #304970, revision 10 Title: YaST UI for pam_mount configuration openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-12 16:48:23 reject reason: Postponing. Priority Requester: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-05-26 20:24:01 + reject reason: Out of resources for 11.2. Priority Requester: Important Requested by: Jiří Suchomel (jsuchome) Description: See bug https://bugzilla.novell.com/show_bug.cgi?id=347144: user requests a way for configuring pam_mount. We already have feature 300967 for some part, maybe other parts of it could be used in samba-client module. Michael, please check which parts might have sense Relations: - inlcude pam_mount in an up-to-date version and provide a YaST interface for it (novell/bugzilla/id: 347144) https://bugzilla.novell.com/show_bug.cgi?id=347144 Discussion: #1: Michael Calmer (mcalmer) (2008-06-30 11:25:01) Hmm, maybe we should think about a general solution. We use currently pam_mount for encrypted home directiories. Mounting samba shares is requested and now we have a general request to configure pam_mount. The pam_mount configuration is more or less the same like /etc/fstab. It provides all filesystem types which are supported via fstab and some more with special handling from pam_mount directly. The main difference is, that it is possible to have general rules which applies for all users logging-in, groups of users (supporting uid ranges, by guid or guid ranges or group names) and rules which applies only for a single user. For single user configuration a plugin for the users module would be good, but for more general rules a special module would be the best way. Such a module should have an API which can be used by other modules like samba-client to push in special rules needed fo this kind of configuration. -- openSUSE Feature: https://features.opensuse.org/304970

1 0

[openFATE 305551] Document YaST RELAX NG Schema
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305551, revision 6 Title: Document YaST RELAX NG Schema openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Important Requested by: Thomas Schraitle (thomas-schraitle) Partner organization: openSUSE.org Description: According to bnc#455994 (comment #17) Lukas Ocilka suggested to create a FATE entry for this purpose. Background: The YaST DTD for /etc/YaST2/firstboot.xml and the like is outdated and lead to invalid XML files. The DTD is/was rewritten as a RELAX NG Schema but elements, attributes, and attribute values are not documented yet. Business case (Partner benefit): openSUSE.org: * Documented RNG schema supports XML editors in showing tool tips during the writing of a XML file. * WIth the help of XSLT a summary can be created automatically. > reduces costs Discussion: #1: Lukas Ocilka (locilka) (2009-01-16 16:32:28) The XML format of a control file is currently documented at http://forgeftp.novell.com/yast/doc/SL11.1/tdg/inst_in_general_chap.html (generated from manually written docbook file) nevertheless this means that it has to be done at two places at once: the RELAX NG schema and its documentation itself. Having the documentation source insite the RELAX NG schema would halp to keep the documentation in sync. -- openSUSE Feature: https://features.opensuse.org/305551

1 0

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305503, revision 10 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 303859] simple network configuration in 1st stage
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303859, revision 27 Title: simple network configuration in 1st stage openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-09 10:04:08 reject reason: Postponing, out of resources. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Jiří Suchomel (jsuchome) Description: The feature of "Automatic Configuration" has a nice effect of not asking users for accepting all the default settings. However, there's (at least) one setting that is default but still not widely accepted (I think so - at least I change it always): it's the firewall that is automatically running. Wouldn't it be good to have some simple client, only opened from installation proposal upon user's request (so not by default) where could be this option configured? Even better would be "Network" part in Installation summary, with the only setting "Firewall on", which would be a link which value changes on click. References: https://bugzilla.novell.com/show_bug.cgi?id=379149 https://bugzilla.novell.com/show_bug.cgi?id=303859 Discussion: #1: Matthias Eckermann (mge1512) (2008-06-09 23:49:49) An automatically running firewall is great - for the average user. And this even applies in enterprise. I strongly recomment to reject this feature for ALL products: SLES, SLED and openSUSE, but leave it to Federico. Guy, Federico, Michl, Marcus? #2: Jiří Suchomel (jsuchome) (2008-06-10 07:49:31) (reply to #1) Well, I'm not asking for not starting firewall by default. I agree it is good to have it automatically on. But we miss an option to change this during the installation workflow. #3: Michal Svec (msvec) (2008-06-10 11:24:41) (reply to #2) Right, the proposal was to have a simple way, ideally a hyperlink, to disable the firewall, either completely or just for some services (ssh) somewhere accessible during the installation workflow. We should certainly keep the current default of running firewall automatically. #4: Lukas Ocilka (locilka) (2008-06-10 14:51:08) (reply to #3) It's quite easy to add another firewall_proposal client to the fist stage but that one could only provide enable/disable functionality (the default value is set in control file already). On the other hand, opening a firewall for some services couldn't be done as these services are known after packages with service- definitions are installed (firewall services defined by packages). Using other words: In the installed system. This feature is more about specific configuration dialogs providing functionality to Open Firewall for XYZ Service - I think only configuration of users is affected now (samba-client, SLP broadcast reply, ...?). #5: Jiří Suchomel (jsuchome) (2008-06-10 15:03:08) (reply to #4) No, it isn't. This feature is about possibility to either shut down the firewall or open ports for defined (not arbitrary) services (e.g. ssh). No samba, no SLP. It is called simple network configuration in 1st stage. #6: Lukas Ocilka (locilka) (2008-06-10 16:42:14) (reply to #5) Yes I know what is it called, but as I've already written, in first stage, firewall can be only enabled or disabled. No additional servics could be open as they are unknown in that stage. I'm just talking about the limits of the proposed firewall/network client in first stage. The rest is left on particular modules to open ports/services as required by a specific service used in second stage. Services are defined in packages, their ports, names, description. Even SSH has its own definition in openssh package: /etc/sysconfig/SuSEfirewall2.d/services/sshd . This package needen't be installed at all. #7: Jiří Suchomel (jsuchome) (2008-06-11 08:07:35) (reply to #6) And again, I am not requesting any configuration of services in this stage. Basically I want the same thing we have in current network proposal (at the beginning of currently-usually-unused 2nd stage) , where you can shut firewall down and/or open ssh port. If sshd is the problem (but in the time of installation proposal, we know if it is going to be installed or not, so it may be hidden if sshd is not selected for installation) it doesn't have to be there, and it may consist of simple firewall off/on hyperlink. So yes, it is true that firewall_proposal client ...could only provide enable/disable functionality , but this is actually the point of this feature. I should probably also make clear that I'm not requesting any additonal step in the sequence, only the option to be selected from installation summary, just like Installation from Images is enabled (disable) one. #8: Guy Lunardi (glunardi) (2008-06-12 17:34:47) (reply to #7) Could this be served by providing an hyperlink which would open the current network module presented during the normal installation? Like I had made my initial priority, I am pretty neutral on this. I think power users would appreciate the feature but most of our 1-time installation users would not care. I am fine having it if the investment is very small. #11: Jiří Suchomel (jsuchome) (2008-06-13 07:48:43) (reply to #8) Hyperlink yes, but for enabling/disabling, not for full firewall configuration. This is not really possible in 1st stage, see Lukas' comments 4 and 6. #9: Federico Lucifredi (flucifredi) (2008-06-12 18:11:07) Guys, I am not following... why do we want the enable/disable choice in 1st stage? Looks just fine to me as is. Please clarify what's the advantage of allowing the choice earlier. #10: Jiří Suchomel (jsuchome) (2008-06-13 07:47:11) (reply to #9) In previous versions, we had the network configuration proposed which user had to accept, but now the networking is (by default) configured automatically (and this is without debates fine for most users). The old screen with the network configuration had an option disable firewall with one click and this is the thing which I miss now (yes, it is possible to use the old way also in 11.0, but it brings bunch of other configuration options that are correctly done automatically). So, earlier actually means during installation . Of course this is possible to configure after the installation, but just like many other users, I'd like to have the system configured after the system is installed. #12: Federico Lucifredi (flucifredi) (2008-06-13 17:02:08) (reply to #10) okay - I understand. Yes, this is handy, as it saves the need to go through all the config when all one wants to do is remove the fw. _if_ there is a way to include in the early workflow, lets do it. Of course, that may not be the case on "keeping it simple" grounds. #13: Stanislav Visnovsky (visnov) (2008-06-19 13:21:59) (reply to #12) I agree, if we are able to find a reasonable place, would be nice to have. -- openSUSE Feature: https://features.opensuse.org/303859

1 0

[openFATE 300758] Show orphaned packages
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #300758, revision 66 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: JP Rosevear (jproseve) Description: The package manager should learn to show orphanized packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. #11: Karsten König (remur) (2009-01-19 10:09:49) How about using rpmorphan, I agree with flucifredi about the command line idea... http://rpmorphan.sourceforge.net/ And otherwise you could use their system to find orphanized packages and display them in yast but make clear that deleting -all orphanized packages will also delete the ones explicitly installed... (it only detects wether the package fullfiles any requirement...) #12: Ján Kupec (jkupec) (2009-01-19 14:48:38) (reply to #11) I'm not the solver developer, but i'm pretty sure it's easy (and probably more effective) to find the 'leaf' packages (that's what rpmorphan seems to do) using existing solver (see satsolver package). But we don't want to just highlight leaf packages, we want to remove unused packages, that is all leaves minus those explicitly installed. So we will feed the solver with this 'explicitly-installed' information. The package history will be the source of this info for now. Maybe later we find some way to store this info that could be used across tools (e.g. directly in the rpm db). So rpmorphan will be able to use this info as well. #13: Pavol Rusnak (prusnak) (2009-01-19 15:44:26) (reply to #12) Yes, that's good idea. Detecting leaf packages is the first step. Detecting which ones to remove (i.e. not explicitly installed) is the second. I think that rpmorphan shows all leaf packages, but it selects only the ones that start with "lib". If we strictly followed library packaging policy that would do the trick. btw. rpmorphan is packaged in Contrib (http://en.opensuse.org/Contrib) #14: Michal Smrž (ilfirin) (2009-03-07 20:05:22) (reply to #11) I am afraid of using rpmorphan to do this. Cause last time, I tested it, it wants to remove libdvdnav and libdvdcss libraries. This is very bad. It leads to many not advanced users to ask in phorums "Why OpenSUSE is not playing DVDs anymore?" I see many problems this could make. #15: Christoph Thiel (cthiel1) (2009-04-21 15:23:06) We don't have the resources to implementing this. Seems to be a prefect fit for a community project. #17: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-22 07:58:47) Maybe the idea to accomplish this would be simply by using the packages. xml file and diff it. We can already export what packages we got right? So if it would compare the packages.xml before installation and after it would then delete it. There is a problem when installing many packages, they would all have to be "grouped" which pulled which dependencies. -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[openFATE 305285] dictionary and DoS attack protection based using log scanning and dynamic firewall ban
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305285, revision 15 Title: dictionary and DoS attack protection based using log scanning and dynamic firewall ban openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Description: Detailed Description For these attackss, usually the application/service will not allow the attacker to break in, however once a malicious password guess or DoS attack is done, baning the connection for some minutes and then an unban time of several minutes is usually enough to stop a network connection being flooded, as well as reducing the likelihood of a successful dictionary attack. The situation goes this way: - attacker starts a password guess - the system detects Y continuous failed attempts to login in the log file of the service - the system issues an iptables action to block the ip for X minutes. - after X minutes, the ip is allowed again - attacker starts a DoS attack - the system detects Y continuous connections without login - the system issues an iptables action to block the ip for X minutes. - after X minutes, the ip is allowed again Scope To provide an extra option in the firewall which allows to select which services to monitor (usually by looking at patterns in the log file ) and block the ip for a configurable interval once a dictionary attack or DoS is suspected. The option could be as well in the service module (or in both) or even in the specific service configuration module. Usually parameters to configure are the patterns and the actions. Also, YaST should tell the user to install the required packages if this option is enabled. To be defined in the scope is how much configurability is needed. If known services will be protected, or if a generic way to define protection for an arbitrary service is desired. Possible Implementation Fail2Ban provices right now most of the functionality. Provides a service that allows to define jails, a jail is a pattern and an action. A service can have more than one jail. For example the patterns for an ssh DoS attack is different than a dictionary attack on the same service, and the ban times may be different. Fail2Ban provides generic functionality not tied to any specific service and comes with predefined patterns and actions for various popular services as sshd, apache2 http authentication and others. http://en.wikipedia.org/wiki/Fail2ban http://www.fail2ban.org YaST would need to write the configuration about which patterns to use depending on the service to protect, or optionally define patterns for unknown services, same with actions, and start or stop the service depending on this functionality being enabled or not. Test Plan Doing serveral failed attempts on the ssh server should block the user for 3 minutes. Simple testcase. User Experience The functionality should be availabe in a clever location (which can be more than one, for example, firewall, services or the specific module), allowing to turn it on with sane defaults (hopefully provide the defaults fail2ban provides). The user can see the blocked attempts in the logs. Dependencies Using the fail2ban approach would require the fail2ban package, which in turns requires python, available in the openSUSE build service from a community user home project. (home:leonardocf) Contingency Plan None, as the functionality was not available before. Relations: - Preventing Brute Force Attacks With Fail2ban On OpenSUSE 10.3 (url: http://www.howtoforge.com/fail2ban_opensuse10.3) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:50:52) I don't know about the enteprise angle (I need to think), but for the community distro it seems quite a cool feature. + #3: Christoph Thiel (cthiel1) (2009-05-26 18:50:09) + We won't be able to implement this feature in 11.2 within the YaST + teams. Maybe still something for the community? -- openSUSE Feature: https://features.opensuse.org/305285

1 0

[openFATE 303873] Reducing pop ups during installation
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #303873, revision 15 Title: Reducing pop ups during installation openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 11:01:26 reject reason: This can wait. Postponing. Priority Requester: Important openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Desirable Requested by: Martin Schmidkunz (mschmidkunz) Description: Before installing the system the user is asked to confirm various licenses. Each license is presented via pop up. Depending on the selected packages the user might be forced to accept quite a lot of them. This is quite unusable and we should think about how to reduce these. One idea might be: http://en.opensuse.org/Image:Installation_nopopups.png Not for SLES: Furthermore after accepting all these licenses the user has to confirm the installation in an extra pop up. I do not see the necessity for that pop up as users made the experience with other operating systems who do not ask the user for comfirmation (Apple Mac OS, MS Windows, Ubuntu, Red Hat Enterprise Linux, Fedora) that installation means that something will happen to their hard drive. Discussion: #1: Matthias Eckermann (mge1512) (2008-05-15 12:10:27) I agree with and like: http://en.opensuse.org/Image:Installation_nopopups.png But the extra pop-up for "YES, I really want to wipe my harddisk" must remain, as it is a security and safetiness issue. Marking this part of the idea as "Not for SLES". Federico, what is your opinion here? #2: Michael Löffler (michl19) (2008-05-15 12:27:44) Ciaran can you give the view from a legal perspective? #3: Ciaran Farrell (babelworx) (2008-05-16 11:51:38) I like the setup described in the screenshot and believe that it certainly gives the person installing the opportunity to review every license individually. In fact, I'm going to suggest to Patrick Mc Bride that this could be a default license acceptance method as it is far better than what we currently have available (i.e. all or nothing system). I'll ask Christopher De Nicolo for his opinion (from a german legal perspective). #4: Federico Lucifredi (flucifredi) (2008-05-22 15:47:44) I just went through the 11.0 beta 3 workflow, and I am satisfied with the current state. the mock-up is ok, but consider this: while it is true that you get prompted 5 times to approve licenses, if there is something that users are trained to do, in all platforms, is precisely click accept :-) I would say we can proceed with it, but I don't consider it a major issue, and not a usability problem. by the way, the 11.0 install workflow rocks :-) -- openSUSE Feature: https://features.opensuse.org/303873

1 0

[openFATE 120053] Restrict Services By Interface in Inetd YaST module
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #120053, revision 35 Title: Restrict Services By Interface in Inetd YaST module openSUSE-10.3: Rejected by Thorsten Kukuk (kukuk) reject date: 2007-11-21 10:53:32 reject reason: Rewrite postponed to 11.1 Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2006-09-06 16:49:59 reject reason: Affected module will be rewritten for 10.3. Priority Requester: Desirable openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-06-27 14:32:29 reject reason: Out of resources, postponing. Priority Requester: Desirable - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-05-26 20:39:11 + reject reason: Out of resources for 11.2. Existing functionallity in + yast2 firewall should be sufficient. Priority Requester: Desirable Requested by: Martin Vidner (mvidner) Description: Restrict services by interface, e.g. write a generic tcpwrappers library for other yast modules. References: Bug 49800 (https://bugzilla.novell.com/show_bug.cgi?id=49800) Discussion: #1: Lukas Ocilka (locilka) (2006-07-21 08:52:01) This probably depends on feature #100110: Possible Merge With Inetd Editor #2: Jiri Srain (jsrain) (2006-09-06 16:49:22) (reply to #1) Yes, doesn't make much sense if the module(s) will be rewritten... #3: Lukas Ocilka (locilka) (2006-10-23 17:22:49) Martin, please, add more suggestions how to restrict these services if you have some idea. Thanks. #4: Martin Vidner (mvidner) (2006-10-23 17:33:54) Technically: man xinetd.conf: bind Allows a service to be bound to a specific interface on the machine. This means you can have a telnet server listening on a local, secured interface, and not on the external interface. Or one port on one interface can do something, while the same port on a different interface can do something completely different. Syntax: bind = (ip address of interface). -- openSUSE Feature: https://features.opensuse.org/120053

1 0

[openFATE 305634] Debian-like dist-upgrade live system full version upgrade
by fate_noreply＠suse.de 26 May '09

26 May '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305634, revision 114 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Relations: - Wiki page for implementation (url: http://en.opensuse.org/Upgrade/11.2) Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) Isn't that simply a packaging problem? #25: Klaus Kämpf (kwk) (2009-02-02 19:42:45) (reply to #24) In this case, it looks like a packaging problem, indeed. However, we had more complicated upgrade tasks in the past, like dropping devs.rpm and running udev instead. See Removing devs.rpm (http://en.opensuse.org/Software_Management/Upgrade/Devs_Rpm) for a discussion of the problem. #30: Peter Poeml (poeml) (2009-03-10 15:31:10) (reply to #25) Interesting discussion about that particular issue, but simple to solve. What works is keeping devs.rpm, and/or simply rpm -e --justdb it. (It's enough to do so later.) The more complicated issues in the past where a case where the kernel changed its major version, and some networking applications could not start with the (still running) old kernel. Didn't prevent an online upgrade over the network though, and applications could keep running. When skipping several openSUSE versions, and differences have accumulated, in can happen that an upgrade in one step is not possible. It's not possible to upgrade from 9.0 to 10.1 without first updating to 9.1, due to the kernel. These issues are quickly found by experimentation though. Other than that, the most hurting issue during remote upgrades is the difficulty to ensure persistent device naming for NICs, because that is reimplemented / changed with each openSUSE version, the upgrade procedure is not well documented, and funny surprises are the rule, and it often simply doesn't work. Other small hurdles are the increasing modularization of kernel, which can lead to lack of support for chipsets and storage in the initrd, package split-offs (mingetty) that lead to lack of essential components after the upgrade. It pays to make sure that all packages are installed which are in the "minimal" patter of that openSUSE version. And the required but disappeared PAM module locked us out once also... A word to all the non-believers who think that upgrades don't work: I have upgraded dozens of systems remotely during the last decade. All my productive systems are repeatedly upgraded that way since day one. Unfortunately, the tools we have didn't help with this. Apart from using rpm, I started doing this with yum a few years ago (if it works, metadata is available, falling back to rpm if needed). Last year I documented some steps: http://poeml.de/~poeml/10.1-11.0-update/update-11.0.howto. With today's conveniency of virtualization at hand, I actually did an upgrade by experiment with a VM first, to minimize the risk, and documented all the steps. Since I had to upgrade several 10.1 machines, this seemed like a good idea to reduce the risk and save brain energy. The notes from it are a good outcome, too. #26: Klaus Kämpf (kwk) (2009-02-02 19:43:24) (reply to #21) Whats the bug number for this problem ? #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… #27: Federico Lucifredi (flucifredi) (2009-02-04 15:32:01) (reply to #20) this is very helpful, we should look at the bumps that Debian hits while doing this. On a separate note, just tried to "yum upgrade" frlom RHEL 5.2 to RHEL 5.3, and it went without a hitch. There may be something to be gathered from Fedora as well here. #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. #28: Javier Llorente (javierllorente) (2009-03-10 14:08:21) Just a few comments... A few weeks ago, I upgraded one server from 11.0 to 11.1 via ssh using zypper dup. zypper and its related libraries have to be upgraded first in order to avoid problems, especially if the upgrade process is interrupted. Another issue besides the order of the upgrade, would be restarting daemons and dealing with new .conf. Maybe we could check if it has been edited, if not, then automerge it. Some stuff could malfunction due to old config files. We could also have a manual merge option. Another thing... wouldn't it be better to download all the packages at once and install them afterwards instead of downloading/installing package by package? On a side note, I want to say that my upgrade went smoothly (rcpbind wasn't installed but I consider that a small issue). zypper has been improved a lot. It would be great if zypper dup was officially supported as another upgrade method. #29: Peter Poeml (poeml) (2009-03-10 14:35:19) (reply to #28) Regarding config merge on update, I have played with two things. First, the yum plugin called yum-merge-conf, which allows for interactive merging of config files during the upgrade. Works and gets the job done, and could be done in zypper as well, however from my own experience I have to say that it protracts the update more than I sometimes like, and I typically want to do this job in a separate step (after the packages are updated). not protract the update for merging all files. So I rather use another approach, which is a script called rpmresolve (https://build.opensuse.org/package/view_file?file=rpmresolve&package=server… 3Apoeml), which works in a similar way, based on presence of rpmsave/rpmnew files. It opens vim in diff mode, lets you merge and asks you which version you want to keep. Works well for me since years, it just might require refinement of some things of the implementation in a more generic way (e.g. calling $EDITOR with different option than - d). -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 304429] Package cache handling in yast
by fate_noreply＠suse.de 23 May '09

23 May '09

Feature changed by: Rémy Marquis (Spyhawk) Feature #304429, revision 14 Title: Package cache handling in yast openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 21:45:10 reject reason: Postponing. Zypper already provides the functionality. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Done Priority Requester: Important Requested by: Ladislav Slezak (lslezak) Description: Add a possibility to edit 'keeppackages' option in *.repo files. The downloaded packages are not kept by default, but it should be configurable by user. The question is how it should be configurable. My suggestions are a check box or an extra menu item in the repositoru manager (repositories. ycp) . References: https://bugzilla.novell.com/show_bug.cgi?id=393709 Test Case: * check if the installed version of yast2-packager is 2.18.0 or later, with following command: $ rpm -q yast2-packager * add a new Software Repository: open YaST2 -> Software -> Software Repositories -> Add * during adding the new Software Repositories flag "Keep Downloaded Packages" * install or update a package: # zypper install <package name> * check if the package rpm file was saved in local cache (default: /var/cache/zypp/packages/) Discussion: #2: Ladislav Slezak (lslezak) (2009-01-08 13:47:14) Implemented in yast SVN trunk (will be in yast2-packager-2.18.0) There is a new check box, similar to 'Enabled' and 'Autorefresh' check boxes. (bnc#402617) #3: Eduardo Sotomayor (easgs) (2009-05-21 01:01:51) Will it work when installing a package with Yast not zypper command? + #4: Rémy Marquis (spyhawk) (2009-05-23 08:36:50) (reply to #3) + Yes. it is working. As specified above, there is a new checkbox in the + UI for enabling cache handling. -- openSUSE Feature: https://features.opensuse.org/304429

1 0

[openFATE 304429] Package cache handling in yast
by fate_noreply＠suse.de 21 May '09

21 May '09

Feature changed by: Eduardo Sotomayor (Easgs) Feature #304429, revision 13 Title: Package cache handling in yast openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 21:45:10 reject reason: Postponing. Zypper already provides the functionality. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Done Priority Requester: Important Requested by: Ladislav Slezak (lslezak) Description: Add a possibility to edit 'keeppackages' option in *.repo files. The downloaded packages are not kept by default, but it should be configurable by user. The question is how it should be configurable. My suggestions are a check box or an extra menu item in the repositoru manager (repositories. ycp) . References: https://bugzilla.novell.com/show_bug.cgi?id=393709 Test Case: * check if the installed version of yast2-packager is 2.18.0 or later, with following command: $ rpm -q yast2-packager * add a new Software Repository: open YaST2 -> Software -> Software Repositories -> Add * during adding the new Software Repositories flag "Keep Downloaded Packages" * install or update a package: # zypper install <package name> * check if the package rpm file was saved in local cache (default: /var/cache/zypp/packages/) Discussion: #2: Ladislav Slezak (lslezak) (2009-01-08 13:47:14) Implemented in yast SVN trunk (will be in yast2-packager-2.18.0) There is a new check box, similar to 'Enabled' and 'Autorefresh' check boxes. (bnc#402617) + #3: Eduardo Sotomayor (easgs) (2009-05-21 01:01:51) + Will it work when installing a package with Yast not zypper command? -- openSUSE Feature: https://features.opensuse.org/304429

1 0

[openFATE 306327] Add DB2 Express-C
by fate_noreply＠suse.de 20 May '09

20 May '09

Feature changed by: Pascal Bleser (pbleser) Feature #306327, revision 7 Title: Add DB2 Express-C openSUSE-11.2: New Priority Requester: Desirable Requested by: Robert Schweikert (rjschwei) Description: IBM is interested to providing an easy mechanism for users to install DB2 Express C, the free version of DB2. It would be nice if we could add DB2 Express C to the openSUSE non-oss repository. Discussion: #3: Glenn Doig (doiggl) (2009-04-24 06:16:56) http://www-01.ibm.com/software/data/db2/express/ http://www-01.ibm.com/software/data/db2/express/download.html + #4: Pascal Bleser (pbleser) (2009-05-20 22:00:05) + Why not, let's go for it. If IBM wants to see openSUSE as a vehicle to + drive the adoption of their products, even if not opensource, and as + long as it doesn't affect the license/EULA/redistribution of the + distribution itself, I don't see any reason not to support that + initiative. + IBM can choose to either have it in the non-OSS repository, or host it + in a repository of their own, with openSUSE builds. + What is involved on our side of things ? -- openSUSE Feature: https://features.opensuse.org/306327

1 0

[openFATE 306444] change parted to use Hardware suggested sectors per track
by fate_noreply＠suse.de 19 May '09

19 May '09

Feature added by: Dean Giles (dgiles) Feature #306444, revision 1, last change by Title: change parted to use Hardware suggested sectors per track openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Dean Giles (dgiles) Description: parted creates partitions which are automatically assigned 63 sectors per track. Hardware, such as HP raid devices, advertise that they want 32 sectors per track. It advertises that through ioctl HDIO_GETGEO. fdisk can utilize the hardware reported sectors per track. parted needs to be changed to do the same. See bug # 501152. Dean -- openSUSE Feature: https://features.opensuse.org/306444

1 1

[openFATE 305588] kdump support for autoyast installation
by fate_noreply＠suse.de 18 May '09

18 May '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305588, revision 11 Title: kdump support for autoyast installation openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Stefan Fent (sfent) Description: In SLES11 it is possible to add an autoyast section for kdump to the autoyast.xml file. This does not work in openSUSE11.1. Please add support for this in openSUSE as well. See bug #456707 for reference. + Discussion: + #2: Jozef Uhliarik (juhliarik) (2009-05-18 16:54:53) + added kdump support for autoyast installation to trunk. changes only + for control file in installation. the feature will be available with + package yast2-installation 2.18.15. IMHO it is done -- openSUSE Feature: https://features.opensuse.org/305588

1 0

[openFATE 306397] Use VFS cache directly for reads in NSS
by fate_noreply＠suse.de 15 May '09

15 May '09

Feature changed by: Rémy Marquis (Spyhawk) Feature #306397, revision 2 Title: Use VFS cache directly for reads in NSS Requested by: Paul Taysom (taysom) Description: Greg Pachner suggested that we try to satisfy NSS read requests straight from the Linux cache without going into NSS. This means not getting the NSS spinlock to satisfy a read operation. Since almost 40% of the NetBench requests are reads (but not time), this looked like a good bet. I implemented this approach (it has some hacks and is not of the level of quality to be checked in). Results: 8 Processor, 32 bit NetBench went from 720 to 836 for the peak, a gain of 15% 2 Processor, 32 bit NetBench went from 559 to 578 for the peak, a gain of 3% This is a change we want to consider for OES-3. Way too risky for Sp2. NSS does not currently check and update all the page status bits to make this fully work, have to study interactions with zAPIs, and changes the semantics of NSS for pages being modified. You can now read a page while it is being modified. Both the Traditional File System and all Unix file systems have this attribute but it is a change for NSS. + Discussion: + #1: Rémy Marquis (spyhawk) (2009-05-15 17:34:36) + Duplicate of Feature #306398 -- openSUSE Feature: https://features.opensuse.org/306397

1 0

[openFATE 306436] Filter for Leaf Packages in Software Management
by fate_noreply＠suse.de 15 May '09

15 May '09

Feature changed by: Rémy Marquis (Spyhawk) Feature #306436, revision 3 Title: Filter for Leaf Packages in Software Management openSUSE-11.2: New Priority Requester: Mandatory openSUSE-11.3: New Priority Requester: Mandatory Requested by: Berthold Gunreben (azouhr) Description: I'd like to see a new Filter in the Software Management of YaST that enables the user to see "Leaf" packages that do not provide functionality needed by other packages. This would make it easier for customers to remove unneeded packages from the system. + Discussion: + #1: Rémy Marquis (spyhawk) (2009-05-15 16:50:20) + Strongly related to Feature 300758 (orphaned packages). To be marked as + a duplicate. + See https://features.opensuse.org/300758 + -- openSUSE Feature: https://features.opensuse.org/306436

1 0

[openFATE 306354] OSC under Windows
by fate_noreply＠suse.de 15 May '09

15 May '09

Feature added by: andrea florio (anubisg1) Feature #306354, revision 1, last change by Title: OSC under Windows Buildservice: Unconfirmed Priority Requester: Important Requested by: andrea florio (anubisg1) Description: i think that port OSC under windows will be really usefull, everybody know what osc is, but use it under windows can allow me and lots of developer/packager to work on packages even if they are running windows for any reason -- openSUSE Feature: https://features.opensuse.org/306354

1 8

[openFATE 302485] sync GPT and MBR on MacBook (mactel)
by fate_noreply＠suse.de 13 May '09

13 May '09

Feature changed by: Lars Vogdt (lrupp) Feature #302485, revision 32 Title: sync GPT and MBR on MacBook (mactel) openSUSE-10.3: Rejected by Stephan Kulow (coolo) reject date: 2007-10-01 12:11:18 reject reason: not done from what I heared Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-04-28 09:46:04 reject reason: lacking parted maintainer for the moment Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Done Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Done Priority Requester: Mandatory Requested by: Ruediger Oertel (oertel) Description: on multiboot setups on MacBooks and other mactel machines, using a combination of GPT and MBR is pretty common (and necessary if you either want to use grub or are also using Windows) for installation on these machines we need to offer a way to sync the GPT to the MBR whenever a change to the GPT is made. There exists a patch for parted to do just this (see bugzilla#220839) and also the sources of refit (refit.sourceforge.net, tool gptsync). Relations: - GPT partitioning and boot support (feature/id: 303026) - fully support disks with GPT (feature/id: 303924) Discussion: #1: Stephan Kulow (coolo) (2007-08-01 12:37:33) sounds like a dataloss we should fix for 10.3 too #2: Edith Parzefall (emapedl) (2007-08-01 17:42:46) We need to find out more about what actually needs to be done, before we can consider making an attempt for 10.3 despite the approaching deadline. #3: Edith Parzefall (emapedl) (2007-08-07 11:53:32) There's not enough time left, please reject for 10.3. #4: Ruediger Oertel (oertel) (2007-11-06 12:29:36) for reference, the patch for parted is in bug#220839. This patch adds the method "map_gpt_to_msdos" to parted and was written by Olaf Hering and discussed on the parted mailing list in May 2007. #5: Duncan Mac-Vicar (dmacvicar) (2008-02-04 21:29:52) Olaf, you wrote the patch, can you please describe us what is exactly needed so YaST makes this kind of configuration to work? There is little knowledge about this situation and we imagine adding the patch to parted is not the only required step. Some additional code in YaST and while setting up the bootloader might be required. Do you know about it? #6: Olaf Hering (olh) (2008-02-18 10:04:25) (reply to #5) There are comments in the patch. Once the GPT partitioning is done, map one GPT partition to a primary msdos partition. yast2-storage knows what the boot partition is, so it can force the mapping. #7: Arvin Schnell (aschnell) (2008-04-03 17:11:26) Duncan asked me to summarise the task for implementation: 1) Include parted patch "parted.msdos-on-gpt.patch". Thomas saw the risk of breaking parted by this. Issue for parted maintainer (we have none). 2) Add new calls to parted to establish the mapping from GPT to MSDOS disk labels. Issue for yast2-bootloader and/or yast2-storage. 3) Fix bootloader config to not call "parted ... boot on" when it's already on. Should fix the update problem Rudi has. Issue for yast2- bootloader. AFAIS not required with patched parted. #8: Duncan Mac-Vicar (dmacvicar) (2008-04-14 11:43:17) Coolo, points 1 and 3 call for reject until bootloader situation and parted one is better. #9: Joachim Plack (jplack) (2008-04-28 12:30:48) michl@ : AFAIK The MacBooks are to date not handled as a supported platform. But they should be last but not least due to there pretty wide spread of that thingy. Please check, define and prioritize. Thanks. BTW there are some booting issues involved #10: Michael Loeffler (sprudel24) (2008-04-28 13:36:54) (reply to #9) That's a clear "nice to have" feature. Needed ressources and involved risks need to be low. #11: Stephan Kulow (coolo) (2008-06-12 12:39:54) (reply to #10) I'm not so sure about this. Depending on what market you look at, you get a market share of 10 - 50 percentage. I didn't fail to notice that Saturn Fürth's laptop departement is basically built around macbooks. #12: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:21:19) Please reject for 11.0. All resources allocated with mandatory features already. #13: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:46:29) (reply to #12) meant SLE11/openSUSE11.1 #14: Alexander Graf (algraf) (2008-08-22 19:54:25) (reply to #13) For openSUSE 11.1 / SLES11 it's done already. I checked in a patch for parted a while ago. #15: Stephan Kulow (coolo) (2009-04-22 14:22:43) (reply to #14) opening to openfate to have a link + #16: Lars Vogdt (lrupp) (2009-05-13 12:43:12) (reply to #14) + For me it doesn't look like "done already". + I've a MacBook Pro here and tried to install openSUSE 11.1 without + success. FYI: I'm using rEFIt as "bootloader" here - and after each + installation, rEFit tells me that the MBR and GPT is out of sync and + can't be repared. + With the older openSUSE (10.3) it works with this workaround: + http://en.opensuse.org/Installation_on_MacBook_Pro_Intel_(x86) <-- grub + is not installed + Sadly I need the MacBook for my work, but if you can't find another + one, I can run a backup and reproduce my problems for you. -- openSUSE Feature: https://features.opensuse.org/302485

1 0

[openFATE 305296] Easy Way to Disable Beagle Completely During Installation
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: andrea florio (anubisg1) Feature #305296, revision 80 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #26: Peter Nixon (peternixon) (2009-03-11 20:39:01) (reply to #3) +1 #29: Pedro Veloso (pedrodh) (2009-04-01 22:18:05) (reply to #26) Totally agree #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) I agree with everything you said, but you must realize I/we aren't arguing against search. We're arguing against beagle. I personally use google desktop search on a daily basis. And it works well. I assume that it does all its work when I'm not physically using the computer (a policy that is ideal for desktop usage). I'm not advocating its inclusion (primarily license reasons and kde integration reasons) but you should see that I'm not against a search or anything like that. Beagle on the other hand, I've tried to give it a fair shot a few times. To see if it has improved (something I will admit Banshee has done). But its *always* problematic. Something that is echoed daily on IRC and the mailing lists. The firefox extension causes huge amounts errors and slow downs. The actual search program maxs out the CPU. IO brings the computer to a crawl when I need to get work done etc. It's just not pretty. So if Beagle works well, I'd love to use it. But it doesn't and shouldn't be included. Put it this way. I would really like to see kernel initialization of graphics devices. However, until it's finished and works properly -- I think we'd both agree that it shouldn't be on our systems. I know it's not a good test for everything, but have you noticed how many other desktop distros have chosen to include beagle? #17: Sebastian Rösgen (palimpseste) (2009-02-19 18:16:48) (reply to #16) Ok, I see your point. Perhaps beagle is indeed not a good solution and I was too narrow minded to realize it. (Though I haven't experienced the CPU problems anymore for about one year, I suppose you are right). Especially since the development of beagle has come to a crawl (the last release: 0.3.9 was released about four weeks ago but it needed nearly half a year to be released and contains only some mere bug fixes). I think, I am going to open a new feature request in openFate. If you (and the other guys) are not against desktop search, but instead against beagle, it could be interesting to discuss why Tracker (http://projects.gnome.org/tracker/index.html) should not become a replacement for beagle. Especially since KDE has now Strigi as a core component. So one can get rid of beagle and use some "quasi native" tools for desktop search (namely "strigi" and "tracker") on Gnome and, respectively, KDE. Anyway, thanks for your reply and the discussion. #18: Sebastian Rösgen (palimpseste) (2009-02-19 18:23:53) (reply to #17) Hm, as it seems I cannot open such a request. Wonderful! So perhaps somebody has read this discussion and might be so kind to at least evaluate the request and "perhaps" might open a new feature request concerning the replacement of beagle by Tracker (which is a Gnome Desktop search, but since KDE has already its own Desktop search this should not be that problematic... I hope) And before somebody asks: no I will not file a feature request via bug tracking system. Those usually take weeks or even months before they are answered/evaluated/discussed etc... #19: Federico Lucifredi (flucifredi) (2009-02-19 16:52:12) (reply to #18) Hello Sebastian - I do not take the thread as being "against desktop search", which is a great feature, or against Beagle, which I personally run. The decision is only to have Beagle not be running by default out of the box, but to have it installed and ready. The first time a search is performed, we ask. Users who want desktop search select to run it, and those who are more "frugal" in terms of CPU do not. I am running a 3 year old laptop, and Beagle is running just fine for me. I suspect that's the case for a lot of people. But it is still a good idea to ask for a choice. #20: Eric Springer (erikina) (2009-02-22 03:03:55) (reply to #17) 100% agree. I think tracker/strigi make wonderful replacements. :) #22: andrea florio (anubisg1) (2009-02-25 00:40:51) (reply to #20) indeed... beagle is to heavy, traker instead, is simply wonderful! #23: Barbara Hudson (barbie_h) (2009-03-04 02:22:21) (reply to #15) I was going to vote in favour of the request, because I've been bitten by beagle bringing machines to a crawl many times, but one thing I've noticed is that, as people move to dual / quad -core machines, it's no longer a big issue. I'm not saying ignore the memory and resource problems - just that even laptops nowadays can run plasma and beagle and still feel responsive. The current system, where it notifies you when it does the initial indexing, is a lot better than the computer slowing to a crawl on a fresh install and people wondering why openSUSE is soooo slow. #21: Stanislav Visnovsky (visnov) (2009-02-24 09:10:56) Coolo, I believe this should be done via patterns. #24: Stephan Kulow (coolo) (2009-03-04 11:52:23) (reply to #21) having a desktop search easy to enable sounds like a good to have feature, so I wouldn't simply remove the package from install. But it doesn't make sense on a KDE4 desktop (and it's not there in 11.1 afaik) and it doesn't have to be running by default for GNOME either. But this is something for the beagle maintainers to decide. #25: Stephan Kulow (coolo) (2009-03-04 11:53:33) (reply to #24) that is: it should be off by default (seeing all the votes). But if it's worth to make it easier to turn it on than it is, I leave to those that know. But the solution to enable it, should be within the desktop. #27: Jan Engelhardt (jengelh) (2009-03-16 18:03:00) Less than "easy way to disable beagle completey during installation" it should even be "disable beagle by default", thank you. #28: Marcel Müller (open_assistant) (2009-03-16 20:32:45) great idea, especially to my slowly pc #30: Gabriel Stein (gabrielstein) (2009-04-03 21:15:44) Totally Agree. I just post on my blog, and I will pay 5 pints of Guinness to the great developer which will do that amazing thing. #31: john andersen (jsamyth) (2009-04-16 20:22:51) I agree Beagle should be an optional item, not installed by default.   There, I've said it.   But an alternative might be to install it and restrict it't indexing BY DEFAULT to the user's home directory, (and perhaps the user's mail spool), and hava a configuration window that allows adding additional directories. That is a feature that might make it more palletable.  But realistically, when this many people arrive at a Future Feature site begging and pleading for a package to dropped from a normal installation you should assume there are some serious flaws with that package.  This site should be about new and improved features we would all like to see, but instead this thread is focused on something that has been rammed down our throats for way too many releases, and which has historically been difficult to remove.   Side issue: Unless you are a Linux Developer there is no point in having it index the entire hard drive.  Your average user has no need of these areas, and experienced users already know where things are, so a generalized indexer that searches the entire disk is a solution looking for a problem. #32: jean-christophe baptiste (phocean) (2009-04-27 11:28:48) Ok for those who want to get an easy way to disable Beagle. But it should be activated by default. I am using Beagle intensively (on Gnome) and I have never got a problem with it. It just rocks and a huge time saver to me. Maybe my hardware is just not obsolete (Core 2 duo laptop)... I think it is the kind of killer app good to show off and that can bring more new users. + #33: andrea florio (anubisg1) (2009-05-12 20:04:51) (reply to #32) + you are luky then.. beagle on my pc make them very very slower, it + should be disabled by default, if you need it, then you insta/activate + it -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305268] Refactor bootloader UI
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305268, revision 9 Title: Refactor bootloader UI - openSUSE-11.2: Candidate + openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Jiri Srain (jsrain) Description: In order to simplify maintenance, allow to fix some bugs and also use more flexibility of YaST UI, the user interface of the bootloader module should be rewritten to YCP instead of using generator with limited possibilities. Discussion: #2: Federico Lucifredi (flucifredi) (2009-01-26 20:45:53) prioritizing cleanup task as per plan. #3: Stanislav Visnovsky (visnov) (2009-02-02 13:11:26) Jiri, please, document the planned changes and provide a link for the feature. #7: Jozef Uhliarik (juhliarik) (2009-05-12 16:46:32) Refactoring yast2-bootloader UI is done. It is possible that it will be little modified later but the basic goal is done. -- openSUSE Feature: https://features.opensuse.org/305268

1 0

[openFATE 305268] Refactor bootloader UI
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Jozef Uhliarik (juhliarik) Feature #305268, revision 8 Title: Refactor bootloader UI openSUSE-11.2: Candidate Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Jiri Srain (jsrain) Description: In order to simplify maintenance, allow to fix some bugs and also use more flexibility of YaST UI, the user interface of the bootloader module should be rewritten to YCP instead of using generator with limited possibilities. Discussion: #2: Federico Lucifredi (flucifredi) (2009-01-26 20:45:53) prioritizing cleanup task as per plan. #3: Stanislav Visnovsky (visnov) (2009-02-02 13:11:26) Jiri, please, document the planned changes and provide a link for the feature. + #7: Jozef Uhliarik (juhliarik) (2009-05-12 16:46:32) + Refactoring yast2-bootloader UI is done. It is possible that it will be + little modified later but the basic goal is done. -- openSUSE Feature: https://features.opensuse.org/305268

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Jan Kara (jankara) Feature #305168, revision 23 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. -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 306403] KOffice 2.1 in 11.2
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Stephan Binner (Beineri) Feature #306403, revision 3 Title: KOffice 2.1 in 11.2 openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Jean Cayron (jeancayron) + Developer: Stephan Binner (beineri) Description: KOffice 2.1 will be released in november 2009, at the same time than openSUSE 11.2 ( see release plan (http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.1/Release_Plan) ). Since the 2.0 will not be feature complete, it would be great for KDE4 integration to have the latest version on the official repositories (maybe do as Firefox the RC with later update). Let make the people choose their Office Suite. -- openSUSE Feature: https://features.opensuse.org/306403

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305168, revision 22 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". -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Stephan Kulow (coolo) Feature #305168, revision 21 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) -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 305588] kdump support for autoyast installation
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Jiri Srain (jsrain) Feature #305588, revision 10 Title: kdump support for autoyast installation - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Stefan Fent (sfent) Description: In SLES11 it is possible to add an autoyast section for kdump to the autoyast.xml file. This does not work in openSUSE11.1. Please add support for this in openSUSE as well. See bug #456707 for reference. -- openSUSE Feature: https://features.opensuse.org/305588

1 0

[openFATE 305588] kdump support for autoyast installation
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Stanislav Visnovsky (visnov) Feature #305588, revision 9 Title: kdump support for autoyast installation openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Stefan Fent (sfent) Description: In SLES11 it is possible to add an autoyast section for kdump to the autoyast.xml file. This does not work in openSUSE11.1. Please add support for this in openSUSE as well. See bug #456707 for reference. -- openSUSE Feature: https://features.opensuse.org/305588

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Jan Kara (jankara) Feature #305168, revision 18 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". -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Stephan Kulow (coolo) Feature #305168, revision 17 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 -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 304429] Package cache handling in yast
by fate_noreply＠suse.de 12 May '09

12 May '09

Feature changed by: Holger Sickenberg (holgisms) Feature #304429, revision 11 Title: Package cache handling in yast openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 21:45:10 reject reason: Postponing. Zypper already provides the functionality. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Done Priority Requester: Important Requested by: Ladislav Slezak (lslezak) Description: Add a possibility to edit 'keeppackages' option in *.repo files. The downloaded packages are not kept by default, but it should be configurable by user. The question is how it should be configurable. My suggestions are a check box or an extra menu item in the repositoru manager (repositories. ycp) . References: https://bugzilla.novell.com/show_bug.cgi?id=393709 Test Case: * check if the installed version of yast2-packager is 2.18.0 or later, with following command: $ rpm -q yast2-packager * add a new Software Repository: open YaST2 -> Software -> Software Repositories -> Add * during adding the new Software Repositories flag "Keep Downloaded Packages" - * update a package: # zypper update -t <package name> + * install or update a package: # zypper install <package name> * check if the package rpm file was saved in local cache (default: /var/cache/zypp/packages/) Discussion: #2: Ladislav Slezak (lslezak) (2009-01-08 13:47:14) Implemented in yast SVN trunk (will be in yast2-packager-2.18.0) There is a new check box, similar to 'Enabled' and 'Autorefresh' check boxes. (bnc#402617) -- openSUSE Feature: https://features.opensuse.org/304429

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 11 May '09

11 May '09

Feature changed by: Jan Kara (jankara) Feature #305168, revision 16 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). -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 306408] blah
by fate_noreply＠suse.de 11 May '09

11 May '09

Feature changed by: Michael Löffler (michl19) Feature #306408, revision 9 Title: blah openFATE: Rejected by Hendrik Vogelsang (hennevogel) reject date: 2009-05-07 16:53:14 reject reason: done testing Priority Requester: Important Info Provider: Heidi Lahtinen (chrysantine) Requested by: Hendrik Vogelsang (hennevogel) Description: This is a test feature. Discussion: #1: Hendrik Vogelsang (hennevogel) (2009-05-07 16:09:14) please make a comment #2: Hendrik Vogelsang (hennevogel) (2009-05-07 16:19:52) this is a comment #3: Hendrik Vogelsang (hennevogel) (2009-05-07 16:34:47) (reply to #2) why? #4: Hendrik Vogelsang (hennevogel) (2009-05-07 16:45:19) (reply to #3) hrrrmmmm + #5: Michael Löffler (michl19) (2009-05-11 16:03:02) + Henne, there is something important missing. -- openSUSE Feature: https://features.opensuse.org/306408

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 11 May '09

11 May '09

Feature changed by: Matthias Eckermann (mge1512) Feature #305168, revision 15 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? -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 306416] Add additional users and roles.
by fate_noreply＠suse.de 11 May '09

11 May '09

Feature added by: Joe Harmon (jaharmon) Feature #306416, revision 1, last change by Title: Add additional users and roles. openFATE: Unconfirmed Priority Requester: Mandatory Requested by: Joe Harmon (jaharmon) Description: We have several managers that are running other operating systems other than Linux. The webFATE tool was a good answer to this issue but the problem is that they can only add themselves to a fate request. We need the ability to add other people to the fate request since the fate client is not available on platforms other than Linux. -- openSUSE Feature: https://features.opensuse.org/306416

1 1

[openFATE 303534] Extend BarGraph Widget
by fate_noreply＠suse.de 10 May '09

10 May '09

Feature changed by: Marc Telesha (mtelesha) Feature #303534, revision 28 Title: Extend BarGraph Widget openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Arvin Schnell (aschnell) Requested by: Matthias Eckermann (mge1512) Description: The latest mockups for the partitioner contain an BarGraph with additional features: * legend * several areas with same color/legend * a bit small (maybe not so important) Here is a picture (http://w3.suse.de/~aschnell/bg2.png) from the mockup. Relations: - Enhance partitioner to be more user friendly (novell/bugzilla/id: 390213) https://bugzilla.novell.com/show_bug.cgi?id=390213 - Graphical Display of Hard Disk partitions (novell/bugzilla/id: 414322) https://bugzilla.novell.com/show_bug.cgi?id=414322 - Blog Comment praising GParted (url: http://lizards.opensuse.org/2009/03/06/context-menus-in-yast-partitioner/#c…) Discussion: #1: Federico Lucifredi (flucifredi) (2008-06-13 15:15:21) Stano, if we need it it is of course M. Let me know, I just have no business reasons, this is entirely an engineering decision. #2: Stefan Hundhammer (sh-sh-sh) (2008-06-17 15:29:07) What's wrong with using the _existing_ widget with its existing features? #3: Stanislav Visnovsky (visnov) (2008-06-17 15:54:05) Agreement is that this is not needed. #4: Katarina Machalkova (kmachalkova) (2009-02-25 16:43:41) Can we please re-consider this for openSUSE 11.2 ? Some visualization of used/free space ratio on the disk/partition, or the whole disk layout in the partitioner overviews would be nice. The problem (not the only one) with current bar graph widget is that if some portion of the graph becomes too small, the text on it is no longer readable. A legend of the graph (as depicted above) would help a lot, but at the very minimum, some tooltips over the graph parts could be added #5: Michael Löffler (michl19) (2009-03-25 17:27:12) (reply to #4) It looks still like an engineering decsion. Stano please re-consider or reject ;-) #6: Arvin Schnell (aschnell) (2009-03-25 17:53:24) (reply to #5) I don't understand why this should be an engineering decision. This feature will directly influence what the users see. It's not a detail hidden deep in source code that makes geeks say "wow" if they should find it while being bored to death. This is a feature users are constantly asking for! #11: Jean-Daniel Dodin (jdd_sysop) (2009-04-08 20:53:33) gparted is much friendly than YaST. shame. jdd #12: FERNANDO RUBEN ESPINOSA RAMIREZ. (fersito) (2009-04-09 04:01:51) You must to do what ever you want Katarina so in order to learn like myself.-fernando (from Leòn GTO. Mexico)greetings. #13: Duncan Mac-Vicar (dmacvicar) (2009-04-09 11:03:22) (reply to #12) This is even a fake email. Final-Recipient: rfc822; ferub(a)att.net.mx Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host mailin-02.mx.aol.com[64.12.137.89] said: 550 MAILBOX NOT FOUND (in reply to RCPT TO command) + #14: Marc Telesha (mtelesha) (2009-05-10 08:03:28) + Persoanlly I used a LiveCD of Parted Parted (Gpartitioner) before + installing OpenSUSE everytime. It is much easier to do it this way when + setting up a dual booting computer.I really think if it had a better + GUI for partitions it would make this partitioning easier for people to + understand, especially people giving Linux a try.-Marc -- openSUSE Feature: https://features.opensuse.org/303534

1 0

[openFATE 305168] default to relatime
by fate_noreply＠suse.de 08 May '09

08 May '09

Feature changed by: Stephan Kulow (coolo) Feature #305168, revision 14 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: New + 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. -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 306273] send email notification to infoprovider
by fate_noreply＠suse.de 08 May '09

08 May '09

Feature added by: Michael Löffler (michl19) Feature #306273, revision 1, last change by Title: send email notification to infoprovider openFATE: Unconfirmed Priority Requester: Important Requested by: Michael Löffler (michl19) Description: If someone is set a infoprovider for a feature he/she can see this only through checking a feature once in a while or by following the opensuse-features mailing list. This not efficient and will in many cases result in no information by the infoprovider as he/she never get knowledge that some information is requested. Use Case: Someone created a feature but information is missing. If he/she can be informed by an email that there is some information missing the feature handling will improve a lot. -- openSUSE Feature: https://features.opensuse.org/306273

1 7

[openFATE 304429] Package cache handling in yast
by fate_noreply＠suse.de 08 May '09

08 May '09

Feature changed by: Holger Sickenberg (holgisms) Feature #304429, revision 10 Title: Package cache handling in yast openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 21:45:10 reject reason: Postponing. Zypper already provides the functionality. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Done Priority Requester: Important Requested by: Ladislav Slezak (lslezak) Description: Add a possibility to edit 'keeppackages' option in *.repo files. The downloaded packages are not kept by default, but it should be configurable by user. The question is how it should be configurable. My suggestions are a check box or an extra menu item in the repositoru manager (repositories. ycp) . References: https://bugzilla.novell.com/show_bug.cgi?id=393709 + Test Case: + * check if the installed version of yast2-packager is 2.18.0 or later, + with following command: $ rpm -q yast2-packager + * add a new Software Repository: open YaST2 -> Software -> Software + Repositories -> Add + * during adding the new Software Repositories flag "Keep Downloaded + Packages" + * update a package: # zypper update -t <package name> + * check if the package rpm file was saved in local cache (default: + /var/cache/zypp/packages/) Discussion: #2: Ladislav Slezak (lslezak) (2009-01-08 13:47:14) Implemented in yast SVN trunk (will be in yast2-packager-2.18.0) There is a new check box, similar to 'Enabled' and 'Autorefresh' check boxes. (bnc#402617) -- openSUSE Feature: https://features.opensuse.org/304429

1 0

[openFATE 302306] Reorganization of YaST control center
by fate_noreply＠suse.de 08 May '09

08 May '09

Feature changed by: Karl Eichwalder (keichwa) Feature #302306, revision 57 Title: Reorganization of YaST control center openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-03 17:08:02 reject reason: Postponing, we are running out of time. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-25 15:09:31 reject reason: Needs more discussion. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-07-18 18:56:09 reject reason: postponing as per engineering's request. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Martin Schmidkunz (mschmidkunz) Description: As many users (even the experienced ones) find the current organization of YaST modules confusing a reorganization is needed. We have conducted a usability study where experienced users sorted the YaST modules. So I would really ask to take advantage of these data. You find the data and some thoughts about a possible re-categorization on: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The reorganization would affect the sorting and presentation, some labeling issues, the use of a consistent icon set, the use of tool tips and an enhancment of search One possible solution would be to organize it similar to the GNOME configuration center: I already heard that it might be mandatory to present AppArmor as an extra section (which in my opinion would be not advisable from a usability perspective, but if it is mandatory, then we have to add it as an extra section). I also thought that some YaST modules (e.g. keyboard, mouse, DNS, Hostname) are doublicated but it turned out, that this makes sense for SLES. Still I suggest combining the modules "user management" and "group management" into a single module called "User and Group Management". This makes sense because opening "user management" and "group management" opens the same module but only show a different view. Documentation Impact: This would require a lot of changes throughout the manuals. Discussion: #1: Tanja Roth (ta-ro) (2007-05-30 14:33:36) Would a reorganization apply to both KDE and GNOME desktop, then? Whatever a new YaST structure would look like, from a doc perspective it would be important that YaST structure and appearance are in sync for both desktops as we strive to use a "common doc base" for both desktops whereever possible to reduce efforts and costs. As reorganization of YaST would require many changes throughout our manuals, we cannot afford to additionally maintain different "flavors" of YaST chapters for KDE/GNOME. Apart from that, consistent structure and appearance of YaST in both desktops would also be a benefit for users. #2: Stanislav Visnovsky (visnov) (2007-06-12 11:40:45) Sigi, is the card study finished now? Where can we find the results? #3: Martin Schmidkunz (mschmidkunz) (2007-06-12 13:58:58) > Would a reorganization apply to both KDE and GNOME desktop, then? Yes. Exactly for the reasons you named, Tanja :-) By the way, a reorganization of YaST control center already took place in SLES 10 SP1. This solution is similar to what Sigi and I suggested. Perhaps it would be a good idea to take the YaST control center as it is in SLES 10 SP1, improve it a little and implement its design into all our products. What do you think about that? #4: Stanislav Visnovsky (visnov) (2007-06-12 14:00:46) (reply to #3) There was no reorganization for SLE10 SP1. The only change was introduction of slab-based GNOME control center for YaST. The categorization, description and module lists did not change and are shared between KDE and GNOME control centers. #5: Martin Schmidkunz (mschmidkunz) (2007-06-12 18:01:19) I am sorry for a missunderstanding. I meant that we should take the current "GNOME control centre" - like design of the YaST control centre in SLES 10 SP 1 as a base for a redesign of the YaST control centre in our other products. Additionally to that, we should discuss (and perform) a reorganization of modules. #7: Federico Lucifredi (flucifredi) (2007-06-29 17:59:43) (reply to #5) This is worth pursuing, I am no UX expert, but if we can make it easier for users to find things, we should. A reorganization should be well thought-out, so that we break the existing habits *only once*, we should not be reshuffling things too often. #8: Siegfried Olschner (sdolschn) (2007-07-03 12:35:30) The results of the the cardsort study are available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study The subjects (N=~30) have been "Experts", so you can transfer the results to a new openSUSE YaST Control Center. The cluster trees with 2 different statistical options show only one difference: - ISDN, Modem, DSL, Network => Hardware - ISDN, Modem, DSL, Network => Network see http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Illustrative_M… I'm just writing a sumary. This section is placed at the top of the page. #9: Siegfried Olschner (sdolschn) (2007-07-03 12:39:23) I got only 2-3 NOT-Expert users in the sample. Their results are not presented on the page. But it's clear, they separated out cards like: VLM, iSCSI Initiator, Powertweak, VNC, Sudo, AppArmor, LDAP, etc., etc. #10: Siegfried Olschner (sdolschn) (2007-07-06 10:05:23) Some mockups available at: http://en.opensuse.org/YaST_Control_Center_-_Card_Sort_Study#Sorting_and_pr… #11: Martin Schmidkunz (mschmidkunz) (2007-11-29 13:50:55) Some additional mock ups and thoughs about that topic are available at: http://en.opensuse.org/YaST/Development/New_Control_Center #13: Martin Schmidkunz (mschmidkunz) (2008-02-11 15:24:24) One other suggestion was influenced by the KDE 4 control center: http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_KDEstyle The main concerns with these mock ups are: * information overload * "search" is somehow meaningless if it isn't provided by some kind of thesaurus #15: Berthold Gunreben (azouhr) (2008-04-09 12:52:12) I don't know if this is just too late, but for me the only design that looks like a real step forward from all the designs on http://en.opensuse.org/YaST/Development/New_Control_Center/ is http://en.opensuse.org/YaST/Development/New_Control_Center/YaST_System_Navi… I really like this approach. Please don't just create huge lists of modules, or preselected lists of modules that never can meet the customers needs. #16: Duncan Mac-Vicar (dmacvicar) (2008-04-24 14:56:14) This feature was on impl. But limited resources and refocus on PackageKit froze development. Passing back to Stano. #17: Federico Lucifredi (flucifredi) (2008-06-13 19:49:56) lets figure out a plan and get it done this time :) #20: Martin Schmidkunz (mschmidkunz) (2007-09-29 03:17:48) As there is some negative feedback from the KDE 4 personal settings menu (https://bugzilla.novell.com/show_bug.cgi?id=431432) maybe we should take it into account when talking about a YaST control center redesign. BTW: what is the status on this feature request? #21: Thomas Göttlicher (tgoettlicher) (2008-10-23 17:03:56) (reply to #20) Thanks for this hint. Development on this featrue is postponed. #22: evamaria fuchs (nefuchs) (2009-01-22 17:49:48) Currently we are conducting usability tests, see: http://en.opensuse.org/YaST/Development/New_Control_Center#Usability_Tests + #24: Karl Eichwalder (keichwa) (2009-05-08 07:37:16) + For what's worth, things got worse in the meantime ;) This feature + needs to be split into 2 or 3 subfeatures: + + * Improve labels (e.g., "/etc/sysconfig Editor" -> "Sysconfig Editor"). + * Reorganize groups: Move items from "Other" to Miscellaneous, split + Network Services into Network Servers and Network Clients, make the + Apparmor entries one entry and move it to Security, make Virtualization + entries one entry and move it to System, move Hostnames from Network + Services to Network Devices and rename Network Devices to "Network + Devices and Hostnames". + * Improve the UI. + The Gnome CC is rahter pointless because its left navigation (?) is + just superfluous (ok, there is now "Common Tasks"...). Because YaST + contains more groups and especially entries, we need a way to hide or + collapse groups completely. (I do not like the KDE idea just to display + a subset of the entries of a group.) + + BTW, the worst thing about yast's gtk ui is the idea of sorting groups + alphabetically. In English, happily "Hardware" comes before + "Miscellaneous"... -- openSUSE Feature: https://features.opensuse.org/302306

1 0

[openFATE 306408] blah
by fate_noreply＠lists4.suse.com 07 May '09

07 May '09

Feature changed by: Hendrik Vogelsang (hennevogel) Feature #306408, revision 6 Title: blah openFATE: New Priority Requester: Important Info Provider: Heidi Lahtinen (chrysantine) Requested by: Hendrik Vogelsang (hennevogel) Description: This is a test feature. Discussion: #1: Hendrik Vogelsang (hennevogel) (2009-05-07 16:09:14) please make a comment #2: Hendrik Vogelsang (hennevogel) (2009-05-07 16:19:52) this is a comment #3: Hendrik Vogelsang (hennevogel) (2009-05-07 16:34:47) (reply to #2) why? + #4: Hendrik Vogelsang (hennevogel) (2009-05-07 16:45:19) (reply to #3) + hrrrmmmm -- openSUSE Feature: https://features.opensuse.org/306408

1 0

Test Ignore
by fate_noreply＠suse.de 07 May '09

07 May '09

1 0

Test Ignore
by fate_noreply＠suse.de 07 May '09

07 May '09

Hi, test ignore Henne -- http://opensuse.org

1 0