On Fre, 2013-08-16 at 11:28 -0400, Matthias Clasen wrote: > >> 701078 Port NM to BlueZ 5 > > > > > > IMHO, this is very late to happen 'just before RC' (3.9.90 is on Aug 20) > > with a full ABI/API freeze. > > This did not appear 'just before RC - it has been the plan for a > while. This bug is just on the blocker list because the NM changes > haven't landed yet.
The idea maybe not.. but the code; so far, no distro targetting GNOME 3.10 for their upcoming release (Fedora & openSUSE both in November), could switch to BlueZ5, because the entire rest of the eco system uses BlueZ 4. So nobody had a real chance yet to actually work towards integrating this all. And dists also enter freeze periods (likely even a bit longer than GNOME itself) > > And I don't think NM is even the only piece in the GNOME stack affected; > > from a quick glance, I can see at least also: > > * GVFS (backend; can probably be disabled). > > I don't know the current state for gvfs, but yes, that can be disabled. BT can be disabled in all areas... in some it might hurt more or less of course. > > * gnokii (seems those Nokia phones just don't die!) > > * gnome-phone-manager (mostly obsolete I guess). > > These are not part of our modulesets, so we can't really let them > block progress. Of course; and those two I probably won't even mind just dropping if the porting efforts don't way in. > > > And stuff outside of the reach of GNOME: > > * PulseAudio (has a bluetooth module) > > Pulseaudio has support for Bluez5 in git master; we're hoping to get a > release in time for 3.10. There are some regressions there. > 'hope' sounds promising. The regressions a bit less. > > * qemu (bring BT support to VMs) > > I don't know anything about bluetooth in qemu. What would that be good for ? you can pass through your BT to a OS running inside qemu. Mostly useful for 'proprietary software on proprietary OSes where free alternatives don't cut it yet'; I'd seen people doing it, but can't answer on the real life impact if they can no longer do it. > > This all would be no issue if the variants could co-exist of course :( > > Indeed. But thats a complaint to direct at the upstream bluez > maintainers. We're trying to do the best we can, under the > circumstances. Of course.. so am I, but from a distributions point of view; I can either disable BT in everything but gnome (or hope i can find patches to port stuff over, with a short time frame until a release, with limited testing time) or disable BT in gnome.. both scenarios not exactly what I'd want to do; Don't mis-understand: I don't mind breaking stuff here and there, but we should try to merge 'breaking stuff' early in the cycles so that whoever imports code from us has some reasonable time catching up. Just my thoughts... of course the final solution will have to be worked out by the distributions, not by GNOME itself; I'm merely asking for consideration of the downstreams. I will of course do my best to get this sorted in openSUSE. Thanks for the great work! Dominique -- Dimstar / Dominique Leuenberger <[email protected]> _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
