November 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 301175] Update Messages Handling
by fate_noreply＠suse.de 27 Nov '09

27 Nov '09

Feature changed by: Christoph Thiel (cthiel1) Feature #301175, revision 49 Title: Update Messages Handling openSUSE-10.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-11-23 08:29:21 reject reason: not done in time... Priority Requester: Mandatory Projectmanager: Important openSUSE-10.3: Rejected by Stephan Kulow (coolo) reject date: 2007-08-07 11:17:55 reject reason: Solution needs to be integrated earlier in the release Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Andreas Jaeger (a_jaeger) Requested by: Marcus Meissner (msmeissn) Description: During update of packages they could notify users about changes via email and/or the SuSEplugger (until 10.0, this is not anymore in 10.1). Most of these are outdated and not really usefull anymore and should be removed. The question is how to handle situations like bind where config files get rewritten and the user should be informed if this fails. In general, it is not possible to send emails from rpm install scripts. Most cases could be handled by the release notes but there are cases that cannot and we need a better solution to present this, especially since many people to not read the local emails. Relations: - update-messages functionality not implemented (novell/bugzilla/id: 450093) https://bugzilla.novell.com/show_bug.cgi?id=450093 - Software Management/Code11/Scripts and Messages (url: http://en.opensuse.org/Software_Management/Code11/Scripts_and_Messages#Auto…) Discussion: #2: Hendrik Vogelsang (hennevogel) (2006-09-05 14:52:12) Cleanup the messages and readd the features we lost with the removal of SUSEPlugger to zen-updater or whatever? #3: Duncan Mac-Vicar (dmacvicar) (2006-11-02 11:48:15) Current patches offer the message feature, so you could basically offer that package as a patch. If that is not sufficient, I propose something: We add a /var/spool/zypp-messages or something, and a binary which rpm spec call to inject messages. The zypp backend of the applet, check the spool in every check and use knotify to notifiy the user. I am only missing, where does the current rpm inject the messages to? #5: Edith Parzefall (emapedl) (2007-02-01 17:30:54) Andreas: any comments on the proposed solutions? #6: Duncan Mac-Vicar (dmacvicar) (2007-07-27 15:58:07) A proposal for normal packages: Create a dbus/dcop interface both applets implement. * create a /usr/sbin/update-messsage wrapper that allows rpms to send a message. * the wrapper sends a dcop/dbus message to the applets, which in turn show a passive popup? Other ideas? #7: Edith Parzefall (emapedl) (2007-08-06 13:50:22) Coolo, should we go ahead with the proposed solution and make a late feature admission request? #8: Stephan Kulow (coolo) (2007-08-06 19:18:17) (reply to #7) No, this requires documentation changes I'm not willing to accept. So I rather stay with the status quo ;( #9: Edith Parzefall (emapedl) (2007-08-07 11:05:55) Then please reject for 10.3. #10: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:19:05) Please reject for 11.0. All resources allocated with mandatory features already. #11: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:32:22) Please reject for SLE11/11.1. All resources allocated with mandatory features already. #12: Marcus Meissner (msmeissn) (2008-12-03 15:50:15) This was promised as "will be done" to the Maintenance Department. Mark it Mandatory for SP1. #13: Federico Lucifredi (flucifredi) (2009-01-23 15:39:07) (reply to #12) please note, any solution must not break "RPM only" compatibility - meaning these should be notification messages, not scripts used in any event to finish configuration or to cause "side effects" of any kind. #14: Federico Lucifredi (flucifredi) (2009-01-23 15:38:53) I disagree with the rationale that users don't read local mail. An admin should have that local mail forwarded, and I think we ought to facilitate configuring the forwarding even to other machines. I think that may have more success than popups... at least for Enterprise customers. For community use, sure, popups are helpful (as init 5 is more likely :-) #15: Stephan Kulow (coolo) (2009-03-04 11:35:25) (reply to #14) but who would send these mails if rpm is the only vehicle we can be sure of. We don't want packages to send mails. #16: Michael Andres (mlandres) (2009-09-23 17:18:17) That's the zypp.conf option I'd like to introduce for this feature: ## ## Command to be invoked to send update messages. ## ## Packages may leave an update message file in {update.messagesdir}. ## At the end of each commit, zypp collects those messages and may send ## a notification to the user. ## ## zypp will prepare the update messages according to the selected ## content format and pipe the content to the command. ## ## Format: ## single - For each update message invoke the command and send ## the message. ## none - For each update message invoke the command but don't ## use a pipe to send any data. You probably want to pass ## the message file on the commandline using %P (see ## Substitutions). ## digest - Single invocation of the command, sending the path ## names of all update message. One per line. ## bulk - Single invocation of the command, sending the ## concatenated content of all update messages, separated ## by Ctrl-L. ## ## Substitutions: ## %p - package identification (name-version-release.arch) ## %P - full path to the update message file ## ## Valid values: The value is specified as "format | command". ## An empty value will turn off any notification. ## ## Examples: single | mail -s 'Update message from %p' root ## none | my-send-script -f %P ## ## Default value: single | /usr/lib/zypp/notify-message -p %p ## # update.messages.notify = single | /usr/lib/zypp/notify-message -p %p #17: Michael Andres (mlandres) (2009-10-07 17:13:03) The libzypp part seems to be done with libzypp-6.18.0 (for openSUSE 11.2). The /usr/lib/zypp/notify-message script, which gets invoked per default, sends mail with subject [zypp-notify-message] packagename- version.arch to root. The feature can be configured/disabled in /etc/zypp.conf. The list of update message files is also returned via ZYppCommitResult, so zypper/UI could write a note, or even offer to display them if we want that too. And we could also think about sending the config file diffs we create via this feature. #19: Ján Kupec (jkupec) (2009-11-20 15:25:11) (reply to #17) Zypper 1.2.11 now shows a list of packages which wrote notifications, and offers to view them all in pager. Submitting the package in few minutes. + #22: Christoph Thiel (cthiel1) (2009-11-27 15:07:38) (reply to #21) + In that case, let's mark this feature as done, eh? :) -- openSUSE Feature: https://features.opensuse.org/301175

