kobopatch - An improved patching system

[Alanon]

I've been playing around with this new system, and I can really see how it will make things a lot easier moving forward. The instructions were just as easy to follow as the previous method, if not easier, and the major benefit is that you only really need to configure the overrides once and have an almost automatic process. I only have two remarks that might make things a bit easier in the long run.

First, could you make an exception to continue compiling the patches even if an override entry is not found? This would make sense if someone really wanted to patch their new firmware and didn't want to wait for, say the beta games patch to be adapted. Of course, this is practically useless if you intend to wait until all the patches are adapted before releasing a new version, but if the patch release process will be in stages, I think it makes sense?

The second point is really just food for thought. While configuring everything, I caught myself having forgotten to alter the recommended value for my Aura One in the "ePub fixed/adjustable top/bottom margins" patch. In fact, this often happened in the old patching regiment and had to redo the process. I haven't really looked at other patches to see if they have different recommended values for different models, but I can't help but wonder if there's a way to automate this process for all "configurable" patches? Perhaps by adding an entry in the kobopatch.yaml to serve as a device/model identifier?

Anyway, great job!

[geek1011]

Originally Posted by Alanon

I've been playing around with this new system, and I can really see how it will make things a lot easier moving forward.

Thanks!

Originally Posted by Alanon

First, could you make an exception to continue compiling the patches even if an override entry is not found? This would make sense if someone really wanted to patch their new firmware and didn't want to wait for, say the beta games patch to be adapted. Of course, this is practically useless if you intend to wait until all the patches are adapted before releasing a new version, but if the patch release process will be in stages, I think it makes sense?

That is why I say to comment out broken patches. Because of the fast release/update cycle, patches can be updated at any time.

Originally Posted by Alanon

The second point is really just food for thought. While configuring everything, I caught myself having forgotten to alter the recommended value for my Aura One in the "ePub fixed/adjustable top/bottom margins" patch. In fact, this often happened in the old patching regiment and had to redo the process. I haven't really looked at other patches to see if they have different recommended values for different models, but I can't help but wonder if there's a way to automate this process for all "configurable" patches? Perhaps by adding an entry in the kobopatch.yaml to serve as a device/model identifier?

I've been thinking that too ... I might be able to add a device specific option to the instructions, but that would come in a later version. I will think about this a bit more later.

Thanks for the feedback!

[oren64]

Nice work again

In the zlib patches douse it compress the code with null at the end like in pipcat method?

[geek1011]

Originally Posted by oren64

Nice work again

In the zlib patches douse it compress the code with null at the end like in pipcat method?

No. That's only needed for normal strings (which are null terminated), as zlib streams have a trailer which marks the end consisting of an adler32 checksum of the data (see https://www.ietf.org/rfc/rfc1950.txt). I have tested this specifically to confirm.

And for updating your patches which come with kobopatch, you can either use GitHub, reply to this thread, or send me a PM.

[npr]

A couple of small problems I've had with this patch:

1) Patch --- Custom reading footer style
The penultimate line:

#ReplaceString: {Offset: 00FA, Find: "margin-top:+00px", Replace: "margin-top:-10px"}

Should be Offset: 250

2) In kobopatch.yaml

# files:
# src/whatever.txt: usr/local/Kobo/whatever.txt

No space is allowed before "files:"

[geek1011]

Originally Posted by npr

A couple of small problems I've had with this patch:

1) Patch --- Custom reading footer style
The penultimate line:

#ReplaceString: {Offset: 00FA, Find: "margin-top:+00px", Replace: "margin-top:-10px"}

Should be Offset: 250

2) In kobopatch.yaml

# files:
# src/whatever.txt: usr/local/Kobo/whatever.txt

No space is allowed before "files:"

1. You can also add a 0x before the hex value.
2. You need to uncomment and remove the space.

[NiLuJe]

@geek1011: In the nickel patches, I'm guessing "Remove recommendations (row1col2) from home screen" should be part of the "Home screen tweaks" group, because it breaks the match against "#row1col2" that "Remove footer (row3) and increase cover size on new home screen" & "Remove footer (row3) on new home screen" rely on .

[geek1011]

Originally Posted by NiLuJe

@geek1011: In the nickel patches, I'm guessing "Remove recommendations (row1col2) from home screen" should be part of the "Home screen tweaks" group, because it breaks the match against "#row1col2" that "Remove footer (row3) and increase cover size on new home screen" & "Remove footer (row3) on new home screen" rely on .

Thanks! I've modified the patches to make them both work at the same time.

[NiLuJe]

FWIW, automation is a go .

(That's highly unportable and pretty specific to my own setup, but, hey, if it can give someone else ideas... ).

Which leads me to a minor question, @geek1011:

Can I forgo commenting the default blank overrides: in the config and just append mine at the bottom of the file? (I won't ask you to make it commented out by default, because I know how confusing that might be to some users, as #110 just proved ).

[Terisa de morgan]

I,ve got the four overriden uncommented and only two with active patches. Is that what you need? And the problem in the message wasn't the comment but the format deppending on exact indentation

[geek1011]

Originally Posted by NiLuJe

FWIW, automation is a go .

(That's highly unportable and pretty specific to my own setup, but, hey, if it can give someone else ideas... ).

Looks good!

Originally Posted by NiLuJe

Can I forgo commenting the default blank overrides: in the config and just append mine at the bottom of the file? (I won't ask you to make it commented out by default, because I know how confusing that might be to some users, as #110 just proved ).

No, I enabled strict parsing (to make it easier for users to spot errors), so that won't work.

[JSWolf]

If we change some of the values in the patches, will the new patch system remember this? If not, can it be written to remember?

[geek1011]

Originally Posted by JSWolf

If we change some of the values in the patches, will the new patch system remember this? If not, can it be written to remember?

No, it won't. It could be made to, but for simplicity, I suggest making a copy of the patch into an additional patch file, as described in the tips and tricks at the start of this thread. If there is enough demand, I might make it.

[JSWolf]

Originally Posted by geek1011

No, it won't. It could be made to, but for simplicity, I suggest making a copy of the patch into an additional patch file, as described in the tips and tricks at the start of this thread. If there is enough demand, I might make it.

It would be a useful feature. And isn't the idea with the new patching system to make things easier?

[geek1011]

Originally Posted by JSWolf

It would be a useful feature. And isn't the idea with the new patching system to make things easier?

Yep, but both in the code, maintenance, and usage. Currently, kobopatch is only 130% the LOC compared to patch32lsb (including tests, which makes it easier to code), yet it has more features. It already has features to make maintenance easier (FindZlib, FindZlibHash, ReplaceZlib, FindReplaceString, ResetBaseAddress, automated patch testing, etc). It has features to make usage easier (multiple patch files for single binary, add arbitrary files to KoboRoot, compiling and adding translations, store patch enabled state in config file). I'm trying to balance the ease of use with the ease of maintenance and code.

If I can figure out an easy and elegant way to store changes to variables in patches, I'll implement it.