Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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/019858.html 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 TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On Sat, Jan 25, 2014 at 7:41 AM, Adam Williamson ad...@happyassassin.net wrote: drago01 drag...@gmail.com wrote: On Fri, Jan 24, 2014 at 12:16 AM, Adam Williamson awill...@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@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. There is a difference between a minor inconvenience (I have to do x, y and z instead of just a or have to use a different tool to do task x) and hardware that suddenly stops working after an upgrade. This thread is clearly an indicator that at least some people have different exceptions here. 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. OK. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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/019858.html 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 TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. pgpquRkGHmXRU.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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/019858.html 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? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On Sat, Jan 25, 2014 at 4:40 PM, Tomasz Torcz to...@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/019858.html 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
- Original Message - snip I actually think Cinnamon used blueman in F19 for Bluetooth management, iirc. Nope. Which is why it broke when I bumped the soname of the gnome-bluetooth libraries. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On 23/01/14 23:16, Chris Murphy wrote: On Jan 23, 2014, at 2:56 PM, Brian J. Murrell br...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On Jan 24, 2014, at 4:47 AM, David Sommerseth dav...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On Fri, Jan 24, 2014 at 5:51 PM, Chris Murphy li...@colorremedies.comwrote: On Jan 24, 2014, at 4:47 AM, David Sommerseth dav...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
drago01 drag...@gmail.com wrote: On Fri, Jan 24, 2014 at 12:16 AM, Adam Williamson awill...@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@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On Thu, 23 Jan 2014 19:53:19 +0100 David Sommerseth dav...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On 23/01/14 19:58, Frank Murphy wrote: On Thu, 23 Jan 2014 19:53:19 +0100 David Sommerseth dav...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 dav...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 dav...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On Jan 23, 2014, at 2:56 PM, Brian J. Murrell br...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
- 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
