camus has quit [Read error: Connection reset by peer]
camus has joined #yocto
mihai has joined #yocto
jwillikers has quit [Remote host closed the connection]
Tokamak has quit [Ping timeout: 258 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
amitk has joined #yocto
boo has quit [Ping timeout: 258 seconds]
CocoJoe has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
rpcme has quit [Ping timeout: 246 seconds]
vmeson has quit [Ping timeout: 250 seconds]
vmeson has joined #yocto
rob_w has joined #yocto
LetoThe2nd has joined #yocto
sbach has quit [Read error: Connection reset by peer]
mckoan|away is now known as mckoan
sbach has joined #yocto
<mckoan>
good morning
<LetoThe2nd>
yo dudX and mckoans
ant__ has quit [Ping timeout: 240 seconds]
leon-anavi has joined #yocto
vd has quit [Quit: Client closed]
mseeber has joined #yocto
<RP>
Of course as soon as I try and step away for a few days, the overrides bugs start being reported :(
<LetoThe2nd>
RP: 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.
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
mseeber has quit [Quit: mseeber]
mseeber has joined #yocto
prabhakarlad has joined #yocto
<mihai>
yo
* LetoThe2nd
mihai: exactly
<mihai>
:)
kranzo has joined #yocto
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
mranostaj has quit [Remote host closed the connection]
kranzo has left #yocto [#yocto]
mranostaj has joined #yocto
kranzo has joined #yocto
<dv_>
I added INHERIT += "rm_work" in local.conf , and yet, rm_work wasn't executed on the built recipes
zeddii has quit [Ping timeout: 272 seconds]
camus1 has joined #yocto
<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 with
<LetoThe2nd>
dv_: maybe just dump tmp?
<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) ?
goliath has joined #yocto
<dv_>
"dump tmp"?
<LetoThe2nd>
dv_: well, rm -fR your tmp dir. it will be refilled from sstate quickly, and from thereon rm_work will probably be helpful
<dv_>
I need the workdirs of some recipes intact
camus has quit [Ping timeout: 276 seconds]
camus1 is now known as camus
<dv_>
also, this is a workaround - the proper solution is rm_work
<dv_>
ah, ok, misread
zeddii has joined #yocto
<LetoThe2nd>
seriously, 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.
<dv_>
but wait - isn't rm_work supposed to clean up tmp? that's what you'd do by running rm'ing tmp
<dv_>
-running
<dv_>
well, perhaps not all of us have multi-TB SSDs in our machines
<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.
<LetoThe2nd>
neither 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.
<dv_>
either way, rm_work is a must at the moment.
<dv_>
"more disk space" is NOT an option right now.
<LetoThe2nd>
like 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.
<dv_>
but that makes no sense
<dv_>
rm_work is supposed to dump work from tmp!
<LetoThe2nd>
no.
<LetoThe2nd>
rm_work is supposed to clean out after building.
<dv_>
well, "i.e. after all work on the current recipe is done"
<dv_>
so, once the recipe is fully built, rm_work should kick in
zeddii has quit [Ping timeout: 240 seconds]
<dv_>
and I have seen this behavior in the past. but something apparently changed.
<LetoThe2nd>
so 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.
<dv_>
but I did have rm_work included in local.conf right from the start
<dv_>
even before I built anything at all
<dv_>
hm. perhaps a bug?
<LetoThe2nd>
then you'll have to dig deeper what packages eat the space, in which form, and why they're not cleaned.
zeddii has joined #yocto
<LetoThe2nd>
and have you verified that its actually tmp that eats the space, not sstate or downloads?
<dv_>
yea, I did that. it turns out that _none_ of the packages were cleaned up
<dv_>
and yup, its tmp
Guest14 has joined #yocto
Guest14 has quit [Client Quit]
<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>)
<dv_>
and lo and behold, all packages were cleaned up
<LetoThe2nd>
dv_: have you verified the behaviour exists on a raw poky? its very well possible that some layer breaks it.
cebrax has joined #yocto
<LetoThe2nd>
in 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.
<cebrax>
Hello
<kranzo>
Hi 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)
florian has joined #yocto
<dv_>
LetoThe2nd: looks more and more like it ..
<kranzo>
LetoThe2nd actually your livecoding on youtube is pretty enjoyable
<dv_>
oh well, gotta bite that bullet. either way, this is not normal rm_work behavior if I got this right
<LetoThe2nd>
kranzo: 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?
<LetoThe2nd>
dv_: like i said - if you can nail it down to a reproductible description, then we'll (not exactly happily, but hey!)
frieder has joined #yocto
<LetoThe2nd>
treat is as a bug. otherwise, well, what can i say.
<LetoThe2nd>
kranzo: and thanks!
<kranzo>
yes 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.
Fulgo has joined #yocto
Fulgo has quit [Client Quit]
<cebrax>
Does anybody know u-boot-fslc v2020 support LCD IF drivers for iMX6ULL?
<cebrax>
Does anybody know *whether* u-boot-fslc v2020 support LCD IF drivers for iMX6ULL or not?
<LetoThe2nd>
kranzo: yeah we usually go for docker.
<qschulz>
kranzo: been using podman only :)
<LetoThe2nd>
cebrax: why not ask the uboot folks?
<cebrax>
@leto2
<qschulz>
I use pyrex for development and will try to setup a CROPS container for CI
Fulgo has joined #yocto
<kranzo>
qschulz rootless? or not?
<qschulz>
rootless
<cebrax>
LetoThe2nd Thank you! :)
<kranzo>
qschulzill have a look into that, i just manually setup a small minimal image by hand so maybe there is something to tweakk
<cebrax>
LetoThe2nd are you Josef Holzmayr?
<Fulgo>
Hello
<Fulgo>
Please, 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 concepts
<Fulgo>
I 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 complicated
<LetoThe2nd>
cebrax: i actually am :)
frieder has quit [Remote host closed the connection]
<qschulz>
Fulgo: breathe in, breathe out and ask the question :) ALl will be good :)
<Fulgo>
hahaha
<Fulgo>
Well, I will start slow :D
<qschulz>
one question at a time, try to provide enough context but not too much and think about XY problem
<LetoThe2nd>
Fulgo: 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.
<Fulgo>
First, 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't
<cebrax>
LetoThe2nd wow! I really appreciate GREAT videos you are making, thank you!
<Fulgo>
Thanks, all
<LetoThe2nd>
cebrax: thank! :)
<Fulgo>
This is just a doubt, because trying to trim the image provided by the vendor is when the problems arise XD
<Fulgo>
Maybe that question is... very basic but I was expecting to find something like "ext3", and I just saw something like this in DISTRO_FEATURES
<cebrax>
I 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 :'(
<qschulz>
Fulgo: 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 vol
<qschulz>
ubi images can have multiple ubifs volumes, etc...
<qschulz>
Fulgo: how did you check the content of IMAGE_FSTYPES?
<LetoThe2nd>
cebrax: 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.
<Fulgo>
Yes, I understand a wic image could have multiple partitions. In fact I found the following: IMAGE_FSTYPES="tar.gz wic.gz"
<qschulz>
cebrax: 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 Yocto
<qschulz>
Fulgo: there you go :)
<LetoThe2nd>
cebrax: 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.
<qschulz>
Fulgo: to know what's inside the wic, you need to find the wks file that is used for your custom image
<Fulgo>
Umh... 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 resources
<Fulgo>
And paying without any certainty of getting what I want... is not an option I guess
<LetoThe2nd>
cebrax: 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.
<cebrax>
qschulz 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?
<Fulgo>
I have all of them working. The vendor provided a HUGE image, and I want to trim it (reduce it to only what I need)
<LetoThe2nd>
Fulgo: and, "trimming" an image is usually not a good way. start small and then add whatever you need.
<Fulgo>
The 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 interesting
<Fulgo>
Umh... 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 image.bb and removed all the undesired packets
<Fulgo>
I 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)
<Fulgo>
LetoThe2nd thanks for the training materials
<LetoThe2nd>
yeah, 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?
<Fulgo>
I was in YoctoProject: Youtube and website resources
<qschulz>
Fulgo: next step is to enable buildhistory and investigate which packages are making your rootfs grow too much and those you can afford to remove
<Fulgo>
yes...
<cebrax>
LetoThe2nd 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..
<Fulgo>
This 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 minimum
<Fulgo>
Maybe is not possible but I have to try
<qschulz>
cebrax: why do you want LCD support in U-Boot?
<LetoThe2nd>
cebrax: happens, that. for the u-boot case: take it out of yocto, make it work alone. then reintegrate.
<qschulz>
Fulgo: you want a 4MB rootfs???
<cebrax>
LetoThe2nd Oh, by the way I didn't imply you to make a video on it, reading it again, sorry my sentence feels like that :D
<Fulgo>
No. 4MB everythin.
<qschulz>
Fulgo: lol
<Fulgo>
Kernel, rootfs, devicetree... everything
<LetoThe2nd>
Fulgo: 4MB is outright illusory unless you invest quite some effort.
<Fulgo>
That is what I said
<LetoThe2nd>
Fulgo: and with a recent kernel, moreso.
<qschulz>
LetoThe2nd: "quite some effort" is a BIG understatement
<LetoThe2nd>
qschulz: definitions of "quite some" tend to vary, traditionally.
<cebrax>
qschulz Because I want to display a boot logo before linux can show one, as it takes 6-7 secs
<LetoThe2nd>
cebrax: 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.
<Fulgo>
The point is that they use very slow interfaces to update the distribution (serial comms) and the smaller the better
<qschulz>
cebrax: 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 :) )
<LetoThe2nd>
Fulgo: depending on the hw and everything, it can be possible. for a beginner? hardl.y
<qschulz>
Fulgo: if it's an update speed issue and not a storage limitation, that's a different thing
<LetoThe2nd>
Fulgo: if you really, really need such, then you better hire somebody.
<LetoThe2nd>
Fulgo: and as qschulz says: if its only to mitigate update times, then its actually a XY problem and should be solved differently.
<qschulz>
because I guess you could do some binary diff update or whatever it's called to avoid uploading the whole image?
<Fulgo>
Well, I am noob in YOCTO, but it always a time to learn :(
<Fulgo>
I put effort not to fail, but if you consider it is impossible...
<qschulz>
but yeah, more than a few MB via serial comms is almost a deal breaker, I understand
<LetoThe2nd>
Fulgo: there is a reason why size reduction is a common topic in linux trainings.
<cebrax>
qschulz 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 :D
<Fulgo>
LetoThe2nd differently? If I have a huge image, I need to reduce it to update YOCTO image
<qschulz>
Fulgo: 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 is
<Fulgo>
patches are painful to handle
<LetoThe2nd>
Fulgo: 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"
<Fulgo>
I used years ago something with bsdiff and dealing with the patches was a real challenge
<qschulz>
difficult in terms of time spent and various SW components to be modified and still have a working build
<LetoThe2nd>
Fulgo: look up current OTA solutions.
<Fulgo>
No, no. Well, they are saying 4MB because they want to put some preassure
<cebrax>
Actually this is the first time I interact with embedded linux, here is my first board, when I saw RAM test passed, I almost cried :)
<qschulz>
Fulgo: is there really no other way that serial comms to update your thing?
<cebrax>
#u-boot channel is filled with cricket sounds I guess.. Does anybody know any other places I can talk with u-boot guys?
<Fulgo>
Yes, but the project requires a good performance for the legacy interfaces
<qschulz>
LetoThe2nd: yes but you would need to update very often to make sure the diff is as small as possible
<cebrax>
LetoThe2nd thank you!
<Fulgo>
With ETH there are no problems at all
<qschulz>
cebrax: on libera?
<cebrax>
Yes, also freenode
<Fulgo>
We expect not to need any update, but they want to have all the means available
<qschulz>
Fulgo: seems like a marketing issue :)
camus1 has joined #yocto
<qschulz>
cebrax: there's one issue with your question, you're asking about a vendor fork of u-boot in an upstream channel :)
<LetoThe2nd>
cebrax: 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.
camus has quit [Ping timeout: 258 seconds]
camus1 is now known as camus
<LetoThe2nd>
cebrax: like i said: board bringup is hard work.
<qschulz>
cebrax: that lowers the chance to have people interested in your problem :)
<Fulgo>
hahaha yes... you know, the commercials are tough people
<cebrax>
Oh, that was what I felt, and hearing it from you guys made it official for me I guess :(
<qschulz>
Fulgo: and sometmes they need someone to say what they want is not reasonable or impossible :)
<Fulgo>
Yes, I am doing it. But I understand that I need to struggle a bit
<cebrax>
LetoThe2nd Yeah, that's what I've been doing for a week now.. I guess I need to work a lot more harder
<Fulgo>
I do not give up easily
<qschulz>
Fulgo: 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 possible
<Fulgo>
At least have some basis to defend if it is or not possible
<Fulgo>
qschulz I agree with you. But when they ask me why, I have to give an explanation XD
<Fulgo>
I cannot say... well, I tried a lot
<Fulgo>
The kernel itself is 6MB, so they know that 4MB is not possible
<qschulz>
Fulgo: well, sometimes the skills you have at one point in time is not enough to do something.
<Fulgo>
Now, I have to know if I can reduce these 100MB
<Fulgo>
qschulz 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 future
<Fulgo>
qschulz I am going to check those
<qschulz>
have it much smaller than 100MB is surely possible, it all depends what you REALLY need in your system
<LetoThe2nd>
qschulz: chromium!
<qschulz>
you'll need to play with PACKAGECONFIG, split packages in more packages, NO_RECOMMENDATIONS is also a good start
<qschulz>
don't forget to look into the distro and machine configuration files, sometimes useless stuff is added there, especially in vendor BSPs
<qschulz>
LetoThe2nd: ?
<cebrax>
qschulz lol that's a funny name, NO_RECOMMENDATIONS
<Fulgo>
qschulz what is NO_RECOMMENDATIONS?
<LetoThe2nd>
qschulz: "it all depends what you REALLY need in your system" -> chromium!
<LetoThe2nd>
Fulgo: not giving beer to me is NOT_RECOMMENDED, for example
<qschulz>
LetoThe2nd: LIES, I wanted to send you some you refused
<LetoThe2nd>
qschulz: shhhhht!
<qschulz>
con man
<Fulgo>
qschulz 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 added
<LetoThe2nd>
qschulz: how dare you demolish my beer-based PR campaigning?!?
<qschulz>
Fulgo: bitbake -e will help you, don't use grep since you want the history of the variable
<Fulgo>
I tried even to use bitable -g but dot takes incountable hours to generate the graph... Maybe I am doing something wrong
<Fulgo>
Yes, It is what I did
<Fulgo>
bitbake -e fsl-image-ngc | grep "^DISTRO"
<qschulz>
Fulgo: no, don't use dot, just read with your text editor
<Fulgo>
bitbake -e fsl-image-ngc | grep "^IMAGE"
<qschulz>
Fulgo: "don't use grep" I just said :)
<Fulgo>
qschulz ok ok
<Fulgo>
no??? It is huge then XD
<qschulz>
go to the line starting with IMAGE and look above
<Fulgo>
May python functions and others
<Fulgo>
Ok
<qschulz>
Fulgo: redirect to a file or less and search for the line
<qschulz>
then read above
<Fulgo>
It is not easy for me to trace in YOCTO
<qschulz>
trace?
<Fulgo>
bitbake -e fsl-image-ngc > test.txt
<Fulgo>
done
<Fulgo>
Well, trace or know who added the packed to the rootfs
<Fulgo>
maybe trace is not the verb
<qschulz>
Fulgo: 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...
<qschulz>
Fulgo: I recommend builhistory again, at least you know which packages should be nuked first
<Fulgo>
The 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?
<qschulz>
Fulgo: no, you should avoid _remove as much as possible
<qschulz>
you 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)
<qschulz>
you probably want to write your own distro conf too
<mseeber>
i got burned by _remove in the past. turned out variables can be configured (by vendors) in a way that they ignore a _remove
<qschulz>
(and probably switch from systemd to sysv for example)
<Fulgo>
umh.. 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 that
<qschulz>
Fulgo: 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)
<qschulz>
Fulgo: I suspect fuckery in your vendor BSP layer :)
<Fulgo>
But I understand that if the distro adds the undesired packets... there will not be other way
<Fulgo>
Maybe XD
<Fulgo>
IT IS A TRAP!
<Fulgo>
I basically cloned wayland distro conf file, and removed x11
<JaMa>
RP: 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)
<Fulgo>
But once I used bitbake with the new distro... everything exploded
<qschulz>
Fulgo: 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 need
<mseeber>
LetoThe2nd: thanks, that would have worke, but at that time i had a different problem, i am going to look it up in my notes
<Fulgo>
I do not need vendor's layer?
<Fulgo>
machine configuration, patches and others?
<RP>
JaMa: As that fix shows, there are some gremlins left we need to find and work out...
<kranzo>
maybe i'll go back to my initial problem first: i'll get a host-contamination error while do_configure of graphviz (meta-oe, hardknott)
<JaMa>
agreed, 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 changes
<kranzo>
im reading the logs but i cant figure out where the wrong includes are set up
<JaMa>
like including that glibc-2.34 upgrade in my builds was a bad idea as just yesterday I got the images building again
<RP>
JaMa: We probably have changed a few too many things in a short time :/
nohit has joined #yocto
<mseeber>
Ah, 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 variable
<qschulz>
ah that reminds me I haven't sent the patch for virtclass-multlib-lib32 having a higher precedence than forcevariable
<qschulz>
RP: i postponed it because I was wondering if we just couldn't add forcevariable at the end, when the list of all overrides is made
<qschulz>
that would probably be cleaner than removing it and readding it at the end in multilib code
<qschulz>
but no idea where to look for right now
<RP>
qschulz: I suspect we have a similar issue with other virtclass stuff
* RP
would prefer forcevariable went away to be honest
<RP>
qschulz: it is very hard to find the "last" point it would be changed :/
<LetoThe2nd>
RP: <jedivoice>forcevariable, go away</jedivoice>
<RP>
JaMa: right, the timing on that change wasn't great :/
<RP>
equally, I was pretty horrified at that bug :(
<LetoThe2nd>
RP: did it work?
<JaMa>
yes, 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 :)
<RP>
JaMa: right. In hindsight... :/
<Fulgo>
I am going to try to build a core-minimal-image in the meantime... and let's see if I get something smaller '=(
<qschulz>
Fulgo: 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 files
<qschulz>
Fulgo: 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 separately
<Fulgo>
qschulz 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 minimal
<Fulgo>
Well, graphic and sound stuff
<Fulgo>
I am becoming a YOCTO packet ripper :(
<Fulgo>
(noob one)
<Fulgo>
qschulz you mean the kernel could be including some packets? I am going to check /boot
<Fulgo>
Umh... just the kernel (Image.gz) and the splash
<Fulgo>
I will try to remove the splash also XD
florian_kc has joined #yocto
<qschulz>
Fulgo: 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 /boot
<qschulz>
all depends on your system
<qschulz>
use buildhistory before chasing packages, if the package is 100Kb, there's no need to focus your effort on it right now
<qschulz>
and I'm not sure splash will be meaningful in terms of space
<Fulgo>
1.2MB splash
<Fulgo>
I 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 there
<RP>
JaMa: there is a lot of cleanup it would be nice to do...
<jsandman>
RP: 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 prepare
<jsandman>
the build system) option, but then building with devtool seems to recompile every host+target dependency from scratch
<RP>
jsandman: If you use -n, it wouldn't do the checks and those checks are saying it will recompile :/
<RP>
jsandman: 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 different
<JaMa>
now behaves differently, than before overrides changes
<JaMa>
triggers QA Issue: foo rdepends on blacklist-me, but it isn't a build dependency? [build-deps]
<jsandman>
Ok. I'll try that. THanks
<RP>
JaMa: are you sure that isn't the packagedata issue?
<RP>
(since I think package_qa reads the data using that codepath)
<JaMa>
sorry, I thought I already had the packagedata fix included in this build but seems not
<JaMa>
as a work around I've changed the remove to be RDEPENDS:${PN}:class-target:remove which fixed the QA check
<JaMa>
yes, that's resolved by packagedata, thanks and sorry for noise
<jsandman>
RP: 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)`.
<RP>
jsandman: don't trust -t :(
* RP
merged that under duress but it simply doesn't work most of the time :(
<jsandman>
Okey. 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?
<RP>
jsandman: hard to say without knowing what you've done :/
<jsandman>
So I can get an output like this from bitbake-diffsigs comparing the sigdata to sigbasedata: https://paste.debian.net/1206760/
<RP>
jsandman: I suspect you won't be using nativesdk with eSDK so probably ok
jwillikers has joined #yocto
<RP>
jsandman: 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 though
<RP>
jsandman: you need to compare like with like, e.g. glib-native:do_fetch with glib-native:do_fetch
<jsandman>
ah 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/* then
<RP>
jsandman: that sounds better
<jsandman>
okey so it would look something like this for the task that gives me the "pseudo/pseudo_git.bb:do_fetch) failed with exit code 'setscene whitelist'" https://paste.debian.net/1206761/
camus has quit [Ping timeout: 256 seconds]
rob_w has quit [Remote host closed the connection]
aleblanc has joined #yocto
camus has joined #yocto
goliath has quit [Quit: SIGSEGV]
Fulgo has quit [Quit: Client closed]
aleblanc has quit [Ping timeout: 258 seconds]
davidinux has quit [Ping timeout: 258 seconds]
davidinux has joined #yocto
aleblanc has joined #yocto
goliath has joined #yocto
keepitsimplejim[ has quit [Quit: You have been idle for 30+ days]
rodrjassoccom[m] has quit [Quit: You have been idle for 30+ days]
alex88[m] has quit [Quit: You have been idle for 30+ days]
AlessandroTaglia has quit [Quit: You have been idle for 30+ days]
xicopitz[m] has quit [Quit: You have been idle for 30+ days]
asus_986_gpu[m] has quit [Quit: You have been idle for 30+ days]
ndec[m] has quit [Quit: You have been idle for 30+ days]
fabatera[m] has quit [Quit: You have been idle for 30+ days]
JonasVautherin[m has quit [Quit: You have been idle for 30+ days]
SnowBeast[m] has quit [Quit: You have been idle for 30+ days]
lacouture[m] has quit [Quit: You have been idle for 30+ days]
TrevorWoerner[m] has quit [Quit: You have been idle for 30+ days]
boo has joined #yocto
camus has quit [Quit: camus]
vd has joined #yocto
<vd>
hi all -- I have FOO[flag] = "${BAR}" but d.getVarFlags('FOO').get('flag') literally equals '${BAR}', not the value of BAR. What do I miss?
ndec[m] has joined #yocto
<vd>
kergoth ^
camus has joined #yocto
camus has quit [Remote host closed the connection]
<qschulz>
shouldn't it be getVarFlags('FOO', 'flag')?
<vd>
qschulz well I have var = d.getVarFlags('FOO') and a few bar = var.get('flag'), etc. is there a difference?
* qschulz
shrugs
<qschulz>
d.getVarFlag('FOO', 'flag') by the way, note the missing s
<qschulz>
I guess you want, d.getVarFlags('FOO', expand=['flag'])
goliath has joined #yocto
kranzo has quit [Quit: Client closed]
vd has quit [Quit: Client closed]
BCMM has quit [Ping timeout: 256 seconds]
mckoan is now known as mckoan|away
CocoJoe has quit [Quit: Client closed]
vd has joined #yocto
florian_kc has quit [Ping timeout: 258 seconds]
florian has quit [Quit: Ex-Chat]
camus has joined #yocto
leon-anavi has quit [Quit: Leaving]
BCMM has joined #yocto
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
sakoman has joined #yocto
override has quit [Ping timeout: 250 seconds]
rpcme has joined #yocto
yates_work has joined #yocto
<yates_work>
which part of the bitbake process fills the <build>/tmp/work/<arch>/<pn>/<pr>-r0/build/ folder?
<JPEW>
yates_work: Usually do_configure & do_compile
<yates_work>
i created a new libffi recipe in my layer based on the oe poky/meta/recipes-support/libffi/libffi_3.3.bb recipe but pointing to a later github version, buf that directory is being left empty and thus do_compile is failing
<yates_work>
JPEW: ok
<JPEW>
yates_work: IIRC thats the directory that several of the build tool classes (e.g. cmake, meson, etc.) use for "out of tree builds"
<JPEW>
So it really depends on what the build system for the recipe is and if it supports out of tree builds
<yates_work>
JPEW: that last statement confuses me. the build system is yocto! ?
<JPEW>
yates_work: The build system for the software the recipe describes (make, autotools, cmake, meson, waf, etc.)
<JPEW>
It's possible the software doens't support out-of-tree builds
<yates_work>
what does "out-of-tree" mean in this context?
<JPEW>
In 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 directory
<yates_work>
the 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.
<yates_work>
"in a separate directory from the source code" - what source code? the kernel?
<JPEW>
The libffi source code
<JPEW>
yates_work: Looks like it cannot find the configure script: NOTE: nothing to configure
<yates_work>
the entire libffi source code is provided when the fetch is performed on a git repo, no?
<mischief1>
we don't use headers from our virtual/kernel
<mischief1>
we need the headers from backports since we have different backports packages for different hardware :-D
<mischief1>
would we need to setup a shared_workdir step for those backports recipes?
<JPEW>
You just need the kernel headers?
<JPEW>
You 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)
<mischief1>
we basically just need include/uapi/linux/nl80211.h that is specific to our backports trees (dont ask me why it ended up this way..)
<mischief1>
JPEW: what does it mean to stage it?
<mischief1>
is that different from just do_install in a recipe?
<JPEW>
mischief1: No
LetoThe2nd has joined #yocto
amitk_ has quit [Ping timeout: 240 seconds]
<angolini>
I'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?
<boo>
ERROR: 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.
<boo>
No implicated filename, no pointer to a conversion README.... seems we coulda done better than that.
boo is now known as paulg
LetoThe2nd has quit [Quit: Connection closed for inactivity]