Quote:
Originally Posted by JSWolf
And one thing you can do that would help. If anyone using this selects a patch that throws up an error, log it and post in this thread that it doesn't work and I can update the ZIP file and the second post. Then you can read in the new file and so on. That way, we can whittle done which patches do not work.
|
You know I wrote a tool for that which I use to maintain the patches (I should really get back to that...).
I could put together a guide (or otherwise show you and jackie_w) about how to do the whole patch thing and do proper releases on GitHub.
The main idea is:
- Create a GitHub issue to track the stuff for the firmware version.
- Run mktestdata in kobopatch-testdata on all firmware zips and ensure they're the same, then commit one of them (if I haven't already done that).
- Extract the testdata.
- Run symdump (from kobopatch) on nickel and libnickel (optional, but useful for debugging), and sort+diff the names (strongly recommended to get an idea of what changed).
- Run strings on nickel and libnickel and diff it (strongly recommended to get an idea of what changed).
- Run armqrc.py (from qrc) and qrc2zip on nickel (optional, but useful for writing patches).
- Copy the previous firmware folder in kobopatch-patches src/versions to the new firmware version.
- Run scripts/test to find the ones which don't work and fix the low-hanging ones.
- Commit the changes.
- Commit any fixes for other patches.
- Test the final patch zip by running scripts/build with the firmware version.
- Once ready, create tag with name v(prev+1).
- Wait for the patch zips to be automatically built.
- Write the release notes and publish the automatically created draft release.
- Copy the last post from the mr-posts branch and update it for the new firmware info (use kobo-versionextract in koboutils to get it), then post it to MR and commit it back to the branch named after the post ID in the URL.
Alternatively, I could at least add the patch updates so far to the GH repo without creating a release and give you both write access (jackie_w already does) so you can make use of the automated testing without needing to set it all up locally.