Bug 465727

Summary: Review Request: obexd - D-Bus service for Obex Client access
Product: [Fedora] Fedora Reporter: Bastien Nocera <bnocera>
Component: Package ReviewAssignee: Parag AN(पराग) <panemade>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: fedora-package-review, marcel, notting, panemade
Target Milestone: ---Flags: panemade: fedora-review+
kevin: fedora-cvs+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-07 18:25:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Bastien Nocera 2008-10-06 04:25:44 UTC
Spec URL: http://hadess.fedorapeople.org/obexd/obexd.spec
SRPM URL: http://hadess.fedorapeople.org/obexd/obexd-0.5-1.fc9.src.rpm
Description:
obexd contains obex-client, a D-Bus service to allow sending files
using the Obex Push protocol, common on mobile phones and 
other Bluetooth-equipped devices.

Comment 1 Bastien Nocera 2008-10-06 04:26:23 UTC
Builds in koji scratch:
http://koji.fedoraproject.org/koji/taskinfo?taskID=862931

Comment 2 Parag AN(पराग) 2008-10-06 05:09:41 UTC
how is this different from bluetooth-sendto?

Comment 3 Bastien Nocera 2008-10-06 06:09:09 UTC
It's a D-Bus service, whereas bluetooth-sendto is a front-end. bluetooth-sendto can use obex-data-server, or obexd.

Comment 4 Parag AN(पराग) 2008-10-06 06:40:04 UTC
Suggestions:-
1)rpmlint complained as
obexd.i386: W: incoherent-version-in-changelog 0.5 1:0.5-1.fc10
==> easy fix change it to 0.5-1
obexd.i386: W: spurious-executable-perm /usr/share/doc/obexd-0.5/send-files
obexd.i386: W: doc-file-dependency /usr/share/doc/obexd-0.5/send-files /usr/bin/python
==> You may like to drop executable bits on send-files which is installed as %doc file.

2) Why Epoch is added in SPEC?

  I see COPYING is included as GPLv3 but sources have GPLv2 license text, But license in SPEC is correct.

I tried to use bluetooth-sendto to send file to mobile but I think existing setup on rawhide is using obex-data-server to send file and if i try to remove it, its removing bluetooth packages.

Then I tried to send file using send-files program as
send-files <mobiledeviceHWaddress> Track1.mp3
but nothing appeared on screen and no files received on mobile.

Comment 5 Bastien Nocera 2008-10-06 06:48:57 UTC
(In reply to comment #4)
> Suggestions:-
> 1)rpmlint complained as
> obexd.i386: W: incoherent-version-in-changelog 0.5 1:0.5-1.fc10
> ==> easy fix change it to 0.5-1

Fix locally

> obexd.i386: W: spurious-executable-perm /usr/share/doc/obexd-0.5/send-files
> obexd.i386: W: doc-file-dependency /usr/share/doc/obexd-0.5/send-files
> /usr/bin/python
> ==> You may like to drop executable bits on send-files which is installed as
> %doc file.

Fixed locally

> 2) Why Epoch is added in SPEC?

Cut'n'paste error.

>   I see COPYING is included as GPLv3 but sources have GPLv2 license text, But
> license in SPEC is correct.

That's probably because the autotools install the COPYING file if it's not present.

> I tried to use bluetooth-sendto to send file to mobile but I think existing
> setup on rawhide is using obex-data-server to send file and if i try to remove
> it, its removing bluetooth packages.

obex-client will be used automatically by bluetooth-sendto from bluez-gnome-1.8 only.

> Then I tried to send file using send-files program as
> send-files <mobiledeviceHWaddress> Track1.mp3
> but nothing appeared on screen and no files received on mobile.

I don't think send-files is supposed to work for Obex Push targets. Try with a newer bluez-gnome.

Comment 6 Parag AN(पराग) 2008-10-06 07:57:37 UTC
As no updated SRPM is provided for reviewing, I am reviewing package given in initial comment.

