Bug 489564

Summary: Review Request: Blueman - Bluetooth Manager
Product: [Fedora] Fedora Reporter: Juan Manuel Rodriguez <nushio>
Component: Package ReviewAssignee: Wolfgang Ulbrich <chat-to-me>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: arambuladuransergio, atigro, axet, chat-to-me, chkr, dgilmore, dwmw2, fedora, fedora-package-review, grinnz, kevin, krnlbg, leigh123linux, leon, lkundrak, massi.ergosum, mi, neteler, notting, nushio, rajeeshknambiar, req1348, ricardo.arguello, walmis
Target Milestone: ---Keywords: Reopened
Target Release: ---Flags: chat-to-me: fedora‑review+
limburgher: fedora‑cvs+
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.10-3.fc11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-19 06:32:57 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 496433    
Attachments:
Description Flags
specfile which fixes the compilation problems none

Description Juan Manuel Rodriguez 2009-03-10 13:55:09 EDT
Spec URL: http://proyectofedora.org/mexico/wp-content/uploads/2009/03/blueman.spec
SRPM URL: http://proyectofedora.org/mexico/wp-content/uploads/2009/03/blueman-102-1fmexsrc.rpm
Description: Blueman is designed to provide simple, yet effective means for controlling 
BlueZ API and simplifying bluetooth tasks such as:
 * Connecting to 3G/EDGE/GPRS via dial-up
 * Connecting to/Creating bluetooth networks
 * Connecting to input devices
 * Connecting to audio devices
 * Sending/Receiving/Browsing files via OBEX
 * Pairing
Blueman also integrates with Network Manager 0.7, so any Dialup/Network 
connections will be made available (via HAL) to Network Manager.
Comment 1 Juan Manuel Rodriguez 2009-03-10 13:58:54 EDT
This is the second RPM I make (First was Blueman 1.01). 

I'm still trying to learn a lot about making packages, and I'd love to get Blueman into Fedora's repositories. 

Rajeesh also made a similar specfile (this one has one tiny error, missed a file). Here's his Spec: http://rajeeshknambiar.fedorapeople.org/blueman.spec (add %{_datadir}/hal/fdi/information/20thirdparty/11-blueman-bnep.fdi to the files list)

I understand I have much to learn, but I'd love to learn and help out.
Comment 2 David Woodhouse 2009-03-11 11:30:31 EDT
Missing BuildRequires: Pyrex
Comment 3 Juan Manuel Rodriguez 2009-03-11 11:38:23 EDT
Updated Spec file:
http://proyectofedora.org/mexico/wp-content/uploads/2009/03/blueman.spec

Now includes all BuildRequires and Requires. 
Changed tag to dist tag.
Comment 4 Christian Krause 2009-03-11 16:26:15 EDT
Hi Juan,

I've done a rough review of your Review Request and there are a couple items which needs to be addressed.

1. Since you're seeking sponsorship for the Packagers Group, please make your Review Request block the FE-NEEDSPONSOR bug (see http://fedoraproject.org/wiki/PackageMaintainers/Join for details)

2. The Source0: field refers to the subversion repository. If there is no upstream tarball it is necessary to provide some information how the tarball gets generated. For details please see here: http://fedoraproject.org/wiki/Packaging/SourceURL . However, it this case it looks like that upstream provides a tarball, so please refer to this location in Source0:
http://download.tuxfamily.org/blueman/blueman-1.02.tar.gz

You can test whether you've used the correct URL by running
spectool -g SPECS/blueman.spec
it should download the correct source file.

3. The package doesn't build cleanly in mock since not all build requirements are listed. Please setup mock locally - it is a big help to find missing build requirements. ;)
For details please check the following wiki site: http://fedoraproject.org/wiki/Extras/MockTricks

4. rpmlint is quite chatty about the spec file and the rpm files:

rpmlint SPECS/blueman.spec RPMS/i386/blueman-1.02-2.fc10.i386.rpm RPMS/i386/blueman-debuginfo-1.02-2.fc10.i386.rpm SRPMS/blueman-1.02-2.fc10.src.rpm
blueman.i386: E: zero-length /usr/share/doc/blueman-1.02/README
blueman.i386: W: non-conffile-in-etc /etc/xdg/autostart/blueman.desktop
blueman.i386: W: devel-file-in-non-devel-package /usr/lib/python2.5/site-packages/_blueman.a
blueman.i386: E: zero-length /usr/share/doc/blueman-1.02/NEWS
blueman.i386: W: non-conffile-in-etc /etc/dbus-1/system.d/org.blueman.Mechanism.conf
blueman.i386: W: invalid-license GPL v3
blueman-debuginfo.i386: W: invalid-license GPL v3
blueman.src: W: invalid-license GPL v3
3 packages and 1 specfiles checked; 2 errors, 6 warnings.

* zero-length files shouldn't be included

* please fix the license tag (see http://fedoraproject.org/wiki/Packaging/Guidelines#Licensing and the links there for details)

Using rpmlint helps to catch some well-known mistakes in spec files early. ;-)
http://fedoraproject.org/wiki/Packaging/Guidelines#Use_rpmlint

6. please don't package *.la files

7. *.a files should be omitted, too

