Quote:
Originally Posted by GeoffR
I find the new system more difficult than the old one when it comes to updating the patches, that is very likely just that I have become so used to the old way, but there are a couple of specific things that might help:
Does anyone know of a working yaml-mode for Emacs 24? The one on the Debian repository is a bit glitchy.
Is there a way to run kobopatch on a single yaml file that is equivalent to:
Code:
patch32lsb -i libnickel.so.1.0.0 -p libnickel.so.1.0.0.patch -o out
I do this a lot, combined with objdump, to compare before and after and to check for mistakes as I go. |
As for emacs, I would suggest using VSCode instead for editing kobopatch files, as it's yaml (and Go) support is really great (outline, syntax highlighting, folding, performance, git integration, etc). Also, it's diffs are useful.
As for the last thing you do, I can put together a tool later today. It's pretty simple, as the patching functionality is separated into a Go package.
My workflow is slightly different. I usually first run "./scripts/build.sh;./scripts/test.sh" after making a folder for the new firmware and copying the previous patches (note that a tarball needs to be out in the testdata dir with the binaries for the firmware). This tells me the most obviously broken patches. I then fix the easy ones with objdump (passed through c++filt), and try applying them. If they work, I continue on to the more complex ones. I use the Hopper dissembler for this, as it allows me to easily make modifications, and export executables (which I copy and test over telnet). It also has really good tools for viewing the assembly in different forms (hex, cfg, pseudocode, custom types, etc). Finally, I update the patch files and build a zip. I enable all the patches, and test the functionality of each one. To release the patches, I make a new git tag.
If you have any further questions, I'd be happy to answer them.
Also note that I probably won't have time to update all the patches from scratch in the next firmware version, as I don't usually have so much spare time. I will still be able to port your changes, update the other patches, and make a release, but you'll need to do most of the updating like usual.