1 0

[openFATE 306411] Configuration files merge
by fate_noreply＠suse.de 27 Nov '09

27 Nov '09

Feature changed by: Michal Hrusecky (-miska-) Feature #306411, revision 20 Title: Configuration files merge openSUSE-11.2: Rejected by Michael Löffler (michl19) reject date: 2009-08-11 15:58:40 reject reason: too late for 11.2 Priority Requester: Desirable openSUSE-11.3: Evaluation Priority Requester: Desirable Requested by: Michal Hrusecky (-miska-) Description: If we want to make our distribution friendly even to advanced users, I think that we shouldn't touch users configuration files. Luckily this isn't problem as in spec file Ican state that this file is configuration and I don't want to replace it if user did some manual changes. Or I can say that I want to replace it and keep backup of original one. But what I'm missing is some tool to easily merge these files. In Gentoo there is etc-update (http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=4#doc_…) or dispatch-conf (http://en.gentoo-wiki.com/wiki/Dispatch-conf) . I'll describe more precisely what feature I'm missing and why I think it's needed. Let's say that I've got some package and there was quite big change in package default configuration file which will affect most of the users. On the other hand users can have pretty complicated constructions in their configuration files and if they did something like that, it's quite possible that they don't need to update their configuration file. So it is needed to tell users that if they are experiencing problems it is most likely because they touched default configuration. I can take care of it manually, mention it in various README and such, but more easier way would be following. User installs some packages. At the end of zypper or yast installation there will be warning "You've got 42 configuration files to merge, please run etc-update/dispatch-conf/whatever". Then user will run some easy interactive tool which will state which configuration files can use some manual merging, it will allow user to see difference between them and let him choose which one he wants or let him merge them manually somehow. Same warning about unmerged configuration files should appear each time user installs something, no matter if this installation didn't add any conflict, until all conflicts are fixed. User will be warned about possible problems, hacker can play with it and keep his changes against distribution defaults and ordinary user will just click on "use distribution default for all" if he ever encounter such a problem (shouldn't happen as ordinary user wouldn't touch configuration files). I explained basic expected work flow, so now what I think should be supported: * detect configuration files, their conflicts and allow their merge - this shouldn't be a big problem as rpm already stores conflicting files as .rpmnew/.rpmold * we probably want to keep even old versions to support three way merge to achieve even better results * if we are already storing these configuration files, maybe we should let users to backup their own changes as well, add support for versioning these configuration files * warn user that he has conflicts in configuration files - will require a little bit yast/zypper integration * merging tool should support both console and graphical interface (maybe use yast as possible frontend) * support for various formats (expandable by plugins) - ordinary diff may not be the best tool for merging XML files or ini files * ordinary user who don't change anything shouldn't need to know about this tool Relations: - Debian-like dist-upgrade live system full version upgrade (feature/id: 305634) Discussion: #1: Michal Hrusecky (-miska-) (2009-06-02 09:49:38) I was thinking about this a little bit more and if we want to support some kind of versioning and we want to use plugins for getting differences, it may be a good idea to request that plugins will be capable not only of producing nice output of difference between configuration files, but it probably should be able to apply it (behave not only as a 'diff', but also as a 'patch'). And we can build some simple version control system on top of it. Advantages: * can handle non-plain text files better (via plugins) * we can implement feature to discard or merge several commits into one to save space/make commit log more readable * can handle nicelly even insane configuration files like sqlite database or compressed directory with configuration files or any other binary format Disadvantages: * probably worse handling of text files * another thing to maintain/possible source of bugs #2: Stephan Kulow (coolo) (2009-06-09 11:51:14) this sounds like a lot of work to do right and with little gain. We lived quite well for years without it and whatever tool you come up will create new problems, there won't be a perfect tool. Applications with very bizzare config format usually come with their own configuration update tool that can be called from %post So I would put very low imporance on this. #3: Andreas Jaeger (a_jaeger) (2009-06-09 14:20:14) (reply to #2) The question is what is really needed to do here. If we could take some scripts from Gentoo and those would work without changes - cool. If we would need to change each and every config file for this, I'm also for rejecting. So, for me it's not clear what the cost is. #4: Michal Hrusecky (-miska-) (2009-06-12 16:12:55) (reply to #3) Well, merging utility can be probably ported from Gentoo with few minor tweaks (although it would be console only utility) or it could be written from scratch (with possible features in mind). This shouldn't be a big problem (it will just take some time). In feature #305634 comment #19 there is even an example how to write such a simple utility. With current rpm workflow, I think there is no need for packages changes. Only thing that would need some adjustements for this feature to be fully functional is integration with yast/zypper so thay will print warning about possible conflicts. I wouldn't suggest to force people to solve, just printing that there are some and that they should solve them using this utility should be enough. So it will need just some hack/new feature in installation procedure - run a program and allow it to create some notification for user. This is probably related to feature #301175 (301175) #5: Michael Andres (mlandres) (2009-06-15 12:02:05) (reply to #3) Libzypp checks for changed configfiles, and if they differ the 'diff' output is written to /var/log/YaST2/ (I don't know if YaST still mails this to root). Notification is also /var/log/zypp/history, and AFAIK zypper displays some info as well. But it's not a big deal to have a more flexible consumer for this information. The easiest would be to check for the presence of a certain script (or a directory containing scripts), and if it exists invoke it with package names and configfiles as argument. Then you can install any handler you like. #6: Elmar Stellnberger ATK (estellnb) (2009-08-04 11:48:04) At Bug 506815, Comment #2 we have a more simple proposial simply notifying the user about changes in configuration files and selecting an appropriate .rpmnew/.rpmold strategy. This should be the first thing to be implemented in this regard before we can move on to fancier things like an interactive auto-diff&merge (https://bugzilla.novell.com/show_bug.cgi?id=506815#c2) I personally would not regard the gain as little since forgetting to re- create config files can be very tedious especially if you forget about it and especially if there are regular upgrades as for the buildservice repos. #7: Ralph Ulrich (ulenrich) (2009-08-05 13:44:25) (reply to #6) Zypper should make a summary: 1. new rpmnew,rmpold files 2. How many of rpmnew,rpmold files were sitting around before action #8: Michal Hrusecky (-miska-) (2009-08-05 16:05:07) (reply to #7) As users should be notfied about other things as well after update, notifications shouldn't be handled by zypper (we've got Yast too) but we will need some general mechanism to notify user. And probably rpm should generate message about new configurations file conflict. But this message should be one of many possible messages (sometimes some other important user action is needed after update). I think users notifications are already discussed in feature#301175 (301175) . I also created wiki (http://en.opensuse.org/Configuration_Merge) page for this feature some time ago. #9: Stanislav Brabec (sbrabec) (2009-08-06 12:43:40) (reply to #8) User notification were also topic of: http://lists.opensuse.org/zypp-devel/2009-05/msg00001.html https://features.opensuse.org/305307 may be interesting way to inform as well (especially for auto updates) #10: Rick Beauchamp (techwiz03) (2009-10-31 02:22:14) Goes a bit farther than what I had to do to resolve a Yast-network config problem. * Yast correctly identified network settings were bad in config files but didn't report which files were at fault. * Yast then asked for acknowledgement that message was read. * Yast then re-scanned and looped through this process until shutdown forced. For me resolve was to search some 19 config files and compare them till bad settings were found and manually fixed. I fear that an implementation of your type of merge configs could potentially make such a scenerio seriously compromise the debugging process. After experiencing such a problem it prompted me to develope a multi- file examiner. This program does not directly change any settings or config files. What you do is select the catagory you are looking at (Networking) then choose the type of sub-system (wireless). You get a list of files that pertain to wireless networking. You then can select up to 7 files from the list which each in turn display in a tabbed viewer. You can then examine them and even change then with-in the browser, but what my solution lacks is the ability to directly save the changes. What my solution does allow is copying the contents to the clipboard for pasting into a suitable writer for saving. Thusly the intent of my solution is targeted at finding an error and identifying where the error'd file is. Tying this in with your topic, if a config merge is desired, the safest way is always through manual interaction. If you use a program like mine to view multiple config files, you could merge the contents between tab-windows, and then copy the contents complete to the clipboard for saving under an explicite filename. my 2 cents worth. + #11: Michal Hrusecky (-miska-) (2009-11-27 11:25:05) (reply to #10) + This sounds interesting. Didn't thought about categorization. Is your + program somewhere available? How do you get such categories? Got two + ideas - by package name or by path (as network is nicelly categorized + in direcotries). I still think that automatic merge can be quite safe. + If you changed some little things like enabling some service, you + probably don't need to know that there was some typo fixed somewhere in + comments in the same file. Of course it has to be up to user to + enable/disable if he wants to do some automatic merging, but typically + I'm satistied with system defaults and I do care only about few + configuration files. -- openSUSE Feature: https://features.opensuse.org/306411

