Patches by ichthyosaurus

Thanx for this detailed answer.
Yes this is the one
So I will have a look, if I have success later on.
I will as well reread your docs and give - if possible - hints what can be improved.

1 Like

I fear this is a rocky road to go with my skills. Anyway, if you are still holding my hand, I maybe get there where I want. As a reward, I will write you a guide with the title “updating a patch for complete noobs”, which you can use for your github docs.

Ok, what have I done:
I changed the CONFIG file in the way I think it has to be. Than I used

sailfish-patch -i CONFIG unified_diff.patch

which returned some errors and told me to try it again. I fixed the errors in the CONFIG and run it again.

Output is:

sailfish-patch -i CONFIG unified_diff.patch
warning: license text not found at COPYING
you can download it using the ‘-eL’ option
error: unrecognized source file
Any patch file, or a patch named ‘unified_diff.patch’ in the
root of a tar archive are supported.
You can safely remove ‘sfos-patch-three-finger-volume’ for cleanup.

And a folder (sfos-patch-three-finger-volume) with a new CONFIG file was created. Nothing else, just the CONFIG file.

I guessed for the license text warning and run

sailfish-patch eL unified_diff.patch

in the folder above the newly created one. Where the unified_diff.patch file lies. The command completed without any output.

Unfortunately I have no clue what

error: unrecognized source file

mean (do I have to be connected to the phone?) and what does

You can safely remove ‘sfos-patch-three-finger-volume’ for cleanup.

mean? Shall I delete the newly created folder? But then the new CONFIG file is gone as well.

Further on, for me it is not clear, when I have to make things on my Workstation and when do I have to ssh to my phone. And if I have to ssh to my phone, what is the syntax I have to use together with your commands. I usually use ssh to use Terminal more comfortably. So I usually use putty, but of course I now that i can connect via ssh -p 22 defaultuser@IP in Terminal as well, but if I just connect via ssh sailfish-patch can’t be found, because it is not on my phone. But if I read the docs correctly, for the build and deploy command I have to ssh to my phone.

And, In the docs on github you wrote:

  • Run sailfish-patch -i CONFIG my_patch_file.diff to create a new repo and bootstrap it.

What does that mean? I don’t know what bootstrapping is and I would read this line as with that command you have created a repo and it is bootstrapped. But further above is written that the bootstrap option is

sailfish-patch -u

Questions over questions, I warned you about stupid questions :grimacing:

I would have attached my CONFIG file in Blockquote, but it gets misinterpreted.

1 Like

I released the v0.0.7 and it could be the “good one” because I have tested intensively and in the worst conditions. Moreover, it is indipendent from Google services but relies on Qualcomm SUPL hosts network. Among other features, implement a throttling for XTRA in such a way the SFOS does not lag and apps do not freeze.

PERFORMANCES

After a reboot, the fix indoor with 4G IPv4-only mobile data transit on a free UDP VPN with energy save mode enabled and WiFi tethering active, it takes less than 15s for 9000m h-accuracy and near 1m for fixing the point under 100m of h-accuracy, 2m for 15m with 6/41 use/view satellites. Without the WiFi tethering active or any Wifi connections, it takes near 30s for 30m h-accuracy.

1 Like

As long as you’re not in a hurry - I’m generally quite slow with replying :see_no_evil:

That would be awesome! It’s really good to get all these questions because it will make patching more approachable and easy for beginners.

Well, that is weird. I just tested it myself and it works for me. Did you change the unified_diff.patch file? The error message means that the script could not determine whether the file actually is a patch. Can you run file --mime-type -b unified_diff.patch and check if the output is text/x-diff?

That’s because it did not recognize the patch file and aborted the process, i.e. it did not import anything yet. The CONFIG file is just an unchanged copy of the config file you prepared. The message means that you can (should) delete the newly created folder so that you can try again. (The script doesn’t delete it automatically because it might be interesting for finding what went wrong - not in our case though.)

The license is not required at this step, and the -eL option download the license text from spdx.org. It should actually print something like saved license GPL-3.0-or-later to COPYING…

The only thing you may have to run on the phone is rpm -qf /path/... to find the package that a file belongs to. The new -Id option does that for you though, so normally you don’t have to run anything via SSH yourself.

Also, you shouldn’t put sailfish-patch on the phone because it needs Bash and wouldn’t work with Sailfish’s Busybox.

The script needs SSH access to your phone, though, and I just realised that it isn’t documented in the readme how to configure this. You have to set these environment variables (they have very brief descriptions in the manpage and when running sailfish-patch --help):

  • SF_PATCH_SSH_TARGET: set this to the IP you use to connect
  • SF_PATCH_REMOTE_USERNAME: set this to defaultuser, the current default value is still nemo
  • SF_PATCH_PASSFILE: this is quite important: on your phone, go to Settings → Developers → Password and set a secure password. Then save this password in a plain text file somewhere on your computer, and define the path to this file in SF_PATCH_PASSFILE.

