Bug 465727 - Review Request: obexd - D-Bus service for Obex Client access
Review Request: obexd - D-Bus service for Obex Client access
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Parag AN(पराग)
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-06 00:25 EDT by Bastien Nocera
Modified: 2008-10-07 14:25 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-07 14:25:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
panemade: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Bastien Nocera 2008-10-06 00:25:44 EDT
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 00:26:23 EDT
Builds in koji scratch:
http://koji.fedoraproject.org/koji/taskinfo?taskID=862931
Comment 2 Parag AN(पराग) 2008-10-06 01:09:41 EDT
how is this different from bluetooth-sendto?
Comment 3 Bastien Nocera 2008-10-06 02:09:09 EDT
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 02:40:04 EDT
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 02:48:57 EDT
(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 03:57:37 EDT
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 04:08:28 EDT
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 04:22:19 EDT
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 04:37:07 EDT
(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 13:41:22 EDT
cvs done.
Comment 12 Bastien Nocera 2008-10-07 14:25:05 EDT
Building in rawhide, thanks.

Note You need to log in before you can comment on or make changes to this bug.