Friday, 2021-08-06

*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 258 seconds)00:09
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:33
*** aleblanc <aleblanc!> has quit IRC (Ping timeout: 258 seconds)00:45
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto00:57
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto01:12
*** sakoman <sakoman!~steve@> has quit IRC (Quit: Leaving.)01:44
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)01:48
*** camus <camus!~Instantbi@> has joined #yocto01:49
*** mihai <mihai!~mihai@user/mihai> has joined #yocto01:58
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)02:03
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 258 seconds)02:35
*** camus1 <camus1!~Instantbi@> has joined #yocto02:59
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 256 seconds)03:00
*** camus1 is now known as camus03:00
*** amitk <amitk!~amit@> has joined #yocto04:02
*** boo <boo!> has quit IRC (Ping timeout: 258 seconds)04:41
*** CocoJoe <CocoJoe!> has joined #yocto04:41
*** roussinm <roussinm!> has quit IRC (Quit: WeeChat 3.3-dev)05:26
*** rpcme <rpcme!~rpcme@> has quit IRC (Ping timeout: 246 seconds)05:44
*** vmeson <vmeson!> has quit IRC (Ping timeout: 250 seconds)05:48
*** vmeson <vmeson!> has joined #yocto06:07
*** rob_w <rob_w!> has joined #yocto06:22
*** LetoThe2nd <LetoThe2nd!> has joined #yocto06:36
*** sbach <sbach!~sbach@user/sbach> has quit IRC (Read error: Connection reset by peer)06:40
*** mckoan|away is now known as mckoan06:41
*** sbach <sbach!~sbach@user/sbach> has joined #yocto06:41
mckoangood morning06:41
LetoThe2ndyo dudX and mckoans06:45
*** ant__ <ant__!> has quit IRC (Ping timeout: 240 seconds)06:50
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto06:51
*** vd <vd!> has quit IRC (Quit: Client closed)06:53
*** mseeber <mseeber!> has joined #yocto06:59
RPOf course as soon as I try and step away for a few days, the overrides bugs start being reported :(07:01
LetoThe2ndRP: ya, but unfortunately it wouldn't have worked the other way round. so if you were like "i'm gonna be away the next x days in order to trigger bug reports", then not a single one would have arrived.07:02
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)07:03
*** camus <camus!~Instantbi@> has joined #yocto07:04
*** mseeber <mseeber!> has quit IRC (Quit: mseeber)07:05
*** mseeber <mseeber!> has joined #yocto07:07
*** prabhakarlad <prabhakarlad!> has joined #yocto07:14
* LetoThe2nd mihai: exactly07:26
*** kranzo <kranzo!> has joined #yocto07:41
*** camus1 <camus1!~Instantbi@> has joined #yocto07:41
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)07:42
*** camus1 is now known as camus07:42
*** mranostaj <mranostaj!~mranostaj@> has quit IRC (Remote host closed the connection)07:52
*** kranzo <kranzo!> has left #yocto07:53
*** mranostaj <mranostaj!~mranostaj@> has joined #yocto07:53
*** kranzo <kranzo!> has joined #yocto07:56
dv_I added INHERIT += "rm_work" in local.conf , and yet, rm_work wasn't executed on the built recipes08:04
*** zeddii <zeddii!> has quit IRC (Ping timeout: 272 seconds)08:04
*** camus1 <camus1!~Instantbi@> has joined #yocto08:04
dv_perhaps bitbake would normally run rm_work at a much later stage. however, my machine ran out of disk space because of all of those not-removed workdirs - precisely what rm_work is there to deal with08:05
LetoThe2nddv_: maybe just dump tmp?08:05
dv_is there a way to force bitbake to always run rm_work *immediately* after the packages are done (unless the recipes are in RM_WORK_EXCLUDE) ?08:06
*** goliath <goliath!~goliath@user/goliath> has joined #yocto08:06
dv_"dump tmp"?08:06
LetoThe2nddv_: well, rm -fR your tmp dir. it will be refilled from sstate quickly, and from thereon rm_work will probably be helpful08:06
dv_I need the workdirs of some recipes intact08:06
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 276 seconds)08:07
*** camus1 is now known as camus08:07
dv_also, this is a workaround - the proper solution is rm_work08:07
dv_ah, ok, misread08:07
*** zeddii <zeddii!> has joined #yocto08:07
LetoThe2ndseriously, if your strategy to a working build is squeezing the last handful of GB out of your disk with rm_work, then you're in trouble anywas.08:07
dv_but wait - isn't rm_work supposed to clean up tmp? that's what you'd do by running rm'ing tmp08:08
dv_well, perhaps not all of us have multi-TB SSDs in our machines08:08
dv_and this is not just about "a few GB". without rm_work, tmp eats up about 120 GB. with rm_work, maybe 4 GB.08:09
LetoThe2ndneither do i. but its like planning your monthly budget in a way that work perfectly with 10$ spare. it works. until that one month when you need new shoes.08:09
dv_either way, rm_work is a must at the moment.08:10
dv_"more disk space" is NOT an option right now.08:10
LetoThe2ndlike i said: dump your tmp. hope for rm_work to save you from thereon. if its not enough, clean out your sstate, hope even more.08:12
dv_but that makes no sense08:13
dv_rm_work is supposed to dump work from tmp!08:13
LetoThe2ndrm_work is supposed to clean out after building.08:13
dv_well, "i.e. after all work on the current recipe is done"08:14
dv_so, once the recipe is fully built, rm_work should kick in08:14
*** zeddii <zeddii!> has quit IRC (Ping timeout: 240 seconds)08:14
dv_and I have seen this behavior in the past. but something apparently changed.08:14
LetoThe2ndso if you slap it onto your tmp with everything already built, then... building doesn't happen, therefore rm'ing doesn't. thats how i read it. i mightbe wrong of course, but i'm 75% sure it is like that.08:14
dv_but I did have rm_work included in local.conf right from the start08:15
dv_even before I built anything at all08:15
dv_hm. perhaps a bug?08:15
LetoThe2ndthen you'll have to dig deeper what packages eat the space, in which form, and why they're not cleaned.08:15
*** zeddii <zeddii!> has joined #yocto08:15
LetoThe2ndand have you verified that its actually tmp that eats the space, not sstate or downloads?08:16
dv_yea, I did that. it turns out that _none_ of the packages were cleaned up08:16
dv_and yup, its tmp08:16
*** Guest14 <Guest14!~Guest14@> has joined #yocto08:16
*** Guest14 <Guest14!~Guest14@> has quit IRC (Client Quit)08:16
dv_I forced bitbake to rm_work those packages by first gobbling up the package names (by going into tmp/work/arm-poky-[...]-eabi/ and running "echo * | xclip" and then running bitbake -c rm_work <pasted clipboard contents>)08:17
dv_and lo and behold, all packages were cleaned up08:17
LetoThe2nddv_: have you verified the behaviour exists on a raw poky? its very well possible that some layer breaks it.08:18
*** cebrax <cebrax!~cebrax@> has joined #yocto08:18
LetoThe2ndin other words: if rm_work doesn't work as intended on a vanila poky, then its a bug (which is possible of course). if it does work there, then, well... you need to go dig deeper.08:19
kranzoHi there, i had some configure-usafe aborts on my build, so i startet using a container (same ubuntu20.04) to get a clean env, worked fine until i discovered pseudo-aborts on random recipes, is there a known issue with building in conatiners or a "proper" way to debug pseudo aborts? (i'm pretty new to yocto)08:20
*** florian <florian!> has joined #yocto08:20
dv_LetoThe2nd: looks more and more like it ..08:21
kranzoLetoThe2nd actually your livecoding on youtube is pretty enjoyable08:22
dv_oh well, gotta bite that bullet. either way, this is not normal rm_work behavior if I got this right08:22
LetoThe2ndkranzo: the pseudo aborts usually come from the fs/inods/watchers being pushed beyond their limits in combination with some known and some maybe unknown factors. do they happen on fresh builds too? is there something special about your containers?08:23
LetoThe2nddv_: like i said - if you can nail it down to a reproductible description, then we'll (not exactly happily, but hey!)08:24
*** frieder <frieder!> has joined #yocto08:24
LetoThe2ndtreat is as a bug. otherwise, well, what can i say.08:24
LetoThe2ndkranzo: and thanks!08:24
kranzoyes clean builds break as well, but while describing the problem i noticed i use podman instead of docker right now, maybe they tread some fs stuff different. ill give it a try.08:27
*** Fulgo <Fulgo!> has joined #yocto08:28
*** Fulgo <Fulgo!> has quit IRC (Client Quit)08:28
cebraxDoes anybody know u-boot-fslc v2020 support LCD IF drivers for iMX6ULL?08:30
cebraxDoes anybody know *whether* u-boot-fslc v2020 support LCD IF drivers for iMX6ULL or not?08:30
LetoThe2ndkranzo: yeah we usually go for docker.08:30
qschulzkranzo: been using podman only :)08:30
LetoThe2ndcebrax: why not ask the uboot folks?08:31
qschulzI use pyrex for development and will try to setup a CROPS container for CI08:31
*** Fulgo <Fulgo!> has joined #yocto08:31
kranzoqschulz rootless? or not?08:31
cebraxLetoThe2nd Thank you! :)08:32
kranzoqschulzill have a look into that, i just manually setup  a small minimal image by hand so maybe there is something to tweakk08:34
cebraxLetoThe2nd are you Josef Holzmayr?08:35
FulgoPlease, no anger, but... I have many questions I am not finding answer for and I am not sure if this would be the place :(. Obviosly, I do not expect to have the work done and I think I am still missing basic concepts08:38
FulgoI have read the reference manuals, seen many videos and read other resources but apart from the basics, as I want to go a little further the things turn complicated08:39
LetoThe2ndcebrax: i actually am :)08:40
*** frieder <frieder!> has quit IRC (Remote host closed the connection)08:40
qschulzFulgo: breathe in, breathe out and ask the question :) ALl will be good :)08:40
FulgoWell, I will start slow :D08:41
qschulzone question at a time, try to provide enough context but not too much and think about XY problem08:41
LetoThe2ndFulgo: howdy, welcome! so - if your question is yocto-related, you can always drop it in here. we will always have a look and try to answer. the worst things that can happen is that you don't get an answer because nobody knows, or that we might redirect you to another place where we see the question more fit. but all in all we're very relaxed.08:41
FulgoFirst, I am trying to actually guess the filesystem my custom image will use.... I have checked variables such as: IMAGE_FSTYPES and ROOTFS_XXXX expecting to find something but.. I haven't08:42
cebraxLetoThe2nd wow! I really appreciate GREAT videos you are making, thank you!08:42
FulgoThanks, all08:42
LetoThe2ndcebrax: thank! :)08:42
FulgoThis is just a doubt, because trying to trim the image provided by the vendor is when the problems arise XD08:42
FulgoMaybe that question is... very basic but I was expecting to find something like "ext3", and I just saw something like this in DISTRO_FEATURES08:43
cebraxI really wish if there was a video that brought up a custom embedded linux board, with custom device trees and such, especially for hardware guys :'(08:44
qschulzFulgo: you can define the "final" type of an artefact from an image recipe with IMAGE_FSTYPES indeed. Some types are filesystems only, some are a combination of filesystems (e.g. wic allows to create images with multiple partitions of different filesystems (or no fs), can have multiple ubifs vol08:44
qschulzubi images can have multiple ubifs volumes, etc...08:44
qschulzFulgo: how did you check the content of IMAGE_FSTYPES?08:45
Fulgobitbake -e fsl-image-ngc | grep "^FSTYPES"08:45
LetoThe2ndcebrax: well, its not that easy. board bringup is often complicated and time consuming, unless the hardware is already known good and has working SW support.08:45
FulgoYes, I understand a wic image could have multiple partitions. In fact I found the following: IMAGE_FSTYPES="tar.gz wic.gz"08:46
qschulzcebrax: that's not really the point of Yocto though, you bring up the bootloader and kernel/device tree first, with cross-compilation toolchains provided by your vendor/distribution and then you can integrate them in Yocto08:46
qschulzFulgo: there you go :)08:46
LetoThe2ndcebrax: so, there are a nuber of good trainings out there that will show the most common things about that. i can say that for everything from bootlin, the resources are even free. but all in all, it depends quite a bit on hardware debugging and expertise.08:46
qschulzFulgo:  to know what's inside the wic, you need to find the wks file that is used for your custom image08:47
FulgoUmh... I have seen many videos but they usually just build a basic distro and image. Once I pretend to trim the image or to change something I do not find free resources08:47
FulgoAnd paying without any certainty of getting what I want... is not an option I guess08:48
LetoThe2ndcebrax: and unless somebody pays me a couple k€, probably more like couple 10k€, i am pretty sure i can't show a full bringup in video form.08:48
cebraxqschulz Yeah, I think that's what it comes to, you need to move to Yocto once you've got all your peripherals working I guess?08:48
FulgoI have all of them working. The vendor provided a HUGE image, and I want to trim it (reduce it to only what I need)08:49
LetoThe2ndFulgo: and, "trimming" an image is usually not a good way. start small and then add whatever you need.08:49
FulgoThe filesystem was only something I was not finding... If a wic image is being generated, there should be something in there building the partitions in it but... where. So, just  as a first question I found it interesting08:50
FulgoUmh... so, you recommed that I should create a layer with a core-image-base, and add features to it. Actually, the image provided by the vendor is huge because the image recipe, so firstly I just created my own and removed all the undesired packets08:51
FulgoI reduced the image from 1GB to 100MB but... we need something small and poky tiny seems not to be supported (that is what the vendor says)08:52
FulgoLetoThe2nd thanks for the training materials08:52
LetoThe2ndyeah, essentially thats what i would recommend. copying the original image recipe and ripping out stuff is ok, if it works for you. so, 100M is still too big, or what?08:52
FulgoI was in YoctoProject: Youtube and website resources08:53
qschulzFulgo: next step is to enable buildhistory and investigate which packages are making your rootfs grow too much and those you can afford to remove08:53
cebraxLetoThe2nd You're absolutely right.. Moving further is really detailed, as you are in a REALLY big system.. Imagine finding your way thru a really big harness of wire.. For example, I managed to make my LCD work with linux, now I am trying to make u-boot use my LCD, however after a week I don't think I have moved a centimeter forward..08:53
FulgoThis is a new project based in an old one from 1993... and as the legacy has a 4MB size... they pretend me to reduce the image to the minimum08:53
FulgoMaybe is not possible but I have to try08:54
qschulzcebrax: why do you want LCD support in U-Boot?08:54
LetoThe2ndcebrax: happens, that. for the u-boot case: take it out of yocto, make it work alone. then reintegrate.08:54
qschulzFulgo: you want a 4MB rootfs???08:54
cebraxLetoThe2nd Oh, by the way I didn't imply you to make a video on it, reading it again, sorry my sentence feels like that :D08:54
FulgoNo. 4MB everythin.08:54
qschulzFulgo: lol08:54
FulgoKernel, rootfs, devicetree... everything08:54
LetoThe2ndFulgo: 4MB is outright illusory unless you invest quite some effort.08:54
FulgoThat is what I said08:54
LetoThe2ndFulgo: and with a recent kernel, moreso.08:55
qschulzLetoThe2nd: "quite some effort" is a BIG understatement08:55
LetoThe2ndqschulz: definitions of "quite some" tend to vary, traditionally.08:55
cebraxqschulz Because I want to display a boot logo before linux can show one, as it takes 6-7 secs08:55
LetoThe2ndcebrax: if it makes you feel better: some time back i wasted 4 weeks straight on hunting exactly ONE BIT to be set correctly in a driver.08:56
FulgoThe point is that they use very slow interfaces to update the distribution (serial comms) and the smaller the better08:56
qschulzcebrax: ok but just so you know, it's not straightforward to have flick-free transition when the kernel is taking control of the LCD. But if that does not matter, then it's simpler (didn't say simple :) )08:56
LetoThe2ndFulgo: depending on the hw and everything, it can be possible. for a beginner? hardl.y08:57
qschulzFulgo: if it's an update speed issue and not a storage limitation, that's a different thing08:57
LetoThe2ndFulgo: if you really, really need such, then you better hire somebody.08:57
LetoThe2ndFulgo: and as qschulz says: if its only to mitigate update times, then its actually a XY problem and should be solved differently.08:58
qschulzbecause I guess you could do some binary diff update or whatever it's called to avoid uploading the whole image?08:58
FulgoWell, I am noob in YOCTO, but it always a time to learn :(08:58
FulgoI put effort not to fail, but if you consider it is impossible...08:59
qschulzbut yeah, more than a few MB via serial comms is almost a deal breaker, I understand08:59
LetoThe2ndFulgo: there is a reason why size reduction is a common topic in linux trainings.08:59
cebraxqschulz I really don't mind the flicker for now.. Actually I am in the learning phase and for now, even a text on LCD is a really big success for me :D08:59
FulgoLetoThe2nd differently? If I have a huge image, I need to reduce it to update YOCTO image08:59
qschulzFulgo: trimming down the kernel, bootloader, and rootfs is a difficult task which is rarely documented because it is very HW and project-specific so there's no one rule to rule them all or whatever the expression is09:00
Fulgopatches are painful to handle09:00
LetoThe2ndFulgo: of course you need to get down then, but if the rule says "update must not exceed 4MB", then thats a completely different thing than "image must not exceed 4MB"09:01
FulgoI used years ago something with bsdiff and dealing with the patches was a real challenge09:01
qschulzdifficult in terms of time spent and various SW components to be modified and still have a working build09:01
LetoThe2ndFulgo: look up current OTA solutions.09:01
FulgoNo, no. Well, they are saying 4MB because they want to put some preassure09:01
cebraxActually this is the first time I interact with embedded linux, here is my first board, when I saw RAM test passed, I almost cried :)09:01
FulgoWhat they do not want is a 100MB image09:01
qschulzcebrax: huge first step, congrats!09:02
FulgoOTA... Over the Air?09:02
qschulzFulgo: yes09:02
cebraxqschulz thank you!09:02
FulgoWell, I am not sure what new solutions will have arisen but with low throughput interfaces it gets complicated09:03
LetoThe2ndcebrax: nice indeedcool project09:03
qschulzI think 4MB is unrealistic without a lot of time and money spent09:03
LetoThe2ndqschulz: 4MB image? yup. 4MB diff update? might be realistic.09:03
qschulzFulgo: is there really no other way that serial comms to update your thing?09:03
cebrax#u-boot channel is filled with cricket sounds I guess.. Does anybody know any other places I can talk with u-boot guys?09:04
FulgoYes, but the project requires a good performance for the legacy interfaces09:04
qschulzLetoThe2nd: yes but you would need to update very often to make sure the diff is as small as possible09:04
cebraxLetoThe2nd thank you!09:04
FulgoWith ETH there are no problems at all09:04
qschulzcebrax: on libera?09:04
cebraxYes, also freenode09:04
FulgoWe expect not to need any update, but they want to have all the means available09:04
qschulzFulgo: seems like a marketing issue :)09:04
*** camus1 <camus1!~Instantbi@> has joined #yocto09:05
qschulzcebrax: there's one issue with your question, you're asking about a vendor fork of u-boot in an upstream channel :)09:06
LetoThe2ndcebrax: well as you're on a patched u-boot, there will probably not be too much enthusiasm for it. i would advise to "do your homework", e.g. get the sources, look at the board you're basing off, from there, look at the drivers, etc.09:06
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 258 seconds)09:06
*** camus1 is now known as camus09:06
LetoThe2ndcebrax: like i said: board bringup is hard work.09:06
qschulzcebrax: that lowers the chance to have people interested in your problem :)09:06
Fulgohahaha yes... you know, the commercials are tough people09:06
cebraxOh, that was what I felt, and hearing it from you guys made it official for me I guess :(09:07
qschulzFulgo: and sometmes they need someone to say what they want is not reasonable or impossible :)09:07
FulgoYes, I am doing it. But I understand that I need to struggle a bit09:07
cebraxLetoThe2nd Yeah, that's what I've been doing for a week now.. I guess I need to work a lot more harder09:08
FulgoI do not give up easily09:08
qschulzFulgo: try for a few days to get something as minimal as possible but still working. Then present those results, and tell them it's going to cost them 100 times more financially or in man hours to get it down to much smaller or to discover it's not possible09:08
FulgoAt least have some basis to defend if it is or not possible09:09
Fulgoqschulz I agree with you. But when they ask me why, I have to give an explanation XD09:09
FulgoI cannot say... well, I tried a lot09:10
FulgoThe kernel itself is 6MB, so they know that 4MB is not possible09:10
qschulzFulgo: well, sometimes the skills you have at one point in time is not enough to do something.09:10
FulgoNow, I have to know if I can reduce these 100MB09:10
qschulzFulgo: and might help, boot time reduction is often a consequence of size reduction09:11
Fulgoqschulz I again agree with you. That is why I am here. Just to have feedback from people that master YOCTO and how I can get the knowledge for now or for the future09:12
Fulgoqschulz I am going to check those09:12
qschulzhave it much smaller than 100MB is surely possible, it all depends what you REALLY need in your system09:12
LetoThe2ndqschulz: chromium!09:12
qschulzyou'll need to play with PACKAGECONFIG, split packages in more packages, NO_RECOMMENDATIONS is also a good start09:13
qschulzdon't forget to look into the distro and machine configuration files, sometimes useless stuff is added there, especially in vendor BSPs09:14
qschulzLetoThe2nd: ?09:14
cebraxqschulz lol that's a funny name, NO_RECOMMENDATIONS09:14
Fulgoqschulz what is NO_RECOMMENDATIONS?09:14
LetoThe2ndqschulz: "it all depends what you REALLY need in your system" -> chromium!09:14
LetoThe2ndFulgo: not giving beer to me is NOT_RECOMMENDED, for example09:15
qschulzLetoThe2nd: LIES, I wanted to send you some you refused09:15
LetoThe2ndqschulz: shhhhht!09:15
qschulzcon man09:15
Fulgoqschulz yes, I am trying to remove things from DISTRO_FEATURES and IMAGE_INSTALL. But another interesting question I am not being able to solve... I can see in those variables packages that I would like to remove, but I am not able to see where were those added09:15
LetoThe2ndqschulz: how dare you demolish my beer-based PR campaigning?!?09:16
qschulzFulgo: bitbake -e will help you, don't use grep since you want the history of the variable09:16
FulgoI tried even to use bitable -g but dot takes incountable hours to generate the graph... Maybe I am doing something wrong09:16
FulgoYes, It is what I did09:16
Fulgobitbake -e fsl-image-ngc | grep "^DISTRO"09:16
qschulzFulgo: no, don't use dot, just read with your text editor09:17
Fulgobitbake -e fsl-image-ngc | grep "^IMAGE"09:17
qschulzFulgo: "don't use grep" I just said :)09:17
Fulgoqschulz ok ok09:17
Fulgono??? It is huge then XD09:17
qschulzgo to the line starting with IMAGE and look above09:17
FulgoMay python functions and others09:17
qschulzFulgo: redirect to a file or less and search for the line09:18
qschulzthen read above09:18
FulgoIt is not easy for me to trace in YOCTO09:18
Fulgobitbake -e fsl-image-ngc > test.txt09:19
FulgoWell, trace or know who added the packed to the rootfs09:19
Fulgomaybe trace is not the verb09:19
qschulzFulgo: it's one of the difficult things yes, because -g does not list only direct dependencies but all dependencies. So dependencies of your direct dependencies...09:22
qschulzFulgo: I recommend builhistory again, at least you know which packages should be nuked first09:22
LetoThe2ndqschulz: dukenukem'ed09:22
FulgoYes, or the manifest also helps09:23
FulgoThe problem is, if I do not want one of the installed packets... the only way to remove it from the rootfs is using DISTRO_FEATURES_remove or IMAGE_INSTALL_remove?09:23
qschulzFulgo: no, you should avoid _remove as much as possible09:24
qschulzyou need to check if it's directly added to IMAGE_INSTALL in which case you can just NOT include it (remember, you wrote your own image recipe)09:24
qschulzyou probably want to write your own distro conf too09:25
mseeberi got burned by _remove in the past. turned out variables can be configured (by vendors) in a way that they ignore a _remove09:25
qschulz(and probably switch from systemd to sysv for example)09:25
qschulzmseeber: enlighten me09:25
LetoThe2ndmseeber: see comment by chris09:26
Fulgoumh.. To be honest, I tried yesterday but as I added my distro, bitbakes complained a lot that the distro was not supported or something like that09:26
qschulzFulgo: if they are not direct addition, then you need to figure out which package is adding it, then check if it's possible to remove it from the dependencies (by modifying PACKAGECONFIG for example)09:26
qschulzFulgo: I suspect fuckery in your vendor BSP layer :)09:26
FulgoBut I understand that if the distro adds the undesired packets... there will not be other way09:26
FulgoMaybe XD09:27
FulgoIT IS A TRAP!09:27
FulgoI basically cloned wayland distro conf file, and removed x1109:27
JaMaRP: FWIW: I'm still seeing some weird issues in honister which look like some side-effect of override conversion, but I'm still trying to narrow it down to something reproducible in oe-core (I'll retest with the packagedata fix you've merged, but doesn't seem to be directly related)09:28
FulgoBut once I used bitbake with the new distro... everything exploded09:28
qschulzFulgo: I usually recommend to get rid of the vendor BSP layer and just take their kernel/u-boot recipes as it's usually what you need09:28
mseeberLetoThe2nd: thanks, that would have worke, but at that time i had a different problem, i am going to look it up in my notes09:28
FulgoI do not need vendor's layer?09:29
Fulgomachine configuration, patches and others?09:29
RPJaMa: As that fix shows, there are some gremlins left we need to find and work out...09:29
kranzomaybe i'll go back to my initial problem first: i'll get a host-contamination error while do_configure of graphviz (meta-oe, hardknott)09:30
JaMaagreed, pity that the overides changes are now spread across many commits (in various layers) so it's not easy to switch back and forth with just overrides changes09:30
kranzoim reading the logs but i cant figure out where the wrong includes are set up09:30
JaMalike including that glibc-2.34 upgrade in my builds was a bad idea as just yesterday I got the images building again09:31
RPJaMa: We probably have changed a few too many things in a short time :/09:31
*** nohit <nohit!> has joined #yocto09:32
mseeberAh, found it, it was not a remove thing but a _forcevariable thing, sorry for the mixup: I had to do a PREFERRED_VERSION_opencv_forcevariable since a 3rd party layer did something with that variable09:32
qschulzah that reminds me I haven't sent the patch for virtclass-multlib-lib32 having a higher precedence than forcevariable09:40
qschulzRP: i postponed it because I was wondering if we just couldn't add forcevariable at the end, when the list of all overrides is made09:41
qschulzthat would probably  be cleaner than removing it and readding it at the end in multilib code09:41
qschulzbut no idea where to look for right now09:42
RPqschulz: I suspect we have a similar issue with other virtclass stuff09:42
* RP would prefer forcevariable went away to be honest09:42
JaMaRP: there is some breakaga from the inactive override fix as well, e.g.
RPqschulz: it is very hard to find the "last" point it would be changed :/09:43
LetoThe2ndRP: <jedivoice>forcevariable, go away</jedivoice>09:43
RPJaMa: right, the timing on that change wasn't great :/09:43
RPequally, I was pretty horrified at that bug :(09:43
LetoThe2ndRP: did it work?09:44
JaMayes, it will be worth it in long term, it's just that unexpanded variable like this was in many cases the incorrect override conversion, except in few cases it's not :)09:44
RPJaMa: right. In hindsight... :/09:45
FulgoI am going to try to build a core-minimal-image in the meantime... and let's see if I get something smaller '=(09:46
qschulzFulgo: try with that first it's a good idea. Then see which packages are pulled in. You know then it's likely coming from conf files09:47
qschulzFulgo: I don't remember if it's the default, but it's possible your kernel is making it in /boot too (in the rootfs most likely), might want to disable that if you ship the kernel separately09:47
qschulzgood luck!09:47
JaMaeventually we might want to unify these a bit as well
Fulgoqschulz yes... but as I mentioned, I have problems knowing where the packets come from, so if I find underired packets I will be in a similar situation. Furthermore, the vendor's image inherits from core-base so, it will not add too many packets I suppose comparing with the minimal09:50
FulgoWell, graphic and sound stuff09:51
FulgoI am becoming a YOCTO packet ripper :(09:51
Fulgo(noob one)09:51
Fulgoqschulz you mean the kernel could be including some packets? I am going to check /boot09:53
FulgoUmh... just the kernel (Image.gz) and the splash09:54
FulgoI will try to remove the splash also XD09:54
*** florian_kc <florian_kc!> has joined #yocto09:55
qschulzFulgo: no, that the kernel is installed in /boot but on embedded systems it might not be needed since it might be flashed on another partition, meaning you can get rid of it in /boot09:55
qschulzall depends on your system09:56
qschulzuse buildhistory before chasing packages, if the package is 100Kb, there's no need to focus your effort on it right now09:56
qschulzand I'm not sure splash will be meaningful in terms of space09:57
Fulgo1.2MB splash09:57
FulgoI think U-BOOT loads it but it is not in a partition. But I am not totally sure about this. UBOOT also gets the dts from there10:00
RPJaMa: there is a lot of cleanup it would be nice to do...10:01
jsandmanRP: back to my 'setscene' issue. I did not make anything out of those stamp files. I did not understand it. However, I was able to generate de eSDK by starting from a fresh tmp directory. I did generate the "full" sdk but now I get the error when installing de eSDK script. It seems the eSDK DOES get installed if I pass in the '-n' (Do not prepare10:01
jsandmanthe build system) option, but then building with devtool seems to recompile every host+target dependency from scratch10:01
RPjsandman: If you use -n, it wouldn't do the checks and those checks are saying it will recompile :/10:03
RPjsandman: if you have an esdk build and a normal build, compare the sstate checksums and try using bitbake-diffsigs on the earlier things in the build you can see that are different10:04
JaMaRP: RDEPENDS:${PN}:remove:class-target = "blacklist-me"10:04
JaMaRDEPENDS:${PN}:class-target += "blacklist-me"10:04
JaManow behaves differently, than before overrides changes10:04
JaMatriggers QA Issue: foo rdepends on blacklist-me, but it isn't a build dependency? [build-deps]10:05
jsandmanOk. I'll try that. THanks10:05
RPJaMa: are you sure that isn't the packagedata issue?10:07
RP(since I think package_qa reads the data using that codepath)10:07
JaMasorry, I thought I already had the packagedata fix included in this build but seems not10:08
JaMaas a work around I've changed the remove to be RDEPENDS:${PN}:class-target:remove which fixed the QA check10:08
JaMayes, that's resolved by packagedata, thanks and sorry for noise10:11
jsandmanRP: It seems I don't have some sigdata files in my nativesdk stamps. If I do `bitbake-diffsigs -t glib-2.0 do_package` I get `ERROR: Only one matching sigdata file found for the specified task (glib-2.0 do_package)`.10:40
RPjsandman: don't trust -t :(10:53
* RP merged that under duress but it simply doesn't work most of the time :(10:53
jsandmanOkey. I'll try the tool without options. No problem. So I only see .sigdata. files under my native stamps but only .sigbasedate. for the nativesdk stamps. Is that expected?10:59
RPjsandman: hard to say without knowing what you've done :/11:01
jsandmanSo I can get an output like this from bitbake-diffsigs comparing the sigdata to sigbasedata:
RPjsandman: I suspect you won't be using nativesdk with eSDK so probably ok11:01
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto11:02
RPjsandman: I think in the eSDK you need to bitbake -S none <target> to get the stamps. I can't remember offhand how you do that in the eSDK though11:03
RPjsandman: you need to compare like with like, e.g. glib-native:do_fetch with glib-native:do_fetch11:03
jsandmanah damn. Sorry I got it all wrong :S . I need to compare ~/my_sdk/tmp/stamps/x86_64-linux/* stuff against ~yocto/build/tmp/stamps /x86_64-linux/* then11:05
RPjsandman: that sounds better11:05
jsandmanokey so it would look something like this for the task that gives me the "pseudo/ failed with exit code 'setscene whitelist'"
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 256 seconds)11:18
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)11:26
*** aleblanc <aleblanc!> has joined #yocto11:35
*** camus <camus!~Instantbi@> has joined #yocto11:53
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)12:08
*** Fulgo <Fulgo!> has quit IRC (Quit: Client closed)12:12
*** aleblanc <aleblanc!> has quit IRC (Ping timeout: 258 seconds)12:19
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 258 seconds)12:22
*** davidinux <davidinux!> has joined #yocto12:24
*** aleblanc <aleblanc!> has joined #yocto12:25
*** goliath <goliath!~goliath@user/goliath> has joined #yocto12:55
*** keepitsimplejim[ <keepitsimplejim[!~keepitsim@2001:470:69fc:105::3630> has quit IRC (Quit: You have been idle for 30+ days)13:02
*** rodrjassoccom[m] <rodrjassoccom[m]!~rodrjasso@2001:470:69fc:105::4019> has quit IRC (Quit: You have been idle for 30+ days)13:02
*** alex88[m] <alex88[m]!~alex88moz@2001:470:69fc:105::ce4> has quit IRC (Quit: You have been idle for 30+ days)13:02
*** AlessandroTaglia <AlessandroTaglia!~al3x88mat@2001:470:69fc:105::ce3> has quit IRC (Quit: You have been idle for 30+ days)13:02
*** xicopitz[m] <xicopitz[m]!~xicopitzm@2001:470:69fc:105::4869> has quit IRC (Quit: You have been idle for 30+ days)13:02
*** asus_986_gpu[m] <asus_986_gpu[m]!~asus986gp@2001:470:69fc:105::1014> has quit IRC (Quit: You have been idle for 30+ days)13:02
*** ndec[m] <ndec[m]!~ndecmatri@2001:470:69fc:105::9c0> has quit IRC (Quit: You have been idle for 30+ days)13:02
*** fabatera[m] <fabatera[m]!~fabateram@2001:470:69fc:105::18d5> has quit IRC (Quit: You have been idle for 30+ days)13:02
*** SnowBeast[m] <SnowBeast[m]!~snowbeast@2001:470:69fc:105::b4c8> has quit IRC (Quit: You have been idle for 30+ days)13:02
*** JonasVautherin[m <JonasVautherin[m!~jonasvaut@2001:470:69fc:105::68d5> has quit IRC (Quit: You have been idle for 30+ days)13:02
*** lacouture[m] <lacouture[m]!~lacouture@2001:470:69fc:105::35b7> has quit IRC (Quit: You have been idle for 30+ days)13:02
*** TrevorWoerner[m] <TrevorWoerner[m]!~trevorwoe@2001:470:69fc:105::4e57> has quit IRC (Quit: You have been idle for 30+ days)13:02
*** boo <boo!> has joined #yocto13:09
*** camus <camus!~Instantbi@> has quit IRC (Quit: camus)13:23
*** vd <vd!> has joined #yocto13:27
vdhi all -- I have FOO[flag] = "${BAR}" but d.getVarFlags('FOO').get('flag') literally equals '${BAR}', not the value of BAR. What do I miss?13:28
*** ndec[m] <ndec[m]!~ndecmatri@2001:470:69fc:105::9c0> has joined #yocto13:29
vdkergoth ^13:29
*** camus <camus!~Instantbi@> has joined #yocto13:31
*** camus <camus!~Instantbi@> has quit IRC (Remote host closed the connection)13:32
qschulzshouldn't it be getVarFlags('FOO', 'flag')?13:35
vdqschulz well I have var = d.getVarFlags('FOO') and a few bar = var.get('flag'), etc. is there a difference?13:37
* qschulz shrugs13:40
qschulzd.getVarFlag('FOO', 'flag') by the way, note the missing s13:41
qschulzotherwise, d.getVarFlags('FOO', expand=True)13:42
qschulzquickly reading the code13:42
RPeverything used to default to no expansion. Now only getVarFlags does, for reasons I don't remember13:46
vdRP: does 'now' includes hardknott?13:48
*** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto13:49
*** roussinm <roussinm!> has joined #yocto13:49
*** CocoJoe <CocoJoe!> has quit IRC (Quit: Client closed)13:54
*** mattsm <mattsm!> has quit IRC (Quit: Ping timeout (120 seconds))13:56
RPvd: yes, happened a while (years) ago13:56
vdRP: does FOO need to be registered somehow or anything to make bitbake aware of it? because I can assure you that my variable isn't expanded13:59
RPvd: see what qschulz said - you need expand=True for getVarFlags13:59
vdRP: ho crap, I misread your previous comment and understood that everything BUT getVarFlags defaults to no expansion...14:02
*** mattsm <mattsm!> has joined #yocto14:03
*** vmeson <vmeson!> has quit IRC (Ping timeout: 252 seconds)14:12
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)14:13
*** sakoman <sakoman!~steve@> has joined #yocto14:13
*** vmeson <vmeson!> has joined #yocto14:17
* RP heads afk for the weekend14:22
vdRP: enjoy o/14:24
*** sakoman <sakoman!~steve@> has quit IRC (Read error: Connection reset by peer)14:24
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)14:26
*** cebrax <cebrax!~cebrax@> has quit IRC (Quit: Client closed)14:27
*** mattsm <mattsm!> has quit IRC (Read error: Connection reset by peer)14:29
*** mattsm <mattsm!> has joined #yocto14:30
*** prabhakarlad <prabhakarlad!> has joined #yocto14:31
*** mseeber <mseeber!> has quit IRC (Ping timeout: 245 seconds)14:31
*** bps <bps!~bps@user/bps> has quit IRC (Remote host closed the connection)14:31
*** bps <bps!> has joined #yocto14:31
*** LetoThe2nd <LetoThe2nd!> has quit IRC (Quit: Connection closed for inactivity)14:42
*** davidinux <davidinux!> has quit IRC (Ping timeout: 240 seconds)14:52
*** davidinux <davidinux!~davidinux@> has joined #yocto14:53
*** amitk_ <amitk_!~amit@> has joined #yocto15:10
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 276 seconds)15:13
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 258 seconds)15:22
vdqschulz: RP: I have "Exception: TypeError: argument of type 'bool' is not iterable" with expand=True15:23
qschulzvd: yeah, broken code15:26
vdqschulz: what do you mean? Is it a known issue?15:27
qschulzno, but I can see where in the code it breaks :15:28
* vd doesn't follow15:28
*** CocoJoe <CocoJoe!> has joined #yocto15:30
qschulzok so I have no idea how this function should be used15:31
qschulzit seems you should pass a list to it15:32
qschulzto expand*15:32
qschulzI guess you want, d.getVarFlags('FOO', expand=['flag'])15:33
*** goliath <goliath!~goliath@user/goliath> has joined #yocto15:35
*** kranzo <kranzo!> has quit IRC (Quit: Client closed)15:56
*** vd <vd!> has quit IRC (Quit: Client closed)15:57
*** BCMM <BCMM!~BCMM@user/bcmm> has quit IRC (Ping timeout: 256 seconds)15:58
*** mckoan is now known as mckoan|away16:07
*** CocoJoe <CocoJoe!> has quit IRC (Quit: Client closed)16:11
*** vd <vd!> has joined #yocto16:16
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 258 seconds)16:18
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:20
*** camus <camus!~Instantbi@2409:8a1e:911e:dbb0:9ddf:805b:fafe:d042> has joined #yocto16:28
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)16:51
*** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto17:11
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)17:29
*** prabhakarlad <prabhakarlad!> has joined #yocto17:56
*** sakoman <sakoman!~steve@> has joined #yocto18:06
*** override <override!> has quit IRC (Ping timeout: 250 seconds)18:10
*** rpcme <rpcme!> has joined #yocto18:15
*** yates_work <yates_work!> has joined #yocto18:18
yates_workwhich part of the bitbake process fills the <build>/tmp/work/<arch>/<pn>/<pr>-r0/build/ folder?18:19
JPEWyates_work: Usually do_configure & do_compile18:21
yates_worki created a new libffi recipe in my layer based on the oe poky/meta/recipes-support/libffi/ recipe but pointing to a later github version, buf that directory is being left empty and thus do_compile is failing18:21
yates_workJPEW: ok18:22
JPEWyates_work: IIRC thats the directory that several of the build tool classes (e.g. cmake, meson, etc.) use for "out of tree builds"18:22
JPEWSo it really depends on what the build system for the recipe is and if it supports out of tree builds18:22
yates_workJPEW: that last statement confuses me. the build system is yocto! ?18:24
JPEWyates_work: The build system for the software the recipe describes (make, autotools, cmake, meson, waf, etc.)18:26
yates_workautotools? "inherit autotools texinfo multilib_header"18:26
JPEWyates_work: Looks like it18:27
yates_workhere's the log.do_configure:
yates_workline 2 is suspicious18:27
JPEWIt's possible the software doens't support out-of-tree builds18:29
yates_workwhat does "out-of-tree" mean in this context?18:29
JPEWIn a separate directory from the source code... e.g. you can do a simple rm -rf of the build directory to clean it without having to touch the source directory18:30
yates_workthe only difference between the original recipe and this one is that the SRC_URI is that it checksout a git repo instead of downloading a tarball.18:31
yates_work"in a separate directory from the source code" - what source code? the kernel?18:33
JPEWThe libffi source code18:33
JPEWyates_work: Looks like it cannot find the configure script: NOTE: nothing to configure18:34
yates_workthe entire libffi source code is provided when the fetch is performed on a git repo, no?18:34
yates_workSRC_URI = "git://;protocol=http;"18:34
yates_workok (re: configure script)18:35
JPEWyates_work: If you use git://, you need to set "S" correctly; usually `S = "${WORKDIR}/git"`18:35
yates_workwell <build>/tmp/work/x86_64-linux/libffi-native/3.4-r0/git is present and filled with what looks like the git repo18:37
JPEWyates_work: yes... but if you check, I'm guess `S` points somewhere else18:37
yates_worklemme check18:38
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 272 seconds)18:42
*** davidinux <davidinux!~davidinux@> has joined #yocto18:43
yates_workthank you, JPEW18:45
yates_workso S specifies where do_configure, etc. gets the source from, not where do_fetch puts it?18:46
JaMado_fetch fetches to DL_DIR, do_unpack unpacks it from DL_DIR to S18:48
JPEWyates_work: Correct. The defaults for each happen to line up with the layout most OSS software uses in source tarballs18:48
JPEWJaMa: For tarballs I think it actually extracts to WORKDIR and relies on the tarball having a top level directory that matches "${PN}-${PV}"18:49
JaMaJPEW: yes, you're right18:50
mischief1is there a way to make a recipe depend on headers from the current kernel rather than the portable uapi headers?18:54
mischief1specifically, we want to use nl80211 headers from vendor kernels (which vary by machine) for e.g. iw and hostapd.18:55
mischief1JPEW: sorry, i misspoke slightly19:00
mischief1we don't use headers from our virtual/kernel19:00
mischief1we need the headers from backports since we have different backports packages for different hardware :-D19:00
mischief1would we need to setup a shared_workdir step for those backports recipes?19:01
JPEWYou just need the kernel headers?19:01
JPEWYou might be able to write a recipe that just has the kernel headers you need and stages it (which would avoid the need for the shared workdir)19:02
mischief1we basically just need include/uapi/linux/nl80211.h that is specific to our backports trees (dont ask me why it ended up this way..)19:04
mischief1JPEW: what does it mean to stage it?19:04
mischief1is that different from just do_install in a recipe?19:04
JPEWmischief1: No19:06
*** LetoThe2nd <LetoThe2nd!> has joined #yocto19:10
*** amitk_ <amitk_!~amit@> has quit IRC (Ping timeout: 240 seconds)19:11
angoliniI'm trying to find some email, patch, note, with some kind of a reason for the override syntax change. Only because I'm writing a blog post and it would be nice to point to some reason from the community... if any. Is there something like that?19:14
*** florian_kc <florian_kc!> has joined #yocto19:16
JPEWangolini: I know there are several email threads about it19:16
angolinigreat! I forget that linkedin exists19:16
angolinithanks a lot19:17
JPEWAh that works!19:17
LetoThe2ndangolini: yw19:18
LetoThe2ndthats why we have a social media person at OE now :)19:19
angoliniand I understood why I could not find that email! Because I was looking in another (several others) mailing lists19:20
JPEWI feel like we need an official Historian19:22
LetoThe2ndJPEW: now that would be awesome from a very nerdy POV19:22
angolinionce upon a time......19:23
JPEW"The Annotated History of OpenEmebedded, Volume I"19:25
LetoThe2ndJPEW: "The Art of wasting perfectly good compute cycles, Fascicle 3-14159"19:26
angoliniI think it must include "the trust" at some point in the title19:26
angolinior "that nobody understands"19:26
JPEW"Appendix A: Git commit messages, 2010-2020"19:27
LetoThe2ndJPEW: +119:27
*** camus <camus!~Instantbi@2409:8a1e:911e:dbb0:9ddf:805b:fafe:d042> has quit IRC (Quit: camus)19:42
*** mranostaj <mranostaj!~mranostaj@> has quit IRC (Ping timeout: 272 seconds)20:13
*** mranostaj <mranostaj!~mranostaj@> has joined #yocto20:25
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 258 seconds)20:34
*** florian_kc is now known as florian20:39
*** florian <florian!> has quit IRC (Ping timeout: 258 seconds)20:59
*** sakoman <sakoman!~steve@> has quit IRC (Read error: Connection reset by peer)21:04
*** aleblanc <aleblanc!> has quit IRC (Ping timeout: 258 seconds)21:17
*** sakoman <sakoman!~steve@> has joined #yocto21:20
*** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has quit IRC (Quit: - Chat comfortably. Anywhere.)21:50
*** u1106 <u1106!~quassel@2a05:d014:58:4b00:bbe8:f33:b5b7:d4f7> has joined #yocto21:53
*** vd <vd!> has quit IRC (Quit: Client closed)21:57
*** roussinm <roussinm!> has quit IRC (Ping timeout: 256 seconds)21:57
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)22:13
*** florian <florian!> has joined #yocto22:15
*** rpcme <rpcme!> has quit IRC (Quit: Client closed)22:16
*** florian <florian!> has quit IRC (Ping timeout: 258 seconds)22:30
boobuild$bitbake -c cleanall perl-native22:59
booERROR: Variable PACKAGECONFIG_append_pn-qemu-system-native contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake.22:59
booNo implicated filename, no pointer to a conversion README....    seems we coulda done better than that.23:00
*** boo is now known as paulg23:01
*** LetoThe2nd <LetoThe2nd!> has quit IRC (Quit: Connection closed for inactivity)23:10
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)23:28
*** JaMa <JaMa!> has quit IRC (Quit: leaving)23:33
*** roussinm <roussinm!> has joined #yocto23:58
*** BCMM <BCMM!~BCMM@user/bcmm> has quit IRC (Ping timeout: 258 seconds)23:59

Generated by 2.17.2 by Marius Gedminas - find it at!