February 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305701] allow more customization in "Automatic Configuration" installation mode
by fate_noreply＠suse.de 09 Feb '09

09 Feb '09

Feature changed by: Stephan Kulow (coolo) Feature #305701, revision 3 Title: allow more customization in "Automatic Configuration" installation mode - openSUSE-11.2: Evaluation + openSUSE-11.2: Duplicate of #303859 Priority Requester: Important Requested by: Stefan Assmann (assmannst) Description: In openSUSE 11.1 there's this feature called "Use Automatic Configuration" which saves you a lot of time during second stage of the installation. However it makes some decisions which you might want to make yourself. This could be further improved, explanation following. In the first stage we have the global overview called "Installation Settings" where you can ultimately revise your settings. In case of an "automatic configuration" this panel should also allow to customize: * basic network settings * firewall At the moment the behavior is that network will be configured somehow YaST thinks it should be right in the second stage and the firewall will always be turned on, allowing no ssh login after installation. That gives the good idea of "Automatic Configuration" a bad after- taste. Having this customizable during first stage is a good step further down the road of an easy, well integrated installation process -- openSUSE Feature: https://features.opensuse.org/305701

1 0

[openFATE 305326] 5 Second Boot
by fate_noreply＠suse.de 09 Feb '09

09 Feb '09

Feature changed by: Stephan Kulow (coolo) Feature #305326, revision 8 Title: 5 Second Boot - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stephan Kulow (coolo) + reject date: 2009-02-09 15:47:52 + reject reason: Sorry to be harsh, but this feature can't be implemented + as asked for. Priority Requester: Mandatory Requested by: Jared Allen (jpallen) Partner organization: openSUSE.org Description: The amount of time required to boot up needs to be reduced drastically. I suggest we consider the work being done in this article: http://lwn.net/Articles/299483/ as our baseline and strive to make similar adjustments. Business case (Partner benefit): openSUSE.org: As we continue to get more involved in the Thin Client and UMPC markets, boot time becomes increasingly important. Intel's Moblin project is touting boot time as one of the significant features/advantages of their Moblin project. There are signs that other distros are following suit. We have at least one Thin Client partner that is requesting significant improvements in boot time in order to remain competitive. In fact, SLETC would have been included on more thin client hardware shipments to-date had we a faster boot time. Discussion: #1: Jared Allen (jpallen) (2008-10-06 17:03:30) I spoken with both AJ and Michael Meeks regarding this requirement. AJ suggested that include Coolo in the discussion since it will most definitely affect the distribution as a whole. #2: Stephan Kulow (coolo) (2009-01-20 15:18:14) similiar adjustments? Do you mean the "We had to do a lot of damage to X," part or the "use xfce" part? There is a limit on what you can do in a generic system and many of the low hanging fruits is already done. If you talk about getting a thin client to boot fast, then making transparent use of suspend & resume is the way to go IMO. Booting off cold hardware is problematic if you want more than xfce. There are about 100MB data to read for a pretty standard KDE session (and I assume GNOME is similiar) - on a pretty fragmented file system you get ~8MB/s netto - so just reading your files takes already 12s. Making preload dynamic on the blocks actually used is something that was discussed long, long ago, but the kernel still doesn't provide the infrastructure - so this is one of the TODOs, but possibly Intel got that ball rolling. Kernel drivers being quicker with probing would be another TODO, also listed in the article. Another urgent TODO is defragmentation because readahead helps only a little if the next update will scatter the files around your 1TB hard drive. -- openSUSE Feature: https://features.opensuse.org/305326

1 0

[openFATE 305622] Add support for lzop compression to GNU tar
by fate_noreply＠suse.de 09 Feb '09

09 Feb '09

Feature changed by: Stephan Kulow (coolo) Feature #305622, revision 13 Title: Add support for lzop compression to GNU tar openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Neutral Requested by: Matthias Eckermann (mge1512) Description: (iaW) update to tar 1.21 Use Case: 'tar' is one of the most important archiving tools for Linux and Unix- like systems in general. Our version should be capable of interacting with all other versions including the respective compression algorithms and tools. Discussion: #1: Jan Engelhardt (jengelh) (2009-01-19 09:32:51) tar --use=lzop -cf foo.tar.lzop #2: roland kletzing (rkletzin) (2009-01-20 21:44:53) shouldn`t we first have lzop package being part of the distro/factory, before make standard tools using it? (also see https://bugzilla.novell.com/show_bug.cgi?id=461228) it`s on the wishlist for a long time now, glad to see that we have openFate now (since adding to the wishlist was as good as talking to a wall) -- openSUSE Feature: https://features.opensuse.org/305622

