| Message ID | 20250624104155.559827-1-yi.zhao@windriver.com |
|---|---|
| Headers | show |
| Series | fix runtime versions | expand |
On Tue, 24 Jun 2025 at 12:42, Yi Zhao via lists.openembedded.org <yi.zhao=eng.windriver.com@lists.openembedded.org> wrote: > This series of patches was sent in April. Ross suggested discussing this > with upstream to see if they could update the scripts to address the > issue. I talked to upstream and they declined because they believed that > "autoreconf may result in different built source code than what has been > distributed"[1]. Is there a benefit of carrying these patches in core to the broader community? I don't think anyone's particularly confused or misled by 'unknown' reported by executables at runtime, we have procedures to verify that what we build is exactly what upstream has released, and various built time reporting mechanisms to see the versions. Wind River obviously has invested a lot of time and effort into this, presumably because it has a paying customer that is obsessed about what executables on target say, but I do struggle to justify carrying and maintaining these fixes. Alex
On Tue, 2025-06-24 at 12:50 +0200, Alexander Kanavin via lists.openembedded.org wrote: > On Tue, 24 Jun 2025 at 12:42, Yi Zhao via lists.openembedded.org > <yi.zhao=eng.windriver.com@lists.openembedded.org> wrote: > > This series of patches was sent in April. Ross suggested discussing this > > with upstream to see if they could update the scripts to address the > > issue. I talked to upstream and they declined because they believed that > > "autoreconf may result in different built source code than what has been > > distributed"[1]. > > Is there a benefit of carrying these patches in core to the broader > community? I don't think anyone's particularly confused or misled by > 'unknown' reported by executables at runtime, we have procedures to > verify that what we build is exactly what upstream has released, and > various built time reporting mechanisms to see the versions. > > Wind River obviously has invested a lot of time and effort into this, > presumably because it has a paying customer that is obsessed about > what executables on target say, but I do struggle to justify carrying > and maintaining these fixes. I guess it raises the question of patch vs sed too. Would this be more maintainable if we just had a common sed like function to take these out of autogen.sh? If it breaks, it isn't the end of the world... There is the advantage that it is relatively standardised. Cheers, Richard
On 6/24/25 18:50, Alexander Kanavin wrote: > On Tue, 24 Jun 2025 at 12:42, Yi Zhao via lists.openembedded.org > <yi.zhao=eng.windriver.com@lists.openembedded.org> wrote: >> This series of patches was sent in April. Ross suggested discussing this >> with upstream to see if they could update the scripts to address the >> issue. I talked to upstream and they declined because they believed that >> "autoreconf may result in different built source code than what has been >> distributed"[1]. > Is there a benefit of carrying these patches in core to the broader > community? I don't think anyone's particularly confused or misled by > 'unknown' reported by executables at runtime, we have procedures to > verify that what we build is exactly what upstream has released, and > various built time reporting mechanisms to see the versions. > > Wind River obviously has invested a lot of time and effort into this, > presumably because it has a paying customer that is obsessed about > what executables on target say, but I do struggle to justify carrying > and maintaining these fixes. This is exposed by version check using check-version-mismatch.bbclass. In some cases, a mismatch between the runtime version and the build-time version can cause confusion for users. On the other hand, this suffix does not exist in other distributions. I will follow Richard's suggestion. Use a more standardized approach. Thanks, Yi > > Alex
On Tue, 2025-06-24 at 18:41 +0800, Yi Zhao via lists.openembedded.org wrote: > This series of patches was sent in April. Ross suggested discussing this > with upstream to see if they could update the scripts to address the > issue. I talked to upstream and they declined because they believed that > "autoreconf may result in different built source code than what has been > distributed"[1]. > I found that Debian maintains a similar patch in their own repo[2], as > it was also rejected upstream[3]. > > > [1] https://lists.gnupg.org/pipermail/gnupg-devel/2025-May/035913.html > [2] https://salsa.debian.org/debian/gnupg2/-/blob/debian/unstable/debian/patches/debian-packaging/avoid-beta-warning.patch > [3] https://lists.gnupg.org/pipermail/gnupg-devel/2014-November/029068.html > > Yi Zhao (8): > libgpg-error: drop -unknown suffix from version number > pinentry: drop -unknown suffix from version number > libgcrypt: drop -unknown suffix from version number > gnupg: drop -unknown suffix from version number > libassuan: drop -unknown suffix from version number > libksba: drop -unknown suffix from version number > procps: fix runtime version when using git shallow tarball > psmisc: fix runtime version when using git shallow tarball I did also want to ask if WindRiver have considered a slightly different approach to testing some of this. We already have some tests which run things like "dnf --help" and "dnf --version" on the target using the runtime testing. Those did catch a missing dependency in the recent dnf upgrade so they do add some value. I've been wondering for a while about extending this to run those kinds of options against more of our binaries. In this specific case, we could check that "unknown" doesn't creep back in. Is that something WindRiver would be intersted in extending our runtime tests to do, at least for some set of binaries. We can guard the tests on whether the images contain the appropriate packages. Cheers, Richard