November 2013 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 316728] WebUI links on Hermes Build failure notifications
by fate_noreply＠suse.de 20 Nov '13

20 Nov '13

Feature added by: Claudio Freire (klaussfreire) Feature #316728, revision 1 Title: WebUI links on Hermes Build failure notifications Buildservice: Unconfirmed Priority Requester: Desirable Requested by: Claudio Freire (klaussfreire) Partner organization: openSUSE.org Description: It would save quite a lot of searching and general annoyance if hermes notifications e-mails for build failure (and in general package-related stuff) had a link to OBS WebUI in addition to instructions with osc. We don't always have osc at hand when we get those emails, you know... -- openSUSE Feature: https://features.opensuse.org/316728

1 0

[openFATE 307846] Kolab groupware server support by openSUSE
by fate_noreply＠suse.de 20 Nov '13

20 Nov '13

Feature added by: Richard Bos (rbos) Feature #307846, revision 1 Title: Kolab groupware server support by openSUSE openSUSE-11.3: Unconfirmed Priority Requester: Neutral Requested by: Richard Bos (rbos) Description: Kolab (http://kolab.org) is a free and open software groupware solution. It allows seamless support of mixed clients environments (Outlook/KDE/Web). The following functionality is provided by kolab; groupware (free/busy information), email, spam and virus filtering, a webinterface for the system administrator and end user. The web interface can be used to add, modify and remove users, domains, distributions list, shared folders, among other things. Kolab is build from only open source software, and the data it stores is freely available by the end user. This means that if the end user is not satisfied with the provided service delivered by the service provider, the end user can retrieve his or her data and move it to somewhere else. The Kolab groupware server is assembled with postfix, cyrus, amavis, openldap, apache among other open source projects. Due to its design the kolab server supports multiple domains and thousands of end users. Clients that can be used with Kolab groupware server are for example KDE's kontact, horde, MS Outlook in combination with a connector. Kolab for openSUSE has been available for a long time already, but it was always necessary to patch multiple projects to provide all (groupware) functionality. Since September 2009, it is only necessary to extend cyrus with some patches to get the required functionality. Hence in order to have Kolab working on openSUSE cyrus must be patched. The patched cyrus version can be retrieved from the build service. Kolab is it worth to be supported by openSUSE as it is composed of only open source software, it supports thousands of end users, and very unique end users have full control over all their data including their groupware information! -- openSUSE Feature: https://features.opensuse.org/307846

1 21

[openFATE 312568] YaST: add support for systemd service in Services Manager (replacement for Runlevel Editor)
by fate_noreply＠suse.de 19 Nov '13

19 Nov '13

Feature changed by: Vladimir Moravec (vmoravec) Feature #312568, revision 17 Title: YaST: add support for systemd service in Services Manager (replacement for Runlevel Editor) - openSUSE Distribution: Implementation + openSUSE Distribution: Done Priority Requester: Important Projectmanager: Mandatory Requested by: Frederic Crozat (fcrozat) Partner organization: openSUSE.org Description: Yast runlevel editor should be able to detect if systemd is running and allow to enable/disable systemd service (which can shadow some sysvinit services). Relations: - systemd adaptation of YaST (novell/bugzilla/id: https://bugzilla.novell.com/show_bug.cgi?id=664548) https://bugzilla.novell.com/show_bug.cgi?id=https://bugzilla.novell.com/sho… Documentation Impact: Admin Guide (systemd.xml) Discussion: #2: Frederic Crozat (fcrozat) (2012-01-06 11:27:40) YaST support (probably adding a service) should talk to systemd using D- Bus API (like it is already done in systemd gtk gui), so it won't have to handle merge of configuration and so on. #3: Andreas Jaeger (a_jaeger) (2013-07-19 11:14:53) Isn't this done already? #4: Frederic Crozat (fcrozat) (2013-07-19 11:33:27) (reply to #3) it is : http://kobliha-suse.blogspot.fr/2013/06/yast-runlevel-is-dead-long-live-yas… #5: Andreas Jaeger (a_jaeger) (2013-07-19 11:35:51) (reply to #4) Thanks - written in ruby. So, if we go to ruby, this is done. Thus not marking yet as done but leaving it open for evaluation until a decision is made that the ruby version will be the SLE 12 one. #6: Lukas Ocilka (locilka) (2013-07-30 14:31:47) (reply to #5) Code is here: https://github.com/yast/yast-services-manager And Ruby is set :) Anyway, some parts are still missing... #7: Jiri Srain (jsrain) (2013-08-15 14:57:26) (reply to #6) So, let's finish them :-) #8: Lukas Ocilka (locilka) (2013-09-02 16:56:49) (reply to #7) Vlado, please, take over. #9: Lukas Ocilka (locilka) (2013-11-18 09:48:48) Vladimir, isn't this already done? #10: Vladimir Moravec (vmoravec) (2013-11-19 14:42:48) (reply to #9) Oh, yes, it's been already implemented. -- openSUSE Feature: https://features.opensuse.org/312568

1 0

[openFATE 312568] YaST: add support for systemd service in Services Manager (replacement for Runlevel Editor)
by fate_noreply＠suse.de 19 Nov '13

19 Nov '13

Feature changed by: Vladimir Moravec (vmoravec) Feature #312568, revision 16 Title: YaST: add support for systemd service in Services Manager (replacement for Runlevel Editor) openSUSE Distribution: Implementation Priority Requester: Important Projectmanager: Mandatory Requested by: Frederic Crozat (fcrozat) Partner organization: openSUSE.org Description: Yast runlevel editor should be able to detect if systemd is running and allow to enable/disable systemd service (which can shadow some sysvinit services). Relations: - systemd adaptation of YaST (novell/bugzilla/id: https://bugzilla.novell.com/show_bug.cgi?id=664548) https://bugzilla.novell.com/show_bug.cgi?id=https://bugzilla.novell.com/sho… Documentation Impact: Admin Guide (systemd.xml) Discussion: #2: Frederic Crozat (fcrozat) (2012-01-06 11:27:40) YaST support (probably adding a service) should talk to systemd using D- Bus API (like it is already done in systemd gtk gui), so it won't have to handle merge of configuration and so on. #3: Andreas Jaeger (a_jaeger) (2013-07-19 11:14:53) Isn't this done already? #4: Frederic Crozat (fcrozat) (2013-07-19 11:33:27) (reply to #3) it is : http://kobliha-suse.blogspot.fr/2013/06/yast-runlevel-is-dead-long-live-yas… #5: Andreas Jaeger (a_jaeger) (2013-07-19 11:35:51) (reply to #4) Thanks - written in ruby. So, if we go to ruby, this is done. Thus not marking yet as done but leaving it open for evaluation until a decision is made that the ruby version will be the SLE 12 one. #6: Lukas Ocilka (locilka) (2013-07-30 14:31:47) (reply to #5) Code is here: https://github.com/yast/yast-services-manager And Ruby is set :) Anyway, some parts are still missing... #7: Jiri Srain (jsrain) (2013-08-15 14:57:26) (reply to #6) So, let's finish them :-) #8: Lukas Ocilka (locilka) (2013-09-02 16:56:49) (reply to #7) Vlado, please, take over. #9: Lukas Ocilka (locilka) (2013-11-18 09:48:48) Vladimir, isn't this already done? + #10: Vladimir Moravec (vmoravec) (2013-11-19 14:42:48) (reply to #9) + Oh, yes, it's been already implemented. -- openSUSE Feature: https://features.opensuse.org/312568

1 0

[openFATE 312568] YaST: add support for systemd service in Services Manager (replacement for Runlevel Editor)
by fate_noreply＠suse.de 18 Nov '13

18 Nov '13

