June 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 305715] Package event framework
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305715, revision 15 Title: Package event framework - openSUSE-11.2: New + openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) + reject date: 2009-06-09 14:44:19 + reject reason: We're not going to manage to do this for 11.2. If rpm + gets all the changes, we can incorporate this later. Priority Requester: Desirable Requested by: Andreas Gruenbacher (agruen) Description: The installation, upgrade, or removal of several packages triggers actions such as running ldconfig, rebuilding the initrd, or similar. Those actions are not specific to the package at hand, but either global with a system-wide effect (such as running ldconfig), or they affect a group of packages (such as all kernel (sub-)packages of a specific version, including all KMPs affecting it). Those actions need to be run eventually (with order restrictions relative to other package installs, upgrades, or removals), but running them again and again for each package is wasteful. (Example: with the kernel packages split into kernel-$flavor-base, kernel-$flavor, and kernel-$flavor-extra in CODE11, we currently run mkinitrd out of the %post script of each package. We don't know which of those packages will be installed, and when generating the initrd is supposed to succeed. This both wastes time, and we also cannot tell transient from permanent failures.) In former days, SuSEconfig was used for some of those tasks, but it turned into a major nightmare (perhaps due to its design). It would be nice if we could come up with a framework in which packages can trigger events and define which actions they need to be run, and rpm will then perform those actions in an appropriate order, avoiding repeating the same action unnecessarily. (The dependencies between actions and package installs/upgrades/removals are somewhat complex, but I think they are manageable.) Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-23 18:09:34) This is desirable only as it happens within RPM's framework (or if the additions are "candy" that does not affect the actual result). This includes upstreaming. I do not want to comment besides the RPM requirement until Engineering determines how (and if) to proceed. There are too many factors involved. Stano, Needinfo me back when you guys have a settled position or decide to postpone this one given the other priorities. #2: Klaus Kämpf (kwk) (2009-01-29 12:45:22) Actually, there is probably litte engineering can do or decide here imho. It very much depends on PMs long-term strategy for RPM. There are currently two options * One is to stay with rpm 4.x and keep the status quo. * The other is to move up to rpm5 and try to influence its development. Upstream implementation of the feature request can only happen within rpm5. Adopting rpm5 for the distribution has several prerequisites: * Investment into rpm5 development. * Getting more distributions to adopt rpm5. * Influencing Linux Standards Base to accept rpm5. Given recent comments from RedHat/Fedora, widespread rpm5 adoption looks rather unlikely. #3: Michael Schröder (mlschroe) (2009-01-29 12:50:19) (reply to #2) That sounds like rpm-4 doesn't get new features at all, which is simply not true. Actually I think it's probably easier to get new features into rpm-4, because it's very hard to convince Jeff of something he doesn't like, whereas Panu is more open. #4: Klaus Kämpf (kwk) (2009-01-29 13:22:30) (reply to #3) Now thats good to know. But this probably still needs a significant investment (and a fair bit of persuasion) into rpm4, I guess. #5: Casper Clemence (maninalift) (2009-02-28 15:05:35) I don't know about the issue of how the installer works but from a user perspective the handling of multiple kernel flavours could certainly be better. At the moment a symbolic link is automatically created at /boot/vmlinuz pointing, rather arbitrarily IMO, to the most recently updated kernel. Also the grub menu is messed with in an inept sort of a way. If instead symbolic links were created for each kernel flavour there would be no need to change the grub menu except when new flavours were installed or others removed, thus preserving all of the users other boot settings. -- openSUSE Feature: https://features.opensuse.org/305715

1 0

[openFATE 305572] Extend dwarfextract for generic distro packages
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305572, revision 5 Title: Extend dwarfextract for generic distro packages - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important Requested by: Jan Blunck (janblunck) Description: dwarfextract is a tool to postprocess debuginfo. The tools removes duplicate type information caused by linking different compilation units. Currently the tool has only been used to work on the debuginfo of the kernel package. The tools should be extended so that it can be used in the buildsystem to postprocess any applications debuginfo (like C++ debuginfo etc.). Tools that use debuginfo like GDB need to tested and fixed accordingly. Relations: - Based on work for this FATE (feature/id: 304323) + Discussion: + #1: Andreas Jaeger (a_jaeger) (2009-06-09 14:24:16) + Let's only do this, if it brings us more than 10 % of space saving. + Jan, can you give any numbers from the kernel? -- openSUSE Feature: https://features.opensuse.org/305572

1 0

