July 2008 - openSUSE Features - openSUSE Mailing Lists

[openFate 302988] Don't Zap by default
by fate_noreply＠suse.de 22 Jul '08

22 Jul '08

Feature changed by: Matthias Eckermann <mge(a)novell.com> Feature #302988, revision 13 Title: Don't Zap by default openSUSE-11.0: Done Priority Requester: Mandatory Projectmanager: Important + openSUSE-11.1: Done + Priority + Requester: Mandatory SLED-11: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Stephan Kulow <coolo(a)novell.com> Partner organization: openSUSE.org Description: We have this long standing issue that ctrl-alt-backspace is exiting the desktop without much the user can do about it, while every **** web site asks you if you want to discard random information if you browse away. While the zap functionality is useful for some and essential for some situations, where your X server is broken _and_ the keyboard combination is not _that_ easy to trigger, shutting it off completely is not preferred. So we discussed and what seems reasonable is press once -> beep, press twice -> zap. Egbert and Luc say this can be implemented in the X server and then we can leave the option on by default. Documentation Impact: yes Discussion: #1: Stephan Kulow <coolo(a)novell.com> (2007-11-27 13:36:58) If this feature can't be implemented by let's say alpha 2 due to other constraints, I would like to change the default to not zapp for beta1. #2: Michael Loeffler <michl(a)novell.com> (2007-11-27 14:41:40) fully in agreement with coolo. Do it with few effort asap or leave it. #3: Stefan Dirsch <sndirsch(a)novell.com> (2008-01-05 13:07:34) Sounds like extortion to me. Not nice. And won't help in the end. People will complain again and we need to revert it again. #4: Luc Verhaegen <lverhaegen(a)novell.com> (2008-03-20 02:12:54) Implemented in server and input driver code. Mailing patches to sndirsch for integration into packages. The Sax (or whatever) integration needed to specify this option at install time still needs to be done (i have no clue there). Implementation details: xorg.conf: Option "ZapWarning" "True" Uses PCSpeaker for beep. Press once, beep. Press again within 2s (which is ample), terminate. Documented in xorg.conf manpage. Users will be _so_ thrilled about this cool new feature in openSuSE. #5: Stefan Dirsch <sndirsch(a)novell.com> (2008-03-20 16:21:16) sax2, which sets this option by default, xorg-x11-server and xorg-x11- driver-input has now been submitted to STABLE. ==> FIXED for STABLE/Factory *and* openSUSE 11.0 Beta1. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302988

1 0

[openFate 302924] use the raw meta-data cache to save downloads
by fate_noreply＠suse.de 22 Jul '08

22 Jul '08

Feature changed by: Matthias Eckermann <mge(a)novell.com> Feature #302924, revision 7 Title: use the raw meta-data cache to save downloads openSUSE-11.0: Done Priority Requester: Desirable Projectmanager: Mandatory + openSUSE-11.1: Done + Priority + Requester: Desirable SLED-11: Done Priority Requester: Desirable SLES-11: Done Priority Requester: Desirable Requested by: Ján Kupec <jkupec(a)novell.com> Partner organization: openSUSE.org Description: At least for http, zypp shouldn't download a file which already is (unchanged) in its meta-data cache again. This will most probably need to make the media back-end aware of the raw cache. Also, this feature can be implemented keeping the rpm file caching in mind (FATE #302159). References: https://bugzilla.novell.com/show_bug.cgi?id=307098 https://bugzilla.novell.com/show_bug.cgi?id=348050 FATE #302159 Discussion: #1: Stanislav Visnovsky <visnov(a)novell.com> (2007-11-06 10:02:49) Crucial functionality to further improve the stack. #2: Duncan Mac-Vicar <dmacvicar(a)novell.com> (2007-12-10 16:44:18) This can be fixed if we use Fetcher on commit and set the right cache paths. #3: Cristian Rodriguez <crrodriguez(a)novell.com> (2007-12-14 12:52:15) Critical enhacement, will make zypp lots of faster and more importantly friendly with the mirror infraestructure. #4: Ján Kupec <jkupec(a)novell.com> (2008-02-19 15:54:32) Done by Duncan using Fetcher. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302924

1 0

[openFate 302923] handle redirection to mirrors robustly
by fate_noreply＠suse.de 22 Jul '08

22 Jul '08

Feature changed by: Matthias Eckermann <mge(a)novell.com> Feature #302923, revision 12 Title: handle redirection to mirrors robustly openSUSE-11.0: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2007-11-28 15:42:20 reject reason: Out of scope for 11.0 Priority Requester: Neutral + openSUSE-11.1: Rejected by Matthias Eckermann <mge(a)novell.com> + reject date: 2008-07-22 23:04:50 + reject reason: Postponing, will not be ready. + Priority + Requester: Neutral openSUSE-11.2: New Priority Requester: Neutral SLED-11: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-08 12:13:52 reject reason: Postponing, will not be ready. Priority Requester: Neutral SLES-11: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-08 12:13:49 reject reason: Postponing, will not be ready. Priority Requester: Neutral Requested by: Ján Kupec <jkupec(a)novell.com> Partner organization: openSUSE.org Description: The proposal is to try other mirrors from a mirror list (from the redirector?) if an error occurs on some of the mirrors while providing a file from http/ftp repository. See the references for more details. References: https://bugzilla.novell.com/show_bug.cgi?id=337410 http://lists.opensuse.org/opensuse-buildservice/2007-10/msg00170.html http://en.opensuse.org/Libzypp/Failover http://code.google.com/soc/2008/suse/appinfo.html?csaid=6F1844AB23B67E06 Discussion: #1: Stephan Kulow <coolo(a)novell.com> (2007-11-20 11:15:49) I would be strictly against having an own mirror list. The decision was to go with the redirector (or NCC for SLE) and be done with mirrors. If that does not work, then we have to do this whole thing again, not adding untested work arounds to the product. #2: Stephan Kulow <coolo(a)novell.com> (2007-11-20 11:16:55) so I would reject this. But it's basically "Eval by Klaas" now #3: Klaas Freitag <freitag(a)novell.com> (2007-12-03 09:49:44) I agree with Coolos and Peters statements, I would also reject. #4: Klaas Freitag <freitag(a)novell.com> (2008-06-12 10:06:42) I have to revert my statement that I made before in comment #3, this problem is more serious than realised in the first look. First, it should be noted that we do not control mirrors nor we do have the chance to really influence them. That means that if a mirrors decides to not longer mirror or to switch off or whatever, we have to live with it. However if a customer is sticky to a mirror that is not longer available he would not get any packages from it and thus installation or update fails. The worst thing about that is that this seems to happen regularly but we do not realise that because we're not involved. A solution would be to have a list of possible mirrors that is used by the software installation stack to find a working mirror. Peter knows much more here. But I am not sure at the moment if not Yast/zypper already has this functionality in 11.0? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302923

1 0

[openFate 302919] Improved argument handling for zypper
by fate_noreply＠suse.de 22 Jul '08

22 Jul '08

Feature changed by: Matthias Eckermann <mge(a)novell.com> Feature #302919, revision 10 Title: Improved argument handling for zypper openSUSE-11.0: Done Priority Requester: Mandatory Projectmanager: Important + openSUSE-11.1: Done + Priority + Requester: Mandatory SLED-11: Done Priority Requester: Mandatory SLES-11: Done Priority Requester: Mandatory Requested by: Klaus Kämpf <kkaempf(a)novell.com> Partner organization: openSUSE.org Description: Please improve argument handling on the zypper command line. zypper install foo should look for a package named foo and, if no such package exist, do an automatic fallback to a capability. The --name qualifier can be used to prevent this fallback (forces a package name. The --capability qualifier can be used to force a capability. - Specifying versions and operators should also be more flexible (Following the motto be generous in what you accept, and strict in what you send ) zypper in foo-1.2-3 should try to install package foo, version 1.2, release 3. zypper in foo-1.2 should try to install package foo, version 1.2, any release. zypper in foo should try to install package foo, any version, any release. When specifying operators, spaces should be accepted, i.e. zypper in foo = 1.2-3 - Forcing a specific repository could be done by prefixing the package name with the repository alias followed by a colon, i.e. zypper in opensuse:foo - To be discussed on opensuse-softwaremgmt and cross-checked with other tools like smart and yum. Documentation Impact: Please, consider this for the documentation update. Discussion: #1: Stanislav Visnovsky <visnov(a)novell.com> (2007-11-23 11:24:48) zypper improvements. #2: Ján Kupec <jkupec(a)novell.com> (2008-04-14 15:02:32) All of the orginal suggestions are implemented, except for per-package forcing of repositories. Can i mark as done? I also thought of install foo@arch postfix to force specific architecture. There is no libzypp API for per-package forcing of repository or architecture but it's doable in zypper the old (forced) way. Would take only few more hours. #3: Ján Kupec <jkupec(a)novell.com> (2008-04-14 14:58:01) BTW, we've got wildcard support, install/remove in one go using +/- ~/! prefix (+maybe more i cannot recall now) as bonus :O) Details will be added to the man page and wiki later. #4: Ján Kupec <jkupec(a)novell.com> (2008-04-21 13:29:15) All done in zypper 0.11.1 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302919

