Skip to content

Conversation

@MaxIhlenfeldt
Copy link
Collaborator

Missed in #738 that we already have 0031-Fix-ARM-build-with-recent-glibc.patch.

@MaxIhlenfeldt MaxIhlenfeldt requested a review from rakuco August 3, 2023 11:23
@MaxIhlenfeldt
Copy link
Collaborator Author

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.

@rakuco
Copy link
Collaborator

rakuco commented Aug 3, 2023

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 devtool I think it's done automatically, otherwise I personally don't mind what the patch number is. Not sure if there are official guidelines from OE though?

@MaxIhlenfeldt
Copy link
Collaborator Author

If you're using devtool I think it's done automatically

I tried getting it to work, but wasn't able to. I currently just do it by hand.

Not sure if there are official guidelines from OE though?

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?

@rakuco
Copy link
Collaborator

rakuco commented Aug 3, 2023

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 git format-patch on an upstream checkout and copy the patch file here without having to rename it) and not use numbers for things that remain, like 0003-v8-qemu-wrapper.patch.

Note that either workflow will probably break if someone decides to use devtool in the future -- see commit 98b68ba which renamed several patches, for example.

@kraj
Copy link
Collaborator

kraj commented Oct 10, 2023

I think on major version upgrades it can be renumbered if some get dropped. If you use devtool workflow this should happen automagically.

@MaxIhlenfeldt
Copy link
Collaborator Author

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.

@kraj
Copy link
Collaborator

kraj commented Oct 12, 2023

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>
@MaxIhlenfeldt MaxIhlenfeldt force-pushed the fix-patch-enumeration branch 2 times, most recently from 7f53f10 to 260a406 Compare October 30, 2023 18:35
@MaxIhlenfeldt
Copy link
Collaborator Author

@rakuco @kraj please let me know if you agree with the re-organization I've applied in this PR's latest commit.

Copy link
Collaborator

@kraj kraj left a 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

@MaxIhlenfeldt
Copy link
Collaborator Author

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.

@kraj
Copy link
Collaborator

kraj commented Nov 2, 2023

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.

devtool modify chromium-x11
devtool build chromium-x11

@MaxIhlenfeldt
Copy link
Collaborator Author

Thanks! However, devtool modify chromium-x11 already gives me an error. I don't think it's worth spending more time trying to get this to work, as I already have a functional workflow. If this PR makes devtool harder to use, we can just fix it in a follow-up. Thus, I'll go ahead and merge this, so I can start working on the 118 update.

@MaxIhlenfeldt MaxIhlenfeldt merged commit d5542fc into OSSystems:master Nov 2, 2023
@kraj
Copy link
Collaborator

kraj commented Nov 2, 2023

Thanks! However, devtool modify chromium-x11 already gives me an error. I don't think it's worth spending more time trying to get this to work, as I already have a functional workflow. If this PR makes devtool harder to use, we can just fix it in a follow-up. Thus, I'll go ahead and merge this, so I can start working on the 118 update.

Yeah that’s fine I think @shr-project had it working iirc in past

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants