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] openobex-devel-0.1.4-1.2.1.jolla.armv7hl requires bluez-libs-devel, but this requirement cannot be provided
Hello, Normally, you don't need the -devel package on device. It is used to compile in SDK only and provide the headers and .so. The executable created in SDK is linking against the .so.X that is provided by the non -devel package, itself installed on device. Good luck with your efforts to bring back SyncML ! Damien. Le Samedi 20 juillet 2019, deloptes a écrit : > > Hi, > > buteo-syncml is linking against openobex. Openobex-devel is installed in the > SDK, but can not be installed in the native environment. > > Fatal error: openobex-devel-0.1.4-1.2.1.jolla.armv7hl requires > bluez-libs-devel, but this requirement cannot be provided > > How is it possible that it is installed in the SDK? > > How can this be resolved? > > Thank you in advance. > > 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 (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
