July 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 302411] Always mount root-fs under /dev/root
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Jiri Srain (jsrain) Feature #302411, revision 27 Title: Always mount root-fs under /dev/root openSUSE-10.3: Rejected by Ihno Krumreich (ihno) reject date: 2007-09-26 11:51:40 reject reason: Not decited yet. So rejected. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-02-13 12:44:18 reject reason: We have a clear consense that we won't change anything for 11.0 that risks bootloader development (but rather concentrate on consolidating it) and as Jack outlined, it is a risk. Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Hannes Reinecke (hreinecke) Description: The root filesystem should always be mounted at /dev/root, which in turn is a symlink to the actual device node. This way we don't have to edit /etc/fstab if the root device is named differently (ie for automatic booting from degraded mirrors etc). And it would help with having always a consistent /etc/fstab, as /dev/root will be always present. Documentation Impact: + Discussion: #1: Ihno Krumreich (ihno) (2007-07-27 11:52:12) Effort/risk in YaST / bootloader? #2: Stephan Kulow (coolo) (2007-11-19 22:44:38) (reply to #1) who do you ask? #3: Joachim Plack (jplack) (2008-01-14 13:58:33) In principle having a symbolic link for a root device does not make a problem. But _changing_ the symlink might make the current bootloader configuration inconsistent. E.g. Having root=/dev/root in the bootloader config and pointing to /dev/md0 (mirror) hints to duplicate the boot code to two disks, changing the symlink to point to a single disk changed the semantics of the config. So the risk is that by changing the symlink and doing a kernel update one might invalidate the boot configuration resulting in a possible unbootable system. #4: Matthias Eckermann (mge1512) (2008-06-06 09:15:25) (reply to #3) I understand the risk, but the feature itself sounds useful enough. Part of bootloader discussion. Not mandatory for now. #5: Stanislav Visnovsky (visnov) (2008-07-07 13:57:06) (reply to #4) Jiri, please, take a look. #7: Jiri Srain (jsrain) (2009-06-01 13:57:08) For GRUB configuration itself, the root= kernel parameter can be omited completly for standard installations (since initrd handles mounting root itself). I hope that just modifying the partitioner to write fstab should be sufficient in basic cased. However, since YaST needs to know which real device /dev/root is, it needs to exist during installation and be set properly (according to the target system). Probably just creating the symlink manually during installation after mounting the disk and writing fstab is sufficient? #8: Stephan Kulow (coolo) (2009-07-16 11:58:50) yast already handles /dev/root (checked with arvin) and the bootloader and /etc/fstab should not be touched. Just the initrd needs mount differently. #9: Arvin Schnell (aschnell) (2009-07-16 12:10:50) (reply to #8) YaST needs modification when /etc/fstab should contain /dev/root as the device for root-fs (as the description says). After all YaST writes /etc/fstab during installation. + #10: Jiri Srain (jsrain) (2009-07-16 12:22:05) (reply to #9) + Arvin, please, remember to ensure that the symlink itself also exists + even during installation/upgrade. -- openSUSE Feature: https://features.opensuse.org/302411

1 0

[openFATE 302411] Always mount root-fs under /dev/root
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Arvin Schnell (aschnell) Feature #302411, revision 26 Title: Always mount root-fs under /dev/root openSUSE-10.3: Rejected by Ihno Krumreich (ihno) reject date: 2007-09-26 11:51:40 reject reason: Not decited yet. So rejected. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-02-13 12:44:18 reject reason: We have a clear consense that we won't change anything for 11.0 that risks bootloader development (but rather concentrate on consolidating it) and as Jack outlined, it is a risk. Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Hannes Reinecke (hreinecke) Description: The root filesystem should always be mounted at /dev/root, which in turn is a symlink to the actual device node. This way we don't have to edit /etc/fstab if the root device is named differently (ie for automatic booting from degraded mirrors etc). And it would help with having always a consistent /etc/fstab, as /dev/root will be always present. Documentation Impact: + Discussion: #1: Ihno Krumreich (ihno) (2007-07-27 11:52:12) Effort/risk in YaST / bootloader? #2: Stephan Kulow (coolo) (2007-11-19 22:44:38) (reply to #1) who do you ask? #3: Joachim Plack (jplack) (2008-01-14 13:58:33) In principle having a symbolic link for a root device does not make a problem. But _changing_ the symlink might make the current bootloader configuration inconsistent. E.g. Having root=/dev/root in the bootloader config and pointing to /dev/md0 (mirror) hints to duplicate the boot code to two disks, changing the symlink to point to a single disk changed the semantics of the config. So the risk is that by changing the symlink and doing a kernel update one might invalidate the boot configuration resulting in a possible unbootable system. #4: Matthias Eckermann (mge1512) (2008-06-06 09:15:25) (reply to #3) I understand the risk, but the feature itself sounds useful enough. Part of bootloader discussion. Not mandatory for now. #5: Stanislav Visnovsky (visnov) (2008-07-07 13:57:06) (reply to #4) Jiri, please, take a look. #7: Jiri Srain (jsrain) (2009-06-01 13:57:08) For GRUB configuration itself, the root= kernel parameter can be omited completly for standard installations (since initrd handles mounting root itself). I hope that just modifying the partitioner to write fstab should be sufficient in basic cased. However, since YaST needs to know which real device /dev/root is, it needs to exist during installation and be set properly (according to the target system). Probably just creating the symlink manually during installation after mounting the disk and writing fstab is sufficient? #8: Stephan Kulow (coolo) (2009-07-16 11:58:50) yast already handles /dev/root (checked with arvin) and the bootloader and /etc/fstab should not be touched. Just the initrd needs mount differently. + #9: Arvin Schnell (aschnell) (2009-07-16 12:10:50) (reply to #8) + YaST needs modification when /etc/fstab should contain /dev/root as the + device for root-fs (as the description says). After all YaST writes + /etc/fstab during installation. -- openSUSE Feature: https://features.opensuse.org/302411

1 0

[openFATE 302411] Always mount root-fs under /dev/root
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Stephan Kulow (coolo) Feature #302411, revision 25 Title: Always mount root-fs under /dev/root openSUSE-10.3: Rejected by Ihno Krumreich (ihno) reject date: 2007-09-26 11:51:40 reject reason: Not decited yet. So rejected. Priority Requester: Mandatory openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-02-13 12:44:18 reject reason: We have a clear consense that we won't change anything for 11.0 that risks bootloader development (but rather concentrate on consolidating it) and as Jack outlined, it is a risk. Priority Requester: Mandatory openSUSE-11.2: Evaluation Priority Requester: Mandatory Projectmanager: Important Requested by: Hannes Reinecke (hreinecke) Description: The root filesystem should always be mounted at /dev/root, which in turn is a symlink to the actual device node. This way we don't have to edit /etc/fstab if the root device is named differently (ie for automatic booting from degraded mirrors etc). And it would help with having always a consistent /etc/fstab, as /dev/root will be always present. Documentation Impact: + Discussion: #1: Ihno Krumreich (ihno) (2007-07-27 11:52:12) Effort/risk in YaST / bootloader? #2: Stephan Kulow (coolo) (2007-11-19 22:44:38) (reply to #1) who do you ask? #3: Joachim Plack (jplack) (2008-01-14 13:58:33) In principle having a symbolic link for a root device does not make a problem. But _changing_ the symlink might make the current bootloader configuration inconsistent. E.g. Having root=/dev/root in the bootloader config and pointing to /dev/md0 (mirror) hints to duplicate the boot code to two disks, changing the symlink to point to a single disk changed the semantics of the config. So the risk is that by changing the symlink and doing a kernel update one might invalidate the boot configuration resulting in a possible unbootable system. #4: Matthias Eckermann (mge1512) (2008-06-06 09:15:25) (reply to #3) I understand the risk, but the feature itself sounds useful enough. Part of bootloader discussion. Not mandatory for now. #5: Stanislav Visnovsky (visnov) (2008-07-07 13:57:06) (reply to #4) Jiri, please, take a look. #7: Jiri Srain (jsrain) (2009-06-01 13:57:08) For GRUB configuration itself, the root= kernel parameter can be omited completly for standard installations (since initrd handles mounting root itself). I hope that just modifying the partitioner to write fstab should be sufficient in basic cased. However, since YaST needs to know which real device /dev/root is, it needs to exist during installation and be set properly (according to the target system). Probably just creating the symlink manually during installation after mounting the disk and writing fstab is sufficient? + #8: Stephan Kulow (coolo) (2009-07-16 11:58:50) + yast already handles /dev/root (checked with arvin) and the bootloader + and /etc/fstab should not be touched. Just the initrd needs mount + differently. -- openSUSE Feature: https://features.opensuse.org/302411

