qschulz has quit [Remote host closed the connection]
Tokamak has quit [Ping timeout: 255 seconds]
qschulz has joined #yocto
<override>
the filesystem layout that wic creates, I can just dd that onto my emmc??
robbawebba has quit [Quit: WeeChat 3.0.1]
jwillikers has quit [Remote host closed the connection]
Tokamak has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 268 seconds]
steve__ has quit [Ping timeout: 255 seconds]
prabhakarlad has quit [Quit: Client closed]
sakoman has quit [Quit: Leaving.]
camus1 has joined #yocto
camus has quit [Ping timeout: 252 seconds]
camus1 is now known as camus
Tokamak has quit [Ping timeout: 258 seconds]
Lihis has quit [Quit: Quitting]
paulg has quit [Ping timeout: 265 seconds]
Lihis has joined #yocto
vmeson has quit [Ping timeout: 258 seconds]
vmeson has joined #yocto
Lihis has quit [Ping timeout: 246 seconds]
Lihis has joined #yocto
eFfeM has joined #yocto
eFfeM has quit [Remote host closed the connection]
ecdhe has quit [Read error: Connection reset by peer]
ecdhe has joined #yocto
ant__ has quit [Ping timeout: 255 seconds]
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
roussinm has quit [Ping timeout: 252 seconds]
frieder has joined #yocto
goliath has joined #yocto
zyga has joined #yocto
zpfvo has joined #yocto
Net147 has quit [Ping timeout: 268 seconds]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
prabhakarlad has joined #yocto
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
xmn has quit [Quit: ZZZzzz…]
tnovotny has joined #yocto
camus has quit [Ping timeout: 255 seconds]
camus has joined #yocto
leon-anavi has joined #yocto
xmn has joined #yocto
LetoThe2nd has joined #yocto
<LetoThe2nd>
yo dudx
xmn has quit [Remote host closed the connection]
hpsy has joined #yocto
<mihai>
yo
florian has joined #yocto
vd has quit [Quit: Client closed]
wing0_ has joined #yocto
wing0_ has quit [Client Quit]
wing0 has joined #yocto
wing0 has quit [Client Quit]
florian_kc has joined #yocto
wing0 has joined #yocto
florian_kc has quit [Ping timeout: 258 seconds]
wing0 has quit [Client Quit]
creich has quit [Remote host closed the connection]
zyga-mbp has joined #yocto
hpsy has quit [Remote host closed the connection]
<rburton>
override: depends on what wic file you used, what your target is, and what the medium is, but that's the intention yes
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
tnovotny has quit [Read error: Connection reset by peer]
tnovotny_ has joined #yocto
linums has joined #yocto
creich has joined #yocto
<wyre>
do you recommend to do a different recipe for a systemd application?
<wyre>
I mean, for a systemd service of an application?
<mckoan>
wyre: as the YoctoJester chants "it depends"
<rburton>
wyre: in the application recipe would make a lot of sense
<rburton>
so you can't have one without the other
* LetoThe2nd
shuffles off into lunch break, humming "ebony and ivory"...
* LetoThe2nd
ponders throwing something really sharp and pointy rburtons way
<wyre>
also I'm trying to create a recipe for a python module so ... I should install it in /usr/lib/python3.7/site-packages, but could I do this directly?
<rburton>
wyre: does the module support distutils/setup.py?
<rburton>
is it on pypi already?
<wyre>
nope, it's not on pypi
<wyre>
and it won't be in there unfortunately
<wyre>
it's a local module
<rburton>
assuming it's sensible and uses setup.py then just use distutils3.bbclass
<OutBackDingo>
anyone knows what branch/release gcc 9 was last in ? dunfell ?
<OutBackDingo>
seems its dunfell
<wyre>
rburton, could you provide me some example?
<wyre>
I mena, I've done the setup.py, how should I use distutils3 ?
<wyre>
in the recipe?
<wyre>
I mena, I'd appreciate some example to create my recipe
<OutBackDingo>
ok, so did something change in guthub ? alot of fetches failing, no master branches, now main ?
dvorkindmitry has quit [Ping timeout: 268 seconds]
dvorkindmitry has joined #yocto
lukma has quit [Quit: leaving]
lukma has joined #yocto
jwillikers has joined #yocto
<wyre>
why it says it cannot find setup.py when it's in the workdir? https://bpa.st/ARSQ rburton
<wyre>
setup.py is in the working directory, so ... why it cannot found it?
<rburton>
wyre: you didn't set S and you're fetching from git?
<rburton>
easier for you to debug than me, that log tells you what S *is*, and you can see what it actually unpacked too, not me
<wyre>
the log contains the very same I've just pasted
<wyre>
and I can't see there what S is
<rburton>
ls tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/python3-dp1642gw-api/1.0-r0/dp1642gw-dev/ <-- that is not what you set as S
<wyre>
however, in the recipe I'm setting S as ${WORKDIR}
<rburton>
the unpacker is mirroring the local file structure
<rburton>
your local files are in a directory so it copies the structure
<rburton>
and if your setup.py installs properly then you can just get rid of most of that install_append
<wyre>
rburton, apparently the setup.py is working but it generates an .egg file
<wyre>
so I cannot see what's actually installing
* LetoThe2nd
bites keyboard
<LetoThe2nd>
must... not... type... pun....
thekappe has quit [Quit: WeeChat 1.9.1]
woky has quit [Quit: Nothing in this world is hopeless!]
hpsy has joined #yocto
<rburton>
wyre: a properly written setup.py will install properly anyway, as the class tells it to
<override>
Can we only dd a disk image, or can we dd just the rootfs as well? To further elaborate what I'm trying to figure: The disk layout shown here https://github.com/Freescale/meta-freescale/blob/master/wic/imx-imx-boot-bootpart.wks.in, lets say I ive added another blocks of rootfs to it. Any updates to my board's rootfs, Id try to write to this additional rootfs partition I added. Im trying to see if thats
<override>
even possible. Can we dd a rootfs (an ext4 file), or does it have to be a complete wic image. If its the latter, then on my emmc would the two partitions look something like this |{imx-boot boot rootfs}| |{imx-boot boot rootfs}|?
<rburton>
with ext4 in IMAGE_FSTYPES you get just a bare ext4 if that's what you want
<rburton>
you could manually dd that into the right partition
zyga_ has joined #yocto
<dv_>
I've seen command lines that try to set the build's nice level by calling "nice bitbake", and other setups that use BB_TASK_NICE_LEVEL in local.conf instead
<dv_>
it is my impression that the second approach is better, but I don't know the details
<dv_>
anybody knows more?
zyga-mbp has quit [Ping timeout: 265 seconds]
zyga has quit [Ping timeout: 256 seconds]
<override>
rburton: that's partly what's confusing me right now. I was given the impression that complete disk images are wis. when I set IMAGE_FSTYPES to ext4 id get a complete disk image in ext4 format some how? It would include everything {imx-boot boot rootfs}, and not just the rootfs? why's ext4 usually just associated with root file systems then? why can IMAGE_FSTYPES be set to wic, when wic is considered to
<override>
be a disk image?
zyga_ has quit [Ping timeout: 268 seconds]
<rburton>
if you set image fstypes to ext4 then the image you ask for is put in an ext4 file system. a wic takes the root filesystem (when its just a directory) and makes partition tables, pulls in other files such as bootloaders, etc.
<rburton>
a ext4 isn't a disk image, its just a partition
zyga-mbp has joined #yocto
woky has joined #yocto
<override>
rburton: so let me ask you this why are we able to set IMAGE_FSTYPES to wic or ext4 when only ext4 is an file system type and not wic?
<rburton>
wic is a tool that takes instruction (the wks file) to build a disk image from root filesystems
<rburton>
the main root filesystem being the image you built in the first place
<JPEW>
override: you have 2 separate cases: first you need to create the initial flash image with two partitions, for which wic is an option. Second, you need to update one of the partitions, which you can do by dd'ing the ext4 image into the partition
<override>
rburton: feel free to link me some stackoverflow or something if you feel like im just going around in circles. Would it be correct to say that when we set IMAGE_FSTYPE to ext4 we wont really get a disk image at all? we are just getting a partition with the file system in it?
<override>
JPEW: Im losing my mind here just understanding why is that we call a partition with the ext4 rootfs an image? like you just said the "ext4 image into the partition", wouldnt that just be the rootfs and not the entire disk image???
jwillikers has quit [Remote host closed the connection]
<rburton>
yes, IMAGE_FSTYPES never promised to be a "disk image"
<rburton>
input is an image, which is a filesystem tree on disk. output is... something.
<rburton>
set IMAGE_FSTTYPES to tar.gz and you get a tarball
zyga-mbp has quit [Ping timeout: 255 seconds]
<rburton>
ext4 and you get a ext4 file system on disk which contains that tree
<rburton>
wic will invoke the wic tool which uses the kickstart file you specify to do further operations, like making a partition tables, pulling in a bootloader, etc
<rburton>
the problem is that 'image' is a somewhat overloaded term
<rburton>
a full disk image includes the partition table, which obviously isn't part of an ext4
<override>
thanks for patiently explaining me all this, think I get it now.
<rburton>
basically, do_image is input: directory tree as defined by the image recipe, output: whatever you tell it in IMAGE_FSTYPES
<rburton>
you can do anything in an image fstype: ext4.md5 will write a md5 checksum file for your ext4
<rburton>
--ptable msdos says to create a classic doc partition table
<rburton>
anoyingly thats not in the docs
<override>
im guessing its a thing to have no partition table at all? I dont see any --ptable msdos in the wks in looking at. Ive definitely come across that term in my bed time reading on file systems, wic, and all things related..
<override>
maybe --no-table means no partition table?
<rburton>
yeah
<override>
is the partition table usually defined in the u-boot partition?
<rburton>
how can the partition table be defined inside a partition? :)
<rburton>
i believe what that imx one is doing is putting the uboot at the beginning of the disk, then a partition table and the partitions
<override>
what do you even call that contraption that has the partion table
<override>
if its not a partition
<rburton>
its just a bit of the disk
<override>
rburton: thanks youve been immensely helpful this morning
<override>
JPEW: so I didnt have my logs turned on till this morning, and you prolly told me this before, but can you link me to some wks that creates an initial flash image with two partitions?
<JPEW>
override: I don't have an example of that, sorry
<override>
we would call those two partions rootfs im thinking?
<override>
swap out the rootfs and youd get all the new python modules and stuff?
<JPEW>
override: I think so. If you play around with the wks file for a while I think you can get it figured out
<override>
I just wana get my ducks in a row before I start playing around. With the chip shortage going on my entire company's only got a handful of these eval kits from toradex. If I brick it, I wont hear the end of it.
<JPEW>
override: Will it boot from an SD card?
<override>
for now I could have it boot from an sd card even
<override>
for like a POC thing
<JPEW>
override: That's what I would do until you have the bootloader working
<override>
eventually, i think what I want to do is set eveything up on sd card then dd it to the eMMC on the board
<JPEW>
override: Yep, that's what we do on our factory assembly line
<qschulz>
override: I believe most iMX SoCs have a USB boot mode via USB OTG and the uuu tool when there's nothing on any boot storage media
<qschulz>
I've seen that on i.mx6, 7 and 8
<qschulz>
and since it boots via something uploaded to volatile memory, no risk of bricking it
_franck_ has joined #yocto
<angolini>
I don't think you will get to brick a toradex board only by copying images to the emmc or sdcard. And yes, uuu is always an alternative
<override>
yeah, ive used the uuu. the uuu thing was what got me doing this a/b scheme for updating stuff to beging with (I will use it later to for in field updates and all) the uuu just doesnt work on macs, so Im doing this now..
<override>
but yeah, its good to know I wont brick anything
<angolini>
I don't know which toradex board you're using, but probably it can be used with uuu
<override>
im using the verdin, so yeah im familiar with uuu and all
<angolini>
we used to have a sdcard image type on meta-freescale... I mean, on the past
<angolini>
maybe this is something you want to play with
<angolini>
it was a bbclass
<override>
you got a link for its wks? I can checkout the meta-freescale repo too
<override>
Thanks for the help guys. I better take the plunge now and just start trying out different wks files i guess
<_franck_>
hi, I'm using "devtool modify" to work on a project. I can build the recipe with "devtool build $MYPROJECT". However, when I build my image, it seems like it uses the other recipe (the original one, not in /workspace) and do_populate_lic crashes
<_franck_>
do I miss a step ?
<override>
_franck_ do a bitbake reset <recipe> on the one you dont want no more?
<_franck_>
it will reset the one not in ./workspace ?
<override>
should reset whereever the recipe you give it is at I think?!
<_franck_>
is "bitbake reset" a thing ?
<override>
think its devtool reset
<override>
and not bitbake, sorry.
<qschulz>
angolini: sdcard images were replaced by wic in most cases IIRRC
<qschulz>
_franck_: look at the layer priority of the layer holding the original recipe and devtool's
<qschulz>
bitbake-layers show-layers or something like that should give you the info you want
<_franck_>
qschulz: sounds good, let me see
<_franck_>
workspace is at the very end of the list
<_franck_>
nedd to find how to change that
<qschulz>
_franck_: it does not matter much, the layer priority (it's a variable in layer.conf) matters first
<qschulz>
then among layers of the same priority, the order in which they are listed in BBLAYERS in bblayers.conf matters
<_franck_>
ah yes, the number at the end of each lines. workspace = 99
<qschulz>
then it should have priority
<qschulz>
I think youmight find interesting log if you do bitbake -DDD <recipe>
<qschulz>
and then check the reasons why a recipe was taken and not the other
<qschulz>
but it seems like something broken in your layers/devtool becauyse devtool modify basically just creates a bbappend for the original recipe
<_franck_>
ok thanks you, I'll dig this up and come back
<qschulz>
so except if the bbappend is ignored for some reason, or its content overriden from another bbappend (which is unlikely because its priority is 99, probably the highest of all yours)
<qschulz>
I don't see why it wouldn't be used
<qschulz>
can you tell us exactly what you're seeing and what makes you think bitbake isn'
<qschulz>
t using the devtool'ed recipe?
<_franck_>
I'll try with -DDD
paulg has joined #yocto
<_franck_>
it parses the main bb file -> OK, it appends the .bbappend file -> OK then it does do_populate_lic from the build dir, from a directory that doesn't exist: WARNING: kernel-module-esp32sdio-0.1-r0 do_populate_lic: Could not copy license file ..../kernel-module-esp32sdio/0.1-r0/git/....
<_franck_>
I don't have this git directory
<angolini>
yes, @qschulz, a long time ago
<smurray>
RP JPEW: I need a bigger build machine, oom killer kicked in overnight when I tried generating load with oe-selftest -j 4 ;)
rcw has joined #yocto
<paulbarker>
smurray: That's exactly what happened to me. On my machine running oe-selftest with parallelism munched through 64GB RAM, 8GB swap and then died
Tokamak has joined #yocto
<smurray>
paulbarker: it looks like I have enough swap to get through with -j 2, but it takes quite a while
roussinm has joined #yocto
Tokamak has quit [Read error: Connection reset by peer]
Tokamak has joined #yocto
ecdhe has quit [Ping timeout: 258 seconds]
ecdhe has joined #yocto
<paulg>
did the oom killer identify something with an unreasonable RSS, or did it do the usual circular firing squad thing?
* paulg
has no idea what lives inside oe-selftest.
sakoman has joined #yocto
zyga has joined #yocto
<paulg>
speaking of parallel - can we revert meta-yocto f83319541 ?? Hiding the parallel options in the extended sample means they aren't copied to the autogenerated default (as commented out) local.conf
<paulg>
And then when starting with a new build or project, one has to go hunting for them to ensure one has the names correct vs. simply just uncommenting them.
<paulg>
I can't imagine I'm the only one who would rather manually set parallelism values fairly regularly.
vd has joined #yocto
<fray>
I don't screw with them often, but honestly it's always a pain when I'm on a shared machine and need to look up the right variables to set.. I'd love to have them back in the same file, but shorten the explanation leaving the default value in the bitbake.conf
<fray>
(yes I know they're in the sample.extended, but nobody ever looks there because that file doesn't end up in the build directory like local.conf does)
<paulg>
**exactly**
<paulg>
the referenced commit moved them from the sample to sample.extended
<Xagen>
when a build is started with bitbake, which mechanism is used to determine which packages are already built that it can pull from for dependencies?
<fray>
(there is a third setting which was never in the documented references to control the paralleization of the parsing as well. I also need to look that one up in bitbake)
<paulg>
and I don't want to look at sample.extended since I know it isn't used by default and worry it may contain bitrot.
<fray>
on a tangently related topic, I've been fighting people using rm_work on shared machines recently and the disk I/O is REALLY bad with a ton of people trying to rm at the same time across teh shared disks..
<paulg>
whee, I can only imagine.
<fray>
I'm wondering of do_rm_work[number_threads] = "1" (or some similar small number) might actually speed up disk I/O for everyone and real-world times..
<fray>
hadn't considered trying that until just now
<paulg>
do_rm_work[12 hours from now]
<fray>
unfortunately that won't work in my situation.. :P These shared machines have criminally small amounts of storage on them shared between 20 and 30 users..
<paulg>
doesn't help if you have people from all time zones on the machine either.
<fray>
timed a build yesterday, and 95% of the execution time was spent on sstate-cache extraction and rm_work..
<paulg>
that had to be blindingly fast. :-(
<fray>
25 minutes (real-clock) time for equivalent for bitbake core-image-minimal when most of sstate-cache was used..
<fray>
(note the 'most' not all)
<fray>
listed 'system time' as 95 seconds..
<wyre>
rburton, the setup.py works as expected, however I'm still having the same issue with bitbake, it cannot open the file
<rburton>
wyre: because your S isn't where the files are unpacking
<rburton>
the fetcher is mirroring the directory structure, so your setup.py is not in WORKDIR, but a subdirectory of it
<wyre>
rburton, so should I set S to the directory containing setup.py? or force the setup.py to be in the working directory?
<wyre>
rburton, now I'm having problems with the systemd services, https://bpa.st/VAOQ again the problem about "files were installed but not shipped in any package"
<rburton>
wyre: well, many recipes in oe-core don't
rcw has quit [Read error: Connection reset by peer]
rcw has joined #yocto
sakoman has quit [Remote host closed the connection]
zpfvo has quit [Remote host closed the connection]
xmn has joined #yocto
sakoman has joined #yocto
florian has quit [Quit: Ex-Chat]
vmeson has quit [Ping timeout: 252 seconds]
vd is now known as v2d
leon-anavi has quit [Quit: Leaving]
dtometzki has joined #yocto
vmeson has joined #yocto
mckoan is now known as mckoan|away
steve__ has joined #yocto
Tokamak has quit [Ping timeout: 255 seconds]
Tokamak has joined #yocto
linums has quit [Quit: Client closed]
v2d has quit [Quit: Client closed]
vd has joined #yocto
<Ad0>
I run dunfell. I completely forgot how I can patch the kernel with bitbake
<Ad0>
I need to reintroduce a kernel function that was removed in a later kernel heh
wing0 has joined #yocto
<Ad0>
"2.4. Using devtool to Patch the Kernel" right?
ncaidin_lf has joined #yocto
ncaidin_lf has quit [Client Quit]
frieder has quit [Read error: Connection reset by peer]
hpsy has quit [Ping timeout: 268 seconds]
whuang0389 has joined #yocto
LetoThe2nd has quit [Quit: Connection closed for inactivity]
<whuang0389>
so why does Yocto do this? My image builds fine incrementally. When I delete my cache (tmp sstate-cache and deploy), do a full rebuilding (minus the download), the build fails on some recipes
<override>
whats the difference between a .wic.gz and wic.bmap? which should I be writing to a sdcard. Can someone also please suggest a dd command for writing to an sdcard?
<kergoth>
override: the .bmap is just information for bmaptool to use when writing .wic or .wic.gz or .wic.bz2.
<kergoth>
override: you need both
<kergoth>
bmaptool is the best way, but dd will do, in which case you woudln't need the .bmap
<rfs613>
whuang0389: by "incrementally" do you mean running bitbake again? If nothing changed, the previous build (from sstate) will be used, it won't rebuild from scratch.
<whuang0389>
incrementally meaning yes, using sstatecache. I would add new recipes to the build and rebuild the image with previous cache. Just now I deleted my cache, tmp, and deploy folder to do a full rebuild and it fails =/
<override>
the .wks that is shown under deploy, is that the one that gets used or something? I didnt put it there, but I somehow see a copy
dtometzki has quit [Read error: Connection reset by peer]
dtometzki has joined #yocto
<rburton>
override: bmaptool optimises writing images which typically have a lot of empty space. the bmap file says where the holes are, and bmaptool just writes the actual content. When you have a 4GB image with 3.8GB of empty space, that makes a huge difference
<rfs613>
whuang0389: okay, i see, so the issue is that your incremental builds are not building everything. So you either have some broken/incompatible recipes, or there are dependencies which are not explicit (so it works when you add one at a time, but not when you ask bitbake to build everything from scratch)
<override>
rburton: ok cool. and whats the deal with the .wks under deploy. is that suppose to mean something?
<override>
is that bitbakes way of saying what got used for making the .wic image?
<JPEW>
override: ^^ correct
<override>
cool and this bmptool should come with yocto like those oe-utils or no?
<whuang0389>
yea =/ so is it proper to wipe the cache each time we add a new recipe?
<JPEW>
override: It's not an OE tool... you can usually install it from your host distro
<kergoth>
override: .wks is a file used to tell wic how to construct the image. the image build process may well write it to deploy for informational purposes, but its not needed for deployment
<rfs613>
whuang0389: it seems like overkill to me, but I guess it depends where the recipes are coming from. My setup is fairly static, not adding layers or recipes very much, so I don't really notice any problems.
<override>
kergoth: for some reason my new .wks isnt getting picked up, or atleast in deploy i keep seeing the old one. do i need to run clean or something?
<kergoth>
if WKS_FILE is correct ( run bitbake -e yourimage | grep WKS_FILE=), then it used the right one
wing0 has quit [Quit: WeeChat 3.1]
wing0 has joined #yocto
<override>
can I do a lsblk or something on a .wic disk image before writing it to my board?
<override>
JPEW: know some command that'll make uboot boot from the wic image from the sd card (when there is already an image loaded on the board at first bootup)
<rfs613>
override: okay, looks like you've gone one additional partition at the start, for u-boot. So shift the numbers I said by one.
<override>
hmm ill checkout that fatload command. trying to see that 0:1 is for
<rfs613>
in your case it will be 0:2.. the first is device number (0 based) and the second is partition (1 based).
<rfs613>
you can also use "fatls mmc 0:2" from u-boot prompt, you should see the contents of your "/boot" partition.
<override>
very cool. thanks
Guest26 has joined #yocto
zyga_ has joined #yocto
ant__ has joined #yocto
zyga has quit [Ping timeout: 252 seconds]
<kergoth>
override: how to boot your device from sd depends on how the board boots, in some cases there's a multi-level uboot setup, in others it's a dip switch, etc. check your board documentation
<override>
i forgot, how can i explicty declare what wks to use. and where was I putting that in? distro.conf or machine.conf?
dev1990 has quit [Remote host closed the connection]
camus1 has joined #yocto
dev1990 has joined #yocto
camus has quit [Ping timeout: 258 seconds]
camus1 is now known as camus
<Guest26>
I added gles2 to IMAGE_INSTALL_append in my local.conf file but when I build I get ERROR: nothing provides "gles2" I guess I have to add something else?
<whuang0389>
usually the graphic stuff is provided by vendor.. no?
<override>
kergoth: ill get to the board boot scheme in a bit, can you rmind me where and how I can explicity define what .wks to use?
steve__ has quit [Ping timeout: 252 seconds]
<Guest26>
I'm using meta-qt I thought it would be in that? I'm new to yocto. I also added PACKAGECONFIG+="gles2" in my new recipies-qt/qt5/qtbase_git.bbappend file
<LetoThe2nd>
Guest26: i don't think there's a package for that, maybe you want virtual/gles2 or something like that? (just guessing, no graphics guy)
<LetoThe2nd>
i'd expect it to be indirectly provided by mesa
<override>
kergoth: I made changes to my default one, but im trying to explicity name a wks in my image recipe or something. just so that everything stays in the meta i got access to
<Guest26>
Oh mesa, I'll see it that is turned on.
<whuang0389>
you should probably do bitbake -vn virtual/gles2 (i think it's that command)
<LetoThe2nd>
Guest26: don't randomly try and install stuff. 1) IMAGE_INSTALL doesn't belong into local.conf. 2) try to understand what you need, and where you get it. if in doubt, look at demo images/distros by your vendor.
florian has joined #yocto
<override>
JPEW: I forgot what var lets you explictly defien the name for a .wks file. remeber you telling me once, but ofcourse my logging wasnt on then...
<override>
thanks, and I should be defining that in image recipe?
<Guest26>
LetoThe2nd: Yeah I'm working on a project someone who left here a year ago setup and all the bitbake stuff runs from Cmake. I am kinda hacking around, we are using a Kontron board but NXP bsp.
<JPEW>
usually in machine.conf
<override>
ok cool. thanks
camus has quit [Ping timeout: 258 seconds]
camus1 has joined #yocto
<LetoThe2nd>
Guest26: unfortunately thats a classic story "i just inherited and am trying to beat it into shape". start small. put the target aside. learn the basics of distro vs. image vs. machine. create a layer, create an image, create a handful of testing recipes. then come back to the original task.
camus1 is now known as camus
<Guest26>
LetoThe2nd: Thanks, good advice, I should have found this IRC channel 2 weeks ago!