October 2009 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 308257] Partitioner: allow for adjusting layout when creatin raid10 (and maybe 5/6?)
by fate_noreply＠suse.de 19 Nov '09

19 Nov '09

Feature added by: Sinisa Bandin (siny) Feature #308257, revision 1 Title: Partitioner: allow for adjusting layout when creatin raid10 (and maybe 5/6?) openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Sinisa Bandin (siny) Description: Because using "far" layout makes BIG difference in speed of array. Also makes possible extra-safe arrays with number of copies greater than 2, up to total number of storage devices. Not sure about raid5/6, I am not using them. -- openSUSE Feature: https://features.opensuse.org/308257

1 2

[openFATE 306967] KDE default
by fate_noreply＠suse.de 16 Nov '09

16 Nov '09

Feature added by: Frank Karlitschek (FrankKarlitschek) Feature #306967, revision 1 Title: KDE default openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Frank Karlitschek (frankkarlitschek) Description: I propose to make KDE the default desktop in openSUSE. - It is confusing for new Linux users if they have to decide between KDE and GNOME during the installation. New users don´t know either of them. So it is easier for beginners if there is a default. openSUSE has more KDE users than GNOME users so it is logical to make KDE the default. - Unique Selling Point. It is important for openSUSE to provide something that Ubuntu and Fedora don´t provide. It would be beneficial for openSUSE to be the only big KDE distribution. - This could attract more developers because KDE developers need a nice distribution to develop on. - This would increase the popularity of openSUSE in the KDE user community. The negative impact on the GNOME community is not that bad because Ubuntu is the most popular GNOME distribution. openSUSE should, of course, also ship and support GNOME. So experienced users can choose. But new users should have KDE as default. What do you think? -- openSUSE Feature: https://features.opensuse.org/306967

1 109

[openFATE 306413] Poulsbo (GMA500) graphics support
by fate_noreply＠suse.de 15 Nov '09

15 Nov '09

Feature added by: Justin Haygood (jhaygood) Feature #306413, revision 1, last change by Title: Poulsbo (GMA500) graphics support openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Justin Haygood (jhaygood) Description: openSUSE should support laptops with an Intel GMA500 (Poulsbo) graphics card. Currently, Ubuntu has a monopoly on such machines, such as the Dell Inspiron Mini 12 -- openSUSE Feature: https://features.opensuse.org/306413

1 3

[openFATE 305783] Integrate latest stable KDE4 release
by fate_noreply＠suse.de 05 Nov '09

05 Nov '09

Feature added by: Stephan Binner (Beineri) Feature #305783, revision 1, last change by Title: Integrate latest stable KDE4 release openSUSE-11.2: New Priority Requester: Mandatory Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org Description: Depending on what the openSUSE 11.2 schedule allows, the next release has to contain either the latest KDE 4.2.x or KDE 4.3.x packages including usual nifties (see external link) and integration with the distribution. In any case it should be tested and run with Qt 4.5 and KDE applications should be used in KDE4 versions as far as possible. Relations: - Ideas what to achieve with KDE on 11.2 (url: http://en.opensuse.org/KDE/Ideas/11.2) -- openSUSE Feature: https://features.opensuse.org/305783

1 17

[openFATE 308205] Include openvz in server area
by fate_noreply＠suse.de 03 Nov '09

03 Nov '09

Feature added by: fsk aio (fasiko) Feature #308205, revision 1 Title: Include openvz in server area openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: fsk aio (fasiko) Description: Include a optimized openvz kernel for isolation. if possible, integrated into yast for an easy administration -- openSUSE Feature: https://features.opensuse.org/308205

1 2

[New: openFATE 308262] repo naming convention
by fate_noreply＠suse.de 03 Nov '09

03 Nov '09

Feature added by: Ralph Ulrich (ulenrich) Feature #308262, revision 1 Title: repo naming convention openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Ralph Ulrich (ulenrich) Description: Please openSUSE do make yourself easy to understand. The repo namings are in such a state that even openSUSE long time users get confused. So nobody can edit the wiki to inform users right now. examples: a) http://download.opensuse.org/distribution/openSUSE-current/ ? is more than a year old. ? same as: http://download.opensuse.org/distribution/openSUSE-stable/ b) http://download.opensuse.org/distribution/11.2-RC2/ ? same as: http://download.opensuse.org/factory-snapshot/ but coolo said: "factory and 11.2 are two distinct projects since" Factory is normally rolling... But what is a rolling snapshot ??? Solution: Some naming convention: 1. never name a release current but stable 2. name repo before release testing (like Debian) 3. rename factory unstable (like Debian) "snapshot" normally is a repository of a point in the past and should not point to the future (as now with 11.2 you have empty snapshots to be released tomorrow). -- openSUSE Feature: https://features.opensuse.org/308262