[openFATE 305547] Support for ECDSA in yast2 ca_mgm
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305547, revision 6 Title: Support for ECDSA in yast2 ca_mgm openSUSE-11.2: New Priority Requester: Mandatory Requested by: Vit Pelcak (vpelcak) Description: It would be good if yast2 ca_mgm supported ECDSA keys. This feature is necessary to support RFC 4869. Currently only RSA is supported. + Discussion: + #1: Andreas Jaeger (a_jaeger) (2009-06-09 14:22:26) + What is the advantage here? From the description I'm not seeing any + benefit of implementing this. -- openSUSE Feature: https://features.opensuse.org/305547

1 0

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

09 Jun '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #306411, revision 9 Title: Configuration files merge openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Michal Hrusecky (-miska-) Description: If we want to make our distribution friendly even to advanced users, I think that we shouldn't touch users configuration files. Luckily this isn't problem as in spec file Ican state that this file is configuration and I don't want to replace it if user did some manual changes. Or I can say that I want to replace it and keep backup of original one. But what I'm missing is some tool to easily merge these files. In Gentoo there is etc-update (http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=4#doc_…) or dispatch-conf (http://en.gentoo-wiki.com/wiki/Dispatch-conf) . I'll describe more precisely what feature I'm missing and why I think it's needed. Let's say that I've got some package and there was quite big change in package default configuration file which will affect most of the users. On the other hand users can have pretty complicated constructions in their configuration files and if they did something like that, it's quite possible that they don't need to update their configuration file. So it is needed to tell users that if they are experiencing problems it is most likely because they touched default configuration. I can take care of it manually, mention it in various README and such, but more easier way would be following. User installs some packages. At the end of zypper or yast installation there will be warning "You've got 42 configuration files to merge, please run etc-update/dispatch-conf/whatever". Then user will run some easy interactive tool which will state which configuration files can use some manual merging, it will allow user to see difference between them and let him choose which one he wants or let him merge them manually somehow. Same warning about unmerged configuration files should appear each time user installs something, no matter if this installation didn't add any conflict, until all conflicts are fixed. User will be warned about possible problems, hacker can play with it and keep his changes against distribution defaults and ordinary user will just click on "use distribution default for all" if he ever encounter such a problem (shouldn't happen as ordinary user wouldn't touch configuration files). I explained basic expected work flow, so now what I think should be supported: * detect configuration files, their conflicts and allow their merge - this shouldn't be a big problem as rpm already stores conflicting files as .rpmnew/.rpmold * we probably want to keep even old versions to support three way merge to achieve even better results * if we are already storing these configuration files, maybe we should let users to backup their own changes as well, add support for versioning these configuration files * warn user that he has conflicts in configuration files - will require a little bit yast/zypper integration * merging tool should support both console and graphical interface (maybe use yast as possible frontend) * support for various formats (expandable by plugins) - ordinary diff may not be the best tool for merging XML files or ini files * ordinary user who don't change anything shouldn't need to know about this tool Relations: - Debian-like dist-upgrade live system full version upgrade (feature/id: 305634) Discussion: #1: Michal Hrusecky (-miska-) (2009-06-02 09:49:38) I was thinking about this a little bit more and if we want to support some kind of versioning and we want to use plugins for getting differences, it may be a good idea to request that plugins will be capable not only of producing nice output of difference between configuration files, but it probably should be able to apply it (behave not only as a 'diff', but also as a 'patch'). And we can build some simple version control system on top of it. Advantages: * can handle non-plain text files better (via plugins) * we can implement feature to discard or merge several commits into one to save space/make commit log more readable * can handle nicelly even insane configuration files like sqlite database or compressed directory with configuration files or any other binary format Disadvantages: * probably worse handling of text files * another thing to maintain/possible source of bugs #2: Stephan Kulow (coolo) (2009-06-09 11:51:14) this sounds like a lot of work to do right and with little gain. We lived quite well for years without it and whatever tool you come up will create new problems, there won't be a perfect tool. Applications with very bizzare config format usually come with their own configuration update tool that can be called from %post So I would put very low imporance on this. + #3: Andreas Jaeger (a_jaeger) (2009-06-09 14:20:14) (reply to #2) + The question is what is really needed to do here. If we could take some + scripts from Gentoo and those would work without changes - cool. If we + would need to change each and every config file for this, I'm also for + rejecting. + So, for me it's not clear what the cost is. -- openSUSE Feature: https://features.opensuse.org/306411

1 0