1 0

[openFate 302119] Load package selector and libzypp only when needed
by fate_noreply＠suse.de 21 Jul '08

21 Jul '08

Feature changed by: JP Rosevear (jpr(a)novell.com) Feature #302119, revision 25 Title: Load package selector and libzypp only when needed openSUSE-10.3: Rejected by <visnov(a)novell.com> reject date: 2007-08-01 16:40:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by <visnov(a)novell.com> reject date: 2008-04-28 13:42:30 reject reason: Did not make it, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Candidate Priority Requester: Desirable Projectmanager: Important Requested by: Stefan Hundhammer <sh(a)novell.com> Partner organization: openSUSE.org Description: The YaST2 UI should load the code for the package selector and libzypp only when needed. Not all applications / YaST2 modules need package selection code, yet for all of them the respective code from the YaST2 UI and libzypp is loaded. Discussion: #1: Stefan Hundhammer <sh(a)novell.com> (2007-04-13 18:13:44) In the YaST2 Qt the package management related code is now moved to a separate plugin that is loaded upon demand only if the calling YCP application actually requests a PackageSelector widget. This reduces the memory footprint from 20 MB VmRSS minimum (HelloWorld. ycp) to 18 MB minimum (PackageSelector-empty.ycp). #3: Katarina Machalkova <kmachalkova(a)novell.com> (2007-04-16 14:41: 35) Stano, do we want this for curses UI as well? If yes, than it's not 'done' ... #4: Stanislav Visnovsky <visnov(a)novell.com> (2007-04-16 14:47:02) (reply to #3) Agreed. Reopening for ncurses and possibly gtk+. #5: Jiri Srain <jsrain(a)novell.com> (2007-06-13 13:54:26) JP, both Qt and NCurses are done, but GTK is still missing. #6: Stefan Hundhammer <sh(a)novell.com> (2007-06-13 15:08:58) Looks like yast2-pkg-bindings are also loaded unconditionally. It shouldn't be too hard to do that with "lazy initialization" like UI built-ins: Postpone loading the Y2Component until it's really needed. #7: Stanislav Visnovsky <visnov(a)novell.com> (2007-06-19 15:01:54) (reply to #6) Jiri, if Pkg bindings problem is not addressed, it does not make sense to fix Gtk UI. #8: Jiri Srain <jsrain(a)novell.com> (2007-07-18 13:59:50) (reply to #7) Sorry for missing this. Martin, please, solve this for the Pkg bindings. #10: Stanislav Visnovsky <visnov(a)novell.com> (2007-11-08 11:38:22) (reply to #9) Please, follow up on this. #11: Martin Vidner <mvidner(a)novell.com> (2008-04-10 15:23:51) yast2-perl-bindings-2.16.6 no longer links to libzypp, which means libzypp will not be loaded at the very start of yast (perl still will be loaded, but that is relatively cheap). That helps in some cases, but mostly it only delays loading of libzypp, which occurs as soon as Pkg (or Package) is imported. Now I need to make Pkg lazy. #12: Martin Vidner <mvidner(a)novell.com> (2008-04-21 15:32:09) I have it almost working, but got stopped by bug 381917 (https://bugzilla.novell.com/show_bug.cgi?id=381917) : problems with destructors of static objects + #13: JP Rosevear <jpr(a)novell.com> (2008-07-21 13:59:18) (reply to #12) + Martin, what's the status here? Will we need to do anything explicit in + packagekit to get this functionality? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302119

1 0

[openFate 303367] Better Beagle Acceptance
by fate_noreply＠suse.de 21 Jul '08

21 Jul '08