1 0

[openFATE 306315] Improve PK/zypper/YaST Big Lock
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #306315, revision 3 Title: Improve PK/zypper/YaST Big Lock - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-07-16 11:45:36 + reject reason: no resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Federico Lucifredi (flucifredi) + Partner organization: openSUSE.org Description: Currently, execution of any action by one of the package management tools blocks all others, in a "big lock" fashion". This is entirely acceptable when I am doing something with YaST, or running the PK applet, but it is very fastidious when it is due to background activity. Running zypper and seeing that lock message when nothing is being run by the user is very annoying (and is really the same for Yum on RHEL - but it still sucks :-) Can we improve the way PK refreshing causes everything else to lock up? I must say I expect upstream to be doing something about this... Business case (Partner benefit): - The lock interferes with Administrator activity at random moments, and - is very aggravating. It would be a competitive detail over RHEL, as - well as a customer satisfaction item. + openSUSE.org: The lock interferes with Administrator activity at random + moments, and is very aggravating. It would be a competitive detail over + RHEL, as well as a customer satisfaction item. Discussion: #1: Federico Lucifredi (flucifredi) (2009-03-30 21:13:47) I am somewhat reluctant to give this an M, as I do not know if something can actually be done to improve this. It would certainly warrant an M if a good solution can be devised, as this is really annoying on both SLES and RHEL, and it would make us look good in the comparison. -- openSUSE Feature: https://features.opensuse.org/306315