[openFATE 306403] KOffice 2.1 in 11.2
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #306403, revision 9 Title: KOffice 2.1 in 11.2 - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stephan Kulow (coolo) + reject date: 2009-06-09 11:55:15 + reject reason: firefox is a special case as we lose security updates + very early, but koffice security updates are a very rare case. And + koffice will be in beta when we reach the "no version updates anymore" + state. Priority Requester: Important Requested by: Jean Cayron (jeancayron) Developer: Stephan Binner (beineri) Description: KOffice 2.1 will be released in november 2009, at the same time than openSUSE 11.2 ( see release plan (http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.1/Release_Plan) ). Since the 2.0 will not be feature complete, it would be great for KDE4 integration to have the latest version on the official repositories (maybe do as Firefox the RC with later update). Let make the people choose their Office Suite. Discussion: #1: Ricardo Gabriel Berlasso (rgbsuse) (2009-06-05 23:44:24) Another possibility is to implement a dedicated repository for koffice, in the same way we now have the repository for OOo. #2: Stephan Binner (beineri) (2009-06-08 09:00:58) (reply to #1) The usual KDE:Backports repository should be sufficient. #3: Ricardo Gabriel Berlasso (rgbsuse) (2009-06-08 14:25:35) (reply to #2) I do not agree: enabling backport repo means enabling ALL the content on the backport repo. I only want koffice. -- openSUSE Feature: https://features.opensuse.org/306403

1 0

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

09 Jun '09

Feature changed by: Stephan Kulow (coolo) Feature #306411, revision 8 Title: Configuration files merge openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Michal Hrusecky (-miska-) Description: If we want to make our distribution friendly even to advanced users, I think that we shouldn't touch users configuration files. Luckily this isn't problem as in spec file Ican state that this file is configuration and I don't want to replace it if user did some manual changes. Or I can say that I want to replace it and keep backup of original one. But what I'm missing is some tool to easily merge these files. In Gentoo there is etc-update (http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=4#doc_…) or dispatch-conf (http://en.gentoo-wiki.com/wiki/Dispatch-conf) . I'll describe more precisely what feature I'm missing and why I think it's needed. Let's say that I've got some package and there was quite big change in package default configuration file which will affect most of the users. On the other hand users can have pretty complicated constructions in their configuration files and if they did something like that, it's quite possible that they don't need to update their configuration file. So it is needed to tell users that if they are experiencing problems it is most likely because they touched default configuration. I can take care of it manually, mention it in various README and such, but more easier way would be following. User installs some packages. At the end of zypper or yast installation there will be warning "You've got 42 configuration files to merge, please run etc-update/dispatch-conf/whatever". Then user will run some easy interactive tool which will state which configuration files can use some manual merging, it will allow user to see difference between them and let him choose which one he wants or let him merge them manually somehow. Same warning about unmerged configuration files should appear each time user installs something, no matter if this installation didn't add any conflict, until all conflicts are fixed. User will be warned about possible problems, hacker can play with it and keep his changes against distribution defaults and ordinary user will just click on "use distribution default for all" if he ever encounter such a problem (shouldn't happen as ordinary user wouldn't touch configuration files). I explained basic expected work flow, so now what I think should be supported: * detect configuration files, their conflicts and allow their merge - this shouldn't be a big problem as rpm already stores conflicting files as .rpmnew/.rpmold * we probably want to keep even old versions to support three way merge to achieve even better results * if we are already storing these configuration files, maybe we should let users to backup their own changes as well, add support for versioning these configuration files * warn user that he has conflicts in configuration files - will require a little bit yast/zypper integration * merging tool should support both console and graphical interface (maybe use yast as possible frontend) * support for various formats (expandable by plugins) - ordinary diff may not be the best tool for merging XML files or ini files * ordinary user who don't change anything shouldn't need to know about this tool Relations: - Debian-like dist-upgrade live system full version upgrade (feature/id: 305634) Discussion: #1: Michal Hrusecky (-miska-) (2009-06-02 09:49:38) I was thinking about this a little bit more and if we want to support some kind of versioning and we want to use plugins for getting differences, it may be a good idea to request that plugins will be capable not only of producing nice output of difference between configuration files, but it probably should be able to apply it (behave not only as a 'diff', but also as a 'patch'). And we can build some simple version control system on top of it. Advantages: * can handle non-plain text files better (via plugins) * we can implement feature to discard or merge several commits into one to save space/make commit log more readable * can handle nicelly even insane configuration files like sqlite database or compressed directory with configuration files or any other binary format Disadvantages: * probably worse handling of text files * another thing to maintain/possible source of bugs + #2: Stephan Kulow (coolo) (2009-06-09 11:51:14) + this sounds like a lot of work to do right and with little gain. We + lived quite well for years without it and whatever tool you come up + will create new problems, there won't be a perfect tool. Applications + with very bizzare config format usually come with their own + configuration update tool that can be called from %post + So I would put very low imporance on this. -- openSUSE Feature: https://features.opensuse.org/306411

