Yeah, that's not the right way. Then it would be 3.0.13-0ubuntu1, and not changed in the upstream version. Which is OK too, but I went ahead and imported a git-archive export as 3.0.13+git20210716.269ef9d-1 in the Debian repository and uploaded that to experimental with any-riscv64 (and any-ia64) added to Architecture.
In the PPA, there are a bunch of other changes to debian/rules that are not advertised, such as
- changing from /usr/lib{32,64} to multi-arch paths (which is not where stuff looks for it)
- a redundant addition of an arm64 architecture (any-arm64 is there already)
- I guess cross-compilation support?
I don't think we can apply the first one. We can apply the third one in another upload, but I do want it mentioned in the changelog what's going on. Well optimally, can you submit a merge against the gnu-efi salsa repo with the compilation changes and describe it in the commit message (first line will be used as changelog entry)? That would be best!
Yeah, that's not the right way. Then it would be 3.0.13-0ubuntu1, and not changed in the upstream version. Which is OK too, but I went ahead and imported a git-archive export as 3.0.13+ git20210716. 269ef9d- 1 in the Debian repository and uploaded that to experimental with any-riscv64 (and any-ia64) added to Architecture.
In the PPA, there are a bunch of other changes to debian/rules that are not advertised, such as
- changing from /usr/lib{32,64} to multi-arch paths (which is not where stuff looks for it)
- a redundant addition of an arm64 architecture (any-arm64 is there already)
- I guess cross-compilation support?
I don't think we can apply the first one. We can apply the third one in another upload, but I do want it mentioned in the changelog what's going on. Well optimally, can you submit a merge against the gnu-efi salsa repo with the compilation changes and describe it in the commit message (first line will be used as changelog entry)? That would be best!