Feature changed by: Frank Sundermeyer (fsundermeyer) Feature #312568, revision 15 Title: YaST: add support for systemd service in Services Manager (replacement for Runlevel Editor) openSUSE Distribution: Implementation Priority Requester: Important Projectmanager: Mandatory Requested by: Frederic Crozat (fcrozat) Partner organization: openSUSE.org Description: Yast runlevel editor should be able to detect if systemd is running and allow to enable/disable systemd service (which can shadow some sysvinit services). Relations: - systemd adaptation of YaST (novell/bugzilla/id: https://bugzilla.novell.com/show_bug.cgi?id=664548) https://bugzilla.novell.com/show_bug.cgi?id=https://bugzilla.novell.com/sho… + Documentation Impact: + Admin Guide (systemd.xml) Discussion: #2: Frederic Crozat (fcrozat) (2012-01-06 11:27:40) YaST support (probably adding a service) should talk to systemd using D- Bus API (like it is already done in systemd gtk gui), so it won't have to handle merge of configuration and so on. #3: Andreas Jaeger (a_jaeger) (2013-07-19 11:14:53) Isn't this done already? #4: Frederic Crozat (fcrozat) (2013-07-19 11:33:27) (reply to #3) it is : http://kobliha-suse.blogspot.fr/2013/06/yast-runlevel-is-dead-long-live-yas… #5: Andreas Jaeger (a_jaeger) (2013-07-19 11:35:51) (reply to #4) Thanks - written in ruby. So, if we go to ruby, this is done. Thus not marking yet as done but leaving it open for evaluation until a decision is made that the ruby version will be the SLE 12 one. #6: Lukas Ocilka (locilka) (2013-07-30 14:31:47) (reply to #5) Code is here: https://github.com/yast/yast-services-manager And Ruby is set :) Anyway, some parts are still missing... #7: Jiri Srain (jsrain) (2013-08-15 14:57:26) (reply to #6) So, let's finish them :-) #8: Lukas Ocilka (locilka) (2013-09-02 16:56:49) (reply to #7) Vlado, please, take over. #9: Lukas Ocilka (locilka) (2013-11-18 09:48:48) Vladimir, isn't this already done? -- openSUSE Feature: https://features.opensuse.org/312568

1 0

[openFATE 100011] Remove SuSEconfig
by fate_noreply＠suse.de 18 Nov '13

18 Nov '13

Feature changed by: Frank Sundermeyer (fsundermeyer) Feature #100011, revision 27 Title: Remove SuSEconfig openSUSE-10.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-08-25 14:59:37 reject reason: We cannot remove all of it. We're currently looking at individual scripts and improve those. Priority Requester: Desirable openSUSE-10.3: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-09-20 17:15:47 reject reason: we cannot remove it completely for now. Thorsten filled requests for single scripts. Priority Requester: Desirable openSUSE Distribution: Done Priority Requester: Mandatory SL-10.1: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-01-05 17:35:29 reject reason: not done for 10.1 Priority Requester: Neutral Requested by: Andreas Jaeger (a_jaeger) - Documentation Editor: Frank Spielmann (fs) Partner organization: openSUSE.org Description: Let's remove all SuSEconfig scripts since only YaST calls SuSEconfig but other tools like rpm and zypper do not call it. If scripts are needed, they need to be invoked as part of the postinstall. Relations: - Forbid new SuSEconfig scripts in autobuild (feature/id: 300890) - Remove SuSEconfig dependency of syslog-ng (feature/id: 300891) - Get rid of SuSEconfig.news (feature/id: 300892) - Get rid of SuSEconfig.zmessages (feature/id: 300893) - Get rid of SuSEconfig.sortpasswd (feature/id: 300894) - Get rid of SuSEconfig.libxml2 (feature/id: 300946) - Get rid of SuSEconfig.pango (feature/id: 300947) - Get rid of SuSEconfig.scrollkeeper (feature/id: 300948) - Get rid of SuSEconfig.sgml-skel (feature/id: 300949) - Get rid of SuSEconfig.xpdf (feature/id: 300950) - Get rid of SuSEconfig.postfix (feature/id: 309055) - Get rid of SuSEconfig.gtk2 (feature/id: 309370) - Get rid of SuSEconfig.groff (feature/id: 311297) - Get rid of SuSEconfig.ispell (feature/id: 311298) - Get rid of SuSEconfig.words (feature/id: 311299) - Get rid of SuSEconfig.texlive (feature/id: 313535) - Get rid of SuSEconfig.fonts (feature/id: 313536) - Get rid of SuSEconfig.glib2 (feature/id: 313537) - Get rid of SuSEconfig.permissions (feature/id: 313538) - Get rid of SuSEconfig.icu (feature/id: 313539) - Get rid of SuSEconfig.mailman (feature/id: 313540) - Get rid of SuSEconfig.ghostscript-cjk (feature/id: 313541) - Get rid of SuSEconfig.isdn (feature/id: 313543) - Get rid of SuSEconfig.cjk-latex (feature/id: 313544) - Get rid of SuSEconfig.prelink (feature/id: 313545) - Get rid of SuSEconfig.scim (feature/id: 313546) - Get rid of SuSEconfig.scpm (feature/id: 313547) - Get rid of SuSEconfig.sendmail (feature/id: 313548) - Get rid of SuSEconfig.xjdic (feature/id: 313549) Documentation Impact: Remove SuSEconfig references in the manuals Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2005-12-02 00:35:48) Andreas, do you want to set some more concrete targets? #2: Thorsten Kukuk (kukuk) (2012-09-20 15:26:24) aaa_base and filesystem without SuSEconfig are submitted to Factory. YaST2 developer will adjust YaST2. #3: Sharque uddin Ahmed Farooqui (safknw) (2012-10-19 08:14:24) It is going to be in 12.3, right? -- openSUSE Feature: https://features.opensuse.org/100011

