Bug 16093

Summary: Compatibility with old sed/awk interferes with reproducibility
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Yoann Congal <yoann.congal>
Component: devtools / tool chainAssignee: Unassigned <unassigned>
Status: NEW --- QA Contact:
Severity: normal    
Priority: Medium+ CC: ccasciato, meta.mr.watcher, meta.watcher, randy.macleod, yoann.congal
Version: unspecified   
Target Milestone: 6.99   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Yoann Congal 2025-12-08 15:49:13 UTC
For HPUX, Solaris & AIX compatibility, sed/awk literal strings length are limited to <150 characters.
We often try to fix reproducibility with sed by replacing non-reproducible paths by reproducible ones.
In some cases, the line break added to limit literal string length prevent the sed to match the non-reproducible path (because it is split across 2 lines).

An idea is to drop the compatibility with Unixes we don't support by increasing the maximum line length to something modern sed/awk can handle.

This is the idea of this patch: [PATCH] autoconf: Raise line length limit for sed/awk
https://lists.openembedded.org/g/openembedded-core/message/226850

BUT, it created weird errors on AB when tested by Mathieu:
https://lists.openembedded.org/g/openembedded-core/message/227203
> I've had some issues on the autobuilder for a few days, and it looks
> like it was triggered by this patch. While there was no specific error,
> the -tc build jobs had been running for several days and never ending.
> 
> One example:
> https://autobuilder.yoctoproject.org/valkyrie/?#/builders/66/builds/2740
> 
> I've had a look on the worker: it looks like the host nfs server, used
> to share files with the tests running in qemu, had been failing:
> 
> pokybui+ 4115014  1.1  0.0      0     0 ?        Z    14:23   4:32 [unfsd] <defunct>
> 
> I clearly can't see how this can be linked to this patch, yet, git
> bisect points to it, and after its removal I don't have the issue
> anymore.

Further work is need to understand why this fails or if there is another way to fix reproducibility for packages impacted by compatibility line-break.
Comment 1 Randy MacLeod 2025-12-11 15:58:08 UTC
Explore the range between 128 and 4000?