January 2010 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308881] Mark YaST2 repositories that received new changes after refresh
by fate_noreply＠suse.de 25 Jan '10

25 Jan '10

Feature added by: René Krell (renekrell) Feature #308881, revision 1 Title: Mark YaST2 repositories that received new changes after refresh openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: René Krell (renekrell) Description: I would like to easily find repositories in the YaST2 repository view, which received changes after refreshing them. This could be done by marking them (for instance with a font color or an additional column with the number of new changes against the state before) in the repository list. -- openSUSE Feature: https://features.opensuse.org/308881

1 0

[openFATE 120373] Unified Button Labels
by fate_noreply＠suse.de 24 Jan '10

24 Jan '10

Feature changed by: Roman Bysh (Romanator) Feature #120373, revision 55 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: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 11:08:56 reject reason: out of resources for 11.2. Priority Requester: Desirable openSUSE-11.3: 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? + #32: Roman Bysh (romanator) (2010-01-24 23:56:12) + This is long overdue and should be considered. If not in 11.3, it + should be for 12.0. -- openSUSE Feature: https://features.opensuse.org/120373

1 0

[New: openFATE 308879] Qt version of package installer should allow queries with more than one word
by fate_noreply＠suse.de 24 Jan '10

24 Jan '10

Feature added by: Alessandro Serra (algarues) Feature #308879, revision 1 Title: Qt version of package installer should allow queries with more than one word openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Requested by: Alessandro Serra (algarues) Description: The gtk version of yast package installer allow to search packages using more than one word in the search box. This allow to narrow your search much better than the Qt counterpart which allows only one word, often ending in too many results to go through. If also the Qt version of package installer allowed multi-word based searches, its usability would be considerably improved. -- openSUSE Feature: https://features.opensuse.org/308879

1 0

[New: openFATE 308875] user friendly fsck handling
by fate_noreply＠suse.de 23 Jan '10

23 Jan '10

Feature added by: Andi N Kleen (andikleen2) Feature #308875, revision 1 Title: user friendly fsck handling openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Andi N Kleen (andikleen2) Description: Probably too late for 11.3, but perhaps for 12.0 (but I don't have a category in fate for this) One long standing problem in Linux is that when there's a fsck and the fsck finds an error (common after reboots) after IO errors which force fsck) the fsck interactive interface is very user unfriendly and hard to handle for a newbie and even for experienced users. I believe the situation could be significantly improved with a few tweaks. This is for ext2 fsck, but applies similarly to other fscks (e.g. btrfs, xfs) First it asks a lot of questions for many, but basically everyone presses return anyways. Then there is no straight forward summary on what went wrong and a pointer to the files that ended up in lost+found When could be done better: - When fsck finds an error it should first ask "Shall I do unattended automatic fsck" and then run the fsck like -y That should default to "Yes" with a reasonable timeout (e.g. 60s) (possibly a autoyast/yast settable setting to not do the timeout) - The fsck should print a summary at the end that gives an overview: * How bad the problem is * How many files ended up in lost+found * How many files are lost ... - That overview should be visually distinctive (e.g. different background color) - Possible also have a timeout where it is displayed while the boot is stopped (e.g. 30s) - This could be either implemented by patching fsck or run fsck under a frontend that parses the output (the later might be more scalable to other file systems) - A logfile of the problem should be safed in /dev/shm (writable even with ro root) Then when the desktop starts it should check for the log file in /dev/shm and when it's there display a dialog box "There was a file system check error ...". This dialog box should have a link to open lost+found in the file browser, so that the user can copy files away (open: might need to ask for root password to access it?) -- openSUSE Feature: https://features.opensuse.org/308875

1 0

[openFATE 307196] Buildservice: Accepting of Submissions only with Successfully Build Packages
by fate_noreply＠suse.de 22 Jan '10

22 Jan '10

