On Fre, 2013-08-16 at 19:31 +0200, Yamaban wrote:

On Fri, 16 Aug 2013 19:14, Dimstar / Dominique Leuenberger wrote: [snip]

...

So, we have the hard bullet to bite: either we update (Fedora decided to do so, see https://lists.fedoraproject.org/pipermail/devel/2013-August/187738.html for reference) or we accept to have a non-working BT stack in GNOME.

Updating it would likely still leave a few breakages here and there; but KDE's BlueDevil for example does have support in git.

The 2nd alternative would be to 'try to undo' the Bluez 5 porting in the GNOME Stack; No idea if and how well this will work; we would be the only distro with GNOME 3.10 running on Bluez 4.

+1 for upgrading to bluz5.

Why: it's more likely than not that bluez4 will be dropped upstream (no patches at all) during the OSS 13.1 support time.

Situation wrt support get's worse in view of the coming SLE 12.

Let's NOT get the foul apples in the new basket, nae?

Yes, making sure the depending apps and libs work IS hard work, but a dual stack is even worse, and a 'go-back' to bluez4 will hurt us more in the mid- and long-term.

Fedora has already done the most work, let's have look on what we can adopt wholesale of that.

Thanks for the support. Actually, Seife did a lot of work as well already it seems (See home:seife:bluez5). So it would be a matter of merging this back to Factory ASAP and finding all things still broken. And for sure it will be easier to find future fixes for old stuff breaking with bluez5 than for new stuff breaking with bluez4. Dominique -- Dimstar / Dominique Leuenberger -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fre, 2013-08-16 at 20:40 +0200, Stefan Seyfried wrote:

Am 16.08.2013 19:34, schrieb Dimstar / Dominique Leuenberger:

...

On Fre, 2013-08-16 at 19:31 +0200, Yamaban wrote:

...

...

Fedora has already done the most work, let's have look on what we can adopt wholesale of that.

Thanks for the support. Actually, Seife did a lot of work as well already it seems (See home:seife:bluez5).

Actually not. I just packaged bluez5 (in a now obsolete version), then found out that lots of stuff fails to build.

oh :) at least something... I have your bluez5 package on my machine.. works good so far.

Then I took the easy road out and added "--enable-library", to fix the build issues.

yes.. the library is considered obsolete and will disappear.. stuff that links it for now should probably make use of it.. the library API did not change; so that one is safe.

And then I got distracted.

shame

...

So it would be a matter of merging this back to Factory ASAP and finding all things still broken.

The only thing that might be useful is the bluez package from there and updating it to latest upstream version.

I see you just did that (my SR conflicted; I had 5.8 ready in a branch for you). so, THANKS! Dominique -- Dimstar / Dominique Leuenberger -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fre, 2013-08-16 at 14:50 -0300, Luiz Fernando Ranghetti wrote:

2013/8/16 Dimstar / Dominique Leuenberger :

...

On Fre, 2013-08-16 at 19:14 +0200, Dimstar / Dominique Leuenberger wrote:

...

Hi all,

I've just ran across an issue with Bluetooth in openSUSE 13.1; mainly, the GNOME Stack does not work with BlueZ 4.x anymore.

There are several components that have been ported to Bluez 5 already; and, as most of the stuff is not relying on the library (as this has been marked obsolete by upstream anyway), not much was seen prior to actually finding a BT device to pair it.

A quick addendum here: I just installed bluez 5.2 from home:seife:bluez5 and this brings back GNOME to live with Bluetooth.

So that confirms: bluez5 in home:seife:bluez5 works :) and GNOME knows how to handle it.

Dominique

Hi,

Few days ago someone from SUSE asked something similar on this list:

http://lists.opensuse.org/opensuse-factory/2013-08/msg00117.html (Fate 315090 > Upgrade to Bluez 5)

Yes, I know; but that was without the information that we actually already have code in the stack that would rely on it, but due to the fact that it's D-Bus activated does not expose build issues... So not having the new version only results in runtime issues (no pairing capabilities). Build Issues are so much easier to spot :) Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fre, 2013-08-16 at 14:46 -0400, Greg Freemyer wrote:

On Fri, Aug 16, 2013 at 1:14 PM, Dimstar / Dominique Leuenberger wrote:

...

Updating it would likely still leave a few breakages here and there; but KDE's BlueDevil for example does have support in git.

The 2nd alternative would be to 'try to undo' the Bluez 5 porting in the GNOME Stack; No idea if and how well this will work; we would be the only distro with GNOME 3.10 running on Bluez 4.

Any opinions around here?

Is it feasible to package both and have them conflict?

That way the gnome stack could require Bluez 5 and KDE Bluez 4?

Then have an obvious place in the installer that the user has to choose Bluetooth for Gnome vs. Bluetooth for KDE?

I can't say I like that, but it sounds better than shipping a half working KDE / Bluetooth implementation.

Also what about the rest of the desktops, is there any Bluetooth support and if so with which?

Greg, yes, that would be feasible, (just use virtual provides / requires for example). The big problem would be that you could not install KDE and GNOME on the same box.. a BIG leap backwards and surely not what we as openSUSE would want to achieve... We promote the 'free choice' not only at install time. I'm not sure in how far there is any integration of bluetooth stacks in lxde/xfce/E17.. somwewhat I assume they branched off gnome-bluetooth at early stages and forgot about it. I hope to be wrong. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fre, 2013-08-16 at 15:06 -0400, Greg Freemyer wrote:

To me, jumping to Bluez 5 exclusively for 13.1 just feels like its too late in the development cycle. To do that right would surely require another couple milestone releases.

Good thing, though, is we would not be alone: F20 does it as well (and they do have KDE in there as well.. incl. fixes). Ubuntu did not make the switch yet, but have GNOME 3.10 in the repositories for Saucy. So I'd guess bluetooth either does not work or they reverted patches to try to keep bluez4 alive.

<brainstorming> By using conflicting "Recommends:" statements, couldn't both Gnome and KDE be installable, but only one would have Bluetooth support?

'Conflicting Recommends'? you can recommend packages that do not exist; rpm does not care; only zypper / yast does... and if packages do not exist, they are skipped... after all, it's only recommendations.

Or, how hard would be to change the Bluez 5 namespace to not conflict. Then both could co-exist? <\brainstorming>

IF, then I'd rather recommend doing this on the obsolete base (moving bluez4 out of the way). The biggest issue, imho, is that it's runtime failures only, not buildtime... so anything relying on the bluez4 dbus api simply drips over... Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fre, 2013-08-16 at 15:21 -0400, Greg Freemyer wrote:

On Fri, Aug 16, 2013 at 3:12 PM, Dimstar / Dominique Leuenberger wrote:

...

'Conflicting Recommends'? you can recommend packages that do not exist; rpm does not care; only zypper / yast does... and if packages do not exist, they are skipped... after all, it's only recommendations.

I guess I meant something like:

Bluez4.spec Provides: Bluez4 Conflicts: Bluez5

Bluez5.spec Provides: Bluez5 Conflicts: Bluez4

Gnome.spec Recommends: Bluez5

KDE.spec Recommends: Bluez4

Then highlight it in the release notes that the user needs to choose between Bluez 4 and 5 and what that means.

note: I'm sure the above would need some sort UI changes somewhere to help the user know what's going on.

ok.. now I see what you mean; yes, this would work and yast would 'just' install the working stack on a clean install.. on an upgrade, though, bluzz4 will be there already (well, I doubt we would rename the existing package from bluez to bluez4) and as such, gnome updated systems would never have bluetooth (with manual intervention). For new systems, it would depend on factors like chosen DE at install time, paired with potentially other software you select during installation... Support-wise this sounds like a terrible thing to me; certainly worse than updating KDE BT stak to support it as well; of course, that leaves us with LXDE/XFCE/E17 and their potential implementations. I think it would be good if we could get voices from the respective DE maintainers and the bluez maintainer (ok, seife did already most of the prep work.. and he IS one of the bluez maintainers and did not sound completely opposing the idea). Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fre, 2013-08-16 at 15:44 -0400, Greg Freemyer wrote:

On Fri, Aug 16, 2013 at 3:27 PM, Dimstar / Dominique Leuenberger wrote:

...

I think it would be good if we could get voices from the respective DE maintainers and the bluez maintainer (ok, seife did already most of the prep work.. and he IS one of the bluez maintainers and did not sound completely opposing the idea).