1 0

[openFATE 303848] Common crash screen
by fate_noreply＠suse.de 26 Nov '09

26 Nov '09

Feature changed by: Michal Vyskocil (mvyskocil) Feature #303848, revision 38 Title: Common crash screen openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-08-18 17:10:33 reject reason: oops. Priority Requester: Mandatory openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 10:46:33 reject reason: noone stepped up even though it was discussed several times on public mailing lists. Priority Requester: Mandatory Projectmanager: Desirable Requested by: Federico Lucifredi (flucifredi) Description: As part of the Novell Support Link infrastructure initiative, provide common crash screen to intercept all applications equally, whether KDE, Gnome, OpenOffice, Mozilla or other. The common crash screen is part of the support module. Kernel infrastructure in place (see Ubuntu Apport) use cases: - on graphical screen: prompt user to report crash to Novell. - on headless system: if so configured, report crash automatically to aggregation point (SMT locally or Novell). this is off by default. - optionally, if support contract active, offer button to request live support chat/remote desktop session Discussion: #16: Klaus Kämpf (kwk) (2009-09-21 11:28:11) Why's this feature assigned to YaST ? Looks more like a 'base system' thing to me. #18: Jiri Srain (jsrain) (2009-09-21 16:06:11) (reply to #16) If supportconfig is integrated directly into apport (which makes more sense to me than invoking YaST, which would need to run with root permission and that could be problematic in the security point of view), then there is IMO nothing in YaST to be done here. #17: Klaus Kämpf (kwk) (2009-09-21 11:29:14) Btw., https://fedorahosted.org/abrt/wiki seems to provide this functionality. #19: Stefan Behlert (sbehlert) (2009-09-23 07:33:16) Duncan, could you evaluate the feature and set the status correctly? Thanks! #26: Michal Vyskocil (mvyskocil) (2009-11-26 09:36:19) Apport has been submitted on Monday 23-11-2009, but only with a headless mode, as has been decided on a last call about this feature. #27: Thorsten Kukuk (kukuk) (2009-11-26 09:39:19) (reply to #26) I assume we need to add some packages to the media for this feature? Which are this exactly? + #28: Michal Vyskocil (mvyskocil) (2009-11-26 17:19:10) (reply to #27) + The packages needs to be included into SLE-11-SP1: - apport (incl + apport-gtk) - apport-crashdb-sle - python-zypp from SDK - ptools (will + be submitted asap and maintained by Jan Blunkc as in openSUSE) + Packages apport-crashdb-opensuse and apport-qt should *not* be + included. -- openSUSE Feature: https://features.opensuse.org/303848