Review:
+ package builds in mock (rawhide i386).
koji build => http://koji.fedoraproject.org/koji/taskinfo?taskID=863059
+ rpmlint is silent for SRPM. But NOT for RPM.
obexd.i386: W: spurious-executable-perm /usr/share/doc/obexd-0.5/send-files
obexd.i386: W: incoherent-version-in-changelog 0.5 1:0.5-1.fc10
obexd.i386: E: no-binary
obexd.i386: W: doc-file-dependency /usr/share/doc/obexd-0.5/send-files /usr/bin/python
==> Ok. Assuming you will fix these at time of CVS import.

+ source files match upstream.
614f14a2024d13af5a936345c086cdb7  obexd-0.5.tar.gz
+ package meets naming and packaging guidelines.
+ specfile is properly named, is cleanly written
+ Spec file is written in American English.
+ Spec file is legible.
+ dist tag is present.
+ build root is correct.
+ license is open source-compatible.
+ License text is included in package
  ==> you can add manually GPLv2 COPYING in next upstream release.

+ %doc files present.
+ BuildRequires are proper.
+ Compiler flags used correctly.
+ defattr usage is correct
+ %clean is present.
+ package installed properly.
+ Macro use appears rather consistent.
+ Package contains code.
+ no static libraries.
+ no .pc file present.
+ no -devel subpackage exists.
+ no .la files.
+ no translations are available.
+ Does owns the directories it creates.
+ no duplicates in %files.
+ file permissions are appropriate.
+ no scriptlets are used.
+ Not a GUI app.

Suggestion:-
  1)Remove Epoch tag from SPEC
APPROVED.

Comment 7 Marcel Holtmann 2008-10-06 08:08:28 UTC
I fixed the COPYING file in the upstream repository already. That is an upstream problem and has nothing to do with the packaging.

The build dependency for dbus-glib-devel is bogus. It is glib-devel and dbus-devel.

What do you need libtool for? It has two internal libraries, but these are statically linked ranlib. So just plain gcc will do its job.

Comment 8 Bastien Nocera 2008-10-06 08:22:19 UTC
I fixed the BRs some more, and removed the libtool dep (another cut'n'paste error).

New Package CVS Request
=======================
Package Name: obexd
Short Description: D-Bus service for Obex Client access
Owners: hadess
Branches: devel

Comment 10 Parag AN(पराग) 2008-10-06 08:37:07 UTC
(In reply to comment #7)
> I fixed the COPYING file in the upstream repository already. That is an
> upstream problem and has nothing to do with the packaging.
> 
Agree.

> The build dependency for dbus-glib-devel is bogus. It is glib-devel and
> dbus-devel.
> 
> What do you need libtool for? It has two internal libraries, but these are
> statically linked ranlib. So just plain gcc will do its job.

You are correct. I completely forgotten to check unnecessary BRs. I now just did scratch build with new BRs and its build failed(http://koji.fedoraproject.org/koji/taskinfo?taskID=863125). Change I did is
BuildRequires:  dbus-devel,glib-devel
BuildRequires:  bluez-libs-devel >= 4.0
BuildRequires:  openobex-devel

(In reply to comment #9)
> Spec URL: http://hadess.fedorapeople.org/obexd/obexd.spec
> SRPM URL: http://hadess.fedorapeople.org/obexd/obexd-0.5-2.fc9.src.rpm

So, as per updated SRPM BRs should be 
BuildRequires:  dbus-devel,glib2-devel
BuildRequires:  bluez-libs-devel >= 4.0
BuildRequires:  openobex-devel
which is working fine.
http://koji.fedoraproject.org/koji/taskinfo?taskID=863145

Comment 11 Kevin Fenzi 2008-10-07 17:41:22 UTC
cvs done.

Comment 12 Bastien Nocera 2008-10-07 18:25:05 UTC
Building in rawhide, thanks.