June 2009 - openSUSE Features - openSUSE Mailing Lists

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

13 Jun '09

Feature changed by: T. J. Brumfield (enderandrew) Feature #305317, revision 12 Title: Default to hidden bootloader menu openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Jiri Srain (jsrain) Description: As long as there is no other operating system present (SUSE is the only system), it makes sense to default to hidden bootloader menu (and booting directly). References: http://www.gnu.org/software/grub/manual/grub.html#Hidden-menu-interface https://bugzilla.novell.com/show_bug.cgi?id=425717 Discussion: #1: Stephan Kulow (coolo) (2009-04-16 10:34:48) I like that idea. I guess it's a tiny change for bootloader, but has possibly some docu impact. #2: Stanislav Visnovsky (visnov) (2009-05-28 16:45:13) How should it behave with option to keep kernels from updates (libzypp option)? What about failsafe? #3: Jiri Srain (jsrain) (2009-06-01 11:21:11) From the GRUB documentation: When your terminal is dumb or you request GRUB to hide the menu interface explicitly with the command `hiddenmenu' (*note hiddenmenu::), GRUB doesn't show the menu interface (*note Menu interface::) and automatically boots the default entry, unless interrupted by pressing ESC. When you interrupt the timeout and your terminal is dumb, GRUB falls back to the command-line interface (*note Command-line interface::). This sounds to me like this GRUB feature is intended for different purpose, and the use case described here does not make much sense (unlike lowering the time-out to e.g. 1 second). Torsten, what is your view? According to the documentation, GRUB allows to display the boot menu via pushing the Escape button. + #4: T. J. Brumfield (enderandrew) (2009-06-13 03:31:06) + This option would only be utilized when no other OS is present, and you + can still get back to the menu with Esc. This isn't that much different + than needing F8 for the boot menu for Windows. It would speed up boot + times. How is that a bad thing? -- openSUSE Feature: https://features.opensuse.org/305317

1 0

[openFATE 305147] Wizard mode for Network Card configuration (in YaST)
by fate_noreply＠suse.de 13 Jun '09

13 Jun '09

Feature changed by: T. J. Brumfield (enderandrew) Feature #305147, revision 11 Title: Wizard mode for Network Card configuration (in YaST) openSUSE-11.2: Evaluation Priority Requester: Neutral Requested by: Michal Zugec (mzugec) Description: (based on "Internet/Intranet with external Router" in suse-beta-e) It seems some users don't know how to setup the SuSEfirewall correctly. Especially, they don't know if they should setup a network card as internal or external device. If a network card is found, YaST should ask for its usage (local network or directly connected to the internet?) - every user should know. With this information the firewall setup can be done in a useful way. See bugzilla https://bugzilla.novell.com/show_bug.cgi?id=67415 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:34:01) sounds reasonable. But how many multihomed systems do we find where the user "does not know" ? Besides, the security team's policy seems to be "lock everything, ask questions later", so I am not sure they are willing to mollify the firewall rules (for instance, open up Avahi by default, or other default daemons) on a "local" interface. Asking Marcus for insight. I am not sure on this one. + #2: T. J. Brumfield (enderandrew) (2009-06-13 02:33:51) + I'd contend that openSUSE and SLES/SLED should be treated differently + here. With SLES/SLED, I'd err more on the side of caution and security, + where as with openSUSE, I'd err more on the side of making the system + user friendly. -- openSUSE Feature: https://features.opensuse.org/305147

1 0

[openFATE 304911] Import all GPG keys at once before downloading the metadata from new repositories
by fate_noreply＠suse.de 13 Jun '09

13 Jun '09