1 0

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

05 Feb '09

Feature changed by: Andri Andreas Priyanto (turtlix) Feature #305296, revision 21 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. + #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) + I haven't use beagle since I install openSUSE, and maybe wouldn't or + never But I don't know other user. + I always remove beagle from my gnome-session-properties. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

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

04 Feb '09

Feature changed by: Federico Lucifredi (flucifredi) Feature #305634, revision 63 Title: Debian-like dist-upgrade live system full version upgrade openSUSE-11.2: Evaluation Priority Requester: Mandatory Info Provider: Robert Davies (robopensuse) Requested by: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: With the 11.2 cycle, we want to offer users the ability to perform a live system upgrade in the manner of Debian's dist-upgrade. For the purpose of this cycle, we want to support dist-upgrade from the previous version (11.1) only, as this is a sufficiently complicated problem as is. From the user's view, the difference is between being able to update the system incrementally within the given version or service pack running, to being ble to migrate with a system command ("zypper dup" or similar) to a higher version altogether. In the Debian experience, the set of base distributions is not necessarily limited, but it has been Ubuntu's practice to define what starting points other than "release n-1" are allowed (for instance, all LTS versions are purported to be able to "apt dist-upgrade" to the top of the line, although I have heard of problems trying to jump two years - 6.06->8.10 - in a fell swoop in this manner :-). In the openSUSE scope, we should aim to be able to "dup" between incremental versions, starting from 11.1 to 11.2, and later 11.x to 12.0. Business case (Partner benefit): openSUSE.org: With the introduction of the Zypper stack to SLE, we finally reached the state of a featureful (which YOU was not) and fast, reliable (which ZLM was not) update stack in the platform. For enterprise use, some tweaks are still desirable (changelogs, rollback, ...) which we are looking at, as well as improvements on the Enterprise management front, which we are working on with our SRM colleagues. The only really significant competitive feature we are missing at this point is the Debian/Ubuntu dist-upgrade functionality, which has a powerful psychological impact at the Enterprise level and a much more tangible impact at the small user / single user level: many with no IT department do use Ubuntu these days on the basis that "chasing" Fedora and openSUSE along the six-month upgrade cycle is too much for them, and feel they can save time on Ubuntu with the combination of dist- upgrade and the longer LTS cycle. The rationale for pursuing this is to revoke the special status of coolness this functionality gives Ubuntu, and to terminate the negative influence that may have on our SLE sales (from the expert's personal opinion, the preference then easily spills into purchasing). Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-07 20:42:15) This is the #1 feature in the systems management scope for 11.2 - I have no doubt it will be fun :-) #4: Klaus Kämpf (kwk) (2009-01-09 11:32:53) Passing to mls for technical evaluation (solver + autobuild) #5: Michael Schröder (mlschroe) (2009-01-09 12:48:10) Any hint on what features are currently missing? #6: Klaus Kämpf (kwk) (2009-01-09 13:30:57) (reply to #5) From the top of my head: How to handle * Library ABI changes (e.g. major gcc/g++ upgrades) ? * Core package changes (e.g. devs.rpm to udev) ? * Kernel changes (if application/deamons need a specific kernel abi, dbus comes into mind) ? * Failure handling (network breakdown, package update errors, ...) ? * Booting of the new kernel ? #7: Michael Schröder (mlschroe) (2009-01-09 14:45:09) (reply to #6) And debian does this in some way? #8: Robert Davies (robopensuse) (2009-01-17 12:43:42) (reply to #7) The distupgrade feature differs from changing source list and doing upgrade, so some utility process could be started. They may require some documented procedure to be followed, for "tough" changes. But ABI change, how long since ELF/glibc was introduced? C++ ABI ought not be relevant for upgrade process, they are "just" applications and libaries to be updated. Failure handling - you are told to back up your system first, it is "best effort" not guaranteed. The less you have installed the more likely it is to succeed. Debian offer choice of kernels, this may "punt" the problem to a user controlled install and select from GRUB menu. Debian have apt-cache possibility, to create central pool of packages, to decrease liklihood of network troubles, as well as huge number CD and DVD iso's. #9: Thorsten Kukuk (kukuk) (2009-01-17 15:24:35) (reply to #8) The glibc internal ABI changes frequently. Means, running applications will continue to use the old glibc with the old ABI, but installed are already the new plugins => running applications can crash. #12: Robert Davies (robopensuse) (2009-01-31 15:36:30) (reply to #9) But your upgrade tools are buggy if they are built to rely on "plugins". If you try to dist upgrade a live system within GUI, with all software running, and no breakage, you aim impossibly high. The point is, Debian have had very positive user comments for years about this feature, despite there being many caveats and no guarantee of success. #13: Robert Davies (robopensuse) (2009-01-31 15:42:55) (reply to #12) That wasn't clear. The upgrade tools are built so they won't suffer from changes. It is reasonable to ask user to not be running uncessary applications during a dist upgrade. #16: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:19:55) (reply to #12) Thorsten is talking about general applications. Not plugins. #10: Cristian Rodríguez (elvigia) (2009-01-20 03:36:38) (reply to #8) ABI is important during the upgrade process, I have seen applications crashing if you upgrade running a desktop enviroment, however we need to worry more about other stuff first IMHO. #11: Duncan Mac-Vicar (dmacvicar) (2009-01-29 16:51:48) I think the "Debian" part of the title is missleading if what we want is just to support dup officially. I would like to see a list from some "Debian expert" on how to Debian handles the issues Klaus described above. Appart of the network failure (included in another feature: commit) I ignore (and did not experience during my old Debian times) if Debian does anything special on dist- upgrade which give them the honour to name this feature "Debian like". Otherwise this feature should be closed as "done", (or just waiting for the commit refactoring). Federico, as you named the feature "Debian-like", It would be helpful to know, appart of the download-first feature, what are you missing from Debian so we can reach that point. #14: Robert Davies (robopensuse) (2009-01-31 15:54:26) (reply to #11) Technically you may be right, but that does not solve the perceived problem for end users who want a very well tested, and documented upgrade path. 11.1 shipped with release notes without solutions for problems folk hit (eg) PAM stuff). #15: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:22:12) (reply to #14) Exactly, but if we don't know what specific problems are we hitting during distupgrade the feature has no real work and specific problems can be tracked as bugs. FATE is not a place for "make this better" without concrete requirements or "make an unfalible distupgrade". If requester, prjmgr, or pm expects anything to be done in the area, we need at least: * A list of problems we hit during dist upgrade (I am aware of one specific, which is download-install sequence if network goes down) * The scope. As you mention, asking to close every application (or service) is not much to ask. Therefore the scope has to be set, because if the scope is "distupgrade and glbc upgrade while oracle process hospital monitoring equipment transactions" then this is a very expensive feature. #17: Duncan Mac-Vicar (dmacvicar) (2009-02-02 10:21:02) (reply to #14) btw, can you describe in technical detail the pam upgrade problem so we can document it? #18: Thorsten Kukuk (kukuk) (2009-02-02 10:26:58) (reply to #17) Yes, the PAM maintainers would like to know more details, too. #19: Robert Davies (robopensuse) (2009-02-02 13:45:04) (reply to #18) There were a number of different forum poster's hitting it, just after 11.1 released (I think due to zypper dup not YaST upgrade and therefore unreported to BugZilla). It is not something I had, because I did fresh installs. Interestingly though I have used Debian less, I have done several dist-upgrade's, simply because it is expected to work well. So it is a mistake to focus on specific tech issues alone. This problem is also about expectations and user perceptions. Announcing "support" for dist upgrade and appealing for test, so work rounds can be found, for release notes at time matters to. #21: Cristian Rodríguez (elvigia) (2009-02-02 15:29:32) (reply to #19) as you failed to elaborate on the problem, I will.. Some people end with broken /etc/pam.d/login they have the following line session required pam_resmgr.so but that module is gone, and rpm upgrade does not remove that line (probably because that file has been modified) #24: JP Rosevear (jproseve) (2009-02-02 10:15:19) (reply to #21) Isn't that simply a packaging problem? #25: Klaus Kämpf (kwk) (2009-02-02 19:42:45) (reply to #24) In this case, it looks like a packaging problem, indeed. However, we had more complicated upgrade tasks in the past, like dropping devs.rpm and running udev instead. See Removing devs.rpm (http://en.opensuse.org/Software_Management/Upgrade/Devs_Rpm) for a discussion of the problem. #26: Klaus Kämpf (kwk) (2009-02-02 19:43:24) (reply to #21) Whats the bug number for this problem ? #20: Robert Davies (robopensuse) (2009-02-02 14:48:34) On Scope, here are the Release Notes for Lenny - http://www.uk.debian.org/releases/testing/amd64/release-notes/ 4.1.4 - Prepare a safe environment for the upgrade - text mode or via ssh login, Article on how to go from Etch to Lenny - http://www.debianadmin.com/howto-upgrade-from-debian-etch-40-to-lenny-50.ht… + #27: Federico Lucifredi (flucifredi) (2009-02-04 15:32:01) (reply to + #20) + this is very helpful, we should look at the bumps that Debian hits while + doing this. + On a separate note, just tried to "yum upgrade" frlom RHEL 5.2 to RHEL + 5.3, and it went without a hitch. There may be something to be gathered + from Fedora as well here. #22: Manuel Trujillo (toomany) (2009-02-02 15:44:44) I think this is a really helpful characteristic, because a lot of people like me, use openSUSE as server, and is a true hell to upgrade servers in any datacenter, at kilometers off distance. I hope this feature will be a reallity in the next 11.2. #23: Duncan Mac-Vicar (dmacvicar) (2009-02-02 15:46:27) (reply to #22) Please, if you just want to express your favorites, use the voting feature. Comments is for discussion around solving the problem itself. -- openSUSE Feature: https://features.opensuse.org/305634