1 0

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

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305503, revision 28 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - updateinfo XML scheme (url: http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/pa…) - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there #6: Michael Andres (mlandres) (2009-07-01 18:33:01) libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g search for patches with updateReferenceId "CVE-2007-5707', or of updateReferenceType 'bugzilla",... (I'll provide some sample code) @Jano: I'll provide some code example, that tells how to access and iterate the matching updateReferences. So you could start working on zypper. #7: Ján Kupec (jkupec) (2009-07-03 15:10:56) Thanx! I have a question about the reference types. What types do we support? in updateinfo.rnc (see references) i only see bugzilla and cve Do we want separate options for all supported types, like yum has? #9: Ján Kupec (jkupec) (2009-07-03 15:57:19) (reply to #7) Also, i noticed in 11.1 updates repository, that many bugs have a CVE, but it's only in the description, not in the 'reference' metadata. Only bugzilla is in 'reference'. Do we want to address this? #10: Marcus Meissner (msmeissn) (2009-07-03 15:59:21) (reply to #9) we are not emitting it yet. this also needs to be done :/ #8: Ján Kupec (jkupec) (2009-07-03 15:20:18) Suggestion how the commands could look like: $ zypper fix --search [string] $ zypper fix --bugzilla <#> $ zypper fix --cve <#> #11: Klaus Kämpf (kwk) (2009-07-04 12:11:44) (reply to #8) Please re-think about introducing another term ( fix ), we already have * update * upgrade * patch #12: Ján Kupec (jkupec) (2009-07-07 10:11:04) (reply to #11) What i try to achieve is to have a way to install the patches fixing the issues and a way to list them (issue number & patch name & (patch) description), search in them. The other alternatives i considered were: $ zypper patch [--bugzilla #] [--cve #] $ zypper list-patches --issues [string] The first command looks nice, but i don't know what to use to list/search the issues - the list-patches command does not seem right to me - looks more like it deserved a new command. $ zypper install [--bugzilla #] [--cve #] $ zypper search --issues [string] In this case, like in the 'list-patches --issues' case, the search command would either need to radically change its output, or user would need to call 'zypper patch-info the_found_patch' to get the patch description. Any other ideas? Why is having a new command a bad thing (esp. compared to having new options in the existing commands)? BTW: (We don't have 'upgrade' :O) #13: Martin Vidner (mvidner) (2009-07-07 14:33:03) (reply to #12) Why reinvent the wheel? Can we just copy yum's interface as described in the referenced yum-security article? * http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ (http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/) * http://linux.die.net/man/8/yum-security (http://linux.die.net/man/8/yum-security) #14: Ján Kupec (jkupec) (2009-07-07 14:57:27) (reply to #13) 'zypper update' does not work with patches. 'zypper patch' looks to me like better candidate for new --bz or --cve options. yum does not make difference between these two. The yum plugin also adds a new command (list-sec), which was Klaus' objection. #15: Klaus Kämpf (kwk) (2009-07-07 15:51:26) (reply to #14) Well, my objection is the new term 'fix' besides 'update' and 'patch' and will confuse people. It should be an option to "list" or "list-patches" imho #16: Ján Kupec (jkupec) (2009-07-07 16:16:12) (reply to #15) OK, so far the following looks like a candidate (taken yum into account as well): # to install a fix $ zypper patch [--bz #] [--cve #] [--any-other #] # to list available needed fixes (issue-number, patchname-version, category, description) # all $ zypper list-patches --issues # matching a substring ("CVE", number, or any) $ zypper list-patches --issues foo # only CVEs/bugzillas $ zypper list-patches [--cve] [--bz] #17: Ján Kupec (jkupec) (2009-07-15 09:24:34) Done in zypper. You can fetch zypper 1.2.2 from home:jkupec:Factory to try and let me know what you think. New options in lp and patch commands: $ zypper help lp -b, --bugzilla[=#] List needed patches for Bugzilla issues. --cve[=#] List needed patches for CVE issues. --issues[=string] Look for issues matching the specified string. -a, --all List all patches, not only the needed ones. $ zypper help patch patch [options] -b, --bugzilla # Install patch fixing the specified bugzilla issue. --cve # Install patch fixing the specified CVE issue. --bz works, too. Can this feature be closed, or we'll close it after the repo metadata have the CVE references? #18: Ján Kupec (jkupec) (2009-07-15 09:30:38) One more thing that crossed my mind when looking at the yum article http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ They seem to be able to associate issue numbers with spcecific packages. I'm not sure if this is because they just avoid issuing updates with plenty of packages in single <update> tags, like we often do? + #19: Christoph Thiel (cthiel1) (2009-07-16 11:33:39) (reply to #18) + Rudi, is autobuild planning to adding additional information to the + metadata? -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 305394] Move KDE software updates notifications to upstream infrastructure
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #305394, revision 24 Title: Move KDE software updates notifications to upstream infrastructure - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) + reject date: 2009-07-16 11:29:01 + reject reason: out of resources for 11.2. Priority Requester: Important Projectmanager: Important + openSUSE-11.3: New + Priority + Requester: Important Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: As kpackagekit matures, it may be the case that for 11.2 it is mature enough for replacing kupdateapplet. It already implements various aspects of kupdateapplet: * notifications (knotify) using a kded service (which takes care of refreshing too) * single update selection (kpackagekit gui) * uses a upstream client library for communication with PackageKit, which are better than our PackageKit communication code. Scope kpackagekit is meant here only to replace kupdateapplet. There is not relation with YaST here. Open Issues: * tray notification: may require implementing a plasma tray icon * SUSE specific code (smolt, registration, hardware search) * Requires some research how to introduce those extensions in kpackagekit, or move SUSE specific parts out, like another kded service. User experience Should stay the same Dependencies * PackageKit * libpackagekit-qt Contingency Plan In the case kpackagekit is not yet mature enough, the same resources invested now in kupdateapplet can be invested in improving kpackagekit. Otherwise, we can stay with kupdateapplet as a fallback. Relations: - kpackagekit author interview (url: http://polishlinux.org/kde/kpackagekit-interview/) - kpackagekit screenshot (url: http://www.packagekit.org/img/kpk-update.png) Test Case: * new patches should be notified by knotify * user should be able to see update availability * user should be able to see detailed update information, as well as selecting individual updates * user should get informed if the update repositories configuration has a problem * user should be informed of (available) drivers for plugged hardware Business case (Partner benefit): openSUSE.org: Right now software notifications are done using the kupdateapplet, which comes from the opensuse-updater code,(renamed in a non sucessful attept to upstream it). This applet come from a summer of code project, originally done as a zmd client, then evoluted to a zypper client, and now working as a PackageKit client. Sadly, during 10.3 cycle this applet got the feature to select updates individually and other small stuff which turned it into a very complicated piece of code, and started to became a package manager on its own. Later it became the favorite place to plug any kind of notifications, like registration needed, smolt participation, etc, and right now the code is much more complex that it should be (thus taking more maintenance and testing than it should require). This feature has the objective of cleaning up this situation to free resources in this area. With the progress of packagekit and recently, kpackagekit, this should be possible. kpackagekit already implements various of the needed aspects, and therefore it would mean getting rid of in house code for upstream code. Additionally, it would result in a much more consistant user experience as the tools would be similar across distributions. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:24:20) Looks like Duncan is in favor of this. Stano? If you guys are comfortable with the change, I am all for it. But remember, priority #1 is dist-upgrade. #5: Duncan Mac-Vicar (dmacvicar) (2009-06-02 18:00:54) I will evaluate this feature later, we don't know the status of KPackageKit, we have the package and Thomas contributed patches, so only the decision to switch or not to switch is important. Feedback from the KDE team about upstream KDE 4.3 would also be useful. -- openSUSE Feature: https://features.opensuse.org/305394