Feature changed by: T. J. Brumfield (enderandrew) Feature #304911, revision 23 Title: Import all GPG keys at once before downloading the metadata from new repositories openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-09 07:54:32 reject reason: Cannot be done in time. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Ladislav Slezak (lslezak) Description: If e.g. 10 different repositories are added yast asks to import the GPG key for each repository so the user cannot leave the computer while the metadata are downloaded. References: https://bugzilla.novell.com/show_bug.cgi?id=399253 Discussion: #2: Federico Lucifredi (flucifredi) (2008-07-08 19:41:45) (reply to #1) cute. It is a nice idea indeed. #3: Dmitry Mittov (michael_knight) (2009-02-23 11:03:50) It is not a good idea to add gpg keys for all repos all over the world. What do you want to do with new repos on BuildService? They can be created after release of new Suse version. All repos signed with SuSE Package Signing Key are guaranteed. When you add other repos you should confirm you trust them. But special option for 'zypper ar'. Something like '--trust-key' will solve you problem. #4: Stephan Kulow (coolo) (2009-04-16 14:41:15) (reply to #3) you haven't see the community repos list yet? #5: Stephan Kulow (coolo) (2009-04-16 14:41:42) looking for community volunteers #6: Stanley Miller (stan_qaz) (2009-04-30 04:10:50) Would it be possible to do a quick check to see which repositories do not have the keys already downloaded and do the dialog box for all of them before starting the metadata download? That avoids the issue of just accepting the keys blindly and the issue of having the download process stop and wait for user input when a missing key is found. + #7: T. J. Brumfield (enderandrew) (2009-06-13 02:14:59) + You have to go out of your way to add the repo in the first place. + Can someone please explain a scenario where you would go out of your + way to add the repo, and then reject the GPG key? -- openSUSE Feature: https://features.opensuse.org/304911

1 0

[openFATE 120326] Resume download
by fate_noreply＠suse.de 12 Jun '09

12 Jun '09

