Tone Kastlunger wrote:
> Strictly speaking, I don't see any problem with this - from a syncml
> client / server
> perspective; was the socket owned by the bluetooth manager also for bluez4
> as well?
No, the problem is with Qt5 - There was a totally different mechanism and
the service interface w
>These might be useful for another applications that may be using dbus, but
>not for the syncml code that relies solely on filedescriptors outside dbus.
Strictly speaking, I don't see any problem with this - from a syncml client
/ server
perspective; was the socket owned by the bluetooth manager a
Chris Adams wrote:
> Hi,
>
> (Sorry for top posting, OWA doesn't quote properly...)
>
> That old PR is actually mine, if you're referring to
> https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1
>
> I think it had some issues (e.g. didn't do UUID matching properly between
>
Damien Caliste wrote:
> Ah, I see, when looking at the page of your project
> (https://git.merproject.org/deloptes/bluez5_buteo-syncfw), it is not
> defined as fork from mer-core. I guess, you created a new project and
> push there from your computer. For Gitlab to know it's a fork, you have
> to
Damien Caliste wrote:
> Strange, when you visit the branch page of your project
> (https://git.merproject.org/deloptes/bluez5_buteo-syncfw/branches) do
> you see "merge request" button for each branch ? Is it still returning
> error 403 when you click on one ?
>
> Ah, I see, when looking at the p
Hello,
Le 2019-07-30 11:00, deloptes a écrit :
OK, thank you again. I read the documentation [1] and [2] now and tried
it
accordingly, but when I click the New merge request from
bluez5_buteo-syncfw it goes to a new page "403" saying " You don't have
the
permission to access this page.
Strang
Chris Adams wrote:
> Usually you don't push to the main repository, but instead you create a
> private fork of the repository, push your changes there (e.g. to
> deloptes_bluez5 branch or something) and then create a merge request from
> your private fork to the upstream repository.
>
> Then the
ubject: Re: [SailfishDevel] SyncML topic revived (further down the
rabbit hole)
Chris Adams wrote:
> Again sorry for top posting, using OWA which doesn't quote properly.
>
> It sounds like you're making good progress which is fantastic!
> Please tag me in any merge req
Chris Adams wrote:
> Again sorry for top posting, using OWA which doesn't quote properly.
>
> It sounds like you're making good progress which is fantastic!
> Please tag me in any merge requests (using @chriadam on github etc) so
> that I get notified of them, and then I can review etc.
>
> Best
Damien Caliste wrote:
> Hello,
>
> I guess that
> https://git.sailfishos.org/deloptes/poc-bluez5-buteo-syncml-plugins is a
> fork of buteo-sync-plugins with your changes. What about buteo-syncfw ?
>
> What client are you using on desktop side to test the plugin in phone ?
>
I attach a new patc
Tone Kastlunger wrote:
> I think it'd be important to add it next to bluez4 dbus stuff (and hence
> straightforward perhaps).
>
> I mean, adding bluez5 next to bluez4 support *might* just be easier (i.e.
> less changes) than moving to Y.A.L.
Bluez4 is beeing removed, but yes this is what I mean
>May be it is better using QDbus and not linking against kf5bluezqt and thus
>making buteo-syncfw depend on this library for couple of operations
>required to handle the sync profile.
I think it'd be important to add it next to bluez4 dbus stuff (and hence
straightforward perhaps).
I mean, adding
Damien Caliste wrote:
> What about buteo-syncfw ?
May be it is better using QDbus and not linking against kf5bluezqt and thus
making buteo-syncfw depend on this library for couple of operations
required to handle the sync profile.
I am still thinking about it and I'm not sure.
Let me know what
Chris Adams wrote:
> It sounds like you're making good progress which is fantastic!
> Please tag me in any merge requests (using @chriadam on github etc) so
> that I get notified of them, and then I can review etc.
>
Yes indeed, it works perfectly well. There are still some open questions and
bu
Damien Caliste wrote:
> Can you point out where did you push your modifications to buteo stack ?
> I would like to give a look and test.
>
> I guess that
> https://git.sailfishos.org/deloptes/poc-bluez5-buteo-syncml-plugins is a
> fork of buteo-sync-plugins with your changes. What about buteo-syn
Hello,
Le 2019-07-23 13:41, deloptes a écrit :
As my previous posts were not showing on the dev list, I write here to
test
if it works. In any case I'll be glad to receive some advises and
review on
the progress done.
What I did is to
- rebase btcalendar on current master and add late
rds,
Chris.
From: Devel [devel-boun...@lists.sailfishos.org] on behalf of deloptes
[delop...@gmail.com]
Sent: Tuesday, July 23, 2019 9:41 PM
To: devel@lists.sailfishos.org
Subject: Re: [SailfishDevel] SyncML topic revived (further down the rabbit
hole)
Chris Adams wr
Chris Adams wrote:
> Hi,
>
> (Sorry for top posting, OWA doesn't quote properly...)
>
> That old PR is actually mine, if you're referring to
> https://git.merproject.org/mer-core/buteo-sync-plugins/merge_requests/1
>
> I think it had some issues (e.g. didn't do UUID matching properly between
>
e IRC in .au timezone, or perhaps flypig or pvuorela
in .fi timezone).
Best regards,
Chris.
From: Devel [devel-boun...@lists.sailfishos.org] on behalf of Damien Caliste
[dcali...@free.fr]
Sent: Saturday, July 20, 2019 9:16 PM
To: devel@lists.sailfishos.org
Sub
Hello,
Le Samedi 20 juillet 2019, Tone Kastlunger a écrit :
> buteo-sync-plugin tho,
> so I suppose expectations for a more extensive changeset to be merged
> upstream should be kept low?
I'm afraid it's a question of poking. Submitter should ask for reason of
silence or rejection up to getting a
Theres a dangling mr pending for over a year (for calendar sync) in the
buteo-sync-plugin tho,
so I suppose expectations for a more extensive changeset to be merged
upstream should be kept low?
On Saturday, July 20, 2019, Damien Caliste wrote:
> Hello,
>
> Le Samedi 20 juillet 2019, deloptes a éc
Hello,
Le Samedi 20 juillet 2019, deloptes a écrit :
> 5. 1.7 uses cmake and thus building does not work
You can build cmake projects in SDK also. Sailfish-office is one example,
Calligra another one, while the latter is a bit complicated due to KF5
dependencies.
In a nutshell, ssh into SDK,
-
Chris Adams wrote:
> Hi,
>
> Yes, I suspect that the Buteo plugins weren't updated when the rest of the
> stack was upgraded to BlueZ 5.
> I assume that you can simply update the code in that repository to use the
> appropriate interfaces and APIs to begin the porting effort. I don't
> believe t
23 matches
Mail list logo