8. to make the spec file more readable it is ok to use wildcards, e.g.:
%{_mandir}/man1/*
etc.

Please have a look at the mentioned items first and then I'll do a more detailed review. If you have any questions, don't hesitate to ask!

Best regards,
Christian
Comment 5 Juan Manuel Rodriguez 2009-03-12 03:31:51 EDT
Hi there, 

I updated the Specfile and generated a new SRPM. 
Spec URL:
http://proyectofedora.org/mexico/wp-content/uploads/2009/03/blueman.spec
SRPM URL:
http://proyectofedora.org/mexico/wp-content/uploads/2009/03/blueman-1.02-4.fc10.src.rpm

So far, I've got rpmlint to only complain about a .a file

devel-file-in-non-devel-package /usr/lib/python2.5/site-packages/_blueman.a

I've been trying to find on Google, but I haven't been able to filter that file, while keeping the * in the Python site-packages. 

Also, I haven't been able to build the package with mock, I'm still learning to see what I can find. 

Thanks for your time!
Comment 6 Christian Krause 2009-03-12 16:34:01 EDT
Hi,

thanks for the new package, I've looked at it and here are some more comments:

- it's good that you've corrected the URL for Source0

- however, the blueman-1.02.tar.gz which is included in your src.rpm does not match the file provided upstream:

md5sum blueman-1.02.tar.gz SOURCES/blueman-1.02.tar.gz
7f66f569a716f8c6fce9360176166eac  upstream/blueman-1.02.tar.gz
8e02d7d66b46a7c62b4396080aba0211  SOURCES/blueman-1.02.tar.gz

Please use exactly the upstream package. In general all modifications must be done using patches. (Sure, there are exceptions, e.g. if upstream contains material which Fedora may not distribute, but that's not the case here).

- rpmlint:
rpmlint SPECS/blueman.spec RPMS/i386/blueman-* SRPMS/blueman-1.02-4.fc10.src.rpm 
blueman.i386: W: devel-file-in-non-devel-package /usr/lib/python2.5/site-packages/_blueman.a
3 packages and 1 specfiles checked; 0 errors, 1 warnings.

Looks much better!

The remaining *.a file can be just deleted in the %install section with:
rm -f $RPM_BUILD_ROOT%{_libdir}/python*/site-packages/*.a .

- License: Just a minor issue: Since the source files states that the license is "gplv3 ... or any later version", please use GPLv3+ in the license tag. ;-)

- wildcard usage: Even this is not a realy mistake, in general please use also wildcards for the executables and the manuals: %{_bindir}/* and %{_mandir}/man1/*

- roughly check of the build requirements:
* please substitute gtk2 with gtk2-devel
* please add dbus-python-devel

- mock build problems:
I've played a little bit with mock and your package, and it looks like that there were just the mentioned build requires missing. It would be good if you could do the tests on your side, too. What are the issues you've seen so far? Probably I can help...


Regards,
Christian
Comment 7 Juan Manuel Rodriguez 2009-03-12 17:29:41 EDT
Hi Christian, thanks for your time!

The reason why the upstream tar package and the one I use are different is because Upstream won't compile on Fedora 10. There's a bug that prevents it from detecting PyGTK. Bug was fixed and will be part of 1.03, so hopefully, I won't need any patches for 1.03. 

Here's the bug url: https://bugs.edge.launchpad.net/blueman/+bug/337877
Here's the patch I used, from Rajeesh: http://rajeeshknambiar.fedorapeople.org/blueman-configure-rpmbuild.patch which he posted at his blog: http://rajeeshknambiar.wordpress.com/2009/03/10/blueman-build-issue/

I updated my specfile to reflect all your comments. I've compiled and installed Blueman and I never required dbus-python-devel, but I added it to the build reqs anyways. 

I updated the Spec file to the same url. 
Spec URL:
http://proyectofedora.org/mexico/wp-content/uploads/2009/03/blueman.spec
SRPM URL:
http://proyectofedora.org/mexico/wp-content/uploads/2009/03/blueman-1.02-5.fc10.src.rpm

I'll be running some mock tests. I hope to compile this for x86_64 and ppc soon. 

Thanks again for your advice!
Comment 8 Juan Manuel Rodriguez 2009-03-12 17:51:38 EDT
Latest SRPM (blueman-1.02-5.fc10.src.rpm) works with mock. Managed to compile the i386 version. Now testing x86_64. 

INFO: Done(SRPMS/blueman-1.02-5.fc10.src.rpm) Config(fedora-10-i386) 13 minutes 19 seconds
Comment 9 Christian Krause 2009-03-12 17:55:45 EDT
Hi,

(In reply to comment #7)
> The reason why the upstream tar package and the one I use are different is
> because Upstream won't compile on Fedora 10. There's a bug that prevents it
> from detecting PyGTK. Bug was fixed and will be part of 1.03, so hopefully, I
> won't need any patches for 1.03. 

Yeah, but the patch must not be manually added to the tarball. It is sufficient that it is delivered in the src.rpm. If you just copy the upstream tarball into SOURCES and rebuild the src.rpm file using the existing spec file, then everything is OK:

I've just checked, whether your patch and spec files works also with the upstream tarball - it does. ;-) :

- the package builds
- the patch is included (automatically) in the src.rpm
- the src.rpm includes the upstream tarball

> Blueman and I never required dbus-python-devel, but I added it to the build
> reqs anyways. 

The dbus-python-devel requirement was revealed by the mock build. ;-)

> I'll be running some mock tests. I hope to compile this for x86_64 and ppc
> soon. 

If you cannot build the package e.g. for a different architecture, you can use koji, fedora's build system - you'll find more information here:
http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji

You can use a command line like this to get e.g. a src.rpm built in koji:
koji build --scratch dist-f11 SRPMS/blueman-1.02-5.fc10.src.rpm

The output is then something like this:
https://koji.fedoraproject.org/koji/taskinfo?taskID=1238728

Regards,
Christian
Comment 10 Juan Manuel Rodriguez 2009-03-12 18:49:17 EDT
Hi, 

I changed my Tarball back to upstream. Made a new SRPM. Learned to use Koji, testing building everything for Fedora 11 and I'll test for F10 afterward. 

Here's the new packages:
Spec URL:
http://proyectofedora.org/mexico/wp-content/uploads/2009/03/blueman.spec
SRPM URL:
http://proyectofedora.org/mexico/wp-content/uploads/2009/03/blueman-1.02-6.fc10.src.rpm

On a personal note, I no longer consider building RPMs witchcraft.
Comment 11 Rajeesh 2009-03-14 00:19:18 EDT
A few comments:

I do not find dbus-python-devel a BuildRequires either. Anyway.

It is better to use the patch mentioned in upstream to fix the build issue, which is here: http://launchpadlibrarian.net/23437278/blueman-pytgtk-check.patch
Comment 12 Juan Manuel Rodriguez 2009-03-14 03:28:54 EDT
Rajeesh, 
I can't get it to compile using upstream patch, maybe I'm patching it wrong, so I used your patch instead. 

I still can't get it to compile on x86_64 using Mock.
Comment 13 Rajeesh 2009-03-14 06:06:23 EDT
Heck, have been trying to set up mock for past 2 hours with my slow internet connection.

Can you try this spec - http://rajeeshknambiar.fedorapeople.org/blueman.spec
with this patch - http://rajeeshknambiar.fedorapeople.org/blueman-build-pygtk.patch ?
Comment 14 Rajeesh 2009-03-14 10:41:52 EDT
Ah, after a round of wrestling with Mock, I sorted out all the BuildRequires correctly and builds fine for i386. SPEC in the same earlier location (version 1.02-3).

Can you guys try?

I couldn't do Mock build for x86_64, as mock fails with error on "groupinstall buildsys-build" but I think that's unrelated.
Comment 15 Christian Krause 2009-03-15 15:02:18 EDT
(In reply to comment #11)
> A few comments:
> 
> I do not find dbus-python-devel a BuildRequires either. Anyway.

Otherwise a mock build on x86 will fail with this error message:

checking for python module dbus... no
configure: error: Could not find Python module dbus
Comment 16 Christian Krause 2009-03-15 18:32:50 EDT
Hi,

Here is now a more detailed review of Juan's last package with the patch added by Rajeesh. We've already worked on this package for quite some time to make it fulfill the requirements, so I've used Juan's package as base.

I've investigated the build problem and it is caused by the following:
Python (similar to perl) uses two directories for vendor specific data:
- %{python_sitearch} (architecture specific, usually shared objects)
- %{python_sitelib} (architecture-independend *.py files)

Since both directories point to the same dir on x86 (/usr/lib/python2.5/site-packages) but differ on x86_64 systems (/usr/lib/python2.6/site-packages for noarch and /usr/lib64/python2.6/site-packages for arch-sepcific files).
This will cause problems if only %{python_sitearch} is used and so they must be used both - please see my spec file (attached to the bug) and
http://fedoraproject.org/wiki/Packaging/Python for details.

The spec file I've attached builds on all architectures in F11. It would be good to go further using this one. ;-)

https://koji.fedoraproject.org/koji/taskinfo?taskID=1242586

I've changed the build requirements so that it builds and I've changed the deletion of the *.la and *.a file. Just a hint: even in this case there was no harm, but if you know, that you only want to delete files with rm, please don't use the '-r' switch.

Here is a more detailed review (of Juan's package with Rajeesh's patch and my small modifications of the spec file - it is attached to this bug). Please note, that I cannot sponsor you, since I'm quite new here, too.

* rpmlint: OK
rpmlint SPECS/blueman.spec RPMS/i386/blueman-1.02-6.fc10.i386.rpm RPMS/i386/blueman-debuginfo-1.02-6.fc10.i386.rpm SRPMS/blueman-1.02-6.fc10.src.rpm
3 packages and 1 specfiles checked; 0 errors, 0 warnings.

* naming: OK

* spec file name matches %{name}: OK

* License: for the code it seems OK (GPL3 COPYING file, *.c files and a couple of python files refer to GPLv3+, no direct indication of a different license), but the svg icons are GPL2.0

* License packaged: OK

* Source0: OK (matches upstream, spectool -g works):
7f66f569a716f8c6fce9360176166eac  blueman-1.02.tar.gz

* package builds in F11 on all archs:
https://koji.fedoraproject.org/koji/taskinfo?taskID=1242586

* build requirements: OK

* locale handling: OK, %{find_lang} is used
* ldconfig: OK (n/a, since no libraries in linker's default paths)

* dir ownership: TODO
- since it places files into %{_datadir}/gnome/autostart the package should require gnome-session which owns this directory

- same applies to %{_datadir}/PolicyKit/policy/org.blueman.policy -> PolicyKit should be required

- the following two entries would cause that "/usr/share/blueman" would not have a proper owner:
%{_datadir}/%{name}/icons/hicolor/*
%{_datadir}/%{name}/ui/*.ui

-> you have to use %{_datadir}/%{name}/ instead (so that all files below including /usr/share/blueman belong to the package)

* files not listed twice: OK

* file permssions: OK

* rm -rf $RPM_BUILD_ROOT in %install and %clean: OK

* macro usage: OK, probably
%{python_sitelib}/blueman
can be changed to
%{python_sitelib}/%{name}

* code vs. content: no content besides some icons

* large docu: OK (n/a)

* %doc: OK

* header files / static libs: OK (n/a)

* pkgconfig files: OK (n/a)

* shared libs: OK (n/a)

* *.la, *.a files: OK (deleted in %install)

* desktop-file: TODO

- update-desktop-database not needed any more

* gtk-update-icon-cache: TODO

- the directories must be "touch"ed before gtk-update-icon-cache runs - the preferred usage is now in Fedora:

%post
touch --no-create %{_datadir}/icons/hicolor &>/dev/null || :

%postun
if [ $1 -eq 0 ] ; then
    touch --no-create %{_datadir}/icons/hicolor &>/dev/null
    gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
fi

%posttrans
gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :

* patches: TODO
- since the package contains now an upstream patch, it is necessary to add a comment about the status of the patch (e.g. was it already committed upstream, is there a corresponding bug report upstream, etc.) (see: http://fedoraproject.org/wiki/Packaging:Guidelines -> All Patches should have an upstream bug link or commnet)

* compiler flags: OK (rpmoptflags used)

* debuginfo complete: OK

* functional check: TODO
- I did just installed the package and tried to use it, but without much success. Please can you give me some easy to reproduce use-cases?

- As far as I know bluez-gnome and gnome-bluetooth provide similar functionality. How do these packages interact? Which are necessary? Are they mutual exclusive? It would be great if you could give me some insights about this...


Best regards,
Christian
Comment 17 Christian Krause 2009-03-15 18:51:59 EDT
Created attachment 335280 [details]
specfile which fixes the compilation problems
Comment 18 Juan Manuel Rodriguez 2009-03-15 21:20:49 EDT
Christian, 

Upstream bug report is this: https://bugs.edge.launchpad.net/blueman/+bug/337877

I updated the Spec to include the observations. 

I tried compiling using Koji, but got "Policy Violation" errors. Maybe I'm doing something wrong? http://koji.fedoraproject.org/koji/taskinfo?taskID=1242686
I also noticed that dist-f9 and dist-f10 appear to be "locked"... I wonder what that's about?

I placed my Spec in the usual directory:
Spec URL:
http://proyectofedora.org/mexico/wp-content/uploads/2009/03/blueman.spec

It compiles, installs and works correctly in 32bit (x86) Fedora 10, tested in 2 laptops and 1 desktop. 

I'm not sure why I can't compile for F11... 

Thanks a lot for your time, I hope to get this packaged soon.
Comment 19 Rajeesh 2009-03-15 23:22:12 EDT
(In reply to comment #15)
> (In reply to comment #11)
> > A few comments:
> > 
> > I do not find dbus-python-devel a BuildRequires either. Anyway.
> 
> Otherwise a mock build on x86 will fail with this error message:
> 
> checking for python module dbus... no
> configure: error: Could not find Python module dbus  

BuildRequires of dbus-python would be sufficient for this, correct? My mock environment here doesn't have dbus-python-devel installed, but it builds cleanly.
Comment 20 Rajeesh 2009-03-15 23:25:17 EDT
Just a note : "autoreconf -f -f --disable" will produce no .{l,}a files, thereby removing them in %install can be omitted.
Comment 21 Rajeesh 2009-03-15 23:29:56 EDT
(In reply to comment #16)

> - same applies to %{_datadir}/PolicyKit/policy/org.blueman.policy -> PolicyKit
> should be required

We already have "Requires: PolicyKit-gnome", which depends on PolicyKit. So this is spurious, I think.

Thanks Christian!
Comment 22 Rajeesh 2009-03-16 01:19:03 EDT
(In reply to comment #20)
> Just a note : "autoreconf -f -f --disable" will produce no .{l,}a files,
> thereby removing them in %install can be omitted.  

Typo. :-(
It should be "%configure --disable-static"
Comment 23 Christian Krause 2009-03-20 19:34:56 EDT
Hello,

(In reply to comment #18)
> I tried compiling using Koji, but got "Policy Violation" errors. Maybe I'm
> doing something wrong?
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1242686
> I also noticed that dist-f9 and dist-f10 appear to be "locked"... I wonder what
> that's about?

It looks like that you've tried to do an "official" build for these packages, but right now you can do only scratch builds. Please try: "koji build --scratch dist-f9 path/to/my.src.rpm"

> Spec URL:
> http://proyectofedora.org/mexico/wp-content/uploads/2009/03/blueman.spec

I've roughly scanned over your new spec file, there are still some minor issues:

* when using %{_datadir}/%{name}/* , only the entries of the directory %{_datadir}/%{name} will be owned by the package, but not the directory itself. Please use %{_datadir}/%{name}/

* desktop-file: TODO
- update-desktop-database not needed since the destkop file doesn't include a mimetype:
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#desktop-database

* if you like, you can also try to use the suggestion from Rajeesh to use --disable-static to avoid the build of the *.la and *.a files completely (and so to avoid to remove them explicitely)

* Since this package may interfere with the existing bluez-* and gnome-bluetooth packages, it is necessary to test it. Please have a look at my comments regarding the "functional check" and address them. Thanks!

Best regards,
Christian
Comment 24 Juan Manuel Rodriguez 2009-03-23 18:12:24 EDT
Hi Christian, 

I updated the SPEC to v9 to include the latest changes. 
Spec URL:
http://proyectofedora.org/mexico/wp-content/uploads/2009/03/blueman.spec

I changed the datadir/name so that it own the directory too. 
I removed the update-desktop-database. 

I tried --disable-static, however that seems to generate .la files anyways (but it no longer creates .a files), so I left the line to remove .la files. 

I've been using blueman in my desktop since I started building the packages, I do have gnome bluetooth installed, as far as I know, there have been no conflicts between the 2 of them, but I'll be running some more tests. 

I think we're getting down the final touches to the SPEC File, I hope to see blueman in F10 soon!
Comment 25 Juan Manuel Rodriguez 2009-03-23 18:25:53 EDT
Built packages succesfully for Fedora 11 and Fedora 10. 
F11: http://koji.fedoraproject.org/koji/taskinfo?taskID=1255447
F10: http://koji.fedoraproject.org/koji/taskinfo?taskID=1255459

It failed on F9. I think that's because some dependencies could not be fulfilled
F9: http://koji.fedoraproject.org/koji/taskinfo?taskID=1255474

Error log: http://koji.fedoraproject.org/koji/getfile?taskID=1255477&name=root.log
Comment 26 Juan Manuel Rodriguez 2009-03-27 03:04:44 EDT
Any additional comments?
Comment 27 Christian Krause 2009-04-23 18:06:10 EDT
(In reply to comment #25)
> Built packages succesfully for Fedora 11 and Fedora 10. 
> F11: http://koji.fedoraproject.org/koji/taskinfo?taskID=1255447
> F10: http://koji.fedoraproject.org/koji/taskinfo?taskID=1255459
> 
> It failed on F9. I think that's because some dependencies could not be

Sorry for the late response.

It looks like that Lubomir is officially taking care of this review and he may also be able to sponsor your.

I've roughly looked at your most recent spec file: http://proyectofedora.org/mexico/wp-content/uploads/2009/03/blueman.spec
and I have some minor remarks:

- in %postun you call "gtk-update-icon-cache" twice (detailed information: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Icon_Cache )

- since data files are placed in %{_datadir}/hal/fdi/information/20thirdparty, the package should require "hal".

Additionally I've tested it a little bit with my cell phone and it seems to work good (don't know why I couldn't get it running previously).

I think that package is now ready for a final review.
Comment 28 Michal Ingeli 2009-04-27 05:47:24 EDT
I updated package tu current version of blueman (1.10). Based on previous spec file, removed patch0 (as it was fixed in recent versions). rpmlint silent, builds fine in mock for fedora-10-i386.

http://v3.sk/~xyzz/rpm/blueman-1.10-1.fc10.src.rpm
http://v3.sk/~xyzz/rpm/blueman.spec

> - in %postun you call "gtk-update-icon-cache" twice (detailed information:
> http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Icon_Cache )
Updated according to wiki.

> - since data files are placed in %{_datadir}/hal/fdi/information/20thirdparty,
> the package should require "hal".
Added hal as requirement.
Comment 29 Juan Manuel Rodriguez 2009-04-27 11:07:13 EDT
Thanks for the update Michal, 

With the whole "FLISoL" business, I've been a bit too busy to change/update blueman, but I'm ready to continue with the package audit ;)
Comment 30 Lubomir Rintel 2009-04-27 16:40:29 EDT
Seems mostly fine.

- Builds in mock
  http://koji.fedoraproject.org/koji/taskinfo?taskID=1324720
- Packaged latest version
- Requires & provides sane
- Filelist ok
- Uses compiler flags correctly
- Patches present submitted upstream
- SPEC file clean, legible, written in American English

1.) RPMlint:

> blueman.src: W: mixed-use-of-spaces-and-tabs (spaces: line 4, tab: line 4)
> The specfile mixes use of spaces and tabs for indentation, which is a cosmetic
> annoyance.  Use either spaces or tabs for indentation, not both.

EasyFix

> blueman.src: W: patch-not-applied Patch0: blueman-build-pygtk.patch
> A patch is included in your package but was not applied. Refer to the patches
> documentation to see what's wrong.

With this not applied, it's probably not needed to require and run autoconf, right?

2.) Summary & Description

Formatted text will not look good in GUIs. You may want to change the description to be a descriptive paragraph instead of a bulleted list.

Summary may also need some improvement; I would not be able to decide whether I want the application or not just by reading the summary. Please think of the casual user; something like "Tool to manage Bluetooth enable devices" or might be more appropriate.
Comment 31 Lubomir Rintel 2009-05-08 03:01:00 EDT
Juan Manuel: ping
Comment 32 Juan Manuel Rodriguez 2009-05-08 19:18:15 EDT
Hi there, sorry for the late reply. 

[Excuse]
Fedora 11 left one laptop and one desktop completely out of service, which left me with no room to develop. I just grabbed my bro's F10 laptop and am finishing the packages. 
[/Excuse]

I'll update this message as soon as I repackage the RPM.
Comment 33 Leonid Kanter 2009-05-14 11:25:31 EDT
I rebuilt http://v3.sk/~xyzz/rpm/blueman-1.10-1.fc10.src.rpm on F11 and tried it. /dev/rfcomm0 was successfully created but blueman was unable to add new modem to hal configuration. Traceback follows:

Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 586, in msg_reply_handler
    reply_handler(*message.get_args_list(**get_args_opts))
  File "/usr/lib/python2.6/site-packages/blueman/plugins/applet/DBusService.py", line 103, in reply
    self.Applet.Plugins.Run("on_rfcomm_connected", dev, rfcomm, uuid)
  File "/usr/bin/blueman-applet", line 210, in Run
    ret = getattr(inst, function)(*args, **kwargs)
  File "/usr/lib/python2.6/site-packages/blueman/plugins/applet/ModemManager.py", line 122, in on_rfcomm_connected
    self.RegisterModem(device.get_object_path(), port)
  File "/usr/lib/python2.6/site-packages/blueman/plugins/applet/ModemManager.py", line 58, in RegisterModem
    m = Mechanism()
  File "/usr/lib/python2.6/site-packages/blueman/main/Mechanism.py", line 29, in __init__
    service = self.bus.get_object("org.blueman.Mechanism", "/")
  File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 244, in get_object
    follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 241, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 183, in activate_name_owner
    self.start_service_by_name(bus_name)
  File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 281, in start_service_by_name
    'su', (bus_name, flags)))
  File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 630, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed: Cannot launch daemon, file not found or permissions invalid
Loading configuration plugins
Using gconf config backend
Comment 34 Lubomir Rintel 2009-05-14 11:39:00 EDT
(In reply to comment #32)
> I'll update this message as soon as I repackage the RPM.

Just to remind you: It's been another week.
Three week for such tiny change is that some kind of joke or something?
Unless you'll post an updated RPM in a reasonable time frame the review request will be closed as abandoned.

(In reply to comment #33)
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed:
> Cannot launch daemon, file not found or permissions invalid
> Loading configuration plugins
> Using gconf config backend  

Looks like you're running it as root or something like that.
Comment 35 Leonid Kanter 2009-05-15 12:28:29 EDT
(In reply to comment #34)

> (In reply to comment #33)
> > dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ExecFailed:
> > Cannot launch daemon, file not found or permissions invalid
> > Loading configuration plugins
> > Using gconf config backend  
> 
> Looks like you're running it as root or something like that.  

No, I was running it as non-privileged user. Looks like it's F11-related problem, because on F10 the same package works perfectly. 

If you install blueman on ubuntu - it obsoletes gnome-bluetooth package. On Fedora, there are 2 bluetooth icons and gnome-bluetooth must be disabled manually.
Comment 36 Juan Manuel Rodriguez 2009-05-15 19:17:16 EDT
No RPM left behind!

Built Blueman 1.10-2
F10: http://koji.fedoraproject.org/koji/taskinfo?taskID=1356989
F11: http://koji.fedoraproject.org/koji/taskinfo?taskID=1356994

Spec: http://proyectofedora.org/mexico/Blueman.spec
SRPM: http://proyectofedora.org/mexico/blueman-1.10-1.fc11.src

I'm deeply sorry for being so late on providing the simple fixes. Work caught the best of me, and some Fedora 11 issues stopped me from fully migrating. 

I'm looking into a way to obsolete the old gnome-bluetooth once this is installed, any suggestions are appreciated.
Comment 37 Rajeesh 2009-05-16 00:40:36 EDT
(In reply to comment #36)
> I'm looking into a way to obsolete the old gnome-bluetooth once this is
> installed, any suggestions are appreciated.  

A simple "Obsoletes: gnome-bluetooth" directive in the spec file will do.
Comment 38 Lubomir Rintel 2009-05-16 01:02:30 EDT
(In reply to comment #36)

> I'm deeply sorry for being so late on providing the simple fixes. Work caught
> the best of me, and some Fedora 11 issues stopped me from fully migrating. 

Thanks, will look into those.

> I'm looking into a way to obsolete the old gnome-bluetooth once this is
> installed, any suggestions are appreciated.  

I believe the best thing you can do here is nothing and you should leave it up to the user.

(In reply to comment #37)
> (In reply to comment #36)
> > I'm looking into a way to obsolete the old gnome-bluetooth once this is
> > installed, any suggestions are appreciated.  
> 
> A simple "Obsoletes: gnome-bluetooth" directive in the spec file will do.  

Definitely not. You shouldn't obsolete other packages without approval of the package maintainer. Especially if both are maintained; let the user choose.
Comment 39 Juan Manuel Rodriguez 2009-05-16 01:04:14 EDT
I made a Spec that obsoletes bluetooth-applet, since that's the dual-icon showing up. 

Obsoleting gnome-bluetooth brings dependency issues.
Comment 40 Michal Ingeli 2009-05-16 03:08:17 EDT
Two bluetooth icons is not an issue. User can still decide which bluetooth app he/she will use and disable one of them in gnome session manager. Obsoleting package, that provides almost same functionality will force user to choose only one to install. There is no real reason for doing this.
Comment 41 Lubomir Rintel 2009-05-18 14:41:36 EDT
(In reply to comment #39)
> I made a Spec that obsoletes bluetooth-applet, since that's the dual-icon
> showing up. 

Please do not obsolete anything in Fedora that's not really obsolete, you don't replace it, don't conflict with it and haven't agreed with the maintainer.

The package seems fine in other respects and I'll approve it once you get sponsored.

In order to sponsor you, I'd like to see a couple of informal reviews you've done. That's usually done to demonstrate you're familiar with the guidelines and RPM packaging.
Comment 42 Juan Manuel Rodriguez 2009-05-19 01:29:29 EDT
Regarding obsoletes: I know I shouldn't obsolete other packages without user confirmation, thats why I didn't even send it to koji, I simply wanted to try the "Obsoletes" directive. 

Regarding reviews: I'll look around for other RPMs and do some reviews, I'm really looking forward to having Blueman officially in Fedora! :D
Comment 43 Valmantas Palikša 2009-06-12 17:26:58 EDT
I think a "Provides: dbus-bluez-pin-helper" entry is required, since bluez has this in the Requires fields. Without it, it would be difficult to install blueman as the only bluetooth manager.
Comment 44 Lubomir Rintel 2009-06-13 04:31:23 EDT
Juan: Ping. Anything you can get sponsored for?
Comment 45 Juan Manuel Rodriguez 2009-06-18 11:35:37 EDT
Lubomir: How about: https://bugzilla.redhat.com/show_bug.cgi?id=489014

Valmantas: I added the Provides as suggested. I'll try to remove all bluetooth references from Fedora, then try to install that package as the only bluetooth one. 

As soon as I finish and complete the test, I'll submit the package again. 

Sorry for taking so long, but I don't intend on abandoning my first rpm :)
Comment 46 Lubomir Rintel 2009-06-19 13:04:28 EDT
(In reply to comment #45)
> Lubomir: How about: https://bugzilla.redhat.com/show_bug.cgi?id=489014

Umm, somehow. Please try to follow the review guidelines and note the things you have checked: https://fedoraproject.org/wiki/Packaging/ReviewGuidelines

You may search bugzilla for closed review requests to see how are they usually done.
Comment 47 Lubomir Rintel 2009-06-26 09:26:41 EDT
'nushio' has been sponsored
removing NEEDSPONSOR now, the package can be

APPROVED
Comment 48 Juan Manuel Rodriguez 2009-06-26 09:39:51 EDT
Thanks Christian, Rajeesh and Lubomir for helping me get approved!
Comment 49 Juan Manuel Rodriguez 2009-06-26 09:54:46 EDT
New Package CVS Request
=======================
Package Name: blueman
Short Description: GTK+ Bluetooth Manager
Owners: nushio
Branches: devel, F-10, F-11
InitialCC:
Comment 50 Jason Tibbitts 2009-06-26 20:40:07 EDT
CVS done.
Comment 51 Jason Tibbitts 2009-06-26 20:42:03 EDT
Oops, unfortunately I can't do CVS because of:

blueman: PackageDB returned an error creating blueman: Email address nushio@gmail.com is not a valid bugzilla email address.  Either make a bugzilla account with that email address or change your email address in the Fedora Account System https://admin.fedoraproject.org/accounts/ to a valid bugzilla email address and try again.

Could you fix that?
Comment 52 Jason Tibbitts 2009-06-26 21:09:21 EDT
The problem, it seems, is that you made a FAS account, then made a bugzilla account with the FAS email.  For whatever reason, pkgdb doesn't permit that; it requires that the email address in FAS and the bugzilla address match.  You can request an exception by filing an infrastructure ticket at https://fedorahosted.org/fedora-infrastructure/.
Comment 53 Juan Manuel Rodriguez 2009-06-26 23:27:20 EDT
Yes Jason, I know, Toshio told me about it :)

I'm fixing, I've been AFK because of the fudcon. I'm excited to be a packager, you couldn't choose a better time, now that i'm pumped with Fedora.
Comment 54 Dennis Gilmore 2009-06-27 10:28:13 EDT
CVS Done
Comment 55 Fedora Update System 2009-06-27 11:20:59 EDT
blueman-1.10-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/blueman-1.10-3.fc11
Comment 56 Fedora Update System 2009-06-27 11:22:45 EDT
blueman-1.10-3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/blueman-1.10-3.fc10
Comment 57 Juan Manuel Rodriguez 2009-06-27 11:27:22 EDT
Done for F10, F11, Rawhide, now its on testing! :D
Comment 58 Fedora Update System 2009-06-30 17:28:24 EDT
blueman-1.10-3.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update blueman'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-7096
Comment 59 Fedora Update System 2009-06-30 17:41:47 EDT
blueman-1.10-3.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update blueman'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7170
Comment 60 Fedora Update System 2009-07-19 06:32:48 EDT
blueman-1.10-3.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 61 Fedora Update System 2009-07-19 06:34:12 EDT
blueman-1.10-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 62 leigh scott 2015-05-26 05:27:43 EDT
re-review of dead package

Spec URL: https://leigh123linux.fedorapeople.org/pub/review/blueman/1/blueman.spec

SRPM URL: https://leigh123linux.fedorapeople.org/pub/review/blueman/1/blueman-2.0-1.fc20.src.rpm

Description: GTK+ Bluetooth Manager
Fedora Account System Username: leigh123linux
Comment 63 leigh scott 2015-05-26 06:50:50 EDT
*** Bug 1171517 has been marked as a duplicate of this bug. ***
Comment 64 Wolfgang Ulbrich 2015-05-26 10:36:02 EDT
APPROVED!

Only a minor issue after our conversation per irc and your fixed srpm.

[!]: Package must own all directories that it creates.
     Note: Directories without known owners: /usr/share/pixmaps/blueman

Please own directory before uploading to git.



This is a review *template*. Besides handling the [ ]-marked tests you are
also supposed to fix the template before pasting into bugzilla:
- Add issues you find to the list of issues on top. If there isn't such
  a list, create one.
- Add your own remarks to the template checks.
- Add new lines marked [!] or [?] when you discover new things not
  listed by fedora-review.
- Change or remove any text in the template which is plain wrong. In this
  case you could also file a bug against fedora-review
- Remove the "[ ] Manual check required", you will not have any such lines
  in what you paste.
- Remove attachments which you deem not really useful (the rpmlint
  ones are mandatory, though)
- Remove this text



Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
- Package does not use a name that already exists.
  Note: A package with this name already exists. Please check
  https://admin.fedoraproject.org/pkgdb/acls/name/blueman
  See:
  https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Conflicting_Package_Names


===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[-]: Development (unversioned) .so files in -devel subpackage, if present.
     Note: Unversioned so-files in private %_libdir subdirectory (see
     attachment). Verify they are not in ld path.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "*No copyright* GPL (v2 or later)", "GPL (v2 or later)", "GPL
     (v3 or later)", "Unknown or generated". 109 files have unknown
     license. Detailed output of licensecheck in
     /home/rave/blueman/licensecheck.txt
[x]: Package requires other packages for directories it uses.
     Note: No known owner of /usr/share/pixmaps/blueman
[!]: Package must own all directories that it creates.
     Note: Directories without known owners: /usr/share/pixmaps/blueman

Please own directory before uploading to git.

[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: glib-compile-schemas is run in %postun and %posttrans if package has
     *.gschema.xml files.
     Note: gschema file(s) in blueman
[x]: The spec file handles locales properly.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: gtk-update-icon-cache is invoked in %postun and %posttrans if package
     contains icons.
     Note: icons in blueman
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 20480 bytes in 3 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %license.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: %config files are marked noreplace or the reason is justified.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package contains desktop file if it is a GUI application.
[x]: Package installs a %{name}.desktop using desktop-file-install or
     desktop-file-validate if there is such a file.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: No %config files under /usr.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

Python:
[x]: Python eggs must not download any dependencies during the build
     process.
[x]: A package which is used by another package via an egg interface should
     provide egg info.
[x]: Package meets the Packaging Guidelines::Python
[x]: Package contains BR: python2-devel or python3-devel
[x]: Binary eggs must be removed in %prep

===== SHOULD items =====

Generic:
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Uses parallel make %{?_smp_mflags} macro.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[-]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
     Note: Arch-ed rpms have a total of 4249600 bytes in /usr/share
[x]: Rpmlint is run on debuginfo package(s).
     Note: No rpmlint messages.
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).


Rpmlint
-------
Checking: blueman-2.0-1.fc22.x86_64.rpm
          blueman-2.0-1.fc22.src.rpm
blueman.x86_64: W: spelling-error %description -l en_US bluetooth -> Bluetooth, blue tooth, blue-tooth
blueman.x86_64: W: non-conffile-in-etc /etc/xdg/autostart/blueman.desktop
blueman.src: W: spelling-error %description -l en_US bluetooth -> Bluetooth, blue tooth, blue-tooth
blueman.src:34: W: unversioned-explicit-provides dbus-bluez-pin-helper

dbus-bluez-pin-helper is a virtual provides

blueman.src: W: invalid-url Source0: https://github.com/blueman-project/blueman/releases/download/2.0/
blueman-2.0.tar.xz HTTP Error 403: Forbidden

This is a false positve, download link is valid!

2 packages and 0 specfiles checked; 0 errors, 5 warnings.




Rpmlint (debuginfo)
-------------------
Checking: blueman-debuginfo-2.0-1.fc22.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.





Rpmlint (installed packages)
----------------------------
blueman.x86_64: W: spelling-error %description -l en_US bluetooth -> Bluetooth, blue tooth, blue-tooth
blueman.x86_64: W: non-conffile-in-etc /etc/xdg/autostart/blueman.desktop
2 packages and 0 specfiles checked; 0 errors, 2 warnings.



Requires
--------
blueman (rpmlib, GLIBC filtered):
    /bin/sh
    /usr/bin/env
    PolicyKit-authentication-agent
    bluez
    config(blueman)
    dbus
    desktop-notification-daemon
    libbluetooth.so.3()(64bit)
    libc.so.6()(64bit)
    libglib-2.0.so.0()(64bit)
    libgobject-2.0.so.0()(64bit)
    libgthread-2.0.so.0()(64bit)
    libpthread.so.0()(64bit)
    libpython2.7.so.1.0()(64bit)
    notify-python
    obexd
    pygobject3
    python(abi)
    python2
    rtld(GNU_HASH)



Provides
--------
blueman:
    application()
    application(blueman-adapters.desktop)
    application(blueman-manager.desktop)
    blueman
    blueman(x86-64)
    config(blueman)
    dbus-bluez-pin-helper



Unversioned so-files
--------------------
blueman: /usr/lib64/python2.7/site-packages/_blueman.so

Source checksums
----------------
https://github.com/blueman-project/blueman/releases/download/2.0/blueman-2.0.tar.xz :
  CHECKSUM(SHA256) this package     : 81a5ca95124f12bfb62d2d2d0d265af70cdae1d43b0c6e4fc6d2bad8f82958f1
  CHECKSUM(SHA256) upstream package : 81a5ca95124f12bfb62d2d2d0d265af70cdae1d43b0c6e4fc6d2bad8f82958f1


Generated by fedora-review 0.5.3 (bcf15e3) last change: 2015-05-04
Command line :/usr/bin/fedora-review -v -r -n blueman-2.0-1.fc20.src.rpm -m fedora-22-x86_64
Buildroot used: fedora-22-x86_64
Active plugins: Python, Generic, Shell-api, C/C++
Disabled plugins: Java, SugarActivity, fonts, Haskell, Ocaml, Perl, R, PHP, Ruby
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6
Comment 65 leigh scott 2015-05-26 10:42:25 EDT
Package Change Request
======================
Package Name: blueman
New Branches: f21 f22 epel7
Owners: leigh123linux raveit65
InitialCC:
Comment 66 leigh scott 2015-05-26 10:47:50 EDT
unblock ticket filed

https://fedorahosted.org/rel-eng/ticket/6186
Comment 67 Jon Ciesla 2015-05-26 15:22:40 EDT
Git done (by process-git-requests).
Comment 68 markusN 2015-09-28 12:54:00 EDT
Tested on current Fedora 22

dnf install blueman
exit

blueman-applet

... data transfer from phone to F22 workstation on laptop works.