Feature changed by: T. J. Brumfield (enderandrew) Feature #120326, revision 70 Title: Resume download openSUSE-10.2: Rejected by Stanislav Visnovsky (visnov) reject date: 2006-09-21 09:56:17 reject reason: Not enough resources to implement in time. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-25 15:20:32 reject reason: Out of time. Postponing. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.0: Rejected by Jiri Srain (jsrain) reject date: 2008-03-28 13:51:03 reject reason: Out of resources for 11.0. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-01 11:34:46 reject reason: Postponing, needs downloading refactor. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Klaus Kämpf (kwk) Description: YaST/YOU times out too easy when downloading large packages like kde- base (14 MB) over a single ISDN connection. Please cache the half downloaded package so I don't have to start from the beginning again. See http://bugzilla.suse.de/show_bug.cgi?id=9740 (http://bugzilla.suse.de/show_bug.cgi?id=9740) http://bugzilla.suse.de/show_bug.cgi?id=278507 (http://bugzilla.suse.de/show_bug.cgi?id=9740) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2006-06-30 17:40:31) Klaus, do you now whether this is still an issue? #2: Klaus Kämpf (kwk) (2006-06-30 18:38:23) We still have very large packages (kernel, OpenOffice_org) which might not download completely in one go. #5: Milisav Radmanic (radmanic) (2006-09-08 15:25:57) (reply to #4) this applies to the media manager and Jiri already agreed to return this back to the YAST team, since Marius only helped out during CODE 10. Marius will of course help with the implementation, by sharing his knowledge. #7: Stanislav Visnovsky (visnov) (2007-11-23 10:32:46) Related to commit-refactoring. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:21:33) Klaus, are you still running ISDN? just kidding :-) Stano, please your opinion on workload - is this easily achievable? if not, there are hgher priorities. #10: Stanislav Visnovsky (visnov) (2008-06-20 13:10:21) (reply to #9) Jiri, could we get estimate for this? #11: Jiri Srain (jsrain) (2008-08-04 08:59:34) (reply to #10) Since curl itself does support resuming download, then this feature should not be hard to be implemented. #12: Ruchir Brahmbhatt (ruchir) (2009-01-17 12:07:25) I also vote for this feature. #13: Dmitry Mittov (michael_knight) (2009-01-19 09:01:09) It is also a great problem when you use slow mirror. download.opensuse. org redirects me to one of yandex mirrors (score 20). And I have timeout on big packages. #14: Piotrek Juzwiak (benderbendingrodriguez) (2009-01-21 18:17:13) I'd vote at least for a way to change the timeout settings for YaST or it doesn't solve the problem? #15: Alam Aby Bashit (init7) (2009-01-22 09:35:17) I'd like to vote this feature implemented in 11.2. You surely want to have resume capability if you have unreliable yet slow internet connection for say, updating KDE 4.2 :) #16: Duncan Mac-Vicar (dmacvicar) (2009-01-22 15:14:44) (reply to #15) Please stop this "I vote for this" or "+1" or "mee too" comments. There is no voting system in FATE yet, but following a discussion about "I want this too" makes hard to evaluate features. #17: James Mason (bear454) (2009-01-24 06:05:01) Could this be accomplished using a bittorrent backend instead of curl ? #18: Jan Engelhardt (jengelh) (2009-01-30 15:31:33) (reply to #17) ISDN is already slow as it is. I would not want to spend more time downloading just because of the metadata traffic that is going to happen. Not to mention what happens if there are no peers around or they configured themselves to upload-limit themselves. Still, most download.opensuse.org downloads are faster than a torrent for me. #19: Pascal Bleser (pbleser) (2009-03-02 08:42:26) Caching is one thing. But even using retries in curl would help, see "curl --retries". #20: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-23 16:38:17) It could be accomplished by using aria for downloading packages? There would be no more problems with timeouts and bad checksums ? #21: Ján Kupec (jkupec) (2009-04-23 17:36:18) (reply to #20) Actually we are already using aria in current development branch, so this is not so urgent anymore. Still, the download can be interrupted also in other ways than connection timeout, e.g. user decision, sudden power outage, etc... Does anyone know whether aria supports resuming? (Implementing this for the curl backend is not important anymore). #22: Markus K (kamikazow) (2009-04-25 12:49:41) (reply to #21) Yes, aria supports resuming -- even better than wget (don't know about curl), because aria uses the file size to check whether the to-be- downloaded file changed. #23: Peter Poeml (poeml) (2009-04-28 09:14:12) (reply to #21) It does. See section "Resuming Download" in its man page (http://aria2.sourceforge.net/aria2c.1.html#_resuming_download) ; and also note the -c option. + #24: T. J. Brumfield (enderandrew) (2009-06-12 23:35:43) + Perhaps as an addendum to this feature, I'd like to see the option to + set a number of automatic retries. + If Yast tells me it needs to download 3 gigs worth of packages, I don't + want to watch for one package to timeout, hanging the whole process up. + I'd like to configure it so that it will automatically retry the + package X times, then skip the package and move on. -- openSUSE Feature: https://features.opensuse.org/120326

1 0

[openFATE 306411] Configuration files merge
by fate_noreply＠suse.de 12 Jun '09

12 Jun '09

Feature changed by: Michal Hrusecky (-miska-) Feature #306411, revision 11 Title: Configuration files merge openSUSE-11.2: 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) -- openSUSE Feature: https://features.opensuse.org/306411

1 0