1 0

[openFATE 100386] Support a verbose logging mode in yast
by fate_noreply＠suse.de 04 Feb '09

04 Feb '09

Feature changed by: Martin Vidner (mvidner) Feature #100386, revision 33 Title: Support a verbose logging mode in yast openSUSE-10.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-09-30 20:43:33 reject reason: for 10.3. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 10:24:26 reject reason: Postponing, needs more research. Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Federico Lucifredi (flucifredi) reject date: 2008-06-28 19:27:16 reject reason: fixing my typo. Mandatories in the past don't work (yet). Priority Requester: Important Projectmanager: Important openSUSE-11.1: Done Priority Requester: Important Projectmanager: Important SL-10.0: Rejected by Andreas Jaeger (a_jaeger) reject date: 2005-12-02 14:56:13 reject reason: not done. Priority Requester: Desirable Requested by: Andreas Jaeger (a_jaeger) Description: Create a verbose logging mode in yast, where any action yast performs is logged. Any file yast touches should be logged (to /var/log/YaST2/y2log AND clean up the structure of that log file, to make it easier to read and interpret) and all changes on the systems configuration. The goal is to make it really transparent what yast does. Documentation Impact: Admin guide needs to contain information about the new log file. Please add it to the Log file section in the troubleshooting chapter Discussion: #1: Edith Parzefall (emapedl) (2006-09-28 17:17:54) Can't be done for 10.2. Back to TPMs. #2: Edith Parzefall (emapedl) (2007-07-31 16:17:45) Sorry, couldn't be done for 10.3. We need a concept for this. Even within the team different developers have different needs. Improving the logging to give all developers the best possible debugging information will be difficult, but it's definitely something we should attempt in the near future. #3: Stanislav Visnovsky (visnov) (2007-11-08 10:48:48) Can we get some traction here finally? #4: Stanislav Visnovsky (visnov) (2007-11-28 10:16:38) Reopening, the YaST transparency is often cited as a problem for users. #6: Federico Lucifredi (flucifredi) (2008-06-28 17:13:54) I think this has enough user benefit and is trivial enough, we should just get it done. #12: Stanislav Visnovsky (visnov) (2008-09-10 11:03:50) I've added y2useritem and y2usernote builtins into yast2-core. This might be helpful for this feature. + #14: Martin Vidner (mvidner) (2009-02-04 16:17:39) + I have added the two functions to yast2-perl-bindings-2.18.0 (for oS + 11.2). -- openSUSE Feature: https://features.opensuse.org/100386

