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.
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.
Missing BuildRequires: Pyrex
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.
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
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!
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
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!
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
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
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.
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
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.
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 ?
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.
(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
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
Created attachment 335280 [details] specfile which fixes the compilation problems
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.
(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.
Just a note : "autoreconf -f -f --disable" will produce no .{l,}a files, thereby removing them in %install can be omitted.
(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!
(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"
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
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!
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
Any additional comments?
(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.
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.
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 ;)
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.
Juan Manuel: ping
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.
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
(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.
(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.
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.
(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.
(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.
I made a Spec that obsoletes bluetooth-applet, since that's the dual-icon showing up. Obsoleting gnome-bluetooth brings dependency issues.
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.
(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.
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
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.
Juan: Ping. Anything you can get sponsored for?
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 :)
(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.
'nushio' has been sponsored removing NEEDSPONSOR now, the package can be APPROVED
Thanks Christian, Rajeesh and Lubomir for helping me get approved!
New Package CVS Request ======================= Package Name: blueman Short Description: GTK+ Bluetooth Manager Owners: nushio Branches: devel, F-10, F-11 InitialCC:
CVS done.
Oops, unfortunately I can't do CVS because of: blueman: PackageDB returned an error creating blueman: Email address nushio 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?
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/.
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.
CVS Done
blueman-1.10-3.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/blueman-1.10-3.fc11
blueman-1.10-3.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/blueman-1.10-3.fc10
Done for F10, F11, Rawhide, now its on testing! :D
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
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
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.
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.
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
*** Bug 1171517 has been marked as a duplicate of this bug. ***
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
Package Change Request ====================== Package Name: blueman New Branches: f21 f22 epel7 Owners: leigh123linux raveit65 InitialCC:
unblock ticket filed https://fedorahosted.org/rel-eng/ticket/6186
Git done (by process-git-requests).
Tested on current Fedora 22 dnf install blueman exit blueman-applet ... data transfer from phone to F22 workstation on laptop works.