[openFATE 120373] Unified Button Labels
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature changed by: Michael Löffler (michl19) Feature #120373, revision 52 Title: Unified Button Labels openSUSE-10.3: Rejected by Stephan Kulow (coolo) reject date: 2007-07-30 10:43:50 reject reason: not enough resources to do it right Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2009-03-30 09:27:47 reject reason: Did not happen completely in time. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Klaus Kämpf (kwk) Description: Unify button labels YaST currently uses several different button labels for basically the same action, i.e. 'Ok', 'Accept', and 'Finish'. Decision: Only a single label per action should be used. Labels should be generally "OK" and "Cancel" for standard modules and "Back", "Next", "Cancel" and "Finish" for wizards. Documentation Impact: check YaST descriptions in manuals and update screen shots Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2006-06-27 11:36:42) I'm moving this from "future" to 10.3. 10.2 will share much with SP1, so we cannot make this kind of change there. Adding Coolo and Edith for usability and YaST, respectively. #2: Tanja Roth (ta-ro) (2007-06-11 16:37:21) This would also have documentation impact - we would have to check the YaST parts of the manuals and to redo a lot of screen shots, I guess. #3: Jiri Srain (jsrain) (2007-07-26 14:27:21) I don't think that we can solve this issue now, this must start being solved at the beginning of release cycle. Please, move to 11.0. #4: Stephan Kulow (coolo) (2007-11-20 11:48:19) the release cycle of 11.0 just started. Please kill Reject and Accept soonish. If I may add here: please do not overuse Ok and Cancel, but rather use explicit actions where appliying. "Do not delete 11 files? Ok/Cancel" is no-go, Delete/Cancel helps the user much more. #5: Jiri Srain (jsrain) (2008-03-10 13:36:56) (reply to #4) I don't think that such cases can be handled a different way than on the per-case basis as bugreports. #6: Jiri Srain (jsrain) (2008-03-10 13:39:16) This is the list of files which contain the Accept or Reject words (probably not complete and probably some of the files are superfluous due to non-perfect regext). Please, get rid of as many as possible of them. ./add-on/src/add-on_proposal.ycp ./add-on/src/inst_language_add-on.ycp ./apparmor/src/include/subdomain/reporting_archived_dialogs.ycp ./apparmor/src/include/subdomain/reporting_utils.ycp ./dhcp-server/src/dns-server-wizard.ycp ./fingerprint-reader/src/users_plugin_fingerprint_reader.ycp ./firewall/src/dialogs.ycp ./firewall/src/subdialogs.ycp ./ftp-server/src/complex.ycp ./ftp-server/src/dialogs.ycp ./inetd/src/dialogs.ycp ./installation/src/clients/inst_network_setup.ycp ./installation/src/clients/inst_proposal.ycp ./kdump/src/dialogs.ycp ./kerberos-client/src/dialogs.ycp ./ldap-client/src/LdapPopup.ycp ./ldap-client/src/ui.ycp ./live-installer/src/inst_live_simple_proposal.ycp ./ncurses-pkg/src/pkg_layout.ycp ./network/src/lan/complex.ycp ./nis-client/src/ui.ycp ./ntp-client/src/dialogs.ycp ./packager/doc/display_driver_popup.ycp ./packager/src/clients/inst_packages.ycp ./packager/src/clients/inst_productsources.ycp ./printer/src/common/dialogs.ycp ./registration/src/modules/Register.ycp ./restore/src/ui.ycp ./runlevel/src/runlevel_proposal.ycp ./samba-server/src/ldap-widget.ycp ./sound/sound/src/complex.ycp ./squid/src/complex.ycp ./storage/storage/src/inst_custom_part.ycp ./storage/storage/src/inst_prepdisk.ycp ./storage/storage/src/modules/StorageControllers.ycp ./system-update/src/system-update.ycp ./tune/hwinfo/src/newid.ycp ./tune/hwinfo/src/system_settings_dialogs.ycp ./update/src/clients/system_update.ycp ./update/src/clients/update.ycp ./update/src/include/rootpart.ycp ./users/src/dialogs.ycp ./users/src/users_plugin_ldap_all.ycp ./users/src/users_plugin_ldap_passwordpolicy.ycp ./users/src/users_plugin_ldap_shadowaccount.ycp ./users/src/users_plugin_quota.ycp ./yast2/library/modules/Label.ycp ./yast2/library/wizard/src/Wizard.ycp ./ycp-ui-bindings/examples/Wizard2.ycp #7: Martin Schmidkunz (mschmidkunz) (2008-03-10 17:18:59) Cool! When we are already touching the navigation buttons maybe we can also try to work out feature #303446 "Button order, positioning, labeling in YaST". Button order should be according to the selected desktop. If another desktop then KDE or GNOME is selected either KDE or GNOME button order should be used. The help button should be aligned left and the navigation buttons should be aligned right. Having too much space between the navigation buttons as we have no doesn't support grouping of buttons, which makes navigation difficult for the user. Labeling should be as stated in this feature. #8: Ladislav Slezak (lslezak) (2008-03-17 16:51:45) Fixed in yast2-sound-2.16.4, yast2-tune-2.16.0 and in yast2-packager- 2.16.27 #9: Arvin Schnell (aschnell) (2008-03-18 17:25:40) Is the decision documented in some style-guide? #10: Martin Schmidkunz (mschmidkunz) (2008-03-19 12:10:05) It is documented in http://en.opensuse.org/Image:Ysg.pdf However this is just a first draft which needs to be approved (FATE: 303041) #11: Jiří Suchomel (jsuchome) (2008-03-26 10:55:07) Done in yast2-ldap-client, yast2-fingerprint-reader, yast2-kerberos- client, yast2-nis-client, yast2-users #12: Jozef Uhliarik (juhliarik) (2008-03-27 10:18:07) Fixed in yast2-kdump-2.16.10, yast2-ftp-server-2.16.10 and in yast2- dhcp-server-2.16.7 #13: Arvin Schnell (aschnell) (2008-03-27 16:40:31) Done for storage. #14: J. Daniel Schmidt (jdsn) (2008-04-01 11:51:50) In case of registration the word "Reject" is used in context of a certificate. The user is asked to "Trust" or "Reject" the certificate. Changing it to "Trust" and "No" or to change the question and switch to "Yes"/"No" is not quite intuitive I think. So I'd keep the word "Reject" for registration. Btw: It will appear never in openSUSE but only during manual installation of a SLE product with registering agains a registration proxy aka. SMT. #15: Katarina Machalkova (kmachalkova) (2008-04-04 10:43:39) And what about installation proposals and installation clients? Are we suppose to substitute word "Accept" by something else there, too? If so, what is the suitable word in such case? Clearly not "Finish" (as it may let user think that it will finish the whole installation), is "OK" the right one then? #16: Martin Schmidkunz (mschmidkunz) (2008-04-04 11:21:54) What about using "Next"? #17: Jiri Srain (jsrain) (2008-04-04 10:51:20) (reply to #16) Next sounds to me like another step in a workflow should follow, which is not this case. I personally prefer simple "OK". #18: Lukas Ocilka (locilka) (2008-04-04 12:25:58) (reply to #17) I personally still prefer "Accept" as it was in the previous YaST Style Guide TM. But "OK" might work too. "Next" is definitely _not_ the right way to go. We have to distinguish between the main workflow and the step-workflows. #19: Martin Schmidkunz (mschmidkunz) (2008-04-04 12:33:28) (reply to #18) Why is it necessary to distinguish between main workflow and steps workflow? To the user it is just one installation process. Just out of curiosity: why is accepting the proposal not considered just another step in the installation workflow? basic settings => accepting proposal => perform installation #20: Lukas Ocilka (locilka) (2008-04-04 12:52:04) (reply to #19) For accepting the installation proposal, I'd even rather use [Install] than anything else. [Accept] has been used there because it's so important decision that in needs emphasizing. #21: Jiri Srain (jsrain) (2008-04-04 11:55:21) (reply to #19) Katarina's question was about the button e.g. in the partitioning dialog, not about the installation proposal as whole (if I understood it correctly). #22: Martin Schmidkunz (mschmidkunz) (2008-04-04 14:19:14) (reply to #21) Sorry for the misunderstanding and thanks for the correction! I suggest to use Cancel/OK as the only two buttons. Reason: the dialogs are side-steps from main installation workflow. I think now I got Lukas' comment about main worklfow and steps- workflow. :-) #23: Katarina Machalkova (kmachalkova) (2008-04-04 17:23:36) (reply to #21) Right, the partitioning dialog (or networking, gfx card, whatever) that is launched from installation proposal. For example, in yast2-network, we use (in the very same dialog) "Finish" on running system, but "Accept" in installation. My q. was whether to substitute the installation client's "Accept" button with something more suitable. #24: Lukas Ocilka (locilka) (2008-04-11 18:23:12) Changing Accept buttons to Install or Update (FATE #120373) >> yast2- installation-2.16.34 #25: Lukas Ocilka (locilka) (2008-04-11 18:45:41) Done in yast2-update-2.16.6 This is definitely going to break something as I can't check every change made... #26: Jiri Srain (jsrain) (2008-04-14 11:40:57) Most of the Accept/Reject buttons are gone now. Let's solve the remaining ones as bugs. + #31: Michael Löffler (michl19) (2009-06-09 15:39:44) (reply to #26) + Jiri, how much work needs to be done to clean it up by 100%? #27: Martin Schmidkunz (mschmidkunz) (2009-03-18 16:23:14) It is true that the Accept and Reject button labels are removed from the YaST modules. However the button labels are far from being unified. The biggest mess ist the crude mixture of "Cancel" and "Abort" labels and the second issue is the presentation of "Back" buttons which have the same functionality as "Cancel" but are shown in one screen configuration dialogs. The attempt to solve these issues via bugzilla (https://bugzilla.novell.com/show_bug.cgi?id=478089) revealed that this issue seems to aquire some ressources. One main reason for button labeling trouble seems to be that wizard.ycp is used in many places where the dialog is not a wizard, but where it is an overview. To get a professional, consistent GUI and in order to reduce translation efforts and development of new YaST modules one possible solution might be the development of two different templates: * * wizard.ycp for wizards and installation and * * overview.ycp for edit/singe configuration/overview dialogs Some possible layouts can be viewed at: * http://en.opensuse.org/Image:Wizard_dialog.png * http://en.opensuse.org/Image:Overview_dialog.png Buttons could use something like the button box widget developed sh or the button label widget developed by mzugec. As mentioned in the bug, it will take some effort and ressources but I think, that the outcomes will be worth it! #30: Martin Schmidkunz (mschmidkunz) (2009-04-01 15:39:33) The status of button labels in YaST (based on openSUSE 11.1/SLE 11) can be found at: http://en.opensuse.org/Media:Unified_buttons_yast.pdf Some basic numbers: * * 10 different button combinations for overview dialogs * * 5 different button combinations for wizard dialogs * * 3 different button combinations for progress dialogs Suggestions for a unification: * Use Cancel/OK for overview dialogs * Use Cancel/OK and Back/Cancel/Next (Back/Cancel/Finish) for wizards * Cancel for progress dialogs Necessary work for unified buttons in overview dialogs * Cancel/OK is already used in 28 of 78 overview dialogs * 50 overview dialogs which need adjustments (4 x relabeling 2 buttons, 9 x relabeling 1 button, 12 x hide 1 button, 25 x hide 1 Button and relabeling 2 buttons) Necessary work for unified buttons in wizard dialogs * Cancel/OK and Back/Cancel/Next are already used in 23 of 44 overview dialogs * 21 wizard dialogs which need adjustments (20 x relabeling 1 button, 1 x add “Cancel” button) Necessary work for unified buttons in progress dialogs * Cancel is already used in 3 of 46 progress dialogs * All progress dialogs can be easily adjusted by hiding “Back” and “Next” buttons and relabel “Abort” into “Cancel” in progress.ycp Final conclusions/questions * Unified button labels in wizards and progress dialogs can be achieved by just adjusting wizard.ycp and progress.ycp libraries * Overview dialogs need some manual adjustments as they base on wizards. ycp as well * Can adjustments be done by copying code from existing dialogs with OK/Cancel buttons (e.g. Date and Time)? * Does it make sense to invest into an overview.ycp dialog? -- openSUSE Feature: https://features.opensuse.org/120373

