**** BEGIN LOGGING AT Mon Apr 19 02:59:56 2021 Apr 19 07:12:08 yo dudX Apr 19 07:36:30 good morning Apr 19 07:36:37 good morning Apr 19 07:37:37 hello Apr 19 10:15:12 Hi All, Is it possible to add EXTRA_OECMAKE_ for two machines and say x, y and not for z ? Apr 19 10:18:05 prabhakarlad: either repeat it (e.g. EXTRA_OECMAKE_x and EXTRA_OECMAKE_z) or make use of MACHINEOVERRIDES mechanism to add a "family" in there which x and y machines are part of but not machine z Apr 19 10:19:22 qschulz: thanks for the pointer Apr 19 10:59:35 we should certainly add a note to https://layers.openembedded.org/layerindex/branch/master/layer/meta-optee/ that this layer is obsolete are that its contents are now maintained in meta-arm. I cannot submit a change with my account there, who can do that ? Apr 19 11:11:09 I think I can do that now Apr 19 11:11:38 ah bit its still getting commits Apr 19 11:11:54 if its not to be used then the master branch can just be removed Apr 19 11:13:16 done https://layers.openembedded.org/layerindex/branch/master/layer/meta-optee/ Apr 19 11:14:53 Hi Apr 19 11:15:43 i want strip some of python packages (unnecessary) from the build Apr 19 11:16:21 * RP is curious whether bitbake-getvar in master-next is useful Apr 19 11:16:31 so that it will reduce the size of python package Apr 19 11:16:58 python modules Apr 19 11:17:00 * Apr 19 11:17:12 how can yocto facilitate this Apr 19 11:32:59 Is there a simple way how to create a symlink for the rootfs e.g. my_rootfs.ext4.gz so that the MACHINE is not included in the filename? Apr 19 11:34:00 Or that the MACHINE is not part of any image recipe? Apr 19 11:35:45 [3:45:42 PM] i want strip some of python packages (unnecessary) from the build Apr 19 11:37:15 mr_qwertz: https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_NAME should help you out Apr 19 11:37:27 mr_qwertz: otherwise: https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_POSTPROCESS_COMMAND if you just want to add symlinks Apr 19 11:39:26 Mahesh: don't add them to your image? If that is not the issue, find out where those packages are added (DEPENDS/RDEPENDS?) can they be not included depending on PACKAGECONFIG option? Apr 19 11:40:16 bitbake -g will be your friend Apr 19 11:41:16 how to know packages which are not necessary Apr 19 11:42:54 qschulz thx Apr 19 11:43:38 Mahesh: so you do actually ask "i want to install less but i don't know what i can leave out"? Apr 19 11:44:15 yes Apr 19 11:45:05 LetoThe2nd Apr 19 11:45:45 o/ Apr 19 11:46:37 Mahesh: well then you probably better start out by understanding your requirements, as the yocto build can remove many things, if you can tell what. if you can't tell, yocto is not going to help you. Apr 19 11:59:34 Mahesh: set NO_RECOMMENDATIONS :-) Apr 19 11:59:41 but there be dragons Apr 19 11:59:45 so listen to LetoThe2nd Apr 19 12:03:32 derRichard: https://youtu.be/1QSCFI9y3SA Apr 19 12:34:24 LetoThe2nd: \o/ Apr 19 12:34:27 good sound Apr 19 12:35:02 derRichard: by now i have sme form of metal for almost any keyword. just to annoy rburton, of course. Apr 19 12:36:36 :-D Apr 19 13:11:24 LetoThe2nd how to useĀ  PACKAGECONFIGĀ  variable for removing specific moules of python package Apr 19 13:11:29 modules* Apr 19 13:15:53 Mahesh: https://youtu.be/559CF3gYCJA Apr 19 13:31:52 RP: something clearly went off the rails in my build! https://pastebin.com/csJctuRh Apr 19 13:32:00 that, I've never seen before! Apr 19 13:41:47 zeddii: I have seen it before, fun when it happens :) Apr 19 13:43:15 I remember Tom Zannusi did that on purpose with his python templates he was adding for whatever tool it was .. his design lives on! Apr 19 13:51:20 zeddii: those were insane :) Apr 19 13:54:44 zeddii: I particularly like the directories called else and if :) Apr 19 13:57:34 hehe. good times! Apr 19 14:09:40 tlwoerner: did you have any time for kernel bsp ? Apr 19 14:43:12 zeddii, jonmason: https://autobuilder.yoctoproject.org/typhoon/#/builders/113/builds/911 - you can argue about who needs to fix that :) Apr 19 14:45:12 sorry, not yet Apr 19 14:46:04 yann: are you happy with the changes you posted? (they're marked WIP) Apr 19 14:46:27 yann: i pulled in the one patch already Apr 19 14:46:57 RP: that's with my tweaked kern-tools patch ? if so, I'll fix it. Apr 19 14:46:58 reduce bbappend duplication Apr 19 14:47:13 yann: and i pulled in the baud rate change Apr 19 14:48:18 zeddii: thanks :) Apr 19 14:49:02 these are of course, just warnings that have always been hidden :D I'll just need a bit of time to get my local builder setup to reproduce it. I had to remove all my old state due to yet another ailing disk. Apr 19 14:49:31 well, I'm happy with the general direction. I have one fixup for the remaining WIP (put "bsp" in "files/" instead of "linux-yocto/" to avoid poluting FILESEXTRAPATHS). Otherwise, I guess we can work incrementally from there if the approach suits you Apr 19 14:50:18 (incidentally my optee patches build onto that unpublished fixup ;) ) Apr 19 15:09:02 Hi :-) Apr 19 15:09:02 I am reading about wic in the manual. Apr 19 15:09:03 Shouldn't: Apr 19 15:09:03 wic create -e Apr 19 15:09:04 create a wic image? Apr 19 15:09:04 The output I get are the partitions seperately. Apr 19 15:14:31 There is a huge task do_swuimage that calls several Python functions. Is there a possibility that _append can also be used for a nested Python function that is not themselve a task? Apr 19 15:21:33 swupdate: test and you shall see :) (use bb.warn() in python tasks or bbwarn "" in shell tasks to make it super obvious) Apr 19 15:25:38 :D Apr 19 16:06:15 RP: I remember you were saying something about increased parse times. Or maybe I imagined it. It might be part of my messed up build, but I was seeing a two minute start up time on my builds this morning. Trying to decide if I should debug further or chalk it up to a corrupted build. Apr 19 16:24:56 hah. gcc has been packaging for 23 minutes. Apr 19 16:25:00 good times. Apr 19 16:25:22 but yet, I see no signs of memory pressure or disk issues. Apr 19 16:25:25 * zeddii fires up perf Apr 19 16:25:28 0: gcc-10.3.0-r0 do_package - 23m6s (pid 25802) Apr 19 16:25:50 the kernel is trying to catch up! Apr 19 16:25:51 0: gcc-10.3.0-r0 do_package - 23m6s (pid 25802) Apr 19 16:26:20 'er .. 0: linux-yocto-5.10.30+gitAUTOINC+b7125842b7_8465e471f5-r0 do_package - 18m58s (pid 41147) Apr 19 16:36:25 kergoth: see what you think of the bitbake-getvar patch I sent. Torn on bitbake vs bb and a few other details Apr 19 16:37:08 zeddii: I fixed a parse time issue Apr 19 16:37:26 I think do_package has some kind of performance regression somewhere :/ Apr 19 16:39:15 0: linux-yocto-5.10.30+gitAUTOINC+b7125842b7_8465e471f5-r0 do_package - 32m5s (pid 41147) Apr 19 16:39:33 and people wonder why we didn't like slinging kernel source everywhere and make work-shared :D Apr 19 16:41:33 zeddii: are you building on a Raspberry Pi :p ? Apr 19 16:42:19 zeddii: oh, I wonder if this is because we fixed gcc's source handling Apr 19 16:42:29 * RP bets that was it Apr 19 16:43:18 although that shouldn't have changed linux-yocto Apr 19 16:43:48 I haven't even switched to meta-arm to try and do that kernel warning fix. Apr 19 16:43:56 at this rate, it'll be june before I send a patch Apr 19 16:43:59 0: linux-yocto-5.10.30+gitAUTOINC+b7125842b7_8465e471f5-r0 do_package - 36m24s (pid 41147) Apr 19 16:44:47 I'm polling the machine's stats, nothing is showing as error or super pressured. I may just try the windows fix and reboot the builder. which is sad, since I have about 7 months of shell history there :D Apr 19 16:46:05 zeddii: (helping as much as I can...) what about tail -f /proc/41147/fd/2 ? Apr 19 16:46:07 zeddii: would be nice to know what its doing Apr 19 16:46:41 zeddii: might help us improve Apr 19 16:47:17 nothing very intersting: https://pastebin.com/BLCtHucx Apr 19 16:47:33 I'll check the process state now, it may just be hung up on something. Apr 19 16:47:46 but there are others: 1: kernel-devsrc-1.0-r0 do_install - 38m39s (pid 42662) Apr 19 16:48:10 but the rest of the tasks are chugging away Apr 19 16:48:11 2: cpio-2.13-r0 do_package_qa - 33s (pid 30154) Apr 19 16:48:47 hmm. that process is doing an objcopy Apr 19 16:49:14 https://pastebin.com/BD3vBALa Apr 19 16:49:59 and going very, very slowly through all the modules. Apr 19 16:50:59 zeddii: it is expected to loop over those, just not sure why its so slow. It should also be doing them in parallel. Did you disable PARALLEL_MAKE? Apr 19 16:51:20 I think it would hook for BB_NUMBER_THREADS anyway Apr 19 16:51:57 same local.conf as before. but I agree. super strange. I'll keep an eye on it and keep poking. Apr 19 16:52:04 I'm just totally into setting a world record now! Apr 19 16:52:05 0: linux-yocto-5.10.30+gitAUTOINC+b7125842b7_8465e471f5-r0 do_package - 44m54s (pid 41147) Apr 19 16:52:18 what's 45 minutes between friends ? Apr 19 16:55:59 zeddii: are you sure your disk isn't dead, or connected with wet string or something? ;-) Apr 19 17:00:02 zeddii: I think I've seen times like that but only when I was deleting builds in parallel with running them (or when there was a rouge runqemu eating 100% CPU of a single CPU) Apr 19 17:00:18 :D brand new disk! smartctl and the kernel are showing no issues, neither did iotesting. Apr 19 17:00:29 agreed, there is something else being evil, and it is hiding from me. Apr 19 17:00:55 I'll just restart and see how it goes. I've set my record, the kernel finished packaging! Apr 19 17:04:58 would it make sense to add timestamp to log.do_ so that it's easier to debug those kinds of issues? (I'd assume at least..) Apr 19 17:18:15 qschulz: I did try that and it was surprisingly difficult to get right Apr 19 17:21:09 rburton, Saur: who is going to fix the btrfs-tools issue with meta-gplv2? :/ Apr 19 17:21:40 RP: We do not use btrfs... Apr 19 17:25:54 RP: I have not seen anything about btrfs-tools. Where should I look? Apr 19 17:26:24 Saur: https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/3315/steps/11/logs/stdio is the problem. Looks like its a ptest dependency in util-linux so we can probably just remove that for gplv2 Apr 19 17:29:42 I've put a patch on master-next to see if that helps Apr 19 17:31:16 confirmed, that does seem to fix it Apr 19 17:33:21 RP: what were the issues if I may ask? Apr 19 17:34:13 qschulz: btrfs-tools changed to LGPL-3.1 and now breaks meta-gplv2 which excludes the license Apr 19 17:34:31 RP: Though I guess it will affect running ptest for util-linux if you have meta-gplv2 enabled? Apr 19 17:35:31 Saur: sure. Not sure I'm going to worry about it Apr 19 17:35:44 Nah, I wouldn't either. :) Apr 19 17:40:00 yann: congrats you broke meta-arm :) Apr 19 17:40:16 not sure how it didn't break in testing but that's testing for you Apr 19 17:51:01 oh uh :) Apr 19 17:53:47 rburton: any clue why i don't get this QA error ? Apr 19 17:54:18 looks like my setup is closer to the testing one ? Apr 19 18:06:12 how can an image avoid building the kernel and bootloader? Apr 19 18:42:45 rburton: jonmason: the warnings that RP noted this morning come from the defconfig. I can get rid of them in multiple ways ... but want your input. Apr 19 18:42:54 these are the warnings : https://autobuilder.yoctoproject.org/typhoon/#/builders/113/builds/911/steps/12/logs/stdio Apr 19 18:43:26 I can create a fragment that just sets them to the value we want, we can patch the defconfig, we can declare them non-hardware (and hence no warning) ... Apr 19 18:43:37 my trek to get a toolchain built for the csky architecture is currently parked at libitm - there is no implementation for csky. is libitm _required_ for each architure or is it optional? Apr 19 18:48:57 zeddii: IMHO, it needs to be fixed in the upstream defconfig Apr 19 18:49:16 they are modifying the defconfig by hand and not regenerating it Apr 19 18:49:43 we're working around some similar silliness in meta-arm-bsp (different warnings though) Apr 19 18:51:36 I can come up with something to mask them in the linux-yocto builds, or I can carry a linux-yocto patch for it. or we convince RP to ignore the warnings ;) Apr 19 18:52:18 Hello .In previous projects using yocto 2.1 we had only 1 sdk and we were able to a toolchain.cmake file to include in configuration steps and later into and proper IDE to navigate C/C++ sources.Now in yocto dunfell there are multiple sysroots .. any pointer on how to implement same solution? Apr 19 18:54:44 zeddii: I think a patch would be better, then we can try to upstream it (and get upset when they say no) Apr 19 18:55:46 stable kernel broke qemuarm64-secureboot between 5.10.21 and 5.10.22. So I've been bisecting all morning Apr 19 18:55:55 ack'd. I'll cook something up. Apr 19 18:56:05 heh. the myth of the stable kernel in action! ;) Apr 19 18:56:23 on a positive note, I have gitlab ci running testimage now to find it faster Apr 19 18:56:41 nice. I should figure that out myself. Apr 19 18:56:57 it took me 2 weeks, but mostly because I'm stupid Apr 19 18:57:05 I'd be happy to walk you through it Apr 19 18:57:06 so about a month for me Apr 19 18:57:36 the trick is to understand that gitlab runner does not run the gitlab docker images inside it, but as a peer Apr 19 18:57:48 I'll take you up on that offer. I'll put it on the list with the CVE bash and try to get to them. Apr 19 18:57:56 ahah Apr 19 18:58:02 https://gitlab.com/jonmason00/meta-arm/-/pipelines/288760615 Apr 19 18:58:21 * zeddii clicks Apr 19 18:58:51 I'm thinking of doing a follow on to Paul Barker's gitlab CI talk, "gitlab CI for dummies" Apr 19 18:59:05 I'd be down for that. Apr 19 18:59:22 which reminds me. I'm probably almost out of time to submit something for the summit. Apr 19 18:59:27 * zeddii scrawls that on the list. Apr 19 18:59:41 I can just re-offer my failed talks from last time. Apr 19 19:00:45 lol Apr 19 19:10:12 I'm tempted to annoy people and show how the layer management issue is actually been solved with git submodules Apr 19 19:11:06 Use https://github.com/siemens/kas as everybody Apr 19 19:13:24 swupdate: I am using that Apr 19 19:13:53 I'm even "fixing" the docker image to allow for testimage (builder user needs sudo) Apr 19 19:14:14 as soon as I get it fully working on x86 and arm64 builders, I'll push the changes Apr 19 19:14:34 * zeddii uses git pull Apr 19 19:14:58 zeddii: you should at least have a shell script and cronjob Apr 19 19:15:20 no way. I want to chose when updates happen. this isn't a CI I'm talking about :D Apr 19 19:15:21 sstate pre-population with overnight builds Apr 19 19:16:10 doing features, maintenance, bug fixes, etc, I chose when I want to risk explosions :D Apr 19 19:16:34 that is fair Apr 19 19:17:53 I was clicking around the gitlab stuff you linked, Still can't tell what does what. Clearly I need to do some reading. Apr 19 19:18:13 @jonmason are those builds being farmed out to your infrastructure ? Apr 19 19:18:38 I wouldn't mind being able to trigger some of that for meta-virt. a bit less for my kernel stuff. Apr 19 19:18:39 my desktop has 2 runners Apr 19 19:19:32 essentially, you get gitlab runner docker, then decide how to run the CI. We're using kas inside a docker Apr 19 19:20:11 and it uses your runner to exec on the build h/w of your specification ? that's the main thing I want. Apr 19 19:20:13 with a prepopulated sstate, it takes about 40 mins to build everything and run testimage Apr 19 19:20:25 yes, it is all running locally Apr 19 19:20:32 no servers or cloud Apr 19 19:20:48 I'll definitely have to dig into it then. that ticks the big boxes. Apr 19 19:21:31 Maybe I should write you and howto as a start of a talk, and you can tell me whats missing and if I'm very stupid or not Apr 19 19:22:02 That would be awesome. I have cycles to try and do feedback. Apr 19 19:22:33 ok, I'll try to get what I have cleaned up and sent to you in an email Apr 19 19:49:01 has is read only though? Apr 19 19:49:32 kas Apr 19 20:06:33 Crofton|cloud: what do you mean? you can specify what to build (like branches) and pull images out Apr 19 20:11:04 the submodule has the got hashes of the layers Apr 19 20:11:07 and branches Apr 19 20:11:22 and you can edit and make new branches snd submiot work upstream Apr 19 20:29:11 yes, you can fetch specific versions or track upstream. with gitlab you can schedule jobs. it works out well Apr 19 20:38:52 Crofton|cloud: our kas/ci stuff is all in meta-arm if you want to dig in Apr 19 20:38:57 meta-security does the same sort of thing Apr 19 20:53:46 rburton: if meta-security used kasproject/kas docker image, they could reduce their gitlab-ci.yml by 3 lines :) Apr 19 20:54:04 I was going to try it out once I got all of our stuff sorted Apr 19 20:58:58 zeddii: YP Summit CFP ends tomorrow! You better dig up some old stuff fast ;-) Apr 19 21:01:16 jonmason: off by one... week, actually. https://pretalx.com/yocto-project-summit-2021/cfp Apr 19 21:05:16 phew. I can put it off for a lot longer! ;) Apr 19 21:05:19 LetoThe2nd: in my defense, I'm not sure what day it is Apr 19 21:05:31 jonmason, isn't it riot-eve ? Apr 19 21:05:39 * zeddii runs **** BEGIN LOGGING AT Mon Apr 19 21:08:15 2021 Apr 19 21:23:30 * LetoThe2nd riots off to bed. G'Night dudX Apr 19 22:29:57 what is more common term in the yocto vocabulary to describe the system on which the build happens? "host" or "native"? Apr 19 22:44:21 vdl: I would say the build system is the "host" and "native" is the environment on that system Apr 19 22:50:10 vdl: native is probably more usual. The trouble is GNU cross build has specific meanings for build, host and target and they don't mean what people think they do :/ Apr 19 23:35:57 RP: I see. Same concerns come to me when I'm designing a system with "host" and containers. While "container" is explicit, "host" images are more prone to confusion. Apr 19 23:45:47 When a package isn't available in common layers, do you guys import the recipe in your layer, or do you use the layer providing it as shown on http://layers.openembedded.org? Apr 19 23:46:04 I don't have strong opinion for simple packages such as "sshpass". Apr 20 00:20:43 vdl: usually it will depend on your use of that layer, if its just one recipe or you need more core pkgs from it. Apr 20 00:34:03 * armpit sshpass should move to meta-oe **** ENDING LOGGING AT Tue Apr 20 02:59:56 2021