January 2009 - openSUSE Features - openSUSE Mailing Lists

[openFate 302923] handle redirection to mirrors robustly
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Peter Poeml (poeml) Feature #302923, revision 20 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: Evaluation Priority Requester: Neutral Requested by: Ján Kupec (jkupec) 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) (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) (2007-11-20 11:16:55) so I would reject this. But it's basically "Eval by Klaas" now #3: Klaas Freitag (kfreitag) (2007-12-03 09:49:44) I agree with Coolos and Peters statements, I would also reject. #4: Klaas Freitag (kfreitag) (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? #5: Peter Poeml (poeml) (2008-10-01 11:58:38) YaST/zypper in 11.1 will have preliminary support for this. The essential part of http://en.opensuse.org/Libzypp/Failover has been implemented during a GSoC project this year. See http://lists.opensuse.org/zypp-devel/2008-09/msg00142.html for the status. There is a number of things left to do, like * making it the default * better debuggability - show what it does * better progress report * testing * integration into the install system so it is available during installation Further features from the proposal (mirror preference, simultaneous downloads) are not tackled yet. #6: Federico Lucifredi (flucifredi) (2009-01-07 16:29:58) I would like to see robust redirection, if possible. The details about a list, probably should not be in the feature description. #7: Todd R (theblackcat) (2009-01-22 22:20:45) Would this also be able to handle changes in the Buildservice, like renaming or moving of a certain Buildservice repository? + #8: Peter Poeml (poeml) (2009-01-23 11:56:48) (reply to #7) + No, that is outside the scope. Changing repositories when the system is + upgraded to a next major version is also outside the scope. Maybe that + can be covered by + http://en.opensuse.org/Standards/Repository_Index_Service, if I am not + mistaking it. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302923

1 0

[openFate 302476] KDE notification for apparmor rejects
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Michael Loeffler (sprudel24) Feature #302476, revision 18 Title: KDE notification for apparmor rejects openSUSE-11.0: Rejected by Stephan Kulow <coolo(a)novell.com> reject date: 2008-03-26 17:30:24 Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.1: Rejected by JP Rosevear <jpr(a)novell.com> reject date: 2008-08-15 11:38:24 reject reason: Rejected due to lack of time. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Stephan Kulow (coolo) + Partner organization: openSUSE.org Description: fate #300563 added dbus event advertising. We'd need a KDE frontend for these dbus events that shows a notification of these events. Documentation Impact: Needs to be documented Discussion: #1: Stephan Binner (beineri) (2008-03-18 10:45:07) Just had a chat with Ludwig and Marcus about this topic (if it would be a nice SoC project) and they don't see much use in having such an applet on the desktop. #2: Marcus Meissner (msmeissn) (2008-03-20 14:52:14) (reply to #1) (background reasoning is: it would spend almost all of the time: doing nothing.) #4: Stephan Kulow (coolo) (2008-03-26 17:30:09) (reply to #2) such dbus callbacks are perfect kded modules - they would register a callback and be dead code after that and create a notification on callback. And it's half a day effort, not really SoC material. #3: Jared Allen (jpallen) (2008-03-20 13:56:50) I like the idea of using this as a SoC project. Let's consider this for openSUSE 11.1 #6: Stephan Binner (beineri) (2009-01-17 16:16:46) (reply to #3) Any objection to make this fate public for openSUSE.org partner and try to advertize it there? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302476

1 0