Feature changed by: JP Rosevear (jpr(a)novell.com) Feature #303367, revision 11 Title: Better Beagle Acceptance openSUSE-11.0: Rejected by Gary Ekker(gekker(a)novell.com) reject date: 2008-05-27 09:03:27 reject reason: Not done for 11.0. Priority Requester: Mandatory Projectmanager: Important - openSUSE-11.1: Evaluation + openSUSE-11.1: Candidate Priority Requester: Mandatory Projectmanager: Important - SLED-11: Evaluation + SLED-11: Candidate Priority Requester: Mandatory Projectmanager: Important Requested by: Andreas Jaeger (aj(a)novell.com) Partner organization: openSUSE.org Description: There have been several discussions on the public openSUSE mailing lists, e.g. http://lists.opensuse.org/opensuse-factory/2008-01/msg00157.html where people complain about resource usage or garbage from beagle. I suggest that we analyze the current situation and check where are real problems and consider solutions. One option would be to make it easier for users to not enable beagle on their systems. Note: The feature request is about getting a better acceptance by our users of our indexing technology - and therefore let's figure out what are the problems they are hitting in real life. References: https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Andreas Jaeger(aj(a)novell.com) (2008-01-20 11:12:58) See also bug 282678. #2: Andreas Jaeger(aj(a)novell.com) (2008-01-23 16:23:51) Note: powertop advises "Suggestion: Disable or remove 'beagle' from your system. Beagle is the program that indexes for easy desktop search, however it's not very efficient and costs a significant amount of battery life.". #3: JP Rosevear(jpr(a)novell.com) (2008-01-23 10:38:58) (reply to #2) Yes, this is well known and was covered extensively last year and caused by polling for battery status in some cases. 0.3.2 uses hal to detect battery status: http://www.mail-archive.com/dashboard-hackers@gnome.org/msg03464.html #4: JP Rosevear(jpr(a)novell.com) (2008-01-23 10:41:35) (reply to #3) Also part of it was a mono issue: http://www.nabble.com/Beagle-indexing-when-running-on-batteries-td13842939.… -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303367

1 0

[openFate 305080] Enable runlevel 4
by fate_noreply＠suse.de 21 Jul '08

21 Jul '08

Feature changed by: Matthias Eckermann (mge(a)novell.com) Feature #305080, revision 6 Title: Enable runlevel 4 - openSUSE-11.1: New + openSUSE-11.1: Duplicate of #303798 Priority Requester: Important - SLED-11-SP1: New + SLED-11: Duplicate of #303798 Priority Requester: Important - SLES-11-SP1: New + SLES-11: Duplicate of #303798 Priority Requester: Important Requested by: Peter Bowen (pzb(a)novell.com) Partner organization: openSUSE.org Description: Currently we do disable runlevel 4. We should update the inittab to enable runlevel 4 and update initscripts to run at 4 if they run at 3. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305080

1 0

[openFate 304928] LSB build target
by fate_noreply＠suse.de 18 Jul '08

18 Jul '08

Feature changed by: Darren Davis (ddavis(a)novell.com) Feature #304928, revision 12 Title: LSB build target Buildservice: Evaluation Priority Requester: Important Requested by: Adrian Schröter (adrian(a)novell.com) Requested by: Michael Loeffler (michl(a)novell.com) Partner organization: openSUSE.org Description: A LSB build target is requested from PM. This does mean we need * A usable base distribution, which avoids to generate binaries with non-LSB requirements. * Additional LSB validation checks packaged. We could integrate these as rpmlint checks for example. Jiri, how can we setup such a distribution, using selected packages from a SUSE distro plus lsb-build-cc as compiler ? Jiri, can you package the lsb validation checks as rpmlint packages or shall we run them in a different way ? Discussion: #1: Jiri Dluhos(jdluhos(a)novell.com) (2008-06-18 13:55:50) The task has two sides: Checking binaries for LSB compliance is relatively easy; I will investigate how the checks could be incorporated into rpmlint. Building in LSB-pure environment is a conceptually different, and significantly more complex task. We have already tried to implement a pure LSB build target for buildservice, but the straightforward strategy failed because LSB-pure environment is too restricted to build essential system binaries (like mount). The Linux Foundation uses a specially crafted host distro for their builds, which is not LSB compliant per se, and then do an additional round of checks and purifications on the built binaries. We can mimic this process. #2: Jiri Dluhos(jdluhos(a)novell.com) (2008-06-18 14:23:32) What we will need is probably the lsbappchk tool from the LSB Application Testkit (downloadable at http://www.linuxfoundation.org/en/Download (http://www.linuxfoundation.org/en/Download) ). I will look at the sources to see if we can easily build it on- site. #3: Jiri Dluhos(jdluhos(a)novell.com) (2008-06-18 15:51:49) For the record (and for the curious :-) ), the database of LSB- compliant interfaces is here: http://bzr.freestandards.org/lsb/devel/specdb (http://bzr.freestandards.org/lsb/devel/specdb) #4: Darren Davis(ddavis(a)novell.com) (2008-06-30 07:55:35) I would also be nice if after they build their LSB Compliant Application in the Build Service, that they could also do the part of submitting the results for the LSB Navigator that the ATK provides. https://www.linuxfoundation.org/dbadmin/commons/welcome.php #5: Gerald Pfeifer(gp(a)novell.com) (2008-06-30 22:53:24) Michl is out right now, so let me play Michl on TV. Important for PM, and on to Adrian. ;-) #6: Martin Mrazik(mmrazik(a)novell.com) (2008-07-01 06:08:50) (reply to #5) Maybe before evaluating this it would be better to split this fate entry into two: * Create a LSB build target * Package ATK and integrate with rpmlint + #7: Darren Davis(ddavis(a)novell.com) (2008-07-18 12:35:52) (reply to + #6) + We could keep this FATE for the build target. I have created FATE 305085 + for the ATK. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304928