1 0

[openFATE 305336] Ship man page for every executable
by fate_noreply＠suse.de 04 Feb '09

04 Feb '09

Feature changed by: Matthias Eckermann (mge1512) Feature #305336, revision 22 - Title: [NONCODE] Ship man page for every executable + Title: Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Description: 1. Even graphical applications need docs outside the application itself. The need to run the application, to know what does it does, is not good. 2. You need a standard documentation format; where standard = expected for people needing that documentation. Who are, often, not knowing the distro well (so the format can't be distro-specific). And the format must be the same for all binaries/packages. One can't rely on the fact it will always be easy and intuitive to find that some application is part KDE (for example) and one can get the documentation in konqueror when typing 'help:/application'. 3. To view the documentation must be as easy as possible and with as minimal resources as possible. This is why online documentation is not so good (you need a running Internet net connection), documentation in a web browser as well (you need X and graphical desktop). HTML is questionable as it (as a format) allows so many extensions that it is needed to expect that such documentation will not be readable in text browsers after some time. 4. Many parts are shared between openSUSE and the enterprise products. And, in the enterprise world, we need to be much more standard conforming. Including the documentation. A UNIX admin will use the 'man' command for getting info about the binary. 'info' system is here as well, for many years. But 'man' is still more usual. Imagine a server room with hundreds/thousands of servers of several UN*X clones - 'man' works everywhere, and Linux is expected to be "on par" also with respect to those capabilities. These four points stay behind the idea of man pages needed and provided for everything. Relations: - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages with missing man pages can be found (url: http://en.opensuse.org/Manual_Pages/Missing) Use Case: User / Administrator should find a dedicated man page for every executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. -- openSUSE Feature: https://features.opensuse.org/305336