[openFate 305586] Desktop independent global notification framework
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305586, revision 13 Title: Desktop independent global notification framework openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Desirable Requested by: Stefan Assmann (assmannst) Partner organization: openSUSE.org Description: Our current desktop environments lack a good, configurable notification framework like Growl on Mac OS X. With D-BUS in place we could develop/integrate a framework that is desktop independent and could serve both KDE and GNOME applications the same way. This provides one step towards integrating both desktops more closely, thus making the user experience smoother. One such notification system is already in development. It's called mumbles (http://www.mumbles-project.org/) and provides lots of features similar to Growl. * It's customizable * Has theming support * Has plugin support * Desktop independent * Can use compiz for smooth display Using such a framework, more than just integrating desktops could be achieved: * Local notifications on hardware events * Remote notifications on login/hardware events * Easy scriptability for custom notifications Steps necessary to implement such a framework in openSUSE/SLE: * Install and configure framework by default * Integrate framework configuration in desktop environment * Make framework interactive so the user can react on events (optional) * Make applications D-Bus/Notification aware, so they send events, already available: Firefox, Thunderbird, Pidgin, several others Business case (Partner benefit): openSUSE.org: Such a framework would be a huge win for the general user experience, as it makes the desktop look more integrated and smooth. It's even a good idea for SLES, so administrators can be easily notified when events occur, without the hassle to set up syslog forwarding+parsing+notifying. Discussion: #2: Guy Lunardi (glunardi) (2008-12-18 08:32:18) I agree this is an important part of the desktop platform. How is this different from the libnotify solution which I believe we use for this purpose today? It is my PM understanding it does most everything you are describing including a CLI (notify-send). Applications such as NetworkManager, PowerManager, Pidgin and Banshee. Reading their FAQ, the reason for not using libnotify is that the author wanted to put more Python dependent software on their system :- ). Is this proposal about switching from libnotify to mumbles? (honestly asking, I have no opinion) #3: Stefan Assmann (assmannst) (2008-12-18 15:46:19) (reply to #2) Honestly I have not much insighted into libnotify myself. Talking to Alex Graf about this, we came up with the idea to teach the libnotify daemon how to forward messages to mumbles. It turns out that libnotify has support for theming, so it should be possible to create a theme that forwards all events to mumbles. Then we would not have to make a decision what we should use and could just switch and see what suits us best. This way we don't lose any functionality. In my opinion mumbles looks a lot smoother than the current libnotify messages. However I guess everything possible with mumbles could be tought to libnotify as well. Frankly said I don't want to make a decision here, what I care for is that the functionality described in this fate will be integrated into our products. #4: Stefan Assmann (assmannst) (2008-12-18 16:15:56) (reply to #3) Update: Talking to the developers I just learned that mumbles will intercept libnotify messages and handle them. There's a plugin for mumbles that does that. #5: Tejun Heo (teheo) (2008-12-22 13:28:54) I think that having the notion of what a "notification" is and how the user can take "action"s to it is quite important. There are multiple classes of notifications - some are ephemeral while others must get acknowledgement from the user. For example, download complete from firefox, new driver or codec installation suggestion and smartd reporting imminent disk failures can and probably should use the same notification mechanism but they need to be handled differently. For ephemeral notifications, I think what libnotify has been doing is fine but for anything else, we at least need a way for the user to ack or take actions accordingly and review and search unacked and acked notifications. I think having such notification mechanism will help us a lot as a distro as it will enable us to suggest things in not-too-intrusive yet friendly way. #6: M. S. (funkym) (2009-01-17 13:05:51) libnotify does all that and ontop is based on a desktop independent freedesktop specification (http://galago-project.org/specs/notification/index.php) for notifications to adopt by any desktop environment. It is written in C which is much more suitable for daemons and provides bindings for D- BUS, Mono, Python and Vala. Interactive notifications are already used widely; take PackageKit as an example. The developer of growl is also interested to improve libnotify as they are closely related and friends with the maintainer. A cross desktop friendly notifications utility in Python is the right thing to make things worse. If you want the bling just create a different theme for libnotify... What libnotify needs though is a bit of coding love to implement stuff like network notifications. Switch to Mumbles -> NO! Contribute to libnotify -> YES! $2c #7: Stefan Assmann (assmannst) (2009-01-19 09:55:39) (reply to #6) It's no longer the question whether to switch from one to the other. Mumbles is able to intercept libnotify messages so we can provide it "on top" and switch. Then it's a question of defaults and what we like this to become. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305586

1 0