1 0

[openFATE 305313] creating nonexistent directories with Autoyast
by fate_noreply＠suse.de 16 Jul '09

16 Jul '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #305313, revision 13 Title: creating nonexistent directories with Autoyast - openSUSE-11.2: Evaluation + openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important Requested by: Uwe Gansert (ug) Description: from bug #429491 It should be possible to create directories just like files with its permissions and ownership. Today it is impossible (using just "files") to put for example /root/.ssh/authorized_keys. To anticipate possible comments, the "file_script" is not IMHO the right way to deal with the problem since it is invoked after writing the file to a filesystem. Yet it may be considered a workaround as of today. Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 14:19:55) up for Engineering's comment. Is workaround adequate ? #2: Milisav Radmanic (radmanic) (2009-04-16 14:06:01) The workaround is effective but technically not adequate. We should support creating directories like we do it for files. The request is off the mailinglist and makes sense. #3: Stanislav Visnovsky (visnov) (2009-05-28 16:41:02) Isn't it better to have support for untarring root.tar.gz to the filesystem like kiwi does? #4: Uwe Gansert (ug) (2009-06-04 15:37:40) (reply to #3) the idea of untaring a tgz is actually not that bad but in this case I'd prefer to keep it simple. A tgz needs to be stored in base64 format inside of the XML and it's not obvious what's in it by looking at the XML file. Changing something in that is a bit complex too, compared to simply use a text editor and change the XML file. People who need to add so many files/dirs that it's too much for the "files" section can do that with a tgz+scripts combination already. For smaller changes (which is enough for many customers from my experience) the clearly represented "files" section is better I think because you can see immediately what happens just by looking at the XML file. -- openSUSE Feature: https://features.opensuse.org/305313

1 0

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

16 Jul '09

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

1 0

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

16 Jul '09

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

1 0

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

16 Jul '09

Feature changed by: Christoph Thiel (cthiel1) Feature #120373, revision 53 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 + 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: New + 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