1 0

[openFATE 100011] Remove SuSEconfig
by fate_noreply＠suse.de 18 Nov '13

18 Nov '13

Feature changed by: Frank Sundermeyer (fsundermeyer) Feature #100011, revision 26 Title: Remove SuSEconfig openSUSE-10.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-08-25 14:59:37 reject reason: We cannot remove all of it. We're currently looking at individual scripts and improve those. Priority Requester: Desirable openSUSE-10.3: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-09-20 17:15:47 reject reason: we cannot remove it completely for now. Thorsten filled requests for single scripts. Priority Requester: Desirable openSUSE Distribution: Done Priority Requester: Mandatory SL-10.1: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-01-05 17:35:29 reject reason: not done for 10.1 Priority Requester: Neutral Requested by: Andreas Jaeger (a_jaeger) + Documentation Editor: Frank Spielmann (fs) Partner organization: openSUSE.org Description: Let's remove all SuSEconfig scripts since only YaST calls SuSEconfig but other tools like rpm and zypper do not call it. If scripts are needed, they need to be invoked as part of the postinstall. Relations: - Forbid new SuSEconfig scripts in autobuild (feature/id: 300890) - Remove SuSEconfig dependency of syslog-ng (feature/id: 300891) - Get rid of SuSEconfig.news (feature/id: 300892) - Get rid of SuSEconfig.zmessages (feature/id: 300893) - Get rid of SuSEconfig.sortpasswd (feature/id: 300894) - Get rid of SuSEconfig.libxml2 (feature/id: 300946) - Get rid of SuSEconfig.pango (feature/id: 300947) - Get rid of SuSEconfig.scrollkeeper (feature/id: 300948) - Get rid of SuSEconfig.sgml-skel (feature/id: 300949) - Get rid of SuSEconfig.xpdf (feature/id: 300950) - Get rid of SuSEconfig.postfix (feature/id: 309055) - Get rid of SuSEconfig.gtk2 (feature/id: 309370) - Get rid of SuSEconfig.groff (feature/id: 311297) - Get rid of SuSEconfig.ispell (feature/id: 311298) - Get rid of SuSEconfig.words (feature/id: 311299) - Get rid of SuSEconfig.texlive (feature/id: 313535) - Get rid of SuSEconfig.fonts (feature/id: 313536) - Get rid of SuSEconfig.glib2 (feature/id: 313537) - Get rid of SuSEconfig.permissions (feature/id: 313538) - Get rid of SuSEconfig.icu (feature/id: 313539) - Get rid of SuSEconfig.mailman (feature/id: 313540) - Get rid of SuSEconfig.ghostscript-cjk (feature/id: 313541) - Get rid of SuSEconfig.isdn (feature/id: 313543) - Get rid of SuSEconfig.cjk-latex (feature/id: 313544) - Get rid of SuSEconfig.prelink (feature/id: 313545) - Get rid of SuSEconfig.scim (feature/id: 313546) - Get rid of SuSEconfig.scpm (feature/id: 313547) - Get rid of SuSEconfig.sendmail (feature/id: 313548) - Get rid of SuSEconfig.xjdic (feature/id: 313549) + Documentation Impact: + Remove SuSEconfig references in the manuals Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2005-12-02 00:35:48) Andreas, do you want to set some more concrete targets? #2: Thorsten Kukuk (kukuk) (2012-09-20 15:26:24) aaa_base and filesystem without SuSEconfig are submitted to Factory. YaST2 developer will adjust YaST2. #3: Sharque uddin Ahmed Farooqui (safknw) (2012-10-19 08:14:24) It is going to be in 12.3, right? -- openSUSE Feature: https://features.opensuse.org/100011