1 0

[openFate 303517] Configure a cronjob for refreshing repositories
by fate_noreply＠suse.de 18 Jul '08

18 Jul '08

Feature changed by: J. Daniel Schmidt (jdsn(a)novell.com) Feature #303517, revision 11 Title: Configure a cronjob for refreshing repositories openSUSE-11.1: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Ladislav Slezak (lslezak(a)novell.com) Partner organization: openSUSE.org Description: Autorefresh configured repositories at certain times, this could be on certain days, or time of day, etc. A mockup and more details are in https://bugzilla.novell.com/show_bug.cgi?id=346966 Discussion: #1: Federico Lucifredi(flucifredi(a)novell.com) (2008-06-13 15:12:52) there are some caveats I can think of requiring silent fail (for instance, a laptop), or requiring randomization (not hitting NCC with a volley all at the same time), but I think the idea is good. #2: Duncan Mac-Vicar(dmacvicar(a)novell.com) (2008-07-07 11:13:37) If you think you can make it work in a reliable way, please present a concept. Right now PackageKit and updater applets do refresh often before checking for updates so the system repos _are_ refreshed. So I don't see much value in this feature (unless a concept is presented). #3: Stanislav Visnovsky(visnov(a)novell.com) (2008-07-07 12:34:19) (reply to #2) We have a concept in the automatic online update configuration. #4: Jiri Srain(jsrain(a)novell.com) (2008-07-07 12:58:59) (reply to #3) You mean running online update from cron? It should involve metadata refresh, but I do not see any reason for a separate metadata download from cron. #5: Ladislav Slezak(lslezak(a)novell.com) (2008-07-09 10:30:09) (reply to #4) The feature should allow to disable "autorefresh" flag for all repositories so the package management can be started quickly without connecting to network. The cronjob would keep the metadata uptodate. Of course, there might be a problem when metadata are changed too often on the server, but in my opinion that's not a usual case in the real world. #6: Jiri Srain(jsrain(a)novell.com) (2008-07-10 12:16:08) Let's extend the "automatic online update" module so that it offers whether to do real automatic online update, or just refresh the metadata (via one check box) + #8: J. Daniel Schmidt(jdsn(a)novell.com) (2008-07-18 18:13:38) (reply to + #6) + This would hide the feature in an update related module. But the feature + does not restrict this only to update repositories. Build-Service Repos + might need a refresh as well or think of Factory. The right place for + this feature is the Repository Manager. It has no relation to the + update process or a configuration concerning updates. #7: Jiří Suchomel(jsuchome(a)novell.com) (2008-07-14 14:46:01) Daniel, what's the status of the plan to merge "online update configuration" into registration module? + #9: J. Daniel Schmidt(jdsn(a)novell.com) (2008-07-18 18:15:46) (reply to + #7) + Currently I plan to merge it into a new module together with "Online Update + Configuration" related settings. Please do not extend it with this + unrelated repo refreshing dialog. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=303517

1 0

[openFate 305080] Enable runlevel 4
by fate_noreply＠suse.de 18 Jul '08

18 Jul '08

Feature changed by: Peter Bowen (pzb(a)novell.com) Feature #305080, revision 4 Title: Enable runlevel 4 openSUSE-11.1: New Priority Requester: Important SLED-11-SP1: New Priority Requester: Important SLES-11-SP1: New Priority Requester: Important Requested by: Peter Bowen (pzb(a)novell.com) + Partner organization: openSUSE.org Description: Currently we do disable runlevel 4. We should update the inittab to enable runlevel 4 and update initscripts to run at 4 if they run at 3. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305080

1 0