1 0

[openFATE 303848] Common crash screen
by fate_noreply＠suse.de 26 Nov '09

26 Nov '09

Feature changed by: Thorsten Kukuk (kukuk) Feature #303848, revision 37 Title: Common crash screen openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-08-18 17:10:33 reject reason: oops. Priority Requester: Mandatory openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 10:46:33 reject reason: noone stepped up even though it was discussed several times on public mailing lists. Priority Requester: Mandatory Projectmanager: Desirable Requested by: Federico Lucifredi (flucifredi) Description: As part of the Novell Support Link infrastructure initiative, provide common crash screen to intercept all applications equally, whether KDE, Gnome, OpenOffice, Mozilla or other. The common crash screen is part of the support module. Kernel infrastructure in place (see Ubuntu Apport) use cases: - on graphical screen: prompt user to report crash to Novell. - on headless system: if so configured, report crash automatically to aggregation point (SMT locally or Novell). this is off by default. - optionally, if support contract active, offer button to request live support chat/remote desktop session Discussion: #16: Klaus Kämpf (kwk) (2009-09-21 11:28:11) Why's this feature assigned to YaST ? Looks more like a 'base system' thing to me. #18: Jiri Srain (jsrain) (2009-09-21 16:06:11) (reply to #16) If supportconfig is integrated directly into apport (which makes more sense to me than invoking YaST, which would need to run with root permission and that could be problematic in the security point of view), then there is IMO nothing in YaST to be done here. #17: Klaus Kämpf (kwk) (2009-09-21 11:29:14) Btw., https://fedorahosted.org/abrt/wiki seems to provide this functionality. #19: Stefan Behlert (sbehlert) (2009-09-23 07:33:16) Duncan, could you evaluate the feature and set the status correctly? Thanks! #26: Michal Vyskocil (mvyskocil) (2009-11-26 09:36:19) Apport has been submitted on Monday 23-11-2009, but only with a headless mode, as has been decided on a last call about this feature. + #27: Thorsten Kukuk (kukuk) (2009-11-26 09:39:19) (reply to #26) + I assume we need to add some packages to the media for this feature? + Which are this exactly? -- openSUSE Feature: https://features.opensuse.org/303848