I'll bow out of the discussion. I don't maintain anything that uses Bluez, so I become just a user. You have your finger on the pulse of the distro release process so you can make a better decision in regards to obsoleting Bluez 4 for 13.1 without adding in a milestone or 2.

I did not mean to 'shut you out of the discussion'. Your input is very welcome. My intention was mere to ADD the voices of the DE maintainers on top; We are not doing a distribution for the maintainers (only), but also for for our users.

To be honest, 12.3 seems pretty good to me, so delaying 13.1 to get a properly working Bluez 5 would be something I would vote for. Also Evergreen is likely to be based on 13.1 so having it be a solid release would be great.

Bluez5 is not 'new' anymore.. bluez 5.0 was released December 2012; and has since had a constant flow of releases, up to current 5.8; as such, I don't think delaying would be in anyway needed; also considering, that a maintenance update would not be impossible (remaining on one stack... adding bluez later on as maintenance update sounds like a very bad idea.) Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday 16 August 2013 21:58:55 Dimstar / Dominique Leuenberger wrote:

My intention was mere to ADD the voices of the DE maintainers on top; We are not doing a distribution for the maintainers (only), but also for for our users.

Hi Dominique. I just looked at the Fedora packages and it seems they just switched to the Bluez5 branch of libbluedevil/bluedevil. I will also try to check with upstream if this is working and what exactly the status is of this branch. I don't want to end up in a similar situation as the gstreamer-1.0 support for Phonon. :-) On the other hand, I will start testing Bluez5 and bluedevil to see if things are working or that we have some other issues there. However this covers only KDE and Gnome, but openSUSE offers also other DE's so we need also the input from them. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 16.08.2013 21:58, schrieb Dimstar / Dominique Leuenberger:

Bluez5 is not 'new' anymore.. bluez 5.0 was released December 2012; and has since had a constant flow of releases, up to current 5.8;

Yes, but nobody (besides some embedded systems) used it until now :-) -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 16.08.2013 21:27, schrieb Dimstar / Dominique Leuenberger:

of course, that leaves us with LXDE/XFCE/E17 and their potential implementations.

Since gnome dropped the standalone applet there is no support outside of gnome / KDE anymore. In theory there is blueman, but that has not gotten updates for the last 2 years worth of NetworkManager changes and surely is not bluez5 ready. And blueman is not in official openSUSE repos. cheers, seife -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday 16 August 2013 23:59:36 Dimstar / Dominique Leuenberger wrote:

So, that actually leaves GNOME (which is 'formally' moving to Bluez5) and KDE, which seems to have patches available.

Doesn't sound that bad.

Raymond: how are your tests going so far?

Hi Dominique, So far not really good. I get quite some crashes whenever I try to pair my laptop with my phone. Which results that bluedevil at a certain moment no longer sees the bluetooth adapter. As indicated already by you before, for KDE it only concerns the two bluedevil packages that needs to be validated and checked. Fedora is also using that branch without any particular patch, but they might have something on the bluez5 side. So testing continues and I didn't had a chance yet to talk to the bluedevil developer. Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday 16 August 2013 23:59:36 Dimstar / Dominique Leuenberger wrote:

So, that actually leaves GNOME (which is 'formally' moving to Bluez5) and KDE, which seems to have patches available.

Doesn't sound that bad.

Hi Dominique, I spoke with the upstream developer of bluedevil and he indicated that he needs to add Bluez5 support to Bluedevil for Fedora for their new version 20. In practice this means that he needs to have this finished latest by the end of september/first week of October (to be ready by the first beta release of Fedora 20). However an initial working version should be delivered beginning of September for the Alpha version of Fedora 20. The upstream developer indicated that he will start working on it this coming week, but he doesn't know when he will be completely finished. I will be tracking his progress by updates on the bluez5 branch of bluedevil and see if we have basic functionality or not. If we indeed have a working Bluedevil for Bluez5 by the beginning of October, then I guess this would go nice along the release of Gnome 3.10. With some optimism, I believe we could aim for Bluez5 support in 13.1 for both KDE and Gnome, however in case that Bluedevil is not ready, we should be able to have Bluez4 for KDE alongside Bluez5 for Gnome. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jeffrey Cheung wrote:

