**** BEGIN LOGGING AT Wed May 12 02:59:56 2021 May 12 05:55:44 zeddii: kernel tooling is failing on master kernel due to https://github.com/torvalds/linux/commit/6dd85ff178cd76851e2184b13e545f5a88d1be30 May 12 05:58:43 here is output from do_kernel_configcheck http://sprunge.us/qS2OhP May 12 06:53:56 Hi everyone, I'm trying to add a user with 'EXTRA_USERS_PARAMS = " useradd nodered -d /data/node-red"' but I get this error: https://gist.github.com/alex88/118740c75fc9f8f8aa540202f696dc6a however it doesn't show the command output, how can I get the output? May 12 07:10:16 oh nvm, found it May 12 07:53:37 good morning May 12 09:10:24 kanavin: https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/3401/steps/11/logs/stdio is a little bizarre :/ May 12 09:11:58 If I use wic to generate the fstab, how do i make sure that the same fstab is used also by meta-rauc? Since after I flash the secondary partition from rauc it doesn't automatically mount /boot and so rauc can't communicate with uboot May 12 09:12:13 https://github.com/leon-anavi/meta-rauc-community/blob/master/meta-rauc-raspberrypi/recipes-core/base-files/files/fstab this example uses a custom fstab but I would like to use the wic generated one for both May 12 09:13:13 just to say: I am happy to hear people are using meta-rauc-community :) May 12 09:14:03 well it was awesome to learn how to get started with meta-rauc :) I'm just re-implementing it to understand what each piece does May 12 09:16:29 oh, just saw your username :) May 12 09:49:46 however even just looking at rauc-community, the /home mount point created in the wic file isn't in the default /etc/fstab so after an update it won't be mounted? or will it be mounted by automount? May 12 10:04:51 RP: I've seen these OOM errors earlier and elsewhere, e.g. gcc ran out of memory May 12 10:05:05 RP: seems to have started occurring this week May 12 10:06:29 kanavin: but why only mesa's packages for all the package backends when other things were building ok? May 12 10:06:45 kanavin: something odd happened there :/ May 12 10:19:28 alex88, I don't remember on the top of my head. There should be some additional info in the git commit messages. Have you already seen the blog post? https://www.konsulko.com/getting-started-with-rauc-on-raspberry-pi-2/ May 12 10:23:12 RP: I don't have a quick answer :( May 12 10:43:26 kanavin: I reran the build to see if it happens again. Might be worth saving that build directory? May 12 10:43:40 kanavin: I wondered if anything was debuggable in place May 12 10:45:53 kanavin: hmm, qemumips64 also failed with memory issues on that same worker May 12 10:52:59 RP: told you so :) May 12 10:55:02 kanavin: something still doesn't feel right May 12 11:36:13 RP: are the runqueue issues you're working on in bitbake/master-next only reproducible with multiconfig or are you seeing them without multiconfig as well (I still see some missing Manifests in do_prepare_recipe_sysroot and I'm not using multiconfig) May 12 11:38:17 JaMa: only multiconfig May 12 11:44:14 Good Morning, atm I'm looking for a way to enable systemd-coredump in Thud. There is a /etc/systemd/coredump.conf file but the rest is missing. So I tried to extend by using a systemd_%.bbappend with PACKAGECONFIG_append = " coredump " and also in an bb file by PACKAGECONFIG_append_pn-systemd = " coredump ". But there's no systemd-coredump added to /usr/bin. Does anybody have an idea how to enable this f May 12 11:44:14 eature. Thank you, Florian May 12 12:08:18 RP: in my case it looks like python3-typing-extensions-native-3.10.0.0-r0 built everything correctly (based on logs in temp directory left behind by rm_work), but somehow didn't stage anything in sysroots-components/x86_64/python3-typing-extensions-native/ nor created sstate-control/manifest-x86_64-python3-typing-extensions-native.populate_sysroot or the next build removed it, is there a log from removing the May 12 12:08:24 stale sstate objects or removal of recipes from sysroot (to find out which objects/recipes were removed?) The next build started with "Removing 2 recipes from the x86_64 sysroot...done." (and 3+3 from arch/machine sysroot + 193+67 stale sstate objects from arch/machine) May 12 12:11:42 JaMa: I'd suspect rm_work :/ May 12 12:11:51 JaMa: I can't tell from that info though :/ May 12 12:12:11 https://paste.ubuntu.com/p/xwzj7x8cX4/ shows the sequence, the build at 16:20 rebuilt python3-typing-extensions-native to upgraded version and all builds after that are failing to find it (because bitbake still thinks it's already built and staged) May 12 12:14:25 but it would need to be some strange race-condition with rm_work or something, because I'm using rm_work all the time and these disappearing Manifests are very rare (and happen with various recipes - but usually with native I think) May 12 12:18:28 I'll enable more debug output for sstate_eventhandler_reachablestamps and sstate_eventhandler_stalesstate to be shown by default and lets see next time this happens May 12 12:25:16 JaMa: these problems are hard and I'm struggling to context switch well enough to be helpful, sorry :( May 12 12:25:59 RP: no problem, you helped enough by confirming that it's not completely known issue yet and worth debugging from my end May 12 12:26:41 JaMa: definitely not known, we don't see it on the autobuilder either which is another hint to me that it could be rm_work removing something it shouldn't or racing May 12 12:27:22 do you run incremental builds in the same TMPDIR for multiple MACHINEs? May 12 12:29:40 Good morning, I had a general question about creating a bbappend for a kernel. I created a linux-yocto_%.bbappend in my own layer and I have a fragments.cfg that is used in my recipe. Everything in that recipe seems to work, but for the life of me I cant figure out how to override LOCALVERSION for the kernel. May 12 12:30:10 I have it specified in the fragment.cfg, but the kernel is always built with -yocto-standard. May 12 12:33:29 A note on that, all of the CONFIG options in the fragments.cfg seem to work May 12 12:39:37 JaMa: no, not sure we do May 12 13:01:46 @FloRiAn_: I think your syntax is not OK. can you try e.g in local.conf PACKAGECONFIG_pn-systemd_append = " coredump" May 12 13:06:23 FloRiAn_: you can check it's really in systemd package by running `oe-pkgdata-util find-path '*coredump*'`, maybe you're just missing the appropriate package in your image May 12 13:25:09 khem: I'm still brining up linux-yocto-dev for 5.13-rc1, but I'll address that shortly. May 12 13:30:49 steven_: It's controlled by a bitbake variable in kernel-yocto for historical reasons May 12 13:31:46 zeddii: is there a clean way to override that? May 12 13:32:08 it's just a variable, LINUX_VERSION_EXTENSION May 12 13:32:15 so just like you'd set any variable. May 12 14:28:16 zeddii: thanks, works like a charm May 12 14:31:09 There was one other item that has been a bit of a pain. systemd is adding a service by default in the image. The service is called serial-getty@ttyS0.service. I've attempted disabling via PACKAGECONFIG, adding a bbappend to remove the .service file, and finally I added a core-image-base.bbappend to attempt to remove the service file in a custom cleanup function called by ROOTFS_POSTPROCESS_COMMAND. So far nothing has been able to May 12 14:31:12 remove the service. May 12 14:51:29 I still can't figure out why master hangs on configure with Ubuntu 18.04.... is that distro no longer supported? May 12 14:51:39 m4 configure that is May 12 14:52:40 JPEW: odd. I'm running on an older ubuntu for my builder, with an up to date master and didn't notice that. but I'll see if it happens here when I kick my next build. May 12 14:52:55 Maybe it requires a buildtools tarball? May 12 14:58:14 Nope, even fails with buildtools. Weird May 12 15:04:06 I'm using 18.04 in most of builders I have available and haven't seen it hanging with current master May 12 15:20:09 JaMa: BTW, tried to use pyrex on Fedora 34 and podman, didn't work. I know this does not help, I'll give you logs and probably open an issue on github just as a todo when I have time May 12 15:22:48 JPEW: I guess this was for you ^ :) May 12 15:25:30 JaMa: ah, same first letter in the nick, mixing everybody :p May 12 15:25:47 JaMa: but thanks for "forwarding" to the right person :) May 12 15:26:29 qschulz: Ya, podman has some issues May 12 15:30:36 JPEW: I'll send a patch for zsh too, a == in shell should be simply = May 12 15:31:06 if I haven't before next week, shout at me please :) May 12 15:32:38 qschulz: OK May 12 15:33:12 qschulz: We do test zsh, so I'm curious where it slipped though May 12 15:34:27 Ah hah! I think m4-native do_configure coredumps as part of a configure test and it looks like my PC is in an unhealtly state were it never finishes processing coredumps May 12 15:34:38 JPEW: IIRC (not on the problematic computer right now): https://github.com/garmin/pyrex/blob/master/pyrex-init-build-env#L60 May 12 15:35:31 so if the first condition isn't met then the second isn't evaluated, so I guess that is missing in some tests? May 12 15:35:41 Ya, probably May 12 15:36:12 We do test ZSH: https://github.com/garmin/pyrex/blob/master/.github/workflows/main.yml#L48 May 12 15:36:28 I should probably make the CI run check-bashisms or something May 12 15:37:23 JPEW: shellcheck I guess? May 12 15:37:33 Ya, I forget the actual name May 12 15:38:11 JPEW: if PYREXCONFFILE isn't set in your test, the error won't happen May 12 15:39:37 qschulz: Ya, I think the tests all set that May 12 15:40:44 JPEW: then it's a mystery, let's see if I can fix that May 12 16:15:48 leon-anavi, yeah I saw that, however my setup is a little different, my wic file has a /data folder not the /home one, rauc works, the only problem is that the fstaab file generated in the rauc bundle doesn't seem to include /boot and /data but the image generate by bitbake does May 12 16:16:54 ok, yes in this case you will need to adjust it to your specific use case. May 12 16:21:47 however looks there's no way to have wic generate the fstab for the update bundle as well? is that because we're not generating a standard image but an update bundle? May 12 16:23:20 khem: I have a fix for the tools under test now. Have to test the specrum of versions, but it did pass my 5.13-rc test. I'll have something by end of day if it all goes well. May 12 16:23:52 and it just went boom in my test May 12 16:23:54 * zeddii looks May 12 16:38:05 Would I be correct in thinking that this build failure is caused by the following error?: https://paste.ee/p/ExFvN May 12 16:46:34 tlwoerner or JPEW: I don't see any rk3128 based machines in meta-rockchip, any idea how good the upstream kernel support for it is? May 12 16:49:57 smurray: No idea. The rk3399 and rk3288 have good upstream support May 12 16:51:48 JPEW: I see stuff for rk3128 in the mainline kernel, but have yet to find an example of someone using it ;) May 12 16:53:42 smurray: Ya. I've never used it before May 12 16:54:03 smurray: yes, that's what i see too. there appears to be rk3128 support scattered about in the kernel (pinctrl, clk, etc) but no device trees based on it May 12 16:55:28 smurray: You might also have some trouble with the GPU; I don't know if panfrost supports the Mail 400 May 12 16:56:32 JPEW: panfrost doesn't support the Mali400, but the open-source lima driver does May 12 16:56:57 tlwoerner: Ah, OK. I've never used lima. Been pretty happy with panfrost May 12 16:57:20 heh, it's definitely an old chip at this point May 12 16:57:32 smurray: u-boot has support for 1 rk3128 board: the evb-rk3128 May 12 16:58:24 i don't even know if that's a board that's been released, i wouldn't be surprised if it wasn't May 12 16:58:43 tlwoerner: yeah, Tom mentioned that. It looks like the stuff that didn't make it upstream for the kernel is in rockchip-linux's kernel repo, but it's pretty stale May 12 16:59:12 evil vendor kernels, lol May 12 16:59:15 I'm guessing there were Android settop boxes shipped with it, it was the follow-on to the rk3126 May 12 16:59:55 I can only assume someone considers it now because it's cheap and somehow available ;) May 12 17:00:57 someone's dumping the SoCs on alibaba (probably) May 12 17:01:43 maybe raspberrypi will pick them up… haha lol May 12 17:02:51 heh. I'm guessing the current shortages of everything might make it look appealing May 12 17:02:59 it's only software, right? ;) May 12 17:03:51 at the highest level, how does one build his own kernel and associated metadata instead of using a yocto linux kernel and the associated yocto linux metadata such as yocto-kernel-cache? May 12 17:04:20 pick a kernel tree, and supply a defconfig May 12 17:04:41 it seems the kernel development doc is mainly about yocto linux: https://docs.yoctoproject.org/kernel-dev/index.html May 12 17:07:24 zeddii: a "defconfig" is already provided in the kernel srctree for some architectures, http://paste.ubuntu.com/p/gQVpd7RvMT/ May 12 17:07:25 and inherit kernel at the very least May 12 17:07:52 wait, that link is wrong May 12 17:08:06 yates: https://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-kernel/linux/linux-raspberrypi_5.10.bb May 12 17:08:09 sure. so you copy it out to your layer, write your own handling for it, or use what I did for the linux-yocto references. May 12 17:08:13 http://paste.ubuntu.com/p/3J3WXw5sSS/ May 12 17:09:19 yates: do a find with *defconfig ;) you'll see MANY other defconfigs May 12 17:09:24 there's a huge spectrum of kernel recipes, configuration schemes, etc, etc, we took up the cause to try and reduce them over a decade ago, and documented it. But there's no way we'l ever consolidate or document everything. There's just too large a set of requirements and kernel providers. May 12 17:09:33 ah. so even not using a yocto linux kernel, the defconfig would have to be copied over from the srctree. May 12 17:09:44 or you write yourself a function to do it. May 12 17:09:51 yates: ... no? May 12 17:10:12 linux-yocto does not do it for example May 12 17:11:01 the core kernel bbclass is very tightly defined on what it does for the configuration step. that allows everyone to do what they need on top. It has to be simple, being all things to all kernel providers is just impossible and ends up complex. May 12 17:11:43 which is why we never touched it when introducing the reference BSPs, and tree. you'd break so many things. So anything specific to a kernel provider is opt-in. May 12 17:14:30 smurray: SMOP May 12 17:15:36 tlwoerner: heh, indeed May 12 17:16:00 zeddii: by "kernel provider," do you mean yocto recipes and other metadata to handle a kernel?> May 12 17:16:16 smurray: i learned that one a long time ago, early in career, by working at companies run by EEs ;-) May 12 17:16:21 no. I mean whatever kernel tree is providing the source code. May 12 17:17:23 a provider is the OE term for the various trees you can use for the same thing. i.e. something provides "virtual/kernel" May 12 17:18:30 tlwoerner: always fun to not get looped in until after the hardware design is done May 12 17:19:11 zeddii: by various trees are you referring to (e.g.) different versions (4.2.x, 5.8.x, 5.10.x. etc)? May 12 17:19:26 ..from the same linus kernel repo? May 12 17:19:42 possibly, or from semi vendors, other projects, etc. May 12 17:19:54 aha. i see. May 12 17:20:51 rather, i begin to see. May 12 17:24:42 so does basically the linux-yocto and support metadata (e.g., the stuff in yocto-kernel-cache) provided via the following line in the yocto-linux kernel recipes (e.g., meta/recipes/linux/linux-yocto_5.8.bb): require recipes-kernel/linux/linux-yocto.inc May 12 17:25:52 s/provided/begin to be provided/ May 12 17:28:23 yes, and there's an inherit of kernel-yocto and kernel in that .inc, that get the core/common kernel definitions/task and add some to work with the way the tree is structured. May 12 17:28:40 zeddii: thank you thank you thank you thank you thank you thank you thank you thank you May 12 17:28:43 !!!!!!!!!! May 12 17:28:48 May 12 17:30:11 even though i've been reading the docs and searching poky for clues, the kernel build stuff has seemed elusive. i am grateful for your patience and help in clarifying for me. May 12 17:30:23 zeddii: ^^^^ May 12 17:30:29 it's no different than say an autotools based source tree. Your recipe sets the repo in the SRC_URI, you inherit autools to get the base operations that know how to deal with autotools, and then you add your own tasks/functions to deal with the quirks of the particular project. In the simplest case, you don't add much, but in more complex ones, you do. And sometimes the tasks/functions are put in bbclas May 12 17:30:29 ses so we can reuse them. May 12 17:32:27 ok May 12 17:34:51 and the unfortunate thing for many new yocto users is that the first thing they are handed is some vendor's terrible kernel tree and recipes and asked to make them work. Which means they associate some of the complexity and issues that they see with the kernel or reference kernels, when really, they are just fundamental OE/yocto things that any recipe has to deal with. May 12 17:35:18 once they get through that, then the find the horrors of whatever evil vendor tree they've been handed. May 12 17:35:35 ha. not really funny, though May 12 17:37:27 well i would think, after we get our kernel worked out for csky and a couple of bsps, we can submit it to you for eventual incorporation into yocto-linux May 12 17:38:17 unfortunately it's a shitty little processor unlikely to become too popular... May 12 17:38:59 yates: linux-yocto is based on upstream Linux kernel, you would probably need to upstream it first in order for it to make it to linux-yocto recipe later on May 12 17:39:34 it is already there, at least partially. May 12 17:39:46 there is an arch/csky folder May 12 17:40:31 i guess we would add some custom drivers, bsps, and policies? May 12 17:40:36 support for the architecture does not mean support for you board May 12 17:41:13 qschulz: that line seems to be blurry May 12 17:41:15 drivers, device tree if this architecture supports it (probably not?) or a board definition file (never done this, always worked with aarch64 and mips64 and they have dt support) May 12 17:41:35 yes, a device tree May 12 17:44:23 e.g., kernel policies (if i understand things correctly) are not part of the linxu srctree and can be board-agnostic May 12 17:44:34 what's a kernel policy? May 12 17:45:49 qschulz: e.g. as discussed here: https://docs.yoctoproject.org/kernel-dev/intro.html May 12 17:47:23 yates: yeah a kernel policy is just a chunk of a kernel .config/defconfig May 12 18:06:10 Hi there. Having some strange issue, looking for suggestions for troubleshooting. Branch "Dunfell". May 12 18:07:02 I have a layer with a line `LAYERDEPENDS_package = "core"` everything works fine and I can rung `bitbake-layers` May 12 18:08:02 As I change it to `LAYERDEPENDS_package = "core openembedded-layer"` it breaks the `bitbake-layers` command May 12 18:10:15 https://pastebin.com/MbUsujX8 May 12 18:10:57 It dies even without accepting the `-d` flag which I tried to add to make sense of things May 12 18:54:52 hey guys! Any ideas on "go-systemd-4+gitAUTOINC+b4a58d9518-r0 do_fetch: Fetcher failure: Unable to find revision b4a58d95188dd092ae20072bac14cece0e67c388 in branch master even from upstream"? Checked the repo out, the revision is there. Failed twice on a row... May 12 18:57:27 do_fetch: Fetcher failure for URL: 'git://github.com/coreos/go-systemd.git'. Unable to fetch URL from any source. May 12 19:02:28 luneff. check that they didn't rename the branch to 'main' we are suffering that all over right now. May 12 19:03:05 zeddii, indeed! it's "main"... May 12 19:03:50 you'll have to bbappend it in your own layer until we fix the recipes. May 12 19:04:31 I'm fixing the ones in meta-virt, but the changing of branches is a pain in the a.... May 12 19:05:33 yeah, got it. thank you! Wouldn't have noticed that by myself May 12 19:06:20 they really could have just left master to wither away and made 'main' the default. But that would have been too easy on the consumers ;) May 12 19:07:12 SRC_URI = "git://${PKG_NAME}.git;branch=main" works May 12 19:08:00 is it happening everywhere now? :-) May 12 19:08:03 yup! we have a patch on the list for it as well. I was just trying to see if I could do something 'fancier' and am probably jsut going to make the branch explicit and be done with it. May 12 19:08:28 luneff. it's becoming more common as the various projects adopt inclusive language policies. May 12 19:08:54 Sep 20, 2020 — All new Git repositories on GitHub will be named "main" instead of "master" starting October 1, 2020. May 12 19:10:17 yah. I could live with that. but projects going and nuking their existing branches. gah. May 12 21:17:32 The Yocto Project Summit will be starting in less than 2 weeks! May 12 21:17:39 get all your information here: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/ May 12 21:24:16 will presentation sessions recordings be available if someone is following the training sessions? May 12 22:32:31 * RP is not touching edk2 again, it is horrible :( May 13 00:44:56 Hi May 13 00:45:24 I see this error while building the yocto rootfs May 13 00:45:26 Running transaction test May 13 00:45:27 Error: Transaction test error: May 13 00:45:27   file /usr/share/polkit-1/rules.d conflicts between attempted installs of gnome-control-center-3.36.4-r0.1.cortexa72_cortexa53 and polkit-0.116-r0.1.cortexa72_cortexa53 May 13 00:45:28   file /usr/share/polkit-1/rules.d conflicts between attempted installs of gvfs-1.44.1-r0.1.cortexa72_cortexa53 and gnome-control-center-3.36.4-r0.1.cortexa72_cortexa53 May 13 00:45:37 This fails during do_rootfs May 13 00:51:36 Mads: check those recipes to see what permissions they're setting for that directory, I've seen conflicts like that if two recipes install -d with different -m mode values May 13 00:53:09 Mads: or if one of the recipes is setting different user/group for it May 13 01:00:57 I dont see any installs and modes for either recipes May 13 01:11:20 and he's gone **** ENDING LOGGING AT Thu May 13 02:59:56 2021