1 0

[openFATE 303848] Common crash screen
by fate_noreply＠suse.de 26 Nov '09

26 Nov '09

Feature changed by: Michal Vyskocil (mvyskocil) Feature #303848, revision 36 Title: Common crash screen openSUSE-11.1: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-08-18 17:10:33 reject reason: oops. Priority Requester: Mandatory openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-08-12 10:46:33 reject reason: noone stepped up even though it was discussed several times on public mailing lists. Priority Requester: Mandatory Projectmanager: Desirable Requested by: Federico Lucifredi (flucifredi) Description: As part of the Novell Support Link infrastructure initiative, provide common crash screen to intercept all applications equally, whether KDE, Gnome, OpenOffice, Mozilla or other. The common crash screen is part of the support module. Kernel infrastructure in place (see Ubuntu Apport) use cases: - on graphical screen: prompt user to report crash to Novell. - on headless system: if so configured, report crash automatically to aggregation point (SMT locally or Novell). this is off by default. - optionally, if support contract active, offer button to request live support chat/remote desktop session Discussion: #16: Klaus Kämpf (kwk) (2009-09-21 11:28:11) Why's this feature assigned to YaST ? Looks more like a 'base system' thing to me. #18: Jiri Srain (jsrain) (2009-09-21 16:06:11) (reply to #16) If supportconfig is integrated directly into apport (which makes more sense to me than invoking YaST, which would need to run with root permission and that could be problematic in the security point of view), then there is IMO nothing in YaST to be done here. #17: Klaus Kämpf (kwk) (2009-09-21 11:29:14) Btw., https://fedorahosted.org/abrt/wiki seems to provide this functionality. #19: Stefan Behlert (sbehlert) (2009-09-23 07:33:16) Duncan, could you evaluate the feature and set the status correctly? Thanks! + #26: Michal Vyskocil (mvyskocil) (2009-11-26 09:36:19) + Apport has been submitted on Monday 23-11-2009, but only with a + headless mode, as has been decided on a last call about this feature. -- openSUSE Feature: https://features.opensuse.org/303848

1 0

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

26 Nov '09

Feature changed by: Karl Eichwalder (keichwa) Feature #302306, revision 75 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: Rejected by Jiri Srain (jsrain) reject date: 2009-07-17 10:19:44 reject reason: Let's do it early in the 11.2 development cycle to have feedback from Alpha snapshots and be able to adjust. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.3: 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"... #28: Bart Otten (bartotten) (2009-11-08 14:19:50) (reply to #24) +1 The AppArmor-group is annoying me for a long time. When it came into openSUSE I allready filed a bugreport (FATE was not openFATE yet). I think there are still some lessons in the card sort study. #25: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:24:54) the split between kcontrol and yast is confusing #26: Rémy Marquis (spyhawk) (2009-06-05 02:22:02) (reply to #25) This issue has already been discussed here : http://duncan.mac-vicar.com/blog/archives/452 #27: jimbo bigcreed (dimble_thricefoon) (2009-06-17 16:10:31) (reply to #26) cheers for the info. as long as they provide a non-confusing synthesis of the two related system management functions in a native QT4.5 environment i will be happy. #29: Atri Bhattacharya (badshah400) (2009-11-25 00:55:36) In my opinion, it would be nice to split up YaST's Control Centre into two tabs 1) Basic tasks: This tab should show a limited number of tasks (not modules) used frequently by a typical desktop user. The list might include things like: Set up a printer, Set up a TV card, Check for update, Install/uninstall software, Change system-wide network proxy, Configure date and Time, Add/remove user, manage network settings, view release notes, etc. Tasks might also be grouped into categories like hardware, etc. 2) Advanced view: This is a separate tab that shows all the modules categorised into groups. This is equivalent to the present control- centre view. By not presenting at first view a large number of icons with complicated names and advanced functionality (e.g. Kerberos client, AppArmor, Remote administration-VNC, etc.) the control-centre will prevent a typical desktop user from being overwhelmed, which happens with the present view. The task based list will also help in the sense that one generally thinks in terms of tasks when he/she starts up YaST to configure something. The advanced-view is also present (could use a check-box that says show advanced view by default in YaST for experienced people) for all other modules that might be necessary for specialised usage (like the kerberos client). The present YaST Control Centre is overwhelming for a typical desktop user. Reorganising it so that it shows a task-based list at first view will help regular users appreciate the power of YaST and also importantly its simplicity. It is imperative that we concentrate on the average Joe desktop user in streamlining the interface while keeping in mind its versatility and strengths for the experienced user as well. I believe a reorganisation of YaST's interface along these lines will achieve that. #30: Karl Eichwalder (keichwa) (2009-11-25 09:09:31) (reply to #29) The idea is quite good, but I'd avoid tabs. I'd add two additional additional groups ("Favorites" and "Basics") and list them at the top of the left pane. "Favorites" are meant to be populated by the user, just add two or three entries to make look it nice. "Basics" should contain 8 or 10 entries such as "Install/Remove Software", "Network Config", "Update Config", etc. As a third group you could add "Recent Modules"... After these two are three groups add a separator. #31: Atri Bhattacharya (badshah400) (2009-11-25 17:59:07) (reply to #30) >The idea is quite good, but I'd avoid tabs. Why? Tabs might help separate the gui into two distinct views: basic and advanced. Isn't that useful? However the Favourites and Basics groups you have mentioned also sound very interesting. My point in the above post was to have a view that lists tasks instead of modules, this in my opinion is important for useability. If the basics group as mentioned in your comment has tasks that would be great, the point being when we fire up YaST we are thinking "gotto change the proxy" or "have to add another user" or "have to set up my printer" as against when we are launching application-browser in Gnome for example where one is thinking "OK, let me start this image-editor". A task-based YaST would really help in my opinion, whether they are organised in a tab-based view or as groups as you mention (I actually like the group view more, but there should also be an advanced view which should be useful for the experienced users). + #32: Karl Eichwalder (keichwa) (2009-11-26 08:23:43) (reply to #31) + > Tabs might help separate the gui into two distinct views: basic and + advanced. + Maybe, it's useful. I think vertical space is precious. Screens are + wide and wider, but often not that high. Really small screens are back + with the NetBooks. And then, there is the ncurses YaST UI. + I think most things are already task based up to some degree. There is + not just one single module called "software management", but there are + also other entry point to software managing such as managing + repositories or doing online update. The same is valid for networking + stuff. + But it would be nice to add a search interface. The gtk incarnation + comes with a filter option what is a start. -- openSUSE Feature: https://features.opensuse.org/302306

