dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
Shaun has quit [Quit: Lost terminal]
qschulz has quit [Quit: qschulz]
d0ku has quit [Ping timeout: 248 seconds]
qschulz has joined #yocto
mihai- has joined #yocto
mihai has quit [Ping timeout: 240 seconds]
soneil has joined #yocto
d0ku has joined #yocto
soneil has quit [Remote host closed the connection]
goliath has quit [Quit: SIGSEGV]
<moto-timo> You might need the new override syntax? Which branch/release/version of Yocto Project are you on?
<moto-timo> The wiki has not been updated to the new syntax (wikis are rarely updated :( )
<vagaruy> I tried the dunfell for both poky and meta-openembedded. .
<moto_timo[m]> vagaruy: ok for dunfell the override syntax is the original syntax
<moto_timo[m]> vagaruy: I’m not an expert on tunings, so maybe someone else can help.
<moto_timo[m]> vagaruy: you have nodejs building though, correct?
<vagaruy> I have nodejs building and also able to include some packages. eg. devtool add "npm://registry.npmjs.org;package=targz;version=1.0.1" works but quite a few of them don't . The cute-files from the example works as well .
jwillikers has quit [Remote host closed the connection]
<moto-timo> vagaruy: trying locally...
<moto-timo> vagaruy: MACHINE is qemuxi6-64 no?
<vagaruy> moto-timo yes
<vagaruy> moto-timo I think I made some progress . It seems like the failure occurs for packages where the generated npm-shrinkwrap.json has no dependencies. Removing the file and updating the recipe seems to pass the fetch stage .
<moto-timo> vagaruy: interesting...
<moto-timo> vagaruy: devtoo;/recipetool are not all that intelligent, so corner cases definitely break.
<moto-timo> vagaruy: but if that is the fix, it would be worth filing a bug on bugzilla.yoctoproject.org on devtool
<vagaruy> moto-timo I also added a print statement in fetch2 __init__ and I can see this being printed in a loop 'npm://registry.npmjs.org/;package=xstate;version=4.23.1', 'npmsw:///mnt/64243b31-a71a-4e03-b25a-3a53ba211945/build/poky/meta/recipes-nodejs-packages/nodejs-xstate/nodejs-xstate/npm-shrinkwrap.json'] .
<vagaruy> moto-timo Thank you for your time. I will dig a bit more and file a bug
<moto-timo> vagaruy: we're all in this together :)
jmiehe has quit [Quit: jmiehe]
d0ku has quit [Ping timeout: 250 seconds]
otavio has quit [Remote host closed the connection]
otavio has joined #yocto
<moto-timo> full error is:
<vagaruy> moto-timo Thank you. That's exactly the error I was getting as well .
<moto-timo> vagaruy: one of our resident tune experts might have more insights :)
Ad0 has quit [Ping timeout: 250 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
Ad0 has joined #yocto
sakoman has quit [Quit: Leaving.]
Tokamak has joined #yocto
tp43_ has joined #yocto
Tokamak has quit [Ping timeout: 240 seconds]
vagaruy has quit [Ping timeout: 240 seconds]
paulg has quit [Ping timeout: 252 seconds]
Tokamak has joined #yocto
Tokamak has quit [Ping timeout: 252 seconds]
Tokamak has joined #yocto
sakoman has joined #yocto
Guest8812 has joined #yocto
Guest8812 has quit [Client Quit]
vagaruy has joined #yocto
tp43_ has quit [Ping timeout: 250 seconds]
amitk has joined #yocto
vagaruy has quit [Ping timeout: 240 seconds]
mihai- is now known as mihai
tp43_ has joined #yocto
tp43_ has quit [Ping timeout: 250 seconds]
vagaruy has joined #yocto
tp43_ has joined #yocto
Tokamak has quit [Ping timeout: 240 seconds]
Tokamak has joined #yocto
vagaruy has left #yocto [#yocto]
sakoman has quit [Quit: Leaving.]
tp43_ has quit [Ping timeout: 250 seconds]
leon-anavi has joined #yocto
troth has quit [Ping timeout: 250 seconds]
frieder has joined #yocto
zyga has joined #yocto
<mihai> yo
troth has joined #yocto
rob_w has joined #yocto
rfuentess has joined #yocto
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
lucaceresoli has joined #yocto
derRicha1d is now known as derRichard
LetoThe2nd has joined #yocto
Guest86 has joined #yocto
rber|res has joined #yocto
<LetoThe2nd> yo dudX
zpfvo has joined #yocto
<Guest86> I wonder if I could get help on this channel to my lack of understanding how some tooling for Yocto works.
<Guest86> I have run into a problem when moving my yocto build area to run on top of docker.
<Guest86> Essentially what it boils down to is that a certain ioctl call for bmap-tools is failing when ran on docker and I needed to make a small error handling for that purpose to BmapHelpers.py file for it.
<Guest86> So I have the fix working, but I cannot for the life of it figure out how to actually make a clean patch for this because I cannot find the right source files.
<Guest86> On the system I see following bmap providers:
<Guest86> wic-tools
<Guest86> bmap-tools
<Guest86> bmap-tools-native
<Guest86> But it seems during the build stage, yocto uses something from under tmp/work/sb3_imx6dl-fslc-linux-gnueabi/sb3-dev/1.0-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/bmaptools/BmapHelpers.py
<Guest86> If I make the change to this file, the build process will work, but I would like to provide a clean patch so that all my team mates would benefit from this change as well. Can someone help me where does this python package come from ?
<LetoThe2nd> Guest86: just guessing now: as it is in the -native sysroot, i would expect it to come from the bmap-tools-native package. you can probably check that by inspecting the task dependencies for sb3
d0ku has joined #yocto
<Guest86> LetoThe2nd but it appears that even if I recompile bmap-tools-native my "fixed" version of BmapHelpers.py remains and the build keeps succeeding
<Guest86> (I recompile with "bitbake bmap-tools-native -c cleansstate" and then just "bitbake bmap-tools-native")
<LetoThe2nd> check the task dependencies
rfuentess has quit [Remote host closed the connection]
<Guest86> LetoThe2nd (I executed bitbake -g sb3) and I get
<Guest86> $ cat recipe-depends.dot | grep bmap
<Guest86> "sb3-dev" -> "bmap-tools-native"
<Guest86> "bmap-tools-native" [label="bmap-tools-native\n:3.4-r0\nvirtual:native:/home/build/sb3/fsl-community-rocko/sources/poky/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb"]
<Guest86> "bmap-tools-native" -> "quilt-native"
<Guest86> "bmap-tools-native" -> "python3-native"
<Guest86> "bmap-tools-native" -> "python3-setuptools-native"
<Guest86> "wic-tools" -> "bmap-tools-native"
<LetoThe2nd> hence its bmap-tools-native as expected. so the next step would be to check if your build of it actually incorporates the patch as desired.
<LetoThe2nd> *sigh* rocko.
<LetoThe2nd> where can i bill the EOL support hours?
<Guest86> *sweating*
<Guest86> Yeah so my trouble here is that if I rebuild the bmap-tools-native (first cleansstate and then build) my hacked file remains for some reason
<Guest86> It should be overwritten again with the original file "that shouldnt work".. but it doesnt seem to get overwritten
<LetoThe2nd> so how do you "patch"
goliath has joined #yocto
bps has quit [Ping timeout: 252 seconds]
<LetoThe2nd> and, inevitable question: is the behaviour you're trying to work around still present in the current/stable state of bmap-tools? if not, backport stuff or upgrade.
<Guest86> Apologies for the being unclear. So indeed my original problem is that I have a fix for the file that makes things work. I couldnt find what provided the BmapHelpers.py file, so I first started looking how to debug and fix the problem by changing the file directly under sysroot
<Guest86> (tmp/work/sb3_imx6dl-fslc-linux-gnueabi/sb3-dev/1.0-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/bmaptools/BmapHelpers.py).
<Guest86> Next I was trying to find what actually provides this file under sysroot to make a patch, but I seem to be unable to find it. (Cleaning and rebuilding bmap-tools-native does not erase and replace my "fixed versin of the file" under sysroot).
<Guest86> Now writing all this out and I think about it, could it be that yocto sees that no changes have been done to original so he doesnt re-export the file to the sysroot ?
<Guest86> Perhaps I need to try adding some meaningless patch to see if the file gets overwritten then
<Guest86> (or indeed, the actual patch I want to make)
<LetoThe2nd> now i guess you're getting closer.
<Guest86> Appreciate the help. Let me try that. Im afraid I dont have a cost center number for you ;)
<LetoThe2nd> and: anything you do and tinker in one of the sysroots is completely beyond bitbake. if you want a recipes output to change, you have to actually patch it respectively add the patch to the sources.
<LetoThe2nd> Guest86: how comes i'm not surprised. now an honest answer please. is that actually fixed in the current versions, and are we wasting time on outdated stuff?
<Guest86> right. I was aware of that. I guess I just started wrong way around
Tokamak has quit [Ping timeout: 252 seconds]
<Guest86> Looking at the repo from intel, indeed they seem to have fixed this - essentially with same approach
<LetoThe2nd> *sigh²"
<LetoThe2nd> now do an estimate on the cost of your hours alone you wasted due to rocko.
<Guest86> Can I ask another question while we are at this. I have bmap-tools_3.4.bb under rocko, would it be enough to just get a newer bb file from one of the newer branches for this or Im up whole load of dependency hell if I try to just pick this one recipe ?
<LetoThe2nd> it depends.
<LetoThe2nd> go and find out.
<Guest86> :)
<Guest86> thank you, let me try that first before patching
tnovotny has joined #yocto
<Guest86> ok. Indeed adding a new bb file fixed the issue for me too. Thank you again LetoThe2nd
<Guest86> Looks like indeed the problem was not going to patching route right from the start, I would have figured this out sooner
<LetoThe2nd> just what i said. hours and hours of effort pointlessly wasted due to EOL software.
bps has joined #yocto
bps has joined #yocto
Guest86 has quit [Ping timeout: 246 seconds]
zyga has quit [Remote host closed the connection]
zyga has joined #yocto
rperier has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
rperier has joined #yocto
kranzo has joined #yocto
bunk has quit [Ping timeout: 250 seconds]
bunk has joined #yocto
florian has joined #yocto
<wCPO> I'm trying to use recipetool to create a recipe: recipetool create -o foo $PWD/efitools-1.9.2.tar.gz, but it just fails with: FileNotFoundError: [Errno 2] No such file or directory: '/home/kristian/yocto/build/tmp/work/recipetool-neyy7v2h/work/recipe-sysroot'
zyga has quit [Remote host closed the connection]
<wCPO> So using the https url works, but not using a local file
zyga has joined #yocto
JaMa has joined #yocto
Shaun has joined #yocto
vd has quit [Quit: Client closed]
prabhakarlad has quit [Quit: Client closed]
kranzo has quit [Ping timeout: 246 seconds]
frieder has quit [Remote host closed the connection]
jwillikers has joined #yocto
moto-timo has quit []
moto-timo has joined #yocto
JPEW has quit []
JPEW has joined #yocto
cocoJoe has quit [Quit: Client closed]
frieder has joined #yocto
rfuentess has joined #yocto
CookieMonster has joined #yocto
CookieMonster has quit [Write error: Broken pipe]
goliath has quit [Quit: SIGSEGV]
<thekappe> hello guys
<thekappe> I have a C program along with its Makefile
<thekappe> I need to add the install target to the Makefile, in order to install the binary file in the specified directory
manuel1985 has quit [Quit: Leaving]
<thekappe> how is that treated when bitbaking the recipe ?
<thekappe> if I move the binary file to /usr/bin, it will be installed in ${D}/usr/bin ?
cocoJoe has joined #yocto
armoon has joined #yocto
goliath has joined #yocto
<LetoThe2nd> thekappe: just don't use absolute paths.
<qschulz> thekappe: I think I remember some people add $DESTDIR in front of the install path
<qschulz> (in the makefile)
<qschulz> on a local (outside of Yocto) build, DESTDIR wouldn't be defined, but in Yocto it'd be set to ${D}
armoon has quit [Ping timeout: 246 seconds]
rob_w has quit [Quit: Leaving]
vagaruy has joined #yocto
<jonmason> I want to test a bunch of tune modifications, but without building a whole image (otherwise this would take days). What is the smallest thing I can compile to verify? glibc?
vagaruy has quit [Ping timeout: 240 seconds]
lucaceresoli has quit [Quit: Leaving]
<jonmason> JaMa: thanks!
paulg has joined #yocto
<RP> vmeson: some good news. I have a horrendous hack for rust that might just work for the uninative issue
<tgamblin> do we have any existing examples of populating /etc/resolv.conf in an image to satisfy ptests?
<paulg> echo "nameserver 8.8.8.8" >> /etc/resolv.comf :-)
tnovotny has quit [Read error: Connection reset by peer]
tnovotny has joined #yocto
tnovotny_ has joined #yocto
tnovotny has quit [Ping timeout: 248 seconds]
sethfoster has joined #yocto
<sethfoster> Hey folks. I'm trying to write a fetcher class that unfortunately doesn't bear enough similarities to others that it has to inherit directly from FetchMethod. What I'm seeing is that the download function seems to start and immediately stop without an error
<sethfoster> it does some assignment logic, has some warning-level logs at the beginning and end, and a bunch of runfetchcmd calls. the logging at the beginning fires but the logging at the end doesn't.
<sethfoster> i've passed sys.stdout to the log param of runfetchcmd, which I'm not sure is right; and I don't have a progress monitor, which I suspect might be causing the problem.
<sethfoster> I can post the code if you want but don't want to spam the channel
sakoman has joined #yocto
<qschulz> sethfoster: if you want to share code snippet, you can use any pastebin and paste the link here, that'll do
<sethfoster> oh, perfect
<sethfoster> i'm exercising it by running bitbake -c fetch electron (electron is the package recipe i'm writing that uses the fetcher)
<sethfoster> at -DD you end up getting that first DOWNLOADING log, then do_fetch saying the task finished immediately
xmn has joined #yocto
<zyga> I'm trying to wrap my head around bitbake doing something unexpected
<zyga> I'm working on a new recipe, initially nothing there, just name/description/license
<zyga> I get a failure from do_populate_lic that the license file cannot be found
<zyga> looking at the docs and sources it seems that the path is relative to S
<zyga> but S points to an ... empty directory?
<zyga> the actual sources are in ../git/
<zyga> SRC_URI is a typical git URL
<RP> zyga: have you set S = "${WORKDIR}/git" in the recipe?
<zyga> SRCREV is "${AUTOREV}"
<zyga> no, I didn't
<zyga> but I never experienced this in other recipes (arguably they did inherit more)
<qschulz> you should :)
<zyga> why is S set this way?
<zyga> as in, pointing to an empty place?
<qschulz> because the git fetcher is cloning into ${WORKDIR}/git
tnovotny_ has quit [Read error: Connection reset by peer]
<zyga> so why is it not setting S=?
tnovotny_ has joined #yocto
<qschulz> and the default is adapted to most convention of tarballs
<qschulz> which contains only one directory, named following this convention softwarename-softwareversion
<qschulz> so S by default is ${WORKDIR}/${PN}-${PV}
<zyga> right but if the git fetcher puts the code in a different place
<zyga> why is S not updated?
<qschulz> because you can have multiple kinds of fetchers
<zyga> hmm? many at once in one recipe?
<qschulz> you can also specify in which subdirectory of ${WORKDIR} (or S?) to clone
tnovotny has joined #yocto
<qschulz> SRC_URI = "git://something https://anotherthing npm://somethingelse" etc...
<zyga> I see
<qschulz> which fetcher should set S in that case?
<zyga> I think it's all sensible, just not discoverable
<qschulz> I think recipetool or devtool add should have handled this case just fine
<zyga> especially that the license checker is really the means to discover that S is pointing to an empty place
<qschulz> it's usually a good start to write recipes if you're not really use to it
<zyga> ah, I see
<zyga> I didn't do that
<zyga> as I have a go project that wasn't quite go happy with go-mod
<zyga> and I wanted to unroll the stack a little to see if I can do what I need
<zyga> thank you!
tnovotny_ has quit [Ping timeout: 250 seconds]
thekappe has quit [Ping timeout: 250 seconds]
<zyga> I have a go+makefile project
<zyga> and it's a bit hard to figure out exactly what each of the helpers is doing to try to run both build systems
andrei[m]1 has joined #yocto
goliath has quit [Remote host closed the connection]
andrei[m]1 has left #yocto [#yocto]
andrei[m]1 has joined #yocto
vd has joined #yocto
Guest73 has joined #yocto
<RP> rust-llvm is worst than ltp in world builds :(
<JPEW> llvm takes forever in general
tre has joined #yocto
Ad0 has quit [Ping timeout: 250 seconds]
<JaMa> almost as bad as webkit, but still significantly faster than chromium/qtwebengine
Ad0 has joined #yocto
<zyga> go-mod and go are broken with devtool modify source tree
<zyga> but I'll debug exactly why later, it creates a symbolic link loop
<zyga> thank you for the help, I'm a little bit ahead now
andrei[m]1 is now known as agherzan
agherzan has quit [Quit: Reconnecting]
agherzan has joined #yocto
rpcme has joined #yocto
tnovotny has quit [Quit: Leaving]
<rpcme> which repo has the mega manual sources? seems as though some build environment prereqs have changed on the mainline and they need to be added to the yocto project quick build - pzstd zstd
rfuentess has quit [Remote host closed the connection]
<rpcme> hm, well it's just zstd on ubuntu 20.04
tre has quit [Remote host closed the connection]
<RP> rpcme: the yocto-docs repo. I'm aware that needs updating
<rpcme> RP: thanks ... looking
zyga has quit [Ping timeout: 252 seconds]
agherzan has quit [Quit: Reconnecting]
agherzan has joined #yocto
<rpcme> tgamblin: thank you, done editing poky.yaml, working on the patch now.
<RP> kanavin: did you have a chance to look at https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/2473 ?
<RP> vmeson: good/bad news. I fixed the rust issue with buildtools. It doesn't work with other glibc mismatch with uninative scenarios
<rpcme> RP: is the fix for rust on master-next? I am setting up an environment for esteban right now.
<RP> rpcme: yes, I rebased it
<rpcme> nice
florian has quit [Quit: Ex-Chat]
<vmeson> RP: some good news is nice. I'm just finishing the test of openssl-1.1.1l for hardknott and then meetings and then I'll look at oe-core/master-next and the rust status.
<kanavin> RP: I did, it seems like a generic qemu timeout issue, rather than anything to do with the test specifics?
<kanavin> Waiting at most 1000 seconds for login banner (08/25/21 14:18:09)
<kanavin> Connection from 127.0.0.1:56116
<kanavin> Reached login banner in 6.2349326610565186 seconds (08/25/21 14:18:15)
<kanavin> The output:
<kanavin> Couldn't login into serial console as root using blank password
<kanavin> root
<kanavin> Password:
<kanavin> Login timed ou
<kanavin> Poky (Yocto Project Reference Distro) 3.3+snapshot-f07727bf5a5eb0fe96c6b1368d0b010bf25729f0 qemux86-64 /dev/ttyS1
<kanavin> qemux86-64 login: <<< run_serial(): command timed out after 120 seconds without output >>>
Tokamak has joined #yocto
<RP> kanavin: This seems to be happening repeatedly on ubuntu only and only since halstead tried adding those modules. The output in the logs is suspciously empty so the kernel isn't even trying to boot making me suspect a much earlier failure not being shown in the output
<RP> kanavin: it is only the virgl test doing it
zpfvo has quit [Remote host closed the connection]
<kanavin> RP: then I need to log in there and try to reproduce locally. Do you have other failure instances?
rber|res has quit [Remote host closed the connection]
goliath has joined #yocto
<kanavin> e.g. is it specifically ubuntu 20.04, or across ubuntu versions
<RP> kanavin: even dunfell is now breaking
<kanavin> RP: thanks! I'll take it, if you need an urgent fix, we can skip the test on ubuntu.
<RP> kanavin: looks like it could be 2004 specific
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
nsbdfl has quit [Ping timeout: 245 seconds]
nsbdfl has joined #yocto
Tokamak has quit [Client Quit]
Tokamak has joined #yocto
<kanavin> RP: running a build on 2004, it's core-image-minimal so not too long to replicate
agherzan has quit [Quit: issued !quit command]
<kanavin> RP: those version updates are the last batch, I won't be sending more until the next cycle starts :)
Tokamak has quit [Quit: Textual IRC Client: www.textualapp.com]
<RP> kanavin: thanks, hopefully it should be clear when run manually. Fixing the logs to show whatever is wrong would be an added bonus! :)
<RP> kanavin: and thanks for the upgrades. I was hoping we'd get lttng uprev'd but too much else going on...
<kanavin> RP: yes, I'll do a quick bike ride while it builds :) last chance before a week of daily rain
Tokamak has joined #yocto
<RP> kanavin: sounds good. I'm hoping for no rain this weekend for a mtb enduro :)
<RP> rpcme, vmeson: looks like if I swap the linker flags into the target-cc wrapper, rust-native builds in those cases where it was failing
<RP> that sounds like a rust bug to me but what do I know...
<vmeson> RP, I'm not sure if this is only a Canadianism but: You know more than the average bear!
<RP> vmeson: we don't have any bears in the UK so reference points are hard on that one!
<rpcme> RP: will flag this to esteban
agherzan has joined #yocto
<RP> rpcme: I'll test the patch more widely and get it into master-next so we can discuss it
* RP stopped all his builds and restarted but of course sakoman's build pinched all the workers I freed
<sakoman> RP: sorry about that!
frieder has quit [Remote host closed the connection]
agherzan has quit [Quit: issued !quit command]
<RP> tgamblin: the currently allocated builds are a nice example of why it should allocate picky workers first!
<RP> er, picky builders
argonautx has joined #yocto
<tgamblin> RP: hmm, I see that
<tgamblin> qemux86-64-ptest on an ubuntu1604 builder
<RP> tgamblin: right
xmn has quit [Ping timeout: 248 seconds]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
florian has joined #yocto
dlan has quit [Ping timeout: 248 seconds]
florian has quit [Ping timeout: 248 seconds]
dlan has joined #yocto
<moto-timo> is 1604 considered a picky builder?
<tgamblin> moto-timo: buildperf-ubuntu1604 is a picky builder, since it won't run on anything but an ubuntu1604 worker
<moto-timo> Oh, duh. TY
<tgamblin> so qemux86-64-ptest getting assigned to an ubuntu1604 if there's another builder it could use is suboptimal
<tgamblin> s/builder/worker
<tgamblin> I must stop getting the words confused :)
<RP> tgamblin: buildperf-ubuntu1604 is actually easy as it will only run on perf-ubuntu1604 - they're a 1-1 match
<RP> tgamblin: but the general idea is right :)
<RP> oe-selftest-ubuntu is a better example
<tgamblin> Yeah
agherzan has joined #yocto
_franck_ has left #yocto [The Lounge - https://thelounge.chat]
argonautx has quit [Quit: Leaving]
rpcme has quit [Ping timeout: 246 seconds]
vagaruy has joined #yocto
Guest73 has quit [Quit: Client closed]
vagaruy has quit [Ping timeout: 240 seconds]
<kanavin> RP: pokybuild@ubuntu2004-ty-1:~/akanavin/poky/build$ ls -l /dev/dri/renderD128
<kanavin> pokybuild@ubuntu2004-ty-1:~/akanavin/poky/build$ groups
<kanavin> crw-rw---- 1 root render 226, 128 Aug 23 16:54 /dev/dri/renderD128
<kanavin> pokybuild kvm
<kanavin> Ubuntu sets too strict permissions simply
<kanavin> not sure where that is configured, but perhaps adding pokybuild users to render group will do the trick
<kanavin> runqemu prints:
<kanavin> runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: egl: no drm render node available
<kanavin> qemu-system-x86_64: egl: render node init failed
<kanavin> why oe-selftest is printing something entirely different is a mystery :)
<kanavin> halstead, ^^^
rpcme has joined #yocto
<halstead> kanavin: ah, I can update groups
<kanavin> halstead, is there a reason regular users aren't in kvm group?
<kanavin> that'd make life easier, we could run builds and use qemu without sudo pokybuild
<kanavin> halstead, thanks :)
<moto-timo> RP: python3-pluggy upgrade to 1.0.0 in progress. In case there is any chance of getting it in the release. Otherwise we can stage it.
cocoJoe has quit [Quit: Client closed]
<JPEW> sgw: Thanks for the patches. I had already fixed up some of them, just pushed an updated jpew/sbom branch to try out
<JPEW> sgw: It generates a lot of License warnings currently; I think we can tackle cleaning those up although I'm not sure what to do about all the PD licenses
vagaruy has joined #yocto
rpcme has quit [Quit: Client closed]
<RP> kanavin: Thanks! Would be good to figure out why that isn't printed too :/
rpcme has joined #yocto
<kanavin> RP: I'll try to get to that :) this has been ongoing for a while, if qemu isn't able to start, oe-selftest is not helpful :-/
<vmeson> RP: The new master-next built rust-hello-world just fine with sstate-cache, so I started a no sstate-cache build. I will also do world builds and oe-selftests. Is there anything else that you'd suggest for testing or to do next?
<paulg> zeddii, you might get a laugh out of https://bugzilla.yoctoproject.org/show_bug.cgi?id=14522 seeing as RP tried to suck you into that vortex in the past. :)
* paulg volunteers RP to bisect qemu
<paulg> at least we have a reproducer now.
<paulg> I have to wonder if it wouldn't be smart to just move off of mac99 for qemu-ppc ; using e500 would still be ancient, but at least 10y newer...
<zeddii> yah. we aren't tied to that. it was just the right thing at the time.
<paulg> we are going to have to invest time in limping along mac99 in qemu at some point anyway; it already complains with
<paulg> [ 3.534369] legacy IDE will be removed in 2021, please switch to libata
davidinux has quit [Ping timeout: 250 seconds]
<paulg> shifting qemu ppc target platform is probably beyond my skill set ; I thought I was doing good to add a PCI-16550 card and not blow it up.
davidinux has joined #yocto
<zeddii> yah. we've wanted to do that for a while. I'll have to put time it into. or we kill it. or we get a sponsor to convinces to go ppc64 only (and help make sure it is fully working/supported).
<zeddii> s/time it into/time into it/
<paulg> there is no guarantee the e500 doesn't have the same MPIC emulation bug, of course.
jwillikers has quit [Remote host closed the connection]
<zeddii> paulg, worth a try. maybe we can figure out a streamlined way to test a new platform.
<paulg> I'd consider having a tinker with doing an e500 machine, but I'm pretty sure I'd fail miserably when it comes to mouse/touchscreen/sound crap that is probably table stakes for sato validation.
vagaruy has quit [Ping timeout: 240 seconds]
<zeddii> the screen was an issue before, but if we look into it and see no route to graphics, we can bail pretty early. I'll check the latest machine specs on the qemu site.
<RP> paulg: we don't need sound, touchscreen just needs usb
<RP> graphics is probably the hard bit
<RP> paulg: showing how broken it is helps a lot as it gives ups a reason to drop it unless someone steps up to help it
rpcme has quit [Quit: Client closed]
<RP> paulg: thanks for that. It is worrying that adding the pci card breaks it too :/
<zeddii> debugging a virtualized interrupt controller on ppc sounds fun though!
rpcme has joined #yocto
<tgamblin> anyone else unable to reach git.yoctoproject.org?
<halstead> tgamblin: I'm getting slow page loads.
vagaruy has joined #yocto
<RP> zeddii: you're volunteering? :)
<tgamblin> halstead: consistent timeouts for me
* paulg wonders if he left breadcrumbs on the qemu build-from-source in the yocto IRC logs. Shoulda taken notes....
<halstead> tgamblin: CPU is near the alert level. OOM killer just took out a few processes. I'll find the issue. It should be responsive again.
<vmeson> halstead: tgamblin it seems to be back now.
<vmeson> well, I could clone using git:// but the git.yp.org site isn't responding.
* vmeson tries gopher!
<halstead> tgamblin: vmeson RP. I'm adding more memory. Short downtime. This might mess with builds in progress.
vd has quit [Quit: Client closed]
vd has joined #yocto
<halstead> git.yoctoproject.org is very responsive now.
<paulg> RP, if that irq <n> nobody" cared" happens in the wild again, it would be good to capture /proc/interrupts from the instance... but I've no idea how hard that'd be to plug into the QA tests.
<RP> paulg: we struggle with this side of things. I think tgamblin was looking at dmesg in failure logging so maybe we could ride those coattails?
<halstead> kanavin: Nobody has asked for their user account to be in the kvm group. Everyone has done their testing as pokybuild. I will add your user since it would be helpful to you.
<RP> tlwoerner: There was an interesting reply upstream on the pseudo issue: https://sourceware.org/pipermail/libc-help/2021-August/005998.html
<RP> kanavin, halstead: hmm, this may not be the real issue then? :/
<kanavin> RP: I've run the build as pokybuild
<kanavin> since qemu not using kvm on a heavily loaded machine would be torture :)
<paulg> yeah - it all of course relies on the turdburger being still operable enough for random ssh commands like "dmesg" and "cat /proc/interrupts" and so on ; but such a place to plug in generic data collection would be nice.
<RP> paulg: I dream of this stuff all working nicely
<RP> vmeson: I'm not sure where we're at with rust now. I'm basically waiting on the next autobuilder build to see what that shows
<tlwoerner> RP: amazing that you got any reply to such a specific question, nevermind such a good reply
whuang0389 has joined #yocto
rpcme has quit [Quit: Client closed]
<whuang0389> how can I nest bb.utils.contains? for example: USE_X11="${@bb.utils.contains("DISTRO_FEATURES", "wayland", "0", "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '1', '0', d)}", d)}"
<whuang0389> but in the case where I have x11 enabled, USE_X11 gets set to the value ${@bb.utils.contains('DISTRO_FEATURES', 'x11', '1', '0', d)} and not '1' or '0'
<RP> tlwoerner: it was lovely to get a reply, I thought I wasn't going to!
<tlwoerner> RP: so an auditor library then?
<RP> tlwoerner: maybe, I'd need to look at how that works
florian has joined #yocto
<moto-timo> python3-pluggy upgrade sent. all ptests pass and AUH built on "all" platforms, so it should be good to go
<RP> moto-timo: thanks, will try and get that into a build. Things are a bit backlogged
<vmeson> whuang0389: there do seem to be some examples of that: $ cd .../poky.git then $ rg bb.utils.contains.*bb.utils.contains -- where rg = ripgrep or grep.
<vmeson> *grep -r
<sgw> JPEW: thanks, I will grab the update, what other license warnings are you seeing? From the SPDX valdiate tools?
rpcme has joined #yocto
<whuang0389> ok thanks!
amitk has quit [Ping timeout: 240 seconds]
florian has quit [Ping timeout: 252 seconds]
<vd> do you guys use dracut?
sethfoster has quit [Ping timeout: 250 seconds]
tp43_ has joined #yocto
d0ku has quit [Ping timeout: 248 seconds]
leon-anavi has quit [Quit: Leaving]
<vd> I'm wondering how well it integrates with yocto
sethfoster has joined #yocto
Ad0 has quit [Ping timeout: 252 seconds]
prabhakarlad has joined #yocto
Ad0 has joined #yocto
florian has joined #yocto
<Tokamak> anyone familiar with a nice way to determine how much each component contributes to a final image size? ideal tool would be something like df utility for the package dependency hierarchy of a given recipe/image?
<vmeson> Well, most things work but: bitbake lib32-rustfmt for qemuarm64: rustfmt_1.4.2.bb:do_compile) failed with exit code '1'
<JaMa> Tokamak: buildhistory contains installed_packages_sizes.txt which helps
<JPEW> sgw: A lot of recipes use just "BSD" which isn't valid (need to know which BSD); I will add a special expception for Public Domain (PD) because there isn't really a sane way to handle that :/
<JPEW> A few other minor ones that I think just need the license clarified or a new SPDX license map
<JaMa> s/_/-/g
<Tokamak> thanks for the pointer JaMa
<sgw> JPEW: Yeah, I saw that after running with your new code
goliath has quit [Quit: SIGSEGV]
jmiehe has joined #yocto
<vmeson> RP: tried to build musl after glibc based rust-hello-world: -- *** 0149: raise OSError(errno.EEXIST, "Link %s already exists as a file" % dest, dest)
vagaruy has quit [Ping timeout: 250 seconds]
dev1990 has quit [Quit: Konversation terminated!]
vagaruy has joined #yocto
<vagaruy> Does anyone here use yocto generated linux in a medical device. Curious about the SOUP analysis procedure utilized by various people as required by FDA 62304 guidance document.
<RP> vmeson: we'll probably need to start opening bugs for the issues
<paulg> moar bugz!
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
camus1 is now known as camus
jmiehe has quit [Quit: jmiehe]
florian has quit [Ping timeout: 250 seconds]
d0ku has joined #yocto