(The script needs root (devel-su) access to your phone because it has to run pkcon and rpm when downloading packages from the Jolla store, and when installing the patch for you.)

With “bootstrapping” I mean “take a config file, download the source packages listed there, create a new git repository containing all files, then last but not least apply the patch to the files in the patched folder”. In other words: “set everything up for you so you can get started”.

The -u or --update option does that for patches that were created with sailfish-patch, i.e. that already have a config file. The -i or --import option uses -u internally but adds a few more steps.

You can share it here: https://paste.systemli.org

I hope this wall of text doesn’t confuse you further ;).

2 Likes

I’m an old lad and so my impatient times are gone for quite a time :upside_down_face:

I just changed the text inside the file, to what I posted in the above. I will check tomorrow if kate (my editor of choice) has done anything to the file format:

I guessed so, just wanted to be sure.

Thanx for explantion.

Ok, this was the point where I was absolutely lost, even so I use ssh quite often. I’m happy that you just forgot some parts in the the docs otherwise I would have felt like an idiot. :blush:

Thanx for explaining

I will share the CONFIG tomorrow if I still have no success.
Everything of your text is helping me, so not more confusion but less. :+1:
Thanx for your patience.

1 Like

This link has been added in the quick start guide bookmarks! :blush:

1 Like

The result of file --mime-type -b is text/plain.
Whereas the result on the original file is text/x-diff, so the culprit seems to be Kate or something in its settings. Every time I change something in the original file and save it, the mime type is changed to plain text.
I will use mc-edit and tell you if I succeed.

Did you see the syntax highlighting file for config files, by the way? If not, you can read in the manpage how to enable it: simply copy the highlighting file to $HOME/.local/share/org.kde.syntax-highlighting/syntax/ and restart Kate. Patch config files should now have nice colors and error highlighting which makes them much easier to write/edit.

I’ll update the docs! (eventually :grimacing:)

Glad to hear that! :slight_smile:

I see… Maybe I should allow text/plain in the script as well. On the other hand, if a patch is not recognized by file, it’s probably broken in some way.

Actually, you don’t have to change the patch file anyway. Just try it with the unchanged patch file once, and follow the instructions that the script will give you.

For simple patches like this one, you could actually just modify the two lines in the patched folder by hand.

1 Like

Nice addition, thank you! :slight_smile:

1 Like

Slowly…
Next step is done. Next stop is here.

As a normal user you are not used to set environment variables. Anyway, I searched the net and found that you can set it with the command export

So i have set them and when I list them they are there:

env | grep SF
SF_PATCH_REMOTE_USERNAME=defaultuser
SF_PATCH_PASSFILE=/home/darkstar/Downloads/SF/Patches/PW/PW.txt
SF_PATCH_SSH_TARGET=192.168.111.44

It seems like they are respected regarding the target. But obviously not regarding the username:

/home/darkstar/Downloads/SF/Patches/sailfish-patch -i CONFIG unified_diff.patch
warning: license text not found at COPYING
you can download it using the ‘-eL’ option
warning: license text not found at COPYING
you can download it using the ‘-eL’ option
rmdir: konnte ‘/home/darkstar/Downloads/SF/Patches/sfos-patch-three-finger-volume/original’ nicht entfernen: Datei oder Verzeichnis nicht gefunden
rmdir: konnte ‘/home/darkstar/Downloads/SF/Patches/sfos-patch-three-finger-volume/patched’ nicht entfernen: Datei oder Verzeichnis nicht gefunden
note: bootstrapping distribution package
Leeres Git-Repository in /home/darkstar/Downloads/SF/Patches/sfos-patch-three-finger-volume/.git/ initialisiert
Zu neuem Branch ‘main’ gewechselt
[main (Root-Commit) 2d140a7] patch configuration imported by sailfish-patch
2 files changed, 126 insertions(+)
create mode 100644 CONFIG
create mode 100644 unified_diff.patch
fetching sources… 2d140a7
downloading package via external device…
darkstar@192.168.111.44’s password:

darkstar is the username of the user on the PC. So something is still fishy.

That’s a bug; I just published a fix for it. If you download the latest script, it should hopefully work now.

1 Like

Thanx, I will give it a try tomorrow.

1 Like

I have installed the app anti-lag patch and the uninstalled. Now, I am experience this issue in the screenshoot. It is not persistent, after few second the page becomes normal. Tried to restart the Settings, the home, reboot. Nothing. I had to reinstall the patch.

The patch makes the tabs in the settings app load asynchronously but that shouldn’t affect the settings pages themselves, especially not when the patch isn’t even installed.

Sometimes there are seemingly random and unexplainable issues when using many patches at the same time. I sometimes have to disable all and restart the phone a couple of times until everything goes back to normal…

1 Like

uh oh, like Windows 95… :rofl:

UPDATE

Upgrading the Opal package everything is fine with and wthout the patch

Success!
well… some kind of.

