July 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306488] Package Novell client as part of SLE Media
by fate_noreply＠suse.de 09 Jul '09

09 Jul '09

Feature added by: Sankar P (psankar) Feature #306488, revision 1 Title: Package Novell client as part of SLE Media Requested by: Sankar P (psankar) Description: Package Novell client as part of SLE Media. A) why should we package ? Customers with SLE deployments having OES/NetWare in their data centers need this. B) what is the customer impact if the change is not included NCL has to be separately distributed on a media different from the SLE OS media. C) is there a workaround – if there is please describe what the work around is currently. Download and install NCL, but patch updates may not be available in the patch channel If Novell Client is packaged along with SLE media, it will also help in OES getting the Novell Client by default. Various components of OES (such as Migration) need Novell Client. -- openSUSE Feature: https://features.opensuse.org/306488

1 1

[openFATE 306628] openSUSE Wubi Installation
by fate_noreply＠suse.de 09 Jul '09

09 Jul '09

Feature added by: Raúl García (bgta) Feature #306628, revision 1 Title: openSUSE Wubi Installation openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: Raúl García (bgta) Description: It would be very interesting to be able to install openSUSE through Wubi and Ubuntu. So the ambassadors of openSUSE may provide users an easy installation without the need to create partitions on the disk. -- openSUSE Feature: https://features.opensuse.org/306628

1 2

[openFATE 304879] OOo: Update of KDE integration to KDE4
by fate_noreply＠suse.de 09 Jul '09

09 Jul '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #304879, revision 83 Title: OOo: Update of KDE integration to KDE4 openSUSE-11.1: Rejected by JP Rosevear (jproseve) 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) 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. Use Case: I will find this is really usefull. 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. #9: Ruurd Pels (rfpels) (2009-03-06 22:40:10) Seems to me now that we have 4.2 in FACTORY for 11.1 we can create and release an integration package there so we will be ready by the time SLES11 goes gold. #10: jimbo bigcreed (dimble_thricefoon) (2009-06-04 16:26:13) this would be nice for 11.2 #11: Karsten König (remur) (2009-06-15 15:23:55) Good news everybody! http://artax.karlin.mff.cuni.cz/~kendy/blog/archives/monthly/2009-06.html#2… (Just for tracking, most openfate users propably have seen this by now on planetsuse) #12: jimbo bigcreed (dimble_thricefoon) (2009-06-16 18:41:27) (reply to #11) dot.kde http://www.kdedevelopers.org/node/3983 - KDE4 integration done by the kubuntu boys #13: Stephan Binner (beineri) (2009-07-01 20:17:03) (reply to #12) An early OpenOffice_org-kde4 package exists in Factory so this should be change to Candidate. -- openSUSE Feature: https://features.opensuse.org/304879

1 0

[openFATE 306581] buildservice should be readable without login
by fate_noreply＠suse.de 09 Jul '09

09 Jul '09

Feature added by: Linux Tag (LinuxTag2009) Feature #306581, revision 1 Title: buildservice should be readable without login Buildservice: Unconfirmed Priority Requester: Important Requested by: Linux Tag (linuxtag2009) Description: buildservice should be readable without login. Use Case: wouild be helpful to upstream -- openSUSE Feature: https://features.opensuse.org/306581

1 3

[openFATE 306407] Do not make lang packages mandatory
by fate_noreply＠suse.de 09 Jul '09

09 Jul '09

Feature changed by: Ludwig Nussel (lnussel) Feature #306407, revision 8 Title: Do not make lang packages mandatory openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Mandatory Requested by: Vincent Untz (vuntz) Description: Right now, packages which have a split lang package have "Requires: % {name]-lang". I think that in most cases, this requires is wrong and it should really be a Recommends. FWIW, one thing that is blocking to implement this for GNOME is that the english help files automatically end up in the lang package, while they shouldn't: https://bugzilla.novell.com/show_bug.cgi?id=449847 Discussion: #1: Stephan Binner (beineri) (2009-05-07 08:59:25) The -lang and bundle packages contain also en/C data files and/or manuals. Or you sure that every application checks correctly for their absence? #2: Vincent Untz (vuntz) (2009-05-07 13:09:28) (reply to #1) Stephan: that's more or less the bug I linked to :-) We certainly need to be careful and check for this kind of stuff. #3: Andreas Jaeger (a_jaeger) (2009-07-09 14:32:59) Coolo, could you comment on this and evaluate it, please? #4: Stephan Kulow (coolo) (2009-07-09 14:35:49) (reply to #3) meanwhile I'm convinced myself that using Requires is wrong - as we're cheating anyway in only giving it e.g. german or spanish language. #5: Stephan Kulow (coolo) (2009-07-09 14:36:29) (reply to #4) the question though is: who will do this. We should do it consistently I guess. + #6: Ludwig Nussel (lnussel) (2009-07-09 15:04:33) (reply to #5) + Consistency can be enforced later. Officially allowing/encouraging + Recommends would be quite helpful already so packages can be changed if + they need to be touched anyways. -- openSUSE Feature: https://features.opensuse.org/306407

1 0

[openFATE 306407] Do not make lang packages mandatory
by fate_noreply＠suse.de 09 Jul '09

09 Jul '09

