Summary: | gnome-base/gvfs-1.0.3 with bluez-4 support | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Norman Jonas <bugs.gentoo.org_4> |
Component: | New packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ikelos, jklawiter, Manfred.Knick, manschwetus, renatogallo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://bugzilla.gnome.org/show_bug.cgi?id=552356 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 250909 | ||
Attachments: |
gvfs-1.0.3.ebuild
gvfs-obexftp-updated-apis-2.patch |
Description
Norman Jonas
2008-12-11 13:29:50 UTC
Created attachment 174954 [details]
gvfs-1.0.3.ebuild
Created attachment 174955 [details]
gvfs-obexftp-updated-apis-2.patch
This ebuild only supports net-wireless/bluez - the in tree ebuild would need a more elaborate work to support bluez-3 as well. link to an upstream bug ? This won't be included if it doesn't provide backwards compatibility with at least bluez-libs-3. At worst we need to just conditional patch if preserved-libs or revdep-rebuild is going to help users out once they migrate to bluez-4. We need to move to bluez-4 ASAP imho (I admit that I had personal pain with bluez-3 and getting a bluetooth mouse to work). A patch that would be compatible with either without conditional epatching would be nicer of course (In reply to comment #4) > link to an upstream bug ? This won't be included if it doesn't provide > backwards compatibility with at least bluez-libs-3. Try 552356. There is no backwards compatibility there either. I don't think we should wait for supporting bluez-4 until GNOME-2.26, even if we would have to conditional patch. Another option is to have two revisions, one going for bluez-3, another for bluez-4. Latter patches, former not. Then there's the additional work of keeping those in sync with bluez(-libs) package visibility To not give any implicit impressions -- I have not compared the attached patch with what ended up in upstream SVN, nor tested it, nor vetted this. These would have to still be verified from our side (dev-zero has done some testing too). I personally currently don't have any easy access to any bluetooth devices that would have file storage (obex-ftp) - just a mouse and a headset. The source of the patch is http://cvs.fedoraproject.org/viewvc/devel/gvfs/gvfs-obexftp-updated-apis-2.patch?view=markup. Well, as to the testing part, the fedora patch (identical to this bug's attached one) seems to work fine. Unfortunately, bluez seem to have decided to release obexd, which uses the same D-Bus service name as this (and obexd takes precedence if they're installed side by side), so I can see there being chaos up ahead, but for now (since obexd isn't in the tree), bluetooth-applet and all the gvfs-obexftp goodness seems to work fine. Things to note include: * Still no write support via GFS. * obex:/// doesn't list nearby bluetooth devices (not sure it ever did for gvfs), you'll have to use bluetooth-applet to do that added to the tree. Thanks for reporting and the patches. *** Bug 261964 has been marked as a duplicate of this bug. *** *** Bug 263447 has been marked as a duplicate of this bug. *** *** Bug 267575 has been marked as a duplicate of this bug. *** |