1 0

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

25 Nov '09

Feature changed by: Atri Bhattacharya (badshah400) Feature #302306, revision 74 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: Rejected by Jiri Srain (jsrain) reject date: 2009-07-17 10:19:44 reject reason: Let's do it early in the 11.2 development cycle to have feedback from Alpha snapshots and be able to adjust. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.3: 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"... #28: Bart Otten (bartotten) (2009-11-08 14:19:50) (reply to #24) +1 The AppArmor-group is annoying me for a long time. When it came into openSUSE I allready filed a bugreport (FATE was not openFATE yet). I think there are still some lessons in the card sort study. #25: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:24:54) the split between kcontrol and yast is confusing #26: Rémy Marquis (spyhawk) (2009-06-05 02:22:02) (reply to #25) This issue has already been discussed here : http://duncan.mac-vicar.com/blog/archives/452 #27: jimbo bigcreed (dimble_thricefoon) (2009-06-17 16:10:31) (reply to #26) cheers for the info. as long as they provide a non-confusing synthesis of the two related system management functions in a native QT4.5 environment i will be happy. #29: Atri Bhattacharya (badshah400) (2009-11-25 00:55:36) In my opinion, it would be nice to split up YaST's Control Centre into two tabs 1) Basic tasks: This tab should show a limited number of tasks (not modules) used frequently by a typical desktop user. The list might include things like: Set up a printer, Set up a TV card, Check for update, Install/uninstall software, Change system-wide network proxy, Configure date and Time, Add/remove user, manage network settings, view release notes, etc. Tasks might also be grouped into categories like hardware, etc. 2) Advanced view: This is a separate tab that shows all the modules categorised into groups. This is equivalent to the present control- centre view. By not presenting at first view a large number of icons with complicated names and advanced functionality (e.g. Kerberos client, AppArmor, Remote administration-VNC, etc.) the control-centre will prevent a typical desktop user from being overwhelmed, which happens with the present view. The task based list will also help in the sense that one generally thinks in terms of tasks when he/she starts up YaST to configure something. The advanced-view is also present (could use a check-box that says show advanced view by default in YaST for experienced people) for all other modules that might be necessary for specialised usage (like the kerberos client). The present YaST Control Centre is overwhelming for a typical desktop user. Reorganising it so that it shows a task-based list at first view will help regular users appreciate the power of YaST and also importantly its simplicity. It is imperative that we concentrate on the average Joe desktop user in streamlining the interface while keeping in mind its versatility and strengths for the experienced user as well. I believe a reorganisation of YaST's interface along these lines will achieve that. #30: Karl Eichwalder (keichwa) (2009-11-25 09:09:31) (reply to #29) The idea is quite good, but I'd avoid tabs. I'd add two additional additional groups ("Favorites" and "Basics") and list them at the top of the left pane. "Favorites" are meant to be populated by the user, just add two or three entries to make look it nice. "Basics" should contain 8 or 10 entries such as "Install/Remove Software", "Network Config", "Update Config", etc. As a third group you could add "Recent Modules"... After these two are three groups add a separator. + #31: Atri Bhattacharya (badshah400) (2009-11-25 17:59:07) (reply to + #30) + >The idea is quite good, but I'd avoid tabs. + Why? Tabs might help separate the gui into two distinct views: basic + and advanced. Isn't that useful? + However the Favourites and Basics groups you have mentioned also sound + very interesting. My point in the above post was to have a view that + lists tasks instead of modules, this in my opinion is important for + useability. If the basics group as mentioned in your comment has tasks + that would be great, the point being when we fire up YaST we are + thinking "gotto change the proxy" or "have to add another user" or + "have to set up my printer" as against when we are launching + application-browser in Gnome for example where one is thinking "OK, let + me start this image-editor". A task-based YaST would really help in my + opinion, whether they are organised in a tab-based view or as groups as + you mention (I actually like the group view more, but there should also + be an advanced view which should be useful for the experienced users). -- openSUSE Feature: https://features.opensuse.org/302306

