%changelog
* Tue Mar 28 2006 Rex Dieter 1.0-0.8.beta1
- BR: kdepim-devel (for kitchensync)
- kdebluetooth-1.0_beta1-gcc41.patch

Spec Name or Url: http://apt.kde-redhat.org/apt/kde-redhat/SPECS/kdebluetooth.spec
SRPM Name or Url:
http://apt.kde-redhat.org/apt/kde-redhat/all/SRPMS.stable/kdebluetooth-1.0-0.8.beta1.src.rpm

%changelog
* Mon Apr 17 2006 Rex Dieter <rexdieter[AT]users.sf.net> 1.0-0.9.beta1
- konqueror bluetooth:/ returns error "Bad URL" (kde bug #123607)

Spec Name or Url:
http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/kdebluetooth-1.0-0.9.beta1.spec
SRPM Name or Url:
http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/kdebluetooth-1.0-0.9.beta1.src.rpm

Notable rpmlint messages:
  E: kdebluetooth zero-length /usr/share/icons/locolor/16x16/apps/khciconfig.png
  E: kdebluetooth zero-length /usr/share/icons/locolor/32x32/apps/khciconfig.png

The default hcid start/stop commands in the pairing dialog's file locations
could be fixed by eg. this (although I'm not certain whether they're too useful
in the first place):
  sed -i -e 's|/etc/init\.d/bluez-utils|/etc/init.d/bluetooth|' \
    kdebluetooth/kbluetoothd/kcm_btpaired/pairedtab.cpp
The default for the link key file isn't too useful either, but I don't know what
would be better as the location in FC varies depending on the device id as in
/var/lib/bluetooth/<deviceid>/linkkeys

gnome-bluetooth uses just "Application;System;" as the desktop entry categories
for the menu icons, whereas the "Network" category in kdebluetooth's ones place
the icons in "Internet".  Consider doing a s/Network/System/ in kdebluetooth?

The all-lowercase menu entry names look a bit silly and inconsistent with
everything else IMHO, how about something like these instead:
- kbluetoothd: Bluetooth Meta Server (or KBluetoothD)
- kbtobexclient: Bluetooth OBEX Object Push client (or KbtOBEXClient)
- kbtserialchat: Bluetooth Serial Chat (or KbtSerialChat)

libirmcsynckonnector.so should probably be in the main package, no?

Missing dependencies in -devel, from #includes in installed headers: qt-devel,
bluez-libs-devel

Spec Name or Url:
http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/kdebluetooth-1.0-0.11.svn20060619.spec
SRPM Name or Url:
http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/kdebluetooth-1.0-0.11.svn20060619.src.rpm

%changelog
* Mon Jun 19 2006 Rex Dieter <rexdieter[AT]users.sf.net> 1.0-0.11.svn20060609
- kdebluetooth-svn20060609, making most patches obsolete

* Fri Apr 28 2006 Rex Dieter <rexdieter[AT]users.sf.net> 1.0-0.10.beta1
- -devel: Requires: qt-devel bluez-libs-devel
- include libirmcsynckonnector.so in main pkg
- .desktop: --remove-category=Network --add-category=System
- remove zero length files
- fix default hcid start/top command

Created attachment 131146 [details]
Patch to include tarball recreation info

Based on the changelog the changes look fine, but please include information
how to recreate the tarball in the specfile, such as in the attached patch.  It
helps reviewers now and you in the future.

The tarball I get by executing the commands in the patch differs too much from
the one included in the SRPM for me to continue the review right now; please
consider submitting a new revision that contains sources in easier to reproduce
form.

Sounds good, will do.

Spec Name or Url:
http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/kdebluetooth-1.0-0.12.svn20060619.spec
SRPM Name or Url:
http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/kdebluetooth-1.0-0.12.svn20060619.src.rpm

%changelog
* Mon Jun 19 2006 Rex Dieter <rexdieter[AT]users.sf.net> 1.0-0.12.svn20060609
- document svn tarball creation
- Requires: kdebase (for kcm bits, applnk dir ownership)
- desktop-file-install --add-only-show-in=KDE

- Typo in configure options: s/dependan/dependen/

- obex.h patch seems spurious, configure runs pkg-config on openobex and
  retrieves -I/usr/include/openobex from there to CFLAGS

- With OnlyShowIn=KDE, running gtk-update-icon-cache doesn't sound too useful

- "|| :" at end of desktop-file-install should be removed (may cause 
  inconsistent builds or build failures), and the FIXME comment feels odd; if 
  you know that the .desktop files are not XDG compliant, why process them
  using an XDG tool using --delete-original and ignoring the errors?

- Unowned dir: /usr/share/applnk/Settings/Network

> obex.h patch seems spurious, configure runs pkg-config on openobex and
> retrieves -I/usr/include/openobex from there to CFLAGS

upstream openobex does -I/usr/include, fedora's has been patched (IMO wrongly)
to return -I/usr/include/openobex.  I've filed a bug against that,see bug
#186458 I'll make a note of that in the specfile.

> - With OnlyShowIn=KDE, running gtk-update-icon-cache doesn't sound too useful
It's usefulness (ever) is in question, in my mind... (see bug #170335)

> Re: desktop-file-install, FIXME
IMO, desktop-file-install needs to be fixed to ignore X- attributes (or at least
allow unicode and not just ascii) for which KDE uses them a lot.

> Unowned dir: /usr/share/applnk/Settings/Network
Dang, you must've snagged things before I fixed that.  (:

Entering "bluetooth:/" in konqueror results in "Malformed URL" and the browsing
doesn't work.  The patch at http://bugs.kde.org/show_bug.cgi?id=123607#c10
appears to fix it.

Spec Name or Url:
http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/kdebluetooth-1.0-0.13.svn20060620.spec
SRPM Name or Url:
http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/kdebluetooth-1.0-0.13.svn20060620.src.rpm

%changelog
* Tue Jun 20 2006 Rex Dieter <rexdieter[AT]users.sf.net> 1.0-0.13.svn20060620
- kdebluetooth-svn20060620, (re)fixes
  konqueror bluetooth:/ returns error "Bad URL" (kde bug #123607)
- --disable-dependancy-tracking
- own %%_datadir/applnk/Settings/Network

Spec Name or Url:
http://kde-redhat.unl.edu/apt/kde-redhat/SPECS/kdebluetooth-1.0-0.14.svn20060621.spec
SRPM Name or Url:
http://kde-redhat.unl.edu/apt/kde-redhat/all/SRPMS.stable/kdebluetooth-1.0-0.14.svn20060621.src.rpm

%changelog
* Wed Jun 21 2006 Rex Dieter <rexdieter[AT]users.sf.net> 1.0-0.14.svn20060621
- kdebluetooth-svn20060621, fixes
  compile error kdebluetooth libkobex obex.h not found (kde bug #94572)

Created attachment 131308 [details]
Sync menu entry names with window titles

The "dependancy" typo, unneeded update-gtk-icon-cache, and "|| :" at end of
desktop-file-install issues from comment 8 are still present (yes, I did read
comment 9), as well as the IMO silly Name values for some desktop entries from
comment 3.

Attached is a patch that syncs the Name values with whatever reads in the
corresponding app's window title when it's launched.  Other suggestions in
comment 3.

See also https://bugs.kde.org/show_bug.cgi?id=129594 for an RFE I just filed.

Perhaps I should wait and file a real bug report once this package is approved,
but I couldn't wait to get this up and running....

If you have selinux enabled, and tell hcid to use the kbluepin utility (as
bluez-pin doesn't work), selinux keeps kbluepin from running (expert from
audit.log below).  


type=AVC msg=audit(1151022663.716:63): avc:  denied  { execute_no_trans } for 
pid=3913 comm="sh" name="kbluepin" dev=sda3 ino=6324521
scontext=user_u:system_r:bluetooth_t:s0 tcontext=system_u:object_r:lib_t:s0
tclass=file
type=SYSCALL msg=audit(1151022663.716:63): arch=40000003 syscall=11 success=no
exit=-13 a0=9ee8840 a1=9ee8a88 a2=9ee8910 a3=9ee8618 items=1 pid=3913 auid=500
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="sh" exe="/bin/bash"
type=AVC_PATH msg=audit(1151022663.716:63):  path="/usr/lib/kdebluetooth/kbluepin"
type=CWD msg=audit(1151022663.716:63):  cwd="/"
type=PATH msg=audit(1151022663.716:63): item=0
name="/usr/lib/kdebluetooth/kbluepin" flags=101  inode=6324521 dev=08:03
mode=0100755 ouid=0 ogid=0 rdev=00:00

(In reply to comment #14)
> Perhaps I should wait and file a real bug report once this package is approved,
> but I couldn't wait to get this up and running....
> 
> If you have selinux enabled, and tell hcid to use the kbluepin utility (as
> bluez-pin doesn't work), selinux keeps kbluepin from running (expert from
> audit.log below).  
> 
> 
> type=AVC msg=audit(1151022663.716:63): avc:  denied  { execute_no_trans } for 
> pid=3913 comm="sh" name="kbluepin" dev=sda3 ino=6324521
> scontext=user_u:system_r:bluetooth_t:s0 tcontext=system_u:object_r:lib_t:s0
> tclass=file
> type=SYSCALL msg=audit(1151022663.716:63): arch=40000003 syscall=11 success=no
> exit=-13 a0=9ee8840 a1=9ee8a88 a2=9ee8910 a3=9ee8618 items=1 pid=3913 auid=500
> uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="sh" exe="/bin/bash"
> type=AVC_PATH msg=audit(1151022663.716:63):  path="/usr/lib/kdebluetooth/kbluepin"
> type=CWD msg=audit(1151022663.716:63):  cwd="/"
> type=PATH msg=audit(1151022663.716:63): item=0
> name="/usr/lib/kdebluetooth/kbluepin" flags=101  inode=6324521 dev=08:03
> mode=0100755 ouid=0 ogid=0 rdev=00:00

See if this helps:

# chcon -t bluetooth_helper_exec_t /usr/lib/kdebluetooth/kbluepin

Created attachment 131426 [details]
Exerpt from audit.log

(In reply to comment #15)
> 
> See if this helps:
> 
> # chcon -t bluetooth_helper_exec_t /usr/lib/kdebluetooth/kbluepin
> 

I don't know if helps is the word, but it's different.	Now audit.log is filled
with many more lines, which I've attached.  

PS - Thanks for looking at this.  I know very little about configuring selinux
(as everything else works out of the box).

(In reply to comment #16)
> Created an attachment (id=131426) [edit]
> Exerpt from audit.log
> 
> (In reply to comment #15)
> > 
> > See if this helps:
> > 
> > # chcon -t bluetooth_helper_exec_t /usr/lib/kdebluetooth/kbluepin
> > 
> 
> I don't know if helps is the word, but it's different.	Now audit.log is filled
> with many more lines, which I've attached.  
> 
> PS - Thanks for looking at this.  I know very little about configuring selinux
> (as everything else works out of the box).

I know a bit about about SELinux but unfortunately I know very little about
bluetooth. A quick glance at the attachment suggests that it's trying to look in
lots of directories (including /root, /var/spool/mail, /var/crash etc.) that I
really don't think it has any business looking in. What's it actually supposed
to do? Does it appear to work despite the SELinux denials?

(In reply to comment #17)
>
> I know a bit about about SELinux but unfortunately I know very little about
> bluetooth. A quick glance at the attachment suggests that it's trying to look in
> lots of directories (including /root, /var/spool/mail, /var/crash etc.) that I
> really don't think it has any business looking in. What's it actually supposed
> to do? Does it appear to work despite the SELinux denials?

kbluepin is just a tiny program that pops up a dialog asking for the bluetooth
pairing PIN, which the user enters in the dialog, and then spits out this pin on
stdout before exiting.  When running it as a normal user from the command line
it does exactly this, but that's useless.  In normal circumstances, the
bluetooth system (hcid) calls this program when a bluetooth device requests
pairing with a PIN, and no, as it is now, it doesn't work as it should, the
dialog doesn't appear, and the pairing eventually fails with a timeout (as it
doesn't know the PIN).  I agree, it is very odd that it is looking in so many
directories.  

(In reply to comment #18)
> kbluepin is just a tiny program that pops up a dialog asking for the bluetooth
> pairing PIN, which the user enters in the dialog, and then spits out this pin on
> stdout before exiting.  When running it as a normal user from the command line
> it does exactly this, but that's useless.  In normal circumstances, the
> bluetooth system (hcid) calls this program when a bluetooth device requests
> pairing with a PIN, and no, as it is now, it doesn't work as it should, the
> dialog doesn't appear, and the pairing eventually fails with a timeout (as it
> doesn't know the PIN).  I agree, it is very odd that it is looking in so many
> directories.  

Let's try a different approach. Put SELinux in permissive mode:
# setenforce 0

Then try it again (it should work)

See what SELinux denials are logged for this (after the setenforce).

Created attachment 131433 [details]
Exerpt from audit.log when selinux is disabled.

(In reply to comment #19)
> 
> Let's try a different approach. Put SELinux in permissive mode:
> # setenforce 0
> 
> Then try it again (it should work)
> 
> See what SELinux denials are logged for this (after the setenforce).

Duh, of course.  Ok, selinux non-enforcing, and everything works as expected
(dialog pops up, it pairs, and I can access data on my bluetooth phone).  

Attached is what audit.log logged during the whole process (from initiating
pairing until I can transfer files).

I'm not sure what the right approach to fixing this is. I can't find anything
that looks similar enough in the reference policy, so what I'd suggest it to
bring this up on fedora-selinux-list and ask for advice there.

What's the status of this submission?  It'd be great to have kdebluetooth
included soon.

Comment 13 does not seem to be addressed yet.

I'm unable to use SELinux in enforcing mode for various reasons at the moment
and I don't have a Rawhide setup available to test with its policy, so in case
nobody takes over review responsibility of this package from me (everyone's
welcome!), I'm afraid it'll take until some time after FC6 release until I can
promise to continue the review.  It's not entirely impossible earlier though.

I dug into this a little with rawhide selinux execution of kbluepin is  
blocked.  I didnt try messing around setting up a selinux policy to make it 
work

however i did discover that KDE is not running the things 
in /etc/xdg/autostart/ that its supposed to 
in /etc/xdg/autostart/bluez-pin.desktop it executes bluez-pin --dbus  which  
if i ran that  i got the default pin helper to work.

Rex, ping?  See comments 13, 22 and 23.

I'll get a chance to take a closer look at this sometime this week.

New ping. Rex, what is the status of this RR?

Yeah, been swamped with other stuff, and I was dreading treading into the
selinux ickiness.

I'll see about addressing at least the other issues, and update this soon.

I guess it's time to admit defeat here. ):

Frankly, I'm finding myself lacking the time (and motivation, since I currently
don't use bluetooth) to give this one the love and attention it deserves.

I'd like to hope that someone else with interest and motivation picks this up
where we left off.

Some "progress" here:
http://cachalot.mine.nu/6/SRPMS/kdebluetooth.spec
http://cachalot.mine.nu/6/SRPMS/kdebluetooth-1.0-0.15.beta2.cmn6.src.rpm

I can't get a PIN dialog, nor do I know how that stuff is supposed to work with
bluez 3.x (FC6) which I hear no longer supports pin helpers.  SELinux is
disabled, I suppose kbluepin is never executed, "bluez-pin --dbus" doesn't seem
to do anything either.

build fails on x86_64 FC-6  tryng to use i386 bits

g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../kdebluetooth -I/usr/include/kde -I/usr/lib64/qt-3.3/include -I.  -I/usr/include/xmms -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib64/glib/include    -DQT_THREAD_SUPPORT  -D_REENTRANT  -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION  -c -o 
maindialogbase.o maindialogbase.cpp
/bin/sh ../../libtool --silent --tag=CXX --mode=link 
g++  -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION    -o 
kbemusedsrv  -lkio -lkdeui -lxmms -lgtk -lgdk -lXi -lXext -lX11 -lm -lglib   -L/usr/lib -lbluetooth -L/usr/lib64/qt-3.3/lib -L/usr/lib64     
main.o kbemusedsrv.o controller.o xmmscontroller.o noatuncontroller.o 
amarokcontroller.o scriptscontroller.o dcopcall.o kurltableitem.o 
dcopinterface_skel.o maindialogbase.o 
logdialogbase.o ../libkbluetooth/libkbluetooth.la
/usr/lib/libkio.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status

It has always built fine for me mock/x86_64, but I don't ever remember seeing
any references to xmms either.  Are you building by hand or in mock?  If by
hand, you need to be careful to clean your x86_64 system of any i386 bits.

i built by hand.  ill see if i can reproduce in mock

builds fine in mock, will test today.

i could get a pin dialog using bluetooth-applet  and indeed pin helpers have 
gone away.  from what i can tell whats needed is to add dbus support to 
register and listen for pin requests. 

Just to clarify, did you test the package from comment 29?

Here's how Debian has apparently solved the pin dialog issue; doesn't look too
clean to me but anyway:
http://bugs.debian.org/383877
http://ftp.debian.org/debian/pool/main/k/kdebluetooth/kdebluetooth_0.99+1.0beta2-2.diff.gz

yes i used the package from comment 29   ill try with debian's patch 

What's the current status of kdebluetooth? Is it maintained? *

- Gilboa
* If not, I'm willing to take un-orphan it.

* Thu Mar 29 2007 Gilboa Davara <gilboad[AT]gmail.com> 1.0-0.19.beta2
- Spec file clean-up.

http://gilboadavara.thecodergeek.com/kdebluetooth-1.0-0.19.beta2..src.rpm
http://gilboadavara.thecodergeek.com/kdebluetooth.spec

I'm currently installing F7T3. Once I'm done, I'll rebuild the bluez package
with the proposed pin-helper patch. If all goes well, I'll submit the patch to
the bluez maintainer.

- Gilboa

The package in comment 38 seems to have discarded all changes made in the
package in comment 29 - I don't have time or interest at the moment to go
through all of them again so assigning to nobody@ for someone else to take over.

1. My mistake. I got mixed up by the different versions of kdebluetooth.
2. Mistake or not, posting rude comments have no business here.
3. Taking over the package.

If you're referring to comment 39, calm down, it was not meant to be rude at
all, just stating the fact and letting go of the review so others who may have
more time to look into this know it's time for them to chime in.  Anyway, looks
like it resulted in the desired outcome and there's a new reviewer.

OK.
Here's the problem.
Package went through way-too-many-hands I got completely mixed up by the history
of it.
I cannot review the package... simply because I'm trying to get it
submitted and reviewed. (Read: I followed the un-orphaning procedure and
assigned the bug to myself - forgetting that the package is yet-to-be-submitted).

In short, unless someone has any objections, I'll close this bug, open a new
one (with clean[er] history) and post a review-request.

- Gilboa

(In reply to comment #42)
> In short, unless someone has any objections, I'll close this bug, open a new
> one (with clean[er] history) and post a review-request.

Please clone the current bug, to keep at least the Cc list.

We'll do.
Again, my apologies for the noise.
(I'll just mark the "old" bug as a duplicate of the new bug)

- Gilboa

*** This bug has been marked as a duplicate of 235203 ***