Bug 235203

*** Bug 186452 has been marked as a duplicate of this bug. ***

Open issues:
- pin-helper no longer supported.
  Use the debian old-pin-helper patch to re-enable pin-helper support in bluez.
  If all works well, push it upstream.
- SELinux. According to the original submitter, kdepin is FUBAR in enforce mode.
- FC6/pin-helper support?

- Gilboa

Why have I been added to Cc?

The patch attached to this bug would be nice to include, makes using OBEX file
transfers easier to use with various Nokia devices (from the SDP service view,
select "Nokia OBEX PC Suite Services" instead of "OBEX File Transfer"; the
former works but the latter does nothing for me):

http://bugs.kde.org/show_bug.cgi?id=129594

OK. I'll add it to the next build.

Short update: kdebluetooth builds just fine FC6 but fails miserably on -devel.
(xmms-devel problem).
As a result, I've yet to test the kdepin/bluez-utils patch.

- Gilboa

BTW, making XMMS support build-time optional (default disabled) and/or splitting
kbemusedsrv into a subpackage could be worth considering.

OK. XMMS problem solved.
I've managed to get kdebluetooth and patched [1] bluez-utils talking together
(or actually pairing) without breaking bluez-gnome. (using kbluepin)
I'll upload a new SRPM later today.

- Gilboa
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=236531

Added the sdp patch. I doesn't seem to work. (I do see the PC suite, but once I
try to click on it, the phone disconnects.) I'll investigate further.

* Mon Apr 23 2007 Gilboa Davara <gilboad[AT]gmail.com> 1-0-0.21.beta2
- Patch list clean-up.
- Add Nokia obex detection patch.
- Fix 64bit compile due to bad default in configure. (with_bluetooth_dir)
- Missing BR: libtempter-devel.
- Missing BT: libidn-devel.
- Added: kbluepin wrapper - configure kbluepin as the old-style pin helper.

Spec URL: http://gilboadavara.thecodergeek.com/kdebluetooth.spec
SRPM URL: http://gilboadavara.thecodergeek.com/kdebluetooth-1.0-0.21.beta2.src.rpm

Forgot to add.
Tested on both rawhide x86_64 and i386.
Old-style pinhelper requires a patched bluez-utils RPM. (Pending bluez-utils
maintainer approval)

- Gilboa

Not a review, but several remarks (with the help of rpmlint).

Packaging remarks:
  - next src.rpm should be compiled with a blank %{?dist} (at least to please 
rpmlint),
  - kdebluetooth owns "/usr/share/applnk/Settings/{Network,Peripherals}", 
seems strange,
  - %{_datadir}/config/obexrc should not be marked as %config file.

Things to be fixed with upstream:
  - %{_llibdir}/libirmcsynckonnector.so should be in ${_libdir}/kde3, and 
without any SONAME,
  - %{_datadir}/config/obexrc should have a name that is linked with KDE 
(kobexrc?),
  - kcm_btpaired.desktop and kcm_kbluetoothd.desktop are not correct 
(/usr/bin/desktop-file-validate complains about "Keywords").

