**** BEGIN LOGGING AT Wed Sep 30 02:59:57 2020 Sep 30 04:56:14 otavio: thats ok, but it does not seem for better as it is. Sep 30 07:12:36 sgw: https://autobuilder.yoctoproject.org/typhoon/#/builders/102/builds/979/steps/8/logs/step1c - it tried to dump the info but failed. Does that mean qemu is dead? Sep 30 08:13:04 The_Pacifist: or bitbake virtual/kernel -c menuconfig and check if the option is selected :) both ways work Sep 30 08:27:47 Hi guys, to solve my bitbaking issues of yesterday I tried it using the CROPS docker image and built the image inside the container. I got no errors. Is it possible to run qemu inside of the docker container? If not, can I run the created image with 'runqemu' on my real host instead (Arch Linux)? Sep 30 08:41:50 dleppich: You should be able to run "runqemu slirp" as the slirp option uses emulated networking instead of a tun/tap device Sep 30 08:42:29 I assume "slirp" is the name of the emulated networking implementation Sep 30 08:43:23 That should work fine unless you're doing network intensive testing (slirp is a bit slow) Sep 30 08:46:18 Hi there, quick question Sep 30 08:46:25 Hi guys,I would like to add a new file into the kernel-image-fitimage PACKAGE. I've tied it like that in my recipes-kernel/linux/linux-imx_5.4.bbappend :FILES_kernel-image-fitimage += "/boot/fitconfig"andFILES__append "/boot/fitconfig"In the end I can see in the env logs, that the appended content gets overwritten by the kernel.bbclass file. What Sep 30 08:46:26 is the right way to do that? I thought I have it done the right way. In the end I need the "fitconfig" file on my target /boot/fitconfig. I guessits in the correct place to come with the kernel-image-fitimage. Sep 30 08:46:58 ## $FILES_kernel-image-fitimage [2 operations]# append /home/linderth/workspace/yocto-builder-warrior/meta-port/recipes-kernel/linux/linux-imx_5.4.bbappend:71# "/boot/fitconfig"# set kernel.bbclass:93 [__anon_112__home_linderth_workspace_yocto_builder_warrior_yocto_meta_classes_kernel_bbclass]# "/boot/fitImage-${KERNEL_VERSION_NAME} Sep 30 08:46:59 /boot/fitImage"# pre-expansion value:# "/boot/fitImage-${KERNEL_VERSION_NAME} /boot/fitImage"FILES_kernel-image-fitimage="/boot/fitImage-5.4.24-r0+gbabac008e5cf /boot/fitImage" Sep 30 08:47:39 paulbarker: I was stupid. I generated the 'core-image-minimal' image for the 'beaglebone' and tried running it in qemu -.- I'm trying to build it for qemuarm now and will try it again after it finishes :D Sep 30 09:07:37 Hi , i want try kdump in yocto , so i need to build a capture-kernel and install that to rootfs. does anyone know how to achieve that ? thanks Sep 30 09:14:13 hello guys ! I have a basic recipe to build libiio. git://github.com/analogdevicesinc/libiio.git Sep 30 09:15:16 the recipe build with cmake the libarary, by the way I want to instruct cmake to build also the examples in the examples folder of the repo. How can I do that ? Sep 30 09:16:49 The CmakeList.txt in the root folder of the project reports this line Sep 30 09:16:57 option(WITH_EXAMPLES "Build examples" OFF) Sep 30 09:17:31 so I have to do something in the recipe to set the option, but I don't really know how Sep 30 09:18:37 EXTRA_OECMAKE += "-DWITH_EXAMPLES=ON" maybe? Sep 30 09:19:45 I suspected something like that, thanks @rburton Sep 30 09:19:57 ilkappe, if you look here: https://stackoverflow.com/questions/18435516/how-to-set-a-cmake-option-at-command-line/48503241 Sep 30 09:20:13 looks like the option is WITH_EXAMPLES, you pass those with -D to cmake, and EXTRA_OECMAKE is how to pass extra arguments Sep 30 09:30:31 rburton, I can confirm now Sep 30 09:40:52 I examined my poky repo, and found `poky/bitbake/lib/bb/fetch2/s3.py`. Hence, there seems to be an s3 fetcher. Is it functional and ready to be used in SRC_URI variable in recipes? I'm asking, because `https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-SRC_URI` doesn't mention `s3://` style URIs. Sep 30 09:48:43 manuel1985 interesting. fetchers are normally in the bitbake manual not yocto but indeed s3:// is also not even mentioned Sep 30 10:00:11 Hmm and it doesn't seem to work either. :/ Sep 30 10:00:11 /usr/bin/env aws s3 cp s3://redacted-qt-releases/redacted-qt.arm64v8-1.3.0 /home/manuel/vps/repos/yoc/redacted/build/downloads/redacted-qt.arm64v8-1.3.0 failed with exit code 1, output: Sep 30 10:00:11 fatal error: An error occurred (404) when calling the HeadObject operation: Key "redacted-qt.arm64v8-1.3.0" does not exist Sep 30 10:01:54 Ui, that might have been my mistake. I forgot the `.tar.gz` at the end. :D Let's give it another try... Sep 30 10:09:10 Ok, it seems to have almost worked. I think it downloaded the tarball successfully. It seems Yocto expects the tarball to be a source tree beginning with `packagename-version`, but in my case, that's not the case. I want the tarball to go to the rootfs, unmanipulated. Can I tell Yocto not do unpack it automatically? Sep 30 10:10:07 yes Sep 30 10:10:22 let me get youthe manual Sep 30 10:11:22 (The tarball contains a `docker save`d docker image, which gets `docker load`ed at first boot by a systemd service.) Sep 30 10:11:22 manuel1985 https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#bb-the-unpack. Do not forget you need to put this tarball somewhere in the ${D} directory so it can be packaged. Sep 30 10:15:13 ptsneves: Thanks! That's exactly what I was looking for. I should have taken a look in the manual at the first step. It's actually totally logical that this is to be set in the `do_unpack` stage. Should have spent a bit more time doing actual thinking instead of just googling it right away and asking here. Sep 30 10:15:59 Yocto is really a fine piece of software. :) Sep 30 10:16:03 manuel1985: FWIW, the new docs.yoctoproject.org has a search feature (which probably needs some love but better than nothing :) ) Sep 30 10:17:21 manuel1985 i would say Yocto is one of the few pieces of modern software where the manual is a better resource than searching random google stuff. A lot of users of yocto are using it in closed projects so there is less blog posts etc Sep 30 10:19:24 ptsneves: aaaaaand it's easy to do things the wrong way in Yocto and SO has many examples of that :) Sep 30 10:20:30 qschulz indeed. It is a bit unfortunate and i wonder why. It is quite unique to yocto. Sep 30 12:00:23 Hi everyone. Sep 30 12:00:46 I have a question regarding libgpiod (dunfell) Sep 30 12:01:17 I am adding libgpiod to IMAGE_INSTALL. However all gpio-tools like gpiodetect aso are missing from the image. Any ideas? Sep 30 12:01:58 thomas_dee: look at the recipe. it probably puts those into another package. 'oe-pkgdata-util list-pkg-files -p libgpiod' will list the files and packages Sep 30 12:04:35 rburton Thanks, I guess it is libgpiod-tools. I'll try it. Sep 30 13:07:31 jonmason: hello Sep 30 14:05:39 dl9pf, smurray: There are pseudo abort patches in master-next. I have gotten core-image-sato working, running a wider test on the autobuilder now Sep 30 14:11:15 RP: will pull for a local run Sep 30 14:13:09 dl9pf: thanks, will be interesting to see how stable things are Sep 30 14:20:44 dl9pf: sadly it looks like its blowing up on the autobuilder :( Sep 30 14:22:06 :( , build runs here now Sep 30 14:33:46 i'd copy the pseudo recipe also in my dunfell tree and trigger a build Sep 30 14:39:44 Boring qemu question again : I can use runqemu for basic invocation of my qemu images, but I need to add a fair amount of functionality. I guess I could create a new version of runqemu that takes precedence over the original, or I could write a new one from scratch as mender do with "mender-qemu"... Are there any reasons you can suggest to choose one approach over the other? Sep 30 14:40:49 pev: what func you need to add, give an example Sep 30 14:40:52 qemu arguments ? Sep 30 14:41:24 RP: core-image-minimal built ... Sep 30 14:48:14 core-image-sato built as well Sep 30 14:48:46 cherry-picking the pseudo patches to dunfell and running it on hot (old) sstate-cache will trigger quickly Sep 30 14:50:28 dl9pf: Interesting, that matches my local builds Sep 30 14:50:52 dl9pf: I wonder why the autobuilder is seeing things. I've sent email to the mailing list describing how to debug issues btw Sep 30 14:51:01 or at least giving more info on it Sep 30 14:51:11 * dl9pf reading ... Sep 30 14:51:27 dl9pf: different combinations of arguments to qemu-system-xxxx than I can do with runqemu but also looking to see if I can bridge the networking instead. Sep 30 14:54:38 RP which list - we have to many and groups.io does not make it easy .... Sep 30 14:54:47 dl9pf: oe-core Sep 30 14:56:21 ok, found it ... doh. groups.io ... just give me the latest message at the top Sep 30 14:59:29 dl9pf: do_stash_locales() appears to be breaking glibc (the issue in my email example). This shows we're not catching issues deterministicly though Sep 30 14:59:56 I think we'll have to add some sanity tests of some kind to prove the database is sound Sep 30 15:05:31 i see entries like: Sep 30 15:05:39 Hi, I'm trying to write a recipe (I'm following the bootlin yocto course) for an ncurses based space invaders game. This game is available on source forge. I have troubles fetching the tarball / the checksum changes everytime I try to bake. This is the link: https://sourceforge.net/projects/ninvaders/files/latest/download. I guess that sourceforge does not offer a way to directly download the tarball without going through their 'please wait 5 seconds' page, Sep 30 15:05:40 but I'm not quite sure if that's the issue. Can someone help me out please? Sep 30 15:06:01 RP: (patches ported to dunfell and running on sstate-cache) Sep 30 15:06:06 RP: path mismatch [3 links]: ino 319877528 db '/home/dl9pf/yocto/build-qemux86-64/tmp/work/all-agl-linux/update-rc.d/0.8-r0/pkgdata/update-rc.d' req '/home/dl9pf/yocto/build-qemux86-64/tmp/pkgdata/qemux86-64/update-rc.d'. Sep 30 15:07:49 dleppich: check out other recipes ... e.g. I see for example: SRC_URI = "${SOURCEFORGE_MIRROR}/acpid2/acpid-${PV}.tar.xz Sep 30 15:08:19 dl9pf: is that with a clean tmp directory? Sep 30 15:09:09 dl9pf: I think that message is suggesting ${TMPDIR}/pkgdata should be in the ignore list Sep 30 15:09:11 I wiped tmp and build from sstate-cache Sep 30 15:09:29 i can do a full w/o sstate Sep 30 15:09:44 dl9pf: since pseudo-native is different, I think it won't reuse much? Are you using hashequiv? Sep 30 15:10:39 no Sep 30 15:11:27 dl9pf: Thanks! I could swear I tried it this way before and it did not work.. Not it works like a charm.. Sep 30 15:11:31 dl9pf I think it will just rebuild everything then (which is fine, just clarifying the config) Sep 30 15:11:48 hmm, it used sstate a lot from what I saw Sep 30 15:12:19 Should I be able to use PATH_prepend in my own layer? Sep 30 15:14:27 dl9pf: maybe just source date epoch? Sep 30 15:15:37 dl9pf: I think to make these tests really work (and make it easier to debug) we're going to need a database integrity check Sep 30 15:15:56 won't be perfect but would catch the errors more deterministically Sep 30 15:20:46 RP: makes sense, could be executed at different times to narrow the root cause down. Sep 30 15:29:41 RP: no sstate-cache reuse failed early at Sep 30 15:29:42 path mismatch [3 links]: ino 331056873 db '/home/dl9pf/yocto/build-qemux86-64/tmp/work/qemux86_64-agl-linux/shadow-securetty/4.6-r3/pkgdata/shadow-securetty' req '/home/dl9pf/yocto/build-qemux86-64/tmp/pkgdata/qemux86-64/shadow-securetty'. Sep 30 15:30:42 shadow-securetty_4.6.bb:do_package_qa Sep 30 15:30:42 shadow-securetty_4.6.bb:do_package_write_rpm Sep 30 15:32:36 dl9pf: looks like the same pkgdata issue Sep 30 15:33:01 dl9pf: I'll put a fixup in master-next for that and the glibc issue I found Sep 30 15:33:58 qschulz: right, that is what I was doing but wanted to confirm it was configured with the right bsp layer Sep 30 15:35:17 dl9pf: pushed Sep 30 15:44:55 ok build goes now further Sep 30 15:46:10 dl9pf: there is a check command in pseudo, pseudo -C, so we just need to run this at appropriate points and process the data Sep 30 15:49:36 dl9pf: of course it can't run when pseudo is running Sep 30 15:51:48 RP: dunfell+your patches to pseudo: Sep 30 15:51:53 https://www.irccloud.com/pastebin/CTjZIxJO/ Sep 30 15:59:56 RP: I can't wait to be able to use f-strings in oe when we bump the required python version next. I'm sure it'll be a while, but still :) Sep 30 16:00:18 useradd: Warning: missing or non-executable shell '/bin/false' Sep 30 16:00:18 WARNING: /home/dl9pf/yocto/build-qemux86-64/tmp/work/all-agl-linux/agl-users/0.1-r0/temp/run.useradd_sysroot.90853:1 exit 1 from 'exit 1' Sep 30 16:00:26 exec bit on /bin/false ? Sep 30 16:17:56 dl9pf: I suspect not. What does pseudo.log say? Sep 30 16:18:10 kergoth: I've mixed feelings on that to be honest Sep 30 16:19:01 RP: not high priority, but you and rewitt were working on some WIP changes for toaster container failure on master back in July Sep 30 16:19:12 i hate %s, and .format() is too verbose, so i'm happy about it Sep 30 16:19:13 RP: wondering if those patches you had live in a repo somewhere? Sep 30 16:19:22 as long as no-one goes trying mass conversions to it Sep 30 16:19:43 kergoth: I guess %s doesn't bother the C programmer in me :) Sep 30 16:19:49 RP: for agl-users there is a pseudo folder but no pseudo.log Sep 30 16:20:00 moto-timo: didn't we fix it? Sep 30 16:20:24 RP: not according to my most recent build test on travis ci Sep 30 16:20:52 moto-timo: how was it failing? I'm blanking on this :( Sep 30 16:20:56 RP: it'd help if our bb.note/bb.warn/etc acted more like print or logger, i think. if i could bb.note("something %s somethingelse", foo) i think i'd be less annoyed than using % or .format() directly Sep 30 16:21:04 dl9pf: that is odd :( Sep 30 16:21:17 * moto-timo hunts for the link... pardon the delay Sep 30 16:22:45 dl9pf: can you have a look at that run.useradd_sysroot.12719 script and see if it is starting pseudo and if so, where its pointing it? Sep 30 16:23:07 There should be a log somewhere Sep 30 16:23:08 RP: https://travis-ci.org/github/moto-timo/toaster-container/jobs/709583452 Sep 30 16:23:34 RP: unless something else is causing the selenium delays... that log is arguably not helpful Sep 30 16:24:43 RP: probably not worth distracting you right now Sep 30 16:24:46 moto-timo: the bit where it says xmlrpc.client.Fault: :"> Sep 30 16:24:51 moto-timo: that is revealing Sep 30 16:24:58 https://www.irccloud.com/pastebin/y6qKtMzf/ Sep 30 16:25:02 RP: 11 Sep 30 16:25:13 moto-timo: I thought we'd fixed that Sep 30 16:25:52 RP: I had an internal email thread where rewitt said you two were testing some patches, but I lost track after that (in July) Sep 30 16:26:19 but yes, the xmlrpc fail is the smoking gun you had already identified :) Sep 30 16:26:37 moto-timo: I thought it was fixed. Can you get the bitbake-cookerdaemon.log from that? Sep 30 16:26:50 is there a variable like ${bindir} which I can use for /var/lib? Sep 30 16:27:55 moto-timo: http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib?id=16f820a2a82c12184e7ea0734a61c45a22e82530 may have broken it somehow Sep 30 16:28:48 dl9pf: hmm, and PSEUDO_LOCALSTATEDIR=/home/dl9pf/yocto/build-qemux86-64/tmp/work/all-agl-linux/agl-users/0.1-r0/pseudo/ is empty? Sep 30 16:29:53 yes, empty. Sep 30 16:30:14 moto-timo: http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib?id=a6709152e9788418e6c9431851437eb8ec4c6b46 is an example of the kind of fixes/tweaks that may be needed for toaster Sep 30 16:30:48 moto-timo: if you can give me a simple reproducer set of steps I can problem fix it. I can never remember how to use toaster Sep 30 16:31:18 dl9pf: I'd probably try stracing that script and running it by hard to see if its possible to figure out what is happening Sep 30 16:33:40 * moto-timo refreshes on how to get travis to save artifacts Sep 30 16:55:55 moto-timo: You don't have to get it to save the artifacts, just get it to dump the log on failure Sep 30 16:56:40 moto-timo: I mean, I even dump the hex of the image so that I can convert it back to the image :-D Sep 30 17:13:17 RP: will do the strace next. got his as well: Sep 30 17:13:20 Exception: subprocess.CalledProcessError: Command '['cross-localedef', '--verbose', '--uint32-align=4', '--little-endian', '--add-to-archive', '/home/dl9pf/yocto/build-qemux86-64/tmp/work/qemux86_64-agl-linux/agl-demo-platform/1.0-r0/rootfs/usr/lib/locale/de_DE']' died with . Sep 30 17:13:27 path mismatch [1 link]: ino 356967293 db '/home/dl9pf/yocto/build-qemux86-64/tmp/work/qemux86_64-agl-linux/agl-demo-platform/1.0-r0/rootfs/usr/lib/locale/locale-archive' req '/home/dl9pf/yocto/build-qemux86-64/tmp/work/qemux86_64-agl-linux/agl-demo-platform/1.0-r0/rootfs/usr/lib/locale/locale-archive.guW8Ke'. Sep 30 17:18:01 dl9pf: that should have been fixed by my pseudo change to track fds over link operations Sep 30 17:18:22 rewitt: I was wondering about that image hex dump :) Sep 30 17:26:21 RP: Like I have money to spend on remote storage for artifacts :) Sep 30 18:19:23 * moto-timo multitasking and priority interupting Sep 30 18:19:58 both poorly :) Sep 30 19:00:04 zeddii: do you know anything about scsi_debug? Sep 30 19:07:42 zeddii: because its not making a device when it should be Sep 30 19:26:14 I can't say that I've had to use it in any detail. I can help debug if it might be an issue with the various reference kernels. Sep 30 19:35:48 I am new to Yocto and were able to do 'bitbake core-image-minimal' successfully via CentOS 7.8 on ppc64le (using yocto-3.1.2 from git). Because CentOS has an older version of glibc, so I upgrade the system to 8.2. But rerunning the 'bitbake core-image-minimal' produces an error with exit code 135, and I can't find any useful info to narrow down the issue. Any help is appreciated. Sep 30 19:36:09 ERROR: Task (/yocto/waiki/poky/meta/recipes-devtools/flex/flex_2.6.4.bb:do_package_qa) failed with exit code '135' Sep 30 19:36:09 ERROR: Task (/yocto/waiki/poky/meta/recipes-extended/iptables/iptables_1.8.4.bb:do_package_qa) failed with exit code '135' Sep 30 20:14:38 zeddii: my understanding is that modprobe scsi_debug results in fake /sys/block/sd* being created. works on my debian box. my qemuarm64 from poky master doesn't make the entries Sep 30 20:24:26 missing userspace helper ? Sep 30 20:25:57 hmmm. no mention of one in the docs. Sep 30 20:45:48 Good evening all, looking at generating a dependency graph in dunfell, the docs say I should get recipe-depends task-depends and pn-buildlist, but I'm not getting the recipe file. How can I generate one? Sep 30 21:00:10 Happy Hour starts !!! Yay ! Sep 30 21:46:27 I got a "403 Forbidden" when accessing this link: http://sstate.yoctoproject.org/3.1.2/ ---- using this link as the mirror site in the local.conf. Should I use a different site? Sep 30 21:48:10 waiki, if you haven't do so, try the buildtools.. 'scriptsinstall-buildtools' and see if that helps Sep 30 21:51:58 armpit, where can I find the 'scriptsinstall-buildtools' ? Sep 30 21:58:20 armpit, found it. it is scrips/install-buildtools. looks like there is no ppc64le support Sep 30 22:02:38 shouldn't be that difficult to add Sep 30 22:02:50 i did the work to make it not x86-64 specific when i added arm64 Sep 30 22:03:21 that install-buildtools script is just a helper, you can build your own buildtools and install it by hand Sep 30 22:04:53 Hi Sep 30 22:05:19 Can you help me Sep 30 22:05:21 ? Sep 30 22:05:39 I am trying to install an image from hddimg Sep 30 22:06:01 And my issue is that I can not select a target Sep 30 22:06:18 I want to isntall on sda Sep 30 22:06:36 Since sdb is the usb drive -the installer- Sep 30 22:07:26 And this is the text on the installer is this: "Please select an install target or press n to exit ( ):" Sep 30 22:14:11 rburton okay, will take a look and thanks for the tips. Sep 30 23:17:50 RP: i missed the locale cherry-pick. that is fine. the useradd recipe still bargs. will investigate. running it 3 times manually fixes it and the build proceeds. Sep 30 23:22:46 dl9pf: I nearly have an integrity check patch ready Sep 30 23:25:52 dl9pf: and I just confirmed it did correctly spot the locale problem in glibc Sep 30 23:30:22 dl9pf: added to master-next. If you add "pseudo -Z" commands as pre/postfuncs to install/package/package_write_* tasks it will trigger integrity tests. I'll have to look more at integration tomorrow Sep 30 23:30:48 I hacked some into glibc to check it works, the rest is tomorrow's problem :) Sep 30 23:59:08 Hi, are people using autobuilder2 to run continuous integration for their layers, or their yocto-build custom embedded images, or both? Oct 01 01:57:00 khem: hello! I remember you telling me about a repository setup to start running webassembly with a go backend, do you have that link still available? **** ENDING LOGGING AT Thu Oct 01 02:59:57 2020