1 0

[openFATE 312568] YaST: add support for systemd service in Services Manager (replacement for Runlevel Editor)
by fate_noreply＠suse.de 18 Nov '13

18 Nov '13

Feature changed by: Lukas Ocilka (locilka) Feature #312568, revision 14 Title: YaST: add support for systemd service in Services Manager (replacement for Runlevel Editor) openSUSE Distribution: Implementation Priority Requester: Important Projectmanager: Mandatory Requested by: Frederic Crozat (fcrozat) Partner organization: openSUSE.org Description: Yast runlevel editor should be able to detect if systemd is running and allow to enable/disable systemd service (which can shadow some sysvinit services). Relations: - systemd adaptation of YaST (novell/bugzilla/id: https://bugzilla.novell.com/show_bug.cgi?id=664548) https://bugzilla.novell.com/show_bug.cgi?id=https://bugzilla.novell.com/sho… Discussion: #2: Frederic Crozat (fcrozat) (2012-01-06 11:27:40) YaST support (probably adding a service) should talk to systemd using D- Bus API (like it is already done in systemd gtk gui), so it won't have to handle merge of configuration and so on. #3: Andreas Jaeger (a_jaeger) (2013-07-19 11:14:53) Isn't this done already? #4: Frederic Crozat (fcrozat) (2013-07-19 11:33:27) (reply to #3) it is : http://kobliha-suse.blogspot.fr/2013/06/yast-runlevel-is-dead-long-live-yas… #5: Andreas Jaeger (a_jaeger) (2013-07-19 11:35:51) (reply to #4) Thanks - written in ruby. So, if we go to ruby, this is done. Thus not marking yet as done but leaving it open for evaluation until a decision is made that the ruby version will be the SLE 12 one. #6: Lukas Ocilka (locilka) (2013-07-30 14:31:47) (reply to #5) Code is here: https://github.com/yast/yast-services-manager And Ruby is set :) Anyway, some parts are still missing... #7: Jiri Srain (jsrain) (2013-08-15 14:57:26) (reply to #6) So, let's finish them :-) #8: Lukas Ocilka (locilka) (2013-09-02 16:56:49) (reply to #7) Vlado, please, take over. + #9: Lukas Ocilka (locilka) (2013-11-18 09:48:48) + Vladimir, isn't this already done? -- openSUSE Feature: https://features.opensuse.org/312568

1 0

[openFATE 315090] Upgrade to Bluez 5
by fate_noreply＠suse.de 14 Nov '13

14 Nov '13

