@jolla I used to build programs for the Jolla C2, using a docker container based on sfdk and sb2 .
Yesterday, I thought I’d set up build environment for the new Jolla Phone. Based on the listing on page Index of /sdk/targets/ , and listing given by the command sfdk tools list -a there isn’t a publicly available target for SFOS 5.2.
Can an estimation be given, of how could it possible take to publish the target for SFOS 5.2?
Apologies if I am mixing some terminology in this post.
I had to rework some programs I wrote for 5.0.X for my J2 on 5.2.X and using the 5.1 developer image worked fine for what I needed to accomplish.
There is on https://build.sailfishos.org/
@ellemmennoppi Some programs compiled with the 5.1 image do work nicely on SFOS 5.2., though this depends on the program. Thanks for mentioning that.
@ohnonot Thank you. I tried looking for instructions, at least OBS usage from OpenSUSE videos linked. It seems that OBS cannot see any templates at the moment, and Image Creation service is currently unavailable, according to Image Creator page under Development Services. Is this OBS system purely for building RPMs? Is it possible to build custom tools from Git repositories, which don’t produce an RPM package?
An example: I manually built a client for Proxmark NFC tool, from this repo: GitHub - RfidResearchGroup/proxmark3: Iceman Fork - Proxmark3 · GitHub
Can the OBS be used for such use case, link the given repo and it compiles the client (no RPM references, no spec file and so on)? Sorry for a possibly confusing phrasing. I’m totally new to OBS.
I can’t really help you with that, I’m barely staying afloat on OBS
I use this one here GitHub - CODeRUS/github-sfos-build: GitHub Action for bilding Sailfish OS apps · GitHub Provided by @coderus which is working pretty Fine - You can also setup nice GitHub Actions and automations with that. I use it to Build all my SFOS developed Apps as automation.
—> latest Image available is 5.2.0.15
What’s missing when create apps with the latest sfdk target? Please help me to see the problem here. Thanks.
Obs requires a spec file. The usual route to take on obs chum is to create a repository with an rpm and a submodule with the code to be built. This is a minimal example for a library: GitHub - poetaster/libomemo-c: omemo library for double ratchet in xmpp packaging for sailfishos · GitHub
But, using github actions with @coderus images also works really well. I do both.
Thank you, I’ll sure try it out. It is just weird that the target wasn’t available from Jolla’s official site.
I am unsure what exactly is missing. As an example, I used both, the 5.1.0.11 and 5.1.0.11ea in order to try to compile Proxmark3 NFC reader/writer client for SFOS 5.2.0.16, using this repository: GitHub - RfidResearchGroup/proxmark3: Iceman Fork - Proxmark3 · GitHub.
The compilation went well with both targets, though client execution failed and raised a somekind of an error I could not figure out the reason for.
So technically, I think nothing is actually missing; The execution of the compile binary only fails.
Sure ask more if you want to know more. I hope I answered your question here. 
Thank you @poetaster , I’ll be sure to look into that @coderus made github project!
Why is it needed? Can’t you compile on older targets? I recently went back to 5.0 build image because 5.1 uses a newer glibc and thus apps cannot run on 5.0.
@Rikudou_Sennin For varying reasons, certain programs built on older targets won’t run on SFOS 5.2. And phrasing it “for varying reasons” means that different programs built on older targets may crash differently, and I haven’t been able to pinpoint only one specific issue there.
Which to me suggests that it may not exist.
I understand you would prefer to just test… but lots of clever developers has spent lots of effort on keeping things compatible, so i suspect you are in for a disappointment.
Sure. Testing of course is one thing. Though I do have a need for programs like proxmark3 client. That one I compiled on the phone itself. I’d still try to avoid installing a lot of compilation tools and dependencies on the phone itself.
What i’m saying is that if you don’t have a specific problem correlating to a too-old SDK, chances are significant that a new SDK isn’t a be-all and end-all solution.