1 0

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

25 Nov '09

Feature changed by: Jiri Srain (jsrain) Feature #305553, revision 37 Title: zypper: dist upgrade could error out if more than one repository with a base product exists openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important + openSUSE-11.3: New + Priority + Requester: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) ma, is there a libzypp interface? #14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13) Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see bnc #459527). #15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14) OK, so this should not be too much work. So to sum it up: * zypper: show a warning in 'dup' if there are multiple base repos with different CPEids enabled. * metadata: check/include the CPEid in product metadata (who should do this?) #16: Ján Kupec (jkupec) (2009-07-27 17:30:09) (reply to #14) Rudi, please look at c#14 and 15 #17: Ján Kupec (jkupec) (2009-07-29 19:04:40) Current status: * TODO: put CPE IDs to content/prodcuts.xml metadata (still nobody assigned to do this!) * TODO: satsolver will need to parse the above (or is this ready already?) * PROBLEM: we need to figure out which repos don't go together for dup. I proposed to compare CPEs of 'base' or 'platform' repos, but we have no 'isBase' flag in product or repo metadata. Simply checking for different CPEs is not enough (think of one base product and one addon - two different CPEs, but 'dup' is OK with them). * PROBLEM: even if we'll have the 'isBase' flag, we'll be stuck in case of two different, but compatible bases, like e.g. SLES and SLED could be used standalone or with SLED as an add-on to SLES in the past. Do we still allow this? Any ideas? #18: Ruediger Oertel (oertel) (2009-07-30 17:20:05) adding more data (like the CPE-ids) is not a big issue. the problem for me is rather how to obtain a CPE-id #19: Marcus Meissner (msmeissn) (2009-08-04 17:55:08) CPE ids can be defined by the vendor as I udnerstand ;) I mailed Jan and Rudi. my suggestions would be: cpe:/o:opensuse:opensuse:11.1 cpe:/o:novell:suse_linux_enterprise:11:ga:server cpe:/o:novell: suse_linux_enterprise:10:sp2:desktop #20: Ralph Ulrich (ulenrich) (2009-08-05 13:25:05) (beginners question) Why products at all. Debian/Ubuntu do have so called meta-packages , which are normal package that pull in stuff: minimal, standard ...etc Without products you would loose an additional level of complication? #21: Ján Kupec (jkupec) (2009-08-05 15:02:36) (reply to #20) Using metapackages for puling stuff does not exlude using of CPE ID. It's just means to uniquely identify a product and can be used by Debian's metapackages as well. Other than that, your question is not related to this FATE, and is more appropriate for opensuse-softwaremgmt(a)opensuse.org mailing list. But you might find the answer also here http://en.opensuse.org/Product_Management #22: Ján Kupec (jkupec) (2009-08-19 17:25:34) We still need to do the TODOs and resolve the issues from c#17 here. If you have an idea, please speak up. #23: Klaus Kämpf (kwk) (2009-08-25 09:36:05) I believe the request title is wrong and should be adapted. Indeed 'distribution upgrade' is special, as it considers one repo to be 'authorative' and thus dictating package versions, which might result in a version downgrade. 'zypper dup' should provide support for this and, in case of multiple 'product' (resp. base) repositories request a decision from the user. There are two things to be solved from my pov * Detection of a 'base' vs. 'addon' repo. Could be done by looking at a 'product' resolvable. * Specifying the 'authorative' repo in case of dist upgrade. ie. passing a '--product foo' or '-to repo' to zypper. #24: Ján Kupec (jkupec) (2009-11-18 15:59:55) (reply to #23) Detection of base vs. addon is what we currently lack. The authoritative repo can now be selected using --from option. 'zypper dup --from repo-oss'. #26: Ján Kupec (jkupec) (2009-11-20 15:29:56) Following Jiri's suggestion, i've done this the simple way for now: if --repo or --from are not used, and multiple repos are enabled, 'zypper dup' will show a warning and a hint that the user should check the repo list for incompatible repos. + #27: Jiri Srain (jsrain) (2009-11-25 13:55:01) (reply to #26) + This is all we could do for SP1. Keeping open for further enhancements + for SP2 and/or 11.3. -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305294] [beta1]Support Rotation hotkey in tablets (RANDR 1.2)
by fate_noreply＠suse.de 25 Nov '09

