kobopatch - A new (WIP) patching system

[jackie_w]

Originally Posted by geek1011

Can someone on windows who is willing and knows how to restore a SD card image test out the patch zip? It seems to work fine in everything except for WinRAR, and it works fine with all the Linux and Mac OS tools so I think it should be safe to try. I know the Linux version works though, as I tried it on both my Kobos.

Well, in the interests of progress, I downgraded the status of my old Glo to "sacrificial goat", held my breath and uploaded a KoboRoot.tgz (contained all 4 patchable files) created with the Win 64-bit version of kobopatch v5.1. It seems to work OK!

Getting cocky I enabled a couple of extra patches in nickel.yaml and tried it again. Again, no obvious ill effects and the extra patch changes were visible.

[geek1011]

Originally Posted by jackie_w

Well, in the interests of progress, I downgraded the status of my old Glo to "sacrificial goat", held my breath and uploaded a KoboRoot.tgz (contained all 4 patchable files) created with the Win 64-bit version of kobopatch v5.1. It seems to work OK!

Getting cocky I enabled a couple of extra patches in nickel.yaml and tried it again. Again, no obvious ill effects and the extra patch changes were visible.

Yay! If it boots, then the patches either worked or did not apply at all. Can you see if this tgz triggers an error in WinRAR (I think it should, which would prove WinRAR is buggy)?

[geek1011]

Originally Posted by boriar

@geek1011
What do you think about that:
For implement my idea from here may be a good way process firstly the user list of patches (an unique file for all patches enables and disables) to write temporary individual files for each archive (nickel, libnickel, etc) to use with your kobopatch. With that way the complexity and delay will be little

Your first idea would add complexity, but I could do something like your second. Do you mean that I should ship the original binaries with kobopatch so users do not need to download them?

[jackie_w]

Originally Posted by geek1011

Can you see if this tgz triggers an error in WinRAR (I think it should, which would prove WinRAR is buggy)?

WinRar still only sees 2 files for me. 7-zip sees all 4.

[geek1011]

Originally Posted by jackie_w

WinRar still only sees 2 files for me. 7-zip sees all 4.

Good. I think it can be concluded that WinRAR is buggy and that kobopatch works well.

[boriar]

Originally Posted by geek1011

Your first idea would add complexity, but I could do something like your second. Do you mean that I should ship the original binaries with kobopatch so users do not need to download them?

No.
User copy&paste all patches in the new format in the same archive (i.e. fwpatch.yaml) along with already existing patch. Of course, each patch must have a variable indicating the archive to patch (nickel, libnickel, etc)

Something like:

Spoiler:

# Multi-version patch: 4.6.9960 - 4.8.10956+
Disable reading footer:
- Enabled: no
- PatchFile: nickel
- PatchGroup: Reading footer alternatives
- Description: |
Removes the reading footer for both ePub and KePub books, leaving a 15px
bottom margin which matches the 15px built-in top margin of ePub books.
- FindBaseAddressString: "ReadingFooter {\n qproperty-footerMargin: 105;\n}\n"
- ReplaceString: {Offset: 0x0000, Find: "ReadingFooter {\n qproperty-footerMargin: 105;\n}\n", Replace: "ReadingFooter {min-height:15px;max-height:15px;}\n"}
- FindBaseAddressString: "#caption[qApp_deviceIsTrilogy=true] {\n font-size: 19px;"
- ReplaceString: {Offset: 0x0000, Find: "#caption[qApp_deviceIsTrilogy=true] {\n font-size: 19px;\n}\n", Replace: "#caption {font-size:1px;color:transparent;}\n\0"}

When someone use kobopath, the program first read the file fwpatch.yaml and write a temporary file for each archive to patch (nickel.yaml, libnickel.yaml, etc). Then read each new file and execute the patch like it do now.

Finally, all temporary files are deleted.

The idea behind it is that, when a new patch come to forum, the user should not worry where to put it. All must be copy in the same file without error possibility.
---------------------------
About multipart patch for two archive:

I suppose that the variable "PatchGroup" work checking if only one in the same group are enable. So if all patch are in the same file you can add a new variable "MultiPatch" checking that all patch in the same group are enable at first read.

Something like that:

Spoiler:

# Multi-version patch: 4.7.10413 - 4.8.10956+
Force user line spacing in ePubs (part 1 of 2):
- Enabled: yes
- PatchFile: libnickel.so.1.0.0
- MultiPatch: Line spacing in ePubs
- Description: |
This is part 1 of 2. Also enable part 2 in librmsdk.so.1.0.0.patch
This patch prevents any line-height style set in the book's stylesheet from
being recognised. It will spoil the formatting of some books, but will
ensure that the line spacing set with the adjustment slider takes effect.
- FindBaseAddressString: "\0\0\x20line-height: %1"
- ReplaceString: {Offset: 0x0003, Find: "l", Replace: "_"}


# Multi-version patch: 3.3.0 - 4.8.10956+
Force user line spacing in ePubs (Part 2 of 2):
- Enabled: yes
- PatchFile: librmsdk.so.1.0.0
- MultiPatch: Line spacing in ePubs
# This is part 2 of 2. Also enable part 1 in libnickel.so.1.0.0.patch
#
# This patch prevents any line-height style set in the book's stylesheet from
# being recognised. It will spoil the formatting of some books, but will ensure
# that the line spacing set with the adjustment slider takes effect. (Unless
# the publisher has used the font shorthand style; see option below.)
- FindBaseAddressString: "\0line-height\0"
- ReplaceString: {Offset: 0x0001, Find: "l", Replace: "_"}
#
# Uncomment the following two lines to also prevent the font shorthand style
# from being recognised. The font shorthand style is not very common in ePubs,
# but where used it can also prevent the line spacing from being adjusted.
# Beware that this option will likely have much bigger side-effects on the
# book's formatting, because the font shorthand style is used to set the
# font-size, font family, and other styles in addition to line-height.
#
# - FindBaseAddressString: "\0font\0"
# - ReplaceString: {Offset: 0x0001, Find: "f", Replace: "_"}

[Terisa de morgan]

Originally Posted by geek1011

Good. I think it can be concluded that WinRAR is buggy and that kobopatch works well.

I'm not so sure. I would say yes if WinRar always worked wrong... but only with this utility? Not convincing

[boriar]

Originally Posted by Terisa de morgan

I'm not so sure. I would say yes if WinRar always worked wrong... but only with this utility? Not convincing

When I decided to make my own megapack (for my use) on Windows, I have to left apart winrar for the same reason. The package always produced errors an then change to 7za

[Terisa de morgan]

Originally Posted by geek1011

Edit: can you also try using https://github.com/mholt/archiver to create a tar.gz out of some files and see if it also gives you an issue with WinRAR.

No, this exe file doesn't give any problem when it creates a tar.gz file

[geek1011]

Originally Posted by Terisa de morgan

No, this exe file doesn't give any problem when it creates a tar.gz file

That's really unusual. It creates the tar.gz in exactly the same way. The only explanation is the changes to the archive/tar package in the recent versions of go. Anyways, the patching has worked fine on the Kobo and with all Linux utilities I've tried, so I think it should be fine to ignore the WinRAR errors for now.

I'd love to know if someone figured out what's wrong with WinRAR.

[geek1011]

Originally Posted by boriar

When I decided to make my own megapack (for my use) on Windows, I have to left apart winrar for the same reason. The package always produced errors an then change to 7za

What tool did you use to create the erroneous archive?

[geek1011]

Originally Posted by boriar

No.
User copy&paste all patches in the new format in the same archive (i.e. fwpatch.yaml) along with already existing patch. Of course, each patch must have a variable indicating the archive to patch (nickel, libnickel, etc)

Something like:

Spoiler:

# Multi-version patch: 4.6.9960 - 4.8.10956+
Disable reading footer:
- Enabled: no
- PatchFile: nickel
- PatchGroup: Reading footer alternatives
- Description: |
Removes the reading footer for both ePub and KePub books, leaving a 15px
bottom margin which matches the 15px built-in top margin of ePub books.
- FindBaseAddressString: "ReadingFooter {\n qproperty-footerMargin: 105;\n}\n"
- ReplaceString: {Offset: 0x0000, Find: "ReadingFooter {\n qproperty-footerMargin: 105;\n}\n", Replace: "ReadingFooter {min-height:15px;max-height:15px;}\n"}
- FindBaseAddressString: "#caption[qApp_deviceIsTrilogy=true] {\n font-size: 19px;"
- ReplaceString: {Offset: 0x0000, Find: "#caption[qApp_deviceIsTrilogy=true] {\n font-size: 19px;\n}\n", Replace: "#caption {font-size:1px;color:transparent;}\n\0"}

When someone use kobopath, the program first read the file fwpatch.yaml and write a temporary file for each archive to patch (nickel.yaml, libnickel.yaml, etc). Then read each new file and execute the patch like it do now.

Finally, all temporary files are deleted.

The idea behind it is that, when a new patch come to forum, the user should not worry where to put it. All must be copy in the same file without error possibility.
---------------------------
About multipart patch for two archive:

I suppose that the variable "PatchGroup" work checking if only one in the same group are enable. So if all patch are in the same file you can add a new variable "MultiPatch" checking that all patch in the same group are enable at first read.

Something like that:

Spoiler:

# Multi-version patch: 4.7.10413 - 4.8.10956+
Force user line spacing in ePubs (part 1 of 2):
- Enabled: yes
- PatchFile: libnickel.so.1.0.0
- MultiPatch: Line spacing in ePubs
- Description: |
This is part 1 of 2. Also enable part 2 in librmsdk.so.1.0.0.patch
This patch prevents any line-height style set in the book's stylesheet from
being recognised. It will spoil the formatting of some books, but will
ensure that the line spacing set with the adjustment slider takes effect.
- FindBaseAddressString: "\0\0\x20line-height: %1"
- ReplaceString: {Offset: 0x0003, Find: "l", Replace: "_"}


# Multi-version patch: 3.3.0 - 4.8.10956+
Force user line spacing in ePubs (Part 2 of 2):
- Enabled: yes
- PatchFile: librmsdk.so.1.0.0
- MultiPatch: Line spacing in ePubs
# This is part 2 of 2. Also enable part 1 in libnickel.so.1.0.0.patch
#
# This patch prevents any line-height style set in the book's stylesheet from
# being recognised. It will spoil the formatting of some books, but will ensure
# that the line spacing set with the adjustment slider takes effect. (Unless
# the publisher has used the font shorthand style; see option below.)
- FindBaseAddressString: "\0line-height\0"
- ReplaceString: {Offset: 0x0001, Find: "l", Replace: "_"}
#
# Uncomment the following two lines to also prevent the font shorthand style
# from being recognised. The font shorthand style is not very common in ePubs,
# but where used it can also prevent the line spacing from being adjusted.
# Beware that this option will likely have much bigger side-effects on the
# book's formatting, because the font shorthand style is used to set the
# font-size, font family, and other styles in addition to line-height.
#
# - FindBaseAddressString: "\0font\0"
# - ReplaceString: {Offset: 0x0001, Find: "f", Replace: "_"}

Ok, I can easily add the PatchGroup feature, but I don't think putting all the patches in the same file is a good idea (for example, the nickel css patches are long and would clutter up the file and make it hard to read).

[latepaul]

FWIW I just tested the file attached to post #45 with Winrar 5.5 and 5.6beta3 and both versions see all 4 files.

[geek1011]

Originally Posted by latepaul

FWIW I just tested the file attached to post #45 with Winrar 5.5 and 5.6beta3 and both versions see all 4 files.

Thanks for testing it. I wonder what version Terisa and Oren were using which caused the issue? This problem is getting really bizarre.


Also, on a side note, kobo pulled the latest firmware, but the links to download it still work.

[Terisa de morgan]

With WinRar 5.40 (64 bits), the file in post #45 is corrupt.