**** BEGIN LOGGING AT Tue May 18 02:59:56 2021 May 18 09:29:03 JPEW: you got the good GH username :) May 18 10:20:35 khem, no problem, I'm basically the project's janitor ;) May 18 10:38:17 Hi, I have a weird issue. I have created a recipe, inside the 'do_compile' I have 'CC_FLAGS="${CC_FLAGS}" oe_runmake'. It works perfectly on my Debian testing, but with a Ubuntu base 20.04, the CC_FLAGS is never used when I check the log.do_compile May 18 10:39:28 It works with 'oe_runmake CC_FLAGS="${CC_FLAGS}"' but I call multiple Makefile and I don't always want to override this variable May 18 11:57:59 Hello guys, i don't know if I'm in the right place ... I am new to yocto and am now stuck on a problem. My goal is to create a small BSP for a PocketBeagle. For this I built the core-image-minimal for the beaglebone and tried to run it. However, I get no response at all on the serial console. With a BeagleBone Black on the other hand it works as it should. I was told that a BSP that works on the Black would also work on the Pocket. Is this wrong May 18 11:58:01 and do I need to consider something else? Thanks in advance May 18 12:18:38 pretty sure you're not using the same UART controller as on the beagleboard May 18 12:20:10 I mean, that would be the simplest explanation May 18 13:24:39 Hello Everyone, May 18 13:24:39 I've created a yocto image for intel machine using meta-intel dunfell branch. May 18 13:24:39 The image is booting up without any issues. But I'm facing an issue with the serial console. May 18 13:24:39 I want to connect a gps module to the RS232 serial console. May 18 13:24:40 We rarely had some data from the gps module at the boot then it disappears when it's connected to a RS-232 serial console. May 18 13:24:40 I did following things to debug the issue : May 18 13:24:41 -  I've activated the CONFIG_SERIAL_8250_FINTEK using menuconfig to install the device driver. That I'm not sure if it activates the RS232 serial communication. May 18 13:24:41 - I've verified in the bios that serial console is enabled. May 18 13:24:42 I don't understand what's the cause of this issue. I'd appreciate if someone can help me on this. May 18 13:24:42 Thanks in advance May 18 13:31:58 anishmonachan, 8250_FINTEK is an option for RS485 support provided by certain specific chips. It shouldn't be necessary to use a standard RS232 serial port with a typical legacy GPS using serial instead of USB. May 18 13:39:36 Ok I understand but the /dev/ttyS0 seems to exists and when I connect the RS232 GPS device on the COM port I get a first batch of data and then the NMEA data is corrupted and finally it's stops reading data. May 18 13:41:36 paulg I enabled the 8250_FINTEK beacause it was enabled in the same hardware on a standard linux and in the bios the controller is called F81216. May 18 13:42:10 But it feels like that there is someone else writting or connected to the ttyS0 May 18 13:42:51 anishmonachan: you'd better test a serial connection between your board and a PC to verify the serial channel is good May 18 13:43:54 probably also want to ensure that systemd isn't starting a getty service on that port on the host system May 18 13:44:34 systemctl -l |grep ttyS0 May 18 13:46:35 paulg root@intel-nuc-64:~# systemctl -l |grep ttyS0 May 18 13:46:35   sys-devices-pnp0-00:03-tty-ttyS0.device loaded active plugged /sys/devices/pnp0/00:03/tty/ttyS0 May 18 13:46:36   serial-getty@ttyS0.service loaded active running Serial Getty on ttyS0 May 18 13:47:19 So this means that it's used for getty and that I have to disable it to have free ? May 18 13:47:36 yes May 18 13:47:58 Is it linked with the SERIAL_CONSOLES variable ? May 18 13:48:14 kind of May 18 13:48:49 serial *console* lets you access your linux machine from another machine acting as a serial terminal. May 18 13:49:24 you don't really want/need serial *console* for reading data from your GPS, you only need serial *port* support to use the raw device. May 18 13:49:59 systemctl stop serial-getty@ttyS0.service May 18 13:50:06 is there a way to exclude dependencies of -dbg packages? I want just my few ones, not all the tree till libc May 18 13:50:40 that will tell systemd to keep off of your serial *port* ttyS0 while you are trying to use it for your GPS. (until you reboot the linux host) May 18 13:51:27 [note that none of this is specific to Yocto - you'd get the same on Ubuntu/SuSE/Fedora) May 18 13:51:55 luneff: don't install recommendations May 18 13:52:31 Ok. Because I found this in one of the confs SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1 115200;ttyS2" May 18 13:52:31 APPEND += "rootwait console=ttyS0,115200 console=tty0" May 18 13:52:54 so It feels like it's linked to it May 18 13:53:28 neverpanic, thinking about setting DEBUG_BUILD="1" instead of IMAGE_INSTALL_append = " my-app-dbg " May 18 13:54:00 could be wrong May 18 13:54:02 console=ttyS0... tells the kernel that it should send out boot up messages to its serial port so a connected terminal can see them. May 18 13:54:58 so unless you are running linux on your GPS and trying to debug linux based firmware on that GPS, you'd not be using console= boot arguments. May 18 13:55:00 neverpanic, how to do so with IMAGE_INSTALL? :-) May 18 13:56:49 seems like I can bbappend the whole dependencies tree and say INHIBIT_PACKAGE_DEBUG_SPLIT = "1", but that looks silly May 18 13:57:43 though I can say INHIBIT_PACKAGE_DEBUG_SPLIT = "1" in local.conf and say = "0" in my app packages. right? May 18 13:58:47 well, nevermind... May 18 14:01:27 your image is assembled using the package manager you've chosen. The -dbg packages recommend each other, they don't have hard dependencies. If you tell your package manager not to install recommendations, it will only pull the -dbg packages you specified explicitly. May 18 14:01:58 Disabling the debug split will just mean that all your binaries in your image will have debug symbols built-in, how's that different from installing them all in the first place? May 18 14:02:11 NO_RECOMMENDATIONS for example in your image recipe should do May 18 14:02:40 or in a bbappend, RRECOMMENDS_${PN}-dbg = "" (if it is really a recommendation package as neverpanic said, I haven't checked myself) May 18 14:06:40 thank you guys! May 18 14:08:52 I've locked up ttys using the logind.conf to prevent access using keyboard shortcuts May 18 14:08:53 NAutoVTs=0 May 18 14:08:53 ReserveVT=N May 18 14:08:54 Is that somehow linked to the issue with serial console? May 18 14:12:13 no. VT stands for "virtual terminal". If you aren't running X11 on your linux host, you press +Fn to access emulated consoles via the VGA text mode on the host linux system. May 18 14:14:07 You are overcomplicating this. You need two things. 1) disable getty as per above 2) use sofware that will do and open() of your /dev/ttyS0 and "speak" whatever protocol you GPS uses to negotiate a data exchange. May 18 14:15:06 I don't know what GPS you have and if it uses an open protocol standard - that is a google question and not a Yocto question. May 18 14:18:22 We're using trimble gps May 18 14:19:03 just to be clear, serial port is not the same as serial console. If you are using a serial port as a serial console, it is not "free" to use as a link to your GPS. May 18 14:47:39 rburton: you developed sato?!? is that the same as matchbox-sato? May 18 14:54:17 i'm builing an image that includes my own kernel recipe with SRC_URI += "file://defconfig" and with FILESEXTRAPATHS_prepend set May 18 14:55:31 but i'm getting a run.do_configure error: http://paste.ubuntu.com/p/NFwDVZNbqV/ May 18 14:57:42 and using find i've found the defconfig is in ./work/qemucsky-poky-linux/linux-csky/5.12-r0/defconfig May 18 14:58:27 but that's not in the directory make is cd'ing to: -C /edg/build-csky-toolchain-kernel_5.12-ii/tmp/work-shared/qemucsky/kernel-source May 18 14:59:06 (i think it looks for defconfig first, then olddefconfig). so what's up with this? May 18 15:03:34 yates: one of the team. matchbox-sato is part of sato. May 18 15:04:05 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND May 18 15:04:05 1987087 richard 20 0 88.0g 83.0g 3692 R 105.9 33.0 9:05.85 qemu-arm May 18 15:04:06 cool May 18 15:04:18 rburton, jonmason: not happy with arm today ;-) May 18 15:05:03 ffs qemu May 18 15:05:55 its all rburton's fault May 18 15:06:37 hello guys, I've one question.. May 18 15:07:05 I have a yocto project that builds two images, one for board A and one for board B May 18 15:07:28 rburton, jonmason: seriously, this is why the autobuilders keep OOMing, we have a stupid glibc test May 18 15:07:44 OOM? May 18 15:07:48 hence I've written two multiconfig file: conf/multiconfig/boardA.conf and conf/multiconfig/boardB.conf May 18 15:07:53 out-of-memory May 18 15:08:30 what happen if I run bitbake multiconfig:boardA:myimage and subsequently bitbake multiconfig:boardB:myimage May 18 15:09:16 on a recipe that has do_install_boardA() and do_install_boardB() May 18 15:10:07 it will run two times with the expected configuration (boardA and boardB) or since bitbake see that it has already run for boardA won't run it anymore also considering that the machine has changed ? May 18 15:11:14 thekappe: it depends whether that recipe is multimachine safe. Do you set PACKAGE_ARCH = "${MACHINE_ARCH}" ? May 18 15:11:27 i think not May 18 15:11:35 uff May 18 15:12:12 olddefconfig? May 18 15:12:12 for example I've some customization for systemd to install some *.network files May 18 15:12:31 thekappe: it is machine specific so you need to mark it as such May 18 15:12:49 on boardA but not on boardB and viceversa May 18 15:14:09 so I'll need to add them to all the recipe that has cutomizations ? May 18 15:14:33 thekappe: you do need to show the recipes are machine specific, yes May 18 15:14:53 otherwise can I simply instruct to use two differnt "work" dirctories ? May 18 15:16:41 thekappe: that is how you do that May 18 15:17:26 yeah but I need to trach each recipe every time May 18 15:17:51 I mean using something like TMPDIR="${TOPDIR}/boardA-tmp" May 18 15:18:02 and TMPDIR="${TOPDIR}/boardB-tmp" May 18 15:18:30 thekappe: you can do that too but the recipes are broken May 18 15:19:00 yeah some of them will be compiled two times May 18 15:20:10 thekappe: you are breaking assumptions about how well written recipes behave. That will have interesting sideeffects in the rest of the system May 18 15:20:21 no one can throw me a line on my olddefconfig issue? May 18 15:20:30 The modern codebase does try and fix things up as best it can but its not really a great idea May 18 15:26:09 here's my entire kernel recipe: http://paste.ubuntu.com/p/DSCvnDKWQn/ May 18 15:31:13 have i fucked up? May 18 15:43:16 https://www.youtube.com/watch?v=tR2vWlOG8ms&t=570s May 18 17:10:02 Hello Guys, I am pretty new to the Zephyr environment, but extremely experienced in embedded Linux and Yocto, I am looking for guidance to add a new SoC to the meta-zephyr layer and I was wondering if there is anyone around who may be able to discuss this with me? May 18 17:26:32 In particular I am wanting to add support for the stm32h747 series of SoC's May 18 17:50:27 bitbake runs either bash scripts or python scripts in the build/tmp/work/.../temp folder May 18 17:50:54 i can run bash scripts by just executing ./run.do_xyz in a bash shell May 18 17:51:19 how can i run python scripts? the key seems to be the "d" variable taht is passed at the top level May 18 18:01:00 yes ttps stays but the url changes May 18 18:15:30 Non Terrestrial Or Terrestrial Beings which can help me with Trans Universal Transportation (Please PM Me)1100110 May 18 18:17:01 ptf May 18 18:23:40 ghosthell: see SpaceX May 18 18:40:57 thanks ill try there May 18 18:54:56 i saw a bunch of my overnight builds fail last night in opkg-utils, has that been discussed? May 18 18:56:04 when pod2man is called, the build fails due to a missing perl dependency: May 18 18:56:05 pod2man -r "" -c "opkg-utils Documentation" opkg-build opkg-build.1 May 18 18:58:31 in any case, it looks to be related to my sstate. the common sstate that i'm using seems to be wonky, if i use a fresh sstate it builds fine May 18 18:59:23 how do i delete one object from my sstate (instead of blowing it all away)? May 18 18:59:43 RP: huh. enabling pam bumps mentor's image size by 730K only, alters the build of 4-5 packages, and actually sees fewer total ptest failures in ptest-runner than leaving it disabled. May 18 19:00:01 think mel might be enabling that going forward for all but the most constrained setups May 18 19:00:11 → /usr/bin/env: ‘nativeperl-native/perl’: No such file or directory May 18 19:00:37 easiest to just -c cleansstate yourrecipe rather than removing it manually May 18 19:01:22 or bitbake -C fetch somerecipe to build somerecipe from scratch regardless of sstate. or bitbake --no-setscene will run an entire build not using sstate, without having to start with an empty sstate dir. handy from time to time :) May 18 19:02:53 kergoth: nice! thanks May 18 19:03:59 worth noting that if SSTATE_MIRRORS is in use, removing a local sstate object or -c cleansstate won't result in building anything from scratch, as it can re-fetch them from the configured sstate mirror. in that case -C fetch is invaluable, since it'll still build it from scratch rather than fetching the objects May 18 19:04:11 or no-setscene of course May 18 19:04:14 * kergoth wanders off May 18 19:16:38 running "$ bitbake -c cleansstate opkg-utils" took over 11 minutes :-o May 18 19:16:58 ... wow, that's weird May 18 19:19:09 I have seen long cleanstate lately but not @ 11 min May 18 19:22:12 that's just sstatecleanning 1 package May 18 19:22:38 even more strange, restarting the build after the cleansstate still fails on the same package for the same reason May 18 19:23:13 i think there's something fishy about this common sstate i'm using. i also get the feeling that if i just blow it away and move on with my builds RP wouldn't be happy May 18 19:23:39 so i'll leave this sstate as it is and use a different one for my builds in case some forensics are needed :-) May 18 19:29:45 WARNING: linux-csky-5.12-r0 do_populate_lic: Could not copy license file /edg/build-csky-toolchain-kernel_5.12-iv/tmp/work-shared/qemucsky/kernel-source/linux-csky/GPL-2.0 to /edg/build-csky-toolchain-kernel_5.12-iv/tmp/work/qemucsky-poky-linux/linux-csky/5.12-r0/license-destdir/linux-csky/GPL-2.0: [Errno 2] No such file or directory: '/edg/build-csky-toolchain-kernel_5.12-iv/tmp May 18 19:30:43 ok, so how is GPL-2.0 supposed to get from meta/files/common-licenses/ to build-csky-toolchain-kernel_5.12-iv/tmp/work-shared/qemucsky/kernel-source/linux-csky/? May 18 19:44:19 kergoth: nice to have some data, thanks for sharing May 18 19:44:47 np. i have a buildhistory diff too, but of course it'd be more useful with a more stock setup. haven't tested with nodistro/core-image-base yet May 18 19:45:22 tlwoerner: you much have a large sstate direction. cleansstate does wildcard matching on it which is why it is slow May 18 19:46:08 RP: 355GB May 18 19:46:15 kergoth: I'm surprised more than 4-5 recipes didn't rebuild May 18 19:46:21 tlwoerner: I've seen worse May 18 19:46:52 tlwoerner: that should have said "you must have a large sstate directory". Not sure what my fingers are doing :/ May 18 19:47:50 kergoth: was that with hashequiv? maybe that helped? May 18 19:47:57 lol, that's why there's a gap between me taking the notes for the weekly meetings and posting them, the notes need "fixing" May 18 19:49:04 tlwoerner: for nativeperl to fail like that I'd guess the perl-native sstate would be damaged or perl-native was removed from the sysroot in question. May 18 19:50:03 tlwoerner: did you try cleaning opkg-utils and rebuilding it? I remember seeing something like this recently, I just can't remember why :/ May 18 19:50:28 tlwoerner: of course the clean may destroy evidence too :/ May 18 19:51:11 RP: yes, i did a "bitbake -c cleansstate opkg-utils", took 11 minutes, then "bitbake core-image-minimal" and it failed again in the same way May 18 19:52:54 "bitbake --no-setscene core-image-minimal" also fails May 18 19:53:11 but using a different SSTATE_DIR succeeds May 18 19:56:42 tlwoerner: was the exact error "/usr/bin/env: ‘nativeperl-native/perl’: No such file or directory" as you stated above? May 18 19:57:06 yes, copy&paste May 18 19:57:30 tlwoerner: oh, I do remember this. May 18 19:57:31 that comes from the first line of the pod2man script May 18 19:57:45 which spawns this problem May 18 19:58:11 tlwoerner: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=9f951a2d4985d2d05ceb135e0786e1e1ecd73fc0 was the fix May 18 19:58:33 tlwoerner: it should say xxx/perl-native/perl and is corrupted. May 18 19:58:49 Something about the restore from sstate was broken by that patch which got reverted as a result May 18 19:59:39 tlwoerner: I'm surprised that is persisting in an sstate cache :/ May 18 20:00:00 okay, so this is fixed in poky? (for the record, i'm doing nodistro builds with oe-core directly) May 18 20:00:44 i'm surprised i only hit it last night, i do builds every night May 18 20:01:28 tlwoerner: I reverted the problematic patch and forgot about it, yes May 18 20:01:51 did you build an older revision recently? May 18 20:02:55 RP: possibly. i added a new build recently and probably did a couple builds by hand before adding it to the queue May 18 20:03:41 oh!!!! May 18 20:03:59 i use the same SSTATE_DIR for a gatesgarth build and a dunfell build that i also do nightly May 18 20:04:21 (just to make sure the older branches aren't breaking while i'm not looking) May 18 20:07:13 tlwoerner: presumably one of these builds had that patch and not the revert? :/ May 18 20:12:45 khem: looking at the meta-oe errors last night, both runs have the same issues. sdbus-c++ is a URL not working, and python3-haversine is split() not working (which is probably a change in the underlying data being processed). Do you want me to open bugs for these or is this description sufficient? May 18 20:14:04 Is there anyone out there who could discuss adding new SoC's to zephyr layers? May 18 20:14:48 hcg: is there a question? May 18 20:15:22 I'm not the maintainer of the layer but I'm semi-active in it May 18 20:18:49 Yes, how is he best way to add new processors to the Yocto Layers of meta-zephyr - I am wanting to add support for the stm32h747 SoC, which has 2 cores, one being an M4, which appears to be supported by teh meta-zephyr layer, but the other is an m7 which is not supported. May 18 20:19:23 m7 needs support in oe-core...and is on my todo list...for a long time. May 18 20:20:48 I may have time and my project may have budget, and I would be willing to wrok on this, but I am just looking for pointers as to implement it May 18 20:21:34 I have patches somewhere May 18 20:21:52 my whole point in doing zephyr was to test the arm cortex-m tunes May 18 20:22:38 yes, i have something in meta-arm-bsp for m7 May 18 20:23:38 jonmason: I have sent a fix for python2-haversine May 18 20:24:49 the sdbus-c++ issue is known, its due to ca-certs anamoly on some of the builders. the recipe fetches code during configure ( bad bad) but then git fails due to cert mismatch issues from buildtools tarball May 18 20:25:25 cool, then a nop for me :) thanks May 18 20:26:50 jonmason: I am really new to zephyr, but come from many years of embedded Linux and Yocto, so I really like the Yocto environment, and after looking at the way our engineers are implementing Zephyr I am really scared, but think using Yocto for it may be very beneficial for our total platform strategy which needs to support multiple different May 18 20:26:51 products May 18 20:28:30 hcg: I understand. I did Zephyr and FreeRTOS for a short stint at my previous company. FreeRTOS is so bad May 18 20:32:03 jonmason: Our guys are forking Zephyr for every new project, and that scares the shit out of me... I think using Yocto as a wrapper may be able to prevent this mentality, but I am not too familiar with the Zephyr environment, I really only know Yocto extremely well May 18 20:34:03 my recommendation would be to do your own layer for your SoCs, and put meta-zephyr as a dependency May 18 20:34:19 in meta-arm, we have a qemu-cortex-a53 machine May 18 20:34:25 so it would be similar for you May 18 20:36:56 jonmason: That sounds good, but I would probably need a bit of hand-holding to get the M7 support going, would you be able to do this for me? I probably just need a push in the right direction... May 18 20:43:24 I'm not saying it's correct, but the m7 I have now is http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm-bsp/conf/machine/include/tune-cortexm7.inc May 18 20:43:42 you could add meta-arm as a dep until I get it upstream May 18 20:44:46 That sounds great, thanks May 18 20:45:02 I will look at it in the morning May 18 21:49:44 is there a way to have different incompatible licenses in different images? May 18 22:02:11 zeddii, your xilinx email is so Canadian May 18 22:20:45 jonmason, rburton: I can easily put a 1GB cap on the RSS usage of glibc tests under qemu. If I do that, failures go from 80 to 232 so about 150 more May 18 22:21:08 is that a reasonable compromise until someone can investigate this properly? May 18 22:22:20 (this is on about 3900 tests in total) May 18 22:31:08 meta/recipes-kernel/linux/linux-yocto.inc has the line LICENSE = "GPLv2" May 18 22:31:28 and the line LIC_FILES_CHKSUM ?= "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" May 18 22:32:01 yet none of the files in meta/files/common-licenses have this md5 sum May 18 22:32:28 neither are any of the files "COPYING" in the entire poky distro. May 18 22:32:37 where is this file coming from? May 18 22:32:55 s/neither are /neither do/ May 18 22:36:26 * yates looks around May 18 22:36:44 me knocks on the #yocto door May 18 22:36:50 * yates knocks on the #yocto door May 18 22:38:31 yates: LIC_FILES_CHKSUM refers to files in the source tree May 18 22:38:44 yates: only in specific cases does it point to the common licenses paths, such as for packagegroups which have no sources May 18 22:46:09 kergoth: ok thanks. so in the case of linux-yocto.inc, LIC_FILES_CHKSUM is referring to a file called COPYING in the source tree, which in that case is from one of the branches in https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/ May 18 22:46:10 ? May 18 22:46:26 it's the sources listed in SRC_URI, which is presumably that, yes May 18 22:46:55 ok thanks May 18 22:48:20 where in the source tree does it look for the file? does it look _everywhere_ there, sorta like the equivalent of "find"? May 18 22:49:27 well wait - it's in the top directory. so i guess it looks there. May 18 22:50:25 no, it's a specific path relative to ${S}. i.e. file://foo/COPYING would look in ${S}/foo May 18 22:50:36 that's correct, yes May 18 22:50:37 top May 18 22:56:21 ok May 18 23:05:41 now that i know which licensing file i'm supposed to be checksumming, and what its checksum is, i now am trying to determine this problem: May 18 23:06:09 WARNING: linux-csky-5.12-r0 do_populate_lic: Could not copy license file /edg/build-csky-toolchain-kernel_5.12-v/tmp/work-shared/qemucsky/kernel-source/COPYING to /edg/build-csky-toolchain-kernel_5.12-v/tmp/work/qemucsky-poky-linux/linux-csky/5.12-r0/license-destdir/linux-csky/COPYING: [Errno 2] No such file or directory: '/edg/build-csky-toolchain-kernel_5.12-v/tmp/work-shared/qemucsky/kernel-source/COPYING' May 18 23:06:39 it is as it says: there is NOTHING in /edg/build-csky-toolchain-kernel_5.12-v/tmp/work-shared/qemucsky/kernel-source/ May 18 23:07:03 is there something going wrong in the git checkout? May 18 23:07:46 SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=git;nocheckout=1" May 18 23:26:59 That’s the upstream kernel abs Linux-yocto is practically the same so why are you writing a new recipe? Just bbappend a defconfig in May 18 23:27:54 Rp: it’s a shame it causes more failures, curious what say 5G does, but yeah that seems like an interesting experiment to see what happens overal May 18 23:30:25 rburton: I think my debug test engine may be breaking some of the tests :/ May 18 23:30:55 rburton: I can test with a more minimal setup and double check. Increasing to 16GB limit didn't help improve many of the test failures May 18 23:31:05 rburton: the tests peak around 8GB May 18 23:31:58 rburton: lots at just over 1GB, 17 over 2GB May 18 23:46:18 * RP waits for more results (20 min test runs :/) May 19 00:56:40 rburton: several damn good reasons. May 19 00:57:02 i'm done with linux-yocto - doesn't suit my purposes. May 19 00:57:59 SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git;protocol=git;nocheckout=1" May 19 00:58:23 is there something going wrong in the git checkout? May 19 01:06:14 here is the entire recipe: http://paste.ubuntu.com/p/yXqH2dRtcp/ **** ENDING LOGGING AT Wed May 19 02:59:57 2021