12:53 p.m.
Hi all,
This might be a viewed as a fire torch, but there is, IMO, a major
regression in BlueZ 5 which is shipped in Fedora 20. It doesn't support
HSP/HFP headset profiles, which enables the microphone on many bluetooth
headsets. It's already tracked in this BZ:
<https://bugzilla.redhat.com/show_bug.cgi?id=1045548>
It seems a solution for BlueZ 5 isn't close, especially not for F20.
Upstream is looking at this issue, but not much news have been told yet:
<https://bugs.freedesktop.org/show_bug.cgi?id=73325>
Anyhow, not supporting HSP/HSP profiles is at least hitting my work
ability, and I doubt I'm alone in this situation.
Now, if I had known this before I started upgrading to F20, I wouldn't
have upgraded yet but stayed on F19 a bit longer. However, that's too
late now. This was first listed as a "common bug" about three weeks
after the release.
So, I wonder if it can be considered to enable a "downgrade path" for
bluez and depending packages, as described in the "Contingency Plan":
<https://fedoraproject.org/wiki/Changes/Bluez5>
The other alternative is to tell users to re-install Fedora 19, which I
doubt is such a good alternative in the long run. But I need to
consider that if BlueZ isn't downgraded somehow.
As a side note, it also needs to be discussed how such a key feature of
the bluetooth stack could go unnoticed through QA, and how to avoid this
from happening again.
--
kind regards,
David Sommerseth
12:58 p.m.
On Thu, 23 Jan 2014 19:53:19 +0100
David Sommerseth <davids(a)redhat.com> wrote:
Hi all,
This might be a viewed as a fire torch, but there is, IMO, a major
regression in BlueZ 5 which is shipped in Fedora 20. It doesn't
support HSP/HFP headset profiles, which enables the microphone on
many bluetooth headsets. It's already tracked in this BZ:
is just downgrading bluez any help?
yum downgrade bluez* --releasever=19
___
Regards,
Frank
www.frankly3d.com
1:04 p.m.
On 23/01/14 19:58, Frank Murphy wrote:
On Thu, 23 Jan 2014 19:53:19 +0100
David Sommerseth <davids(a)redhat.com> wrote:
>
> Hi all,
>
> This might be a viewed as a fire torch, but there is, IMO, a major
> regression in BlueZ 5 which is shipped in Fedora 20. It doesn't
> support HSP/HFP headset profiles, which enables the microphone on
> many bluetooth headsets. It's already tracked in this BZ:
>
>
is just downgrading bluez any help?
yum downgrade bluez* --releasever=19
Nope, several packages depends on the bluez-5.13-1 package.
---------------------------
--> Finished Dependency Resolution
Error: Package: pulseaudio-module-bluetooth-4.0-9.gitf81e3.fc20.x86_64
(@updates/20)
Requires: bluez >= 5.0
Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
bluez = 5.13-1.fc20
Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
bluez = 4.101-9.fc19
Available: bluez-4.101-6.fc19.x86_64 (fedora)
bluez = 4.101-6.fc19
Error: Package: 1:gnome-bluetooth-3.10.0-1.fc20.x86_64 (@anaconda/20)
Requires: bluez >= 5.0
Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
bluez = 5.13-1.fc20
Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
bluez = 4.101-9.fc19
Available: bluez-4.101-6.fc19.x86_64 (fedora)
bluez = 4.101-6.fc19
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
----------------------------
Might even be a worse conflict for other users, depending on installed
packages. I believe there's no way around re-compiling NetworkManager,
pulseaudio and other GNOME and KDE packages depending on bluez.
--
kind regards,
David Sommerseth
2:17 p.m.
On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote:
On 23/01/14 19:58, Frank Murphy wrote:
> On Thu, 23 Jan 2014 19:53:19 +0100
> David Sommerseth <davids(a)redhat.com> wrote:
>
>>
>> Hi all,
>>
>> This might be a viewed as a fire torch, but there is, IMO, a major
>> regression in BlueZ 5 which is shipped in Fedora 20. It doesn't
>> support HSP/HFP headset profiles, which enables the microphone on
>> many bluetooth headsets. It's already tracked in this BZ:
>>
>>
>
> is just downgrading bluez any help?
> yum downgrade bluez* --releasever=19
Nope, several packages depends on the bluez-5.13-1 package.
---------------------------
--> Finished Dependency Resolution
Error: Package: pulseaudio-module-bluetooth-4.0-9.gitf81e3.fc20.x86_64
(@updates/20)
Requires: bluez >= 5.0
Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
bluez = 5.13-1.fc20
Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
bluez = 4.101-9.fc19
Available: bluez-4.101-6.fc19.x86_64 (fedora)
bluez = 4.101-6.fc19
Error: Package: 1:gnome-bluetooth-3.10.0-1.fc20.x86_64 (@anaconda/20)
Requires: bluez >= 5.0
Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
bluez = 5.13-1.fc20
Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
bluez = 4.101-9.fc19
Available: bluez-4.101-6.fc19.x86_64 (fedora)
bluez = 4.101-6.fc19
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
----------------------------
Might even be a worse conflict for other users, depending on installed
packages. I believe there's no way around re-compiling NetworkManager,
pulseaudio and other GNOME and KDE packages depending on bluez.
NM only uses bluez via the D-Bus interface, so if you force install
bluez4, NM will still work and should even handle the change at runtime.
And then you'll get DUN back too :)
Dan
2:19 p.m.
On Thu, 2014-01-23 at 14:17 -0600, Dan Williams wrote:
On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote:
> On 23/01/14 19:58, Frank Murphy wrote:
> > On Thu, 23 Jan 2014 19:53:19 +0100
> > David Sommerseth <davids(a)redhat.com> wrote:
> >
> >>
> >> Hi all,
> >>
> >> This might be a viewed as a fire torch, but there is, IMO, a major
> >> regression in BlueZ 5 which is shipped in Fedora 20. It doesn't
> >> support HSP/HFP headset profiles, which enables the microphone on
> >> many bluetooth headsets. It's already tracked in this BZ:
> >>
> >>
> >
> > is just downgrading bluez any help?
> > yum downgrade bluez* --releasever=19
>
> Nope, several packages depends on the bluez-5.13-1 package.
>
> ---------------------------
> --> Finished Dependency Resolution
> Error: Package: pulseaudio-module-bluetooth-4.0-9.gitf81e3.fc20.x86_64
> (@updates/20)
> Requires: bluez >= 5.0
> Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
> bluez = 5.13-1.fc20
> Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
> bluez = 4.101-9.fc19
> Available: bluez-4.101-6.fc19.x86_64 (fedora)
> bluez = 4.101-6.fc19
> Error: Package: 1:gnome-bluetooth-3.10.0-1.fc20.x86_64 (@anaconda/20)
> Requires: bluez >= 5.0
> Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
> bluez = 5.13-1.fc20
> Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
> bluez = 4.101-9.fc19
> Available: bluez-4.101-6.fc19.x86_64 (fedora)
> bluez = 4.101-6.fc19
> You could try using --skip-broken to work around the problem
> You could try running: rpm -Va --nofiles --nodigest
> ----------------------------
>
> Might even be a worse conflict for other users, depending on installed
> packages. I believe there's no way around re-compiling NetworkManager,
> pulseaudio and other GNOME and KDE packages depending on bluez.
NM only uses bluez via the D-Bus interface, so if you force install
bluez4, NM will still work and should even handle the change at runtime.
And then you'll get DUN back too :)
Clarification: I actually don't mean runtime. NM must be restarted to
notice the change from bluez4 <-> bluez5, but it does not need to be
recompiled.
Dan
5:21 a.m.
On 23/01/14 21:19, Dan Williams wrote:
On Thu, 2014-01-23 at 14:17 -0600, Dan Williams wrote:
> On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote:
>> On 23/01/14 19:58, Frank Murphy wrote:
>>> On Thu, 23 Jan 2014 19:53:19 +0100
[...snip...]
>> Might even be a worse conflict for other users, depending on
installed
>> packages. I believe there's no way around re-compiling NetworkManager,
>> pulseaudio and other GNOME and KDE packages depending on bluez.
>
> NM only uses bluez via the D-Bus interface, so if you force install
> bluez4, NM will still work and should even handle the change at runtime.
> And then you'll get DUN back too :)
Clarification: I actually don't mean runtime. NM must be restarted to
notice the change from bluez4 <-> bluez5, but it does not need to be
recompiled.
The DBus interface with bluez5 have changed too.
<http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/>
Does NM support both bluez NM APIs?
--
kind regards,
David SOmmerseth
11:30 a.m.
On Fri, 2014-01-24 at 12:21 +0100, David Sommerseth wrote:
On 23/01/14 21:19, Dan Williams wrote:
> On Thu, 2014-01-23 at 14:17 -0600, Dan Williams wrote:
>> On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote:
>>> On 23/01/14 19:58, Frank Murphy wrote:
>>>> On Thu, 23 Jan 2014 19:53:19 +0100
[...snip...]
>>> Might even be a worse conflict for other users, depending on installed
>>> packages. I believe there's no way around re-compiling NetworkManager,
>>> pulseaudio and other GNOME and KDE packages depending on bluez.
>>
>> NM only uses bluez via the D-Bus interface, so if you force install
>> bluez4, NM will still work and should even handle the change at runtime.
>> And then you'll get DUN back too :)
>
> Clarification: I actually don't mean runtime. NM must be restarted to
> notice the change from bluez4 <-> bluez5, but it does not need to be
> recompiled.
The DBus interface with bluez5 have changed too.
<http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/>
Does NM support both bluez NM APIs?
Correct. It determines which one to use when it starts up, based on what
version of bluez is running at that time.
However, because of a significant change in how DUN works with Bluez5,
NetworkManager does not (yet!) support DUN when Bluez5 is running. We
are working on that.
Dan
11:45 a.m.
On 24/01/14 18:30, Dan Williams wrote:
On Fri, 2014-01-24 at 12:21 +0100, David Sommerseth wrote:
> On 23/01/14 21:19, Dan Williams wrote:
>> On Thu, 2014-01-23 at 14:17 -0600, Dan Williams wrote:
>>> On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote:
>>>> On 23/01/14 19:58, Frank Murphy wrote:
>>>>> On Thu, 23 Jan 2014 19:53:19 +0100
> [...snip...]
>>>> Might even be a worse conflict for other users, depending on installed
>>>> packages. I believe there's no way around re-compiling
NetworkManager,
>>>> pulseaudio and other GNOME and KDE packages depending on bluez.
>>>
>>> NM only uses bluez via the D-Bus interface, so if you force install
>>> bluez4, NM will still work and should even handle the change at runtime.
>>> And then you'll get DUN back too :)
>>
>> Clarification: I actually don't mean runtime. NM must be restarted to
>> notice the change from bluez4 <-> bluez5, but it does not need to be
>> recompiled.
>
> The DBus interface with bluez5 have changed too.
>
> <http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/>
>
> Does NM support both bluez NM APIs?
Correct. It determines which one to use when it starts up, based on what
version of bluez is running at that time.
Perfect!
However, because of a significant change in how DUN works with
Bluez5,
NetworkManager does not (yet!) support DUN when Bluez5 is running. We
are working on that.
Thanks a lot! It makes more sense after having poked at this today.
I've been doing some local mockbuilds today, and noticed I could enable
bluez4 in the NM spec file (it was set to --enable-bluez4=no, afaics),
and I seems to produce some nm-bluez4 files. Now I just need to get the
proper version built, I built the fedpkg NM master by mistake.
--
kind regards,
David Sommerseth
3:58 p.m.
On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote:
Nope, several packages depends on the bluez-5.13-1 package.
Indeed. However I could probably live without gnome-bluetooth if
blueman were still available.
pulseaudio-module-bluetooth though. Would it work with Bluez4? Would
it need a compile to do so? I wonder how you make that a functional
downgrade that users can select if they still need Bluez4.
---------------------------
--> Finished Dependency Resolution
Error: Package: pulseaudio-module-bluetooth-4.0-9.gitf81e3.fc20.x86_64
(@updates/20)
Requires: bluez >= 5.0
Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
bluez = 5.13-1.fc20
Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
bluez = 4.101-9.fc19
Available: bluez-4.101-6.fc19.x86_64 (fedora)
bluez = 4.101-6.fc19
Error: Package: 1:gnome-bluetooth-3.10.0-1.fc20.x86_64 (@anaconda/20)
Requires: bluez >= 5.0
Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
bluez = 5.13-1.fc20
Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
bluez = 4.101-9.fc19
Available: bluez-4.101-6.fc19.x86_64 (fedora)
bluez = 4.101-6.fc19
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
----------------------------
Might even be a worse conflict for other users, depending on installed
packages. I believe there's no way around re-compiling NetworkManager,
pulseaudio and other GNOME and KDE packages depending on bluez.
Indeed. I suspect the same. Perhaps gnome-bluetooth could be
uninstalled and replace with blueman without too much heartburn. It's
the other packages that get troublesome. A
pulseaudio-module-bluetooth-bluez4 as an alternative BT module for PA?
Something similar for NM? It's starting to get ugly and perhaps the
effort spent doing that would be better put towards:
https://bugs.freedesktop.org/show_bug.cgi?id=73325#c5
But either way, it does seem a pretty serious regression. Although
maybe you and me, David, are the only F20 users using HSP bluetooth
headsets. :-/
b.
4:59 p.m.
On Thu, 2014-01-23 at 16:58 -0500, Brian J. Murrell wrote:
On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote:
>
> Nope, several packages depends on the bluez-5.13-1 package.
Indeed. However I could probably live without gnome-bluetooth if
blueman were still available.
pulseaudio-module-bluetooth though. Would it work with Bluez4? Would
it need a compile to do so? I wonder how you make that a functional
downgrade that users can select if they still need Bluez4.
> ---------------------------
> --> Finished Dependency Resolution
> Error: Package: pulseaudio-module-bluetooth-4.0-9.gitf81e3.fc20.x86_64
> (@updates/20)
> Requires: bluez >= 5.0
> Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
> bluez = 5.13-1.fc20
> Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
> bluez = 4.101-9.fc19
> Available: bluez-4.101-6.fc19.x86_64 (fedora)
> bluez = 4.101-6.fc19
> Error: Package: 1:gnome-bluetooth-3.10.0-1.fc20.x86_64 (@anaconda/20)
> Requires: bluez >= 5.0
> Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
> bluez = 5.13-1.fc20
> Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
> bluez = 4.101-9.fc19
> Available: bluez-4.101-6.fc19.x86_64 (fedora)
> bluez = 4.101-6.fc19
> You could try using --skip-broken to work around the problem
> You could try running: rpm -Va --nofiles --nodigest
> ----------------------------
>
> Might even be a worse conflict for other users, depending on installed
> packages. I believe there's no way around re-compiling NetworkManager,
> pulseaudio and other GNOME and KDE packages depending on bluez.
Indeed. I suspect the same. Perhaps gnome-bluetooth could be
uninstalled and replace with blueman without too much heartburn. It's
the other packages that get troublesome. A
pulseaudio-module-bluetooth-bluez4 as an alternative BT module for PA?
Something similar for NM? It's starting to get ugly and perhaps the
effort spent doing that would be better put towards:
https://bugs.freedesktop.org/show_bug.cgi?id=73325#c5
But either way, it does seem a pretty serious regression. Although
maybe you and me, David, are the only F20 users using HSP bluetooth
headsets. :-/
Out of curiosity, what do people use Blueman for?
Dan
5:24 p.m.
On 23/01/14 22:59, Dan Williams wrote:
Out of curiosity, what do people use Blueman for?
Not me personally, but browsing for files on a remote bluetooth device
[1]. With BlueZ 5, one can only push files from a device to a fedora
box (or from a fedora box to a device) [2].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=966247
[2] http://www.hadess.net/2013/11/bluetooth-file-sharing-obexpush-in.html
Colin
7:01 p.m.
On Thu, 2014-01-23 at 16:59 -0600, Dan Williams wrote:
Out of curiosity, what do people use Blueman for?
It includes an applet that could be used instead of the one that ships
with GNOME that is now tied to Bluez5. I was merely putting it forth as
what one could use for an applet if one were to use Bluez4 and one
wanted an applet.
b.
5:26 a.m.
On 23/01/14 23:59, Dan Williams wrote:
On Thu, 2014-01-23 at 16:58 -0500, Brian J. Murrell wrote:
> On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote:
>>
>> Nope, several packages depends on the bluez-5.13-1 package.
>
> Indeed. However I could probably live without gnome-bluetooth if
> blueman were still available.
>
> pulseaudio-module-bluetooth though. Would it work with Bluez4? Would
> it need a compile to do so? I wonder how you make that a functional
> downgrade that users can select if they still need Bluez4.
>
>> ---------------------------
>> --> Finished Dependency Resolution
>> Error: Package: pulseaudio-module-bluetooth-4.0-9.gitf81e3.fc20.x86_64
>> (@updates/20)
>> Requires: bluez >= 5.0
>> Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
>> bluez = 5.13-1.fc20
>> Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
>> bluez = 4.101-9.fc19
>> Available: bluez-4.101-6.fc19.x86_64 (fedora)
>> bluez = 4.101-6.fc19
>> Error: Package: 1:gnome-bluetooth-3.10.0-1.fc20.x86_64 (@anaconda/20)
>> Requires: bluez >= 5.0
>> Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
>> bluez = 5.13-1.fc20
>> Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
>> bluez = 4.101-9.fc19
>> Available: bluez-4.101-6.fc19.x86_64 (fedora)
>> bluez = 4.101-6.fc19
>> You could try using --skip-broken to work around the problem
>> You could try running: rpm -Va --nofiles --nodigest
>> ----------------------------
>>
>> Might even be a worse conflict for other users, depending on installed
>> packages. I believe there's no way around re-compiling NetworkManager,
>> pulseaudio and other GNOME and KDE packages depending on bluez.
>
> Indeed. I suspect the same. Perhaps gnome-bluetooth could be
> uninstalled and replace with blueman without too much heartburn. It's
> the other packages that get troublesome. A
> pulseaudio-module-bluetooth-bluez4 as an alternative BT module for PA?
> Something similar for NM? It's starting to get ugly and perhaps the
> effort spent doing that would be better put towards:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=73325#c5
>
> But either way, it does seem a pretty serious regression. Although
> maybe you and me, David, are the only F20 users using HSP bluetooth
> headsets. :-/
Out of curiosity, what do people use Blueman for?
I used it in far earlier versions of Fedora, because gnome-bluetooth was
just lacking basic features. I used it to setup GPRS/3G connections
using PAN and not rfcomm (as that was the only thing working with my
cell phones at that time), browsing files via OBEX over bluetooth ....
plus it gave more informative information on signal strengths of
connected devices - useful for some debugging.
But as GNOME got far better Bluetooth support (F14 and F19 were quite
good, even though file browsing seemed somewhat cripled in F19), I used
what was there instead of using blueman additionally.
I actually think Cinnamon used blueman in F19 for Bluetooth management,
iirc.
--
kind regards,
David Sommerseth
3:56 p.m.
On Thu, 2014-01-23 at 19:53 +0100, David Sommerseth wrote:
Hi all,
Hi,
This might be a viewed as a fire torch, but there is, IMO, a major
regression in BlueZ 5 which is shipped in Fedora 20.
I agree. But everyone probably already knows that.
It doesn't support
HSP/HFP headset profiles, which enables the microphone on many bluetooth
headsets.
Indeed -- which is a showstopper for anyone that uses a bluetooth
headset as their primary means of VOX communications.
Anyhow, not supporting HSP/HSP profiles is at least hitting my work
ability, and I doubt I'm alone in this situation.
No, you are definitely not alone. I abandoned F20 because of it.
Now, if I had known this before I started upgrading to F20, I
wouldn't
have upgraded yet but stayed on F19 a bit longer.
This is a perfect example of why I always (LVM) snapshot my existing
(F19 at the time) OS before I start an upgrade. Rolling back is really
as simple as updating the /etc/fstab on the snapshot-/ and creating a
grub entry to boot from the snapshot-/. I've had to roll back to F19 on
both my corporate laptop due to this particular issue and my personal
workstation due to other issues, so I am very grateful for my
cautiousness.
So, I wonder if it can be considered to enable a "downgrade
path" for
bluez and depending packages, as described in the "Contingency Plan":
<https://fedoraproject.org/wiki/Changes/Bluez5>
As I understand it's really not quite that simple. The problem is that
the GNOME that's in F20 depends on Bluez5 and won't work with Bluez4 so
downgrading Bluez to 4 also means downgrading GNOME. IIRC there was a
third dependency in all of that but I forget what it is.
As a side note, it also needs to be discussed how such a key feature
of
the bluetooth stack could go unnoticed through QA, and how to avoid this
from happening again.
Indeed. I wondered the same myself.
Cheers,
b.
4:16 p.m.
On Jan 23, 2014, at 2:56 PM, "Brian J. Murrell" <brian(a)interlinx.bc.ca>
wrote:
On Thu, 2014-01-23 at 19:53 +0100, David Sommerseth wrote:
> As a side note, it also needs to be discussed how such a key feature of
> the bluetooth stack could go unnoticed through QA, and how to avoid this
> from happening again.
Indeed. I wondered the same myself.
As far as I know there isn't an explicit test case or release criteria that covers
this functionality, or it would have been discovered. Why it's not a test case is a
valid question, but simply put there are only so many QA people, much of it is voluntary
so not everything important gets tested.
Seemingly critical features that shouldn't have major regressions are exactly where
testing should be done in advance of release. People who care about such functionality
need to alpha and beta test, and review feature proposals that affect things they care
about. You don't have to test for a week or month or the whole cycle. But had there
been more discovery, and criticism of the loss of features at the right time, then it
seems plausible the change would have been pushed back to F21.
https://fedoraproject.org/wiki/Changes/Bluez5
"Major functionality should keep working without regressions, compared to BlueZ 4 in
Fedora 19."
And…
"If the release blocking desktops have major bluetooth related regressions by the
time of the Fedora 20 Beta Change Deadline, then FESCo and the proposal owners may enact a
contingency plan to revert the BlueZ 5 related changes and go back to BlueZ 4."
This thread is suggesting a major regression, and if that's the case then the
contingency should have been employed. But the first red flag for that should have been at
the latest prior to beta freeze.
Chris Murphy
5:47 a.m.
On 23/01/14 23:16, Chris Murphy wrote:
On Jan 23, 2014, at 2:56 PM, "Brian J. Murrell"
<brian(a)interlinx.bc.ca> wrote:
> On Thu, 2014-01-23 at 19:53 +0100, David Sommerseth wrote:
>
>> As a side note, it also needs to be discussed how such a key feature of
>> the bluetooth stack could go unnoticed through QA, and how to avoid this
>> from happening again.
>
> Indeed. I wondered the same myself.
As far as I know there isn't an explicit test case or release
criteria that covers this functionality, or it would have been discovered. Why
it's not a test case is a valid question, but simply put there are only
so many QA people, much of it is voluntary so not everything important
gets tested.
Fair enough. However, in this case it seems this was even noticed. Why
that was never looked into more thoroughly is a mystery for me.
By all means, software does and needs to evolve, and it can break. I
have full understanding for this. But not alerting that basic
functionality of things you would expect breaks, that's the key point
here. That puts users into a difficult situation, especially when the
dependencies are so tricky.
Seemingly critical features that shouldn't have major
regressions
are exactly where testing should be done in advance of release. People who
care about such functionality need to alpha and beta test, and review
feature proposals that affect things they care about. You don't have to
test for a week or month or the whole cycle. But had there been more
discovery, and criticism of the loss of features at the right time, then
it seems plausible the change would have been pushed back to F21.
https://fedoraproject.org/wiki/Changes/Bluez5
I'll admit I noticed the Bluez5 threads on this list, and thought this
was fairly straight forward. Packages needed to be adopted to a new API
is kind of normal. And I took it for granted that the HSP/HFP
functionality would be tested. I cannot understand this functionality
is not considered an important feature. I mean, does people only use
bluetooth for the A2DP profile?
"Major functionality should keep working without regressions,
compared to BlueZ 4 in Fedora 19."
And…
"If the release blocking desktops have major bluetooth related
regressions by the time of the Fedora 20 Beta Change Deadline, then
FESCo and the proposal owners may enact a contingency plan to revert the
BlueZ 5 related changes and go back to BlueZ 4."
This thread is suggesting a major regression, and if that's the case
then the contingency should have been employed. But the first red flag
for that should have been at the latest prior to beta freeze.
During the F20 beta, I was soaked into other work to be able to test
this. But knowing we have a Fedora QA group and a plan for rolling
things back, I had a trust that the Fedora community wouldn't allow this
to happen.
But trust me, I will check things far more closely in the coming
releases ... unless I simply switch to RHEL instead to have some better
predictability.
--
kind regards,
David Sommerseth
10:51 a.m.
On Jan 24, 2014, at 4:47 AM, David Sommerseth <davids(a)redhat.com> wrote:
On 23/01/14 23:16, Chris Murphy wrote:
>
> As far as I know there isn't an explicit test case or release
> criteria that covers this functionality, or it would have been discovered. Why
> it's not a test case is a valid question, but simply put there are only
> so many QA people, much of it is voluntary so not everything important
> gets tested.
Fair enough. However, in this case it seems this was even noticed. Why
that was never looked into more thoroughly is a mystery for me.
QA volunteers don't get assignments. Most work and reports are on what's
personally important or interesting to them.
If XYZ breakage isn't in the matrix or test cases, then it must be personally
important to someone and they have to rock the boat somehow. And because testing weeks
prior to alpha, or beta, let alone final, already involve a ship at high seas…
By all means, software does and needs to evolve, and it can break.
I
have full understanding for this. But not alerting that basic
functionality of things you would expect breaks, that's the key point
here. That puts users into a difficult situation, especially when the
dependencies are so tricky.
First, I refuse the premise that it's QA's job to audit every feature or change,
to determine whether its contingency plan needs to be activated. That would be nice if it
had the resources to do that. QA is well over its eyeballs with the test matrices and test
cases it has.
But the feature page explicitly said no major regressions. So either the feature owner
disagrees with the assessment in this thread that the breakage is a major regression; or
major breakage occurred and even slipped by the feature owner. So? I'm not sure how
you expect this to work better.
One of QA ideas is actually expanding the test matrix, and prioritizing it. I'd guess
that a set of blue tooth tests could be written up (hopefully you'd volunteer to do
this since it seems important enough to you), and put into the "bonus" matrix.
That means, if not tested, it's not release blocking, but at least people can more
visibly see what QA has/hasn't tested. If QA can even get more one off involvement
from volunteers who otherwise don't participate that much, it's still very
helpful.
During the F20 beta, I was soaked into other work to be able to test
this. But knowing we have a Fedora QA group and a plan for rolling
things back, I had a trust that the Fedora community wouldn't allow this
to happen.
In my estimation, you significantly overestimate QA's scope and resources. And that is
an understatement. And I think this misunderstanding in the Fedora community is
widespread. QA maybe needs to do a recruitment drive or bake sale or something.
There are likely quite a number of "basic" things that aren't being touched
by QA first. QA is a community task. If you think it's important, you need to test it
and report on it and waive your hands if you even remotely think a feature contingency
plan should be activated. Otherwise, the result is exactly what has happened here.
But trust me, I will check things far more closely in the coming
releases ... unless I simply switch to RHEL instead to have some better
predictability.
Very, very different contexts. Fedora is made to be worked on. RHEL is made to work.
Chris Murphy
11:03 a.m.
On Fri, Jan 24, 2014 at 5:51 PM, Chris Murphy <lists(a)colorremedies.com>wrote:
On Jan 24, 2014, at 4:47 AM, David Sommerseth
<davids(a)redhat.com> wrote:
> On 23/01/14 23:16, Chris Murphy wrote:> By all means, software does and
needs to evolve, and it can break. I
> have full understanding for this. But not alerting that basic
> functionality of things you would expect breaks, that's the key point
> here. That puts users into a difficult situation, especially when the
> dependencies are so tricky.
<snip>
But the feature page explicitly said no major regressions. So either
the
feature owner disagrees with the assessment in this thread that the
breakage is a major regression; or major breakage occurred and even slipped
by the feature owner. So? I'm not sure how you expect this to work better.
Yeah. Looking back,
https://fedoraproject.org/wiki/Changes/Bluez5explicitly says "User
experience should change minimally.", while
http://www.bluez.org/release-of-bluez-5-0/ explicitly includes "Remove
internal support for telephony (HFP and HSP) profiles." It's not obvious
to me how the two are consistent
Generally FESCo trusts the Change owners to provide accurate information,
and we'd rather keep trusting everyone rather than second-guessing every
word.
Mirek
5:16 p.m.
On Thu, 2014-01-23 at 16:56 -0500, Brian J. Murrell wrote:
> As a side note, it also needs to be discussed how such a key
feature of
> the bluetooth stack could go unnoticed through QA, and how to avoid this
> from happening again.
Indeed. I wondered the same myself.
I'm somewhat cheered that our product has apparently reached the quality
level where people consider a Bluetooth audio profile to be a 'key
feature', but so far as our QA standards are concerned, it ain't.
This didn't really 'pass unnoticed' through QA. I noticed it, and was
supremely unconcerned. Yes, if you depend on this specific feature it
sucks, but it's hardly unusual for some specific feature of something or
other to break between Fedora releases. It's a thing that happens, and
as I'm on record as arguing in more extensive and generic terms, the
nature of Fedora as a project would need to change quite a lot before we
decided we were a project where stuff like this didn't sometimes break.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:31 a.m.
----- Original Message -----
On Thu, 2014-01-23 at 16:56 -0500, Brian J. Murrell wrote:
> > As a side note, it also needs to be discussed how such a key feature of
> > the bluetooth stack could go unnoticed through QA, and how to avoid this
> > from happening again.
>
> Indeed. I wondered the same myself.
I'm somewhat cheered that our product has apparently reached the quality
level where people consider a Bluetooth audio profile to be a 'key
feature', but so far as our QA standards are concerned, it ain't.
Somewhat. My experience for the past couple of years has been that I didn't
monitor bluez closely for one release, and then got nastygrams 3 months after
release that a major Bluetooth functionality broke (pairing, obex sending or
receiving of files, HID devices not connecting, etc.).
This was compounded by the fact that there hasn't been a Bluetooth kernel
maintainer in Red Hat for a number of years. Customers of RHEL and users of Fedora
expect Bluetooth to work out of the box, and never regress, but there's
close to zero investment in making sure it doesn't regress or adding the
necessary features (cf. ObexFTP client support, abandoned for the past 3 years).
TLDR; lack of investment in Bluetooth leads to regressions (within the community or Red
Hat)
This didn't really 'pass unnoticed' through QA. I noticed
it, and was
supremely unconcerned. Yes, if you depend on this specific feature it
sucks, but it's hardly unusual for some specific feature of something or
other to break between Fedora releases. It's a thing that happens, and
as I'm on record as arguing in more extensive and generic terms, the
nature of Fedora as a project would need to change quite a lot before we
decided we were a project where stuff like this didn't sometimes break.
FWIW, the HFP/HSP support is missing in PulseAudio, not in BlueZ for F20.
Cheers
/Bastien Nocera - windmill tilter
7:05 a.m.
On 24/01/14 08:31, Bastien Nocera wrote:
FWIW, the HFP/HSP support is missing in PulseAudio, not in BlueZ for F20.
Can you please shed some more light on this. From what I could grasp
out of the freedesktop bug, it was a bluez bug. And PulseAudio says
bluez4 is needed to get the handsfree profile working.
Anyhow, I'm past this discussion and have started to figure out how to
recompile the needed packages. So anything which can simplify this job
is appreciated.
--
kind regards,
David Sommerseth
12:08 p.m.
Il 24/01/2014 14:05, David Sommerseth ha scritto:
> > FWIW, the HFP/HSP support is missing in PulseAudio, not in
BlueZ for F20.
Can you please shed some more light on this. From what I could grasp
out of the freedesktop bug, it was a bluez bug. And PulseAudio says
bluez4 is needed to get the handsfree profile working.
From the BlueZ 5.0 release notes:
"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 (e.g. oFono which already supports this)"
For Fedora this means PulseAudio.
Paolo
10:24 a.m.
Paolo Bonzini wrote:
From the BlueZ 5.0 release notes:
"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 (e.g. oFono which already supports this)"
For Fedora this means PulseAudio.
This is a recurring problem in Fedora: Developers of software X think that
feature Z is better done in software Y and happily remove Z from X, often
without even talking to the developers of Y, and always without waiting for
Y to actually implement the feature. In some cases, it is not even clear
whether Z can be implemented properly (i.e., to the extent it was in X) in
Y, I don't know whether that's the case here or whether it's just a matter
of time.
Features MUST NOT get removed without a working replacement!
Kevin Kofler
1:04 p.m.
On Sat, 2014-01-25 at 17:24 +0100, Kevin Kofler wrote:
Paolo Bonzini wrote:
> From the BlueZ 5.0 release notes:
>
> "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 (e.g. oFono which already supports this)"
>
> For Fedora this means PulseAudio.
This is a recurring problem in Fedora: Developers of software X think that
feature Z is better done in software Y and happily remove Z from X, often
without even talking to the developers of Y, and always without waiting for
Y to actually implement the feature. In some cases, it is not even clear
whether Z can be implemented properly (i.e., to the extent it was in X) in
Y, I don't know whether that's the case here or whether it's just a matter
of time.
Features MUST NOT get removed without a working replacement!
Unfortunately, it's upstream Bluez that removed/changed these features
for version 5. And the upstream Bluez developers stopped working on
Bluez4 in mid-2012. So staying with Bluez4 would have meant using a
very, very out-of-date Bluez that Fedora developers would have to
maintain, since upstream clearly wasn't interested.
Dan
6:20 a.m.
On Fri, Jan 24, 2014 at 12:16 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Thu, 2014-01-23 at 16:56 -0500, Brian J. Murrell wrote:
> > As a side note, it also needs to be discussed how such a key feature of
> > the bluetooth stack could go unnoticed through QA, and how to avoid this
> > from happening again.
>
> Indeed. I wondered the same myself.
I'm somewhat cheered that our product has apparently reached the quality
level where people consider a Bluetooth audio profile to be a 'key
feature', but so far as our QA standards are concerned, it ain't.
This didn't really 'pass unnoticed' through QA. I noticed it, and was
supremely unconcerned.
We should stop this "its crap anyway" attitude. That's the reason why
people perceive fedora
as beta / unstable / breaks often etc.
Did you at least file a bug?
1:37 a.m.
drago01 <drago01(a)gmail.com> wrote:
On Fri, Jan 24, 2014 at 12:16 AM, Adam Williamson
<awilliam(a)redhat.com>
wrote:
> On Thu, 2014-01-23 at 16:56 -0500, Brian J. Murrell wrote:
>
>> > As a side note, it also needs to be discussed how such a key
feature of
>> > the bluetooth stack could go unnoticed through QA, and how to
avoid this
>> > from happening again.
>>
>> Indeed. I wondered the same myself.
>
> I'm somewhat cheered that our product has apparently reached the
quality
> level where people consider a Bluetooth audio profile to be a 'key
> feature', but so far as our QA standards are concerned, it ain't.
>
> This didn't really 'pass unnoticed' through QA. I noticed it, and was
> supremely unconcerned.
We should stop this "its crap anyway" attitude. That's the reason why
people perceive fedora
as beta / unstable / breaks often etc.
Did you at least file a bug?
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
It's not about "it's crap anyway", it's about our trade off between
completeness and getting new stuff done. Fedora has *always* accepted
major changes before they reach full feature parity with the thing
they're replacing, and I don't see any indication anyone's expecting
that to change.
Having said that I may have to go back and check things, because my
memory is that this is something everyone involved (including the devs
and fesco) knew about at the time, but it's being discussed as if it
were a big surprise.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:33 p.m.
David Sommerseth wrote:
So, I wonder if it can be considered to enable a "downgrade
path" for
bluez and depending packages, as described in the "Contingency Plan":
<https://fedoraproject.org/wiki/Changes/Bluez5>
Officially downgrading BlueZ from 5 to 4 in a shipped release is totally
impractical. It just cannot be done realistically. (Contingency plans are
only intended to be enacted BEFORE the release.)
You may be able to get it downgraded on your machine in a hackish way, but
we cannot really support that.
Sorry,
Kevin Kofler
8:35 p.m.
On Thu, Jan 23, 2014 at 7:33 PM, Kevin Kofler wrote:
David Sommerseth wrote:
> So, I wonder if it can be considered to enable a "downgrade path" for
> bluez and depending packages, as described in the "Contingency Plan":
> <https://fedoraproject.org/wiki/Changes/Bluez5>
Officially downgrading BlueZ from 5 to 4 in a shipped release is totally
impractical. It just cannot be done realistically. (Contingency plans are
only intended to be enacted BEFORE the release.)
Right. But is it possible to ship a bluez4 package and rebuild the
dependencies against that after the release?
Orcan
8:41 p.m.
On Thu, 2014-01-23 at 21:35 -0500, Orcan Ogetbil wrote:
On Thu, Jan 23, 2014 at 7:33 PM, Kevin Kofler wrote:
> David Sommerseth wrote:
>> So, I wonder if it can be considered to enable a "downgrade path" for
>> bluez and depending packages, as described in the "Contingency Plan":
>> <https://fedoraproject.org/wiki/Changes/Bluez5>
>
> Officially downgrading BlueZ from 5 to 4 in a shipped release is totally
> impractical. It just cannot be done realistically. (Contingency plans are
> only intended to be enacted BEFORE the release.)
Right. But is it possible to ship a bluez4 package and rebuild the
dependencies against that after the release?
How does that differ, in practice?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8:53 p.m.
On Thu, Jan 23, 2014 at 9:41 PM, Adam Williamson wrote:
On Thu, 2014-01-23 at 21:35 -0500, Orcan Ogetbil wrote:
>
> Right. But is it possible to ship a bluez4 package and rebuild the
> dependencies against that after the release?
How does that differ, in practice?
Potentially,
- No epoch bump.
- Packages which really need bluez-5, can continue to use it
- No rebuild needed for packages which do not rely on the missing functionality
That said, I am not sure which of the above would apply to the current
situation. That's why I asked.
Best,
Orcan
4:43 a.m.
On 01/24/2014 03:41 AM, Adam Williamson wrote:
On Thu, 2014-01-23 at 21:35 -0500, Orcan Ogetbil wrote:
> On Thu, Jan 23, 2014 at 7:33 PM, Kevin Kofler wrote:
>> David Sommerseth wrote:
>>> So, I wonder if it can be considered to enable a "downgrade path"
for
>>> bluez and depending packages, as described in the "Contingency
Plan":
>>> <https://fedoraproject.org/wiki/Changes/Bluez5>
>>
>> Officially downgrading BlueZ from 5 to 4 in a shipped release is totally
>> impractical. It just cannot be done realistically. (Contingency plans are
>> only intended to be enacted BEFORE the release.)
>
> Right. But is it possible to ship a bluez4 package and rebuild the
> dependencies against that after the release?
How does that differ, in practice?
Think about compat packages and parallel installation.
Ralf
6:32 a.m.
Orcan Ogetbil wrote:
Right. But is it possible to ship a bluez4 package and rebuild the
dependencies against that after the release?
No, because the maintainers said the 2 versions are not parallel-
installable. (The original plan was to make the packages Conflict, which is
why we ended up with getting everything ported to BlueZ 5 instead, to avoid
having desktop environments being mutually exclusive.)
Kevin Kofler
10:40 a.m.
On Fri, Jan 24, 2014 at 01:33:07AM +0100, Kevin Kofler wrote:
David Sommerseth wrote:
> So, I wonder if it can be considered to enable a "downgrade path" for
> bluez and depending packages, as described in the "Contingency Plan":
> <https://fedoraproject.org/wiki/Changes/Bluez5>
Officially downgrading BlueZ from 5 to 4 in a shipped release is totally
impractical. It just cannot be done realistically. (Contingency plans are
only intended to be enacted BEFORE the release.)
I think we need to to upgrade PulseAudio to 5.0. That version, with
bluetooth audio A2DP support, is currently at ”Release Candidate” stage:
http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-January/019...
Such upgrade in stable release need to be done carefuly with above-standard
amount of testing. But I think it's the only viable way.
Additionaly, F20 is going to be our longer supported release. Thanks to
fedora.next movement, we won't have F21 in usual time, but much, much later.
This means we need to treat F20 bugs with more care, as there won't be
fixed release in 6 months.
--
Tomasz Torcz There exists no separation between gods and men:
xmpp: zdzichubg(a)chrome.pl one blends softly casual into the other.
10:43 a.m.
Am 25.01.2014 17:40, schrieb Tomasz Torcz:
On Fri, Jan 24, 2014 at 01:33:07AM +0100, Kevin Kofler wrote:
> David Sommerseth wrote:
>> So, I wonder if it can be considered to enable a "downgrade path" for
>> bluez and depending packages, as described in the "Contingency Plan":
>> <https://fedoraproject.org/wiki/Changes/Bluez5>
>
> Officially downgrading BlueZ from 5 to 4 in a shipped release is totally
> impractical. It just cannot be done realistically. (Contingency plans are
> only intended to be enacted BEFORE the release.)
I think we need to to upgrade PulseAudio to 5.0. That version, with
bluetooth audio A2DP support, is currently at ”Release Candidate” stage:
http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-January/019...
Such upgrade in stable release need to be done carefuly with above-standard
amount of testing. But I think it's the only viable way
my expierience with pulseaudio-upgrades is good
Rex Dieter had PA 4.0 in a un-official repo months before it arrived
in Fedora and there was no regression using that repo on current Fedora
what about a scratch-build announced on @devel and @users to get active testers?
11:12 p.m.
On Sat, Jan 25, 2014 at 4:40 PM, Tomasz Torcz <tomek(a)pipebreaker.pl> wrote:
On Fri, Jan 24, 2014 at 01:33:07AM +0100, Kevin Kofler wrote:
> David Sommerseth wrote:
> > So, I wonder if it can be considered to enable a "downgrade path" for
> > bluez and depending packages, as described in the "Contingency Plan":
> > <https://fedoraproject.org/wiki/Changes/Bluez5>
>
> Officially downgrading BlueZ from 5 to 4 in a shipped release is totally
> impractical. It just cannot be done realistically. (Contingency plans are
> only intended to be enacted BEFORE the release.)
>
I think we need to to upgrade PulseAudio to 5.0. That version, with
bluetooth audio A2DP support, is currently at ”Release Candidate” stage:
http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-January/019...
Such upgrade in stable release need to be done carefuly with above-standard
amount of testing. But I think it's the only viable way.
Additionaly, F20 is going to be our longer supported release. Thanks to
fedora.next movement, we won't have F21 in usual time, but much, much later.
This means we need to treat F20 bugs with more care, as there won't be
fixed release in 6 months.
The first RC is already in rawhide and in F-20 we've had git snapshots
in F-20 for some time. I'm sure once it's proven stable in rawhide it
will come to F-20 but it would likely do good to test it to ensure it
fixes the problem.
Peter
5:41 a.m.
On Sat, Jan 25, 2014 at 05:40:22PM +0100, Tomasz Torcz wrote:
On Fri, Jan 24, 2014 at 01:33:07AM +0100, Kevin Kofler wrote:
> David Sommerseth wrote:
> > So, I wonder if it can be considered to enable a "downgrade path"
for
> > bluez and depending packages, as described in the "Contingency
Plan":
> > <https://fedoraproject.org/wiki/Changes/Bluez5>
>
> Officially downgrading BlueZ from 5 to 4 in a shipped release is totally
> impractical. It just cannot be done realistically. (Contingency plans are
> only intended to be enacted BEFORE the release.)
>
I think we need to to upgrade PulseAudio to 5.0. That version, with
bluetooth audio A2DP support, is currently at ”Release Candidate” stage:
http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-January/019...
After reading more into it… I was mistaken. A2DP is not two-way bluetooth
audio. PA 5 won't fix the headset issue:
#v+
PulseAudio now supports BlueZ 5, but only the A2DP profile.
BlueZ 4 is still the only way to make HSP/HFP work.
#v-
--
Tomasz Torcz There exists no separation between gods and men:
xmpp: zdzichubg(a)chrome.pl one blends softly casual into the other.
3741
days inactive
3745
days old
36 comments
17 participants
participants (17)
-
Adam Williamson -
Bastien Nocera -
Brian J. Murrell -
Chris Murphy -
Colin Macdonald -
Dan Williams -
David Sommerseth -
drago01 -
Frank Murphy -
Kevin Kofler -
Miloslav Trmač -
Orcan Ogetbil -
Paolo Bonzini -
Peter Robinson -
Ralf Corsepius -
Reindl Harald -
Tomasz Torcz