Hi Raymond and Dominique,

Actually we have fate https://fate.novell.com/315090 Upgrade to Bluez5.

Is that a novell restricted fate entry. I'm told I don't have rights to even view it. I didn't know anything in fate was restricted. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Sorry the previous link is for SUSE internal. Try this one >>> https://features.opensuse.org/315090 thanks, Jeffrey

...

...

在 10:40 下午 的 8/25/2013 的訊息 <521A175C.FC5 : 107 : 44874> 中，Jeffrey Cheung 寫入：

...

...

...

在 09:00 下午 的 8/25/2013 的訊息 <4d669d98-125f-46ca-985f-2d7ec8a47e63@email.android.com> 中，Greg Freemyer 寫入：

Jeffrey Cheung wrote:

...

Hi Raymond and Dominique,

Actually we have fate https://fate.novell.com/315090 Upgrade to Bluez5.

Is that a novell restricted fate entry. I'm told I don't have rights to even view it.

I didn't know anything in fate was restricted.

Let me try to resolve.

Jeffrey

...

Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

...

...

在 09:41 下午 的 8/25/2013 的訊息 <1377438068.1920.9.camel@laran.leuenberger.net> 中，Dimstar / Dominique Leuenberger 寫入：> On Son, 2013-08-25 at 06:39 -0600, Jeffrey Cheung wrote: Hi Raymond and Dominique,

Actually we have fate https://fate.novell.com/315090 Upgrade to Bluez5.

However, the status is that it was not ready for M4 of openSUSE 13.1 and thus no approve to move on.

In the same time, since SLE12 is far FCS date than openSUSE 13.1, Al Cho who is the main developer in SUSE will handle for SLE12 bluez5 update.

Jeffrey,

looking at where GNOME 3.10 is heading, we discuss as much as there is need for: but in the end, GNOME 3.10 will depend on BlueZ5;

As such, it's much better for us to switch sooner than later; and Raymond is doing the best job there is to get KDE in line with these requirements as well.

So, I would really recommend that we bite the bullet and push BlueZ5 to Factory ASAP!

OK, I will have AL Cho to work on asap.

The good thing: we won't be alone with this: Fedora 20 will have the same setup. So we can surely profit from each other there.

Yes, I know F20 will apply on Bluez5.

If we stay with Bluez4, then we have to be aware that for GNOME this might or might not work; surely, upstream support will not be given in this case. If you're planning to such tricks for SLE, I urge you to rethink such a plan.

Yes, this is why SLE12 ( not only the kernel team but also both desktop and L3 maintenance teams support ) go on Bluez5

Again, for openSUSE: BlueZ5 is mainly ready, the 'legacy API' needs to be enabled (which is done by Seife) and the stuff relying on the DBUS interface needs to be made aware of the new interface (not backwards compatible). It's a one-time pain we have to take now; or we split the pain over two releases.

Understood, since AL and I are at prague for conference and we will be back to office at Wed, I will have him to link and sync with you guys Very thanks of you and Raymond, Jeffrey

Cheers, Dominique -- Dimstar / Dominique Leuenberger

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi All, sorry for late to reply. On 二, 2013-09-03 at 13:35 +0200, Dominique Leuenberger a.k.a. Dimstar wrote:

Hi all,

...

...

looking at where GNOME 3.10 is heading, we discuss as much as there is need for: but in the end, GNOME 3.10 will depend on BlueZ5;

As such, it's much better for us to switch sooner than later; and Raymond is doing the best job there is to get KDE in line with these requirements as well.

So, I would really recommend that we bite the bullet and push BlueZ5 to Factory ASAP!

OK, I will have AL Cho to work on asap.

Al: did you already have some time here? How is it progressing?

Yes, I did , and I am testing and check bluez 5 functionally. My plan is submit first upgraded bluez 5 version package to openSUSE:Factory this Friday or Next. I am testing and checking for obex-data-server , obexd, obexfs, obexftp, openobex.

...

...

The good thing: we won't be alone with this: Fedora 20 will have the same setup. So we can surely profit from each other there.

Yes, I know F20 will apply on Bluez5.

Based on that: let's not invent all solutions ourselves; a lot of the issues have been fixed 'for us' already.