1 0

[openFATE 305591] Define purpose for each project
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305591, revision 6 Title: Define purpose for each project - Buildservice: New + Buildservice: Evaluation Priority Requester: Important Requested by: Pavol Rusnak (prusnak) Description: define purpose for each project, like: * add-on package * fresh packages + libraries (eg. games) * bleeding edge packages (eg. zypp:svn) * backports for older distributions (eg. zypp:Backport) * playground (eg. all home projects) So, * this sets users expectations * purpose could be indicated by naming conventions, or even better by project flags * purpose must be shown in the search result for this method to work References: http://lists.opensuse.org/opensuse-buildservice/2008-12/msg00056.html -- openSUSE Feature: https://features.opensuse.org/305591

1 0

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

09 Jun '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305168, revision 24 Title: default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-10 10:20:17 reject reason: This is too late for openSUSE 11.1. Postponing. Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: At least for desktops, we should reduce the memory and I/O thrash caused by atime updates, by using relatime. Relations: - bugreport from community (novell/bugzilla/id: 398616) https://bugzilla.novell.com/show_bug.cgi?id=398616 - Offers 'noatime' when 'relatime' is clearly better (novell/bugzilla/id: 461829) https://bugzilla.novell.com/show_bug.cgi?id=461829 Discussion: #1: Robert Davies (robopensuse) (2009-01-16 15:52:09) Bug #461829 is not requesting breaking POSIX semantics by default! relatime should replace noatime option in the mount options part of partioner tool, especially now it has been improved to update atime on file access if it's older than 24 hours. Standards are important, and LRU file caches cannot be relied on if noatime usage is common, or if poor backup software touches atimes, when reading files. #2: Sven Burmeister (rabauke) (2009-01-23 01:09:47) 11.1 is out and 11.2 getting started. Did anyone hear of ubuntu suffering from using relatime by default? If not, it seems likely that there are little to none issues. #3: Stephan Kulow (coolo) (2009-05-08 16:51:21) Matthias, I would think the easiest solution is replacing the current checkbox "use noatime" with "use relatime" and make it default (possibly per product). atime is a major pain for many systems where powersave and co are affected. #4: Matthias Eckermann (mge1512) (2009-05-11 15:52:11) (reply to #3) I am not perfectly happy, as a system crash could invalide the "atime"s with "relatime" switched on; looking for supporting information though, it seems, the broader Linux community is in favour of "relatime" (with remarkable exceptions); thus I propose: * introduce "relatime" as an independend parameter * keep the "noatime" checkbox in YaST * make "relatime" default on SSDs automatically * introduce a generic switch in YaST "defaultrelatime", which can be switched on/off per product * make "relatime" default "on" for the openSUSE product Does that help? #5: Jan Kara (jankara) (2009-05-11 16:33:11) This is a bit separate to how it will all look in Yast but I wanted to point out that in current Linus's tree (going to be 2.6.30) is a patch which changes kernel's default to 'relatime'. So unless we change something, all filesystems on this or newer kernel are going to be mounted as relatime (you have to specify 'strictatime' mount option if you really wish to keep atime). #6: Stephan Kulow (coolo) (2009-05-12 10:36:27) (reply to #5) then we can leave everything as it is actually and the feature is Done once we switch to 2.6.30 #7: Jan Kara (jankara) (2009-05-12 13:08:05) (reply to #6) Yes, the original request will be fulfilled. But I believe it would be good to have a selection in partitioner tool like: "Access time behavior: <relatime|noatime|strictatime>" anyway and make 'relatime' default. Also it is a question how to behave on update - the safest would be to add 'strictatime' to filesystems that don't have any atime setting but realistically it is probably better to ask user whether he agrees to switching to relatime and default to "yes". #9: Stephan Kulow (coolo) (2009-05-12 13:45:51) (reply to #7) completely different feature IMO and way more complex (and definitely over the top of openSUSE 11.2) #10: Duncan Mac-Vicar (dmacvicar) (2009-05-12 14:00:25) (reply to #7) Do we really need this extra options really? Is there a good usecase for it? I don't want to bring something to implementation because it is "good", "cool" or "nice to have". #11: Jan Kara (jankara) (2009-05-12 15:50:33) (reply to #10) User can always edit /etc/fstab by hand so strictly speaking it's not necessary. About the usecase - there really are people who want 'strictatime' for various reasons (well, most often they are just afraid that something can break). From my POV that is enough for substituting that 'noatime' checkbox we have currently with the selection I suggested but I admit I'm not the one who'll have to implement it ;-). Regarding the update - silently changing the behavior of atime seems kind of rough to users to me. At least we should warn them (release notes?) that this is happening and that they can add 'strictatime' to /etc/fstab if they have problems with the change. + #12: Andreas Jaeger (a_jaeger) (2009-06-09 15:36:15) (reply to #11) + Let's add something to the release notes for those updating - and not + do any other changes. -- openSUSE Feature: https://features.opensuse.org/305168

