RFS: blueman
Christopher Schramm
Hash: SHA1
Dear mentors,
I am looking for a sponsor for my package "blueman".
* Package name : blueman
Version : 1.02-1
Upstream Author : Valmantas Palikša <wal...@balticum-tv.lt>
* URL : http://blueman-project.org/
* License : GPL
Section : x11
It builds these binary packages:
blueman - A Graphical bluetooth manager
The package appears to be lintian clean.
The upload would fix these bugs: 517614
The package can be found on mentors.debian.net:
- - URL: http://mentors.debian.net/debian/pool/main/b/blueman
- - Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- - dget
http://mentors.debian.net/debian/pool/main/b/blueman/blueman_1.02-1.dsc
Since it's my very first Debian package, I guess there are a few things
to target before uploading.
First, I'm not sure whether blueman's python lib should get its own
package or not. I think no other piece of software will ever use it, so
I included it within the blueman package.
Second the version numbers mentioned in the dependencies are quite high
(from a Debian point of few). I took them directly from the upstream
author who's maintaining an Ubuntu package. Talking to him about that,
he said, blueman will run with earlier versions, but due to bug fixes he
won't guarantee that everything works fine. Personally I think the
dependencies version numbers can be lowered or even removed, but that'll
need some more intense testing.
In my eyes blueman could be a real deal for lightweight desktops.
Although the current dependencies look like it's a gnome piece of
software, the author targets to remove those dependencies. Version 1.02
did a first step making gconf optional.
Would be great if I could find a sponsor for that.
Kind regards
Christopher Schramm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmpu04ACgkQL/NpYV0RgSzVvwCcCgj/Lo6pNoWbfHAF3KLp/Qia
75oAn3aGrwHZ1PPoHO3vSiLLztTwO2Ab
=rYaf
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-ment...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Neil Williams
Christopher Schramm <deb...@shakaweb.org> wrote:
> I am looking for a sponsor for my package "blueman".
>
> It builds these binary packages:
> blueman - A Graphical bluetooth manager
Haven't we got quite a few of those already?
The RFS (and ITP) should explain why you want to add yet-another.
> In my eyes blueman could be a real deal for lightweight desktops.
gpe-bluetooth is designed for that kind of environment - how does this
one differ?
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Christopher Schramm
> On Sat, 28 Feb 2009 23:31:42 +0100
> Christopher Schramm <deb...@shakaweb.org> wrote:
>
>> In my eyes blueman could be a real deal for lightweight desktops.
>
> gpe-bluetooth is designed for that kind of environment - how does this
> one differ?
>
I'm not familiar with gpe-bluetooth, but the advantages of blueman are
obvious; gpe's description says it brings a file transfer interface and
PAN functionality. Beyond that blueman manages input and audio devices
and makes use of G3/EDGE/GPRS dial-up. And it brings it's own dialogues
for sending, receiving and browsing files. And it's nice looking too.
I don't know any other bluetooth manager that targets all those basic
bluetooth tasks (looking good doing so) and isn't bound to Gnome, KDE or
whatever other software suite. Not in Debian and not even anywhere else.
Of course I will accept if you can show me one I missed.
Jelle de Jong
> Neil Williams wrote:
>> On Sat, 28 Feb 2009 23:31:42 +0100
>> Christopher Schramm <deb...@shakaweb.org> wrote:
>>
>>> In my eyes blueman could be a real deal for lightweight desktops.
>> gpe-bluetooth is designed for that kind of environment - how does this
>> one differ?
>>
>
> I'm not familiar with gpe-bluetooth, but the advantages of blueman are
> obvious; gpe's description says it brings a file transfer interface and
> PAN functionality. Beyond that blueman manages input and audio devices
> and makes use of G3/EDGE/GPRS dial-up. And it brings it's own dialogues
> for sending, receiving and browsing files. And it's nice looking too.
>
> I don't know any other bluetooth manager that targets all those basic
> bluetooth tasks (looking good doing so) and isn't bound to Gnome, KDE or
> whatever other software suite. Not in Debian and not even anywhere else.
> Of course I will accept if you can show me one I missed.
>
>
This program looks nice, but I would like to see a very detailed
explanation how it difference and what the relation is with:
gpe-bluetooth
bluetooth-applet (gnome-bluez)
What for is policykit-gnome dependency exactly used?
I would like to see an GTK based bluetooth manager that is working very
close with bluez upstream and does not depend on gnome dependencies so it
will be usable on all gtk based desktops and embedded systems! So a
flexible configurable gui that also is GNOME Human Interface Guidelines
compliant would be nice.
Does the program has a command line only interface, i am missing command
line tools to pair successfully with all bluetooth devices.
Thanks in advance for the information,
Best regards,
Jelle de Jong
Christopher Schramm
> This program looks nice, but I would like to see a very detailed
> explanation how it difference and what the relation is with:
>
> gpe-bluetooth
> bluetooth-applet (gnome-bluez)
As mentioned (applies to bluez-gnome as well) - blueman brings audio,
input and dial-up support and some advanced features like access point
setup. Since supporting the basic PAN and file transfer features too,
blueman completely replaces bluez-gnome. The author tries very hard to
ensure compatibility.
> What for is policykit-gnome dependency exactly used?
For accessing the system settings. I hope future versions will introduce
another solution for that. As I said, the author promised to distance
from gnome and replace/remove some gnome dependencies, but that process
will take some time.
> Does the program has a command line only interface, i am missing command
> line tools to pair successfully with all bluetooth devices.
No. It's GTK only. I think bluez's own means include sufficient command
line tools (like hcitool). Don't they?
Christopher Schramm
Jelle de Jong
> Jelle de Jong wrote:
>> This program looks nice, but I would like to see a very detailed
>> explanation how it difference and what the relation is with:
>>
>> gpe-bluetooth
>> bluetooth-applet (gnome-bluez)
>
> As mentioned (applies to bluez-gnome as well) - blueman brings audio,
> input and dial-up support and some advanced features like access point
> setup. Since supporting the basic PAN and file transfer features too,
> blueman completely replaces bluez-gnome. The author tries very hard to
> ensure compatibility.
>
Would it not be better to improver bluez-gnome? or work with the
bluez-gnome developers and choice one project to officially support. I
think all the missing features that bluez-gnome does not bring will be on
the developers todo list for bluez-gnome. I am afraid for segmentation
and supplicated efforts. I have not seen any topic about blueman on the
official bluetooth-devel mailinglist. This said, I still thinks blueman
is a potentially great tool, but will my grandmother be able to use it to
connect there mouse and bluetooth speakers!
>> What for is policykit-gnome dependency exactly used?
>
> For accessing the system settings. I hope future versions will introduce
> another solution for that. As I said, the author promised to distance
> from gnome and replace/remove some gnome dependencies, but that process
> will take some time.
>
>> Does the program has a command line only interface, i am missing command
>> line tools to pair successfully with all bluetooth devices.
>
> No. It's GTK only. I think bluez's own means include sufficient command
> line tools (like hcitool). Don't they?
Nope there are no official command line tools for pairing, there is the
simple-agent.py script in the testing directory of the git source, but it
is not supported and does fails for most devices. good command line
paring tools are on my wish list.
Luca Niccoli
> Would it not be better to improver bluez-gnome? or work with the
bluez-gnome is... for gnome.
> Nope there are no official command line tools for pairing, there is the
> simple-agent.py script in the testing directory of the git source, but it
> is not supported and does fails for most devices. good command line
> paring tools are on my wish list.
While a command line tool is long needed, I don't see how a gtk tool
could be considered not useful.
As of now there isn't a single bluetooth suite that fits for people
that don't use Gnome or Kde.
This happens far too often, desktop-environment agnostic programs
should be the rule, not the exception.
As a Xfce user, more often left out in the cold than not, I would
greet with joy blueman.
Cheers,
Luca
Jelle de Jong
> 2009/3/1 Jelle de Jong <jelle...@powercraft.nl>:
>
>> Would it not be better to improver bluez-gnome? or work with the
>
> bluez-gnome is... for gnome.
>
>
>> Nope there are no official command line tools for pairing, there is the
>> simple-agent.py script in the testing directory of the git source, but it
>> is not supported and does fails for most devices. good command line
>> paring tools are on my wish list.
>
> While a command line tool is long needed, I don't see how a gtk tool
> could be considered not useful.
> As of now there isn't a single bluetooth suite that fits for people
> that don't use Gnome or Kde.
> This happens far too often, desktop-environment agnostic programs
> should be the rule, not the exception.
> As a Xfce user, more often left out in the cold than not, I would
> greet with joy blueman.
> Cheers,
>
> Luca
Not to make this a bikeshed topic, I do agree with you but I learned to
look at other aspects to like, maintainability, support, dependencies,
upstream, and development policy. bluez-gnome is just a name its not as
bad as it sounds, I am a heavy xfce user and supporter[1] too and
personally I think xfce sometimes uses to much decencies on there own
environment libs (reinventing the wheel) I respond to these mails because
good bluetooth support is very important for me and I care.
Since I compile and make testing .deb packages for bluez and gnome-bluez
almost monthly I can say the only gnome lookalike dependency for the
bluetooth-applet is libgconf2-dev, its really not that bad.
Remember about documentation for user and vendors that are going to use
and support bluetooth. How is this documentation to look like? Will this
be blueman? or the application provided with the environment. I would be
happy to see blueman replace gnome-bluez. It will be possible to make
compilation switches to make it work better on gtk only and gnome
environments.
So try to work something out with the original developers and see if
there can be one good gtk tool that can be used on gtk only and gnome
environment.
And yes good command-line tools if offtopic but I just wanted to mention
it because I will beg for them :-D I don't like create manual dbus
commands and read the source to make them to just pair a device!
Best regards,
Jelle de Jong
[1] https://secure.powercraft.nl/svn/packages/trunk/pictures/screenshots/
Christopher Schramm
> Would it not be better to improver bluez-gnome? or work with the
> bluez-gnome developers and choice one project to officially support. I
> think all the missing features that bluez-gnome does not bring will be on
> the developers todo list for bluez-gnome. I am afraid for segmentation
> and supplicated efforts.
I don't know what has been the initial reason for bluez-gnome.
Personally I don't think it's up to the bluez team to provide a GUI,
they should better have put the efforts in their command line tools, as
you remarked. In my eyes bluez-gnome is neither highly developed nor
necessary... ...and it's name is quite unfavorable. Maybe the bluez team
would quit bluez-gnome in favor of blueman since it's just superior (not
sure, but I wouldn't expect things in bluez-gnome that could be brought
to blueman, so a merge makes no sense), but that's up to them and not my
or the blueman upstream's cup of tea.
Of course Debian can quit support for bluez-gnome, but I wouldn't remind
that, since it's never a bad idea to give the user a choice and it's
somehow bound to the bluez package.
Anyway, whatever the right strategy to enhance (desktop independent)
bluetooth GUIs should be, blueman definitely brings many advantages and
outplays its alternatives so it has to be shown to developers and users.
I think it's absolutely reasonable to add it to Debian.
So I'm still looking for a sponsor! ;-)
Jelle de Jong
I agree this package is welcome in debian, somebody fancy to sponser?
I just read this:
http://www.hadess.net/2009/02/we-have-fork.html
hadess is one of the bluez developers and somehow they decided (without
any mails on the linux-bluetooth mailinglist) to start a fork of the
bluez-gnome and start gnome-bluetooth.
I have absolute no idea what the heck is going on here, so maybe its time
to start a new thread on the linux-b...@vger.kernel.org mailinglist.
There was a question: "What happened with bluez-gnome development?" on
the mailinglist but it was not answered.
Could you please start a good discussion on the linux-bluetooth
mailinglist, the list is for both users as developers.
Thanks in advance,
Jelle de Jong
Christopher Schramm
> I agree this package is welcome in debian, somebody fancy to sponser?
Since nobody was yet: Is there any problem with sponsoring the package?
George Danchev
> Jelle de Jong wrote:
> > I agree this package is welcome in debian, somebody fancy to sponser?
>
> Since nobody was yet: Is there any problem with sponsoring the package?
Hi,
It is not necessary for the package to have any technical or legal problems in
order to receive a sponsorship feedback, it generally means that it is quite
likely that nobody has found the time or sufficient interest to have a look
at it. As usual, a decent presentation of the package (especially its
advantages over already existing packages if any) may help a lot to find a
sponsor, and of course a purely deceptive or poor advertisement may even work
in the opposite direction ;-)
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
Patrick Matthäi
> Jelle de Jong wrote:
>> I agree this package is welcome in debian, somebody fancy to sponser?
>
> Since nobody was yet: Is there any problem with sponsoring the package?
>
I think I would sponsor it, if you fix the following things:
* Is there a need for a native package? I do not think so.
* debian/prerm seems to be useless at the moment, it should be removed
* debian/control:
- wraped lines are fine but I think you may fit them to a 80x terminal
size, at the moment it is a bit bloated in my eyes
- Standards-Version is out of date
- You are using debhelper, but you are not adding ${misc:Depends}
- (not tested) Are the replaces, conflicts with bluez-gnome *realy* needed?
- Some useless whitespaces at EOL.
* debian/copyright:
- You may add your own copyright for your packaging.
- There are much more different copyright holders for different files
which are not listed there, try it e.g. with grep -r Copyright *|sort|less
- There are also some more missing licenses (GPL3, GPL-2+, GPL-2) in
the package which are not mentioned in the debian/copyright file
* Package building:
The build FTBFS. You are build depending on libbluetooth-dev (>= 4.0)
but in unstable there is just version 3.36-1.
At all (also if the packages would build) it would be rejected by the
ftp-masters, because of the incomplete debian/copyright and useless
native package.
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: pmat...@debian.org
pat...@linux-dev.org
Comment:
Always if we think we are right,
we were maybe wrong.
*/
Christopher Schramm
> I think I would sponsor it, if you fix the following things:
Sure. :-)
> * Is there a need for a native package? I do not think so.
No. I just thought that would be the right thing to do, if there are no
changes in source. Changed it.
> * debian/prerm seems to be useless at the moment, it should be removed
You're right, I've missed that.
> - (not tested) Are the replaces, conflicts with bluez-gnome *realy* needed?
After some examination I think conflicts could be removed, but isn't
replaces a good thing?
> - There are much more different copyright holders for different files
> which are not listed there, try it e.g. with grep -r Copyright *|sort|less
> - There are also some more missing licenses (GPL3, GPL-2+, GPL-2) in
> the package which are not mentioned in the debian/copyright file
I see... And the all have to be put in debian/copyright? Isn't that
going to be a bit bloated?
> * Package building:
> The build FTBFS. You are build depending on libbluetooth-dev (>= 4.0)
> but in unstable there is just version 3.36-1.
I know. Blueman is an applet for bluez4, which has not yet made it to
Debian. I tried to find out who's working on that, but couldn't find any
of the related packages (libbluetooth-dev (>= 4.0), libbluetooth3,
bluez...) on WNPP.
Uploaded a new version. I think the only thing to target is the
copyright file.
Thanks for your help and possible sponsoring!
Patrick Matthäi
Hash: SHA1
Christopher Schramm schrieb:
> Patrick Matthäi wrote:
>> I think I would sponsor it, if you fix the following things:
>
> Sure. :-)
>
>> * Is there a need for a native package? I do not think so.
>
> No. I just thought that would be the right thing to do, if there are no
> changes in source. Changed it.
No, it should be also an non-native package and you should never made
changes to the source itself, just about a patchsystem (debian/patches/).
>
>> - (not tested) Are the replaces, conflicts with bluez-gnome *realy* needed?
>
> After some examination I think conflicts could be removed, but isn't
> replaces a good thing?
Could both packages are installed and used at the same time? Then it
would be wrong to add conflicts and replaces.
>
>> - There are much more different copyright holders for different files
>> which are not listed there, try it e.g. with grep -r Copyright *|sort|less
>> - There are also some more missing licenses (GPL3, GPL-2+, GPL-2) in
>> the package which are not mentioned in the debian/copyright file
>
> I see... And the all have to be put in debian/copyright? Isn't that
> going to be a bit bloated?
Yes, everything has to be in it, look e.g. at the package tork =>
debian/copyright, this is the realy hard part of Debian packaging ;-)
>
>> * Package building:
>> The build FTBFS. You are build depending on libbluetooth-dev (>= 4.0)
>> but in unstable there is just version 3.36-1.
>
> I know. Blueman is an applet for bluez4, which has not yet made it to
> Debian. I tried to find out who's working on that, but couldn't find any
> of the related packages (libbluetooth-dev (>= 4.0), libbluetooth3,
> bluez...) on WNPP.
Can I not be compiled and used with the current unstable one? If not the
package is not ready for sponsoring, yet, first it has to build correctly.
> Uploaded a new version. I think the only thing to target is the
> copyright file.
>
> Thanks for your help and possible sponsoring!
I will look in it, if you also fixed the other points, thanks.
- --
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: pmat...@debian.org
pat...@linux-dev.org
Comment:
Always if we think we are right,
we were maybe wrong.
*/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknyAhsACgkQ2XA5inpabMe9nwCdFaWVpMGffLBLTKR+o85l/+EA
WQAAniCH+R1qR6YhVVDlIQk/KHAz9EMS
=b+Mt
-----END PGP SIGNATURE-----
Ben Finney
> Christopher Schramm schrieb:
> > Patrick Matthäi wrote:
> >> - There are much more different copyright holders for different
> >> files which are not listed there, try it e.g. with grep -r
> >> Copyright *|sort|less
> >> - There are also some more missing licenses (GPL3, GPL-2+, GPL-2)
> >> in the package which are not mentioned in the debian/copyright file
> >
> > I see... And the all have to be put in debian/copyright? Isn't that
> > going to be a bit bloated?
>
> Yes, everything has to be in it, look e.g. at the package tork =>
> debian/copyright, this is the realy hard part of Debian packaging ;-)
Note, Christopher, that there is repeated [0] and ongoing [1] heated
discussion regarding this very point, and a DEP [2] which concerns it
closely.
There is vagueness in the Policy and significant disagreement among
developers over whether ‘debian/copyright’ actually needs to list all
the work's copyright holders and statements. Current practice in many
packages leans toward “no”, while actions of (some of?) the ftpmasters
leans toward “yes”.
I don't know which way this is going to resolve, but it's good to be
aware that the position Patrick espouses may or may not represent
consensus of the Debian project.
[0] <URL:http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html>
[1] <URL:http://lists.debian.org/debian-policy/2009/03/msg00302.html>
[2] DEP 5, <URL:http://dep.debian.net/deps/dep5/>
--
\ “If you ever reach total enlightenment while you're drinking a |
`\ beer, I bet it makes beer shoot out your nose.” —Jack Handey |
_o__) |
Ben Finney
Patrick Matthäi
Hash: SHA1
Ben Finney schrieb:
> There is vagueness in the Policy and significant disagreement among
> developers over whether ‘debian/copyright’ actually needs to list all
> the work's copyright holders and statements. Current practice in many
> packages leans toward “no”, while actions of (some of?) the ftpmasters
> leans toward “yes”.
>
> I don't know which way this is going to resolve, but it's good to be
> aware that the position Patrick espouses may or may not represent
> consensus of the Debian project.
Yes I am aware of the current discussion, but some (2?) packages have
been rejected in the last months because of an incomplete/missing
copyright holder listing. So it is `at the moment' better to include
them if you want to have an ACCEPT.
But I also want to see a good general consensus of it..
- --
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: pmat...@debian.org
pat...@linux-dev.org
Comment:
Always if we think we are right,
we were maybe wrong.
*/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAknzF4cACgkQ2XA5inpabMcXDQCgktIrpVc0OUziwB18JhHzC3Sz
1wEAoJH27DtlR9G+U2G/ygIMfyUpJk5V
=3/9D