| Summary: |
inconsistent .gnu_debuglink |
| Product: |
[Build System, Metadata & Runtime] OE-Core
|
Reporter: |
Juro Bystricky <juro.bystricky> |
| Component: |
core | Assignee: |
Juro Bystricky <juro.bystricky> |
| Status: |
RESOLVED
OBSOLETE
|
QA Contact: |
|
| Severity: |
normal
|
|
|
| Priority: |
Medium+
|
CC: |
meta.mr.watcher, meta.watcher
|
| Version: |
2.4 | |
|
| Target Milestone: |
2.5 M2 | |
|
| Hardware: |
x86 | |
|
| OS: |
Multiple | |
|
| Whiteboard: |
|
|
OS type for building Yocto:
|
---
|
Type of Regression:
|
---
|
|---|
|
Verified:
|
|
Documentation change:
|
No (bug/feature does not impact docs)
|
|---|
| Attachments: |
|
Created attachment 4077 [details] diffoscope output, gawk This is a weird one, highly reproducible, maybe even 100%. I noticed this when building core-image-minimal (gawk_4.1.4-r0_i386.deb is built as part of the build). The .gnu_debuglink contains either: 1. gawk-4.1.4 or 2. gawk The .gnu_debuglink checksum is the same in both cases. 1. local.conf PACKAGE_CLASSES="package_deb" 2. local.conf: PACKAGE_CLASSES="package_deb" INHERIT+="rm_work" TMPDIR="/tmp/ramdisk/gawk" DEPLOY_DIR="/data/master-master/poky-contrib/gawk/tmp/deploy" Basically, when I use ramdisk as TMPDIR, I get different result. I could also reproduce this by building an individual package: $ bitbake gawk Build in two different folders, each containing local.conf as per above. In ramdisk I need to use "rm_work", else I run out of memory, but I don't think that is the culprit. I also witnessed other similar anomalies with respect to .gnu_debuglink: e2fsprogs-e2fsck e2fsprogs-mke2fs