Feature changed by: Stephan Kulow (coolo) Feature #306407, revision 7 Title: Do not make lang packages mandatory openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Mandatory Requested by: Vincent Untz (vuntz) Description: Right now, packages which have a split lang package have "Requires: % {name]-lang". I think that in most cases, this requires is wrong and it should really be a Recommends. FWIW, one thing that is blocking to implement this for GNOME is that the english help files automatically end up in the lang package, while they shouldn't: https://bugzilla.novell.com/show_bug.cgi?id=449847 Discussion: #1: Stephan Binner (beineri) (2009-05-07 08:59:25) The -lang and bundle packages contain also en/C data files and/or manuals. Or you sure that every application checks correctly for their absence? #2: Vincent Untz (vuntz) (2009-05-07 13:09:28) (reply to #1) Stephan: that's more or less the bug I linked to :-) We certainly need to be careful and check for this kind of stuff. #3: Andreas Jaeger (a_jaeger) (2009-07-09 14:32:59) Coolo, could you comment on this and evaluate it, please? + #4: Stephan Kulow (coolo) (2009-07-09 14:35:49) (reply to #3) + meanwhile I'm convinced myself that using Requires is wrong - as we're + cheating anyway in only giving it e.g. german or spanish language. + #5: Stephan Kulow (coolo) (2009-07-09 14:36:29) (reply to #4) + the question though is: who will do this. We should do it consistently + I guess. -- openSUSE Feature: https://features.opensuse.org/306407

1 0

[openFATE 305586] Desktop independent global notification framework
by fate_noreply＠suse.de 09 Jul '09

09 Jul '09

Feature changed by: Will Stephenson (wstephenson) Feature #305586, revision 22 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. #10: Andreas Jaeger (a_jaeger) (2009-07-09 10:21:44) Ubuntu is working on a notification framework well (https://wiki.ubuntu.com/NotifyOSD). Are those in a state that we can make a decision to go one way or the other? Initially we could add it as optional package and ask for feedback with Milestone 4 - and then decide what to do. + #11: Will Stephenson (wstephenson) (2009-07-09 14:34:30) (reply to + #10) + The discussion about notification APIs is still very active on the XDG + list. I recommend not adopting either the Ubuntu proposal or the + galago derived fdo Notification spec until a standard has been agreed. + 1) The Notification spec is not a standard. Its unilateral assumption + of the org.freedesktop.Notification namespace is controversial. A + standard spec is still under discussion. + 2) The Ubuntu design makes strong and arbitrary restrictions on what + can be shown in the notification. + The intention of the current discussion is to design a notification API + that can be a superset of the Ubuntu proposal and provides the features + required by several projects outside Ubuntu. Since a productive + discussion is still taking place, making a premature decision would + undermine the XDG standards process and cause additional work when a + final spec is agreed. + -- openSUSE Feature: https://features.opensuse.org/305586

1 0

[openFATE 306407] Do not make lang packages mandatory
by fate_noreply＠suse.de 09 Jul '09

09 Jul '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #306407, revision 5 Title: Do not make lang packages mandatory - openSUSE-11.2: Unconfirmed + openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Important Requested by: Vincent Untz (vuntz) Description: Right now, packages which have a split lang package have "Requires: % {name]-lang". I think that in most cases, this requires is wrong and it should really be a Recommends. FWIW, one thing that is blocking to implement this for GNOME is that the english help files automatically end up in the lang package, while they shouldn't: https://bugzilla.novell.com/show_bug.cgi?id=449847 Discussion: #1: Stephan Binner (beineri) (2009-05-07 08:59:25) The -lang and bundle packages contain also en/C data files and/or manuals. Or you sure that every application checks correctly for their absence? #2: Vincent Untz (vuntz) (2009-05-07 13:09:28) (reply to #1) Stephan: that's more or less the bug I linked to :-) We certainly need to be careful and check for this kind of stuff. + #3: Andreas Jaeger (a_jaeger) (2009-07-09 14:32:59) + Coolo, could you comment on this and evaluate it, please? -- openSUSE Feature: https://features.opensuse.org/306407

1 0

[openFATE 306407] Do not make lang packages mandatory
by fate_noreply＠suse.de 09 Jul '09

09 Jul '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #306407, revision 6 Title: Do not make lang packages mandatory openSUSE-11.2: Evaluation Priority Requester: Desirable - Projectmanager: Important Requested by: Vincent Untz (vuntz) Description: Right now, packages which have a split lang package have "Requires: % {name]-lang". I think that in most cases, this requires is wrong and it should really be a Recommends. FWIW, one thing that is blocking to implement this for GNOME is that the english help files automatically end up in the lang package, while they shouldn't: https://bugzilla.novell.com/show_bug.cgi?id=449847 Discussion: #1: Stephan Binner (beineri) (2009-05-07 08:59:25) The -lang and bundle packages contain also en/C data files and/or manuals. Or you sure that every application checks correctly for their absence? #2: Vincent Untz (vuntz) (2009-05-07 13:09:28) (reply to #1) Stephan: that's more or less the bug I linked to :-) We certainly need to be careful and check for this kind of stuff. #3: Andreas Jaeger (a_jaeger) (2009-07-09 14:32:59) Coolo, could you comment on this and evaluate it, please? -- openSUSE Feature: https://features.opensuse.org/306407

1 0

[openFATE 305586] Desktop independent global notification framework
by fate_noreply＠suse.de 09 Jul '09

09 Jul '09

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305586, revision 21 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. + #10: Andreas Jaeger (a_jaeger) (2009-07-09 10:21:44) + Ubuntu is working on a notification framework well + (https://wiki.ubuntu.com/NotifyOSD). + Are those in a state that we can make a decision to go one way or the + other? + Initially we could add it as optional package and ask for feedback with + Milestone 4 - and then decide what to do. -- openSUSE Feature: https://features.opensuse.org/305586

1 0