I’m not familiar with the SDK, but it sounds like a more viable option. Do you have more info on setting up the developer environment for this and where to get it?
Can the SDK support environment configurations for SFOS 2.x.x apps ?
If you could get your hands on earlier release of sfos sdk you could try to run jboy in 2.x emulator, on phone right now so can’t check if legacy versions are available, but digging that out could save a bit of time (then again 2.0 was close to decade ago, wouldn’t be surprised if links are dead etc)
Btw have you looked through openrepos comments, some people suggest changing busybox cli tools to gnu versions helped for 3.3 sfos (and some patch?) so maybe you can fix the app itself and skip the whole decade timejump?
Yes, there are significant time jumps in 2.x.x lifecycle from 2014 to 2019. 2.1.4 and 2.2.0 look to be the most reassuring options, given that any SDKs for those are more likely to still be available.
I did not spot that around the busybox switch. I would be more inclined to consider that first.
The user BlacksheepGER has plenty of old releases: GitHub - black-sheep-dev/sailfish-os-torrents: Collection of torrent files for older Sailfish OS releases.
1 Like
A perl oneliner to fix expected value, worth trying that first, could save hours
@emva Spotted that, but there are no seeders for the older versions: Download older version of SailfishOS - #39 by jimjamz
Yes, that would be quite the concise fix if that was to work. I will look at running that, and then a busybox replacement if the former fails.
1 Like
Sadly, the perl invocation of the sed script does not work for the latest error I receive. I do remember seeing this comment now, when I first encountered the error I have, and realising that the solution offered is for a different error type and use case scenario.
The issue in the OpenRepos comments pertains to ‘Error #3’. It is based on what the author of the comment describes, and the perl solution offered is to bypass the error received when loading a ROM (something I cannot get to - Error #7 occurs upon launching the JBoy app. It’s not even possible to reach the step of opening a ROM, so although I’m about to try replacing the busybox tools, I don’t anticipate this solving Error #7.
1 Like
Maybe 3.3 sfos image/sources/sdk+emulator will be easier to find, should work with the perl trick (3.4 might also and this being last J1 supported version should be seeded more reliably)
Sounds like a classic access issue caused by the introduction of SailJail. You may try adding the usual disabling entry to the app’s desktop file first, before taking this long re-flashing detour.
1 Like
Hi @olf
I missed out on a lot of the changelog since 2.x.x so am not familiar with SailJail and the issues it caused.
After a quick search on the topic, is the only addition to the app’s .desktop file that would be required?:
[X-Sailjail]
Sandboxing=Disabled
1 Like
Yes.
And it’s best done by creating a desktop file of the same name at /etc/sailjail/applications, containing just those lines.
4 Likes
It’s working. Thank you for the support guys, it’s much appreciated.
It just shows that being out of the loop for a few releases, a lot of things have come along and changed/broken a few things that have required a few adjustments/workarounds I’m not familiar with.
You have indeed saved me hours, if not days of work. Many thanks.
3 Likes
@jimjamz, it would be nice to report the steps you took in a comment for JBoy at OpenRepos, likely:
-
devel-su pkcon remove symlinks-busybox-bash# This might be wrong, I am typing this by faintly remembering! Please check. -
devel-su echo -e "[X-Sailjail]\nSandboxing=Disabled" > /etc/sailjail/applications/harbour-jboy.desktop# Is the apps’ desktop file name correct? I have no idea!
And please tell there, what your statement “It’s working.” means: Is the app fully functional again or something else?
2 Likes
@olf I will follow up with a report on the comments over at OpenRepos, and provide the results of my testing. I will also backlink to this topic here.
In the end, removing/replacing the busybox binaries was not required. SailJail seemed to be the issue in its entirety. Adding the .desktop file in /etc/sailjail/applications and updating the .desktop in /usr/share/applications was sufficient enough.
1 Like
It should only be necessary to perform one of these two operations, preferably creating a new .desktop file in /etc/sailjail/applications/, as @nephros suggested.
So ultimately it seems to only need a …
devel-su echo -e "[X-Sailjail]\nSandboxing=Disabled" > /etc/sailjail/applications/harbour-jboy.desktop # Is the apps’ desktop file name correct? I have no idea!
… to achieve <whatever>.
P.S.: In general, I trust @ade’s assessments; here, that busybox does cause an issue and the two different workarounds he provided for resolving this. But sure everybody may err, including him or me.
Hence @jimjamz, please double-check your assessment: “In the end, removing/replacing the busybox binaries was not required.”
Correct. Either one of the two operations is sufficient, having tested both exclusively.
My personal preference would be to add the entry to the existing .desktop file in /usr/share/applications as it’s a cleaner approach.
However, I can also understand why instead creating a new file in /etc/sailjail/applications/ would be preferred, for readability purposes (the existence of a file in that directory implies that app has sailjail disabled.
That is the name of the file and the script look correct, but prefixing the command with devel-su does not invoke the root password to be entered, and will automatically respond with Permission denied. Neither does concatenating the commands with &&. Better to have the two as separate steps?
No, /usr/share/ is a “system” directory admins should not interfere with: This is why often a directory under /etc/ exists, the content of which overrides the one in the corresponding “system” directory. This is far more elegant, specifically in the case of .desktop files, because an admin only needs to add the parts which are to be altered or added.
[…] prefixing the command with
devel-sudoes not invoke the root password to be entered […].
Better to have the two as separate steps?
Yes.
I never understood why this is sometimes necessary.
1 Like