...

...

If we stay with Bluez4, then we have to be aware that for GNOME this might or might not work; surely, upstream support will not be given in this case. If you're planning to such tricks for SLE, I urge you to rethink such a plan.

Yes, this is why SLE12 ( not only the kernel team but also both desktop and L3 maintenance teams support ) go on Bluez5

Alignment is good.. let's make best use of it. And glad to see we talk in the same direction.

...

...

Again, for openSUSE: BlueZ5 is mainly ready, the 'legacy API' needs to be enabled (which is done by Seife) and the stuff relying on the DBUS interface needs to be made aware of the new interface (not backwards compatible). It's a one-time pain we have to take now; or we split the pain over two releases.

Understood, since AL and I are at prague for conference and we will be back to office at Wed, I will have him to link and sync with you guys

Very thanks of you and Raymond,

I am currently running bluez5 with a PulseAudio snapshot on my system. Seems to work 'ok' so far, but I only have very limited BT devices to perform any tests with.

Dominique

Cheers, AL -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Jeffrey, Am 25.08.2013 14:39, schrieb Jeffrey Cheung:

Hi Raymond and Dominique,

Actually we have fate https://fate.novell.com/315090 Upgrade to Bluez5.

However, the status is that it was not ready for M4 of openSUSE 13.1 and thus no approve to move on.

I was the one objecting the update. But then I did not know that there is already software using (even depending on) bluez5. My impression was that there is "no need to rush" for 13.1. And when I had looked last, there was no sign of fedora using bluez5 "soon". Now that these things have changed (GNOME 3.10 depends on bluez5, KDE will most likely be able to use it) and we won't be the first and only users of bluez5, I agree with Dominique's assessment that it probably is best to switch to the newer version and not mess around with the old stuff. (<rant> If only GNOME would have kept the standalone bluetooth-applet, this would be a total non-brainer since everyone could use it, but they are really trying to create vendor lock-in to their platform :-( </rant>)

In the same time, since SLE12 is far FCS date than openSUSE 13.1, Al Cho who is the main developer in SUSE will handle for SLE12 bluez5 update.

For SLES12 anything less than bluez5 is probably a bad ide :-) Best regards, and sorry for any confusion I might have caused with my previous rejection. Stefan -- Stefan Seyfried Linux Consultant & Developer -- GPG Key: 0x731B665B B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Aug 26, 2013 at 03:38:04PM +0200, Olav Vitters wrote:

On Sun, Aug 25, 2013 at 04:56:04PM +0200, Stefan Seyfried wrote:

...

(<rant> If only GNOME would have kept the standalone bluetooth-applet, this would be a total non-brainer since everyone could use it, but they are really trying to create vendor lock-in to their platform :-( </rant>)

We quite widely announced the drop of fallback mode. Why are you expecting us to support + develop something that is solely meant for other desktops?

Note that the code is out there, it just does not support Bluez 5 and it requires real development time. If some desktop wants a git.gnome.org account we can do that (code should be in a new repository though). At least two MATE developers e.g. have git.gnome.org accounts + ability to upload tarballs.

I'd really appreciate a reply. -- Regards, Olav -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Sep 09, 2013 at 11:22:25AM +0200, Stefan Seyfried wrote:

Well, what should I say. After gnome-bluetooth became the more or less "official" bluez desktop application, starting to restrict it to a single desktop seems to be a logical thing to if you want to create vendor lock-in.

It was not restricted. The change was announced. The code is out there.

Of course these engineering decisions are not mine and you are free to do whatever you want to, but so i am free to rant about it :-)

So GNOME should handle the development for XFCE? I think your expectations of what people should do are crazy. Be happy that we had something under GNOME that could be used by others. However, instead of appreciating for the time it could be used, you're ranting about it. Rant towards the people who should pick up the development. Until that time, no, you're not welcome to rant about this. Your expectations are unrealistic and not how things are done in free software. I find it terribly rude the way that you're blaming GNOME for what is the responsibility of *others*. You would be able to complain if this was a sudden change of direction. However, we widely announced it. All in all, your response has added nothing. -- Regards, Olav -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 30 October 2013 11:02:35 Ludwig Nussel wrote:

...