1 3

[openFATE 300758] Show orphaned packages
by fate_noreply＠suse.de 31 Oct '09

31 Oct '09

Feature changed by: Atri Bhattacharya (badshah400) Feature #300758, revision 90 Title: Show orphaned packages openSUSE-10.2: Rejected by Thorsten Kukuk (kukuk) reject date: 2006-08-02 11:31:19 reject reason: For SL10.2 we have to get libzypp really stable and fast before we add new features. Priority Requester: Important openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-07-17 17:03:57 reject reason: Postponing. Priority Requester: Important Projectmanager: Desirable openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-11-21 12:16:20 reject reason: Out of scope for 11.0 Priority Requester: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-07 13:34:02 reject reason: Postponing, needs underlaying infrastructure to be fixed first. Priority Requester: Important openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important openSUSE-11.3: Done Priority Requester: Desirable Requested by: JP Rosevear (jproseve) Description: The package manager should learn to show orphanized packages (packages which are not required by other packages and are not in wanted selections) and allow to deinstall them like the popular debfoster/deborphan tools. A typical use case: user installs an application which pulls in some dependencies to test it, uninstalls the application shortly after or way later but the dependencies stay unused installed on the system. Commandline UI (zypper) only. References: https://bugzilla.novell.com/show_bug.cgi?id=166132 Discussion: #1: Jiri Srain (jsrain) (2007-06-05 13:46:00) Schubi, is there any possibility to make solver tell which packages are orphanized? It would be interesting especially if the packages which are marked for deletion were considered as non-installed (eg. if foo- devel is installed but marked for deletion and nothing else requires foo, then foo is orphanized). #2: Stefan Schubert (schubi2) (2007-06-06 11:04:04) (reply to #1) Currently not cause the solver has no information about who (user, package,...) has triggered the installation of a package. If we are storing this information it would be possible for solver to remove these kind of packages too. It is not simple but doable. By the way, we will have to store this kind of information in the future. E.g. we need to save the "keep state by user" in a database in order to regard this state in future solver runs. #3: Jiri Srain (jsrain) (2007-06-06 14:25:07) (reply to #2) Looks like a missunderstanding. Basically every package wihch is not required/recommended/suggested or doesn't enhance anything that is installed and not marked for deletion is IMO considered to be orphanized. If user eg. wants to remove a pattern including all its packages (which are not required by something else), solver providing this kind of information would help a lot (and I don't think that we would need any other information to be stored. #4: Stefan Schubert (schubi2) (2007-06-06 15:33:44) (reply to #3) I do not think so. What does "orphanized" mean ? Let me take your example from comment #1. foo should be deleted too if the user delete foo-devel and foo has been installed due the requirement of foo-devel. BUT the user will kill us if we are deleting foo although the user has installed foo explicit sometime ago in a seperate installation workflow. So this information ( The USER has installed foo) will be currently not saved and is needed here to decide if foo has to be deleted or not. #5: Stefan Schubert (schubi2) (2007-06-06 15:39:47) (reply to #3) Lets take your example concerning the erasing of patterns. That is much more complex. I have already described the problem here: http://en.opensuse.org/Libzypp/Solver#Known_Problems " Proper behaviour of erasing patterns" There are already some bugzilla entries: Bug 274283 - Delete iFolder from YaST makes eDirectory Delete mandatory Bug 238250 - YaST does not upgrade an Add-on Product #6: Jiri Srain (jsrain) (2007-06-08 16:46:32) See also https://bugzilla.novell.com/show_bug.cgi?id=166132 This is another use case for the same solver functionality #8: Federico Lucifredi (flucifredi) (2008-06-12 20:46:17) this should be commandline-only, definitely an advanced-user option. #9: Federico Lucifredi (flucifredi) (2008-06-12 20:47:28) cut from description: See Bug 140346 #10: Duncan Mac-Vicar (dmacvicar) (2008-11-03 11:24:53) As discussed in Prague, this could be done using the package history once we have a reader. #11: Karsten König (remur) (2009-01-19 10:09:49) How about using rpmorphan, I agree with flucifredi about the command line idea... http://rpmorphan.sourceforge.net/ And otherwise you could use their system to find orphanized packages and display them in yast but make clear that deleting -all orphanized packages will also delete the ones explicitly installed... (it only detects wether the package fullfiles any requirement...) #12: Ján Kupec (jkupec) (2009-01-19 14:48:38) (reply to #11) I'm not the solver developer, but i'm pretty sure it's easy (and probably more effective) to find the 'leaf' packages (that's what rpmorphan seems to do) using existing solver (see satsolver package). But we don't want to just highlight leaf packages, we want to remove unused packages, that is all leaves minus those explicitly installed. So we will feed the solver with this 'explicitly-installed' information. The package history will be the source of this info for now. Maybe later we find some way to store this info that could be used across tools (e.g. directly in the rpm db). So rpmorphan will be able to use this info as well. #13: Pavol Rusnak (prusnak) (2009-01-19 15:44:26) (reply to #12) Yes, that's good idea. Detecting leaf packages is the first step. Detecting which ones to remove (i.e. not explicitly installed) is the second. I think that rpmorphan shows all leaf packages, but it selects only the ones that start with "lib". If we strictly followed library packaging policy that would do the trick. btw. rpmorphan is packaged in Contrib (http://en.opensuse.org/Contrib) #14: Michal Smrž (ilfirin) (2009-03-07 20:05:22) (reply to #11) I am afraid of using rpmorphan to do this. Cause last time, I tested it, it wants to remove libdvdnav and libdvdcss libraries. This is very bad. It leads to many not advanced users to ask in phorums "Why OpenSUSE is not playing DVDs anymore?" I see many problems this could make. #15: Christoph Thiel (cthiel1) (2009-04-21 15:23:06) We don't have the resources to implementing this. Seems to be a prefect fit for a community project. #17: Piotrek Juzwiak (benderbendingrodriguez) (2009-04-22 07:58:47) Maybe the idea to accomplish this would be simply by using the packages. xml file and diff it. We can already export what packages we got right? So if it would compare the packages.xml before installation and after it would then delete it. There is a problem when installing many packages, they would all have to be "grouped" which pulled which dependencies. #20: Vladimirs Kuzmins (vovachaka) (2009-10-26 16:27:51) This feature is a specially important, now when we have distro upgrade, which changes a lot of dependencies and a lot of obsolete packages remain installed. Please, someone implement it! #21: Thomas Göttlicher (tgoettlicher) (2009-10-26 16:41:29) I've added a view for orphaned packages in yast2-qt-pkg. There is a package group "orphaned packages" similar to "suggested packages" and "recommended packages" in yast2-qt-pkg version 2.18.17. + #22: Atri Bhattacharya (badshah400) (2009-10-31 14:55:26) (reply to + #21) + Thanks for implementing this much needed feature. But this feature does not + work with the gtk interface in 11.2 RC2; please have this added for the + final release of 11.2. -- openSUSE Feature: https://features.opensuse.org/300758

