Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 was removed in favor of profile. Anyway - the problem is even not there, but in the kf5bluezqt implementation of profile I guess. I was not looking further anymore. > If so, in this regard, there should be no change in responsibility for > the syncmlclient/server. > > About the KF5BluezQt, I totally agree - hoarding abstractions won't make > problems disappear; > I believe the extent of changes should be the driving force for the final > choice (i.e. the least complex > solution which requires the least changes). Less is more ;) > > Just my 2 cents. Thank you for the moral support. I do not know what is more or less. There are these 2-3 classes that need to be reworked anyway. I am happy with this POC for now, but I wish I had the time to do it in qt bluetooth now. The background is that I asked and Chris suggested to choose one and that kf5bluezqt was used in other projects. I did not know either qt5 bluetooth or kf5bluezqt. The latter seemed appealing and this is how I decided to use it. Then Chris mentioned @blam was more into bluetooth, who was sober reviewing the changes on buteo-syncfw and was wondering why I would use qt5 dbus instead kf5bluezqt. I am now convinced this was a good choice and I'll look forward to find the time and do a second PoC with qt5 bluetooth - just for the exercise. They offer QBluetoothSocket which seems to be more appropriate than a LocalSocket and perhaps also the low level c-style socket functions will disappear. I will not push a MR for now - will do the second PoC and we'll see. At the end we may end at DBus again :D regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
>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 also for bluez4 as well? If so, in this regard, there should be no change in responsibility for the syncmlclient/server. About the KF5BluezQt, I totally agree - hoarding abstractions won't make problems disappear; I believe the extent of changes should be the driving force for the final choice (i.e. the least complex solution which requires the least changes). Less is more ;) Just my 2 cents. On Sun, Aug 4, 2019 at 11:31 PM deloptes wrote: > 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 > > client and server, so it was more of an "import" rather than a true > "sync" > > IIRC), which is why it wasn't merged. Subsequent syncs might cause > > duplication, or changes might not be propagated properly, in one > direction > > or the other. I don't recall precisely. > > > > Going forward: my personal opinion is that if you can make the required > > changes to the stack to get everything working, we'd definitely like to > > integrate those changes, as it would ensure that we have more parts of > our > > stack up-to-date, and less dead-code. > > > > That said, at this stage I don't believe that it's high priority > > internally, so not sure how much time/effort sailors will be able to > spend > > helping with this effort, unfortunately. Definitely can review and test, > > but may not be able to help with active development day to day. But am > > always happy to discuss etc (ping chriadam on freenode IRC in .au > > timezone, or perhaps flypig or pvuorela in .fi timezone). > > > > Best regards, > > Chris. > > > > > Hi, so I finished updating and testing, but I feel miserable, because > KF5BluezQt was looking very promissing in the beginning and at the end it > turned out to be of no big advantage to pure Qt5 DBus. > I am not sure if I should not remove KF5BluezQt and write everything only > with Qt5 - despite @blam advocating how good KF5BluezQt is. > > The biggest advantage perhaps is that it initializes when the adapter setup > is completed, but - there seems to be always a but and here come the > disadvantages. > The first disadvantage is that in the background bluetooth is going through > all known devices and registering services that are known to have been > supported to each device. > So at the time I can access the adapter I still do not know if I have to > register the service or not. So if I restart msyncd while BT is on it > crashes like "BUG: scheduling while atomic: kworker/0:1/12981/0x0002". > There is no issue, when msyncd is restarted if BT is off, because the > application is down - nothing on DBus. > > The second big disadvantage of KF5BluezQt is the profile handling. It does > support many profiles, but not the syncml server and client and creating > own profile turned to be very hard, because the profile should handle a > socket/file descriptor, which turns out problematic because of using > QDBusUnixFileDescriptor and QSharedPointer in combination. > 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. > > For the moment the solution works fine, but in the area of the above I see > it as a work around over KF5BluezQt limitations. > It might be also me misinterpreting documentation or limited skills. > > The fact is I don't know what to do now. The time window I had for working > on this closes. The results are not bad - I can sync two most important - > contacts and calendar+todo like I was doing on the N9, but I wish I would > have the time to try Qt Bluetooth or go it directly via DBus. > > The question is to push or not to push :) > > Sorry for the long message, but I am not sure what to do next. I'll update > the PoC with what I have on the PC now. > > Ideas? > > regards > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 > client and server, so it was more of an "import" rather than a true "sync" > IIRC), which is why it wasn't merged. Subsequent syncs might cause > duplication, or changes might not be propagated properly, in one direction > or the other. I don't recall precisely. > > Going forward: my personal opinion is that if you can make the required > changes to the stack to get everything working, we'd definitely like to > integrate those changes, as it would ensure that we have more parts of our > stack up-to-date, and less dead-code. > > That said, at this stage I don't believe that it's high priority > internally, so not sure how much time/effort sailors will be able to spend > helping with this effort, unfortunately. Definitely can review and test, > but may not be able to help with active development day to day. But am > always happy to discuss etc (ping chriadam on freenode IRC in .au > timezone, or perhaps flypig or pvuorela in .fi timezone). > > Best regards, > Chris. > Hi, so I finished updating and testing, but I feel miserable, because KF5BluezQt was looking very promissing in the beginning and at the end it turned out to be of no big advantage to pure Qt5 DBus. I am not sure if I should not remove KF5BluezQt and write everything only with Qt5 - despite @blam advocating how good KF5BluezQt is. The biggest advantage perhaps is that it initializes when the adapter setup is completed, but - there seems to be always a but and here come the disadvantages. The first disadvantage is that in the background bluetooth is going through all known devices and registering services that are known to have been supported to each device. So at the time I can access the adapter I still do not know if I have to register the service or not. So if I restart msyncd while BT is on it crashes like "BUG: scheduling while atomic: kworker/0:1/12981/0x0002". There is no issue, when msyncd is restarted if BT is off, because the application is down - nothing on DBus. The second big disadvantage of KF5BluezQt is the profile handling. It does support many profiles, but not the syncml server and client and creating own profile turned to be very hard, because the profile should handle a socket/file descriptor, which turns out problematic because of using QDBusUnixFileDescriptor and QSharedPointer in combination. 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. For the moment the solution works fine, but in the area of the above I see it as a work around over KF5BluezQt limitations. It might be also me misinterpreting documentation or limited skills. The fact is I don't know what to do now. The time window I had for working on this closes. The results are not bad - I can sync two most important - contacts and calendar+todo like I was doing on the N9, but I wish I would have the time to try Qt Bluetooth or go it directly via DBus. The question is to push or not to push :) Sorry for the long message, but I am not sure what to do next. I'll update the PoC with what I have on the PC now. Ideas? regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 click on the fork button in the mer-core project page > (https://git.sailfishos.org/mer-core/buteo-syncfw). This will create a > new project under your login that is linked to mer-core. You can > directly push there since the local copy on your machine was cloned from > the mer-core one. So: > - click on fork in mer-core ; > - add a remote on your computer ; > - push to this new remote, then you can submit merge requests. > > Hope it helps, > > Damien. Damien, thank you for the help, really appreciated. I have a first win now. MR was created successfully. * Updated to use bluez5 !39 I will create one for the plugins next regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 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 click on the fork button in the mer-core project page > (https://git.sailfishos.org/mer-core/buteo-syncfw). This will create a > new project under your login that is linked to mer-core. You can > directly push there since the local copy on your machine was cloned from > the mer-core one. So: > - click on fork in mer-core ; > - add a remote on your computer ; > - push to this new remote, then you can submit merge requests. > > Hope it helps, Thank you, Damien. I think this might be the problem. First time always a fail :) I will check in the evening. regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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. 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 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 click on the fork button in the mer-core project page (https://git.sailfishos.org/mer-core/buteo-syncfw). This will create a new project under your login that is linked to mer-core. You can directly push there since the local copy on your machine was cloned from the mer-core one. So: - click on fork in mer-core ; - add a remote on your computer ; - push to this new remote, then you can submit merge requests. Hope it helps, Damien. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 MR will undergo review/testing etc until it's deemed ready for > merge and tag. 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. Please contact your GitLab administrator to get permission. " The URL is https://git.merproject.org/deloptes/bluez5_buteo-syncfw/merge_requests/new What can be this? Thank you in advance (for kickstarting) regards [1] https://git.sailfishos.org/help/user/project/merge_requests/index.md [2] https://docs.gitlab.com/ee/gitlab-basics/add-merge-request.html ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
Hi, 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 MR will undergo review/testing etc until it's deemed ready for merge and tag. Best regards, Chris. From: Devel [devel-boun...@lists.sailfishos.org] on behalf of deloptes [delop...@gmail.com] Sent: Monday, July 29, 2019 3:05 AM To: devel@lists.sailfishos.org Subject: Re: [SailfishDevel] SyncML topic revived (further downthe 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 requests (using @chriadam on github etc) so > that I get notified of them, and then I can review etc. > > Best regards, > Chris. > Hi, I think the work is done now. I asked how should I proceed, but no one responded. It looks like I do not have permissions or do not know something buteo-syncfw$ git push --set-upstream origin feat/bluez5v2 Username for 'https://git.merproject.org': deloptes Password for 'https://delop...@git.merproject.org': remote: You are not allowed to push code to this project. fatal: unable to access 'https://git.merproject.org/mer-core/buteo-syncfw.git/': The requested URL returned error: 403 Who can help? BTW buteo-sync-plugins is also ready https://git.sailfishos.org/deloptes/poc-bluez5-buteo-syncml-plugins I did not test Notes, but Contacts, Calendar and Tasks are working in terms that sync works. There are bugs I noticed in Contacts and Calendar, but I render them as not that critical and would open issues, when code is in place. My local setup is Phone Sailfish X with openobex 1.5.x. - I may test with jolla default version next I was just not sure if it works and new that it does with 1.5 Desktop TDE the tdepim plugins from Syncevolution sources Syncevolution 1.5.x Any plugin for Syncevolution - Gnome or KDE5 - would work, however I can not verify this. I think I tried Akonadi years ago For the setup I used the n900 template and the instructions on the Syncevolution web site. I run it like this SYCNEVOLUTION_DEBUG=3 syncevolution -r loglevel=6 xperiax addressbook calendar+todo Let me know what you think regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
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 requests (using @chriadam on github etc) so > that I get notified of them, and then I can review etc. > > Best regards, > Chris. > Hi, I think the work is done now. I asked how should I proceed, but no one responded. It looks like I do not have permissions or do not know something buteo-syncfw$ git push --set-upstream origin feat/bluez5v2 Username for 'https://git.merproject.org': deloptes Password for 'https://delop...@git.merproject.org': remote: You are not allowed to push code to this project. fatal: unable to access 'https://git.merproject.org/mer-core/buteo-syncfw.git/': The requested URL returned error: 403 Who can help? BTW buteo-sync-plugins is also ready https://git.sailfishos.org/deloptes/poc-bluez5-buteo-syncml-plugins I did not test Notes, but Contacts, Calendar and Tasks are working in terms that sync works. There are bugs I noticed in Contacts and Calendar, but I render them as not that critical and would open issues, when code is in place. My local setup is Phone Sailfish X with openobex 1.5.x. - I may test with jolla default version next I was just not sure if it works and new that it does with 1.5 Desktop TDE the tdepim plugins from Syncevolution sources Syncevolution 1.5.x Any plugin for Syncevolution - Gnome or KDE5 - would work, however I can not verify this. I think I tried Akonadi years ago For the setup I used the n900 template and the instructions on the Syncevolution web site. I run it like this SYCNEVOLUTION_DEBUG=3 syncevolution -r loglevel=6 xperiax addressbook calendar+todo Let me know what you think regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 - Y.A.L. In this case can be easily avoided. Unfortunately as you know bluez5 is different and code needs to be reworked. In the case of bueto-sync-plugins - I will stick to kf5bluezqt - it saves a lot of work. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
>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 bluez5 next to bluez4 support *might* just be easier (i.e. less changes) than moving to Y.A.L. Just my 2 cents. best, tk On Fri, Jul 26, 2019 at 7:54 PM deloptes wrote: > 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 you think. > > regards > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 you think. regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 bugs as you mentioned before that are only visible in the logs - but nothing critical. However I will ask in different thread or via gitlab - creating issues that can be followed up. I think it is more or less ready to become an official WIP MR now. Can someone instruct me on how to proceed with this from now on - are there rules, guides on creating MRs. I do not want to cause troubles and I am not a pro in git. - What is the best way to create a MR out of my PoC. I mean I have many commits for backup purposes in the PoC, which not necessarily need be pushed, but if I do a big single one - then the many changes forth and back are confusing. It should be a series of commits that one can easily review. - Should I create a new, or push on top of your MR? I build upon it, I think it makes sense to push on top. What do you, experts, do in such case? What is your advise? Thank you in advance regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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-syncfw ?
>
> What client are you using on desktop side to test the plugin in phone ?
>
Hi,
yes indeed - this is the link - I was just doing PoC and Tone asked to
share.
The buteo-syncfw is not uploaded anywhere. I guess I will push MR to the
original repo. I can only offer the attached patch for now.
regards
diff --git a/libbuteosyncfw/common/TransportTracker.cpp b/libbuteosyncfw/common/TransportTracker.cpp
index 35097ec..3cff6d8 100644
--- a/libbuteosyncfw/common/TransportTracker.cpp
+++ b/libbuteosyncfw/common/TransportTracker.cpp
@@ -32,6 +32,8 @@
#include
#include
+#include
+
using namespace Buteo;
TransportTracker::TransportTracker(QObject *aParent) :
@@ -65,16 +67,24 @@ TransportTracker::TransportTracker(QObject *aParent) :
#endif
// BT
-// Set the bluetooth state
-iTransportStates[Sync::CONNECTIVITY_BT] = btConnectivityStatus();
-if (!iSystemBus.connect("org.bluez",
-"",
-"org.bluez.Adapter",
-"PropertyChanged",
-this,
-SLOT(onBtStateChanged(QString, QDBusVariant
+// Initialize BluezQt
+btManager = new BluezQt::Manager(this);
+if (btManager != 0) {
+BluezQt::InitManagerJob *initJob = btManager->init();
+initJob->start();
+connect(initJob, ::InitManagerJob::result,
+this, ::initBluez5ManagerJobResult/*,
+Qt::QueuedConnection*/);
+LOG_DEBUG("BT manager init started");
+// wait to complete
+while (!btManager->isOperational())
+{
+QCoreApplication::processEvents(QEventLoop::AllEvents, 100);
+}
+}
+else
{
-LOG_WARNING("Unable to connect to system bus for org.bluez.Adapter");
+LOG_CRITICAL("BT manager init failed");
}
// Internet
@@ -97,6 +107,7 @@ TransportTracker::TransportTracker(QObject *aParent) :
TransportTracker::~TransportTracker()
{
FUNCTION_CALL_TRACE;
+
}
bool TransportTracker::isConnectivityAvailable(Sync::ConnectivityType aType) const
@@ -116,16 +127,24 @@ void TransportTracker::onUsbStateChanged(bool aConnected)
updateState(Sync::CONNECTIVITY_USB, aConnected);
}
-void TransportTracker::onBtStateChanged(QString aKey, QDBusVariant aValue)
+void TransportTracker::onBtStateChanged(bool aValue)
{
FUNCTION_CALL_TRACE;
-if (aKey == "Powered")
+if (aValue)
{
-bool btPowered = aValue.variant().toBool();
-LOG_DEBUG("BT power state " << btPowered);
-updateState(Sync::CONNECTIVITY_BT, btPowered);
+// If BT was enabled, give the framework 2sec to complete
+LOG_DEBUG("BT state changed" << aValue << "(sending update in 2sec)");
+QTime dieTime= QTime::currentTime().addSecs(2);
+while (QTime::currentTime() < dieTime)
+QCoreApplication::processEvents(QEventLoop::AllEvents, 100);
}
+else
+{
+// else update state immediately
+LOG_DEBUG("BT state update - new state:" << aValue );
+}
+updateState(Sync::CONNECTIVITY_BT, aValue);
}
void TransportTracker::onInternetStateChanged(bool aConnected, Sync::InternetConnectionType aType)
@@ -142,7 +161,6 @@ void TransportTracker::updateState(Sync::ConnectivityType aType,
{
FUNCTION_CALL_TRACE;
-
bool oldState = false;
{
QMutexLocker locker();
@@ -158,57 +176,39 @@ void TransportTracker::updateState(Sync::ConnectivityType aType,
}
}
-bool TransportTracker::btConnectivityStatus()
-{
-FUNCTION_CALL_TRACE;
+void TransportTracker::initBluez5ManagerJobResult(BluezQt::InitManagerJob* job) {
-bool btOn = false;
-QDBusMessage methodCallMsg = QDBusMessage::createMethodCall("org.bluez",
-"/",
-"org.bluez.Manager",
-"DefaultAdapter");
+FUNCTION_CALL_TRACE;
-QDBusMessage reply = iSystemBus.call(methodCallMsg);
-if (reply.type() == QDBusMessage::ErrorMessage)
-{
-LOG_WARNING("This device does not have a BT adapter");
-return btOn;
+if (job->error()) {
+LOG_CRITICAL("BT manager init error:" << job->errorText());
+return;
}
-QList adapterList = reply.arguments();
-// We will take the first adapter in the list
-QString adapterPath = qdbus_cast(adapterList.at(0)).path();
+// @todo do we need to act on btManager status change?
+//connect(btManager, ::Manager::operationalChanged,
+//this, ::onBtStateChanged);
+// Make sure to
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 latest changes - remove bluez4 from buteo-syncfw and buteo-sync-plugins - replace what needed with bluez5 and - had "a lot of fun" getting the plugins running. Now it works, but has few things to polish and of course to test. It will be indeed wonderful if someone could help with review and advise in the process. 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-syncfw ? What client are you using on desktop side to test the plugin in phone ? Thank you, Damien. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 regards, 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 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 > client and server, so it was more of an "import" rather than a true "sync" > IIRC), which is why it wasn't merged. Subsequent syncs might cause > duplication, or changes might not be propagated properly, in one direction > or the other. I don't recall precisely. > Do you mean the calendar part? We'll test for sure all of this before approaching you with MR. > Going forward: my personal opinion is that if you can make the required > changes to the stack to get everything working, we'd definitely like to > integrate those changes, as it would ensure that we have more parts of our > stack up-to-date, and less dead-code. > Thumbs up and fingers crossed! Thank you! > That said, at this stage I don't believe that it's high priority > internally, so not sure how much time/effort sailors will be able to spend > helping with this effort, unfortunately. Definitely can review and test, > but may not be able to help with active development day to day. But am > always happy to discuss etc (ping chriadam on freenode IRC in .au > timezone, or perhaps flypig or pvuorela in .fi timezone). 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 latest changes - remove bluez4 from buteo-syncfw and buteo-sync-plugins - replace what needed with bluez5 and - had "a lot of fun" getting the plugins running. Now it works, but has few things to polish and of course to test. It will be indeed wonderful if someone could help with review and advise in the process. Thank you in advance ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 > client and server, so it was more of an "import" rather than a true "sync" > IIRC), which is why it wasn't merged. Subsequent syncs might cause > duplication, or changes might not be propagated properly, in one direction > or the other. I don't recall precisely. > Do you mean the calendar part? We'll test for sure all of this before approaching you with MR. > Going forward: my personal opinion is that if you can make the required > changes to the stack to get everything working, we'd definitely like to > integrate those changes, as it would ensure that we have more parts of our > stack up-to-date, and less dead-code. > Thumbs up and fingers crossed! Thank you! > That said, at this stage I don't believe that it's high priority > internally, so not sure how much time/effort sailors will be able to spend > helping with this effort, unfortunately. Definitely can review and test, > but may not be able to help with active development day to day. But am > always happy to discuss etc (ping chriadam on freenode IRC in .au > timezone, or perhaps flypig or pvuorela in .fi timezone). 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 latest changes - remove bluez4 from buteo-syncfw and buteo-sync-plugins - replace what needed with bluez5 and - had "a lot of fun" getting the plugins running. Now it works, but has few things to polish and of course to test. It will be indeed wonderful if someone could help with review and advise in the process. Thank you in advance ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 client and server, so it was more of an "import" rather than a true "sync" IIRC), which is why it wasn't merged. Subsequent syncs might cause duplication, or changes might not be propagated properly, in one direction or the other. I don't recall precisely. Going forward: my personal opinion is that if you can make the required changes to the stack to get everything working, we'd definitely like to integrate those changes, as it would ensure that we have more parts of our stack up-to-date, and less dead-code. That said, at this stage I don't believe that it's high priority internally, so not sure how much time/effort sailors will be able to spend helping with this effort, unfortunately. Definitely can review and test, but may not be able to help with active development day to day. But am always happy to discuss etc (ping chriadam on freenode 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 Subject: Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole) 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 an answer. I agree it's not nice. But Pekka or Chris always gave answers to my MRs in the past. Sometimes rejecting them but always with reasons and after discussion. So for this case, we can be optimistic! Have a nice day, Damien. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 an answer. I agree it's not nice. But Pekka or Chris always gave answers to my MRs in the past. Sometimes rejecting them but always with reasons and after discussion. So for this case, we can be optimistic! Have a nice day, Damien. pgp3SZ8pHCtNx.pgp Description: OpenPGP digital signature ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 é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, > - go to ~/share/... the project directory, > - create a tmp directory and enter it, > - enter target emulation with 'sb2 -t Sailfishos-xxx' (use TAB to complement), > - issue 'cmake ..', > - issue make. > > You can automate this in a spec file to create RPMs of course. > >> To me it looks like the whole stack is left unmaintained and I am not sure >> how the following components are going to be brought to a working state >> without a proper support. I mean even if community can do the work, how big >> are the chances that all the changes in following packages get merged into >> mainstream??? > I'm coming back from vacations next week, and I can help you building everything or modernize what is required. I'm sure Chris Adams or Pekka Vuorela will review any patch and be happy to merge everything making the stack up to date, when patches look good. > > Have a nice day, > > Damien. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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, - go to ~/share/... the project directory, - create a tmp directory and enter it, - enter target emulation with 'sb2 -t Sailfishos-xxx' (use TAB to complement), - issue 'cmake ..', - issue make. You can automate this in a spec file to create RPMs of course. > To me it looks like the whole stack is left unmaintained and I am not sure > how the following components are going to be brought to a working state > without a proper support. I mean even if community can do the work, how big > are the chances that all the changes in following packages get merged into > mainstream??? I'm coming back from vacations next week, and I can help you building everything or modernize what is required. I'm sure Chris Adams or Pekka Vuorela will review any patch and be happy to merge everything making the stack up to date, when patches look good. Have a nice day, Damien. pgpkgYlNevKXa.pgp Description: OpenPGP digital signature ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived (further down the rabbit hole)
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 that we mean to keep BlueZ 4 support working, so no need to have > two separate codepaths with ifdefs depending on version, instead can just > port directly to BlueZ 5 APIs. > > The two repositories with code that will probably need to be updated are: > https://git.merproject.org/mer-core/buteo-syncfw/ > https://git.merproject.org/mer-core/buteo-sync-plugins/ > Hi Chris, all, this "you can simply update the code" turns out to be not so simple. Down the rabbit hole I hit on openobex. I am basically doing some analyses and PoC, so here are my findings 1. buteo-syncml and buteo-sync-plugins use openobex library 2. openobex library provided is openobex-0.1.4-1.2.1.jolla.armv7hl 3. on mer openobex is 1.7 4. in sailfish git reference is set to mer 5. 1.7 uses cmake and thus building does not work 6. in 1.7 significant change was done, so that all relaying code needs to be migrated/upgraded. On my desktop PC I still use 1.5.2 which seems to be stable and working with older applications 7. in sailfish git in rpm/openobex.yaml "Requires" is set to bluez-libs-devel, which breaks other dependencies. Why is it set to require bluez-libs-devel? IMO it should be removed put it all together this obex stuff that I desperately need for advancing on syncml is totally creepy. The way I go now is use openobex 1.5.2 which builds properly with sailfish. Please, let me know what you think and how this can be corrected for the future. To me it looks like the whole stack is left unmaintained and I am not sure how the following components are going to be brought to a working state without a proper support. I mean even if community can do the work, how big are the chances that all the changes in following packages get merged into mainstream??? - buteo-syncfw - buteo-syncml - buteo-sync-plugins - openobex Thank you in advance and kind regards PS: It is a pleasure to use the SDK - works smoothly :) ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Damien Caliste wrote: > Hello, > > Le Jeudi 11 juillet 2019, deloptes a écrit : >> > able to use the same credentials for all these services. >> >> Thank you Slava, but it does not work > Is it working logging in bugs.merproject.org ? If so, what is not working, > to log in git.sailfishos.org webpage or something else ? To push there, > you need to log on the website and add your public SSH key, I guess you > know. > Hi, I just wanted to mention that the issue with git was solved for me. In contrast to bugzilla it requires the username and not the e-mail as login. I bothered lbt again. Anyway I will be commiting first when I have something more solid but now all is settled for that case. Thanks and regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Hello, Le Jeudi 11 juillet 2019, deloptes a écrit : > > able to use the same credentials for all these services. > > Thank you Slava, but it does not work Is it working logging in bugs.merproject.org ? If so, what is not working, to log in git.sailfishos.org webpage or something else ? To push there, you need to log on the website and add your public SSH key, I guess you know. Have a nice day, Damien. > > Who can investigate? > > regards > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.or ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Slava Monich wrote: > AFAIK it's the same LDAP behind bugs.merproject.org and > git.merproject.org (or git.sailfishos.org these days), you should be > able to use the same credentials for all these services. Thank you Slava, but it does not work! Who can investigate? regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
On 22/06/2019 23:39, Tone Kastlunger wrote: Looks like merproject is closed. Hmm? Havent heard of this; it's available at git.sailfishos.org ; Yeah, don't panic! It's just a re-branding :) AFAIK old merproject.org credentials should work at sailfishos.org. At least mine did. Cheers, -Slava Hi, I am not sure if I got the right account from lbt - I got account for bugzilla (bugs.merproject.org) but I think I was supposed to get one for (https://git.merproject.org/mer-core/buteo-sync-plugins) Can someone tell if the former is correct and if yes how to proceed, if no - I'll have to chase lbt again on IRC. thanks AFAIK it's the same LDAP behind bugs.merproject.org and git.merproject.org (or git.sailfishos.org these days), you should be able to use the same credentials for all these services. Cheers, -Slava ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Slava Monich wrote: > On 22/06/2019 23:39, Tone Kastlunger wrote: >>> Looks like merproject is closed. >> Hmm? Havent heard of this; it's available at git.sailfishos.org ; > > Yeah, don't panic! It's just a re-branding :) > > AFAIK old merproject.org credentials should work at sailfishos.org. At > least mine did. > > Cheers, > > -Slava > Hi, I am not sure if I got the right account from lbt - I got account for bugzilla (bugs.merproject.org) but I think I was supposed to get one for (https://git.merproject.org/mer-core/buteo-sync-plugins) Can someone tell if the former is correct and if yes how to proceed, if no - I'll have to chase lbt again on IRC. thanks ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
deloptes kirjoitti sunnuntai 23. kesäkuuta 2019: > Tone Kastlunger wrote: > > > It's been Juhannus weekend in Finland (mid-summer), there's no way you > > will find anyone active on the > > irc :) > > Oh thanks I think I must be naive to some extent, because I last spoke > on Wednesday with two guys from Finland and they told me that Friday is > public holiday :D The mid-summer festival is the high point of the whole summer (the whole year for many) in Finland, so only the most hardcore coders are online! But the Friday is public holiday only for some professions, not for all. It also used to be always at June 21, but now it's always at the weekend. Also, huge thanks for all the effort you have put so far in SyncML! I hope you eventually finish the project and it gets merged! It's a feature I can personally live without, but for someone who needs it, it can be essential. Thank you so much! -- Matti Viljanen matti.vilja...@kapsi.fi Lähetetty Sailfish-laitteestani ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Tone Kastlunger wrote: > It's been Juhannus weekend in Finland (mid-summer), there's no way you > will find anyone active on the > irc :) Oh thanks I think I must be naive to some extent, because I last spoke on Wednesday with two guys from Finland and they told me that Friday is public holiday :D ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
It's been Juhannus weekend in Finland (mid-summer), there's no way you will find anyone active on the irc :) Try again tomorrow or send a pm I'd say. On Sun, Jun 23, 2019 at 2:34 AM deloptes wrote: > > Slava Monich wrote: > > > AFAIK old merproject.org credentials should work at sailfishos.org. At > > least mine did. > > I don't have any :) - looked yesterday and found the info - looked at IRC - > silence - went to bed. (I actually pinged sage and lbt but no one > answered.) > > > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Slava Monich wrote: > AFAIK old merproject.org credentials should work at sailfishos.org. At > least mine did. I don't have any :) - looked yesterday and found the info - looked at IRC - silence - went to bed. (I actually pinged sage and lbt but no one answered.) ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
On 22/06/2019 23:39, Tone Kastlunger wrote: Looks like merproject is closed. Hmm? Havent heard of this; it's available at git.sailfishos.org ; Yeah, don't panic! It's just a re-branding :) AFAIK old merproject.org credentials should work at sailfishos.org. At least mine did. Cheers, -Slava ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Tone Kastlunger wrote: > Hmm? Havent heard of this; it's available at git.sailfishos.org ; > You will have to ping lbt on irc to get an accoutn tho (as per > instructions on the > website "In the meantime, to get an account please contact lbt or sage > on #sailfishos on freenode IRC." ) Yes, I read this, but I am not sure if I catch them on irc. I will try for sure cause buteo-syncfw changes are worth revising. Looking further into buteo-sync-plugins 1st btcalendarsync branch needs to catch up with master 2nd the BT part needs to be reworked. 3rd in kf5bluezqt there are no profiles for syncml But this seems to be the path ATM. On 2 I am not sure if completely or partially. I played last year with org.bluez.obex.FileTransfer1 from bluez 5 on the desktop. It is very simple to create a session and access the device, compared to the code in buteo-sync-plugins. I am tempted to start this part from scratch for the plugins. It could be also a different project name. 3 means the profiles need to be created and tested. This is how far I am ATM. Looks like a lot of work BTW what software are you using for syncing? I was using syncevolution with KDE3 now TDE for the past 7-8y. Has someone tried USB it seems it should be working. I need to check if syncevolution supports this. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
> Looks like merproject is closed. Hmm? Havent heard of this; it's available at git.sailfishos.org ; You will have to ping lbt on irc to get an accoutn tho (as per instructions on the website "In the meantime, to get an account please contact lbt or sage on #sailfishos on freenode IRC." ) On Sat, Jun 22, 2019 at 6:14 PM deloptes wrote: > > Tone Kastlunger wrote: > > > Any source / patch available? > > would be awesome to test it, have some contacts lingering in my Jolla > > phone.. > > Hi, > as mentioned only fist part is kind of done. Second part is still to be > done, but will take time as I have only ~1-2h/day free time. > > So far as mentioned the buteo-syncfw was patched. It seems buteo-syncml did > not need any modifications, but I was looking since yesterday in > buteo-sync-plugins and it looks like more work will be required there. In > worst case couple of (complex) things need to be rewritten. An advice or > discussion would be good. > I would also enjoy sharing the code (and hopefully the work), but I do not > know where to upload. Looks like merproject is closed. > I was going to ask this anyway, so thank you in advance for the response. > Also establishing a communication channel on the subject is good idea IMO. > There are things I do not understand fully. > > regards > > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Tone Kastlunger wrote: > Any source / patch available? > would be awesome to test it, have some contacts lingering in my Jolla > phone.. Hi, as mentioned only fist part is kind of done. Second part is still to be done, but will take time as I have only ~1-2h/day free time. So far as mentioned the buteo-syncfw was patched. It seems buteo-syncml did not need any modifications, but I was looking since yesterday in buteo-sync-plugins and it looks like more work will be required there. In worst case couple of (complex) things need to be rewritten. An advice or discussion would be good. I would also enjoy sharing the code (and hopefully the work), but I do not know where to upload. Looks like merproject is closed. I was going to ask this anyway, so thank you in advance for the response. Also establishing a communication channel on the subject is good idea IMO. There are things I do not understand fully. regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Any source / patch available? would be awesome to test it, have some contacts lingering in my Jolla phone.. On Fri, Jun 21, 2019 at 12:58 PM deloptes wrote: > > Tone Kastlunger wrote: > > > Finally we might get contacts sync via BT \o/ > > > > Good luck warrior! > > > > tortoisedoc > > God heard your prayers > > [14646]: [D] unknown:0 - BT adapter state powered: true > [14646]: [D] unknown:0 - Starting server plug-in: "syncml" > [14646]: [D] unknown:0 - Starting oop plugin "syncml" > [14646]: [D] unknown:0 - Starting > process "/usr/lib/buteo-plugins-qt5//oopp/syncml-server" with plugin > name "syncml" and profile name "syncml" > syncml-server[16368]: [D] unknown:0 - BT manager init started > syncml-server[16368]: [D] unknown:0 - New network state: true New > type: "WLAN" ( 2 ) > syncml-server[16368]: [D] unknown:0 - Network status: > syncml-server[16368]: [D] unknown:0 - Online:: true > syncml-server[16368]: [D] unknown:0 - Connection:: 2 > syncml-server[16368]: [D] unknown:0 - attempting to register dbus > service: "com.buteo.msyncd.plugin.syncml" > syncml-server[16368]: [D] unknown:0 - Plugin "syncml" with > profile "syncml" registered at dbus "com.buteo.msyncd.plugin.syncml" > and path / > syncml-server[16368]: [D] unknown:0 - BT default adapter > path: "/org/bluez/hci0" > syncml-server[16368]: [D] unknown:0 - BT default adapter name: "Xperia X" > syncml-server[16368]: [D] unknown:0 - BT manager init done > > this is after going through buteo-syncfw and buteo-syncml. The latter did > not need any changes, but I recompiled it just to be on the safe side. > > There will be some work with the actual plugins, but hopefully not much. > > regards > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Tone Kastlunger wrote: > Finally we might get contacts sync via BT \o/ > > Good luck warrior! > > tortoisedoc God heard your prayers [14646]: [D] unknown:0 - BT adapter state powered: true [14646]: [D] unknown:0 - Starting server plug-in: "syncml" [14646]: [D] unknown:0 - Starting oop plugin "syncml" [14646]: [D] unknown:0 - Starting process "/usr/lib/buteo-plugins-qt5//oopp/syncml-server" with plugin name "syncml" and profile name "syncml" syncml-server[16368]: [D] unknown:0 - BT manager init started syncml-server[16368]: [D] unknown:0 - New network state: true New type: "WLAN" ( 2 ) syncml-server[16368]: [D] unknown:0 - Network status: syncml-server[16368]: [D] unknown:0 - Online:: true syncml-server[16368]: [D] unknown:0 - Connection:: 2 syncml-server[16368]: [D] unknown:0 - attempting to register dbus service: "com.buteo.msyncd.plugin.syncml" syncml-server[16368]: [D] unknown:0 - Plugin "syncml" with profile "syncml" registered at dbus "com.buteo.msyncd.plugin.syncml" and path / syncml-server[16368]: [D] unknown:0 - BT default adapter path: "/org/bluez/hci0" syncml-server[16368]: [D] unknown:0 - BT default adapter name: "Xperia X" syncml-server[16368]: [D] unknown:0 - BT manager init done this is after going through buteo-syncfw and buteo-syncml. The latter did not need any changes, but I recompiled it just to be on the safe side. There will be some work with the actual plugins, but hopefully not much. regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Chris Adams wrote: > Hi, > > Hmm, I'm not sure. When I enter scratchbox2 target build terminal, I see > KF5BluezQt.pc in /usr/lib/pkgconfig so I assume that: > > CONFIG+=link_pkgconfig > PKGCONFIG+=KF5BluezQt > > should work. But if that doesn't work for you, I'm not sure... > > I just checked some internal projects, they have: > > BuildRequires: pkgconfig(KF5BluezQt) > > in .spec file, and: > Hi, Adding following to the spec file solved the problem BuildRequires: pkgconfig(KF5BluezQt) thank you ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Hi,
Hmm, I'm not sure. When I enter scratchbox2 target build terminal, I see
KF5BluezQt.pc in /usr/lib/pkgconfig so I assume that:
CONFIG+=link_pkgconfig
PKGCONFIG+=KF5BluezQt
should work. But if that doesn't work for you, I'm not sure...
I just checked some internal projects, they have:
BuildRequires: pkgconfig(KF5BluezQt)
in .spec file, and:
PKGCONFIG += KF5BluezQt
in .pro file.
Maybe double check that your sdk target has the appropriate devel packages
installed, and that you can see the .pc file in the /usr/lib/pkgconfig dir from
within the sb2 build terminal.
Best regards,
Chris.
From: Devel [devel-boun...@lists.sailfishos.org] on behalf of deloptes
[delop...@gmail.com]
Sent: Monday, June 17, 2019 5:02 PM
To: devel@lists.sailfishos.org
Subject: Re: [SailfishDevel] SyncML topic revived
Chris Adams wrote:
> Hi,
>
> No problem, thanks for your interest in helping port this module.
> Elsewhere in Sailfish OS stack we have been using the following:
> https://git.merproject.org/mer-core/kf5bluezqt/tree/master
>
> That's a Qt-like wrapper around BlueZ 5 from KDE Frameworks.
> We certainly use that for a variety of things (headsets, car audio and
> phonebook profiles, etc). I don't recall why we aren't using the upstream
> QtBluetooth framework directly, it may have something to do with LGPLv3
> licensing or some other requirements we had at the time, I'm not sure.
>
> Best regards,
> Chris.
>
Hi,
do you have a hint how qmake from buteo-syncfw can find KF5BluezQt
neither adding following to the pro file
unix {
QT_CONFIG -= no-pkg-config
CONFIG += link_pkgconfig
PKGCONFIG += KF5BluezQt
}
nor
QT += BluezQt
works
I always get "Project ERROR: KF5BluezQt development package not found"
I have installed
[mersdk@SailfishSDK build]$ pkcon --filter installed get-packages | grep -i
KF5BluezQt
Installedkf5bluezqt-bluez5-5.25.0+git17-1.i486 (installed)
Installedkf5bluezqt-bluez5-declarative-5.25.0+git17-1.i486 (installed)
Installedkf5bluezqt-bluez5-devel-5.25.0+git17-1.i486 (installed)
thanks
regards
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Chris Adams wrote:
> Hi,
>
> No problem, thanks for your interest in helping port this module.
> Elsewhere in Sailfish OS stack we have been using the following:
> https://git.merproject.org/mer-core/kf5bluezqt/tree/master
>
> That's a Qt-like wrapper around BlueZ 5 from KDE Frameworks.
> We certainly use that for a variety of things (headsets, car audio and
> phonebook profiles, etc). I don't recall why we aren't using the upstream
> QtBluetooth framework directly, it may have something to do with LGPLv3
> licensing or some other requirements we had at the time, I'm not sure.
>
> Best regards,
> Chris.
>
Hi,
do you have a hint how qmake from buteo-syncfw can find KF5BluezQt
neither adding following to the pro file
unix {
QT_CONFIG -= no-pkg-config
CONFIG += link_pkgconfig
PKGCONFIG += KF5BluezQt
}
nor
QT += BluezQt
works
I always get "Project ERROR: KF5BluezQt development package not found"
I have installed
[mersdk@SailfishSDK build]$ pkcon --filter installed get-packages | grep -i
KF5BluezQt
Installedkf5bluezqt-bluez5-5.25.0+git17-1.i486 (installed)
Installedkf5bluezqt-bluez5-declarative-5.25.0+git17-1.i486 (installed)
Installedkf5bluezqt-bluez5-devel-5.25.0+git17-1.i486 (installed)
thanks
regards
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Finally we might get contacts sync via BT \o/ Good luck warrior! tortoisedoc On Sat, Jun 8, 2019 at 5:55 PM deloptes wrote: > > Hi Slava, > > > Slava Monich wrote: > > > Hi, > > > >> Hi, > >> thank you for answering. I see both available in the SDK (I still have > >> 3.0.2.28) > >> > >> kf5bluezqt-bluez5-5.24.0+git15-1.3.2.jolla.i486 > >> libbluez-qt5-0.1.26-1.3.2.jolla.i486 > >> > >> but I can not find source for libbluez-qt5 on mer. I find a note in > >> Changelog for SFOS 2.2.1 > >> > >> Can someone point to the repo used? > > > > > > https://git.merproject.org/mer-core/libbluez-qt > > > > > > thank you very much! I now see this is a library for bluez4. Thanks again! > > > >> When I clone the source bluez-qt5 from KDE, I see that the the version is > >> more mature than what is being used in kf5bluezqt-bluez5-5.24.0, but it > >> also states dependency on Qt-5.10. > > > > > > This could be a reasonable first step - to find out whether the latest > > stuff really depends on Qt 5.10 or somebody was like "oh, I've just > > switched to Qt 5.10, let's bump the dependency". I find it hard to > > imagine that anything Qt 5.10 specific would be actually required by a > > simple D-Bus wrapper. > > > > > > Hmm, yes indeed using the KDEs bluez-qt than what is in mer > kf5bluezqt/bluez-qt seems to be of advantage. Perhaps kf5bluezqt/bluez-qt > need to be lifted to KDEs bluez-qt one. It looks like they dropped support > for bluez4 and added more features from bluez5. > As it is coming from KDE, it might be that 5.10 is the version of Qt they > are using. But indeed investigation is needed if it would work. This adds > on top of what was originally intended :). However now at least the path is > more or less clear kf5bluezqt/bluez-qt -> buteosyncfw -> > buteo-sync-plugins. Wish me joy! > > >> Can you please comment on when new Qt version is expected? On the road > >> map it says 5.9 will expire LST next year and we are stuck at 5.6. I know > >> there was discussion in the past, but can't recall the details. > > > > > > I don't know much about that either, just that it's a licensing/legal > > issue. It's not technical. > > > > Yes, indeed I recall reading the same, but was interested in what is planned > for the future. > > Thanks and regards > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Hi Slava, Slava Monich wrote: > Hi, > >> Hi, >> thank you for answering. I see both available in the SDK (I still have >> 3.0.2.28) >> >> kf5bluezqt-bluez5-5.24.0+git15-1.3.2.jolla.i486 >> libbluez-qt5-0.1.26-1.3.2.jolla.i486 >> >> but I can not find source for libbluez-qt5 on mer. I find a note in >> Changelog for SFOS 2.2.1 >> >> Can someone point to the repo used? > > > https://git.merproject.org/mer-core/libbluez-qt > > thank you very much! I now see this is a library for bluez4. Thanks again! >> When I clone the source bluez-qt5 from KDE, I see that the the version is >> more mature than what is being used in kf5bluezqt-bluez5-5.24.0, but it >> also states dependency on Qt-5.10. > > > This could be a reasonable first step - to find out whether the latest > stuff really depends on Qt 5.10 or somebody was like "oh, I've just > switched to Qt 5.10, let's bump the dependency". I find it hard to > imagine that anything Qt 5.10 specific would be actually required by a > simple D-Bus wrapper. > > Hmm, yes indeed using the KDEs bluez-qt than what is in mer kf5bluezqt/bluez-qt seems to be of advantage. Perhaps kf5bluezqt/bluez-qt need to be lifted to KDEs bluez-qt one. It looks like they dropped support for bluez4 and added more features from bluez5. As it is coming from KDE, it might be that 5.10 is the version of Qt they are using. But indeed investigation is needed if it would work. This adds on top of what was originally intended :). However now at least the path is more or less clear kf5bluezqt/bluez-qt -> buteosyncfw -> buteo-sync-plugins. Wish me joy! >> Can you please comment on when new Qt version is expected? On the road >> map it says 5.9 will expire LST next year and we are stuck at 5.6. I know >> there was discussion in the past, but can't recall the details. > > > I don't know much about that either, just that it's a licensing/legal > issue. It's not technical. > Yes, indeed I recall reading the same, but was interested in what is planned for the future. Thanks and regards ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Hi, Hi, thank you for answering. I see both available in the SDK (I still have 3.0.2.28) kf5bluezqt-bluez5-5.24.0+git15-1.3.2.jolla.i486 libbluez-qt5-0.1.26-1.3.2.jolla.i486 but I can not find source for libbluez-qt5 on mer. I find a note in Changelog for SFOS 2.2.1 Can someone point to the repo used? https://git.merproject.org/mer-core/libbluez-qt When I clone the source bluez-qt5 from KDE, I see that the the version is more mature than what is being used in kf5bluezqt-bluez5-5.24.0, but it also states dependency on Qt-5.10. This could be a reasonable first step - to find out whether the latest stuff really depends on Qt 5.10 or somebody was like "oh, I've just switched to Qt 5.10, let's bump the dependency". I find it hard to imagine that anything Qt 5.10 specific would be actually required by a simple D-Bus wrapper. Can you please comment on when new Qt version is expected? On the road map it says 5.9 will expire LST next year and we are stuck at 5.6. I know there was discussion in the past, but can't recall the details. I don't know much about that either, just that it's a licensing/legal issue. It's not technical. Thank you in advance again regards Cheers, -Slava ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Hi, thank you for answering. I see both available in the SDK (I still have 3.0.2.28) kf5bluezqt-bluez5-5.24.0+git15-1.3.2.jolla.i486 libbluez-qt5-0.1.26-1.3.2.jolla.i486 but I can not find source for libbluez-qt5 on mer. I find a note in Changelog for SFOS 2.2.1 Can someone point to the repo used? When I clone the source bluez-qt5 from KDE, I see that the the version is more mature than what is being used in kf5bluezqt-bluez5-5.24.0, but it also states dependency on Qt-5.10. Can you please comment on when new Qt version is expected? On the road map it says 5.9 will expire LST next year and we are stuck at 5.6. I know there was discussion in the past, but can't recall the details. Thank you in advance again regards Chris Adams wrote: > Hi, > > No problem, thanks for your interest in helping port this module. > Elsewhere in Sailfish OS stack we have been using the following: > https://git.merproject.org/mer-core/kf5bluezqt/tree/master > > That's a Qt-like wrapper around BlueZ 5 from KDE Frameworks. > We certainly use that for a variety of things (headsets, car audio and > phonebook profiles, etc). I don't recall why we aren't using the upstream > QtBluetooth framework directly, it may have something to do with LGPLv3 > licensing or some other requirements we had at the time, I'm not sure. > > Best regards, > Chris. > > > From: Devel [devel-boun...@lists.sailfishos.org] on behalf of deloptes > [delop...@gmail.com] Sent: Friday, June 07, 2019 5:09 PM > To: devel@lists.sailfishos.org > Subject: Re: [SailfishDevel] SyncML topic revived > > Hi, > and thank you for the answer. Appreciated! I see there is QT Bluetooth > module since 5.2. I'll be looking into this to see what is possible. > There is also a kde package bluez-qt which can be also useful, but I did > not have time to look closer. It just looks like that a lot needs to be > reworked to make it right. At the moment I don't know how far this has > been integrated in Sailfish. My experience with audio and sync is very > disappointing. > > And thanks for the repos. Exactly there I've been looking. The best would > be to use QT Bluetooth consistently if possible. Who can provide more > information on the topic? I found this wiki which gives an overview of > packages but not on relations and I'm not sure how up to date it is: > https://wiki.merproject.org/wiki/SailfishOSS > > thanks and regards > > > > 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 that we mean to keep BlueZ 4 support working, so no need to have >> two separate codepaths with ifdefs depending on version, instead can just >> port directly to BlueZ 5 APIs. >> >> The two repositories with code that will probably need to be updated are: >> https://git.merproject.org/mer-core/buteo-syncfw/ >> https://git.merproject.org/mer-core/buteo-sync-plugins/ >> >> Regarding patterns-sailfish-mw - I believe that patterns can be thought >> of as "meta packages" which simply define a whole set of packages which >> should be installed. So in itself, it is not a specific package, but >> will >> include a variety of packages which need to be installed. (I may be >> incorrect, if so perhaps David can correct me.) >> I don't know where the patterns are specified, but they are probably >> internal currently. If you have a new package which you believe should >> be added to the core middleware pattern, I suggest you ping lbt on IRC to >> discuss. >> >> Best regards, >> Chris. >> >> >> From: Devel [devel-boun...@lists.sailfishos.org] on behalf of deloptes >> [delop...@gmail.com] Sent: Wednesday, June 05, 2019 6:06 PM >> To: devel@lists.sailfishos.org >> Subject: Re: [SailfishDevel] SyncML topic revived >> >> deloptes wrote: >> >> >>> Another question is where do I find source or documentation around >>> patterns-sailfish-mw package. It looks like it is the right place to >>> integrate such a plugin. >>> >> >> No one answered about patterns-sailfish-mw. >> >> I was digging deeper and found out that in >> libbuteosyncfw/profile/BtHelper.cpp the interface definitions are bluez4 >> >> >> const QString BT::BLUEZ_DEST = "org.bluez"; >> const QString BT::BLUEZ_MANAGER_INTERFACE = "org.bluez.Manager&qu
Re: [SailfishDevel] SyncML topic revived
Hi, No problem, thanks for your interest in helping port this module. Elsewhere in Sailfish OS stack we have been using the following: https://git.merproject.org/mer-core/kf5bluezqt/tree/master That's a Qt-like wrapper around BlueZ 5 from KDE Frameworks. We certainly use that for a variety of things (headsets, car audio and phonebook profiles, etc). I don't recall why we aren't using the upstream QtBluetooth framework directly, it may have something to do with LGPLv3 licensing or some other requirements we had at the time, I'm not sure. Best regards, Chris. From: Devel [devel-boun...@lists.sailfishos.org] on behalf of deloptes [delop...@gmail.com] Sent: Friday, June 07, 2019 5:09 PM To: devel@lists.sailfishos.org Subject: Re: [SailfishDevel] SyncML topic revived Hi, and thank you for the answer. Appreciated! I see there is QT Bluetooth module since 5.2. I'll be looking into this to see what is possible. There is also a kde package bluez-qt which can be also useful, but I did not have time to look closer. It just looks like that a lot needs to be reworked to make it right. At the moment I don't know how far this has been integrated in Sailfish. My experience with audio and sync is very disappointing. And thanks for the repos. Exactly there I've been looking. The best would be to use QT Bluetooth consistently if possible. Who can provide more information on the topic? I found this wiki which gives an overview of packages but not on relations and I'm not sure how up to date it is: https://wiki.merproject.org/wiki/SailfishOSS thanks and regards 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 that we mean to keep BlueZ 4 support working, so no need to have > two separate codepaths with ifdefs depending on version, instead can just > port directly to BlueZ 5 APIs. > > The two repositories with code that will probably need to be updated are: > https://git.merproject.org/mer-core/buteo-syncfw/ > https://git.merproject.org/mer-core/buteo-sync-plugins/ > > Regarding patterns-sailfish-mw - I believe that patterns can be thought of > as "meta packages" which simply define a whole set of packages which > should be installed. So in itself, it is not a specific package, but will > include a variety of packages which need to be installed. (I may be > incorrect, if so perhaps David can correct me.) > I don't know where the patterns are specified, but they are probably > internal currently. If you have a new package which you believe should be > added to the core middleware pattern, I suggest you ping lbt on IRC to > discuss. > > Best regards, > Chris. > > > From: Devel [devel-boun...@lists.sailfishos.org] on behalf of deloptes > [delop...@gmail.com] Sent: Wednesday, June 05, 2019 6:06 PM > To: devel@lists.sailfishos.org > Subject: Re: [SailfishDevel] SyncML topic revived > > deloptes wrote: > > >> Another question is where do I find source or documentation around >> patterns-sailfish-mw package. It looks like it is the right place to >> integrate such a plugin. >> > > No one answered about patterns-sailfish-mw. > > I was digging deeper and found out that in > libbuteosyncfw/profile/BtHelper.cpp the interface definitions are bluez4 > > > const QString BT::BLUEZ_DEST = "org.bluez"; > const QString BT::BLUEZ_MANAGER_INTERFACE = "org.bluez.Manager"; > const QString BT::BLUEZ_ADAPTER_INTERFACE = "org.bluez.Adapter"; > const QString BT::BLUEZ_DEVICE_INTERFACE = "org.bluez.Device"; > const QString BT::GET_DEFAULT_ADAPTER = "DefaultAdapter"; > const QString BT::FIND_DEVICE = "FindDevice"; > const QString BT::DISCOVERSERVICES = "DiscoverServices"; > const QString BT::GETPROPERTIES = "GetProperties"; > > Where can I address this issue? My impression is that this is related to > syncml and never updated when Jolla updated to bluez5 in Sailfish. > > @Chris Adams - can you advise pls? You've helped me so far. > > Thanks in advance > > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org > ___ SailfishOS.org Devel > mailing list To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Hi, and thank you for the answer. Appreciated! I see there is QT Bluetooth module since 5.2. I'll be looking into this to see what is possible. There is also a kde package bluez-qt which can be also useful, but I did not have time to look closer. It just looks like that a lot needs to be reworked to make it right. At the moment I don't know how far this has been integrated in Sailfish. My experience with audio and sync is very disappointing. And thanks for the repos. Exactly there I've been looking. The best would be to use QT Bluetooth consistently if possible. Who can provide more information on the topic? I found this wiki which gives an overview of packages but not on relations and I'm not sure how up to date it is: https://wiki.merproject.org/wiki/SailfishOSS thanks and regards 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 that we mean to keep BlueZ 4 support working, so no need to have > two separate codepaths with ifdefs depending on version, instead can just > port directly to BlueZ 5 APIs. > > The two repositories with code that will probably need to be updated are: > https://git.merproject.org/mer-core/buteo-syncfw/ > https://git.merproject.org/mer-core/buteo-sync-plugins/ > > Regarding patterns-sailfish-mw - I believe that patterns can be thought of > as "meta packages" which simply define a whole set of packages which > should be installed. So in itself, it is not a specific package, but will > include a variety of packages which need to be installed. (I may be > incorrect, if so perhaps David can correct me.) > I don't know where the patterns are specified, but they are probably > internal currently. If you have a new package which you believe should be > added to the core middleware pattern, I suggest you ping lbt on IRC to > discuss. > > Best regards, > Chris. > > > From: Devel [devel-boun...@lists.sailfishos.org] on behalf of deloptes > [delop...@gmail.com] Sent: Wednesday, June 05, 2019 6:06 PM > To: devel@lists.sailfishos.org > Subject: Re: [SailfishDevel] SyncML topic revived > > deloptes wrote: > > >> Another question is where do I find source or documentation around >> patterns-sailfish-mw package. It looks like it is the right place to >> integrate such a plugin. >> > > No one answered about patterns-sailfish-mw. > > I was digging deeper and found out that in > libbuteosyncfw/profile/BtHelper.cpp the interface definitions are bluez4 > > > const QString BT::BLUEZ_DEST = "org.bluez"; > const QString BT::BLUEZ_MANAGER_INTERFACE = "org.bluez.Manager"; > const QString BT::BLUEZ_ADAPTER_INTERFACE = "org.bluez.Adapter"; > const QString BT::BLUEZ_DEVICE_INTERFACE = "org.bluez.Device"; > const QString BT::GET_DEFAULT_ADAPTER = "DefaultAdapter"; > const QString BT::FIND_DEVICE = "FindDevice"; > const QString BT::DISCOVERSERVICES = "DiscoverServices"; > const QString BT::GETPROPERTIES = "GetProperties"; > > Where can I address this issue? My impression is that this is related to > syncml and never updated when Jolla updated to bluez5 in Sailfish. > > @Chris Adams - can you advise pls? You've helped me so far. > > Thanks in advance > > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org > ___ SailfishOS.org Devel > mailing list To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
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 that we mean to keep BlueZ 4 support working, so no need to have two separate codepaths with ifdefs depending on version, instead can just port directly to BlueZ 5 APIs. The two repositories with code that will probably need to be updated are: https://git.merproject.org/mer-core/buteo-syncfw/ https://git.merproject.org/mer-core/buteo-sync-plugins/ Regarding patterns-sailfish-mw - I believe that patterns can be thought of as "meta packages" which simply define a whole set of packages which should be installed. So in itself, it is not a specific package, but will include a variety of packages which need to be installed. (I may be incorrect, if so perhaps David can correct me.) I don't know where the patterns are specified, but they are probably internal currently. If you have a new package which you believe should be added to the core middleware pattern, I suggest you ping lbt on IRC to discuss. Best regards, Chris. From: Devel [devel-boun...@lists.sailfishos.org] on behalf of deloptes [delop...@gmail.com] Sent: Wednesday, June 05, 2019 6:06 PM To: devel@lists.sailfishos.org Subject: Re: [SailfishDevel] SyncML topic revived deloptes wrote: > Another question is where do I find source or documentation around > patterns-sailfish-mw package. It looks like it is the right place to > integrate such a plugin. > No one answered about patterns-sailfish-mw. I was digging deeper and found out that in libbuteosyncfw/profile/BtHelper.cpp the interface definitions are bluez4 const QString BT::BLUEZ_DEST = "org.bluez"; const QString BT::BLUEZ_MANAGER_INTERFACE = "org.bluez.Manager"; const QString BT::BLUEZ_ADAPTER_INTERFACE = "org.bluez.Adapter"; const QString BT::BLUEZ_DEVICE_INTERFACE = "org.bluez.Device"; const QString BT::GET_DEFAULT_ADAPTER = "DefaultAdapter"; const QString BT::FIND_DEVICE = "FindDevice"; const QString BT::DISCOVERSERVICES = "DiscoverServices"; const QString BT::GETPROPERTIES = "GetProperties"; Where can I address this issue? My impression is that this is related to syncml and never updated when Jolla updated to bluez5 in Sailfish. @Chris Adams - can you advise pls? You've helped me so far. Thanks in advance ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
deloptes wrote: > Another question is where do I find source or documentation around > patterns-sailfish-mw package. It looks like it is the right place to > integrate such a plugin. > No one answered about patterns-sailfish-mw. I was digging deeper and found out that in libbuteosyncfw/profile/BtHelper.cpp the interface definitions are bluez4 const QString BT::BLUEZ_DEST = "org.bluez"; const QString BT::BLUEZ_MANAGER_INTERFACE = "org.bluez.Manager"; const QString BT::BLUEZ_ADAPTER_INTERFACE = "org.bluez.Adapter"; const QString BT::BLUEZ_DEVICE_INTERFACE = "org.bluez.Device"; const QString BT::GET_DEFAULT_ADAPTER = "DefaultAdapter"; const QString BT::FIND_DEVICE = "FindDevice"; const QString BT::DISCOVERSERVICES = "DiscoverServices"; const QString BT::GETPROPERTIES = "GetProperties"; Where can I address this issue? My impression is that this is related to syncml and never updated when Jolla updated to bluez5 in Sailfish. @Chris Adams - can you advise pls? You've helped me so far. Thanks in advance ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] SyncML topic revived
Looking at the code in
buteo-sync-plugins/serverplugins/syncmlserver/BTConnection.h
buteo-sync-plugins/serverplugins/syncmlserver/BTConnection.cpp
// Get the Bluez manager dbus interface
QDBusInterface mgrIface ("org.bluez", "/", "org.bluez.Manager",
QDBusConnection::systemBus ());
This is bluez4 and will never work with bluez5. Is there a way to flash
Sailfish with bluez4 on X? I have bluez4 on an Intex AquaFish, but X came
out with bluez5 (not sure which version introduced bluez5 though). I just
purchased another X for development, so could be first try to revive the
code as is with bluez4 and then try to rework it for bluez5, however from
my previous experience doing bluez4 -> bluez5 it is a lot of work
especially if you want to keep bluez4 and bluez5 support.
I need to look closer how much is needed in the sync-plugin - probably not
much, but perhaps you give me your opinion if bluez4 can be dropped
completely, which will make work easier.
I am not sure which way I should go - it looks like it needs fundamental
work.
Another question is where do I find source or documentation around
patterns-sailfish-mw package. It looks like it is the right place to
integrate such a plugin.
thank you in advance and regards
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Thank you Chris, > The btcalendarsync branch (which added very preliminary support for > synchronizing calendar events via SyncML over Bluetooth) hasn't been > touched in years. A `git pull --rebase origin master` may be needed to I already did this > rebase it on top of current master, and then it's entirely possible that > some other changes may be required to get it working again, depending on > other changes in that repository or elsewhere in the stack... > Indeed it looks like things changed and a deeper look might be needed to reintegrate it. > I don't actually recall much about that one at all, or whether we still > support syncml on the device. First step would be to look at the server > plugin in that repository, find out if it is still installed, what > starts/stops it, etc. Second step would be to check whether it has > permissions to access what it needs to access (e.g. is granted privileged > user rights by invoker, etc). Third step would be to debug its actual > behaviour (e.g. is it responding to SyncML clients appropriately). > it installs fine, but the rest needs more investigation. to try step three it needs to offer SYNCML-[SERVER|CLIENT] via obex, but it does not. I was just wondering what is patterns-sailfish-mw. I recall reading about middle ware in Architecture, but I could not find any hint (so far) how things should work there for this plugin. > p.s. I'm away on vacation for a couple of weeks now, but hopefully this puts you on the right track. > Please feel free to email or ping me on IRC if you need more help, once I get back from vacation. Thanks for the offer again! I am afraid I would need to buy a device for development/testing. I use my one at daily bases and can not risk breaking the setup. It will just take some time. I am afraid, BT/sync can not be debugged in the virtual machine(s). On top I'll need time to catch up with Sailfish OS development documentation, so it is possible that I contact you after you are back from your next vacation :) ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] SyncML topic revived
Hi, Sorry for top-posting, but Outlook Web App doesn't do quoting for some reason. The repository you linked should be the correct one. It contains both server plugin (i.e. syncml server) and client plugin. The btcalendarsync branch (which added very preliminary support for synchronizing calendar events via SyncML over Bluetooth) hasn't been touched in years. A `git pull --rebase origin master` may be needed to rebase it on top of current master, and then it's entirely possible that some other changes may be required to get it working again, depending on other changes in that repository or elsewhere in the stack... I don't actually recall much about that one at all, or whether we still support syncml on the device. First step would be to look at the server plugin in that repository, find out if it is still installed, what starts/stops it, etc. Second step would be to check whether it has permissions to access what it needs to access (e.g. is granted privileged user rights by invoker, etc). Third step would be to debug its actual behaviour (e.g. is it responding to SyncML clients appropriately). Regarding obexd, there is /usr/lib/systemd/user/obex.service so `systemctl --user restart obex` may work. Best regards, Chris. p.s. I'm away on vacation for a couple of weeks now, but hopefully this puts you on the right track. Please feel free to email or ping me on IRC if you need more help, once I get back from vacation. From: Devel [devel-boun...@lists.sailfishos.org] on behalf of deloptes [delop...@gmail.com] Sent: Friday, April 12, 2019 5:58 PM To: devel@lists.sailfishos.org Subject: [SailfishDevel] SyncML topic revived Hi, 2y ago I asked few questions regarding syncml support via bluetooth and you, especially Chris, were nice to advise me to look at https://git.merproject.org/mer-core/buteo-sync-plugins For various reasons (family, work, open source contribs to my desktop and more) I am just now ready to follow up on that, but got very confused. The branch is many commits behind, no url to clone the branch and when trying to install, it says it is obsoleted by the patterns-sailfish-mw package. I however changed the name in spec from buteo-sync-plugins to buteo-syncml-plugins after examining that content would not overwrite anything in patterns-sailfish-mw but I do not see SYNCML service advertised by the phone. And I also see in /etc/obexd/excludes/bluetooth:pcsuite First try, big confusion :) - bare with me. Can you please give me a hint, advice or just help me to put it right? I am committed to working on this in this year and expanding my knowledge base. A bonus question - how do I restart the obexd that is running in the user session? Thank you in advance ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] SyncML topic revived
Hi, 2y ago I asked few questions regarding syncml support via bluetooth and you, especially Chris, were nice to advise me to look at https://git.merproject.org/mer-core/buteo-sync-plugins For various reasons (family, work, open source contribs to my desktop and more) I am just now ready to follow up on that, but got very confused. The branch is many commits behind, no url to clone the branch and when trying to install, it says it is obsoleted by the patterns-sailfish-mw package. I however changed the name in spec from buteo-sync-plugins to buteo-syncml-plugins after examining that content would not overwrite anything in patterns-sailfish-mw but I do not see SYNCML service advertised by the phone. And I also see in /etc/obexd/excludes/bluetooth:pcsuite First try, big confusion :) - bare with me. Can you please give me a hint, advice or just help me to put it right? I am committed to working on this in this year and expanding my knowledge base. A bonus question - how do I restart the obexd that is running in the user session? Thank you in advance ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