1 0

[openFATE 303809] Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1
by fate_noreply＠suse.de 04 Feb '09

04 Feb '09

Feature changed by: Arvin Schnell (aschnell) Feature #303809, revision 18 Title: Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1 openSUSE-11.1: Rejected by Matthias Eckermann (mge1512) reject date: 2008-07-30 16:50:50 reject reason: Moving to SLE 11 SP 1 / openSUSE 11.2 Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Matthias Eckermann (mge1512) Description: Proposal is to offer an option in YaST to clone a disk layout for RAID use and probably jump into the RAID-creation-mode directly Below the original request from C. Boltz / openSUSE community: ----------------------------------------------------------------------------------------------------- It would be good to have an easier way to setup a raid 1 (mirroring). Currently you have to: * create partitions on first disk * create partitions on the second disk (usually using the same layout). * put the corresponding partitions (sda1+sdb1, sda2+sdb2, ...) into a raid array. The easier way would be * [x] I want to create a raid 1 * define the partitioning once for both disks YaST should then partition both disks as requested and create the raid volumes This would save the user/admin some time. However, the traditional method should still be available in case someone wants to have a different layout for some partitions for whatever reason. Relations: - Partitioner: allow cloning of disk layouts - was: easier creation of RAID 1 (novell/bugzilla/id: 387373) https://bugzilla.novell.com/show_bug.cgi?id=387373 Discussion: #2: Matthias Eckermann (mge1512) (2008-05-06 20:10:22) Thanks for the proposal. I am happy that there are more people out there sharing my problems:-) Yet, looking at the current "model" we have in mind for partitioner enhancements, I wonder, if we could probably make that more "generic" by adding something like a "clone disk partitioning scheme" button: You would partition hd0 first and then say: please clone this to hd1, hd2, ... and be able to adjust settings on hd1, ... later. Would that fit? so long - MgE #3: Christian Boltz (cboltz) (2008-05-08 05:07:14) Cloning the disk layout sounds like a good idea and would help. To make it more useful for RAID creation, add "clone to md*", maybe combined with a selection dialog to choose the disks to use. #4: Matthias Eckermann (mge1512) (2008-05-08 05:26:16) Well, you know, we indeed are planning to have such a dialog for creation of raids in the future, ...:-) I changed the "title" according to our discussion, and will 1transfer the request into our internal Feature tracking system soon. Thanks! so long - MgE #6: Martin Schmidkunz (mschmidkunz) (2008-05-15 11:37:58) AFAIK it is currently possible to create one partition after the other. So it does not make sense for me to have a "Clone this partition for future use" at the end. Instead I thought of: http://en.opensuse.org/Image:Idea_303809_1.png When the user presses "Add" in the "partitioning" tab he can choose whether to create one new partition or to use the whole partition scheme from another physical harddisk. Does that make sense? #7: Matthias Eckermann (mge1512) (2008-05-15 12:05:53) (reply to #6) Well, no:-( We are not asking for _partition_ cloning, but _disk_ cloning, i.e. if you have several harddisks, and you want to copy the partitioning from sda to sdb or the like. #8: Martin Schmidkunz (mschmidkunz) (2008-05-16 10:01:41) As discussed live with mge we agree on my proposal. #9: Arvin Schnell (aschnell) (2008-05-16 10:33:01) (reply to #8) That approach has some problems: 1) Hiding "Cloning" behind "Add Partition" is incomprehensible. Cloning affect the whole disk, adding a partition not really. 2) The step to select the partition type is omitted if only one type of partition can be selected. 3) The complete workflow of adding a partition is omitted when no partitions can be created. We (mge, mschmidkunz and aschnell) now agreed upon adding an entry to the "expert" menubutton in the partition overview. + #16: Arvin Schnell (aschnell) (2009-02-04 11:08:08) + Summarising the request: + Add a entry "Close disk layout" to the "Expert" button in the disk + view. This opens a dialog showing all disks that are suitable for being + a clone (constraints: new disks must have equal or larger size). + Several disks can be selected. + On the selected disks: Delete everything (including RAIDs and LVMs + somehow using that disk), create new partition table (if different from + existing) and create partitions with same start and sizes (in cylinders + as libstorage calculates internally) and partition IDs. Other + parameters, e.g. filesystem, are not copied. -- openSUSE Feature: https://features.opensuse.org/303809