25 Nov '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305294, revision 24 - Title: Support Rotation hotkey in tablets (RANDR 1.2) + Title: [beta1]Support Rotation hotkey in tablets (RANDR 1.2) openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Federico Mena Quintero (federico-mena) Description: Tablet notebooks (especially the fancy new ones with Wacom pressure- sensitive screens) have a physical button to rotate the screen, in case you want to hold the tablet in portrait/landscape mode. We need to capture the XF86RotateWindows keysym, and rotate the laptop's display. Discussion: #1: Federico Mena Quintero (federico-mena) (2008-09-12 13:32:48) I just started a wiki page to track the status of support for laptops/tablets with these hotkeys: http://en.opensuse.org/Laptop_hotkeys_for_RANDR #2: Stefan Dirsch (sndirsch) (2009-04-15 17:16:00) Don't know how I can help here. #3: Stefan Dirsch (sndirsch) (2009-06-06 12:36:15) This is more for the RANDR >= 1.2 tool developers I would say. #5: Federico Mena Quintero (federico-mena) (2009-09-02 20:26:09) I'll take care of this. #6: Klaas Freitag (kfreitag) (2009-09-02 21:01:09) Great, thanks. Assuming you do it for both SLE and openSUSE I set it to implementation for both platforms. -- openSUSE Feature: https://features.opensuse.org/305294

1 0

[openFATE 305686] [beta1] gnome-screensaver does not respond to an expired password
by fate_noreply＠suse.de 25 Nov '09

25 Nov '09

Feature changed by: Wang Lance (lzwang) Feature #305686, revision 17 Title: [beta1] gnome-screensaver does not respond to an expired password openSUSE-11.2: Rejected by Stefan Behlert (sbehlert) reject date: 2009-09-08 20:39:08 reject reason: too late for that. Priority Requester: Mandatory Projectmanager: Important Requested by: Guy Lunardi (glunardi) Description: Using novell-lum-2.2.0.11-0.1 1. Authenticate to eDir, 2. Wait until the desktop is locked with screensaver enabled 3. Expire the user's password 4. Attempt to enter user password to unlock the destkop 5. The screensaver just goes into thinking mode for about 30 seconds then re-prompts the user for the password. If I disable password expire then I am able to unlock the desktop. Am attaching the gnome-screensaver file from /etc/pam.d. Relations: - gnome-screensaver does not respond to an expired password (novell/bugzilla/id: 224690) https://bugzilla.novell.com/show_bug.cgi?id=224690 Discussion: #2: Stefan Behlert (sbehlert) (2009-08-31 11:09:17) Marcus, can you give me an opinion from a security point-of-view? For me that sounds like a correct behavior. I'm wondering how other OSes handle this. #3: Marcus Meissner (msmeissn) (2009-09-07 16:32:41) (reply to #2) I think the reporter means that GNOME screensaver should show a message about the expiredness instead of "nothing". This probagly needs to be implemented in gnome-screensaver. #4: Stefan Behlert (sbehlert) (2009-09-08 20:40:02) (reply to #3) Ah, ok, I had a different understanding, but you are right, a message would be good enough. Alex, could someone from your team look at that? #5: Alex Chun Yin Lau (allau) (2009-09-17 17:29:57) Lance, why don't you take a look and see how difficult to add this message in to the screensaver. + #9: Wang Lance (lzwang) (2009-11-25 12:10:27) + Hi + * I found that this feature is related to security. GS implemented + three methods for authorization in source level. They are forking a + process to call /sbin/unix2_chkpwd, directly calling pam API, and + directly accessing system password database. But only one of them can + be compiled in GS finally. Currently in SLED the default method is + using the unix2_chkpwd helper. + * I also found that the function of this feature has been implemented + in the method of directly calling pam API. And it is not possible to + implement the feature by avoiding modifying the source of + /sbin/unix2_chkpwd which is a part of the package pam. Beause the + unix2_chkpwd returns nothing about the expired password. + * So I made a rpm with the method of directly calling pam API. However + it need to change the default configuration about GS in /etc/pam.d. I + do not kown, if it is OK. + * I think maybe we need security team to look this part. + * And this is the URL of new packages https://api.suse.de/build/home:lzwang:branches:SUSE:SLE-11:Update:Test/stan… + Thanks + Lance Wang -- openSUSE Feature: https://features.opensuse.org/305686

1 0