I will be tracking his progress by updates on the bluez5 branch of bluedevil and see if we have basic functionality or not. If we indeed have a working Bluedevil for Bluez5 by the beginning of October, then I guess this would go nice along the release of Gnome 3.10. With some optimism, I believe we could aim for Bluez5 support in 13.1 for both KDE and Gnome, however in case that Bluedevil is not ready, we should be able to have Bluez4 for KDE alongside Bluez5 for Gnome.

There are still people reporting bluetooth problems with KDE. What is the current state there?

Ludwig, At this moment there is no release of Bluedevil that supports Bluez5. We have some git-snapshots in KUSC for Bluedevil to support Bluez5, but we haven't seen any commits for the last two weeks anymore. The upstream author didn't released any preview, alpha or beta version for it yet and indicated also that he will not accept any bugreports on it. Before RC1, I spoke with Jos to indicate that KDE at this moment has a non- working Bluetooth setup due to Bluez5 and that we hopefully can fix that before the 13.1 Release. As far as I know he send that information out, but it doesn't make people actually read that information nor stopping them from registering bugs. In the past we had to take the decision to pull GNome back and patch it to make use of Bluez4 or to go forward with Bluez5 in the hope that KDE would catch up in time. It was impossible to have Bluez4 co-installable with Bluez5 and we saw more and more packages moving to Bluez5 support. Looking upstream than the main driver for supporting newer versions, seems to be the versions that Fedora is supporting. Not surprisingly as that there is quite a big number of Fedora people working on upstream KDE. The same will happen with the UPower 1.,0 change. API's have changed and Gnome 3.12 will require this new version, however KDE doesn't support UPower 1.0 (yet). So again we are looking at Fedora which indicated that they will make that change most likely sometime around April 2014.

PS: do we actually still have anyone who is taking care of monitoring the default KDE bug assignee alias (kde-maintainers@suse.de)?

That alias is something that the SuSE KDE team had set-up in the past and nobody from the current team is assigned to that alias. What we have done is that some of us have registered themselves to Hermes to receive emails whenever something happens for that email alias. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Ludwig Nussel [2013-10-30 12:50]:

Raymond Wooninck wrote:

...

On Wednesday 30 October 2013 11:02:35 Ludwig Nussel wrote:

...

PS: do we actually still have anyone who is taking care of monitoring the default KDE bug assignee alias (kde-maintainers@suse.de)?

That alias is something that the SuSE KDE team had set-up in the past and nobody from the current team is assigned to that alias. What we have done is that some of us have registered themselves to Hermes to receive emails whenever something happens for that email alias.

You mean makeing yourself a watcher of the alias (no Hermes involved there)? That's the correct thing to do I think. I'm not sure if anyone is actually receiving mails directly. If kde-maintainers@suse.de is no good solution to the current way of how the kde team works I'm sure it can be changed. How do other teams handle bugzilla team aliases?

The default assignee of bugs in the Xfce component is a mailing list (bnc-team-xfce@forge.provo.novell.com) to which I am a (or better the only :^) subscriber. I find that a bit cleaner than a dead address being watched through bugzilla but it achieves the same thing. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Raymond Wooninck wrote:

On Wednesday 30 October 2013 11:02:35 Ludwig Nussel wrote:

...

There are still people reporting bluetooth problems with KDE. What is the current state there?

The latest news from the Upstream developer is that he will do a sprint on it starting 11 of Nov. He hopes that it will be finished by the end of that week. Which would mean that we could have Bluez5 support for Bluedevil available (after some testing, etc) as of November 17.

This means that 13.1 has to be released without working Bluetooth support for KDE, but that we would be able to provide a maintenance update around the 17th. If we can count on the support of the Maintenance team, then we could have the update ready before the official release and that people could download the update directly after or during the installation.

Be aware that this is in the most optimistic schedule. At this moment we see that the basic support to recognize bluetooth adapters is working on one system, but not on the other.

Just to summarize what has been said on IRC, 13.1 will ship with the known regression of incomplete bluetooth support in KDE. A maintenance update will be provided ASAP when Bluedevil supports Bluez5. The release notes will document that. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 09 September 2013 11:10:14 Stefan Seyfried wrote:

...

