**** BEGIN LOGGING AT Wed Dec 12 03:00:00 2018 Dec 12 03:31:59 New news from stackoverflow: Yocto build fails due to conflict between recipes Dec 12 07:21:44 ERROR: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1001/bus,guid=4903862dd299a0a7005f2ab15c10b2bd"; export SSH_AGENT_PID="1847"; export SSH_AUTH_SOCK="/run/user/1001/keyring/ssh"; export no_proxy="localhost,127.0.0.0/8,::1"; export NO_PROXY="localhost,127.0.0.0/8,::1"; export http_proxy="http://192.168.:8080/"; export HTTP_PROXY="http://192.168.:8080/"; export PATH="/h Dec 12 07:21:57 is someone familiar with the issue above? Dec 12 07:22:57 PATH="/home/amit/fsl-community-bsp/sources/poky/scripts:/home/amit/fsl-community-bsp/build/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin/arm-fslc-linux-gnueabi:/home/amit/fsl-community-bsp/build/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/defaultpkgname/1.0-r0/recipe-sysroot/usr/bin/crossscripts:/home/amit/fsl-community-bsp/build/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/defaultpkgn Dec 12 07:24:49 output afer running 'bitbake core-image-base' Dec 12 07:28:02 nacknick_: by just looking at it, "http_proxy="http://192.168.:8080/"; export HTTP_PROXY="http://192.168.:8080/"" seems pretty wring. Dec 12 07:28:12 s/wring/wrong/ Dec 12 07:28:32 trying to use such proxy addresses pretty much should cause the fetcher to fail Dec 12 07:28:50 LetoThe2nd I'm not using proxy at all Dec 12 07:29:16 then maybe find out where that comes from? Dec 12 07:30:44 LetoThe2nd now I see there is a env var with that value, i have no idea why Dec 12 07:35:42 LetoThe2nd - OK. seems that export http_proxy="" helped Dec 12 07:37:12 :-) Dec 12 07:39:19 under build/tmp/work I have two folders: armv7at2hf-neon-fslc-linux-gnueabi, x86_64-linux Dec 12 07:39:59 by what those folders are created? Dec 12 07:40:46 by bitbake Dec 12 07:42:31 not by who, but by what parameter I mean Dec 12 07:43:34 not by a parameter per se. those reflect the machine/architecture a specific artifact is meant to run on. Dec 12 07:43:40 by the $MACHINE? Dec 12 07:43:44 no Dec 12 07:43:48 machine is a part of it. Dec 12 07:45:08 I just built all bitbake from the begining, what I have TWO folders? I build for ARM board, why x86_64-linux is created as well?? Dec 12 07:45:16 why I have* Dec 12 07:45:37 because during the build process there are things created that are meant to run on the host Dec 12 07:45:43 ok Dec 12 07:46:21 more often you have 3 or 4 folders there. one host, one allarch, one machine specific, and one tune-specifc Dec 12 07:46:59 what is tune-specific? Dec 12 07:47:27 a bit simplified: "cortexa9" for example Dec 12 07:48:00 now I have 4 :S Dec 12 07:48:04 most packages do not really only work on a specific board, but a specific arch. usually only the kernel and bootloader are really tied to the machine Dec 12 07:49:32 so inside all those folders, if I'm looking for the binary that will finally run in the target machine, where can I find it? in what folder? Dec 12 07:51:09 its not that simple Dec 12 07:51:30 all-fslc-linux, imx6ullevk-fslc-linux-gnueabi armv7at2hf-neon-fslc-linux-gnueabi, x86_64-linux armv7at2hf-neon-mx6ul-fslc-linux-gnueabi, armv7at2hf-neon-fslc-linux-gnueabi, x86_64-linux, armv7at2hf-neon-mx6ul-fslc-linux-gnueabi Dec 12 07:51:36 now I have those 5 folders Dec 12 07:51:54 i remember your case very well from yesterday, and i'm pretty reluctant to assist here, as i'm totally convinced you're doing it wrong. Dec 12 07:52:06 (and don't want to be blamed later) Dec 12 07:52:42 I'm open to here your alternative Dec 12 07:53:07 you won't be blamed anyway Dec 12 07:53:11 my approach would be to to append/extend the recipe that creates/fetches/whatevers the binary, and extend the do_compile step Dec 12 07:53:24 you can append your whatever security tinkering there Dec 12 07:53:38 thats one approach Dec 12 07:54:01 ok. so let me introduce you the restrictions, and tell me if your solution is still relevant Dec 12 07:54:09 the other one is to use a ROOTFS_POSTPROCESS command. in which case you would operate on the rootfs directly before it gets packed Dec 12 07:57:47 LetoThe2nd my product is a script (not only, but for simplify restrictions). The script gets the original binary and modifies it. IT HAS TO BE DONE THAT WAY! running a script on ready-to-run binary, and replace it with the output of the script Dec 12 07:58:07 are your both solutions are still relevant? Dec 12 07:58:11 nacknick_: yes. Dec 12 07:58:19 no need to scream. Dec 12 07:58:26 hh :) Dec 12 07:59:38 ok. so which approach to choose? because I'm not familiar with none of them Dec 12 07:59:56 I mean the two you mentions Dec 12 08:00:02 mentioned* Dec 12 08:00:16 it depends. in both cases you'll probably introduce a big chunk of non-reproductibility Dec 12 08:00:31 my gut feeling would be https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-ROOTFS_POSTPROCESS_COMMAND Dec 12 08:00:50 what do you mean non-reproductibility? Dec 12 08:01:04 but seriously, if you run into problems with image cretion later: make totally sure that you mention that you are doing evil magic there. Dec 12 08:01:41 nacknick_: OE is all about reproductibility. given a specific state of the layers, i can rebuild a functionally identical image again and again, anytime i want Dec 12 08:01:51 thats what you're about to break Dec 12 08:02:24 you are about to create a build process that will only work if your script magic, and whatever external tricks it does are working Dec 12 08:02:50 so here's option 3: have OE only create a tarball. do postprocess and pack into an image externally Dec 12 08:03:13 in that case you can at least be sure that you always get a stable tarball out of the system. Dec 12 08:04:27 LetoThe2nd first question: using ROOTFS is there a way to choose what binaries I want to appply my script on? Dec 12 08:05:02 you get handed a path to a full root file system do whatever you want there. Dec 12 08:05:12 you can also rm -rf /* Dec 12 08:05:20 but don't blame anybody else then. Dec 12 08:06:33 LetoThe2nd 2nd question: what's the difference if I modifies the binary before it's getting packed to your third suggestion; to unpack the binary and re-pack it modified..? Dec 12 08:07:16 the difference is if you are acting *inside* or *outside* of the OE build process. Dec 12 08:07:55 you mean to unpack it from the final image? (wic)? Dec 12 08:07:55 which again to choose properly, depends a lot on your product workflow, build automation, etc. Dec 12 08:08:07 nacknick_: no. read again waht i wrote Dec 12 08:09:03 where do I configure a postprocess? Dec 12 08:09:04 but seriously, i already invested way more time than i wanted to. if you really care about that thing, go find a competent consultant to assist you. Dec 12 08:09:17 i handed you the link to the documentation. Dec 12 08:09:24 and now, i'm off to my own paid work. Dec 12 08:09:26 good luck Dec 12 08:09:45 thanks a lot Dec 12 08:10:17 Any mode ideas how to debug gstreamer-plugins-good not getting installed? The files are there in the image of the package itself, the package is listed in the manifest, but it's not getting copied into the sysroot. Dec 12 08:10:56 It used to work, until I updated the seemingly unrelated meta-raspberrypi layer, and now nothing I've tried makes it work. Dec 12 08:12:14 Last thing I can think of is to revert the raspi layer and see if that helps... Dec 12 08:37:01 Yeah... reverted raspi layer and it's back to working.. bisecting now Dec 12 09:23:07 under do_install of 'grep' binary I added a line that copies another binary and overwrites the existing grep ELF. I checked and it actually replace it. but when running the image on the board, seems that the original grep was kept. any idea why? Dec 12 09:24:31 How do I update this in meta-raspberrypi? https://github.com/raspberrypi/firmware/issues/1051 Dec 12 09:55:47 I tried a newer kernel, didn't help. Seems like that repo isn't directly used. Dec 12 11:04:30 where can I change the flags of the compiler that bitbake uses? Dec 12 11:18:00 anyone got time to help me with a (probably beginner) issue? Dec 12 11:19:59 i'm trying to include the header files with ' IMAGE_INSTALL_append = " kernel-devsrc" ' but while do_install i get the following errormsg: cp: cannot stat 'arch/arm64/kernel/vdso/vdso.lds': No such file or directory Dec 12 11:20:41 nacknick_: for all recipes, or just one? Dec 12 11:21:07 just one Dec 12 11:21:11 i think Dec 12 11:22:32 i can paste a little more of the errormsg if that would help, but it only appears once Dec 12 11:22:49 and only with "kernel-devsrc" Dec 12 12:32:24 rburton - both please. all and just one Dec 12 12:35:38 How do I add an extra install step to a cmake recipe? I don't know... do_install_append or something? Dec 12 12:40:15 pepijndevos: yes Dec 12 12:40:26 nacknick_: in a recipe just extend CFLAGS Dec 12 12:43:19 Actually, what I'm trying to do is install a systemd unit and an udev rule, I'm pretty sure I've seen some systemd magic at least, maybe also udev? Dec 12 12:48:21 rburton, I want to remove a flag... and maybe even replace the compiler Dec 12 12:48:42 nacknick_: set CC to change the compiler Dec 12 12:48:57 if you want to remove a flag then is it one that the recipe is adding, or the makefiles are using directly? Dec 12 12:49:09 pepijndevos: systemd class exists Dec 12 12:49:13 nothing magic needed for udev Dec 12 12:49:17 that's just installing a file Dec 12 12:49:57 rburton, set CC inside recipe? it overwrites the current one? Dec 12 12:50:26 nacknick_: yes, assuming you've written a recipe for the cross compiler. that's quite an assumption though, swapping compilers isn't trivial Dec 12 12:50:43 so again, please say what you're actually trying to do Dec 12 12:51:17 rburton, I'm not sure why, but I saw 'mthumb' flag inside one Makefile, removed it, but it compiled with mthumb Dec 12 12:51:46 i have no knowledge about thumb apart from 'its an arm thing' Dec 12 12:51:50 I know it by the result Dec 12 12:52:15 the bsp controls whether thumb is available or enabled by default Dec 12 12:52:23 thumb is instruction set Dec 12 12:52:55 it supports multiple length of instructions Dec 12 12:53:09 without it, all instructions are in the same size Dec 12 12:53:19 4 bytes for instance Dec 12 12:54:14 I'll try to set CFLAGS var inside recipe to see any sifference Dec 12 12:54:17 difference Dec 12 12:55:21 makefile CFLAGS do not override recipe's? Dec 12 12:55:27 depends on makefile Dec 12 12:55:41 if makefile does CFLAGS= then yes Dec 12 12:55:57 note that if you try and fiddle thumb in cflags you'll be battling with the BSP is doing Dec 12 12:56:15 see meta/conf/machine/include/arm/feature-arm-thumb.inc Dec 12 12:59:08 though if the makefile is also deciding to do thumb tweaks then you've multiple things arguing, such fun Dec 12 13:01:37 rburton, so the SYSTEMD_SERVICE in the bbclass also makes sure it's enabled or something? Dec 12 13:04:30 pepijndevos: it writes init scripts to start it on install yeah Dec 12 13:04:46 whoaaa! devtool deploy-target is my new bestest friend Dec 12 13:07:54 dafuq, my systemctl doesn't have execute permissions Dec 12 13:29:44 nacknick_, rburton disabling thumb is setting ARM_INSTRUCTION_SET to arm where necessary Dec 12 13:40:46 fsdun set in what file? Dec 12 13:42:35 If you only want to have it in one recipe either in .bb or .bbappend or any other used conf using _pn- override Dec 12 13:43:16 or as machine/distro config if you want to prohibit thumb entirely Dec 12 13:45:23 I'm trying to understand the hierarchy, what overrides what? I have makefile, recipe, bitbake config... maybe more files... :S Dec 12 13:46:13 I changed makefile flags, but it seems to ignore my change... Dec 12 13:46:15 nacknick_: recipe/bsp/distro interact in a defined way, basically bitbake.conf shows you the include order Dec 12 13:46:32 what the makefile does, be it listen, replace, extend, is up to the makefile Dec 12 13:52:41 is the recipe the only 'responsible' for building the package? in one recipe I have only two functions (do_install_append_class*), I modified them both, and it worked, but it seems that something else runs after those two functions and changed my modification Dec 12 13:53:12 it worked for a few minutes... Dec 12 13:53:30 but until the bitbake was done - it changed back Dec 12 13:57:21 define "it" Dec 12 13:57:41 plenty runs after do_install, such as do_package Dec 12 13:58:23 also not sure what do_install_append_class is meant to do Dec 12 14:09:20 rburton, it - I replaced a file inside the package folder (with 'cp' inside do_install functions), it was replaced, but replaced back to the original Dec 12 14:09:39 can you pastebin your do_install_append? Dec 12 14:09:51 rburton, who runs do_package? it does not appear inside recipe bb Dec 12 14:10:05 the recipe doesn't have do_fetch either Dec 12 14:10:10 but your tarball gets fetched Dec 12 14:10:19 the recipe only has the tasks it needs to override Dec 12 14:11:25 rburton, it's just recipe of 'file' command: https://pastebin.com/4aq6bAPA Dec 12 14:11:50 rburton you can see my modification under do_install_append Dec 12 14:17:16 nacknick_: wrong path. use $D$bindir/file Dec 12 14:17:30 you're installing to the package staging area, not the install staging area Dec 12 14:17:56 https://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#ref-tasks-install Dec 12 14:17:56 I have the following lines in my local.conf, can I add these to some image or machine file somewhere? SERIAL_CONSOLES = "" Dec 12 14:17:56 LICENSE_FLAGS_WHITELIST = "commercial" Dec 12 14:17:56 ENABLE_I2C = "1" Dec 12 14:18:24 pepijndevos: distro config is where that makes sense Dec 12 14:18:44 I'll try, but I checked in the final image and found that the file's md5 equals to the one that in package folder for some reason Dec 12 14:18:46 nacknick_: ${D}${bindir}/file, i mean Dec 12 14:19:02 nacknick_: yes, because after do_install runs do_package runs, and that uses the files in .../package/ Dec 12 14:19:43 nacknick_: i suggest you stop digging around the work directories and read the manual instead of guessing Dec 12 14:20:44 thanks Dec 12 14:21:04 rburton, absolutely agree, just don't have enough time :| Dec 12 14:21:12 I'll read it finally Dec 12 14:21:45 nacknick_: even if its just the paragraph for the one task you're working on. we said yesterday to copy files into $D. Dec 12 14:22:21 I know. the path you see in pastebin is equal to $D (rburton) Dec 12 14:22:45 ${D} = /home/amit/fsl-community-bsp/build/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/grep/3.1-r0/image Dec 12 14:23:48 oh oops... it's package... I changed it because the reason I mentioned Dec 12 14:26:49 zeddii_home: you're wanted in #oe by ant_home Dec 12 14:30:18 how can i select a different toolchain for a recipe? by default yocto sets CC to i686-poky-linux-gcc (which is in $PATH). for one recipe i need x86_64-pokysdk-linux-gcc Dec 12 14:30:38 yocto build it, i can find it in the tmp dir. but not sure how to use it correctly Dec 12 14:30:39 derRichard: sounds like you want to turn on multilib Dec 12 14:30:50 rburton: no, please let me explain. :-) Dec 12 14:31:57 rburton: i'm this poor sod: https://lists.yoctoproject.org/pipermail/yocto/2018-November/043445.html Dec 12 14:32:18 * rburton steps away slowly Dec 12 14:32:31 so, i'm using a x86_64 machine with DEFAULTTUNE ?= "i586" Dec 12 14:32:37 didn't really follow that thread, sorry Dec 12 14:32:40 no i try to build the kernel with the 64 gcc Dec 12 14:32:58 rburton: long story short, i want the whole userspace built for i586 but the kernel x86_64 Dec 12 14:33:05 plus an sdk Dec 12 14:38:16 as super ugly hack i can use the host gcc for kernel builds since i build always on x86_64 Dec 12 14:38:19 but that is ... Dec 12 14:44:11 ohhh, it's so close to working. My yocto image runs the dummy software fine, so the only thing stopping me form replacing Raspbian now on the actual robot is that I can't get I2C to work to talk to the actual hardware. Dec 12 14:46:30 I've set ENABLE_I2C = "1", but it seems to do close to nothing. Dec 12 14:48:51 pepijndevos: what do you expect ENABLE_I2C to do? Dec 12 14:49:56 Apparently set some things in config.txt Dec 12 14:50:01 ah a rpi specific thing Dec 12 14:50:02 fair enough Dec 12 14:50:15 wrong channel for that i guess Dec 12 14:50:22 check if got set, if it doesnt work bother the meta-rpi maintainers Dec 12 14:51:15 Working on it... looking at the recipe now. But either way, the config.txt that's actually on the SD card just seems a copy-paste without anything extra Dec 12 14:56:07 rburton, using ${D}${bindir}/file I get this: https://imgur.com/Sd71hTL Dec 12 15:02:01 The trouble is that at some point both #yocto and #raspberrypi don't really know what you're doing anymore, and there is no #raspberrypi-yocto channel haha Dec 12 15:02:28 "wait, this madman is not on raspbian?" Dec 12 15:07:31 In my build folder there are 3 copies of config.txt, two of them with the needed I2C lines in tmp/work/raspberrypi3-poky-linux-gnueabi/rpi-config/git-r5/deploy-rpi-config/bcm2835-bootfiles/config.txt and tmp/deploy/images/raspberrypi3/bcm2835-bootfiles/config.txt and one without the extra lines in tmp/work/raspberrypi3-poky-linux-gnueabi/rpi-config/git-r5/git/config.txt and somehow that's the one that ends up on the SD card Dec 12 15:32:48 RP: Are we satisfied that YOCTO #13069 is fixed and can be closed? I saw a few more do_checkpkg() errors in the AB, but they look like network problems (not persist_data). Dec 12 15:34:44 JPEW: Yes, I think we can resolve that, thanks! Dec 12 15:35:00 The checkpkg errors are almost certainly networking Dec 12 16:23:08 is there a command to build the final image again without changing the already built packages? Dec 12 16:26:04 I mean the deploy Dec 12 16:27:33 just run bitbake imagename again Dec 12 16:27:39 if something changed, it will rebuild the image Dec 12 16:58:50 rburton, as I said yesterday, I'm trying to replace a binary. if it recognize that something was changed, it will rerun the recipe and override my change, if it does not recognize any change - my customized binary won't be included in the file deploy image Dec 12 16:59:50 you can use vardeps and vardepsexclude flags to control what variables affect task checksums Dec 12 16:59:58 so you can exclude a variable to make it no longer re-run the task when the var changes Dec 12 16:59:59 nacknick_: are you still just cp'ing from /home? Dec 12 17:00:08 nacknick_: easy fix: put that in SRC_URI Dec 12 17:01:26 kergoth, it does not help since it still won't use my customized binary Dec 12 17:01:28 SRC_URI = ... file:///home/foo/bar; and then in do_install_append just cp from ${WORKDIR}/filename to ${D} Dec 12 17:01:41 rburton, let's try another method; how can I add a do_task to the recipe? Dec 12 17:02:03 I tried to add, but it does not run Dec 12 17:02:23 nacknick_: wish you'd say what you actually wanted to do. having a task won't solve this problem as it still doesn't know that your copying a file from outside of the build system Dec 12 17:03:16 you probably left out the before/after statements, so you have a task that doesn't get ran unless you call it directly Dec 12 17:09:29 rburton, like here? https://pastebin.com/x2gTZJAi Dec 12 17:09:48 yes Dec 12 17:09:58 then it knows to rebuild if file changes Dec 12 17:10:06 ERROR: ParseError at /home/amit/fsl-community-bsp/sources/poky/meta/recipes-devtools/file/file_5.31.bb:20: unparsed line: 'SRC_URI = "git://github.com/file/file.git file://debian-742262.patch file://0001-Add-P-prompt-into-Usage-info.patch file://home/amit/Desktop/file' Dec 12 17:10:22 missing backslash Dec 12 17:10:56 I just copied to pastebin right after I tried with 3 slahes Dec 12 17:11:22 actually you'll need a bonus slash in the url too Dec 12 17:11:25 I copied the 2 slahes version Dec 12 17:11:37 you need two more slashes Dec 12 17:11:45 a forward slash in the url and a backslash to not end the line Dec 12 17:11:52 file:////home/amit/Desktop/file Dec 12 17:11:53 ? Dec 12 17:12:13 file:// is the protocol, no host so empty, then /home/amit/Desktop/file Dec 12 17:12:23 ah yes... added... lets see Dec 12 17:12:28 the other URLs are relative, no leading slash Dec 12 17:12:33 *and a backslash* Dec 12 17:12:37 * rburton -> dinner Dec 12 17:13:48 too long error: https://pastebin.com/KhTTHUrc Dec 12 17:14:47 bon appetit Dec 12 17:15:21 rburton look above when you back Dec 12 17:43:45 nacknick_: just bitbake file, you're explicitly saying "run compile" Dec 12 17:49:16 rburton, bitbake core-image-base? Dec 12 17:49:42 I don't know why, but it says: cp: cannot stat '/home/amit/fsl-community-bsp/build/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/file/5.31-r0/file': No such file or directory Dec 12 17:50:24 but the dest folder is: /home/amit/fsl-community-bsp/build/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/file/5.31-r0/image/usr/bin/file Dec 12 17:51:58 zeddii, when are we moving to 4.19 as default in master? Dec 12 17:52:11 it'll never be the default. Dec 12 17:52:17 it will be the LTS option. Dec 12 17:52:30 I have a series done for that, but haven't had time to build the lsb distros and debug. Dec 12 17:53:07 k. thanks Dec 12 17:53:24 zeddii, hello there Dec 12 17:53:51 I have an holiday-bug for you ;) Dec 12 17:54:27 it happens that forcing qemumips to be le the kernel+modules remain be Dec 12 17:54:44 idem qemumips64 Dec 12 17:55:09 rest of userland is built fine Dec 12 17:56:33 unless there's an LE bsp description in the kernel-cache, it would be the default. sec. let me check. Dec 12 17:57:36 (+DEFAULTTUNE = "mips32r2el" / +DEFAULTTUNE = "mips64el" respectively) Dec 12 17:59:06 iirc this happened with 3.x and th epoint is we use mti-malta[32|64]-be Dec 12 17:59:44 ant_home. there's only 32bit mips le BSP defined right now. Dec 12 17:59:56 so yah, you'd end up with BE for mips64. Dec 12 18:00:06 right now I am on 64 Dec 12 18:00:10 if you send me the config via email, I can add it easily enough. Dec 12 18:00:20 meaning the machine/layers you are building. Dec 12 18:00:25 I have the kernel config already. Dec 12 18:00:37 I just added the DEFAULTTUNE above Dec 12 18:00:50 standard qemumips / qemumips64 recipes Dec 12 18:00:58 yah. that won't have any impact on the endianess of the kernel build. Dec 12 18:01:09 that's the machine name that triggers everything from there. Dec 12 18:01:09 I discovered :) Dec 12 18:01:54 i.e. for 32bit le, we have MACHINE=qemumipsel that finds the right description. we'd need the similar one for 64bit. Dec 12 18:02:10 you cannot have all variations that are in the mips BSP layer Dec 12 18:02:37 https://github.com/MIPS/meta-img Dec 12 18:02:59 I am quite confused with all those variants... Dec 12 18:04:52 that is pretty much what the kernel-cache does. takes a base config (which is 'be') and then flips the configs for le only as a second level configuration. but it is triggered by a different machine name. I can mock something up quickly, but building and booting it would take longer. Dec 12 18:06:00 I really are here on mips64 just to build-test some other recipes Dec 12 18:06:33 toolchain is ready, I can test your hints Dec 12 18:06:34 does oe-core have the userspace tunes for it already ? if so I can do a kernel build easily enough. Dec 12 18:06:35 * zeddii checks Dec 12 18:20:46 jonmason: I think we're going to need some help/work from you with the new server ;-) Dec 12 18:20:53 jonmason: https://autobuilder.yoctoproject.org/typhoon/#/builders/66/builds/1 Dec 12 18:40:31 ant_home. are you building against the 4.18 linux-yocto reference recipe ? Dec 12 18:42:33 RP: no prob, I'll take a look when I get back form lunch Dec 12 18:58:46 RP we should bug " Your host is aarch64 and this SDK was built for ix86 hosts." Dec 12 19:17:27 zeddii, yes linux-yocto-4.18.14+gitAUTOINC+bf98e195a4_6d91dc6281 Dec 12 19:45:12 kanavin_: around? I'm thinking we may need to rework test_maintainers Dec 12 19:57:21 hello! Is it possible to use my SSH identity through ssh-agent when running do_fetch steps? Dec 12 19:58:02 it's doing some git archive --remote=ssh://some-repo.git there which requires my SSH identity (protected by password). Dec 12 20:04:13 The variable SERIAL_CONSOLES is being set in the meta-intel layer machine configuration file "meta-intel/conf/machine/intel-corei7-64.conf". I need to clear it so I tried setting SERIAL_CONSOLES = "" in my "build/conf/local.conf", but it's not having any effect. Do machine configuration files override local.conf? How do I change the value of SERIAL_CONSOLES without editing the Intel layer files? Dec 12 20:20:55 Hey. I'm having an issue on some of my raspberry pi 3's with yoe images, where the networking seems to sometimes not come up. Sometimes it does, sometimes it doesn't. Has anyone experienced this? Dec 12 20:21:05 i'm wondering if switching to systemd may help Dec 12 21:12:49 * apteryx answers self: we can probably use export SSH_AGENT; SSH_AGENT = "${SSH_AGENT}" ... as detailed here: https://www.yoctoproject.org/docs/2.6/bitbake-user-manual/bitbake-user-manual.html#exporting-variables-to-the-environment Dec 12 21:13:41 s/SSH_AGENT/SSH_AGENT_PID/, and we must add also SSH_AUTH_SOCK Dec 12 21:27:18 actual fix here: http://paste.debian.net/1055583/ Dec 12 21:31:53 apteryx: hmm, the assignment shouldn't be necessary Dec 12 21:32:35 bluelightning: OK, yes, it seems to make parsing fail (assigning to itself) Dec 12 21:32:39 I'll try without assigning Dec 12 21:32:52 strange that I got it working once... maybe some state thing Dec 12 21:40:50 bluelightning: yikes... I'm back to my original problem: Permission denied (publickey). Dec 12 21:41:12 export SSH_AGENT_PID and export SSH_AUTH_SOCK don't seem to help Dec 12 21:41:48 well you can easily see if they are being properly exported by looking at run.do_fetch for the recipe Dec 12 21:43:12 actually... they should already be exported into the fetch environment Dec 12 21:53:26 bluelightning: thanks for the tip, I'm looking at that file now Dec 12 21:55:03 bluelightning: hmm, they aren't exported, and my export directives don't seem to affect that Dec 12 21:56:32 apteryx: how about log.do_fetch? they should show up in the command that gets executed Dec 12 21:59:25 I've put echo $SSH_AGENT_PID there, but I just see blanks inthe temp/log.do_fetch Dec 12 22:01:02 so looking at it I don't think that would be expected to show anything Dec 12 22:01:16 variables get passed directly on the command line for fetch commands Dec 12 22:02:30 but that should be clearly visible in the log Dec 12 22:04:36 bluelightning: do I need to enable -e or -v to see the environment variables show up in the commands? Dec 12 22:05:35 no, shouldn't Dec 12 22:08:07 maybe my bitbake is too old to show the same output, I'm on v1.34 (and the project I work on is stuck with it) Dec 12 22:09:37 no, this isn't new Dec 12 22:09:44 this is the kind of thing you should see: Dec 12 22:09:46 https://pastebin.com/uFhDs6xF Dec 12 22:14:58 enabling debug with -D, I see ton of outputs, but the only part about envars seems to be the first line, DEBUG: Removed the following variables from the environment: [...] Dec 12 22:20:55 bluelightning: here's the do_fetch procedure and the log.do_fetch I see (it's very short): http://paste.debian.net/1055591/ Dec 12 22:21:41 apteryx: right... now I see you're defining your own do_fetch, that is a bit unusua Dec 12 22:21:45 *unusual Dec 12 22:22:15 yes, the reason is because the git repos is very fat so we wanted to be able to skip downloading it all Dec 12 22:22:51 apteryx: there are other ways to handle that though, e.g. shallow clones Dec 12 22:22:59 or local mirroring Dec 12 22:24:52 how can we do a shallow clone using the git fetcher? I don't see an option to do it from: https://www.yoctoproject.org/docs/2.6/bitbake-user-manual/bitbake-user-manual.html#git-fetcher Dec 12 22:25:27 and even if it was shallow, sadly in our case it's still be fat since some heavy objects are stored... (bad practice but we have to cope with it for now) Dec 12 22:26:23 and, another question if I might, shouldn't the export statement affect my custom do_fetch definition? Dec 12 22:27:37 so, it should yes, I'm not sure why it wouldn't be Dec 12 22:35:04 it seems they don't even exist at the top level of by .bb recipe Dec 12 22:35:37 I've tested export TEST = "${SSH_AUTH_SOCK}" and TEST2 = "foobar"; I can see foobar in do_fetch but the former is empty Dec 12 22:46:23 wait... these vars are there indeed, in my do_fetch already, without having me to do anything about it. Dec 12 22:46:32 I was wiping them with my attempts to export them... Dec 12 22:46:58 * apteryx spanks his head Dec 12 22:49:33 apteryx: shallow is non-trivial in general unless SRCREV is AUTOREV. you can't shallow clone a specific commit with git. so the fetcher doesn't support shallow clones. it does support generating and using shallow mirror tarballs, which is the best it can do at this time Dec 12 22:49:48 not possible to determine the precise distance from the specified branch to SRCREV Dec 12 22:49:53 at least without already having a full clone Dec 12 22:50:27 kergoth: OK, thanks for explaining Dec 12 22:51:08 np. we could support shallow when srcrev is autorev as a special case, but it'd be rather ugly, and then we'd have to deal with when to convert the clone in DL_DIR from shallow to full, etc, since a single source can be used by multiple recipes. just a mess Dec 12 22:51:18 even shallow tarball support was pretty ugly, but worthwhile i think Dec 12 22:53:48 can I force yocto to refresh the git it is using? (it comes from the host, right?) Dec 12 22:54:40 or maybe I should say s/yocto/bitbake/ Dec 12 22:55:29 maybe by setting FETCHCMD_git Dec 12 22:56:08 apteryx: take git-native out of ASSUME_PROVIDED Dec 12 23:00:26 OK, I've tried with my system's git instead of Guix's git, and I have the same issue (http://paste.debian.net/1055601/). I'll just have to live with passwordless SSH access. Dec 12 23:00:37 s/access/keys/ Dec 12 23:09:03 * kergoth uses keys in an agent with oe builds every day, but doesn't use guix Dec 12 23:15:46 kergoth: what I've found so far is that when overriding do_fetch, the ssh-agent doesn't seem to work in that, but if I otherwise use the builtin fetcher, all works as expected. Dec 12 23:16:21 I've verified that the SSH_AUTH_SOCK and SSH_AGENT_PID from the host are set in that custom do_fetch procedure, and they are, but it doesn't seem to suffice. Dec 12 23:17:56 if `which git' says /usr/bin/git in the shell I run bitbake and I haven't touched ASSUME_PROVIDED, am I guaranteed its the one being used? or is there some caching of a previously found git possible? Dec 12 23:28:17 that's entirel. Dec 12 23:28:19 y possible, yes Dec 12 23:28:27 i'd just wipe tmp and restart the b uild Dec 12 23:34:45 zeddii, it seems just matter of switching the two lines: Dec 12 23:34:50 # CONFIG_CPU_BIG_ENDIAN is not set Dec 12 23:34:50 CONFIG_CPU_LITTLE_ENDIAN=y Dec 13 02:02:24 Hi Everyone, I've got an autotools recipe that needs the kernel source directory and the kernel build directory added to EXTRA_OECONF. What are the proper KERNEL_* bitbake variables I should use? I'm guessing KERNEL_SRC is one of them, but I'm not sure of the correct build output directory. Dec 13 02:18:14 robbawebba: STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR respectively **** ENDING LOGGING AT Thu Dec 13 03:00:01 2018