**** BEGIN LOGGING AT Thu Dec 17 02:59:57 2020 Dec 17 03:01:10 is it supposed to have a MACHINE= variable or only MACHINE_ARCH= is fine? Dec 17 03:06:04 MACHINE is needed to be set Dec 17 03:06:17 does MACHINE_ARCH translate to something ? Dec 17 03:06:40 khem: MACHINE_ARCH= Dec 17 03:11:43 I dont use kas so I perhaps would not understand more but if you just use it normally perhaps you can find whats going on Dec 17 03:39:53 JPEW: interesting Dec 17 03:40:18 khem: the micro HDMI is slightly appealing due to rpi4 cables already attached Dec 17 03:41:52 * moto-timo looking for good "modern" candidate boards for the board farm Dec 17 03:42:08 that don't cost $500 or $250 each Dec 17 03:42:10 just no Dec 17 03:42:19 go away if not around $100-$150 Dec 17 03:42:42 (but I'd rather $35) Dec 17 03:43:12 and if you are $1500 I will just laugh at you Dec 17 03:43:14 stop Dec 17 03:56:38 (you can send me one for free and I will integrate it into the board farm and blog nicely about it) Dec 17 04:04:50 moto-timo: There are a lot of rockchip boards out there Dec 17 04:06:50 moto-timo: Allwinner boards too. I have an H6 based board, but it's kernel support is lacking :/ Dec 17 04:07:27 moto-timo: IMX8 is populare also Dec 17 04:21:01 JPEW: kernel support "lacking" will put it on my shit list Dec 17 04:21:35 JPEW: I am also targetting kernelci.org so if there isn't a well defined, functional korg tree GTFO Dec 17 04:21:42 upstream first you dummies Dec 17 04:21:50 do it now Dec 17 04:21:54 now Dec 17 04:22:02 Greg KH told you so Dec 17 04:35:48 khem: I tried manually, same problem (kas just source the init build env and triggers bitbake for you). Dec 17 04:36:16 so what does it see for MACHINE ? Dec 17 04:39:14 I told you, the output of grep shew a few MACHINE_* but no MACHINE variable Dec 17 05:16:43 v0n: be nice... people will not help you when you say "I told you" Dec 17 05:36:27 JPEW: IMX8 is too generic, I need a specific board to buy... I don't have time to go searching around Dec 17 06:36:10 how can I create a symbolic link to /dev/null in a recipe? "ln -s /dev/null ${D}${sysconfdir}/systemd/system/serial-getty@ttymxc0.service" fails Dec 17 07:31:10 nvm fixed it by creating the destination directory first Dec 17 09:22:35 @moto-timo: I have a couple of imx8 "vendor" boards pls fsl eval board (which is upstream) More expensive, but works with a 5.10.1 upstream kernel (headless) Dec 17 11:14:38 RP: not quite there yet with ptest stability :( Dec 17 11:14:38 AssertionError: Failed ptests:{'glib-2.0': ['glib/codegen.py.test']} Dec 17 11:15:03 until all of those are weeded out, I guess it's good to (manually) keep an eye on regressions such as opkg Dec 17 14:24:48 moto-timo: Rockchip is probably your best bet then. ASuS tinkerboard (a little older, 32-bit RK3288), Rock Pi 4 Dec 17 14:28:45 moto-timo: Orange Pi 4 looks good also (don't have one myself) Dec 17 14:30:55 moto-timo: ROC-RK3328-CC or ROC-RK3328-PC from Firefly looks good too. It's based on a Quad core RK3328 (64-bit) Dec 17 14:43:46 moto-timo: what about pine64? Dec 17 14:56:07 kanavin_home: if you could make it a warning as I mentioned, that would help keep an eye on it Dec 17 14:56:18 kanavin_home: rburton knows the glib ones well ;-) Dec 17 14:57:40 moto-timo: i have a rockpro64 which looks fun Dec 17 15:01:35 qschulz: Ya, I was looking there. I saw the Rock64, but I don't think it's made anymore. Missed the RockPro64 Dec 17 15:05:11 moto-timo: For IMX8, you can get the Google coral board or the IMX8M Pico Pi... there aren't a lot of low cost IMX8 dev boards out there (that I've seen). Also, you'd probably be disappointed with the upstream support Dec 17 15:06:23 rburton: i can expect a MACHINE conf file for the rockpro64 then? ;-) Dec 17 15:07:23 i guess i'm going to have to get one of those 3328 boards then and look at adding support Dec 17 15:07:33 i assumed there was one already tbh Dec 17 15:07:38 its still in a box Dec 17 15:07:50 lol Dec 17 15:09:06 meta-rockchip has a few MACHINEs, but I think rockpro64 is not there Dec 17 15:11:17 I have a fork for meta-rock64... I wrote a sdimage bbclass did some tests with warrior last year Dec 17 15:11:43 moto-timo: note there are several "i.MX8"s, that could mean MM, MQ, QXP, etc. There are EVKs from NXP for all of them, I think Dec 17 15:12:28 bernardoaraujo: why a fork? why not contribute upstream? :-D Dec 17 15:12:46 still open: https://github.com/trecetp/meta-rock64/pull/4 Dec 17 15:12:54 moto-timo: scrolling back, they're all likely too expensive for your price point Dec 17 15:13:07 I think Leonardo doesn't have time to maintain it anymore Dec 17 15:15:26 JPEW: I was meaning pine a64 actually :) Dec 17 15:15:47 based on allwinner a64, upstream support afair Dec 17 15:15:51 nice, another rockchip fork (lol) Dec 17 15:16:29 haha yeah... but rock64 is also 3328... perhaps we could join forces and make some relevant contributions to meta-rockchip? Dec 17 15:16:38 bernardoaraujo: thanks for the link, i'll take a look at integrating it into meta-rockchip Dec 17 15:16:54 bernardoaraujo: yes, that would be ideal! Dec 17 15:18:29 writing this PR was a very nice learning experience... I basically looked at meta-raspberrypi and followed its sdimage bbclass as a template Dec 17 15:19:00 perhaps some silly mistakes here and there... it would be nice to get some feedback Dec 17 15:21:24 bernardoaraujo: haven't sdcard images been replaced by wic generated images? Dec 17 15:22:42 I also considered writing wic but the learning curve was a bit too much for me at the time... so I went for sdimage bbclass because I felt more confident Dec 17 15:22:50 but you could be right, idk Dec 17 15:24:03 bernardoaraujo: meta-rockchip is using wic as much as possible, converting shouldn't be too difficult (famous last words?) Dec 17 15:25:16 in that case wic is more desirable indeed Dec 17 15:25:39 and I think meta-raspberrypi migrated too so if you want, you can probably take inspiration from what they did Dec 17 15:25:41 https://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/?id=722d83761284834070e65dfcb19b2185a0ad1cd3 Dec 17 15:26:20 qschulz: Ah, ya. I only have one allwinner board (H6) and support is... spotty Dec 17 15:26:24 ooh, no shortage of board suggestions :) Dec 17 15:26:47 For example, it runs the upstream kernel, but only at the base clock frequency :/ Dec 17 15:26:49 qschulz: interesting... thanks for pointing that out Dec 17 15:26:58 thank you JPEW, RobertBerger1, qschultz, rburton, smurray Dec 17 15:27:52 tlwoerner: perhaps it's a matter of looking at the boot flow and disk layout and applying that to a sdimage-rk3328.wks? Dec 17 15:28:25 moto-timo: if you're keen on i.MX8, SolidRun make some cheaper boards, but they'd required some BSP work, likely Dec 17 15:32:07 JPEW: Hxx -based boards aren't that well supported comported to A or R series, they're usually the dirt cheap kind (no PMIC for example) Dec 17 15:34:01 if youre considering buying allwinner based boards, you can probably just head out to #linux-sunxi and ask if there's decent support or not Dec 17 15:38:41 Is there a kind of SOURCE_MIRROR_URL for git? Dec 17 15:38:53 We have a few local copies of git repo's of gitlab. Dec 17 15:39:13 But how can I point in the recipes to or own git server iso the one on Intenet. Dec 17 15:39:37 Fair enough. I have the H6 board because it has a very specific GPU for which we needed upstream mesa support Dec 17 15:39:58 bernardoaraujo: yes, that would be the goal Dec 17 15:40:01 If I understand SOURCE_MIRROR_URL correct, this is all about download source archives and not about git repo's itself. Dec 17 15:41:16 tlwoerner: cool let me know if you need any help Dec 17 15:42:14 vermaete: maybe have a look at PREMIRRORS (shot in the dark) Dec 17 15:42:35 bernardoaraujo: sure, send me a board! ;-) Dec 17 15:42:52 lol Dec 17 15:43:12 PREMIRRORS looks for me kind of the same. Dec 17 15:43:22 It's there to download the archives. Dec 17 15:43:26 tlwoerner: hahah I have a rock64, I can test the wic if you want Dec 17 15:43:31 But I could be wrong. Dec 17 15:44:01 Well, PREMIRRORS can be used to download a (local) archive of a git repo. But I would like to just get the code from our local git repo. Dec 17 15:47:59 vermaete: premirrors can be used for any change to the url you want. it doesn't have to change from git:// to http:// Dec 17 15:48:07 vermaete: you can change it to another git://. it's just search/replace Dec 17 15:49:33 @kergoth I will give it a try. But what if it's more that e.g. replace git://github.com to git://mygit. Dec 17 15:49:54 What if it's about git://github.com/a/b to git://mygit/c Dec 17 15:53:16 again, it's search and replace Dec 17 15:53:24 regular expressions. on a per-component basis Dec 17 15:53:31 you can change anything you want, url scheme, host, path, whatever Dec 17 15:53:41 that'll work just fine Dec 17 15:53:57 Thanks, I will give it a try. Dec 17 15:56:36 the key thing to note is that *first* it splits up the url into its components. scheme/host/path/etc, then the replacement is done for each of these individually Dec 17 15:56:53 so it's not a single search for this entire url and replace it with this Dec 17 15:57:43 RP, is the swabber still supported ? Dec 17 15:59:09 I think we can close bug 4517 Dec 17 16:07:09 armpit: its not about swabber! Dec 17 16:23:36 JPEW: from where did you procure your rock pi x? (out of curiosity) Dec 17 16:46:17 Hi all Dec 17 16:46:59 I'm defining my own machine in conf/machine/foo.conf, but bitbake -e core-image-minimal | grep -E "^MACHINE" doesn't show me a "MACHINE" variable. Dec 17 16:47:11 (there's a MACHINE_ARCH=foo though) Dec 17 16:47:18 is it normal? Dec 17 16:48:00 I do not have a tmp/deploy/images/foo/ directory, only a beaglebone one (which my board is based on) Dec 17 16:48:33 tlwoerner: seeed studio Dec 17 16:49:29 JPEW: oh, from them directly? okay. i noticed the usual suspects (digikey, mouser) didn't seem to carry it, was curious if you found it somewhere other than directly from seeeeeeeed Dec 17 17:02:01 tlwoerner: Do you want a "backport" of the serial port fix to gatesgarth, or do you want to fast-forward the HEAD one commit? Dec 17 17:03:05 zeddii, RP: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14154 is the checklayers problem we're hitting with meta-arm-bsp. Dec 17 17:04:52 JPEW: i'll just backport it (likely cherry-pick) Dec 17 17:05:26 (and thanks for the subtle reminder, lol) Dec 17 17:06:36 Anyone have any advice how to get around this build issue https://pastebin.com/rEBSHZ9x. It is regarding adding wireguard to an image recipe. I've added wireguard-tools and wireguard-module to my IMAGE_INSTALL_append variable in my image recipe. Dec 17 17:07:07 JPEW: i guess i'll just get the rock pi x directly then. i had been wanting to pick up a couple of these too anyway: https://www.seeedstudio.com/Type-C-Extension-Cable-with-Switch-p-4734.html Dec 17 17:07:37 What is the correct way to install wireguard into an os-image? Dec 17 17:10:53 Sorry, here's the pastebin again https://pastebin.com/rEBSHZ9x Dec 17 17:11:25 I added a '.' on the end accidentally in my original post Dec 17 17:21:06 tlwoerner: FWIW this is the power supply I've been using: https://www.amazon.com/gp/product/B077HFFLMS/ref=ppx_yo_dt_b_asin_title_o03_s00?ie=UTF8&psc=1 Dec 17 17:24:48 RP: and https://bugzilla.yoctoproject.org/show_bug.cgi?id=14155 is the license bug, chased a bit further Dec 17 17:25:13 JPEW: this is mine: https://www.canadacomputers.com/product_info.php?cPath=5_1336_96&item_id=157506 Dec 17 17:26:17 JPEW: oops!! sorry, this one: https://www.canadacomputers.com/product_info.php?cPath=5_1336_96&item_id=137879 Dec 17 17:27:02 QC3 + PD and 60W Dec 17 17:32:54 rburton: https://autobuilder.yocto.io/pub/non-release/20201216-13/testresults/qemux86-64-ptest/glib-2.0.log Dec 17 17:33:01 no tips here: https://pastebin.com/rEBSHZ9x ? As I've said I added the wireguard-tools and wireguard-module to my IMAGE_INSTALL_append in my image recipe Dec 17 17:33:10 any idea why codegen.py test seems to abort mid-way? it's intermittent Dec 17 17:33:39 e.g. this one succeeds https://autobuilder.yocto.io/pub/non-release/20201214-8/testresults/qemux86-64-ptest/glib-2.0.log Dec 17 17:34:12 JPEW: in any case, i think it's hilarious i've never seen a stable console *until* now (pre patch) Dec 17 17:36:23 kanavin_home: exit 1, so it's not crashing Dec 17 17:41:31 rburton: hmm, right, good to have them filed. Who to own though! Dec 17 17:41:58 RP: your thoughts on them would be appreciated Dec 17 17:50:49 any idea why DEPLOY_DIR_IMAGE doesn't correspond to my image name? Dec 17 17:52:35 tlwoerner: Hmm, interesting. I guess mine maxes out at 18W, which I think is the upper limit of what the Rock Pi 4 needs.... I guess maybe it could be my power supply. Strange Dec 17 17:54:18 rburton: replied as best I can Dec 17 17:57:27 need zeddii to chime in on the kernel one Dec 17 18:00:19 rburton: it needs more understanding of where things are being added to the hash :/ Dec 17 18:00:34 rburton: I remember helping with that code, it looks like something isn't working as it should though Dec 17 19:20:36 khem: moto-timo: I've found the problem! My images are now in build/tmp-glibc/deploy/images/foobar/ instead of build/tmp/deploy/images/foobar/! Dec 17 19:24:06 is it expected? builds for other machines go into build/tmp/... Dec 17 19:29:08 somewhere TMPDIR is being changed from tmp/ Dec 17 19:29:35 default in poky is to use tmp but in oe-core is to use tmp-LIBCNAME Dec 17 19:37:19 khem: ok this explains eveything, thank you! I started from poky+beaglebone(-yocto) but then I created my own distro+machine at the same time. Dec 17 19:42:12 hum I'm mitigated on that one, tmp-LIBCNAME seems like a good idea if you're trying multiple libc, but tmp/ is more conventional and easier to script the storage of built images... Dec 17 19:56:57 actually it makes a lot of sense that oe-core use tmp-LIBCNAME and a distro, which is supposed to define its libc, uses tmp/. Dec 17 20:25:59 RP: Mind running master-next of meta-mingw through the AB when you have a chance? Dec 17 21:04:40 JPEW: gatesgarth updated. sorry for the delay, i wanted to build and run test it :-) Dec 17 21:04:52 JPEW: will trigger now Dec 17 21:06:59 I am specifying a uboot recipe in my machine conf file with PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-myrecipe". I have another recipe which depends on uboot being built first by DEPENDS = "u-boot-myrecipe". Is there any way to DEPEND on the PREFERRED_PROVIDER_virtual/bootloader instead? Dec 17 21:07:32 That way when I change U-Boot recipes, I can just update the preferred provider instead of all the reverse dependencies Dec 17 21:09:22 JPEW: its running Dec 17 21:09:45 ecdhe: depend on virtual/bootloader ? Dec 17 21:10:12 tlwoerner: np. I just started my CI build... should be all green now :) Dec 17 21:10:33 RP: Thanks! Dec 17 21:15:25 Is there a way to force bitbake to build an image recipe without re-building any dependencies? Dec 17 21:16:13 Don't change any dependencies and it should already do that? Dec 17 21:16:54 Shikadi: bitbake -C rootfs ? Dec 17 21:17:30 neverpanic: lol Dec 17 21:18:36 RP: I'll give that a try, though I think I have before and it proceeded to rebuild deps... Basically I'm re-building the kernel to get a new device tree, which nothing actually depends on, but it causes an hours worth of rebuilds of things that depend on the kernel in general Dec 17 21:19:16 Thanks RP, that worked Dec 17 21:20:13 Ah, we've tried a shot at this problem by introducing something we called compatible dependens – in your case the kernel headers don't change, so there's no need to rebuild libc or anything else. Dec 17 21:20:27 We eventually gave up on this method, it was just too fragile. Dec 17 21:20:48 s/dependens/dependencies/ Dec 17 21:22:04 I imagine it's a harder problem to solve than it appears on the surface, but I wish there was a way to force it to ignore it temporarily, just grabbing whatever artifacts already exist Dec 17 21:22:53 I wrote two ways to acquire a build tool, myutil-native... The vendor hosts a zipfile with a binary of the tool, so I made a recipe that brings it in. But I didn't want my build system to depend on the vendor's servers, so I made another recipe that downloads the myutil source from github and builds it. Both recipes could be called myutil-native.bb... is there a way in yocto to distiguish them in case I Dec 17 21:22:59 want to revert to the vendor tool in the future? Dec 17 21:23:26 Right now I only have one recipe in my layer because I couldn't figure out how to properly name them. Dec 17 21:24:20 ecdhe: they can have different version numbers (e.g. one of them the release version, call the other one _git.bb) Dec 17 21:24:35 And then specify DEFAULT_PREFERENCE in one of them Dec 17 21:25:32 We do this for recipes where not everybody has access to the source, bundled with a test for access before the build that sets an env variable. Dec 17 21:26:10 neverpanic: that sounds handy actually, may ship a layer to customers who have a tar ball but not git access Dec 17 21:48:37 my new best friend, ~/.local/bin/yvar: http://ix.io/2It7 Dec 17 21:49:27 (the last line is wm-specific obviously) Dec 17 21:50:21 Shikadi: you can read your question in different ways. I realise you mean something different now. Dec 17 21:51:01 Shikadi: you could lock the sstate signature of the tasks you don't want to change which would have the effect you describe but its not easy as there isn't tooling for it Dec 17 21:55:15 RP: Hmm, that sounds worth trying, any idea where I can start? Dec 17 21:58:08 neverpanic: that worked well, thanks especially for the DEFAULT_PREFERENCE reference, I found that in the bitbake manual Dec 17 22:01:53 My board vendor hosts some git repos with tags for their releases, e.g, v2.3.4. This is the vendor release/package version, not necessarily the version of the software itself. Nonetheless, it's been handy to make recipes like myprogram_2.3.4.bb and then set the SRC_URI="gitserver/user/repo.git;tag=v${PV}" which causes the git repo to be checked out correctly Dec 17 22:02:41 However, there are multiple repos and multiple recipes... in the future, when they upgrade from 2.3.4 to 2.4.0 I will have to rename multiple files to get the ${PV} value to update. Dec 17 22:03:33 I tried naming a variable VENDOR_RELEASE = "2.3.4" in local.conf and referencing that in my SRC_URI... but the variable couldn't be expanded Dec 17 22:06:12 Are there any drawbacks to my current method of just using the vendor package version as the PV? Dec 17 22:07:41 Shikadi: look at the locked-sigs.inc that bitbake -S none generates and try cutting that down and including that file Dec 17 22:08:58 Thanks, I'll start looking into that Dec 17 23:21:47 Hello I included meta-openwrt layer (dunfell branch) to compile ipset as part of my distro . However when I "bitbake ipset" I get this error Dec 17 23:21:59 ERROR: No recipes available for: /meta-openwrt/recipes-tweaks/iptables/iptables_1.6%.bbappend Dec 17 23:22:32 My meta layer only has meta/recipes-extended/iptables/iptables_1.8.4.bb Dec 17 23:23:01 how do I solve this Dec 17 23:23:54 I see that meta-openwrt has /meta-openwrt/recipes-tweaks/iptables/iptables_1.6%.bbappend. and /meta-openwrt/recipes-tweaks/iptables/iptables_1.8%.bbappend Dec 17 23:23:56 khem Dec 17 23:58:27 khem . I see that using BB_DANGLINGAPPENDS_WARNONLY = "1" will get rid of the error .. testing it now Dec 17 23:59:36 however, I see that master branch in meta-openwrt repo only has iptables_1.8%.bbappend where as dunfell has iptables_1.6%.bbappend and iptables_1.8%.bbappend Dec 18 00:00:17 what is the standard practice in this case, is it ok to have two bbappend in repo and expect the developer to put BB_DANGLINGAPPENDS_WARNONLY = "1" in his/her repo? Dec 18 01:33:11 this system's power button is just a wee bit too close to the USB ports and ... yeah... I totally meant to reboot... Dec 18 01:33:50 I suppose there was probably a kernel update waiting anyway... Dec 18 01:33:55 * moto-timo looks at the bright side Dec 18 01:56:21 moto-timo: there are no other sides Dec 18 02:43:49 kiwi_29: best practice is to have separate branches that align with upstream without having to use danglingappends_warnonly. and naturally make sure that all the layres you're using have matching branches checked out **** ENDING LOGGING AT Fri Dec 18 02:59:56 2020