1 0

[openFATE 305336] [NONCODE] Ship man page for every executable
by fate_noreply＠suse.de 03 Feb '09

03 Feb '09

Feature changed by: Matthias Eckermann (mge1512) Feature #305336, revision 19 Title: [NONCODE] Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Description: - User / Administrator should find a dedicated man page for every - executable in openSUSE and SUSE Linux Enterprise systems. + 1. Even graphical applications need docs outside the application + itself. The need to run the application, to know what does it does, is + not good. + 2. You need a standard documentation format; where standard = expected + for people needing that documentation. Who are, often, not knowing the + distro well (so the format can't be distro-specific). And the format + must be the same for all binaries/packages. One can't rely on the fact + it will always be easy and intuitive to find that some application is + part KDE (for example) and one can get the documentation in konqueror + when typing 'help:/application'. + 3. To view the documentation must be as easy as possible and with as + minimal resources as possible. This is why online documentation is not + so good (you need a running Internet net connection), documentation in + a web browser as well (you need X and graphical desktop). HTML is + questionable as it (as a format) allows so many extensions that it is + needed to expect that such documentation will not be readable in text + browsers after some time. + 4. Many parts are shared between openSUSE and the enterprise products. + And, in the enterprise world, we need to be much more standard + conforming. Including the documentation. A UNIX admin will use the + 'man' command for getting info about the binary. 'info' system is here + as well, for many years. But 'man' is still more usual. Imagine a + server room with hundreds/thousands of servers of several UN*X clones - + 'man' works everywhere, and Linux is expected to be "on par" also with + respect to those capabilities. + These four points stay behind the idea of man pages needed and provided + for everything. Relations: - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages with missing man pages can be found (url: http://en.opensuse.org/Manual_Pages/Missing) Use Case: User / Administrator should find a dedicated man page for every executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. -- openSUSE Feature: https://features.opensuse.org/305336

1 0

[openFATE 305336] [NONCODE] Ship man page for every executable
by fate_noreply＠suse.de 03 Feb '09

03 Feb '09

Feature changed by: Matthias Eckermann (mge1512) Feature #305336, revision 18 Title: [NONCODE] Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Description: User / Administrator should find a dedicated man page for every - executable in openSUSE and SUSE Linux Enterprise systems. This should - be implemented starting with openSUSE 11.2. At - http://en.opensuse.org/Manual_Pages/Missing a list of all packages with - missing man pages can be found. + executable in openSUSE and SUSE Linux Enterprise systems. + Relations: + - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages + with missing man pages can be found (url: + http://en.opensuse.org/Manual_Pages/Missing) + Use Case: + User / Administrator should find a dedicated man page for every + executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. -- openSUSE Feature: https://features.opensuse.org/305336

1 0