[openFate 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Stefan Behlert (sbehlert) Feature #304879, revision 31 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear <jpr(a)novell.com> reject date: 2008-08-15 11:47:35 reject reason: As per PM recommendation. Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory + Projectmanager: Mandatory Requested by: Stephan Binner (beineri) Partner organization: openSUSE.org Description: The current OOo KDE integration (file dialogs, addressbook, interface/icon theme,...) is based on KDE3. As openSUSE 11.1/SLED 11 will likely not include KDE3 anymore it has to be upgraded to KDE4. Discussion: #1: Stephan Kulow (coolo) (2008-06-13 09:54:23) There are far too many mandatory OOo features. Please reevaluate - it's unlikely that we won't ship KDE3 apps in SLED11 #2: Dirk Mueller (dirkmueller) (2008-06-13 13:25:48) (reply to #1) we will ship KDE3 libs, yes. that doesn't mean that we desire to have KDE3 app dependencies ;) #7: Rajesh Ganesan (ganesanrajesh) (2009-01-07 03:20:08) Well, an excellent idea and most expected too. But (http://kde.openoffice.org/) seems struck at March 2006 itself. Any plans(or chance) of revival? #8: Armin Moradi (amoradi) (2009-01-19 19:30:45) Excellent idea, again, this brings up the consistency issue with the rest of KDE4. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=304879

1 0

[openFate 305543] software mute not in sync with hardware sync
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305543, revision 4 Title: software mute not in sync with hardware sync openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Juergen Weigert (jnweiger) Partner organization: openSUSE.org Description: the GUI is not in sync when pressing the mute button in order to unmute the system. Every user who recognizes that the system is not unmuted by pressing the mute button will surely press volume up. Once done, everything is fine again: system is being unmuted in hardware and the GUI is in sync again. it was like this before for ages. bugzilla#389178 was closed as wontfix, as this is not a regression. I'd appreciate that this be fixed some day. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305543

1 0

[openFate 305534] f-spot should use sqlite3 instead of sqlite2
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Stefan Behlert (sbehlert) Feature #305534, revision 4 Title: f-spot should use sqlite3 instead of sqlite2 openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Desirable Requested by: Juergen Weigert (jnweiger) Partner organization: openSUSE.org Description: Currently sqlite2 ist installed per default (at least if user runs gnome). It would be much better to require sqlite3 and to phase out sqlite2 to those applications that really need the old-version- compatibility. f-spot was ported to sqlite3 in version 0.4.2, and supports the latest sqlite-3.6 since version 0.5.0.2. f-spot-0.5.0.3 is shipping with e.g. SLED 11 BETA6 -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305534

1 0

[openFate 300689] TabletPC: Support Touchscreen and Wacom decives during installation
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Stefan Behlert (sbehlert) Feature #300689, revision 26 Title: TabletPC: Support Touchscreen and Wacom decives during installation openSUSE-10.3: Rejected by Stephan Kulow <coolo(a)novell.com> reject date: 2007-08-03 09:39:40 reject reason: installation is frozen Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-07-16 09:02:38 reject reason: Postponing. Out of resources. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Important Requested by: Stefan Behlert (sbehlert) Partner organization: openSUSE.org Description: Tablet PCs are normally produced in two kinds of flavours: Convertibles, which have a keyboard, and Slates, which have none (only pens or touchscreens). If a user installs a Slate, he has no keyboard and no (pohysical) mouse device, only the touchscreen. We should on TabletPCs automatically recognize that it is a TabletPC and configure the Wacom or other Touchscreen device where possible. Thus would enhance the usability of the product on TabletPCs. Discussion: #1: Gary Ekker (gekker) (2007-07-17 11:24:05) Stefan, do you see this as work that your team would do, something that needs to be done by the YaST installer, or both? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=300689

1 0

[openFate 305336] [NONCODE] Ship man page for every executable
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Matthias Eckermann (mge1512) Feature #305336, revision 14 Title: [NONCODE] Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) + Partner organization: openSUSE.org Description: User / Administrator should find a dedicated man page for every executable in SLE 11 SP 1. This should be implemented starting with openSUSE 11.2. Business case (Partner benefit): - UNIX "parity". + openSUSE.org: UNIX "parity". 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/?rm=feature_show&id=305336

1 0

[openFate 305168] default to relatime
by fate_noreply＠suse.de 23 Jan '09

23 Jan '09

Feature changed by: Sven Burmeister (rabauke) Feature #305168, revision 10 Title: default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky <visnov(a)novell.com> reject date: 2008-09-10 10:20:17 reject reason: This is too late for openSUSE 11.1. Postponing. Priority Requester: Mandatory openSUSE-11.2: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: At least for desktops, we should reduce the memory and I/O thrash caused by atime updates, by using relatime. Relations: - bugreport from community (novell/bugzilla/id: 398616) https://bugzilla.novell.com/show_bug.cgi?id=398616 - Offers 'noatime' when 'relatime' is clearly better (novell/bugzilla/id: 461829) https://bugzilla.novell.com/show_bug.cgi?id=461829 Discussion: #1: Robert Davies (robopensuse) (2009-01-16 15:52:09) Bug #461829 is not requesting breaking POSIX semantics by default! relatime should replace noatime option in the mount options part of partioner tool, especially now it has been improved to update atime on file access if it's older than 24 hours. Standards are important, and LRU file caches cannot be relied on if noatime usage is common, or if poor backup software touches atimes, when reading files. + #2: Sven Burmeister (rabauke) (2009-01-23 01:09:47) + 11.1 is out and 11.2 getting started. Did anyone hear of ubuntu + suffering from using relatime by default? If not, it seems likely that + there are little to none issues. -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305168

1 0

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

22 Jan '09

Feature changed by: Todd R (TheBlackCat) Feature #302923, revision 19 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: Evaluation Priority Requester: Neutral Requested by: Ján Kupec (jkupec) 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) (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) (2007-11-20 11:16:55) so I would reject this. But it's basically "Eval by Klaas" now #3: Klaas Freitag (kfreitag) (2007-12-03 09:49:44) I agree with Coolos and Peters statements, I would also reject. #4: Klaas Freitag (kfreitag) (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? #5: Peter Poeml (poeml) (2008-10-01 11:58:38) YaST/zypper in 11.1 will have preliminary support for this. The essential part of http://en.opensuse.org/Libzypp/Failover has been implemented during a GSoC project this year. See http://lists.opensuse.org/zypp-devel/2008-09/msg00142.html for the status. There is a number of things left to do, like * making it the default * better debuggability - show what it does * better progress report * testing * integration into the install system so it is available during installation Further features from the proposal (mirror preference, simultaneous downloads) are not tackled yet. #6: Federico Lucifredi (flucifredi) (2009-01-07 16:29:58) I would like to see robust redirection, if possible. The details about a list, probably should not be in the feature description. + #7: Todd R (theblackcat) (2009-01-22 22:20:45) + Would this also be able to handle changes in the Buildservice, like + renaming or moving of a certain Buildservice repository? -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=302923

1 0