Hello Marcel,
On Mon, Sep 04, 2006 at 02:11:52PM +0200, Marcel Holtmann wrote:
> > > > bluez-libs compiled out of the box by just unpacking and moving the
> > > > debian directory over, but bluez-utils needs some work:
> > > >
> > > > * remove bluez-bcm203x package (bcm203x firmware loader removed upstream)
> > >
> > > Not needed at all. You don't wanna support a 2.4 kernel and even if you
> > > really want to, you won't find any of these devices anymore. For all 2.6
> > > kernels the bcm203x kernel module takes care of loading the firmware.
> >
> > I'm going to drop it after etch release when we'll discontinue support for 2.4
> > kernels.
>
> You can drop it now actually. A Liunx 2.4 kernel user and owner of this
> device is a really really unlikely combination. I mean it. It would take
> me at least a couple of hours to find my dongle.
good luck with finding your dongle :)
anyway, as rare as it is etch is going to support 2.4 kernels.
>
> > > This package has to die and from an USB and udev perspective it was a
> > > really nasty hack.
> > >
> > > > * remove 000_rfcomm_conf_example.patch: the example is already commented
> > > > * remove 004_rfcomm_usage.patch: applied upstream
> > >
> > > Sometimes it is a good idea to feed patches back to upstream so I don't
> > > have to extract them from the packages.
> >
> > yep, I'm used to do it, I must have overlooked these patches.
>
> Do you have any other patches that are not upstream?
I'm looking at them one by one, bluez debian packages are maintained with svn.
You can browse the patches for bluez-utils at
http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/?rev=0&sc=0
you might be interested in:
http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/007_hcid_typo.patch?op=file&rev=0&sc=0
which fixes a small typo in hcid
http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/008_pand_man.patch?op=file&rev=0&sc=0
addition for pand manpage referring /etc/bluetooth/pan/dev-up execution
http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/006_xsims.patch?op=file&rev=0&sc=0
more compatible usage of test in bluetooth.init and hsplay
[snip]
> And please drop your passkey agent think completely. This will be
> distribution specific and can't be a solution. It is better to put the
> passkey-agent.c example in the docs directory as an example and mention
> it in a README.Debian.
>
> That said. I am missing a package for bluez-gnome which contains the
> graphical passkey agent. New version is coming up also this week. It
> will fix a small glitch with the status icon.
indeed, how about this plan:
- I will add to bluez-utils a default non-interactive passkey agent (more or less
like now but less hackish) which uses /etc/bluetooth/passkeys/<bt_addr> like
now
- bluez-gnome will provide the graphical passkey agent which takes over the
non-interactive one
Marcel: can agents be "stackable", that is, if two agents are registered and
first one doesn't supply an answer, the second will?
comments?
filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:
Age is not a particularly interesting subject. Anyone can get old. All
you have to do is live long enough.
-- Groucho Marx
Hi Stefan,
> > Let me put it this way. The 3.0 announcement came with a clear warning
> > that the PIN helper is dead and we now need a default passkey agent for
> > every desktop. It was one reason why I jumped to next major number. I
> > don't do this without a serious reason. I provided an example of a
> > passkey agent and the Maemo guys implemented a passkey agent for their
> > platform, but nobody else seemed to care.
>
> In the KDE case, i think that the kdebluetooth code is pretty much without
> an active maintainer. But i have a promising new talent at hand that will
> start fixing and bring it up to date :-)
sounds great. Please tell him that he should use the BlueZ D-Bus API
only. So a linking against libbluetooth is not an option anymore. This
will be the way we will go for the GNOME stuff, too.
Since I will travel tomorrow to Nuremberg for the Linux-Kongress, you
might wanna send him to my talk ;)
Regards
Marcel
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
On Tue, Sep 05, 2006 at 08:59:34PM +0200, Marcel Holtmann wrote:
> Hi Stefan,
> =
> > Well, that would mean that i'd have to document /var/lib/bluetooth/*/pi=
ncodes
> > and i'd want to avoid that.
> =
> you should avoid this when possible.
absolutely. This is why i'd rather provide passkey-agent as a band-aid :-)
> > snprintf(default_path, sizeof(default_path),
> > "/org/bluez/passkey_agent_%d", getpid());
> =
> That might do it. Of course every user must start this by hand and it is
> not automated somehow (init script or desktop startup). There can only
Yes. This is only for the "user has installed new openSUSE factory and now
wants to pair his device"-case. And now he even gets a warning that he shou=
ld
not build important parts of his enterprise infrastructure on the availabil=
ity
of passkey-agent :-)
> > Yes. But for the users, there is no way to pair their devices without a
> > passkey agent. And not everybody can use latest bluez-gnome, but might =
still
> > be a valuable tester for bluez-utils :-)
> =
> Let me put it this way. The 3.0 announcement came with a clear warning
> that the PIN helper is dead and we now need a default passkey agent for
> every desktop. It was one reason why I jumped to next major number. I
> don't do this without a serious reason. I provided an example of a
> passkey agent and the Maemo guys implemented a passkey agent for their
> platform, but nobody else seemed to care.
In the KDE case, i think that the kdebluetooth code is pretty much without
an active maintainer. But i have a promising new talent at hand that will
start fixing and bring it up to date :-)
> The passkey agent interface is fully language independent and they could
> have written one in C, C++, C#, Perl, Python, Java, Haskell and every
> language that provides a D-Bus binding. And again, nobody did. Now I
> gave people two examples on how to write a passkey agent. So they either
> do it now or start using GNOME ;)
There is already work being done for kdebluetooth, i have seen the
"prototype". But apparently the existing code is quite - "interesting"
and needs some cleanup before this can go out to the public.
Everything will be fine :-)
-- =
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N=FCrnberg | "Well, surrounding them's out." =
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easi=
er
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D1=
21642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Stefan,
> > > JFYI, i packaged the passkey-agent as-is for openSUSE factory and added a
> > > README, so the users can authenticate at all until the Desktop environments
> > > are ready. It might make sense to keep it IMO for all those people that do
> > > neither use gnome nor kde and still want to occasionally pair a rfcomm device,
> > > but maybe a multitude of easy to use passkey agents will pop up soon and
> > > we will have one for every taste :-)
> >
> > my advise would be to include passkey-agent.c in the docs section as an
> > example. This is how other packages do it and to make this really clear,
> > the passkey-agent.c is an example. It is _NOT_ meant for any regular
> > installation. This is the reason why it is marked as noinst_*.
>
> Well, that would mean that i'd have to document /var/lib/bluetooth/*/pincodes
> and i'd want to avoid that.
you should avoid this when possible.
> But i'll add this disclaimer to the passkey-agent and remove it from the
> package ASAP:
>
>
> Index: hcid/passkey-agent.c
> ===================================================================
> RCS file: /cvsroot/bluez/utils/hcid/passkey-agent.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 passkey-agent.c
> --- hcid/passkey-agent.c 28 Apr 2006 14:30:59 -0000 1.19
> +++ hcid/passkey-agent.c 5 Sep 2006 18:05:58 -0000
> @@ -284,6 +284,9 @@ int main(int argc, char *argv[])
> char match_string[128], default_path[128], *agent_path = NULL;
> int opt, use_default = 0;
>
> + printf("WARNING: passkey-agent is only a temporary solution. It will be removed from\n"
> + " the openSUSE package as soon as the desktop environments are ready.\n\n");
> +
> snprintf(default_path, sizeof(default_path),
> "/org/bluez/passkey_agent_%d", getpid());
That might do it. Of course every user must start this by hand and it is
not automated somehow (init script or desktop startup). There can only
be one default passkey agent.
> > If something is marked as noinst_* in bluez-utils, then it is either an
> > example, not ready yet or to risky for installation. If you can't get it
> > installed with a configure option, then it is _NOT_ meant to be.
>
> Yes. But for the users, there is no way to pair their devices without a
> passkey agent. And not everybody can use latest bluez-gnome, but might still
> be a valuable tester for bluez-utils :-)
Let me put it this way. The 3.0 announcement came with a clear warning
that the PIN helper is dead and we now need a default passkey agent for
every desktop. It was one reason why I jumped to next major number. I
don't do this without a serious reason. I provided an example of a
passkey agent and the Maemo guys implemented a passkey agent for their
platform, but nobody else seemed to care.
The passkey agent interface is fully language independent and they could
have written one in C, C++, C#, Perl, Python, Java, Haskell and every
language that provides a D-Bus binding. And again, nobody did. Now I
gave people two examples on how to write a passkey agent. So they either
do it now or start using GNOME ;)
Regards
Marcel
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
On Tue, Sep 05, 2006 at 07:13:19PM +0200, Marcel Holtmann wrote:
> Hi Stefan,
> =
> > JFYI, i packaged the passkey-agent as-is for openSUSE factory and added=
a
> > README, so the users can authenticate at all until the Desktop environm=
ents
> > are ready. It might make sense to keep it IMO for all those people that=
do
> > neither use gnome nor kde and still want to occasionally pair a rfcomm =
device,
> > but maybe a multitude of easy to use passkey agents will pop up soon and
> > we will have one for every taste :-)
> =
> my advise would be to include passkey-agent.c in the docs section as an
> example. This is how other packages do it and to make this really clear,
> the passkey-agent.c is an example. It is _NOT_ meant for any regular
> installation. This is the reason why it is marked as noinst_*.
Well, that would mean that i'd have to document /var/lib/bluetooth/*/pincod=
es
and i'd want to avoid that.
But i'll add this disclaimer to the passkey-agent and remove it from the
package ASAP:
Index: hcid/passkey-agent.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/bluez/utils/hcid/passkey-agent.c,v
retrieving revision 1.19
diff -u -p -r1.19 passkey-agent.c
--- hcid/passkey-agent.c 28 Apr 2006 14:30:59 -0000 1.19
+++ hcid/passkey-agent.c 5 Sep 2006 18:05:58 -0000
@@ -284,6 +284,9 @@ int main(int argc, char *argv[])
char match_string[128], default_path[128], *agent_path =3D NULL;
int opt, use_default =3D 0;
=
+ printf("WARNING: passkey-agent is only a temporary solution. It will be r=
emoved from\n"
+ " the openSUSE package as soon as the desktop environments=
are ready.\n\n");
+
snprintf(default_path, sizeof(default_path),
"/org/bluez/passkey_agent_%d", getpid());
=
> If something is marked as noinst_* in bluez-utils, then it is either an
> example, not ready yet or to risky for installation. If you can't get it
> installed with a configure option, then it is _NOT_ meant to be.
Yes. But for the users, there is no way to pair their devices without a
passkey agent. And not everybody can use latest bluez-gnome, but might still
be a valuable tester for bluez-utils :-)
I'll make sure that i get rid of it ASAP and then package the source file
in the documentation directory.
-- =
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N=FCrnberg | "Well, surrounding them's out." =
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easi=
er
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D1=
21642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Stefan,
> > > - I will add to bluez-utils a default non-interactive passkey agent (more or less
> > > like now but less hackish) which uses /etc/bluetooth/passkeys/<bt_addr> like
> > > now
> >
> > Doesn't make sense, because it is distro specific and you duplicate
> > functionality that is already present. Don't do this. This stuff must
> > die. I am serious about it.
>
> JFYI, i packaged the passkey-agent as-is for openSUSE factory and added a
> README, so the users can authenticate at all until the Desktop environments
> are ready. It might make sense to keep it IMO for all those people that do
> neither use gnome nor kde and still want to occasionally pair a rfcomm device,
> but maybe a multitude of easy to use passkey agents will pop up soon and
> we will have one for every taste :-)
my advise would be to include passkey-agent.c in the docs section as an
example. This is how other packages do it and to make this really clear,
the passkey-agent.c is an example. It is _NOT_ meant for any regular
installation. This is the reason why it is marked as noinst_*.
If something is marked as noinst_* in bluez-utils, then it is either an
example, not ready yet or to risky for installation. If you can't get it
installed with a configure option, then it is _NOT_ meant to be.
Regards
Marcel
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, Sep 05, 2006 at 01:07:31PM +0200, Marcel Holtmann wrote:
> Hi Filippo,
> > =
> > - I will add to bluez-utils a default non-interactive passkey agent (mo=
re or less
> > like now but less hackish) which uses /etc/bluetooth/passkeys/<bt_add=
r> like
> > now
> =
> Doesn't make sense, because it is distro specific and you duplicate
> functionality that is already present. Don't do this. This stuff must
> die. I am serious about it.
JFYI, i packaged the passkey-agent as-is for openSUSE factory and added a
README, so the users can authenticate at all until the Desktop environments
are ready. It might make sense to keep it IMO for all those people that do
neither use gnome nor kde and still want to occasionally pair a rfcomm devi=
ce,
but maybe a multitude of easy to use passkey agents will pop up soon and
we will have one for every taste :-)
-- =
Stefan Seyfried | "Please, just tell people
QA / R&D Team Mobile Devices | to use KDE."
SUSE LINUX Products GmbH, N=FCrnberg | -- Linus Torvalds
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easi=
er
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D1=
21642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Filippo,
> > > > > bluez-libs compiled out of the box by just unpacking and moving the
> > > > > debian directory over, but bluez-utils needs some work:
> > > > >
> > > > > * remove bluez-bcm203x package (bcm203x firmware loader removed upstream)
> > > >
> > > > Not needed at all. You don't wanna support a 2.4 kernel and even if you
> > > > really want to, you won't find any of these devices anymore. For all 2.6
> > > > kernels the bcm203x kernel module takes care of loading the firmware.
> > >
> > > I'm going to drop it after etch release when we'll discontinue support for 2.4
> > > kernels.
> >
> > You can drop it now actually. A Liunx 2.4 kernel user and owner of this
> > device is a really really unlikely combination. I mean it. It would take
> > me at least a couple of hours to find my dongle.
>
> good luck with finding your dongle :)
> anyway, as rare as it is etch is going to support 2.4 kernels.
your choice, but it is no longer part of bluez-utils.
> > > > This package has to die and from an USB and udev perspective it was a
> > > > really nasty hack.
> > > >
> > > > > * remove 000_rfcomm_conf_example.patch: the example is already commented
> > > > > * remove 004_rfcomm_usage.patch: applied upstream
> > > >
> > > > Sometimes it is a good idea to feed patches back to upstream so I don't
> > > > have to extract them from the packages.
> > >
> > > yep, I'm used to do it, I must have overlooked these patches.
> >
> > Do you have any other patches that are not upstream?
>
> I'm looking at them one by one, bluez debian packages are maintained with svn.
> You can browse the patches for bluez-utils at
> http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/?rev=0&sc=0
>
> you might be interested in:
>
> http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/007_hcid_typo.patch?op=file&rev=0&sc=0
> which fixes a small typo in hcid
>
> http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/008_pand_man.patch?op=file&rev=0&sc=0
> addition for pand manpage referring /etc/bluetooth/pan/dev-up execution
These two patches were already in the CVS.
> http://svn.debian.org/wsvn/pkg-bluetooth/bluez-utils/trunk/debian/patches/006_xsims.patch?op=file&rev=0&sc=0
> more compatible usage of test in bluetooth.init and hsplay
Added this one. This will get you down to two.
> > And please drop your passkey agent think completely. This will be
> > distribution specific and can't be a solution. It is better to put the
> > passkey-agent.c example in the docs directory as an example and mention
> > it in a README.Debian.
> >
> > That said. I am missing a package for bluez-gnome which contains the
> > graphical passkey agent. New version is coming up also this week. It
> > will fix a small glitch with the status icon.
>
> indeed, how about this plan:
>
> - I will add to bluez-utils a default non-interactive passkey agent (more or less
> like now but less hackish) which uses /etc/bluetooth/passkeys/<bt_addr> like
> now
Doesn't make sense, because it is distro specific and you duplicate
functionality that is already present. Don't do this. This stuff must
die. I am serious about it.
> - bluez-gnome will provide the graphical passkey agent which takes over the
> non-interactive one
Make sure you deprecate bluez-pin, because that one is no longer working
or even useful at all.
> Marcel: can agents be "stackable", that is, if two agents are registered and
> first one doesn't supply an answer, the second will?
The default passkey agent (like bt-applet) is not stackable. There
should be only one default passkey agent and that one should be provided
by the Desktop environment (like GNOME, KDE etc.). However you can have
multiple device specific agents for connection wizards or other
situations where you expect a PIN request.
Regards
Marcel
_______________________________________________
Pkg-bluetooth-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/pkg-bluetooth-maintainers