1 0

[New: openFATE 308272] NetworkManager custom pptp options like loglevel and nobuffer
by fate_noreply＠suse.de 31 Oct '09

31 Oct '09

Feature added by: Mikhail B (asc7uni) Feature #308272, revision 1 Title: NetworkManager custom pptp options like loglevel and nobuffer openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Mikhail B (asc7uni) Partner organization: openSUSE.org Description: When using NM, there is no way to set pptp connection with options like --loglevel 0 and --nobuffer. Business case (Partner benefit): openSUSE.org: If your ISP is buggy enough, without this options you get extremely slow internet connection, high pings and GIGABYTES of system logs about lost or reordered pptp packages. -- openSUSE Feature: https://features.opensuse.org/308272

1 0

[openFATE 306411] Configuration files merge
by fate_noreply＠suse.de 31 Oct '09

31 Oct '09

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

1 0

[openFate 305624] Allow downloading all packages before installing
by fate_noreply＠suse.de 30 Oct '09

30 Oct '09

Feature added by: Jiri Srain <jsrain(a)novell.com> Feature #305624, revision 1, last change by Title: Allow downloading all packages before installing openSUSE-11.2: New Requested by: Jiri Srain (jsrain) Interested: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Libzypp should allow to set a policy to first download all packages and afterwards install all packages at once. It should be considered whether to enable this policy under some scenarios (e.g. makes sense for online update, but not for distro installation) References: https://bugzilla.novell.com:443/show_bug.cgi?id=448040 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305624

1 42