1 0

[openFATE 306231] provide config GUI for snd hda intel model selection
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature added by: Ludwig Nussel (lnussel) Feature #306231, revision 1, last change by Title: provide config GUI for snd hda intel model selection openSUSE-11.2: New Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Description: The intel HDA sound module is not always able to automatically detect the correct model of the sound card. This SDB page describes a long winded way to tell the module which model to use: http://en.opensuse.org/SDB:Intel-HDA_sound_problems It even requires installation of kernel-source just to get the docu file. The problem seems to be quite common on Laptops so yast should just offer a GUI option in the sound module to select the model. This probably requires a machine parsable file provided by alsa that can be read by yast. -- openSUSE Feature: https://features.opensuse.org/306231

1 6

[openFATE 305882] Create Custom Locale in YaST
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305882, revision 4 Title: Create Custom Locale in YaST - openSUSE-11.2: New + openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) + reject date: 2009-06-09 14:53:24 + reject reason: See comment. Priority Requester: Desirable Requested by: Stanislav Visnovsky (visnov) Description: In Gnome there is no easy way (GUI) to set date and time format independent of desktop language. I agree with the use of the locale framework in the Gnome desktop because locale should affect all apps, not just desktop ones, and I hope that KDE follows suit. However, regardless of what Gnome or KDE decides, a tool in YaST to create a custom locale (for apps using locale) and to at the same time set KDE desktop preferences or something similar would be benificial within YaST. In Suse 10.1 Gnome desktop and SLED 10 Gnome desktop it is very cumbersome to choose a default en_CA locale, US English keyboard, en_UK desktop language (since UK English spelling is closer to Canadian spelling), a Weekday Month Day, Year long format an ISO-8601 short date format (i.e. YYYY-MM-DD), and a 24hr time format. On other operating systems and in the KDE desktop it is easy to specify these regional settings (although the KDE settings only apply to KDE apps as far as I know). If there is already an easy way to set date format settings then please help me find it. Relations: - Create Custom Locale in YaST (novell/bugzilla/id: 188844) https://bugzilla.novell.com/show_bug.cgi?id=188844 Discussion: #3: Guy Lunardi (glunardi) (2008-12-09 15:36:53) Stano, I am cleaning up my bugs and finally got to this one. I think this could be useful indeed. A way to setup system-wide locale settings that would apply across the desktop environment and any other applications. This probably needs to be moved to Fate. Could we look into it for openSUSE 11.2 and SP1? + #4: Andreas Jaeger (a_jaeger) (2009-06-09 14:53:16) + Yes, it could be beneficial - on the other hand creating custom locales + is something that needs special care when glibc is updated and is only + usefull in some exotic use cases. Let's reject this for openSUSE. -- openSUSE Feature: https://features.opensuse.org/305882

1 0