kobopatch - An improved patching system - Page 3

Terisa de morgan · 05-29-2018, 01:12 PM

Yes, exactly that. I've seen a couple of patches with that comment, and some in nickel have the same recommendation

geek1011 · 05-29-2018, 01:38 PM

Boriar's idea would be good except that I want to maintain as much compatibility as possible with the original patcher, at least for now.

The way I would probably do it is if two patches have the same name (minus part n of n) and one is enabled, the other would automatically be enabled as well.

npr · 05-30-2018, 02:10 PM

When I first tried this new patching system I had problems with the error: patch_group should not be a comment.
I was using the patches as published by GeoffR which in some cases have the commented line "# patch_group = "
After removing the comment marker (#), from these "patch_group=" lines, the patch progressed ok.

Bit of a pain going through the patches and editing the problem lines rather spoils using the nice kobopatch.yaml feature. I assume this is a temporary glich.

Once the files had been patched I compared them with those from the original patcher and they where reported as being identical.

geek1011 · 05-30-2018, 02:17 PM

Quote:

Originally Posted by npr

When I first tried this new patching system I had problems with the error: patch_group should not be a comment.
I was using the patches as published by GeoffR which in some cases have the commented line "# patch_group = "
After removing the comment marker (#), from these "patch_group=" lines, the patch progressed ok.

Bit of a pain going through the patches and editing the problem lines rather spoils using the nice kobopatch.yaml feature. I assume this is a temporary glich.

Once the files had been patched I compared them with those from the original patcher and they where reported as being identical.

Yep. Thanks for trying it out! As for the error, that is supposed to happen, as the old patcher did not support the patch_group instruction, so it was commented out. My automated conversion tool fixes that for all the default patches, but for individual patches, you'll need to do it manually.

npr · 05-30-2018, 02:41 PM

I'm sure you know best. But to me, it just seems wrong not to ignore a commented out command.

JSWolf · 05-30-2018, 02:57 PM

If this new patching system cannot handle allowing us to change things, then it's of no use. I do make some changes to fit my needs. If I cannot do this, then I prefer to stick to the current system until such times as this can be fixed to allow changes to be made.

Terisa de morgan · 05-30-2018, 03:49 PM

Quote:

Originally Posted by JSWolf

If this new patching system cannot handle allowing us to change things, then it's of no use. I do make some changes to fit my needs. If I cannot do this, then I prefer to stick to the current system until such times as this can be fixed to allow changes to be made.

Sorry, JSWolf, but I think you're understanding it wrong. You can patch this in the same way that till this moment. What other users are requesting is a wat of not having to modify EVERY SINGLE VERSION OF A PATCH, and instead keep the change in a configuration file you can use in every version (till the patch changes, that is).

JSWolf · 05-30-2018, 04:02 PM

Quote:

Originally Posted by Terisa de morgan

Sorry, JSWolf, but I think you're understanding it wrong. You can patch this in the same way that till this moment. What other users are requesting is a wat of not having to modify EVERY SINGLE VERSION OF A PATCH, and instead keep the change in a configuration file you can use in every version (till the patch changes, that is).

Please explain the following from this thread please.

Quote:

Originally Posted by Terisa de morgan

I have a question. There are some patches that, aside of been enabled or no, accept some customization (Custom footer (page number text), for example). How would you handle it here?

Quote:

Originally Posted by geek1011

I wouldn't. That's currently beyond the scope of kobopatch, because there is no clean way it can be implemented (covering edge cases, validation) and it would make it a bit confusing to use. I also wanted to keep as much logic as possible in the patch files itself to make it easier to maintain (it's currently the same number of lines of code as the original one). More complexity means more bugs and less checks. The way I was considering was a variables section in kobopatch.yaml which is substituted into all patches which match, but I decided against it. Also keep in mind that users may not necessarily know how to use the feature.

If one of you can think of a better way to implement this, I'd be happy to consider it.

Also, what would you think of a print instruction to show a message to the user during patching? This would be useful to inform about dangerous patches or things like that.

To me, that reads like it's not possible to make changes to the patches.

Terisa de morgan · 05-30-2018, 04:38 PM

Quote:

Originally Posted by JSWolf

To me, that reads like it's not possible to make changes to the patches.

To me, it reads as the tool is not going to handle customization, in the same way that the current tool doesn't handle it either. And no, the current tool doesn't handle it, you have to modify the patch, and in the same way you can do it here (I've done it).

geek1011 · 05-30-2018, 07:04 PM

Quote:

Originally Posted by JSWolf

Please explain the following from this thread please.

To me, that reads like it's not possible to make changes to the patches.

I'm sorry about the misunderstanding.

What is happening is my patching system currently does everything the old one does, and more. What they want is to be able to find and replace instructions from the main config file (not the patch files) to make it easier to upgrade versions. I'm saying it would make validation of the actual patch files harder if the patch can be modified from more than one location. You can still modify the patch files manually and do more than you could with the old patching system.

Hope this clears things up.

Feel free to ask if you need more clarification.

sherman · 06-02-2018, 04:22 AM

Quote:

Originally Posted by npr

I'm sure you know best. But to me, it just seems wrong not to ignore a commented out command.

Note that the sole purpose of `patch_group` being added in the first place was so that my (sadly neglected) GUI would have some way of knowing which patches were mutually exclusive. In other words, GeoffR kindly added it at my request.

geek1011 is correct in that GeoffR's patcher never used it.

boriar · 06-02-2018, 07:16 AM

Quote:

Originally Posted by sherman

Note that the sole purpose of `patch_group` being added in the first place was so that my (sadly neglected) GUI would have some way of knowing which patches were mutually exclusive. In other words, GeoffR kindly added it at my request.

geek1011 is correct in that GeoffR's patcher never used it.

Why not to update your GUI (very useful for me

) to the new format? It's more consistent and flexible.

mobama · 06-02-2018, 11:46 AM

I'm trying to use it in Linux, but I get the following error:

Quote:

Patching ./usr/local/Kobo/nickel
Fatal: Could not read and parse patch file src/nickel.patch: could not open patch file: open src/nickel.patch: no such file or directory

What am I doing wrong?

geek1011 · 06-02-2018, 05:05 PM

Quote:

Originally Posted by mobama

I'm trying to use it in Linux, but I get the following error:

What am I doing wrong?

If you are trying to use the 3.19.5761 patch zip, you'll need to remove the nickel line from kobopatch.yaml, as there are no nickel patches for that version.

geek1011 · 06-02-2018, 05:07 PM

Quote:

Originally Posted by boriar

Why not to update your GUI (very useful for me

) to the new format? It's more consistent and flexible.

There is the code I use to parse the new format in https://github.com/geek1011/kobopatc...h/kobopatch.go .

Also, I might write a GUI for kobopatch if nobody else wants to and there is enough demand for it.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
kobopatch - A new (WIP) patching system	geek1011	Kobo Developer's Corner	93	05-27-2018 03:04 PM
Patching H2O	Maillemom	Kobo Developer's Corner	8	10-19-2016 09:58 AM
Instructions for patching firmware 3.17.3	GeoffR	Kobo Developer's Corner	60	09-17-2015 05:35 PM
Instructions for patching firmware 3.8.0	GeoffR	Kobo Developer's Corner	92	10-22-2014 07:22 AM
how to clean more disk space in root file system to upgrade system	chinaet	iRex	1	12-18-2006 03:54 PM

05-29-2018, 01:12 PM	#31
Terisa de morgan Grand Sorcerer Posts: 6,227 Karma: 11768331 Join Date: Jun 2009 Location: Madrid, Spain Device: Kobo Clara/Aura One/Forma,XiaoMI 5, iPad, Huawei MediaPad, YotaPhone 2	Yes, exactly that. I've seen a couple of patches with that comment, and some in nickel have the same recommendation

05-29-2018, 01:38 PM	#32
geek1011 Wizard Posts: 2,730 Karma: 6675565 Join Date: May 2016 Location: Ontario, Canada Device: Kobo Mini, Aura Edition 2 v1, Clara HD	Boriar's idea would be good except that I want to maintain as much compatibility as possible with the original patcher, at least for now. The way I would probably do it is if two patches have the same name (minus part n of n) and one is enabled, the other would automatically be enabled as well.

05-30-2018, 02:10 PM	#33
npr Zealot Posts: 102 Karma: 37418 Join Date: Jan 2013 Device: Kobo Glo, Aura, H2OE2, Libra 2	When I first tried this new patching system I had problems with the error: patch_group should not be a comment. I was using the patches as published by GeoffR which in some cases have the commented line "# patch_group = " After removing the comment marker (#), from these "patch_group=" lines, the patch progressed ok. Bit of a pain going through the patches and editing the problem lines rather spoils using the nice kobopatch.yaml feature. I assume this is a temporary glich. Once the files had been patched I compared them with those from the original patcher and they where reported as being identical.

05-30-2018, 02:41 PM	#35
npr Zealot Posts: 102 Karma: 37418 Join Date: Jan 2013 Device: Kobo Glo, Aura, H2OE2, Libra 2	I'm sure you know best. But to me, it just seems wrong not to ignore a commented out command.

05-30-2018, 02:57 PM	#36
JSWolf Resident Curmudgeon Posts: 73,877 Karma: 128597114 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	If this new patching system cannot handle allowing us to change things, then it's of no use. I do make some changes to fit my needs. If I cannot do this, then I prefer to stick to the current system until such times as this can be fixed to allow changes to be made.