Feature added by: Andreas Jaeger (a_jaeger) Feature #307196, revision 1 Title: Buildservice: Accepting of Submissions only with Successfully Build Packages Buildservice: Evaluation Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Partner organization: openSUSE.org Description: I recently noticed that somebody submitted a package to openSUSE:Factory (and it got checked in) that has never ever build in the build service since it has obvious packaging problems (the %setup step did not work at all plus many more problems). I propose that "osc request show" informs the reviewer about the build status of the package. Additionally, "osc accept" should ask for confirmation if the package has not build successfully. Business case (Partner benefit): openSUSE.org: This will help to not have packages that do not build at all. -- openSUSE Feature: https://features.opensuse.org/307196

1 3

[openFATE 307480] Development of .spec files - .specfile editor and wizard
by fate_noreply＠suse.de 22 Jan '10

22 Jan '10

Feature added by: Glenn Doig (doiggl) Feature #307480, revision 1 Title: Development of .spec files - .specfile editor and wizard Buildservice: Unconfirmed Priority Requester: Important Requested by: Glenn Doig (doiggl) Description: Hello, Can this tool be included to help and assist on the creation of .spec files ?. http://wiki.eclipse.org/Linux_Tools_Project/SpecfileEditor/User_Guide (http://wiki.eclipse.org/Linux_Tools_Project/SpecfileEditor/User_Guide) The Specfile Editor plug-in provides a wizard for creating new .spec files too. Cheers Glenn -- openSUSE Feature: https://features.opensuse.org/307480

1 1

[openFATE 307474] Show link-tooltip also in stage succeeded with info from build-compare
by fate_noreply＠suse.de 22 Jan '10

22 Jan '10

Feature added by: Jan-Simon Möller (dl9pf) Feature #307474, revision 1 Title: Show link-tooltip also in stage succeeded with info from build-compare Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Jan-Simon Möller (dl9pf) Description: Use-Case: If a package is in status "Finished" we already display e.g. "new build"/"no change" info. We should show the same data also in state succeeded when hovering the link. It helps on large projects to keep easily track on unchanged build. -- openSUSE Feature: https://features.opensuse.org/307474

1 1

[openFATE 307735] "Publish on Build Success" mode
by fate_noreply＠suse.de 22 Jan '10

22 Jan '10

Feature changed by: Adrian Schröter (adrianSuSE) Feature #307735, revision 3 Title: "Publish on Build Success" mode - Buildservice: Unconfirmed + Buildservice: New Priority Requester: Important Requested by: Stephan Binner (beineri) Description: It would be good to have a publishing mode which runs only if all packages of a project have built successful (no fail, no expansion errors, no broken) to prevent syncing out of a likely broken/non- installable state. This would be especially useful for automatic upgraded snapshots with a whole chain of interdepending packages. + Discussion: + #1: Adrian Schröter (adriansuse) (2010-01-22 16:20:31) + Should be a "publish only if no fail/broken/expansion errors exist) -- openSUSE Feature: https://features.opensuse.org/307735

1 0

[openFATE 307841] distributed computing for build service
by fate_noreply＠suse.de 22 Jan '10

22 Jan '10

Feature added by: Adam Mizerski (etamPL) Feature #307841, revision 1 Title: distributed computing for build service Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Adam Mizerski (etampl) Description: Facts: Build service is overloaded. Now there is about 5000 packages in i586 waiting queue and the same in x86_64. Few days ago it was 3000, so it's growing. My idea: Distributed packaging using BOINC (http://boinc.berkeley.edu) platform. I think that for security reasons big and important packages (like kernel) should be build on OBS build hosts, but everything else can be distributed. -- openSUSE Feature: https://features.opensuse.org/307841

1 4

[openFATE 307840] add aggregate next to link package in web client
by fate_noreply＠suse.de 22 Jan '10

22 Jan '10

Feature added by: Adam Mizerski (etamPL) Feature #307840, revision 1 Title: add aggregate next to link package in web client Buildservice: Unconfirmed Priority Requester: Important Requested by: Adam Mizerski (etampl) Description: Creating aggregations, where features of linking (like project patches) are not needed, will unburden build hosts. If there is no option in web client to create them, beginners will create links and create unneeded load of packages to compile. -- openSUSE Feature: https://features.opensuse.org/307840

1 1