**** BEGIN LOGGING AT Fri Jan 31 03:00:42 2020 Jan 31 04:00:15 what's the best way for a downstream layer to disable boost in OE-core? It's serializing multiconfig build and only mandatory for systemtap? Jan 31 07:13:14 stacktrust: well if nothing would need it, it wouldn't be built Jan 31 07:19:13 stacktrust: What LetoThe2nd said, and I guess you could use BBMASK from your own layer.conf to mask the recipes if you want to make sure nothing can pull in boost by mistake in the future. Jan 31 07:22:03 one can certainly BBMASK things out, but usually fixing the fake dependency (or understanding the right one) is usually the better approach Jan 31 07:27:42 Agreed, it's just that if you're working on a large scale project it can sometimes be a bit hard to make sure everybody knows and remembers to check that a recipe isn't pulled in by changes in the future. Then it can be a good to add a mask with a comment with the rationale. Jan 31 07:28:14 erbo: so as usual. it depends (TM) Jan 31 07:28:58 Absolutely :) The best thing would maybe be to understand why boost is causing issues with multiconfig build in the first place, and get that fixed. Jan 31 07:30:10 probably its some form of bottlenect in the DAG, like perl so often is too. Jan 31 07:42:50 Morning guys, what is the better place to put a local device-tree file ( I would like to share the same between u-boot and kernel recipe :) ) ? Jan 31 08:07:26 Morning guys, what is the better place to put a local device-tree file ( I would like to share the same between u-boot and kernel recipe :) ) ? Jan 31 09:00:59 I want to add my own .dtb file, namely dt-blob at root, how do I include this in my bbappend? Jan 31 09:03:01 was looking at this one https://www.yoctoproject.org/pipermail/yocto/2019-May/045121.html but I find it strange that he has it's own copy procedure for the defconfig, when it simply can be added to srcfiles Jan 31 09:06:23 do I really need to create a patch file to modify the kernel makefile? Jan 31 09:06:25 PinkSnake: Device Trees aren't exactly one to one compatible between U-Boot and Linux FYI. Jan 31 09:06:52 PinkSnake: on the topic now: create a recipe which provides this Device Tree and make it a DEPENDS of both your kernel and u-boot recipes Jan 31 09:06:57 oh he had almost the same quesiton lol Jan 31 09:08:53 Ad0: .dtb or .dts? If you want to build it on its own, I think devicetree.bbclass should be helpful (never used it but it's the 5th time it comes up in the last few days). Otherwise, different options Jan 31 09:09:30 .dts but one is dt-blob.bin output, and I will have another one for a device itself Jan 31 09:09:31 full .dts in SRC_URI, you add it to the right place and you patch the Makefile (or add dtbs-y += my.dts to the correct architecture makefile in some task) Jan 31 09:09:50 otherwise, patch with dts and makefile in it and put that in SRC_URI Jan 31 09:10:00 Ad0: "dt-blob.bin output" ? Jan 31 09:10:07 qschulz sound like a good idea :) Thx ! Jan 31 09:10:12 yes, basic pin configurations Jan 31 09:10:27 it's a special file Jan 31 09:10:56 https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts Jan 31 09:11:56 I could perhaps grep the meta-raspberrypi Jan 31 09:12:05 they add a bunch of dts/dtb Jan 31 09:14:57 Ad0: could you explain what's hgappening, what's needed, what's what, where's should be what? You're using words I'm not used to (and rpi is a rather unusual ARM board :) ) Jan 31 09:16:32 I want to produce a dt-blob.bin file that will be added to the root just like bcm2708-rpi-b.dtb Jan 31 09:16:47 so the questio is if I should just compile it myself and add the dtb, or if I should include the dts Jan 31 09:17:12 I would like to have source files for everything as a part of the compile process really Jan 31 09:17:17 isn't that the "correct" thing to do Jan 31 09:21:54 it seems like the linux kernel sources has the dts though, meta-raspberrypi doesn't add the dts on their own, just include the DTB in the boot using their variable which I can use as well of course Jan 31 09:29:46 Ad0: then you're all set. Might need to just update your KERNEL_DEVICE_TREE in your machine conf: https://www.yoctoproject.org/docs/2.6.2/mega-manual/mega-manual.html#var-KERNEL_DEVICETREE Jan 31 09:30:34 yeah thanks. might need to do both that and the rpi one Jan 31 09:43:09 seems like it has all changed Jan 31 09:43:51 there's no mention of .dts files in arch/arm/boot/dts/Makefile Jan 31 09:44:40 it seems to be just dynamically added and compiled if they are in the right directory. so maybe prior to build I can just copy the dts file to the right dir and that's that Jan 31 09:44:54 Ad0: sources or we can't help Jan 31 09:46:18 https://elixir.bootlin.com/linux/v4.19.100/source/arch/arm/Makefile Jan 31 09:46:35 https://elixir.bootlin.com/linux/v4.19.100/source/arch/arm/boot/dts/Makefile Jan 31 09:47:34 you see the dts files flat in this dir https://elixir.bootlin.com/linux/v4.19.100/source/arch/arm/boot/dts Jan 31 09:51:38 so my machine is "bcm" so it would compile all dts files that starts with bcm* as I see it Jan 31 09:51:46 Ad0: I doubt those are the sources used by meta-raspberrypi? Jan 31 09:52:06 meta-raspberrypi uses the produced dtb files from that Jan 31 09:52:32 https://elixir.bootlin.com/linux/v4.19.100/source/arch/arm/boot/dts/Makefile#L74 Jan 31 09:53:21 let me find where it's referred Jan 31 09:55:29 arch/arm/boot/dts/Makefile mentions .dtb because those are kinda Makefile rules. X.dtb will ask for X.dts to be compiled Jan 31 09:56:19 ok Jan 31 09:57:05 so KERNEL_DEVICETREE won't magically do that? Jan 31 09:57:14 RP: re: rootfs-postcommands: Remove spaces before ; in -ROOTFS_..._COMMAND mail... Isn't it just that he's trying to do _remove = "mycommand;" instead of just _remove = "mycommand"? I don't think we actually care if ROOTFS_.*_COMMAND have "; ; ; ;" in there right? (Haven't checked, just wondering) Jan 31 09:59:19 https://github.com/FrankBau/meta-marsboard-bsp/blob/pyro/recipes-kernel/linux/linux-marsboard_4.1.15.bb Jan 31 09:59:20 Ad0: what's the recipe? Most likely this variable is making Yocto compile only the set DTBs instead of all of them or something, put them in deploy and if another variable is set, put them in /boot ? Something along the way Jan 31 10:00:56 I will get to the bottom of it Jan 31 10:00:59 Ad0: I'm confused why you're looking at the raspberry-pi recipe if you're building that one... Jan 31 10:01:02 https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-kernel/linux/linux-dtb.inc?h=pyro Jan 31 10:01:47 seems like it does it all? :) Jan 31 10:02:13 I use warrior though: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-kernel/linux/linux-dtb.inc?h=warrior Jan 31 10:02:26 Ad0: why did you send me a pyro link then :) Jan 31 10:02:37 haha oops. Jan 31 10:03:12 I think you should have enough clues now, I'll get back to work :) Jan 31 10:03:24 yeah thanks a lot! Jan 31 10:03:50 pleasure, don't hesitate to come back if you need help Jan 31 10:04:24 I am so relieved that this is built in Jan 31 10:16:00 erbo LetoThe2nd: will try BBMASK. multiconfig goes through 25K tasks and the graph bottlenecks a few times during the build. Tried -g to trace boost dependencies, but it's not too useful via ssh. There's a 2016 comment in oe-core which says Boost is optional but it being marked as DEPENDS to avoid a cyclic dependency. Jan 31 10:17:46 stacktrust: dumb idea, but I though of it yesterday... could you actually get the .dot files through ssh. Then run bitbake -u taskexp (NO -g) on it? Jan 31 10:17:59 from your local station Jan 31 10:18:15 stacktrust: if there's a depends set then masking it out will probably just break the build. Jan 31 10:19:07 The DEPENDS is in OE-core on systemtap, which is also not needed, so could be masked out also? Jan 31 10:19:54 stacktrust: if you try, let me know how that goes :) Jan 31 10:20:30 qschulz: good idea, I need to setup a Linux GUI box. Mostly on iPad. Someone mentioned PNG generation, will track that down. Jan 31 10:21:23 Toaster also promises a dependency graph and that would have a web interface. Jan 31 10:22:06 stacktrust: yeah I wouldn't go that path with PNG generation :) With a 3000 tasks image, it needed 5h to compile the png on my 12core CPU with 32GB of RAM :) Jan 31 10:22:16 (but maybe I did something wrong :) ) Jan 31 10:22:41 whoa Jan 31 10:22:55 and it was unreadable in the end Jan 31 10:26:09 Has anyone tried "bitbake buildtools-tarball" on zeus? It's failing to build tar, because it's trying to apply a CVE patch that is already upstream. But I can't find the recipe in OE-core which applies this patch, it seems to be magically constructed by SDK machinery. Jan 31 10:32:32 these images are cool: https://electric-cloud.com/blog/yoctoopenembedded-bitbake-build-visualization/ Jan 31 10:34:11 sigh. it configures and recompiles the kernel each time :/ Jan 31 10:34:27 Ad0: when? Jan 31 10:35:11 when I change the linux-raspberrypi_%.bbappend and change KERNEL_DEVICETREE Jan 31 10:35:56 Ad0: WAIT. Where are you putting KERNEL_DEVICETREE? Jan 31 10:36:21 I tried "dt-blob" without extension Jan 31 10:36:32 Ad0: no... not what, where Jan 31 10:37:07 Ad0: whatever the answer is, it's expected, you change a variable which is used in tasks, thus those tasks will be re-run Jan 31 10:37:15 in right Jan 31 10:37:47 KERNEL_DEVICETREE should be set in your machine configuration file (meta/conf/machine/blabla.conf Jan 31 10:37:52 ok. Jan 31 10:38:00 it got called though Jan 31 10:38:38 No rule to make target 'dt-blob' Stop. Jan 31 10:40:13 Ad0: have you read the link I sent you? Jan 31 10:40:44 I read about KERNEL_DEVICETREE in the mega manual Jan 31 10:40:52 which link are you thinking about :) Jan 31 10:40:58 Read again then, you missed something in parenthesis Jan 31 10:42:04 ok I will try .dtb but the extension should really be .bin to be picked up by the bootloader Jan 31 10:42:27 I guess I have to mv the file in a do_something_task Jan 31 10:44:50 No rule to make target 'arch/arm/boot/dts/dt-blob.dtb'. Stop. Jan 31 10:45:02 I guess it needs to be copied there specifically ? Jan 31 10:45:24 I don't have my own machine config yet so Jan 31 10:45:49 one step at a time Jan 31 10:46:44 yes, dt-blob.dts has to be in arch/${ARCH}/boot/dts. You have an example on one way to do it in the marswhatevr recipe you sent me earlier Jan 31 10:48:31 and you can see they're passing a defconfig as well Jan 31 10:49:34 yeah I was unsure if that was outdated or not Jan 31 10:52:26 Ad0: I'm so confused, are you actually building for an rpi or for a marsboard? Jan 31 10:52:45 rpi. I just found that one to find an example Jan 31 10:54:21 Ad0: then they're using config fragments Jan 31 10:54:55 from a quick look, so you'll need to create the ones you want manually Jan 31 10:57:43 hm Jan 31 10:58:19 if I were to make my own machine. is it possible to inherit include files from meta-raspberrypi ? Jan 31 10:58:33 or do I have to copy it all over / join it in one file Jan 31 10:58:48 Ad0: you can, just use relative path from the root of the meta-raspberrypi layer Jan 31 10:58:55 that's nice! Jan 31 10:59:21 and it's not inherit, it's include or require for file other than bbclasses Jan 31 10:59:42 I am just dreading another recompile :D Jan 31 10:59:56 I need to clear the old machines as well Jan 31 10:59:59 new machine means almost a complete rebuild :) Jan 31 11:00:03 yes Jan 31 11:01:32 it compiled now btw Jan 31 12:13:14 Is it possible to get tasks dependency tree of one recipe or image? Like listtasks but to know taks call order ? Jan 31 12:14:28 PinkSnake: bitbake -g $YOURRECIPE Jan 31 12:17:58 LetoThe2nd thx ;) Jan 31 12:55:24 what can i do when "devtool modify" cannot fetch sources because of "Reversed (or previously applied) patch detected! Assume -R? [n] Jan 31 12:56:09 correction, cannot patch_do_patch Jan 31 12:57:07 and why i dont get this error when normally bitbaking it Jan 31 13:02:08 stuom1: I had some issues with patchdir=.. for a few of my recipes when using devtool. CHeck those. I'd check that the workspace for devtool is clean but I doubt it would let you do something otherwise. Are you using the same machine and distro with devtool than with bitbake? Jan 31 13:08:07 qschulz: i didnt even know i can have different settings for devtool, but atleast explicitly i havent changed anything and devtool has worked with many other recipes. But i will check these, thanks! Jan 31 14:37:27 that sinking feeling when changing one recipe triggers a rebuild of nearly everything Jan 31 14:38:46 fullstop: depending on what you're doing, you can use locked sigs to stop that Jan 31 14:39:06 I deserved this one. :-) Jan 31 14:39:27 i used https://github.com/rossburton/bb/blob/master/libexec/bb-lockdown when i was touching perl.bb and didn't want it to rebuild perl-native every time Jan 31 14:39:27 And I fully blame nvidia for requiring an older gcc toolchain. Jan 31 14:40:17 rburton: saving that for later, thanks! Jan 31 14:40:35 New news from stackoverflow: (Yocto / OpenEmbedded) Enabling systemd's libcryptsetup Jan 31 14:41:12 with that being said, I'm setting up sstate-cache mirrors so that others here can start making recipes / developing for our platforms without building the world. It's fantastic. Jan 31 14:42:38 It's taken me months to get to this point, working on this on and off, but this is definitely an area where yocto bests buildroot by a wide margin. Jan 31 14:44:19 \o/ Jan 31 14:44:24 fullstop: are y'all using the same desktop distro? how much is the sstate-mirror used/efficient? I've been wondering if uninative is enough or not even when you have drastically different distros Jan 31 14:44:39 qschulz: uninative means all hosts are identical Jan 31 14:45:04 rburton: has it ever all been this? Jan 31 14:45:27 sorry not sure what you're asking Jan 31 14:45:44 qschulz: yes, but I've set up docker environments to ensure that. Jan 31 14:46:02 I mean, no host tools peeking through this uninative thing. even in branches before zeus/master? Jan 31 14:46:25 there are host tools which peek through. "file" is one example. Jan 31 14:46:32 qschulz: host tools don't go into the hashes so won't cause hash changes Jan 31 14:47:05 containers is a better solution all over Jan 31 14:47:16 fullstop: yeah, that's what I was thinking about. A few people running distros with no official Yocto support (arch, gentoo) are running containers but like 2% of the company, others are running... outdated distros Jan 31 14:47:19 if you're using container feel free to turn off uninative to save a little bit of time Jan 31 14:47:43 rburton: interesting! Jan 31 14:47:58 my desktop is arch, so I'm using docker to run with a ubuntu user space. Jan 31 14:48:10 fullstop: yup, we've one dev here doing the same Jan 31 14:48:40 i should get around to learning how to do that effectively Jan 31 14:48:42 custom dockerfile though, hopefully we can sync it between people wanting to use docker Jan 31 14:49:05 fullstop: how do you manage X with those dockers? e.g. is -utaskexp still usable or -c menuconfig for example Jan 31 14:49:14 qschulz: have you seen Pyrex? Jan 31 14:49:21 qschulz: one sec, I based it on something I used w/nvidia stuff. Jan 31 14:49:44 https://github.com/garmin/pyrex <-- transparent docker magic for company-wide deployment Jan 31 14:49:47 rburton: I've heard about it yes, I'm just gathering info from multiple people :) Jan 31 14:49:49 qschulz: https://github.com/atinfinity/sdk_manager_docker -- check out launch_container.sh Jan 31 14:50:18 You can launch, for example, xterm from within the container. Jan 31 14:52:45 The volume for the yocto build is just a directory on the host, so others can use graphical editors on the host to make changes if that's their thing. Jan 31 14:53:28 When creating a repo is it preferred to use the tarball vs git repo? Jan 31 14:53:36 s/repo/recipe/ Jan 31 14:54:06 I don't know if I'm in the majority here, but git for me. Jan 31 14:58:16 roussinm: just *guessing* here but I think if you change the SRCREV of the git recipe, you just download the difference in objects from the previous SRCREV. New tarball = new tarball. So space advantage when using git if multiple updates? But overall, perfectly clueless Jan 31 14:58:27 also depends if you have proper tarball releases, if not, don't use them. Jan 31 14:59:03 (and I think it's not advisable to use archives from github but I'm not so sure anymore and I don't remember where I saw it in Yocto) Jan 31 15:02:04 qschulz: the problem I have with using tarball is when you use devtool, it's possible to devtool modify a recipe that is a tarball. Jan 31 15:02:13 it's *not* Jan 31 15:02:34 Maybe that should be a feature request? Jan 31 15:02:39 what? really? Jan 31 15:03:20 qschulz: Yes, try to devtool modify a recipe which is a tarball i.e. lttng-ust. Jan 31 15:03:44 It will error out saying that it can't find a git repo. Jan 31 15:07:43 roussinm: I just did Jan 31 15:07:46 on thud Jan 31 15:07:47 RP: I think I solved YOCTO #13763. Bad interaction between SOURCE_DATE_EPOCH code and AUTOINC Jan 31 15:09:20 I'm on warrior? Jan 31 15:09:21 Err, not AUTOINC, AUTOREV Jan 31 15:09:40 qschulz: no sry I'm on zeus. Jan 31 15:10:42 New news from stackoverflow: Clone repository in post-process function in Yocto || Enabling systemd's libcryptsetup Jan 31 15:11:03 roussinm: try with vanilla poky on master. If it's broken, report. If not, try on zeus with vanilla poky. If broken, report. If not, investigate wtf your layers are doing :) Jan 31 15:13:03 qschulz: it's interesting that our layers could side-effet devtool... Jan 31 15:14:35 Distros are very powerful for example. I had reicpe mismatches during parsing because of a vendor Yocto layer Jan 31 15:14:59 Please reproduce and report, that feels like normal use case for devtool Jan 31 15:16:33 qschulz: it felt like a normal use case for us too. So I'll try to reproduce without any proprietary layers. Jan 31 15:25:51 roussinm: i prefer tarballs: typically smaller and easier to mirror Jan 31 15:30:39 rburton: yes I prefer them too for that reason, but sometimes isn't useful to have a git history to be able understand some part of the code that we are trying to patch throught devtool? Could devtool work with devupstream? Jan 31 15:31:12 i think kanavin fixed some bad devupstream/devtool interaction recently in master Jan 31 15:31:21 rburton: Oh nice! Jan 31 15:31:22 but that's a good reason to just use git, if you're patching it Jan 31 15:34:29 crap. history scrolled to far for me. RP: if you had a though on that mips32 kmod test failure, it scrolled away. sorry about that. if not, no worries either. Jan 31 15:34:51 I was out checking the brexit countdown clock in brussels :D Jan 31 15:36:45 * rburton sobs Jan 31 15:58:07 If I want to remove python3 from sysroot/TARGET of the generated sdk (we don't need the target binaries), should it be as simple as TOOLCHAIN_TARGET_TASK_remove += "python3" ? Jan 31 16:01:32 Maybe we should hard assign TOOLCHAIN_TARGET_TASK with the stuff we only need? I don't feel like that's the "yocto" way.. Jan 31 16:22:23 qschulz, so I think that I'm getting closer and I am getting a different error from bitbake when including dev-pkgs in the IMAGE_FEATURES of the APQ8053 BSP -- I am now getting multilib duplicate files errors when building in glibc-dev and lib32-glibc-dev into the image. Jan 31 16:22:55 qschulz, The error is the exact one reported by this person -- https://www.yoctoproject.org/pipermail/yocto/2016-October/032408.html Jan 31 16:29:24 ohhhhh one thing that I just found out is that by default if the target is linux it's going to use populate_sdk_ext hmmm, we don't want that for us. Jan 31 16:33:40 Is it possible blacklist or remove the 32-Bit multilib version of the glibc-dev package so as not to trigger the multilib check error: duplicate files issue for the headers? Jan 31 16:34:37 rob_gries: PACKAGE_EXCLUDE = "lib32-glibc-dev" maybe? in conf/local.conf. But this might trigger a build error Jan 31 16:35:50 qschulz, I'll give it a try. I already have build errors at this point anyway, so what's one more? /jk Jan 31 16:41:03 New news from stackoverflow: Can't run apt-get update on yocto linux [closed] Jan 31 16:42:25 qschulz: I have unfortunately have reached the same multilib error. Thanks for your help though. Jan 31 16:54:09 RP: Ah, that explains the ca-certificates bug also; allarch.bbclass changes WORKDIR in anon python, so the tasks are looking for the epoch file in the wrong place! Jan 31 17:00:36 aaah Jan 31 17:05:04 my toaster can't get AUTOREV from git - gives an exception. the same user, toaster runs can get revision with the same copy-pasted command. Jan 31 17:05:22 where should I dig a problem? Jan 31 17:09:47 I am using ~/.ssh/id_rsa key as the git key Jan 31 19:11:31 New news from stackoverflow: When a recipe is trying to install files into a shared area when those files already exist.? || Handle git submodules to make a "snapshot" of current state Jan 31 19:37:36 tlwoerner: Did you see my 2 patches to meta-rockchip (minor fix to rock-pi-4 description and rename tinker-rk3288 -> tinker-board)? Jan 31 19:39:17 JPEW: you and kanavin figured out YP bug 13755 before I even got to start working on it! :P Jan 31 19:39:18 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13755 normal, Medium+, 3.1 M3, trevor.gamblin, NEW , binutils-doc man pages have build timestamp encoded in them Jan 31 19:40:26 tgamblin: Ya, I'm not sure if we can use perl-native for pod2man; there's been some resistance to that when it's come up before Jan 31 19:40:43 Adds a big bottleneck to the build Jan 31 19:42:46 tlwoerner: Ah, actually you probably didn't because I sent it to the wrong mailing list :( Jan 31 20:00:20 Ready Jan 31 20:00:30 heh wrong chat :) Jan 31 23:49:08 big thanks to RP and Jefro for scottrif's memoriam! Jan 31 23:50:07 * armpit raises a glass of Bushmills whiskey in honor of Scott Jan 31 23:57:04 * armpit or 2 Feb 01 00:32:55 denix, +1 Feb 01 01:59:20 JPEW: yes, sorry, i did see your patches but got behind on other things. hopefully i'll take a look at them before Monday Feb 01 02:00:12 denix: +1 **** ENDING LOGGING AT Sat Feb 01 03:00:26 2020