1 0

[openFATE 306419] New version of storebackup available
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature added by: hou ghi (houghi) Feature #306419, revision 1, last change by Title: New version of storebackup available Requested by: hou ghi (houghi) Description: There is a new version of storebackup available. The version that can be downloaded is 1.19 http://software.opensuse.org/search?baseproject=openSUSE%3AFactory&p=1&q=st… (http://software.opensuse.org/search?baseproject=openSUSE%3AFactory&p=1&q=st…) One user has version 2.0 available The new version at this moment is 3.0 The current honmepages is NOT on sourceforge anymore. The user has moved his page to http://savannah.nongnu.org/projects/storebackup The direct link to the download page is http://www.very-clever.com/download/nongnu/storebackup/ (http://www.very-clever.com/download/nongnu/storebackup/) There also is a large PDF file available The reason the new version is much better is because there has been a huge increase in speed of backing up over e.g. NFS or rsync. Sometimes 10 times faster from the second backup on. Also it is unwise to have old software in the repo if newer is available. houghi -- openSUSE Feature: https://features.opensuse.org/306419

1 3

[openFATE 306459] Use speedboot on 11.2 or 11.3
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature added by: andrea florio (anubisg1) Feature #306459, revision 1, last change by Title: Use speedboot on 11.2 or 11.3 openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: andrea florio (anubisg1) Description: Mandriva is currently using Speedboot to allow the enduser the machine is booting faster: http://www.phoronix.com/scan.php?page=article&item=mandriva_speedboot&num=1 i think we could use it too, on my aspire one for example the machine boot in about 16 seconds (pretty fast eh?) fro grub lo SHELL or XDM login, the desktop manager take almost same time, about 15 seconds.. lots of time compared to boot time, infact if i use autologin before be able to use the pc i have to wait about 32seconds because, evenif earlyxdm is enable, xdm service itself is the last service before reaching init 5 -- openSUSE Feature: https://features.opensuse.org/306459

1 2

[openFATE 305846] Add the us_int (us international with euro sign keyboard)
by fate_noreply＠suse.de 09 Jun '09

09 Jun '09

Feature added by: Joop Boonen (worldcitizen) Feature #305846, revision 1, last change by Title: Add the us_int (us international with euro sign keyboard) openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Joop Boonen (worldcitizen) Description: Add the us_int (us international with euro sign on "5" key keyboard) in the choices in the installation process (when the keyboard can be chosen). This way it'll be easier to choose this lay-out. -- openSUSE Feature: https://features.opensuse.org/305846

1 9

[openFATE 305535] Improve samba yast modules
by fate_noreply＠suse.de 08 Jun '09

08 Jun '09

Feature changed by: Wyatt Gosling (beachchairs) Feature #305535, revision 13 Title: Improve samba yast modules openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-06-05 15:10:01 reject reason: Missing details. Priority Requester: Important Requested by: James McDonough (jmcdough) Partner organization: openSUSE.org Description: Improve the design of the yast samba modules. More details to come. References: https://bugzilla.novell.com/show_bug.cgi?id=444603 Business case (Partner benefit): openSUSE.org: Many customers report difficulties with various areas of samba yast administration, both with new features requested and layout of current ones. Discussion: #1: Christoph Thiel (cthiel1) (2009-05-28 15:34:16) James, do you have more details yet? Otherwise, we'll have to reject it for openSUSE 11.2 right away. + #2: Wyatt Gosling (beachchairs) (2009-06-08 21:40:29) + As someone who just spent a day configuring Samba, I support this. + The Samba module is a bit advanced, but my main problem was I just + didn't know I had to allow Samba in the firewall. I think the module + should do something about this. Perhaps when you hit Ok you get a + prompt allong the lines of "You have enabled Samba, but the Firewall is + set to block Samba. Would you like to change the Firewall to allow + Samba?" + Still I would like to see a simpler module. Perhaps one that has a just + a few options (then takes a reasonable stab at the rest). Maybe have a + global "Enable Folder and Printer Sharing" toggle, and a toggle to + enable password protection (and set the password!). Then have "Enable + Printer Sharing", "Enable Folder Sharing" subcategories. I don't have + any interest in printer sharing, so I don't know if any sub-options + would be applicable or not. For folder sharing, you would need a list + of directories to share. Not much else needs to be presented to the + user IMO. + Also have it so when you use the KDE Item Properties Panel (and the + Gnome equivelent), it is pre-setup to allow users to add shares without + root priveleges. -- openSUSE Feature: https://features.opensuse.org/305535

1 0