(In reply to comment #10)
>   - %{_datadir}/config/obexrc should not be marked as %config file.

Actually, a precision: %{_datadir}/config/obexrc is for default settings. If 
the administrator of the machine wants some other settings, /etc/kde/obexrc 
can override that. And at the user level, there is ~/.kde/share/config/obexrc

Laurent,

Thanks for the comments.
I'll look'em up and release a new SRPM tomorrow.

BTW, feel free to review this submission if you have the spare time. 
(Given what needs to be done in bluez-utils, kdebluetooth is unlikely for
F7-release... Hopefully we'll be able to get it running following the actual
release.)

- Gilboa

I happen to really need this but given the depth of the issues and the fact that
I'm not up on KDE packaging, I'm not sure if I'd be the best reviewer.  Still,
I'll see what crops up as I get it built and do some testing.

Short updated. (And sorry for the week-long silence)
I'm trying to get a working dbus wrapper for kdepin.
Hopefully, I'll finish it by Friday and release a new SRPM.

The reason for writing a wrapper (as opposed to doing it right [tm], and adding
DBUS support for kdebluetooth itself) is rather simple.
A. I'm a C programmer and I'm a rotten CPP programmer.
B. I zero experience with QT; DBUS' API, as ugly as it looks seems to have a
much lower learning curve. (At least to me)
C. I'm basing my code around existing bluez-dbus wrappers.

While I doubt that it'll be ready by F7/release, if someone picks up the review,
it -should- be ready a couple of days following the release.

- Gilboa

ping

Alive and well.
I'm doing my best to get a release out before the weekend.

- Gilboa

OK. The wrapper (bluez_pinhelper) seems to be working just fine. (AFAICS)
It is a rather generic wrapper (it can be used with 'zenity' and 'dialog' to
create script based passkey dialog-boxes) and as such, I'm currently looking to
get it included upstream into bluez-utils.

The updated kdebluetooth RPM requires the new bluez_pinhelper package, which
will be submitted later today/tomorrow.

- Gilboa

woohoo, kdebluetooth-1.0beta3:
http://lists.kde.org/?l=kde-announce&m=118164828810672&w=2:
"...kdebluetooth got mostly rewritten to make use of the BlueZ D-BUS API and all
of their services..."

quick look over the updated package there is a needed new BuildRequires on 
obexftp-devel

Updated SRPM is on the way.
obexftp and dbus-qt added.

... Hopefully I can get this package out on the open... before F10 :(

OK. Here goes.
I re-did most of SPEC (beta 3 removed huge chunks of the old code.), so I may
have broken a couple of things on the way? (find_lang??)
In general, the pin seems to work (no more helper hacks!). Same goes for the
device scan.
Interface looks better. I've yet to test OBEX file transfers.

* Tue Jun 12 2007 Gilboa Davara <gilboad[AT]gmail.com> 1-0.0-23.beta3
- Beta3.
- Remove pin-helper. (No longer needed - beta3 has dbus support.)
- Added BR dbus-qt.
- Added BR obexftp-devel.

SPEC: http://gilboadavara.thecodergeek.com/kdebluetooth.spec
SRPM: http://gilboadavara.thecodergeek.com/kdebluetooth-1.0-0.22.beta3.src.rpm

Just a FYI: Ick, with this version I'm no longer able to do OBEX file transfers
to a Nokia N70 at all.  My earlier patch
(http://bugs.kde.org/show_bug.cgi?id=129594) doesn't look even close to being
applicable any more, and what's worse, now I can no longer even type the correct
URL to konqueror, obex2://00:17:4b:19:26:83@bluetooth:12/ immediately turns into
obex2://00@bluetooth:12/ when I hit enter and things go south :(

Just a feedback that prompts don't work for me on my FC6 system with the latest
beta3 rpm.

Only by setting "security auto" and by using the passkey I entered into
hcid.conf I can pair a phone with the computer.

"security user" gives me an error message in the phone after I enter a passkey
in the phone.

Ville,

I'm getting the same error.
obexftp problem?

kaie,
FC6 uses an older version of bluez-lib (3.7) while kdebluetooth b3 (AFAIK)
requires bluez-lib >= 3.9.
I'll chance the BR to reflect the required bluez-lib version.

- Gilboa

s/chance/change/g

Gilboa; in the configure line, you can remove '--enable-irmcsynckonnector', in
beta3 it has been removed.

(In reply to comment #24)
> Ville,
> 
> I'm getting the same error.
> obexftp problem?

Maybe, dunno, or a generic Konqueror URL interpretation one.  In earlier
releases the magic URL for me was obex://[00:17:4b:19:26:83]:12/ - now I suppose
it's obex2, the brackets are gone and a @bluetooth has been added before :12.

But I found a workaround - URL escaping the colons before the @ to %3A allows me
to access the phone again.  So this URL works for me with beta3:
obex2://00%3A17%3A4b%3A19%3A26%3A83@bluetooth:12/

for what its worth with F-7 it works fine for me.  
obex2://00:17:84:1b:ef:13@bluetooth:9/ is what i get. 

livinded@herpes:~/rpmbuild/RPMS/i686$ rpmlint -i
kdebluetooth-1.0-0.22.beta3.i686.rpm
W: kdebluetooth no-documentation
The package contains no documentation (README, doc, etc).
You have to include documentation files.

W: kdebluetooth incoherent-version-in-changelog 1-0.0-23.beta3 1.0-0.22.beta3
The last entry in %changelog contains a version identifier that is not
coherent with the epoch:version-release tuple of the package.

Other than that the rpm seems to work find except that it installs menu items in
a few different places which is kind of annoying. The only issues I've had are
ones that appear to be with the application itself.

OK. New SRPM.
Seems to be working ~90% on both my SE K800 and Nokia 6230. (At least file
paring and file transfers)
Thanks again to Thomas Davis for the hex patch.

On a side (or should I say, personal) note, got married two weeks ago; moving to
a new house in two days. Hopefully once the dust settles I'll have more time to
get kdebluetooth (and the rest of my packages) the love that they deserve.

Hopefully this SRPM will be sea-worthy.

* Mon Jun 25 2007 Gilboa Davara <gilboad[AT]gmail.com> 1-0.0-24.beta3
- Added hex encoding patch by Thomas Davis.
- Removed --enable-irmcsynckonnector (deprecated in b3)
- Add missing docs. (Removed by mistake in b23)
- Known issue - services menu doesn't seem to work. (Requires debugging / upstream )

SPEC: http://gilboadavara.thecodergeek.com/kdebluetooth.spec
SRPM: http://gilboadavara.thecodergeek.com/kdebluetooth-1.0-0.24.beta3.src.rpm

- Gilboa

Also.
On my F7 desktop (as opposed to my -devel VMWare VM), kdebluetooth doesn't
auto-start.
Now, my /home (and .kde) has been with me since, err, F2 (?), so I may have a
semi-broken service configuration.

Can anyone confirm that the kdeblueeoth auto-starts on an F7 machine?

You have a settings probelm in the session-manager.

I found that I had to run control-center, select kde components, select session
manager, and select restore previous session under 'On Login'

FYI, there appears to be several other fixes in the SVN repo for kdebluetooth.

I'll check and see what those changes do - some appear to be minor.

Congrats!

Just a little question: since all the .desktop files seem to be OnlyShowIn=KDE,
does the GTK icon cache be updated in scriptlets?

(In reply to comment #28)
> for what its worth with F-7 it works fine for me.  
> obex2://00:17:84:1b:ef:13@bluetooth:9/ is what i get. 

To reproduce the problem I have (had, kind of, workaround in comment 27), try
changing eg. the :9 to :10 in the URL in Konqueror's location bar, hit enter,
and see what the URL changes into.

Ville,

Thanks :)

"Just a little question: since all the .desktop files seem to be OnlyShowIn=KDE,
does the GTK icon cache be updated in scriptlets?"

... Umm, something tells me I shouldn't be calling gtk-update-icon-cache on %pre
and %post, right?

I'll look into the :9/:10 problem.

- Gilboa

... Though... Does anyone see any reason why kdebluetooth icons should be
system-wide instead of KDE-only? (Read: OnlyShowIn!=KDE)

FYI - I tried kdebluetooth-1.0-0.24.beta3.src.rpm and I get the following
selinux related error:

[matt@tbc SRPMS]$ kbluetooth
kbluetooth: error while loading shared libraries: /usr/lib/libkbluetooth.so.0:
cannot restore segment prot after reloc: Permission denied

Weird.

I've tested it on 3 machines, two FC7's in enforcing and on -Devel, again, in
enforcing.
Can you dig out the exact error from messages?

Oh, what's the output of ls -lZ /usr/lib/libkbluetooth.so.0

Mine is:
ls -lZ /usr/lib64/libkbluetooth.so.0 lrwxrwxrwx root root
system_u:object_r:lib_t /usr/lib64/libkbluetooth.so.0 -> libkbluetooth.so.0.0.0

- Gilboa

Ville,

I cannot seem to reproduce the :9/:10 problem and I've tested 4 different phones
(3 Nokia's, one SE) and my palm. (E.g. I'm getting :7 with my SE K800).

Does it continue to happen with -24?

- Gilboa

There seems to be quite a bit of confusion here.  Just forget about any
particular channel numbers (dunno if that's the correct term, but I mean the :9
:10 :12 and friends).  I no longer know what you might mean by the ":9/:10
problem" so here goes:

Problem 1: kdebluetooth doesn't find an OBEX file transfer service on a channel
that would work with my N70.  The SDP view lists an "OBEX File Transfer" icon
but that doesn't work for me (:10), it returns an empty view.  Before beta3, I
patched kdebluetooth to find additionally the one that works for me (:12,
identified by a proprietary PC suite file OBEX transfer thingy ID or something
in addition to the usual OBEX file transfer one), but the patch no longer
applies.  I have the bug/RFE open upstream, and will maybe look into refreshing
the patch sometime so it'd apply to post-beta3 sources again.

Problem 2: Without URL escaping colons, Konqueror eats my obex2 URLs when I type
them into the location bar and hit enter as described in comment 22.  URL
escaping the colons works, see comment 27.

Neither of those problems is a blocker for this package - the first one is an
upstream kdebluetooth RFE, and the second either a bug in Konqueror or a problem
between chair and keyboard.  Just forget about them as far as getting this
package to Fedora is concerned.

Regarding the first problem, I think Nokia PC Suite for Windows installs
something to the phone when it is used the first time - maybe that has done
something to OBEX in my phone when I tried it, dunno.

Ville,

OK. Now I get the full picture.
Can you post the BZ# of the RFE of problem 1 so  I can subscribe to it?
Either way, I did some monkey coding and adopted your patch to B3.
Does it solve the problem?

As for problem 2, I can reproduce it on my Nokia 6230 - konq indeed eats my URL
when I hit enter. Have you reported it upstream?

* Sun Jul 08 2007 Gilboa Davara <gilboad[AT]gmail.com> 1-0.0-25.beta4
- Adopted Ville Skyttä b2 patch to p3. (Hopefully) re-enable Nokia N73 obex support.
- Patch out "Configure services". (Disabled in B3)

SPEC: http://gilboadavara.thecodergeek.com/kdebluetooth.spec
SRPM: http://gilboadavara.thecodergeek.com/kdebluetooth-1.0-0.25.beta3.src.rpm

Created attachment 158729 [details]
N70 support. Take/1

One last thing.
I need someone to review this bug.
Anyone up to it? (Before I spam fedora-maintainers?)

Thanks, but the patch in 0.25 doesn't appear to affect anything.  Comment 4 has
info about my upstream bug report.  I haven't reported the URL eating issue
anywhere.

One new finding with 0.25 (no idea if it was present in earlier revisions): when
browsing my phone, in addition to the (as discussed) non-working-for-me "OBEX
File Transfer" icon, I see a "OBEX Object Push" one.  When double-clicking it, I
get an error dialog saying "Protocol not supported: obex" and nothing more happens.

OBEX object push returns the same protocol error in my case. I've reported it
upstream. [1]

Having a bad code-monkey day (lack of sleep) I tried replacing obex with obex2
in kdebluetooth/kioslave/sdp/btsdp.cpp:247, it works (no error), but I'm getting
an empty konq window.

- Gilboa
[1] http://bugs.kde.org/show_bug.cgi?id=147678

This has lingered long enough... :)

1.  MUST: fix scriptlets, add missing 'touch', before gtk-update-icon-cache:
touch --no-create %{_datadir}/icons/hicolor ||:

2.  MUST: omit stray .la files, add near end of %install:
rm -f $RPM_BUILD_ROOT%{_libdir}/lib*.la
and fix %files list accordingly.
(unless you've discovered these are actually required)

3.  SHOULD remove --add-only-show-in="KDE"
This isn't (shouldn't be!?) desktop-specific, and could be of value to users 
of other desktops.  I don't feel strongly about it, tho.

4.  SHOULD omit
BuildRequires:	libutempter-devel
not sure why that's included (I suspect due to the kde packaging bug that's 
long-since been fixed).

5.  SHOULD use %{?dist} in Release, something like:
Release:	0.25.beta3%{?dist}


Address these, and I'll approve this.

1. sourceforge url should be corrected as stated in:
http://fedoraproject.org/wiki/Packaging/SourceURL?highlight=%28sourceforge%29#head-e27982f18a3bfd26b5b6ecbee113d2d8f3f006f2

2. URL should now be:
http://bluetooth.kmobiletools.org/

3. I'm experiencing crashes (everytime) on clicking on:
* Configuration -> Input Devices
    * connect  (crash)
    * Add new devices - > setup (crash)
(The application KInputWizard (kinputwizard) crashed and caused the signall 11 
(SIGSEGV)

Gilboa, please consider Chitlesh's suggestions 1,2 as SHOULD items as well.
(3) looks like a bug, that afaic, can be addressed post-review (provided the 
app WORKSFORU, I don't have bluetooth to test myself).

I just got a bluetooth usb stick for my birthday. I can take up the review but
will only approve if i can get minimum my usb stick working (It's working with
gnome-bluetooth, up to now). However I would recommend anyone helping this
review to take a look how kubuntu got its kdebluetooth integrated into the
distribution.

Chitlesh, thanks.  I think we've got things pretty well in hand review-wise, but
feedback on functionality is certainly always welcome.

(In reply to comment #46)
> 3. I'm experiencing crashes (everytime) on clicking on:
> * Configuration -> Input Devices
>     * connect  (crash)
>     * Add new devices - > setup (crash)
> (The application KInputWizard (kinputwizard) crashed and caused the signall 
11 > (SIGSEGV)

Someone on suse is experiencing the same crashes:
http://bluetooth.kmobiletools.org/uieforum?c=showthread&ThreadID=8
http://bluetooth.kmobiletools.org/uieforum?c=showthread&ThreadID=9

beta3 should not be released as-is; there is more fixes in the SVN repo at
http://websvn.kde.org/branches/extragear/kde3/pim/kdebluetooth that should be
used, including what appears to be fixed for the kinputwizard crash.

I agree, the rpm itself is pretty decent but there are a lot of upstream issues
that need to be fixed in it. I'm assuming that Beta3 is fairly close to a
complete rewrite as they've added a lot new features, changed the menus a bit,
and they had to add a dbus layer for everything in order to work with BlueZ 3.x.
Unfortunately Beta is is REALLY buggy at least in some of it's functionality. I
haven't tested the svn builds yet, but I'd assume it would better to checkout
source from there at least until a new release is made.

In general, I rather not use the SVN. Unlike rawhide, F7 users are not used to
having unstable packages getting constantly replaced under their feet and beta3
seems to me as "good enough (tm)" (I can reliably pair and un-pair devices and I
can upload/download files to/from my cellphone/palm)

Either way, the input devices bug is known (fixed in svn) and beta4 is just
around the corner [1] so I guess we can release and wait it out.
[1] http://bugs.kde.org/show_bug.cgi?id=147300

SPEC: http://gilboadavara.thecodergeek.com/kdebluetooth.spec
SRPM: http://gilboadavara.thecodergeek.com/kdebluetooth-1.0-0.27.beta3.src.rpm

* Sun Jul 12 2007 Gilboa Davara <gilboad[AT]gmail.com> 1-0.0-27.beta3
- Add missing touch /icon/hicolor.
- Menu items: Remove only-in-KDE.
- BR: Remove libutempter-devel.
- Fix project URL and source URL.
- Add missing %%dist.

- Gilboa

built fine in mock.
$rpmlint *.rpm
W: kdebluetooth patch-not-applied Patch2: kdebluetooth-nokia.patch
(assuming you are purposely including an unused patch).
W: kdebluetooth incoherent-version-in-changelog 1-0.0-27.beta3 1.0-0.27.beta3
(looks like you've got a few version typos in changelog)
W: kdebluetooth-devel no-documentation
(no biggie).


Good work, APPROVED.

... Ooops... had two versions of B27, older one (without the dist) and a new one.
Here's the actual build:

SPEC: http://gilboadavara.thecodergeek.com/kdebluetooth.spec
SRPM: http://gilboadavara.thecodergeek.com/kdebluetooth-1.0-0.27.beta3.fc7.src.rpm

even better...

release should be
Release:		0.27.%{reltype}%{?dist}
instead of
Release:		0.27.%{reltype}%{dist}

+ /usr/lib/rpm/redhat/find-lang.sh /var/tmp/kdebluetooth-1.0-0.27.beta3-root-chitlesh 
kbluelock
No translations found for kbluelock 
in /var/tmp/kdebluetooth-1.0-0.27.beta3-root-chitlesh
+ :
+ for PROG in '$PROG_LIST'
+ /usr/lib/rpm/redhat/find-lang.sh /var/tmp/kdebluetooth-1.0-0.27.beta3-root-chitlesh 
kbluemon
No translations found for kbluemon 
in /var/tmp/kdebluetooth-1.0-0.27.beta3-root-chitlesh
+ :
+ for PROG in '$PROG_LIST'
+ /usr/lib/rpm/redhat/find-lang.sh /var/tmp/kdebluetooth-1.0-0.27.beta3-root-chitlesh 
kbluetooth
No translations found for kbluetooth 
in /var/tmp/kdebluetooth-1.0-0.27.beta3-root-chitlesh
+ :
+ for PROG in '$PROG_LIST'                                                                                                   
....

This should be corrected.

(In reply to comment #53)
> Either way, the input devices bug is known (fixed in svn) and beta4 is just
> around the corner [1] so I guess we can release and wait it out.
> [1] http://bugs.kde.org/show_bug.cgi?id=147300

So why not revert back to beta2 which works as should ?

With the beta3(your 0.27) on konqueror
bluetooth:/
I can see my mobile phone and click on it
sdp://[XX:XX:XX:XX:XX:XX]/ appears on the URL bar of konqueror, but sees 
nothing on my mobile phone, while beta2 does.

Re: comment #58: mock build WORKSFORME:
http://kde-redhat.unl.edu/apt/kde-redhat/mock/fedora-7-i386-kde/kdebluetooth/

Re: comment #59: So why not revert back to beta2?
If it's already fixed in svn, why not wait for beta4? :)

(In reply to comment #60)
> Re: comment #59: So why not revert back to beta2?
> If it's already fixed in svn, why not wait for beta4? :)

I'm ok if the package isn't released to F-7 until beta4 comes out (since it 
still contains the crashes I mentioned before.

Gilboa, please go ahead and follow
http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure
and get this into cvs, so changes/bugs can be tracked.

(In reply to comment #51)
> beta3 should not be released as-is; there is more fixes in the SVN repo at
> http://websvn.kde.org/branches/extragear/kde3/pim/kdebluetooth that should 
be
> used, including what appears to be fixed for the kinputwizard crash.
> 

Nope, there is no such fix. I'm still encountering crashes even when using svn 
snapshots.

kinputwizard fix has gone into svn. 

Chitlesh,

If you look closely (at the history of the BZ) beta2 does not support blue-utils
>= 3.7 which more of less makes it useless for F7.
IMHO, while far from being perfect, b3 is good enough. It's usable.
Yes, it is beta, and clearly marked as such.
But distributing it as beta will help the developers get more bug reports, and
in the long term, get a (much) better kdebluetooth 1.0 release.

I see nothing wrong in releasing beta product to Fedora (especially if there's
no viable alternative), as long as it is clearly marked as such.

As for #58, WORKSFORME - I cannot seem to reproduce this problem. Bad build
environment?

* Sun Jul 15 2007 Gilboa Davara <gilboad[AT]gmail.com> 1-0.0-28.beta3
- Fix %%dist... again...

SPEC: http://gilboadavara.thecodergeek.com/kdebluetooth.spec
SRPM: http://gilboadavara.thecodergeek.com/kdebluetooth-1.0-0.28.beta3.fc7.src.rpm

- Gilboa

New Package CVS Request
=======================
Package Name: kdebluetooth
Short Description: The KDE Bluetooth Framework
Owners: gilboad
Branches: F-7
InitialCC: gilboad

FYI, build 29 disables PPC/PPC64 (obexftp missing).

Tada! (Closing, next-release.)

you have filed a bug for ppc missing obexftp?  added it to the arch tracker 
bug?

now that kdebluetooth is in i want to update kmobiletools  but I dont want to 
drop ppc support.

Help? HOWTO/FAQ?

- Gilboa

http://fedoraproject.org/wiki/Packaging/ReviewGuidelines?highlight=%28excludearch%29

Besides, obexftp is in the ppc tree for both Fedora 7 and devel.
http://download.fedora.redhat.com/pub/fedora/linux/releases/7/Everything/ppc/os/Fedora/obexftp-0.22-0.2.pre4.ppc.rpm
http://download.fedora.redhat.com/pub/fedora/linux/development/ppc/os/Fedora/obexftp-0.22-0.2.pre4.ppc.rpm

But the ppc64 is AWOL indeed.  There's no Exclu(de|sive)Arch in the obextftp
specfile - Dominik, ideas?

Thanks for the link(s).

Build 31 only excludes PPC64.
Missing PPC64 BZ [1] added to PPC64 tracker. [2].

- Gilboa
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250260
[2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FE-ExcludeArch-ppc64

FYI, kdebluetooth.fc7 has been pushed to update testing.
... BTW, is the -devel tree in test1 freeze?

- Gilboa

Are tools like kbtobexclient intentionally missing from the package?
I used that in the past and was very happy with it.
Am I supposed to use something else?
Thanks

Kai,

kbtobexclient seems to be broken (and disabled) by upstream.
Hopefully it'll be re-enabled in b4.

- Gilboa

kdebluetooth-1.0-0.31.beta3.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.

kdebluetooth-1.0-0.31.beta3.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.