* looking for advice on "pseudo abort" incident
@ 2021-03-24 9:27 Robert P. J. Day
0 siblings, 0 replies; only message in thread
From: Robert P. J. Day @ 2021-03-24 9:27 UTC (permalink / raw
To: OE Core mailing list
actually a 2-part post, so bear with me, the first part is not all
that exciting.
continuing my travels through a proprietary layer i've been handed,
i can across a recipe that redefined its PACKAGES in an obviously
strange way:
# Packages to consider
PACKAGES = "${PN} ${PN}-dbg ${PN}-dev ${PN}-staticdev"
# Files to add into the packages
FILES_${PN} += "${libdir}/lib*.so* ${bindir}/* ${datadir}/*"
FILES_${PN}-dbg += "${libdir}/.debug/* ${bindir}/.debug/*"
FILES_${PN}-staticdev += "${libdir}/*.a"
FILES_${PN}-dev += "${includedir}"
FILES_${PN} += "/data"
FILES_${PN} += "/data/config"
FILES_${PN} += "/data/etc"
# Produce package even if it is empty.
ALLOW_EMPTY_${PN} = "1"
ignoring the obvious weirdness of adding hard-coded host paths to the
package definitions, it struck me that it was overkill to entirely
redefine the PACKAGES variable. it seems to me that the stock
bitbake.conf already does a good job of defining the standard package
partitioning, starting with:
PACKAGE_BEFORE_PN ?= ""
PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
PACKAGES_DYNAMIC = "^${PN}-locale-.*"
FILES = ""
FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/*
${libdir}/lib*${SOLIBS} \
${sysconfdir} ${sharedstatedir} ${localstatedir} \
... snip ...
so, sure, lots of recipes might *tweak* the package definitions from
what they are, but it seems that it should be rare to totally toss the
initial definition of PACKAGES, and redefine it from scratch,
especially when it seems that the new definition isn't really all that
different from what you see in bitbake.conf. so my next bit of advice
is going to be, "adjust the recipes's packages, don't redefine them
from scratch." but here's the bigger issue.
only hours after i examined that recipe, i got a report of a "pseudo
abort" error during the build using this layer; something i have
never, ever seen in any of my builds. that error is explained here:
https://wiki.yoctoproject.org/wiki/Pseudo_Abort
and opens with:
"Pseudo can suffer from problems where files are created or modified
in pseudo's fakeroot context, then deleted outside of it. In
particular, the inode number for that file may be reused. If some
later access under pseudo uses that inode number, pseudo can see this
and become confused about whether the files are the same file or not.
Under older behaviour for pseudo, the modes of the old file may be
applied to the new one, causing mode permission corruption."
and what does this have to do with my earlier musings? because,
coincidentally, this pseudo abort error was generated by exactly the
same recipe i was talking about above.
so i'm about to dig into this error (which i have never seen
before), but could the cause be the hard-coding of host paths being
added to some of the recipe's packages? that is, is it possible that,
in the midst of processing that recipe, the host paths are being
modified on the fly by someone or something else, thereby causing this
error? or is that something i can discount entirely? just looking for
any guidance to speed up the debugging.
rday
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2021-03-24 9:27 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-03-24 9:27 looking for advice on "pseudo abort" incident Robert P. J. Day
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.