Am Tue, 13 Aug 2013 23:59:15 +0000 schrieb devel-request@lists.fedoraproject.org:
----- Original Message -----
On 08/02/2013 10:15 AM, Jaroslav Reznik wrote:
Let me know - I'd like to have this one as a Change if it's going to F20
I have been coordinating with various people and looks like all teams are go. NetworkManager and PulseAudio changes are slightly lagging behind, but it's probably best if we move forward and try to integrate everything together in Rawhide before branching F20.
I've cleaned up the feature page and marked it as ready for wrangler:
The page looks good, thanks for coordination. Just could you please extend the scope with resolution for mate bt? Also for contingency plan, I'd like to see a real deadline - Beta as a point to revert things as a coordination would be needed. Once done, pls let me know and I'll announce it and report to FESCo to get an exception.
I don't see that adding a bluetooth-panel-applet package is easy for mate/xfce/lxde. First tests shows me that the removed panel code from gnome-bluetooth isn't independent from the the rest of the code. I quess for this reason the gnome dev didn't remove /usr/lib64/gnome-bluetooth/libgnome-bluetooth-applet.so.0, which is in latest upstream.
Ok, i need really help to create such a package.
But there is also another simple solution........ gnome-bluetooth dev should add the removed (fallback) panel applet code back. I'm pretty shure that is more easier for someone who knows the code to do that.
If gnome-bluetooth is the only client after the bluez5 switch which is working in fedora, than it should be work for all desktops, imo.
So adding the applet back would be a noble gesture from gnome to other desktops ;)
PS: i think cinnamon is also affected, because so far i know use cinnamon blueman code in the momment. But i'm not shure in this point.
On Wed, 14 Aug 2013 12:40:54 +0200 Rave it chat-to-me@raveit.de wrote:
I don't see that adding a bluetooth-panel-applet package is easy for mate/xfce/lxde. First tests shows me that the removed panel code from gnome-bluetooth isn't independent from the the rest of the code. I quess for this reason the gnome dev didn't remove /usr/lib64/gnome-bluetooth/libgnome-bluetooth-applet.so.0, which is in latest upstream.
Ok, i need really help to create such a package.
But there is also another simple solution........ gnome-bluetooth dev should add the removed (fallback) panel applet code back. I'm pretty shure that is more easier for someone who knows the code to do that.
If gnome-bluetooth is the only client after the bluez5 switch which is working in fedora, than it should be work for all desktops, imo.
So adding the applet back would be a noble gesture from gnome to other desktops ;)
PS: i think cinnamon is also affected, because so far i know use cinnamon blueman code in the momment. But i'm not shure in this point.
I've exchanged some emails with the author of https://github.com/ncopa/xfce-bluetooth
Unfortunately, the code there is in very early alpha stage. It doesn't do a whole lot yet. He's happy to have any help implementing things, but makes no promises as to when things will be usable.
This applet depends on vala and the xfce-vala bindings, so I am not sure if it would work for other desktops, but its possible that it could.
If anyone would be interested in helping out with this applet, please contact the maintainer.
For Xfce, we could use this if it becomes usable in time, or we could use some other systray producting applet, or we could just not support bluetooth from the desktop for this release. ;(
kevin
On Sun 18 August 2013 10:00:22 Kevin Fenzi wrote:
On Wed, 14 Aug 2013 12:40:54 +0200
Rave it chat-to-me@raveit.de wrote:
I don't see that adding a bluetooth-panel-applet package is easy for mate/xfce/lxde. First tests shows me that the removed panel code from gnome-bluetooth isn't independent from the the rest of the code. I quess for this reason the gnome dev didn't remove /usr/lib64/gnome-bluetooth/libgnome-bluetooth-applet.so.0, which is in latest upstream.
Ok, i need really help to create such a package.
But there is also another simple solution........ gnome-bluetooth dev should add the removed (fallback) panel applet code back. I'm pretty shure that is more easier for someone who knows the code to do that.
If gnome-bluetooth is the only client after the bluez5 switch which is working in fedora, than it should be work for all desktops, imo.
So adding the applet back would be a noble gesture from gnome to other desktops ;)
PS: i think cinnamon is also affected, because so far i know use cinnamon blueman code in the momment. But i'm not shure in this point.
I've exchanged some emails with the author of https://github.com/ncopa/xfce-bluetooth
Unfortunately, the code there is in very early alpha stage. It doesn't do a whole lot yet. He's happy to have any help implementing things, but makes no promises as to when things will be usable.
This applet depends on vala and the xfce-vala bindings, so I am not sure if it would work for other desktops, but its possible that it could.
If anyone would be interested in helping out with this applet, please contact the maintainer.
For Xfce, we could use this if it becomes usable in time, or we could use some other systray producting applet, or we could just not support bluetooth from the desktop for this release. ;(
It sounds like BlueZ5 is not ready for Fedora, betwen the "early alpha" XFCE code, and shipping git BlueDevil, mate and cinnamon don't appear to work with it ...
Basically we ship Fedora 20 in a state where one only of our major desktop environments supports bluetooth in a stable fashion? That seems kind of like a disaster waiting to happen.
Ryan
On Sun, Aug 18, 2013 at 11:28 PM, Ryan Rix ry@n.rix.si wrote:
On Sun 18 August 2013 10:00:22 Kevin Fenzi wrote:
On Wed, 14 Aug 2013 12:40:54 +0200
Rave it chat-to-me@raveit.de wrote:
I don't see that adding a bluetooth-panel-applet package is easy for mate/xfce/lxde. First tests shows me that the removed panel code from gnome-bluetooth isn't independent from the the rest of the code. I quess for this reason the gnome dev didn't remove /usr/lib64/gnome-bluetooth/libgnome-bluetooth-applet.so.0, which is in latest upstream.
Ok, i need really help to create such a package.
But there is also another simple solution........ gnome-bluetooth dev should add the removed (fallback) panel applet code back. I'm pretty shure that is more easier for someone who knows the code to do that.
If gnome-bluetooth is the only client after the bluez5 switch which is working in fedora, than it should be work for all desktops, imo.
So adding the applet back would be a noble gesture from gnome to other desktops ;)
PS: i think cinnamon is also affected, because so far i know use cinnamon blueman code in the momment. But i'm not shure in this point.
I've exchanged some emails with the author of https://github.com/ncopa/xfce-bluetooth
Unfortunately, the code there is in very early alpha stage. It doesn't do a whole lot yet. He's happy to have any help implementing things, but makes no promises as to when things will be usable.
This applet depends on vala and the xfce-vala bindings, so I am not sure if it would work for other desktops, but its possible that it could.
If anyone would be interested in helping out with this applet, please contact the maintainer.
For Xfce, we could use this if it becomes usable in time, or we could use some other systray producting applet, or we could just not support bluetooth from the desktop for this release. ;(
It sounds like BlueZ5 is not ready for Fedora, betwen the "early alpha" XFCE code, and shipping git BlueDevil, mate and cinnamon don't appear to work with it ...
Basically we ship Fedora 20 in a state where one only of our major desktop environments supports bluetooth in a stable fashion? That seems kind of like a disaster waiting to happen.
Well the problem is that we have way to many desktops (more desktops then resources). We can't delay changes until every desktop catches up (it basically means we can't move on with stuff at all).
On Sun, Aug 18, 2013 at 02:28:34PM -0700, Ryan Rix wrote:
Basically we ship Fedora 20 in a state where one only of our major desktop environments supports bluetooth in a stable fashion? That seems kind of like a disaster waiting to happen.
The current release blocking desktops are Gnome and KDE. If those are broken then F20 doesn't ship - if they're working, it ships. It'd be unfortunate to ship a release that doesn't support the non-blocking desktops, but (right now) it's fundamentally up to them to provide the development effort to ensure that they have a full feature set.
On Sun, Aug 18, 2013 at 8:03 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Sun, Aug 18, 2013 at 02:28:34PM -0700, Ryan Rix wrote:
Basically we ship Fedora 20 in a state where one only of our major desktop environments supports bluetooth in a stable fashion? That seems kind of like a disaster waiting to happen.
The current release blocking desktops are Gnome and KDE. If those are broken then F20 doesn't ship - if they're working, it ships. It'd be unfortunate to ship a release that doesn't support the non-blocking desktops, but (right now) it's fundamentally up to them to provide the development effort to ensure that they have a full feature set.
-- Matthew Garrett | mjg59@srcf.ucam.org --
Instead of shipping it, is there a problem with giving it to those on the developer list and letting us iron out the kinks?
-- Richard
On 19/08/2013 4:31 PM, "Richard Vickery" richard.vickeryrv@gmail.com wrote:
On Sun, Aug 18, 2013 at 8:03 PM, Matthew Garrett mjg59@srcf.ucam.org
wrote:
On Sun, Aug 18, 2013 at 02:28:34PM -0700, Ryan Rix wrote:
Basically we ship Fedora 20 in a state where one only of our major
desktop
environments supports bluetooth in a stable fashion? That seems kind
of like a
disaster waiting to happen.
The current release blocking desktops are Gnome and KDE. If those are broken then F20 doesn't ship - if they're working, it ships. It'd be unfortunate to ship a release that doesn't support the non-blocking desktops, but (right now) it's fundamentally up to them to provide the development effort to ensure that they have a full feature set.
-- Matthew Garrett | mjg59@srcf.ucam.org --
Instead of shipping it, is there a problem with giving it to those on the developer list and letting us iron out the kinks?
I do not really understand what you mean here....
/Andreas
-- Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Sun, Aug 18, 2013 at 09:48:46PM -0700, Richard Vickery wrote:
Instead of shipping it, is there a problem with giving it to those on the developer list and letting us iron out the kinks?
Sure, that's what already happens. If you want to help, this thread contains a multitude of pointers where to start.
Lars
On Mon, Aug 19, 2013 at 04:03:17AM +0100, Matthew Garrett wrote:
On Sun, Aug 18, 2013 at 02:28:34PM -0700, Ryan Rix wrote:
Basically we ship Fedora 20 in a state where one only of our major desktop environments supports bluetooth in a stable fashion? That seems kind of like a disaster waiting to happen.
The current release blocking desktops are Gnome and KDE. If those are broken then F20 doesn't ship - if they're working, it ships. It'd be unfortunate to ship a release that doesn't support the non-blocking desktops, but (right now) it's fundamentally up to them to provide the development effort to ensure that they have a full feature set.
Actually, due to this Change being submitted after the deadline, this isn't 100% true in this case. Fesco approved the Change like this:
" Bluez5 (nirik, 18:54:28) * AGREED: approve bluez5 landing now -- if the other alternate desktop envs agree to not be blocking, they do not need to be fixed in order for the feature to stay in. If they don't we'll need to see that they can get bluez5 support in time for F20 or evaluate whether to trigger the contingency plan. (+7,0) (nirik, 19:09:11) "
At the meeting, nirik expressed the opinion that xfce could ship in Fedora 20 without working bluetooth but he couldn't speak for the other desktop environments. The other exnivronments need to decide whether they can (A) get some working code that works with the new bluetooth stack or (B) are okay with possibly not shipping with working bluetooth support. If they can't and are not then this Change may need to activate its contingency plan.
-Toshio
On Sun, 2013-08-18 at 14:28 -0700, Ryan Rix wrote:
It sounds like BlueZ5 is not ready for Fedora, betwen the "early alpha" XFCE code, and shipping git BlueDevil, mate and cinnamon don't appear to work with it ...
We're not even at Alpha TC1 yet, remember. It's not unusual for stuff roadmapped for F20 Final to be in a fairly early stage at this point. (Plus what mclasen pointed out about only blocking on GNOME and KDE).
Basically we ship Fedora 20 in a state where one only of our major desktop environments supports bluetooth in a stable fashion? That seems kind of like a disaster waiting to happen.
Have you tried Bluetooth on our major desktop environments in F19? :P
(I kid, I kid, it mostly works well. But still, I have to pair my mouse every damn time I want to use it, for instance.)
On Mon, Aug 19, 2013 at 08:55:01AM -0700, Adam Williamson wrote:
Have you tried Bluetooth on our major desktop environments in F19? :P
(I kid, I kid, it mostly works well. But still, I have to pair my mouse every damn time I want to use it, for instance.)
Oh, is https://bugzilla.redhat.com/show_bug.cgi?id=716479 still the case?