Feature changed by: Antoine Ginies (aginies) Feature #315090, revision 40 Title: Upgrade to Bluez 5 Requested by: Jeffrey Cheung (jeffreycheung) Partner organization: openSUSE.org Description: BlueZ 5 come with numerous new features, API simplifications and other improvements. With this release BlueZ only supports the new Bluetooth Management kernel interface that was introduced in Linux 3.4, so essentially this is the minimum kernel requirement for BlueZ 5. For Low Energy support at least kernel version 3.5 is needed. The new major version indicates that the API is not backwards compatible with BlueZ 4, which means that any applications, agents, etc will need to be updated. The BlueZ internal test scripts and tools have naturally already been updated to support the new API. The BlueZ version in SLE11 SP3 is BlueZ 4.99 which mean that regardless of new features, and improvements, we have to upgrade definitely. References: Packages: ofono + Documentation Impact: + RN Discussion: #1: Frederic Crozat (fcrozat) (2013-06-25 16:26:22) Bluez 5 can be installed in parallel with Bluez4, allowing applications not ported to BlueZ 5 API to work properly #2: Frederic Crozat (fcrozat) (2013-07-02 16:53:42) (reply to #1) it looks like I was a bit optimistic. You can only have one BlueZ installed (4 or 5) and they aren't API compatible, which requires having all BT applications moved to BlueZ 5.. #3: Jeffrey Cheung (jeffreycheung) (2013-08-05 12:06:33) So, can this fate proceed ? #4: Ludwig Nussel (lnussel) (2013-08-07 10:34:47) (reply to #3) We are past feature freeze with Milestone 4 now. I suppose this will affect the desktops so please evaluate the potential fallout and discuss on the Factory mailinglist whether it's still possible to fix the affected packages. #5: Jeffrey Cheung (jeffreycheung) (2013-08-07 11:15:59) (reply to #4) Hi Ludwig Nussel, Thanks of reminder. I already send email to factory mailing list. The current status is that RD finished the x86-64 part but i386 not yet. #6: Stefan Seyfried (seife) (2013-08-07 17:00:41) Also note that the bluez library is deprecated with bluez5, so if we want to do it "right", we should not pass --enable-library to configure. The consequence if this is that almost everything that uses bluez will break, though :-) #7: Jeffrey Cheung (jeffreycheung) (2013-08-08 15:39:18) (reply to #6) Thanks and RD acknowledged your comment. We may miss upgrade at openSUSE 13.1 and wait for 13.2 next year. However, we will keep working for SLE12. #12: Petr Tesařík (ptesarik) (2013-08-20 14:03:06) FWIW the Bluetooth stack is currently broken in Factory. At least I cannot get my BT headset to work. We would have to make our own patch to fix this bug (backporting from upstream is hard because of API changes). I'm afraid the maintenance cost in SLE12 lifetime is prohibitively high, not even daring to think about security monitoring. #16: Al Cho (acho-novell) (2013-08-21 15:02:41) (reply to #12) Hi Petr, Thanks for your comment. and Would you file a bug to me about your headset doesn't work ? ( or the bug is already there? ) I would fix it. Thanks, AL #20: Petr Tesařík (ptesarik) (2013-08-23 12:46:13) (reply to #16) The failure seems to be somewhat related to the HCI hardware, not to the bluez version. I only wanted to mention it as an example, but it wasn't a good one after all. Nevertheless, I still believe that providing L3 support for an outdated bluez version for years is too much effort. Moreover, this would be wasted effort, while helping to update dependent packages (in upstream) pays off. #13: Ondrej Holecek (oholecek) (2013-08-20 15:05:24) Note that current PulseAudio (4.0) does not support Bluez5. PulseAudio 5.0 with initial Bluez5 support was planned to release around upcoming GNOME 3.10 (end of September AFAIK) but freeze was postponed so this target was missed. #14: Petr Tesařík (ptesarik) (2013-08-21 11:50:56) (reply to #13) This is sweet. So, the same Lennart who repeatedly introduced incompatible changes in the infrastructure and asked everybody to adapt, has been unable for over a year to adapt his fine software to a similar change in the infrastructure he's using... Why am I surprized? *sigh* #18: Joey Lee (joeyli) (2013-08-23 07:06:48) Thanks for the comments from Petr, Ondrej and Scott. Per Scott's comment, looks Gnome will move to support BlueZ 5. If there doesn't have KDE in SLE-12, then I think move to BlueZ 5 in SLE-12 is make sense. This FATE highly dependent to the development progress of desktop UI(e. g. Gname, KDE) but not just replace the BlueZ package and take care the bluetooth driver in kernel. So, I suggest add desktop engineering leader and Gnome experts to this FATE to collaborative work. #19: Jeffrey Cheung (jeffreycheung) (2013-08-23 15:42:17) Very well, AL, please watch closely the gnome development. Hi Scott, can you provide your member which AL can cowork with. #25: Scott Reeves (sreeves1) (2013-08-30 17:26:23) (reply to #19) For now just directly to me. #21: Jeffrey Cheung (jeffreycheung) (2013-08-25 23:28:54) Add Some current mail thread from openSUSE factory mailing list (1) From Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org> Jeffrey, looking at where GNOME 3.10 is heading, we discuss as much as there is need for: but in the end, GNOME 3.10 will depend on BlueZ5; As such, it's much better for us to switch sooner than later; and Raymond is doing the best job there is to get KDE in line with these requirements as well. So, I would really recommend that we bite the bullet and push BlueZ5 to Factory ASAP! The good thing: we won't be alone with this: Fedora 20 will have the same setup. So we can surely profit from each other there. If we stay with Bluez4, then we have to be aware that for GNOME this might or might not work; surely, upstream support will not be given in this case. If you're planning to such tricks for SLE, I urge you to rethink such a plan. Again, for openSUSE: BlueZ5 is mainly ready, the 'legacy API' needs to be enabled (which is done by Seife) and the stuff relying on the DBUS interface needs to be made aware of the new interface (not backwards compatible). It's a one-time pain we have to take now; or we split the pain over two releases. Cheers, Dominique -- Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org> -------------------------------------------------------------------------------- (2) From Stefan Seyfried <stefan.seyfried(a)googlemail.com> Hi Jeffrey, I was the one objecting the update. But then I did not know that there is already software using (even depending on) bluez5. My impression was that there is "no need to rush" for 13.1. And when I had looked last, there was no sign of fedora using bluez5 "soon". Now that these things have changed (GNOME 3.10 depends on bluez5, KDE will most likely be able to use it) and we won't be the first and only users of bluez5, I agree with Dominique's assessment that it probably is best to switch to the newer version and not mess around with the old stuff. If only GNOME would have kept the standalone bluetooth-applet, this would be a total non-brainer since everyone could use it, but they are really trying to create vendor lock-in to their platform :-( For SLES12 anything less than bluez5 is probably a bad ide :-) Best regards, and sorry for any confusion I might have caused with my previous rejection. Stefan -- Stefan Seyfried Linux Consultant & Developer -- GPG Key: 0x731B665B #22: Al Cho (acho-novell) (2013-08-28 10:26:11) Hi All, we also need a new package "ofono" (https://ofono.org/about) if we choose move to bluez 5. Because bluez remove internal support for telephony (HFP and HSP) profiles. They should be implemented using the new Profile interface preferably by the telephony subsystem of choice ( oFono which already supports this). Cheers, AL #23: Jeffrey Cheung (jeffreycheung) (2013-08-29 11:14:27) (reply to #22) Hi Stefan, per Al, we need the new package "ofono", can we just add the package directly ? #24: Stefan Behlert (sbehlert) (2013-08-29 08:48:19) (reply to #23) Sure, if the license is ok (seems to be GPL2 if I did not misread) and there's a maintainer. I assume it will be in Factory soon? Iexpect we will notice it is required due to dependencies when we start with the SLE 12 images? -- openSUSE Feature: https://features.opensuse.org/315090

1 0

[New: openFATE 313777] OpenSuSE UX/UI Refresh Proposal
by fate_noreply＠suse.de 14 Nov '13

14 Nov '13

Feature added by: Matthew Nawrocki (mattrock1988) Feature #313777, revision 1 Title: OpenSuSE UX/UI Refresh Proposal openSUSE Distribution: Unconfirmed Priority Requester: Important Requested by: Matthew Nawrocki (mattrock1988) Partner organization: openSUSE.org Description: OpenSuSE prides itself in being one of the few older projects to still have an active following as compared to the rest of the GNU/Linux Distributions that exist currently. However, in order to see OpenSuSE rise to the top right next to the likes of Ubuntu and Mint, I suggest that we design a wholly new desktop environment based on Wayland, exclusively for OpenSuSE. I would like to head or at least assist in an effort to design a new desktop environment, exclusive to OpenSuSE that captures the fascination of everyone who uses it. A quality user interface that is not confusing, fast and makes use of 3D acceleration for a smooth experience are a few of the goals to aim for. And of course, the idea is not to be different for the sake of being different, but to truly bring out OpenSuSE's potential as a desktop operating system. I can contribute mock ups of the UX/UI design for the proposed environment and leave the floor open to comments, criticisms and suggestions. This way, we as a community can have a desktop environment to truly call our own that makes everyone excited to give OpenSuSE a spin and eventually permanently install on their computer. Of course, for a project like this to be successful, a team would need to be formed around this to help drive the effort to a home run finish. Because this is a UX proposal, it is imperative to also give the security model, package management and other user tools a look to see if there isn't something we can do better than it is already. Business case (Partner benefit): openSUSE.org: This effort isn't so much to reinvent the wheel as it is to give OpenSuSE an exceptionally distinct flavor in the desktop Linux arena, avoiding the me-too syndrome that is undoubtedly prevalent in countless other Linux distributions that exist today using KDE and GNOME. After investigating the recent success in marketshare growth of both Ubuntu and Mint, thanks to their respective overhauls of the desktop experience with Unity and Cinnamon, OpenSuSE could definitely benefit from this as well. Everyone, nerds and regular folk alike, crave a clean and fun, yet consistent and organized experience that brings a fresh look to the table without "throwing the baby out with the bathwater" in regards to time tested principles in UI design, much like how KDE and GNOME have done in recent years. -- openSUSE Feature: https://features.opensuse.org/313777

1 10