This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 186452 - Review Request: kdebluetooth: The KDE Bluetooth Framework
Review Request: kdebluetooth: The KDE Bluetooth Framework
Status: CLOSED DUPLICATE of bug 235203
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gilboa Davara
Fedora Package Reviews List
: Reopened
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2006-03-23 12:34 EST by Rex Dieter
Modified: 2007-11-30 17:11 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-04 09:20:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to include tarball recreation info (882 bytes, patch)
2006-06-19 13:09 EDT, Ville Skyttä
no flags Details | Diff
Sync menu entry names with window titles (888 bytes, patch)
2006-06-21 14:24 EDT, Ville Skyttä
no flags Details | Diff
Exerpt from audit.log (13.20 KB, text/plain)
2006-06-23 08:52 EDT, Matthew Truch
no flags Details
Exerpt from audit.log when selinux is disabled. (14.94 KB, text/plain)
2006-06-23 10:08 EDT, Matthew Truch
no flags Details

  None (edit)
Description Rex Dieter 2006-03-23 12:34:34 EST
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.7.beta1.src.rpm
Description: 
The aim of this project is a tight and easy to use integration of Bluetooth
into the KDE desktop. You can manage your local Bluetooth devices and services
with it, browse your Bluetooth neighbourhood with konqueror and send and
receive files with just a few clicks.
Comment 1 Rex Dieter 2006-03-28 15:14:21 EST
%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
Comment 2 Rex Dieter 2006-04-17 15:48:30 EDT
%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
Comment 3 Ville Skyttä 2006-04-26 14:10:48 EDT
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
Comment 4 Rex Dieter 2006-06-19 10:49:49 EDT
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
Comment 5 Ville Skyttä 2006-06-19 13:09:04 EDT
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.
Comment 6 Rex Dieter 2006-06-19 13:15:17 EDT
Sounds good, will do.
Comment 7 Rex Dieter 2006-06-19 14:36:44 EDT
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
Comment 8 Ville Skyttä 2006-06-20 15:02:47 EDT
- 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
Comment 9 Rex Dieter 2006-06-20 15:11:22 EDT
> 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.  (:
Comment 10 Ville Skyttä 2006-06-21 01:49:40 EDT
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.
Comment 11 Rex Dieter 2006-06-21 05:52:08 EDT
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

Comment 12 Rex Dieter 2006-06-21 08:40:19 EDT
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)
Comment 13 Ville Skyttä 2006-06-21 14:24:32 EDT
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.
Comment 14 Matthew Truch 2006-06-22 20:40:11 EDT
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


Comment 15 Paul Howarth 2006-06-23 03:39:04 EDT
(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
Comment 16 Matthew Truch 2006-06-23 08:52:25 EDT
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).
Comment 17 Paul Howarth 2006-06-23 09:04:11 EDT
(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?
Comment 18 Matthew Truch 2006-06-23 09:45:06 EDT
(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.  
Comment 19 Paul Howarth 2006-06-23 09:48:45 EDT
(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).
Comment 20 Matthew Truch 2006-06-23 10:08:20 EDT
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).
Comment 21 Paul Howarth 2006-06-27 08:36:13 EDT
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.
Comment 22 Ville Skyttä 2006-08-23 14:52:12 EDT
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.
Comment 23 Dennis Gilmore 2006-09-25 09:46:10 EDT
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.
Comment 24 Ville Skyttä 2006-11-05 13:23:30 EST
Rex, ping?  See comments 13, 22 and 23.
Comment 25 Rex Dieter 2006-11-06 09:42:10 EST
I'll get a chance to take a closer look at this sometime this week.
Comment 26 Laurent Rineau 2006-12-12 08:04:08 EST
New ping. Rex, what is the status of this RR?
Comment 27 Rex Dieter 2006-12-14 09:43:07 EST
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.
Comment 28 Rex Dieter 2006-12-20 08:55:20 EST
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.

Comment 29 Ville Skyttä 2006-12-23 13:51:02 EST
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.
Comment 30 Dennis Gilmore 2007-01-26 08:43:57 EST
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
Comment 31 Rex Dieter 2007-01-26 08:48:00 EST
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.
Comment 32 Dennis Gilmore 2007-01-26 09:53:08 EST
i built by hand.  ill see if i can reproduce in mock
Comment 33 Dennis Gilmore 2007-01-26 11:52:56 EST
builds fine in mock, will test today.
Comment 34 Dennis Gilmore 2007-01-27 11:31:48 EST
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. 
Comment 35 Ville Skyttä 2007-01-27 12:05:29 EST
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
Comment 36 Dennis Gilmore 2007-01-27 13:59:16 EST
yes i used the package from comment 29   ill try with debian's patch 
Comment 37 Gilboa Davara 2007-03-21 11:29:09 EDT
What's the current status of kdebluetooth? Is it maintained? *

- Gilboa
* If not, I'm willing to take un-orphan it.
Comment 38 Gilboa Davara 2007-04-04 08:11:08 EDT
* 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
Comment 39 Ville Skyttä 2007-04-04 08:20:44 EDT
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.
Comment 40 Gilboa Davara 2007-04-04 08:40:30 EDT
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.
Comment 41 Ville Skyttä 2007-04-04 08:54:33 EDT
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.
Comment 42 Gilboa Davara 2007-04-04 09:20:00 EDT
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
Comment 43 Laurent Rineau 2007-04-04 09:26:29 EDT
(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.
Comment 44 Gilboa Davara 2007-04-04 09:29:59 EDT
We'll do.
Again, my apologies for the noise.
(I'll just mark the "old" bug as a duplicate of the new bug)

- Gilboa
Comment 45 Gilboa Davara 2007-04-04 10:19:51 EDT

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

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