Updating it would likely still leave a few breakages here and there; but KDE's BlueDevil for example does have support in git.

How's bluedevil coming along? Patches already in the package? If not, it would be useful to get them in before Beta1 :-))

At this moment we do not have patches yet for bluedevil, however the upstream maintainer started the job. I am not sure if we can make it before Beta 1, but I will keep an eye on it. As indicated before the upstream developer is following the Fedora 20 schedule. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 09.09.2013 11:30, schrieb Dominique Leuenberger a.k.a. Dimstar:

Hi Stefan,

Quoting Stefan Seyfried :

...

Hi Dominique,

There has been a deafening silence from coolo on this topic, so I just went ahead, abused my Base:System and multimedia:libs maintainer powers and accepted your SRs to Base:System. I also forwarded them to Factory

I fixed up the changelog a little bit on Andreas' request, so now sr#198131 and sr#198132 are on their way (198132 droprequest bluez-gstreamer which is no longer present/needed) -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Quoting Jeffrey Cheung :

+ dbus-glib-0.100.2 + ImageMagick-6.8.6-10 + gdk-pixbuf-2.28.2 + OpenOBEX-1.7.1

In beta 1 image, we have

+ dbus-1-glib 0.100.2-1.4 + ImageMagick-6.8.6.9-1.1 ( don't know if this version fit or not ) + libgdk_pixbuf_2_0-0 2.29.3-1.1 ( assume it is the good version ) + libopenobex-1.5-19.4 ( I think that we need openobex 1.7.1 )

Just want to know if we will update the openobex package in next release ?

That's definitively an oversight and needs to be fixed. I'll see what I can do for openobex.. Same as https://bugzilla.novell.com/show_bug.cgi?id=840845, where some reported crashes in PA. Any chance for you to throw an engineer at this one? Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

...

...

On 9/25/2013 at 04:58 PM, in message <20130925105815.Horde.xLnHJ9DnRHlSQqWn2BjlVXA@webmail.leuenberger.net>, "Dominique Leuenberger a.k.a. Dimstar" wrote:

Quoting "Dominique Leuenberger a.k.a. Dimstar" :

...

Quoting Jeffrey Cheung :

...

+ dbus-glib-0.100.2 + ImageMagick-6.8.6-10 + gdk-pixbuf-2.28.2 + OpenOBEX-1.7.1

In beta 1 image, we have

+ dbus-1-glib 0.100.2-1.4 + ImageMagick-6.8.6.9-1.1 ( don't know if this version fit or not ) + libgdk_pixbuf_2_0-0 2.29.3-1.1 ( assume it is the good version ) + libopenobex-1.5-19.4 ( I think that we need openobex 1.7.1 )

Just want to know if we will update the openobex package in next release ?

That's definitively an oversight and needs to be fixed. I'll see what I can do for openobex..

I built version 1.7.1 in my branch.. a bit messy, as most work seems to have gone into 'replacing autofoo with cmake' (aka one broken build system for another one).

Anyway: openobex 1.7.1 SRed to filesystem in SR#200517. Anybody willing / able to do some testing is highly appreciated.

Hi Dominique, Can you suggest how and what to test ? thanks, Jeffrey

Dominique

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi All, I test bluez5 with GNOME in 13.1 beta , and found bluetooth-send didn't work because obexd serivice is not enable in systemd, may we move obexd.service from /usr/lib/systemd/user/ to /usr/lib/systemd/system and add enable command in bluez.spec ? Cheers, AL On Thu, Sep 26, 2013 at 3:49 PM, Dominique Leuenberger a.k.a. Dimstar wrote:

Quoting Jeffrey Cheung :

...

...

Anyway: openobex 1.7.1 SRed to filesystem in SR#200517. Anybody willing / able to do some testing is highly appreciated.

Hi Dominique,

Can you suggest how and what to test ?

the 'how' is probably the easy part: Install openobex and related packages from the repository

https://build.opensuse.org/project/show/home:dimstar:branches:filesystems

The 'WHAT' is more difficult. There are various small tools. Frmo what I can see, OBEX is used for mounting 'BT device storage' (like phones) no a system...

so that might be an easy test to perform. (but I myself am not the maintainer of openobex or anything else in the BT stack :) )

Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org