Anyway. The Patch is on my phone and is working. But there are/were still some problems:

  1. Even so I set a PW file in the Environment Variables (SF_PATCH_PASSFILE=/home/darkstar/Downloads/SF/Patches/PW/PW.txt), I had to type my password all the time, so I guess, there is something not in the right place.

  2. First I tried it with the original and my initial unified.diff.patch which lead to:

patching file lipstick-jolla-home-qt5/volumecontrol/VolumeControl.qml
Hunk #1 succeeded at 288 with fuzz 2 (offset -3 lines).
patching file lipstick-jolla-home-qt5/compositor.qml
Hunk #1 FAILED at 247.
1 out of 1 hunk FAILED – saving rejects to file lipstick-jolla-home-qt5/compositor.qml.rej
error: failed to apply diff
patch command: patch -d ‘patched’ -p’3’ -u <‘diff_applying.patch’
error: failed to apply patch to downloaded sources
Both source directories now contain fresh but unchanged sources.
The original patch is still available in ‘unified_diff.patch’ and you can
try applying it manually to the files in ‘/home/darkstar/Downloads/SF/Patches/sfos-patch-three-finger-volume/patched’.

error: failed to import the patch, see above for details

So I knew, that patch line in VolumeControl.qml succeeded and in compositor.qml failed.
I searched for the Problem and solved it. But that was just guessing. The original patch line has changed. And my first try had the wrong line as target in the wrong section. Anyway after searching in the compositor.qml for globalVolumeGestureItem I found

enabled: !systemGesturesDisabled && largeScreen.

So I changed accordingly to the original patch the largeScreen to smallScreen. But In the end that was just guessing. So for me as a user, it seems quite hard to update a more complex patch. How do you as a developer know, what you have to change on the different files especially, when you create a new patch. I have a function for a patch in mind, which I don’t know if this is really possible with a patch :face_with_monocle: :scream:. Is there somewhere a proper documentation somewhere? I’m quite sure, that I can’t do that on my own, but would of course try to, if I can get some help.

  1. when I just typed sailfish-patch -b for building the patch, I was in the wrong directory. So it just build me two directories and stopped. So I copied sailfish patch in the three-finger-volume directory, and run it from there. Could I have just added the path after the command to avoid the copying?

  2. Unfortunately there is still a minor problem:
    When i apply (and unapply) the patch and want to restart the services, patchmanager says it has to restart the homescreen. If I accept, it doesn’t do that. I have to run it in Terminal to get the patch working. Any hints? I don’t want to publish it when there are still known problems.

If this last thing is fixed, I just publish it via sailfish-patch -Po -Pm, is that correct?

If so, I can start to write my promised documentation for complete noobs or better to say for advanced noobs. I think a complete noob is still somewhat overstrained. :innocent:
I will do this via a new thread here in the forum so you can afterwards review it and take whatever you think is helpful to your docs. Just give me some time for that. I want to do it in a proper way.

2 Likes

Exactly like Windows 95 :'D.

I have no idea how this could be connected, but I’m glad it works now :).

Yay ;).

Did you have to type your devel-su password or your ssh password? The former should only be needed when pushing the patch to the device for testing. The latter is needed for every SSH connection, but there are ways to make the system remember the password (see here).

Well, it’s always just guessing. The only thing that changes with experience is that you get better at guessing :). That’s not a big problem though, because Patchmanager doesn’t actually change any files (it just “simulates” changes) so it’s hard(er) to accidentally break your system.

For the internals of the system? No, sadly not. If Jolla were to release everything under a Free Software license then people could step up and document things… Or did I misunderstand your question?

sailfish-patch always uses the current working directory. You can either put the script into a folder in your $PATH (like this), or you can run it using its full path (like /home/myname/Downloads/sailfish-patch), or you can copy/link the script as you did.

This sounds like a problem with Patchmanager. Maybe ask here?

But you don’t need that anyway. Just add this to your CONFIG file and sailfish-patch restarts it for you during development:

TestCommands:
- systemctl --user restart lipstick

Users also don’t have to use Patchmanager, they can use the “Utilities” settings page and select “restart homescreen” there.

Exactly, but you will need accounts on OpenRepos and for the Web catalog. The -Po command runs a wizard that guides you through publishing on OpenRepos, -Pm does the same for Patchmanager’s web catalog (the “m” stands for “manager”…).

Awesome, thank you so much :slight_smile: !

1 Like

Thanx @ichthyosaurus
In the meantime, I discovered a further problem. The patch only works for some time, and then it stops working. I haven’t yet discovered what triggers the stopping. But when it stops, you have to restart lipstick, to make it work again. Maybe it has something to do with OOM. Even so, I doubt, because it just should be a setting. Anyway, the next four days I have no time for Sailfish other than just using my Phone. After that, I will open up accounts and publish the patch. And I will start to write a documentation. Maybe I will find out what triggers the patch to stop in the meantime…

OK, I wanted to make the last steps: Publish the patch and write the promised guide for noobs.
I had first problems because I haven’t got an email for confirmation. But @coderus helped me out. So I will try to publish the patch tomorrow and then I start to write the guide (should be ready within a week).

3 Likes