<khem>
RP: your v2 is still problematic ERROR: ParseError at /mnt/b/yoe/master/sources/meta-qt5/classes/qmake5_base.bbclass:49: Could not inherit file classes/remove-libtool.bbclass | ETA: --:--:--
<khem>
ERROR: Parsing halted due to errors, see error messages above
<khem>
this is with master-next as of now
buh0 has quit [Ping timeout: 268 seconds]
buh0 has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
sakoman has quit [Quit: Leaving.]
rber|res has joined #yocto
RobertBerger has quit [Ping timeout: 268 seconds]
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #yocto
agupta1 has quit [Ping timeout: 268 seconds]
buh0 has quit [Quit: Bye!]
adams[1] has joined #yocto
BobPungartnik has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
sakoman has joined #yocto
<adams[1]>
tar (child): pzstd -8 -p 16: Cannot exec: No such file or directory ---------> getting this weird error even though I have zstd installed
<adams[1]>
#1: sstate_create_package, /local/home/xyz/ws/build/tmp/work/armv8-2a-poky-linux/gcc-runtime/11.2.0-r0/temp/run.sstate_create_package.8326, line 199
GNUmoon2 has quit [Remote host closed the connection]
GNUmoon2 has joined #yocto
<khem>
it could be corrupt or racing can you check the binary ?
<adams[1]>
khem: which binary, sorry new to yocto.
seninha has quit [Remote host closed the connection]
<adams[1]>
you mean zstd?
mrnuke has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
sakoman has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
xmn has quit [Ping timeout: 252 seconds]
Adrian_ has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
Guest53 has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<Guest53>
Hi guys
<Guest53>
Does bitbake -f option invalidate all dependent tasks?
goliath has joined #yocto
<LetoThe2nd>
Guest53: it taints the build dependency tree AFAICS, so it should really be avoided. what is the actual problem?
<Guest53>
Yes, in general I probably should not do that. Just for testing
<LetoThe2nd>
Yeah but why?
<Guest53>
Seems like I have the task executed multiple times in my CI, so it says 'Nothing to build' and gives exit code 1
<Guest53>
Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.
<LetoThe2nd>
Guest53: but if bitbake thinks that all builds are up to date (so there's nothing to do) it is a good thing usually :)
<LetoThe2nd>
I wonder a bit about why its exit code 1 then, but there probably is some rationale to it.
<Guest53>
stdin is hidden in Jenkins, don't really know why. I think I have to investigate that
<Guest53>
Maybe 'Nothing to build' does not give error code 1, I can check that on my local machine
<Guest53>
then something else gives it
wkawka has joined #yocto
thomasd13 has quit [Quit: Leaving]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
rob_w has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
leon-anavi has joined #yocto
goliath has quit [Quit: SIGSEGV]
Guest46 has joined #yocto
<Guest46>
Hi guys, I'm looking for a way to deploy the file "image_license.manifest" from "${TMPDIR}/deploy/licenses/<image-name>-<machine-name>-date/image_license.manifest" to my filesystem (i.e. my image). Is there a way to do this?
zpfvo has joined #yocto
<ykrons>
qschulz: I get it for my do_configure issue. A typo 'do_configue' with a missing 'r' :| Thanks for your help
Guest53 has quit [Ping timeout: 252 seconds]
mvlad has joined #yocto
Zappan has joined #yocto
gsalazar has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
manuel1985 has joined #yocto
<wkawka>
Hi, I have a problem with RPI0w2. Machine boots, uart is enabled, but on the uart i see only booting process, i don't se login prompt and can't log in into device. Login prompt is visible via HDMI. I get an answer from raspberry channel `you probably have to modify whatever pid 1 is running, to launch a getty on the correct uart` but how can I
<wkawka>
achieve that. Also, there is an option to enter recovery shell during boot and se what is going on there?
goliath has joined #yocto
gsalazar has quit [Ping timeout: 268 seconds]
gsalazar has joined #yocto
GNUmoon2 has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
GNUmoon2 has joined #yocto
mrnuke has quit [Ping timeout: 268 seconds]
Guest53 has joined #yocto
<Zappan>
@wkawka You might want to respawn getty in your inittab
mrpelotazo has quit [Read error: Connection reset by peer]
mrpelotazo has joined #yocto
<qschulz>
ykrons: good to hear :)
Xagen has quit [Read error: Connection reset by peer]
Xagen has joined #yocto
<qschulz>
wyre: ahah! one more (or the same?) layer with this issue
<qschulz>
you should have a LINUX_VERSION somewhere in the recipe
<td54>
should gcc for native recipes use --sysroot flag? We have some kind of host contamination on latest poky master. If we have libmagic installed and we build util-linux-native the ./configure compiles with -lmagic and it links to /lib64/libmagic.so but then on compilation it uses
<td54>
#ifdef USE_MAGIC
<td54>
#include<magic.h>
<td54>
and it fails because we don't have any include path set to /usr/include.
<td54>
And if we for example use --sysroot flag it won't link to /lib64/libmagic.so
<td54>
but maybe the solution would be something else
<Zappan>
wkawka You could edit the inittab file in the sysvinit recipe, or make a recipe append in your own layer
adams[1] has quit [Quit: Client closed]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
stuom has joined #yocto
frieder has joined #yocto
<stuom>
can anyone say what causes this "unexpected EOF in archive" error during do_populate_sdk_ext? https://pastebin.com/iKDhuvXd
Guest3868 has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
<landgraf>
stuom: partially downloaded file I guess
<landgraf>
stuom: try do unpack it manually or (better) check checksums
<Zappan>
stuom: yes or try to refetch (bitbake -c fetch -f)
<ptsneves>
td54: it seems the magic test in utils-linux does not check include the header and the isystem is then ignored. The test is crap
<td54>
ptsneves: well it looks like it, we'll prepare the patch for the test
<ptsneves>
good luck :)
<td54>
thank :)
<stuom>
landgraf Zappan thanks, maybe I'm blind but I don't really understand what file is the culprit? What should I refetch?
<td54>
thanks*
BobPungartnik has quit [Quit: Leaving]
<landgraf>
stuom: ` tar --xattrs --xattrs-include='*' -xf - -C ` - it's stdin not file
<landgraf>
that's why we don't see filename
<stuom>
landgraf ok, what does that mean then?
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
argonautx has joined #yocto
<landgraf>
stuom: tar --exclude='.git' --exclude='__pycache__' --xattrs --xattrs-include='*' -chf - -C /home/tuomas/work/sampo-bsp-platform-v5.3/layers/meta-freescale -p . | tar --xattrs --xattrs-include='*' -xf - -C
<landgraf>
stuom: please try it localy maybe it will give you some clue why it's failing.
<landgraf>
RP: "Small" doesn't sound like small :)
Zappan has quit [Quit: WeeChat 2.3]
Zappan has joined #yocto
<RP>
landgraf: totally breaks some internals :/
<ernstp>
wow, I just found a corporate http proxy that explicitly rejects the User-Agent set in bb.fetch2.wget:checkstatus() :-(
<RP>
ernstp: :(
<ernstp>
I mean it's ancient but still... Just not setting any works..
<ernstp>
"Ubuntu/9.10" :-)
Adrian_ has quit [Quit: Leaving]
<JaMa>
heh I was recently installing ubuntu-6.06 in VM when trying to get some old app using Qt3 bindings in ruby (which weren't updated in last 10 years), but using 9.10 in production that's different kind of insanity :)
<RP>
ernstp: I'll take a patch to update it to something more modern
<ernstp>
Ok the triggering part in the user agent seems to be Firefox/64.0 vs Firefox/63.0
<ernstp>
RP: yeah I will send a patch :-)
* RP
blows away his tmpdir due to the damage he just did to it
<RP>
if anyone was using master-next, they'll probably have corruption too
<ernstp>
or... we stop setting a user agent....
<RP>
ernstp: we did add it for a reason, but a long time ago
<RP>
ernstp: I don't know how things would work out. Sourceforge will probably still be a pain
<ernstp>
RP: yeah, you're right
starblue has quit [Ping timeout: 268 seconds]
Ram-Z_ has quit [Ping timeout: 240 seconds]
starblue has joined #yocto
<stuom>
landgraf thanks, I ran the command locally and it returned no error (or any output). But bitbake still fails
<RP>
landgraf, stuom: the interesting bits in those failures are in the pseudo.log file
<landgraf>
yup. error message says this )
tangofoxtrot has quit [Ping timeout: 268 seconds]
<stuom>
only thing pseudo.log seems to tell is path mismatch [22 links]: ino 1898804 db '/home/tuomas/work/sampo-bsp-platform-v5.3/build-develop/tmp/work/colibri_imx8x-tdx-linux/sampo-console-image/BSPv5.3-r0/rootfs/usr/share/common-licenses/firmware-imx-vpu-imx8/EULA' req '/home/tuomas/work/sampo-bsp-platform-v5.3/layers/meta-freescale/EULA'.
<stuom>
RP does that tell something?
tangofoxtrot has joined #yocto
Skippy has joined #yocto
Skippy is now known as Skiper
Skiper has quit [Client Quit]
Skiper has joined #yocto
<ernstp>
So a python f-string formatting was added to cve_check.py and cherry-picked to Dunfell. Dunfell should support python3.5 however which doesn't have f-strings.
<ernstp>
Now we've been trying to keep cve-check the same between master and LTS right, so should we remove the f-string on master also, or only dunfell?
<ernstp>
(Ubuntu 16.04 has python3.5. I know, it's ancient... 18.04 has python3.6 with f-string support)
<RP>
stuom: that is the file is having issues with
<qschulz>
ernstp: considering that dunfell is going to be supported for about 2 more years, I guess it makes sense to have master not use f-string until dunfell is EOL?
<qschulz>
will allow less mistakes and make maintainers life easier
<ernstp>
qschulz: yeah that's what I thought
<ernstp>
specially for cve-check
<qschulz>
ernstp: you can use formatted string so that it's not too much of a change (in the string section at least)
<stuom>
RP ok, what needs to be fixed then? EULA file exists in both those paths and have same checksum. What is mismatching?
<ernstp>
qschulz: exactly
<qschulz>
ernstp: f'{foo}{bar}' into '{foo}{bar}'.format(foo=foo, bar=bar)
<RP>
stuom: something is changing a file outside of pseudo's knowledge and confusing it
<ernstp>
stuom: which exact Yocto version are you using? there's been fixes to pseudo etc...
Ram-Z has joined #yocto
<RP>
ernstp: this is the issue people have been telling me "isn't a problem" for ages :(
<RP>
(f strings)
<ernstp>
RP: ah... probably very few people actually use python3.5 also...
<stuom>
ernstp the BSP is based on dunfell, not sure how to get more exact version? Current commit of meta-yocto?
<Guest46>
Can I use IMAGE_POSTPROCESS_COMMAND to add files to the ROOTFS?
<stuom>
@RP I have ACCEPT_FSL_EULA = "1" in my local.conf to auto-accept Freescale EULA, can that affect it? Cannot bitbake image without it, though...
ptsneves has quit [Ping timeout: 268 seconds]
<RP>
stuom: could be related, I have no idea how it works
<stuom>
neverpanic thanks. As I understood, my problem (talked above) is that an EULA file is maybe changed outside of pseudo's knowledge, and it aborts the build
<RP>
stuom: the key question is where is BSPv5.3-r0/rootfs/usr/share/common-licenses/firmware-imx-vpu-imx8/EULA getting deleted outside pseudo context
seninha has joined #yocto
florian_kc has joined #yocto
agupta1 has joined #yocto
<stuom>
RP, at least I don't deliberately touch EULA file anywhere, unless BSP does something funny for some reason. But also this happens only with populate_sdk_ext, why it doesn't happen when normally building image?
<RP>
stuom: sounds like it might be the clean and rebuild that is the issue :/
argonautx_ has joined #yocto
<ernstp>
ah there's already a user-agent update on master!
<ernstp>
sakoman: I propose that you cherry-pick "bitbake: fetch2/wget: Update user-agent" to dunfell, it picks cleanly!
<qschulz>
ernstp: the cve-check patches probably applied cleanly too :p
<ernstp>
qschulz: they're trying extra to keep cve-check identical on all the active branches
frieder has quit [Remote host closed the connection]
<qschulz>
ernstp: I know, just nitpicking around the fact that something applying cleanly does not mean it's a simple valid backport
<qschulz>
(waiting for builds to finish, sorry to bother you :) )
Guest53 has quit [Ping timeout: 252 seconds]
roussinm has joined #yocto
<ernstp>
qschulz: right :-) Just mean that it's an easy backport!
xmn has joined #yocto
<roussinm>
I have a python recipe that generates multiple whl files. I just upgraded to kirkstone and bitbake complains about having multiple whl files. What is the way to fix this? Packages? Multiple Recipes, with the same git source? Is there any existing recipe that deals with that in poky or meta-oe?
Lihis has quit [Quit: Quitting]
Lihis has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
amitk has quit [Ping timeout: 268 seconds]
brazuca has quit [Quit: Client closed]
nemik has joined #yocto
argonautx_ has quit [Quit: Leaving]
sakoman has joined #yocto
<RP>
roussinm: you may be the first
dtometzki has joined #yocto
kranzo has joined #yocto
Guest46 has quit [Quit: Connection closed]
<kranzo>
Hi all,
<kranzo>
i've created a local directory structure and use a custom templateconf pointing to a folder outside of OEROOT... works fine so far but is breaking the esdk because the template conf folder is not present in the sdk. i think i abused the variable but i can't find documentation about the proper usage. any advice?
rob_w has quit [Remote host closed the connection]
gsalazar has joined #yocto
thomasd13 has quit [Ping timeout: 268 seconds]
<Tartarus>
zeddii, sakoman, JFYI I was looking at some stuff in dunfell and I see genericx86* machines are behind qemux86* in terms of linux-yocto revs. Is that an easy thing to address or something that'll take a bit of time and so not high up on the priority list?
goliath has quit [Quit: SIGSEGV]
<sakoman>
Tartarus: typically someone from Intel will send a patch to update those
<sakoman>
But since they haven't feel free to send a patch :-)
<Tartarus>
heh, i'll put it on the todo list
<Tartarus>
Do need to sort out the customer requests first
<zeddii>
I have a script that can update the REVs as well, but I do it less often, as the testing is a but more cumbersome on my end. I can send something right now if it saves everyone some time.
<Tartarus>
I was hoping getting everything in line with qemux86* at least would be pretty quick for someone to take care of
davidinux has quit [Ping timeout: 244 seconds]
<Tartarus>
5.4.204 or so is also a bit old I think? But so is dunfell
<RP>
Tartarus: it is quick if you don't care about testing it :/
<Tartarus>
How much testing isn't automated?
<Tartarus>
sdmux boards make even x86 pretty nice for automation, so long as you aren't also trying to flash the firmware :)
td54 has quit [Ping timeout: 252 seconds]
spchpd has joined #yocto
Skiper has quit [Ping timeout: 252 seconds]
Skiper has joined #yocto
<roussinm>
RP: Damn, this is the repository I try to create a recipe from: https://github.com/cheshirekow/cmake_format As you can see there is multiple setups inside the setup.py. so that seems to be the issue.
Skiper has quit [Read error: Connection reset by peer]
Skiper has joined #yocto
mateuszmar2 has quit [Quit: Client closed]
<roussinm>
RP: No idea if that could be the right approach, but if I split all wheels into a seperate packages and, no idea if possible, move the wheel to seperate directories and override install step for each package to run in their own directory... that seems convoluted though.
spchpd has quit [Ping timeout: 268 seconds]
adams[1] has joined #yocto
<bigendian>
hi, is there any issue to setup a meta-layer as a symlink ?
<Saur[m]>
bigendian: Using a symbolic link works fine.
brazuca has joined #yocto
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
TobiQS has quit [Remote host closed the connection]
SDes91 has joined #yocto
<Tartarus>
RP, JPEW a different question, way back in 0be64e54a in oe-core, qemux86 picked up tune-corei7 rather than tune-i586 (without changing the default, with good reason) but qemux86-64 is still only grabbing tune-core2. Since that commit qemux86 switched up to use core2-32 as the default tune. Would it make sense to post a patch switching qemux86-64 to grab tune-corei7 as well, without changing the tune, but similar explanation as to why as given in
<Tartarus>
0be64e54a ?
<RP>
Tartarus: it is done by Intel/WR so I really don't know
<Tartarus>
ok
<RP>
Tartarus: that was in reply to the testing. For the tune, switching is probably ok
<JPEW>
Tartarus: allowing qemux86-64 to tune to i7, but leaving the default as core2-64 seems OK to me
<JPEW>
TBH, I don't know why I didn't do that originally, other than "I didn't need it so I didn't think about it" :)
<Tartarus>
Posting a patch in a moment, bitbake -g'ing to avoid a very silly error
<JPEW>
We don't use qemux86-64 for testing because u-boot doesn't fully support it yet
<Tartarus>
^potential error
<Tartarus>
JPEW: If you wanna talk about u-boot and qemux86-64, we can head over to #u-boot ;) As I'm not sure where the issue would be exactly
<Tartarus>
qemux86-64 is part of the U-Boot CI cycle
<JPEW>
Ya, I think the display wasn't implemented last I checked
<Tartarus>
It shouldn't be different from qemux86 in that regard
GregWilson has quit [Quit: Client closed]
<JPEW>
Ya, I know very little about x86. The documentation in u-boot says it has to be booted with -nographic (and I verified that empirically), and we really want graphics
<Tartarus>
If you email me how to make things fail I'll put it on my to poke list, but I'm on vacation next week too
<Guest16>
I can't make sense of how one is supposed to fetch specific tagged versions anymore from github -is a SHA _always_ required now?
<qschulz>
short answer is "do not use tags"
<qschulz>
I don't remember the long answer :|
stuom has quit [Quit: Client closed]
nemik has quit [Ping timeout: 252 seconds]
nemik has joined #yocto
<Guest16>
Yeah, that feels like the answer - but I feel like that makes updating recipes to new versions a bit more work. One used to be able to just update `some-pkg_0.1.0.bb` to `some-pkg_0.1.1.bb` and viola, you'd get the new version (assuming the new tag existed)
<qschulz>
Guest16: tags can be moved, therefore not desirable for reproducible builds, and you want reproducible builds (if you don't, you do)
<Guest16>
Yeah- that is fair regarding reproducible builds
<Guest16>
that is sort of the point :)
<qschulz>
Guest16: you can always start using auto-upgrade-helper to automatically do this for you
zpfvo has quit [Remote host closed the connection]
davidinux has quit [Ping timeout: 255 seconds]
<qschulz>
we use this tool on the recipes the project maintains
<Guest16>
yeah I can confirm they appear to be fully broken
<Guest16>
Even setting a SRCREV=SomeSha to match the SHA of the actual tag, the build still fails (albeit with a different error saying the SRCREV hash doesn't match the tag name, which... duh?)
nemik has quit [Ping timeout: 264 seconds]
<Guest16>
I also found out that it appears bitbake only supports fetching annotated tags vs. lightweight tags - which I think is perfectly fine, just something I didn't know was a thing
nemik has joined #yocto
d4rkn0d3z has joined #yocto
<Guest16>
As it wasn't abundantly clear from docs
<d4rkn0d3z>
Hi I am trying to build yocto for i.mx8 and I get an error building zstd
<kranzo>
Guest16 remove the tag from SRC_URI it's as its conflicting with SRCREV
<d4rkn0d3z>
could I get some help ?
<Guest16>
Yep, I was hoping to be able to use the `tag=` param and _not_ the SRCREV - but it is sounding like (and looking like) that is not possible
<Guest16>
The only way to fetch a tag is to use the SRCREV of said tag, which is disappointing - unless there is someone that has another way to do this
florian has quit [Quit: Ex-Chat]
gsalazar has quit [Ping timeout: 268 seconds]
florian_kc has quit [Ping timeout: 268 seconds]
<RP>
Guest16: we definitely don't recommend tags. It is possible something got broken with them
<Guest16>
Absolutely understand - with reproducible builds this makes 100% sense. I just had never run into that before kirkstone.
<khem>
debatable but I see we add it to INHERIT_DISTRO and its a weak assign so some one can technically override it and I think these recipes need it regardless of distro policy
<RP>
khem: it is debatable. In theory recipes should build without deleting those files though, it was meant to be optional, not used by recipes non-optionally
<RP>
anyway, something to ponder for now
brazuca has quit [Quit: Client closed]
kranzo has quit [Quit: Client closed]
kranzo has joined #yocto
Guest3868 has quit [Quit: Client closed]
<khem>
yeah, I think we should just make it default and move on
<khem>
I think removing la files help more than they harm
<khem>
so we can perhaps just enable it globally
<khem>
abelloni: I have sent a v4 for glibc 2.36 patch
<khem>
just to avoid sending an immediate patch update to delete two patches
brazuca has joined #yocto
KurtKiefer[m] has joined #yocto
wkawka has quit [Quit: Client closed]
KurtKiefer[m] is now known as kekiefer[m]
<roussinm>
rburton: You integrated the check to see if there was more than 1 wheel to install it fails, what is the idea behind the check? The repository has one setup.py and calls setup() for each tool, which I think creates the whl files? https://git.yoctoproject.org/poky/commit/?id=438b58fd4b5a60da5871b1412ca5ab032244016e Maybe the recipe shouldn't inherit setuptools3 ? The project isn't using
<roussinm>
pyproject.toml either.
adams[1] has quit [Quit: Client closed]
agupta1 has quit [Ping timeout: 268 seconds]
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
kranzo has quit [Quit: Client closed]
nemik has quit [Ping timeout: 268 seconds]
leon-anavi has quit [Quit: Leaving]
nemik has joined #yocto
<d4rkn0d3z>
is there a better place to ask for help with builds?
agupta1 has joined #yocto
manuel1985 has quit [Ping timeout: 268 seconds]
<landgraf>
d4rkn0d3z: google :)
<landgraf>
or here
argonautx has quit [Quit: Leaving]
<d4rkn0d3z>
well I am having trouble with zstd-native building
<d4rkn0d3z>
Can't find anything on google
<JPEW>
d4rkn0d3z: What version of Yocto are you using and what error are you seeing?
<d4rkn0d3z>
I'm following the i.mx yocto user guide
<d4rkn0d3z>
I am alternately getting the following,
<d4rkn0d3z>
ERROR: Task (/home/build/5.15.32-2.0.0/sources/poky/meta/recipes-devtools/binutils/binutils-cross_2.38.bb:do_compile) failed with exit code '1'
<d4rkn0d3z>
or similar with zstd-native
<d4rkn0d3z>
I have tried a few things from the web to no avail
<d4rkn0d3z>
as far as version ...
<JPEW>
Does it give more log messages than that?
<d4rkn0d3z>
kirkstone
nemik has quit [Ping timeout: 268 seconds]
<d4rkn0d3z>
yes a bunch of compiler errors
<JPEW>
Can you include a pastebin of them?
nemik has joined #yocto
<d4rkn0d3z>
here let me revert everything and re-init
<ernstp>
d4rkn0d3z: are you using krikstone for both poky and meta-freescale (which I guess you have since you mention i.mx)
<d4rkn0d3z>
I am new and I am trying to follow the imx8 yocto user guide
yudjinn[m]1 has joined #yocto
<yudjinn[m]1>
hello, I'm trying to catalog and list all the recipes, appends, classes, etc used in the building of an image, whats the best way to do this?
<yudjinn[m]1>
I've tried the -g to build a dotfile, and that gives me bb files, but I want to also see which appends are being used, etc
nemik has quit [Ping timeout: 244 seconds]
<JPEW>
yudjinn[m]1: I don't know of anything that exposes that information; any reason why you want it?
nemik has joined #yocto
<yudjinn[m]1>
I have multiple projects that I want to reorganize into shared layers, and want to catalog what is currently using which recipes so I can make informed decisions about it
<kergoth>
archiver can optionally include full recipe data after inherits/includes/etc, not sure if it mentions what files they came from, though
<JPEW>
yudjinn[m]1: Hmm, ya. I don't know anything that will give you that; bitbake does know that information though (you can see it in bitbake -e)
<d4rkn0d3z>
JPEW I am following the pdf in the link I sent
<JPEW>
d4rkn0d3z: OK, unless someone is already using that, it's unlikely that anyone will try to follow those directions and reproduce it on their own, so the error logs would be helpful
<d4rkn0d3z>
I am about to get it
<d4rkn0d3z>
I just did a new repo init
<d4rkn0d3z>
and sync
adams[1] has joined #yocto
prabhakarlad has joined #yocto
<d4rkn0d3z>
Started fresh build
<d4rkn0d3z>
ERROR: Task (virtual:native:/home/build/5.15.32-2.0.0/sources/poky/meta/recipes-extended/zstd/zstd_1.5.2.bb:do_compile) failed with exit code '1'
<d4rkn0d3z>
Which logs do you want?
nemik has quit [Ping timeout: 268 seconds]
<JPEW>
It should point you to a .log file
nemik has joined #yocto
<d4rkn0d3z>
if it did it scrolled away
<d4rkn0d3z>
I see that error preceded by mounds of compiler errors
Skiper has quit [Ping timeout: 252 seconds]
<d4rkn0d3z>
the error in binutils-cross appears to be related to not finding pod2man although it is installed
<JPEW>
I think it's at the end after bitbake finishes
<JPEW>
Oh, hmm. I thought we listed the log file when an error occurred
<d4rkn0d3z>
perhaps if I just run that particular recipe?
<d4rkn0d3z>
Usually it does
<d4rkn0d3z>
How would one remove that recipe?
<landgraf>
d4rkn0d3z: there should be temp directory under /home/build/5.15.32-2.0.0/minimal/tmp/work/x86_64-linux/zstd-native/1.5.2-r0/
<landgraf>
with logs inside
<JPEW>
Ya should be a line like "ERROR: Logfile of failure stored in: ..."
<landgraf>
look for log*.do_compile
<landgraf>
look for log*.do_compile*
<d4rkn0d3z>
gotcha
<JPEW>
d4rkn0d3z: Ah the line is there but it might be before the error output (it's not necessary, but convenient because it gives the exact path to the error log)
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
<d4rkn0d3z>
Okay I see that log and it shows the compile errors
<d4rkn0d3z>
where do you want it?
<JPEW>
pastebin or equivalent?
<d4rkn0d3z>
okay
<d4rkn0d3z>
too big for pastebin
<JPEW>
Ah; do you see anything in there that you can distill down?