-
Couldn't load subscription status.
- Fork 213
chromium: Fix patch enumeration #739
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chromium: Fix patch enumeration #739
Conversation
|
Also, this PR maybe isn't the perfect place for it, but as it's already about patch numbers: do we just keep increasing the patch numbers forever, even as we remove some patches over time? There are quite a few holes in our numbering already. |
When I worked on recipe updates on my own, I think I ended up prefixing everything with "0001" because I was doing it manually (except if I was backporting a patchset with multiple patches). If you're using |
I tried getting it to work, but wasn't able to. I currently just do it by hand.
I couldn't find any in a quick search, and looking at some meta-oe recipes, it seems like there aren't any re: numbering. I've seen recipes that don't have numbers at all, some have multiple different patches with the same number, some have a mix of numbered and un-numbered patches. I quite like the numbering, so I'd propose we always ensure the numbers increase by one (i.e. no holes). To avoid frequent renaming, it might make sense to have a separate naming scheme for backports, I think just omitting the number for backports would be fine. Wdyt? |
In the past I used to do the opposite: use numbers for the backports (simply because it was easier to use Note that either workflow will probably break if someone decides to use |
|
I think on major version upgrades it can be renumbered if some get dropped. If you use devtool workflow this should happen automagically. |
I'd forgotten about this, thanks for reminding me about it. As mentioned above, I had some problems using devtool, so in the end I just wrote my own script that does everything (except resolving conflicts, of course). My personal preference would be to keep the numbering for non-backport patches (always increasing by one), and name the backports "Backport-XXX.patch", so that we don't have to frequently re-number the non-backports. Let me know if you think that's a bad idea; if not, I'll update this PR to apply the new scheme once #757 has been merged. |
|
Devtool drops backports if they are straight forward automatically as well but prefixing the name is fine it makes it readable |
* Move ARM-specific patches to a separate folder like we already have for musl. * Move backported patches to a separate folder and don't number them. * Re-number all non-backported patches so that the patch number always increases by 1. Signed-off-by: Max Ihlenfeldt <max@igalia.com>
7f53f10 to
260a406
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall this looks fine to me. How does it go with devtool ? I think it will be cool to get it friendly to devtool as well while you are here
I'm not very familiar with devtool, and the times I've tried to figure out the update workflow for Chromium it didn't work... but if you can share the needed devtool steps, I'm happy to make sure it works well with the re-organized patches. |
|
|
Thanks! However, |
Yeah that’s fine I think @shr-project had it working iirc in past |
Missed in #738 that we already have
0031-Fix-ARM-build-with-recent-glibc.patch.