**** BEGIN LOGGING AT Tue Oct 06 02:59:56 2020 Oct 06 06:38:56 yo dudes. Oct 06 06:39:37 hi LetoThe2nd **** BEGIN LOGGING AT Tue Oct 06 06:44:39 2020 Oct 06 06:56:15 'morning, there.. Oct 06 07:50:19 LetoThe2nd: and gals? Oct 06 07:52:10 qschulz: i don't think that "dude" is gendered. **** BEGIN LOGGING AT Tue Oct 06 08:02:57 2020 Oct 06 08:43:24 LetoThe2nd: hmm. i think dude is gendered.. in fact heavily gendered.. i suppose we need help from a native English here, since we aren't ourselves ;-) Oct 06 08:44:00 shall i use dudx instead? ;-) Oct 06 08:45:12 i mean, if it is gendered, then there ought to be a non-male form. which would be... duda? duderina? dudi? Oct 06 08:45:41 ndec, LetoThe2nd: Its a confusing one, its both. It does have male leanings but could also be used to refer to a group Oct 06 08:45:56 As a native speaker, I'd tend to avoid it due to the male bias Oct 06 08:45:58 RP: so, conclusion? Oct 06 08:46:03 Its like "guys" Oct 06 08:46:16 hum. Oct 06 08:46:19 is dudx ok? Oct 06 08:46:24 or dudX? Oct 06 08:47:10 dudes and dudettes? :) Oct 06 08:48:13 Morning! I just ran into a problem with ZBar in zeus. I fail to link against zbar with "undefined reference to `dsprintbuf'". The internetz give me https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg73526.html Oct 06 08:48:33 anyone who successfully links zbar in their app? Oct 06 08:48:48 RP: well in order to be totally PC, i would probably need n forms, where 7 >= n? Oct 06 08:49:15 therefore dudX it is now, until further, greater nonsense comes to my mind! Oct 06 08:49:27 LetoThe2nd: right. its all very tricky Oct 06 08:49:41 LetoThe2nd: dud = non-functioning :'D Oct 06 08:49:58 qschulz: believe it or not, the pun was intended :) Oct 06 08:50:33 This channel clearly needs more trigger warnings... Oct 06 08:50:41 LetoThe2nd: https://media.giphy.com/media/6JB4v4xPTAQFi/giphy.gif Oct 06 08:51:17 frwi: to trigger? Oct 06 08:53:10 J/K, I feel super not-triggered! Triggered by zbar possibly :) **** BEGIN LOGGING AT Tue Oct 06 09:11:09 2020 Oct 06 09:12:04 What's the easiest way to add CFLAGS for a library? Is it to create i.e. zbar_0.10.bbappend containing only CFLAGS += " -DDEBUG_EAN"? **** BEGIN LOGGING AT Tue Oct 06 09:14:58 2020 Oct 06 09:15:13 I pinned meta-raspberrypi to this commit, which is also the current tip of dunfell branch: http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/?id=085fb07e103745ca47cab9bf93195a416b1e83dd Oct 06 09:15:55 linux-raspberrypi.bb has LINUX_VERSION ?= "5.4.59", which is the root problem source here I think Oct 06 09:20:17 Hmmm no I messed something up Oct 06 09:20:18 I though it's clear to me but it isn't. Have to look into it again I think. Oct 06 09:26:19 Ok I don't get that error message posted above. Take a look in this directory: (That's the revision I am on.) http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-kernel/linux?id=085fb07e103745ca47cab9bf93195a416b1e83dd Oct 06 09:26:19 linux-raspberrypi_5.4.bb sets LINUX_VERSION ?= "5.4.59" and includes linux-raspberrypi_5.4.inc which in turns includes linux-raspberrypi.inc which sets PV = "${LINUX_VERSION}+git${SRCPV}" Oct 06 09:27:06 So why does it say "Package Version (5.4.69+gitAUTOINC+69b14a2e6d)" in the error message above? It should be 5.4.59, as set in LINUX_VERSION. Oct 06 09:28:31 Hi everyone. A bit of a newbie here. I am trying to cross compile an out of tree kernel module, but it looks like the sysroot I have created in the SDK is missing some of the required files. Can anyone point me at the most appropriate mailing list to get help? Oct 06 09:34:21 buxtonpaul: any particular requirements for jumping through the SDK hoops at all? why not just build "in yocto"? Oct 06 09:41:00 Long story, but basically the original assumption was that merging the quite large codebase (which I am not familiar with) into a yocto build would be more work than exporting the SDK for the BSP (which I am also not familiar with) and passing the crosscompile related variables into the build. Long term I will probably look to wrap it up in a yocto Oct 06 09:41:00 recipe, but I was looking for a quick win first. Oct 06 09:42:13 The missing files are the kernel asm/xxx.h files which I think are normally generated by a kernel build, but seem to be missing from the kernel folder in the sdk I have generated. Oct 06 09:47:04 This thread describes the same issue https://www.yoctoproject.org/pipermail/yocto/2019-January/043785.html but there is no clear resolution. I am already using populate_sdk to generate the SDK. **** BEGIN LOGGING AT Tue Oct 06 09:49:03 2020 Oct 06 09:51:26 buxtonpaul: is the kernel maybe whacked with in some form, so it generates some stuff that a vanilla one would not? Oct 06 09:52:02 buxtonpaul: I compiled my own kernel modules with help from this page: https://stackoverflow.com/questions/31256770/using-populate-sdk-to-include-kernel-headers#31261404 Oct 06 09:52:35 One caveat was that I also needed to run "make modules_prepare" Oct 06 10:02:48 Thanks. I will have a look at that. Oct 06 10:05:51 well, this pseudo abort turned out to be really 'interesting' :/ Oct 06 10:12:58 So the make modules_prepare looks like it was the key bit of information! That generated the missing file and my build goes much further :-) Thanks! Oct 06 10:38:45 do_image_wic fails for me with following message: "mkfs.ext4: Could not allocate block in ext2 filesystem while populating file system". I tried increasing IMAGE_ROOTFS_SIZE to 9GB and also tried IMAGE_OVERHEAD_FACTOR = 2.5... Would be grateful for any insights... Oct 06 12:16:18 I'm wondering how we could improve the situation wrt all those PACKAGECONFIG options that do not build when set/unset or exhibit failures down the road Oct 06 12:17:40 I understand some of the options are sometimes incompatible with others, or depend on others - that does not make it easy to generate testable configs automatically Oct 06 12:20:32 wouldn't it be nice to have more CI coverage on this ? That would sure add more CI load, and even if we solve the aforementionned issues, it's not obvious how to scale that to a whole distro in a clever way Oct 06 12:24:58 maybe following the full-distro build, just getting each relevant package to build on their own in their "min" and "max" configs (with the latter not necessarily respectively "" and "all options" but maybe expanding to several alternative configs depending on more metainfo being expressed on the available options Oct 06 12:27:12 that could be something like (not even sure it's valid syntax): PACKAGECONFIG[featA][depends] = "featB featC" , PACKAGECONFIG[featA][conflicts] = "featB featC" Oct 06 12:27:40 yann: there's already a conflict one Oct 06 12:27:50 yann: I guess there could be a depends one? Oct 06 12:28:04 yann: the last entry (coma-separated) in PACKAGECONFIG is for conflicts Oct 06 12:28:43 and some way to specify more-than-2-values alternatives, like PACKAGECONFIG[featA][values] = "A B C" Oct 06 12:29:43 qschulz: oh yes I probably noticed that one - I can't help but think this potentially-huge comma-separated list is not optimal **** BEGIN LOGGING AT Tue Oct 06 12:31:39 2020 Oct 06 12:32:34 yann: what do you expect from PACKAGECONFIG[featA][values] = "A B C" ? Oct 06 12:34:06 a way to declare that features A B and C are mutually exclusive (other than having to declare all individual conflicts) Oct 06 12:34:53 that's the case of a program having build-time selection of a backend Oct 06 12:36:04 my attempt does not allow to express whether one of those choices has to be done (for cases where exactly one backend is required) Oct 06 12:36:31 (so that PACKAGECONFIG = '' is invalid) Oct 06 12:37:30 * RP cancels the autobuilder test build and tries again, hopefully with a real wic fix this time Oct 06 12:57:44 jonmason: Just thinking about these arm tune patches. Where we're adding new tunes, could we put them into subdirs straight away? I could then drop that final patch and we could sort out moves in 3.3? Oct 06 13:03:09 * RP notes the wic fix was a bust, lets try that again :/ Oct 06 13:06:45 RP: I was thinking that moving everything atomically would make it easier to backport Oct 06 13:07:31 FYI, I have cortex-m patches queued and am working on coretex-r Oct 06 13:08:07 funny how all this snowballs to doing a simple add of support for A75 ;-) Oct 06 13:09:06 jonmason: I'm thinking that a consistent location where we can is probably the lesser of several evils Oct 06 13:09:48 fair enough, I can resubmit with the new location for all the new ones Oct 06 13:09:53 jonmason: I'm very familiar with snowballs. My involvement with OE in the first place was one Oct 06 13:10:02 LMAO! Oct 06 13:10:08 jonmason: I can tweak the patches if its easier Oct 06 13:10:30 jonmason: The original problem was the jog wheel on my Zaurus C760 didn't scroll ebooks Oct 06 13:10:31 I got it, the less work you need to do the better for everyone Oct 06 13:11:12 jonmason: ok, thanks Oct 06 13:11:16 so you are saying if we pushed more buggy code, we would get more developers of your quality? Oct 06 13:11:33 jonmason: not quite the message I was thinking of! :) Oct 06 13:12:19 the sad thing is I never did end up reading ebooks with a functional jog wheel Oct 06 13:12:32 that is too funny Oct 06 13:19:00 RP: Oooo I like huge parsing speed improvements! Oct 06 13:19:46 JPEW: we're doing something very stupid Oct 06 13:21:58 I know from the profiling this explains a few things Oct 06 13:22:07 (on key bottlenecks on the profiles) Oct 06 13:23:06 jonmason: like this? https://xkcd.com/974/ Oct 06 13:27:07 * yann suddenly remembers something about wanting to play Go on his iPAQ :) Oct 06 13:40:13 tlwoerner: Reminds me of Monk saying "You'll thank me later" Oct 06 14:32:39 Hmm... When yocto can build images for all kinds of machines, and for qemu... can it also build docker images? Oct 06 14:33:43 manuel1985: https://youtu.be/jPbcQEffzJo Oct 06 14:34:22 :-) Oct 06 14:35:18 mind = blown Oct 06 14:35:18 Thank you :D Oct 06 14:35:34 Seem to have missed that one Oct 06 14:35:51 manuel1985: i wasn't lying when i offered advice on docker/containers :) Oct 06 14:36:31 RP: I always ask, but I'll confirm now .. do you want me to continue sending my -stable merges to the reference kernels ? I'm not worried if you don't want to merge them, but I don't want them to cause any stress if they are just adding to backlog. Oct 06 14:40:14 zeddii: i wonder, is there also a frontlog? Oct 06 14:41:05 f -1 (x) Oct 06 14:42:23 :D Oct 06 14:43:50 * LetoThe2nd can't decide if integrating or differentiating zeddii makes more sense. or less. Oct 06 14:44:45 * zeddii graphs a parabola Oct 06 14:45:20 * LetoThe2nd hyperbo{wl,le}w Oct 06 14:45:44 s/}w/}s/g Oct 06 14:46:08 heh. the math folks are going to throw something at us soon. Oct 06 14:46:11 LetoThe2nd: Hehe :) Oct 06 14:46:11 I'm trying to persuade my collegues to go all-in on Yocto. Right now it's a mess of Docker Images which inherit from each other. One we recreate rarely because it's based on Ubuntu UNSTABLE, one containing our in-house dependencies which we recreate more often, and then one which we recreate for every release. And then there are a few more ones. Oct 06 14:47:13 have some fun with that. and/or beer! Oct 06 14:47:23 * zeddii nods Oct 06 14:48:30 "i can drink alcohol without having fun!" Oct 06 14:48:37 Beer is definitely what I need around here **** BEGIN LOGGING AT Tue Oct 06 14:50:40 2020 Oct 06 14:52:48 LetoThe2nd: Still need to sign up, but I already got my company to sponsor me the ticket :D Oct 06 14:53:37 make sure you also register for YPDD Oct 06 14:55:52 zeddii: they're fine, not really a source of stress for me :) Oct 06 14:57:54 Tech Call Link: https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09 Oct 06 14:58:54 YPTM: Joshua Watt here Oct 06 15:02:27 YPTM: Randy MacLeod is there Oct 06 15:03:11 thanks for the link. I need to update my cal with the new one Oct 06 15:03:26 jonmason: s/cal/brain/ Oct 06 15:03:34 YTPM: Saul is here Oct 06 15:04:01 YPTM: Scott Murray is on Oct 06 15:07:00 YPTM: Tim is on Oct 06 15:07:56 YPTM ross joined nice and late Oct 06 15:08:00 LetoThe2nd: YPDD? Yocto project development day? Yocto police department dingaling? Oct 06 15:08:08 former Oct 06 15:08:11 latter! Oct 06 15:08:12 though the latter sounds good Oct 06 15:11:10 The first one was a guess. Glad I turned out to be right. Oct 06 15:11:42 technically, developer not development Oct 06 15:11:51 YPTM: Denys is here Oct 06 15:13:42 denix: you're the call-in? Oct 06 15:13:59 tlwoerner: yeah Oct 06 15:15:29 somehow my mic/mute got messed up. did anybody hear me? Oct 06 15:15:39 LetoThe2nd: no **** BEGIN LOGGING AT Tue Oct 06 15:17:37 2020 Oct 06 15:34:47 If there are no other topics, I will ask about qemu monitor console and qemurunner/select/poll Oct 06 15:34:56 YPTM: my home internet seemingly just died, will check the minutes later Oct 06 15:43:28 YPTM: Jan-Simon is on **** BEGIN LOGGING AT Tue Oct 06 15:59:16 2020 Oct 06 16:06:59 RP: I didn't catch the beginning for YPTM call, but is pseudo in master-next in shape to test it against regular builds? I have old reproducer for host-user-contaminated issue using `qmake qinstall`, it looks like it still can break pseudo (or at least I'm seeing do_package failing in tar with "abort()ing by server requestAborted") Oct 06 16:17:35 JaMa: -next as of an hour or two ago fixes the known issues Oct 06 16:24:57 LetoThe2nd: have you ever used something besides yocto to build docker containers? Could you specifically recommend yocto over e.g. Packer in that space? Oct 06 16:25:04 So I have an interesting warning from bitbake. I have my own layer where I am copying the dropbear recipe (exactly) from poky/meta/recipes-core/dropbear. Then I have a dropbear_%.bbappend that adds some patches. Oct 06 16:25:40 The problem is that sometimes bitbake is showing warnings that the SRC_URI entry for my patches (listed in the bbappend file) could not be found. Oct 06 16:26:23 I believe what is going on is bitbake is picking the wrong recipe (the one from poky/meta/recipes-core/dropbear) and not the one from my layer. Oct 06 16:26:25 Any tips? Oct 06 16:27:45 rabbit9911: If you have the .bbappend, why do you need to copy the .bb? Oct 06 16:28:13 When we update the poky recipe I dont want to automatically get any package upgrades Oct 06 16:28:27 rabbit9911: you can BBMASK the original recipe Oct 06 16:36:21 Dont the recipes get used in the order they are listed in the bblayers list? Layers with higher priority get pref? Oct 06 16:37:30 Seems like this should be well defined and I should not have to mask out recipes from a layer with lower priority? Oct 06 16:38:52 rabbit9911: that bbappend will apply to *both* recieps, and both will be parsed, just only yours will be *built* Oct 06 16:39:13 rabbit9911: either mask out the original as jama says, or better yet, have your bbappend adjust filesextrapath/filespath properly so the patches are found regardless of which base recipe is in use Oct 06 16:41:25 OMG this makes perfect sense Oct 06 16:41:27 Thanks! Oct 06 16:45:36 in my case I had to BBMASK, because the .bbappend included some files in SRC_URI which were already provided in the directory where the overlay recipe lives (so were found there), but when the .bbappend was applied on top of the original recipe in oe-core it was correctly complaining Oct 06 16:47:21 and adjusting FILESEXTRAPATH in bbappend in layer1 to include the THISDIR of the overlay recipe in different layer is difficult (without hardcoding the path) Oct 06 16:58:06 i do it pretty often, usually with bb.utils.which() against BBPATH **** BEGIN LOGGING AT Tue Oct 06 17:03:52 2020 **** BEGIN LOGGING AT Tue Oct 06 17:41:42 2020 Oct 06 17:41:44 Okay I need your help guys. My build fails with "linux-raspberrypi-1_5.4.69+gitAUTOINC+69b14a2e6d-r0 do_kernel_version_sanity_check: Package Version (5.4.69+gitAUTOINC+69b14a2e6d) does not match of kernel being built (5.4.59)." Oct 06 17:41:44 Why does it think the kernel to build is version 5.4.59? Oct 06 17:41:44 Even if I check the repo at exactly this commit hash, it clearly is 5.4.69: https://github.com/raspberrypi/linux/blob/69b14a2e6d4e840c7609370dbf0bac847c3bb15c/Makefile#L4 **** BEGIN LOGGING AT Tue Oct 06 17:45:35 2020 Oct 06 17:52:00 Why is parsing recipes sometimes superfast, and sometimes it seem to take ages? Oct 06 17:53:24 manuel1985: The most common reason is whether there is a cache, and whether or not some of it has been invalidated and needs to be reparsed **** BEGIN LOGGING AT Tue Oct 06 17:55:35 2020 Oct 06 17:55:35 manuel1985: That's what you get for asking so many questions ;) Oct 06 17:58:16 I'm desperate :( Oct 06 18:06:12 manuel1985: What version are you building, and do you have the latest commit for it? Oct 06 18:06:34 (e.g. latest on the dunfell branch) Oct 06 18:13:00 grr, fix one bug in devtool and it breaks other tests Oct 06 18:13:55 argh last minute fix introduced a typo **** BEGIN LOGGING AT Tue Oct 06 18:19:48 2020 Oct 06 18:21:30 I already checked what `do_kernel_sanity_check()` is doing. It seems to check the Makefile: SUBLEVEL=$(grep "^SUBLEVEL =" ${S}/Makefile | sed s/.*=\ *//) Oct 06 18:22:22 manuel1985: And you're just building the kernel recipe from meta-raspberrypi (e.g. `bitbake linux-raspberrypi`) ? Oct 06 18:22:43 But I cannot check the makefile myself, because for some reasons yocto seems to delete it, altough I have "RM_WORK_EXCLUDE += " linux-raspberrypi" in the local.conf Oct 06 18:22:53 JPEW: Jepp Oct 06 18:23:10 Wait a sec Oct 06 18:23:45 No, there is an overlay from another layer Oct 06 18:24:00 Just looking for it Oct 06 18:27:55 This is the append I'm using, but on a slightly older revision: https://github.com/jumpnow/meta-rpi64/blob/dunfell/recipes-kernel/linux/linux-raspberrypi_5.4.bbappend Oct 06 18:27:55 I have troubles finding that file on that older revision due to the github user interface Oct 06 18:30:38 aaaaaargh I'm pinned to commit 7deb4fb5f0408f7fa19811cc48831ed8e93a7951 of that repo. How can I display the file tree at this version? Oct 06 18:31:19 https://github.com/jumpnow/meta-rpi64/tree/7deb4fb5f0408f7fa19811cc48831ed8e93a7951 Oct 06 18:31:47 Oh that is equal to the tip of "dunfell" branch Oct 06 18:31:59 as well, how nice Oct 06 18:31:59 Ya. Oct 06 18:32:10 Does it work without meta-rpi64? Oct 06 18:33:30 Didn't try that. This is also about me understanding how this problem occured in the first place. The thing is: I added RM_WORK_EXCLUDE += " linux-raspberrypi" in the local.conf, so I would have expected the source tree at "/data/new/poky/build-jumpnow-rpi64/tmp/work/raspberrypi4_64-poky-linux/linux-raspberrypi/1_5.4.69+gitAUTOINC+69b14a2e6d-r0/linux-raspberrypi4_64-standard-build", but this dir is empty Oct 06 18:33:44 If I would find the source tree there, I could check the Makefile **** BEGIN LOGGING AT Tue Oct 06 18:36:27 2020 Oct 06 18:37:25 manuel1985: Where did you add RM_WORK_EXCLUDE ? Oct 06 18:38:25 `/data/new/poky/build-jumpnow-rpi64/conf/local.conf` Oct 06 18:38:25 `RM_WORK_EXCLUDE += " linux-raspberrypi"` Oct 06 18:39:06 manuel1985: Is it possible that linux-raspberrypi was an sstate hit? Oct 06 18:39:07 Oh, kernel source code isn't located there Oct 06 18:39:24 It's in a shared work directory I think.... Oct 06 18:40:14 Try looking in: ${TMPDIR}/work-shared/${MACHINE} Oct 06 18:40:17 rewitt: I ran `bitbake -c leanall linux-raspberrypi` before, afair that clears the sstate as well Oct 06 18:40:25 JPEW: Gonna do that, thanks Oct 06 18:43:20 You could also brute force it and do a "devtool modify linux-raspberrypi" that will give you a clone in workspace/sources/linux-raspberrypi which is a little more human readable :) Oct 06 18:43:40 JPEW: That was a hit, perfect. Indeed, the Makefile there is 5.4.59. My recipe wants 5.4.69. Oct 06 18:43:51 what the.. Oct 06 18:43:52 | cd /mel/kergoth/mel/fir/polarfire/build.fromcb/tmp-glibc/work/riscv64-oe-linux/glibc/2.31+gitAUTOINC+1094741224-r0/build-riscv64-oe-linux/csu; /mel/kergoth/mel/fir/polarfire/build.fromcb/t Oct 06 18:43:52 mp-glibc/work/riscv64-oe-linux/glibc/2.31+gitAUTOINC+1094741224-r0/git/scripts/mkinstalldirs /; ln -s . / 2> /dev/null; test -L / Oct 06 18:43:52 | make[2]: *** [Makefile:192: /mel/kergoth/mel/fir/polarfire/build.fromcb/tmp-glibc/work/riscv64-oe-linux/glibc/2.31+gitAUTOINC+1094741224-r0/build-riscv64-oe-linux/csu///gcrt1.o] Error 1 Oct 06 18:44:03 ln -s . / 2>/dev/null; test -L / Oct 06 18:44:04 .. Oct 06 18:44:13 i really don't think / is a symlink, glibc Oct 06 18:45:11 kergoth: I also like how they don't think you will want to know the output Oct 06 18:45:49 heh, yeah, suppressing stderr doesn't seem like a bright idea. who needs to see error messages anyway.. Oct 06 18:46:05 i just love when make says it exited with 1 with no other info :) Oct 06 18:46:09 * kergoth rolls eyes Oct 06 18:46:21 kergoth: It will never fail of course :) Oct 06 18:46:38 this is a weird one, this only fails if i'm tryinig to rebuild glibc using an external toolchain, but not building it in the first place when building that toolchain Oct 06 18:46:57 but that error doesn't seem like it should have anything to do with that context Oct 06 18:46:58 weird Oct 06 18:48:16 I've forgotten all I knew about the hoops necessary to compile glibc properly Oct 06 18:48:52 something about canadians I think Oct 06 18:49:40 JPEW: This is the base recipe, which defines LINUX_VERSION to 5.4.59: http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-kernel/linux/linux-raspberrypi_5.4.bb?id=085fb07e103745ca47cab9bf93195a416b1e83dd Oct 06 18:49:40 This is the append, which defines LINUX_VERSION to 5.4.69: https://github.com/jumpnow/meta-rpi64/blob/7deb4fb5f0408f7fa19811cc48831ed8e93a7951/recipes-kernel/linux/linux-raspberrypi_5.4.bbappend Oct 06 18:49:40 PV gets set to "${LINUX_VERSION}+git${SRCPV}" here: http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-kernel/linux/linux-raspberrypi.inc?id=085fb07e103745ca47cab9bf93195a416b1e83dd Oct 06 18:49:46 Sorry to bother you this much Oct 06 18:50:02 It is okay if you say no :) Oct 06 18:50:23 The links are exactly to the revisions I checked out, and are equal to "dunfell" as well I think Oct 06 18:52:37 For some reason the append seems to work as far as bitbake does recognize it and sets PV accordingly, but it gets ignored for the kernel repo commit Oct 06 18:54:06 it's going to check out whatever SRCREV is set to. use bitbake -e linux-raspberrypi to see what variables are really set to and compare to what you think they're set to Oct 06 18:57:49 Already did so. SRCREV points to the commit which contains 5.4.69. Still, 5.4.59 gets checked out. But there is also SRCREV_machine and SRCREV_meta which slightly confuse me. Oct 06 18:58:26 But I feel guilty with spamming this channel so much. I should write a proper writeup and post it to some mailing list I think. Oct 06 19:00:22 I already learned a lot, thank you kergoth, rewitt and especially JPEW! Oct 06 19:00:39 well, what is your SRCREV_machine ? That's the one that is getting used. Oct 06 19:03:15 zeddii: You nailed it. The commit specified in SRCREV_machine holds 5.4.59. **** BEGIN LOGGING AT Tue Oct 06 19:05:57 2020 Oct 06 19:09:35 Aaaargh, this seems to be commit which caused the append to not apply anymore. The append overwrote only SRCREV, but this commit in the base recipe replaced SRCREV by two new variables SRCREV_machine and SRCREV_meta. Murphy really bit me here. I pinned the repo versions to exactly the commit which broke everything. Additionally, this is the first commit in that repo since weeks. Would I have pinned my stuff a few hours earlier, all wou Oct 06 19:09:35 have been fine. Oct 06 19:09:37 http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/recipes-kernel/linux?h=dunfell&id=085fb07e103745ca47cab9bf93195a416b1e83dd Oct 06 19:13:40 Yeah looking at the kernel-yocto.bbclass seems SRCREV will work if SRCREV_machine is not set, but otherwise SRCREV_machine will be used Oct 06 19:15:50 it's also standard bitbake, those git repo's are named Oct 06 19:15:56 https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linux/linux-raspberrypi_5.4.inc Oct 06 19:16:04 git://github.com/raspberrypi/linux.git;name=machine;branch=${LINUX_RPI_BRANCH} \ Oct 06 19:16:22 hence the SRCREV_machine Oct 06 19:16:27 as a standard override Oct 06 19:17:13 * zeddii wanders off **** BEGIN LOGGING AT Tue Oct 06 19:28:05 2020 Oct 06 19:31:10 zeddii: For a repo with name=xyz, you can define the SRCREV with SRCREV_xyz? Didn't know that. Also https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#git-fetcher doesn't tell about that "name" parameter. Where can I report missing things in the docu? Oct 06 19:34:49 manuel1985: I think at meta-rpi we should have given some notice for this since it seems to be a breaking change Oct 06 19:42:34 Are you contributor to meta-raspberrypi? Cool, thanks for your work :) Oct 06 19:43:00 manuel1985: it is more related to the SRCREV_FORMAT variable, which is set in the base recipes, and that is what is triggering the behaviour. It is documented in the mega-manual, but there's always room for clarification Oct 06 19:43:05 * zeddii really wanders off **** BEGIN LOGGING AT Tue Oct 06 19:54:21 2020 **** BEGIN LOGGING AT Tue Oct 06 19:59:16 2020 **** BEGIN LOGGING AT Tue Oct 06 21:03:57 2020