dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
Tokamak_ has quit [Ping timeout: 255 seconds]
Tokamak has joined #yocto
nerdboy_ has joined #yocto
nerdboy has quit [Ping timeout: 256 seconds]
sakoman has quit [Quit: Leaving.]
<yates_home> can you put a "deltask <taskname>" in a .bb file?
likewise has quit [Quit: Leaving]
jwillikers has quit [Remote host closed the connection]
bps has quit [Ping timeout: 268 seconds]
nerdboy_ is now known as nerdboy
nerdboy has joined #yocto
nerdboy has quit [Changing host]
camus has quit [Ping timeout: 255 seconds]
camus has joined #yocto
camus has quit [Ping timeout: 276 seconds]
camus has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus1 is now known as camus
camus has quit [Ping timeout: 250 seconds]
camus has joined #yocto
paulg has quit [Ping timeout: 256 seconds]
camus1 has joined #yocto
camus has quit [Ping timeout: 245 seconds]
camus1 is now known as camus
woky has quit [*.net *.split]
Lihis has quit [*.net *.split]
bunk has quit [*.net *.split]
troth has quit [*.net *.split]
abelloni has quit [*.net *.split]
iokill has quit [*.net *.split]
abelloni_ has joined #yocto
iokill_ has joined #yocto
Lihis_ has joined #yocto
bunk has joined #yocto
troth has joined #yocto
Lihis_ is now known as Lihis
woky has joined #yocto
TrevorWoerner[m] has quit [*.net *.split]
meck[m] has quit [*.net *.split]
beneth has quit [*.net *.split]
vd has quit [Ping timeout: 246 seconds]
TrevorWoerner[m] has joined #yocto
meck[m] has joined #yocto
beneth has joined #yocto
camus has quit [Quit: camus]
mranostaj has quit [Quit: leaving]
camus has joined #yocto
goliath has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
camus1 is now known as camus
zyga-mbp has joined #yocto
camus1 has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
leon-anavi has joined #yocto
camus has quit [Quit: camus]
Tokamak has quit [Ping timeout: 258 seconds]
Tokamak has joined #yocto
camus has joined #yocto
goliath has quit [Quit: SIGSEGV]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #yocto
rob_w has joined #yocto
mckoan|away is now known as mckoan
<mckoan> good morning
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
zpfvo has joined #yocto
linkliu59 has quit [Remote host closed the connection]
fleg has joined #yocto
linkliu59 has joined #yocto
Tokamak has quit [Ping timeout: 255 seconds]
frieder has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tnovotny has joined #yocto
argonautx has joined #yocto
goliath has joined #yocto
zyga-mbp has joined #yocto
linums has joined #yocto
zyga-mbp has quit [Client Quit]
tortoisedoc has quit [Quit: Client closed]
bps has joined #yocto
bps has joined #yocto
zyga-mbp has joined #yocto
zyga-mbp has quit [Client Quit]
zyga-mbp has joined #yocto
<qschulz> yates_home: yes you can, though it is risky (it can break the task dependency tree). Most often, do_task[noexec] = "1" is preferred
fleg has quit [Remote host closed the connection]
fleg has joined #yocto
florian has joined #yocto
LetoThe2nd has joined #yocto
<LetoThe2nd> yo dudX
<qschulz> o/
<LetoThe2nd> \o
<qschulz> ~o~
<LetoThe2nd> \m/ O \m/
<mckoan> good morning everyone
linums has quit [Quit: Client closed]
tnovotny_ has joined #yocto
tnovotny has quit [Read error: Connection reset by peer]
tnovotny has joined #yocto
tnovotny_ has quit [Ping timeout: 268 seconds]
davidinux has quit [Quit: WeeChat 2.8]
hmw__ has quit [Quit: Konversation terminated!]
nucatus has joined #yocto
<nucatus> hello! quick question. Is it possible to set a variable in an image recipe and read it in regular recipe?
<qschulz> nucatus: no, because recipe data is local to the recipe and image recipe is... a recipe :)
major_orange has joined #yocto
<major_orange> Hello everyone. Any tips on debugging sstate cache? I'm ending up with a whole rebuild for an image if the space between the builds is more then a few days old.
<qschulz> major_orange: bitbake diff-sigs might help
<major_orange> As far as I can see, it isn't fetching any new source (no fetch steps).
<nucatus> qschulz: thanks for this info. However, is there a way, instead of duplicating recipes, to parameterise recipes based on the image that is built?
<qschulz> nucatus: no, only configuration files allow this
<nucatus> qschulz: OK. What would then be the best practice to parameterise a recipe based on a targeted development cycle. For instance we have a image that produces a dev artifact, one that produces a stage artifact and one that produces the prod artifact
<qschulz> nucatus: different distro configuration files seem appropriate
<qschulz> but if it's really only a recipe or two, might be a better idea to just duplicate (you can include other recipe files from within a recipe to use as a base, or use a .inc) and add the packages of the correct recipe to your image recipe
<qschulz> note that obviously the packages and package recipes should be named differently
<qschulz> this gets trickier if your recipe is a dependency of another recipe, since you'll have to duplicate that one too
<qschulz> (distro is the cleanest, but has big consequences in terms of build time since almost nothing is shared between distros)
<nucatus> yeah, this is a pity that you need all that infrastructure just to handle different configuration files for different artifacts
<nucatus> because this is what we need in the end: different config files depending on the targeted dev cycle
<qschulz> nucatus: are the config files required at build time?
<qschulz> or are there config files that would be put in /etc on the target for example?
<nucatus> the latter
<nucatus> I mean we need the config at run time
<qschulz> then I think you can work around this by creating a package per config file (with a /etc/dev-conf etc...)
<qschulz> then in pkg_postinst_${PN}-whatever move the config file to the correct place (since you cannot have two files named the same). At first boot, the file will be installed in the correct place
<qschulz> might want to add RCONFLICTS between the three variants too
<nucatus> but that translates to an individual recipe for each config file, right?
<qschulz> no
<qschulz> you need to name your config files differently though
<qschulz> and always install them
<qschulz> then you split the different conf files in their own package via FILES_ variables
<qschulz> and you add a pkg_postinst (might be another function, you'll need to check if it does what you want) per package which renames or moves the conf file to the correct place on the rootfs
<major_orange> qschulz: Thanks. I've built `core-image-minimal` now twice. The second time I did a small change just to trigger some tasks to occur (I saw `do_rootfs` and
<major_orange> `do_image` running). However `bitbake-diffsigs -t core-image-minimal rootfs` complains `ERROR: Only one matching sigdata file found for the specified task (core-image-minimal rootfs)
<major_orange> `
<qschulz> (on the target)
<nucatus> qschulz: I think I got a grasp of it. I'll experiment with this and let you know. Thanks for the tip
<yates_home> qschulz: ok thanks.
jwillikers has joined #yocto
tnovotny has quit [Read error: Connection reset by peer]
tnovotny has joined #yocto
tnovotny_ has joined #yocto
<major_orange> So just to clarify, if I see a task getting run i.e `0: core-image-minimal-1.0-r0 do_rootfs (pid 1145177) 13% |####### ` that means that task isn't cached. Right?
tnovotny has quit [Ping timeout: 250 seconds]
bluelightning has quit [Remote host closed the connection]
angolini has joined #yocto
<neverpanic> yes. do_rootfs is usually never cached.
<major_orange> neverpanic: Thanks, that explains it why it isn't detecting a change
mckoan has quit [Ping timeout: 258 seconds]
mckoan has joined #yocto
camus has quit [Quit: camus]
linums has joined #yocto
goliath has quit [Quit: SIGSEGV]
<major_orange> What would be a good task then to use for an image? (the end goal is to try and identify the package which is triggering the rebuild of multiple other packages, usually I don't build individual packages but just do `bitbake core-image-minimal`) )
goliath has joined #yocto
<qschulz> look for new/"duplicate" files that are recent in the sigdata directory?
goliath has quit [Client Quit]
<Ad0> how do I find out if I successfully overwrote a specific file with my file in a bbappend
<major_orange> Ad0: You can try the `bitbake-layers flatten`. It will flatten the recipes merging the bb files with the bbappend files and showing you the end result. Check `bitbake-layers flatten -h` for usage.
<Ad0> thanks
<Ad0> does it show the absolute path or something for the physical file location then
<major_orange> Try it out :)
<Ad0> that created a dir with tons of files yeah
LetoThe2nd has quit [Quit: Connection closed for inactivity]
xmn has quit [Ping timeout: 265 seconds]
<Ad0> thanks but this doesn't show what the final output is of the package
<Ad0> recipe*
<Ad0> when I bitbake my recipe how do I see what the final output files on the FS are ? what files it chooses to pick and where they go
<qschulz> Ad0: oe-pkgdata-util list-pkg-files <pkg> if I remember correctly
<Ad0> that lists the files involved in the package but no which file it picks in a machine/whatever directory
vd has joined #yocto
<qschulz> if you want to know the content of the files and check they were correctly overriden, you can read the log in WORKDIR/temp/log.do_fetch and you'll see the paths that are searched
<Ad0> okay thanks
<Ad0> that's a proposal for the pkg utility or the like
<Ad0> tofind out which files were actually selected
<qschulz> Ad0: patches welcome :)
<Ad0> lol
<Ad0> that log shows which paths are searched, indeed but not which one it found lol
<Ad0> what utility would that fit in qschulz if I were to actually take you up on it and make a patch hehe
<Ad0> maybe an option to bitbake itself
<Ad0> but it stands to reason that it searches machines/architectures etc before the root path
<Ad0> so if I have a fiel with the name there it should hit that first
yates has joined #yocto
<Ad0> do_fetch.log could have [FOUND] or something as well
<qschulz> Ad0: first path to be found, first taken
<qschulz> Ad0: I think it stops at the first path it founds
<qschulz> (in the logs I mean)
<yates> qschulz: why does deltask potentially break task dependencies while do_task[noexec] = "1" does not?
<Ad0> hm
<qschulz> yates: because you remove a task
<Ad0> I double checked the path in the log and it matches my actual path but it continues on searching
<Ad0> so it's not clear which one it found
<Ad0> I get the ground truth when mounting the image
tnovotny_ has quit [Quit: Leaving]
<qschulz> you can go to WORKDIR/image (or package-split)
<qschulz> and read the content there
<Ad0> thanks
<qschulz> yates: e.g. you rarely ask a recipe to be fetched, you ask for it to make its packages for example
<qschulz> so, bitbake needs to know what the task for making the packages needs
<qschulz> it'll need do_install
<qschulz> but what do_install needs?
<qschulz> do_compile
<qschulz> do_configure -> do_patch -> do_unpack -> do_fetch
<qschulz> now remove do_configure here
<Ad0> if I bitbake virtual/kernel
<qschulz> and your recipe will stop at do_configure without knowing what to do
<Ad0> it does all that stuff
<Ad0> it doesn't do rootfs etc of course
<qschulz> Ad0: re: the tool, maybe an extension to bitbake-layers show-recipes? The one that shows the bbappends
<yates> ok
<Ad0> when you bitbake your recipe, doesn't it make ipk files and stuff
<vd> hi there -- I have a package which causes the image the fail with "Unable to install packages."
<Ad0> some data / package that has all the files
<yates> at the risk of asking a question whose answer may not be simple, is there a list of top-level "tasks" (packages?) involved in building an image? e.g., virtual/kernel, virtual/bootloader, rootfs, etc?
<vd> but only this specific package, without it the image builds fine. I cannot make sense out of it
<qschulz> virtual/kernel and virtual/bootloader are virtual recipes
<qschulz> do_build is what's called when you bitbake a recipe
<qschulz> DEPENDS, RDEPENDS and the like are actually cross-recipes task dependencies
<vd> yates most base packages are pulled in from a few packagegroups, like packagegroup-core-boot etc. (pulling in machine and distro packages)
<Ad0> when doing core-image-minimal, where is the directory where the rootfs files are laid out before making an image file?
<Ad0> I can look there as well for the true file
<qschulz> WORKDIR for the image recipe
<qschulz> work/<machine>/<image-name>/<image-version>/rootfs I think
goliath has joined #yocto
jkolasa has joined #yocto
kpo has quit [Read error: Connection reset by peer]
kpo has joined #yocto
<vd> ok I nailed down my issue to the combination of a package + a packagegroup
<vd> both together results in "Unable to install packages.", only one of them works
rob_w has quit [Quit: Leaving]
<Ad0> thanks qschulz
zyga has joined #yocto
sakoman has joined #yocto
zyga has quit [Quit: Leaving]
Guest96 has joined #yocto
Guest96 has quit [Client Quit]
wyre_ is now known as wyre
whuang0389 has joined #yocto
paulg has joined #yocto
<major_orange> There is a `.....rootfs.tgz.siginfo` for for rootfs. Does this disprove the claim that the image rootfs tasks aren't cached?
<JPEW> major_orange: defined "cached"?
<JPEW> They are kept locally, so if you rebuild again and nothing changed, it won't rebuild the rootfs
<JPEW> But they are not kept in sstate
<major_orange> I am detecting these files in the sstate paths. `./ee/2c/sstate:core-image-minimal:raspberrypi3-poky-linux-gnueabi:1.0:r0:raspberrypi3:3:4....dc_rootfs.tgz.siginfo`
<major_orange> (context wise, I'm trying to get to a minimal example to `bitbake-diffsigs` on an image to diagnose which packages are guilty for the rebuild)
<JPEW> major_orange: Err, I'm not sure :)
<qschulz> major_orange: sigdata files are in tmp/stamps
<major_orange> qschulz: Thanks. There is a rootfs task also there. `1.0-r0.do_rootfs.sigdata.ee2c421eb3466febf1ebcb701044b565d296675e161c01bdc39b711b069464dc`
<whuang0389> does DEPENDS= or DEPENDS+= matter for a simple recipe that doesn't inherit anything explicitly?
<qschulz> whuang0389: can you explain a bit more what you mean by that?
<whuang0389> just wondering if yocto pulls in "hidden" dependencies, so if I go DEPENDS="....", those "hidden" dependencies aren't pulled in.
<whuang0389> hopefully that makes sense lol
<qschulz> whuang0389: DEPENDS= should be fine but I'd recommend to use DEPENDS += just to be on the safe side if you ever inherit another class/include another recipe
<whuang0389> thanks:)
Tokamak has joined #yocto
zyga has joined #yocto
fleg has quit [Remote host closed the connection]
fleg has joined #yocto
zyga-mbp has quit [Ping timeout: 252 seconds]
zyga has quit [Ping timeout: 258 seconds]
zyga has joined #yocto
fitzsim has quit [Read error: Connection reset by peer]
<jonmason> zeddii: hahaha
<zeddii> I think that's me in the row behind, but who knows. ears and glasses look similar :D
zyga-mbp has joined #yocto
<zeddii> also: https://sched.co/lAMT
jkolasa has quit [Quit: Client closed]
<JPEW> zeddii: Nice
<JPEW> I also have one: https://sched.co/lAMl
* JPEW wonders if anyone has ideas for how to fly a jumble of raspberry pi boards and equipment to Seattle... for a on-site demonstration
<mckoan> zeddii: even Andreea and Lieu :-)
<whuang0389> is that conference virtual?
<JPEW> whuang0389: Hybrid
<whuang0389> hybrid being some talks are in person only? or will all talks be streamed?
<zeddii> JPEW, nice!
<JPEW> whuang0389: I'm not sure; I know they asked when I signed up for a talk if I was coming in person
<whuang0389> oo virtual only 50 bucks :)
<JPEW> whuang0389: I would *assume* all the talks will be streamed, but I could be wrong
<whuang0389> thanks!
fitzsim has joined #yocto
<JPEW> Hmm, does anyone live near Seattle and going to drive the conference?
<moto-timo> JPEW: I _might_ do the 4-hr drive…
sakoman has quit [Quit: Leaving.]
<JPEW> Fair. I was thinking it would be easier to ship my test cluster to a local and have them hand carry it instead of trying to fly it with me
mranostaj has joined #yocto
<whuang0389> so tomorrow is the last day for discounted in-person pass?
sakoman has joined #yocto
<JPEW> whuang0389: Looks like it
<whuang0389> need to somehow convince my boss now haha
rber|res has joined #yocto
argonautx has quit [Quit: Leaving]
Guest15 has joined #yocto
zpfvo has quit [Quit: Leaving.]
Guest15 has quit [Quit: Client closed]
xmn has joined #yocto
mckoan is now known as mckoan|away
florian has quit [Quit: Ex-Chat]
frieder has quit [Remote host closed the connection]
<override> hey guys, so back to figuring out wic images today. So my board is currently flashed with a working image (boots and all fine). I used bmaptool to flash an sdcard, now I want to power up my board, go the the uboot prompt and somehow make it boot using the wic image on the sd card. I cant figure out what uboot commands to use in order to do this.
florian has joined #yocto
florian has quit [Ping timeout: 268 seconds]
<vd> If I do not want to pull in ${PYTHON_PN} as a dependency in my python package, should I add RDEPENDS_${PN} = "" before or after 'inherit setuptools3' or it does not matter?
<vd> override you might want to join #u-boot instead
<override> thanks vd:
<khem> abelloni: something is busted in bitbake on your master-next it seems https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/1418
<RP> khem: FWIW my master-next has overrides changes in so is a bit experimental atm
<khem> RP: are these also picked into abelloni/master-next on contrib tree ?
<khem> I was using that branch
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
<vd> Is there a way to install a package without its dependencies in an image-a, and its dependencies in an image-b?
<RP> khem: no
nucatus has joined #yocto
zyga has quit [Ping timeout: 258 seconds]
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Ping timeout: 252 seconds]
bradfa has quit []
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Ping timeout: 240 seconds]
xantoz has quit [Quit: WeeChat 3.0]
xantoz has joined #yocto
dtometzki has quit [Quit: ZNC 1.8.2 - https://znc.in]
nucatus has joined #yocto
yates_home has quit [Remote host closed the connection]
nucatus has quit [Ping timeout: 240 seconds]
zyga has joined #yocto
dtometzki has joined #yocto
nucatus has joined #yocto
nucatus has quit [Ping timeout: 252 seconds]
<vd> Is SUMMARY of DESCRIPTION set automatically by the setuptools3 class?
nucatus has joined #yocto
<smurray> RP: for the r/o pr server changes is rebasing to master-next which has JPEW's SIGTERM fix workable for you?
linums has quit [Ping timeout: 246 seconds]
nucatus has quit [Ping timeout: 268 seconds]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
LetoThe2nd has joined #yocto
nucatus has quit [Remote host closed the connection]
florian has joined #yocto
whuang0389 has quit [Quit: Client closed]
ecdhe has quit [Ping timeout: 255 seconds]
ecdhe has joined #yocto
nucatus has joined #yocto
nucatus has quit [Ping timeout: 272 seconds]
nucatus has joined #yocto
Tokamak has quit [Ping timeout: 258 seconds]
nucatus has quit [Ping timeout: 276 seconds]
<RP> smurray: yes, that'd work
<smurray> RP: okay
<rburton> vd: no
<rburton> vd: (easily demonstrated by looking at the class)
nucatus has joined #yocto
Tokamak has joined #yocto
nucatus has quit [Ping timeout: 240 seconds]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus_ has joined #yocto
nucatus_ has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus_ has joined #yocto
nucatus_ has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus_ has joined #yocto
nucatus_ has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus_ has joined #yocto
nucatus_ has quit [Ping timeout: 276 seconds]
<abelloni_> khem: yes, all my builds have been failing today
nucatus has joined #yocto
<smurray> RP dl9pf: I've pushed a meta-agl next branch update that should fix up the autobuilder. Took me a bit longer to untangle some new systemd v249 brokenness than I thought it would
nucatus has quit [Read error: Connection reset by peer]
nucatus_ has joined #yocto
nucatus_ has quit [Ping timeout: 276 seconds]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus_ has joined #yocto
<RP> smurray: thanks!
nucatus_ has quit [Ping timeout: 245 seconds]
nucatus has joined #yocto
nucatus has quit [Ping timeout: 240 seconds]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Ping timeout: 256 seconds]
florian has quit [Ping timeout: 265 seconds]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus_ has joined #yocto
nucatus_ has quit [Remote host closed the connection]
nucatus has joined #yocto
yates has quit [Remote host closed the connection]
nucatus has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
nucatus has quit [Remote host closed the connection]
nucatus has joined #yocto
nucatus has quit [Ping timeout: 276 seconds]
leon-anavi has quit [Quit: Leaving]
nucatus has joined #yocto
Guest9749 has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus_ has joined #yocto
nucatus_ has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus_ has joined #yocto
nucatus_ has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
nucatus has quit [Ping timeout: 256 seconds]
Guest73 has joined #yocto
Guest73 has quit [Client Quit]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
kpo has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
kpo has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus_ has joined #yocto
nucatus_ has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
florian has joined #yocto
nucatus has quit [Ping timeout: 265 seconds]
nucatus has joined #yocto
nucatus has quit [Ping timeout: 265 seconds]
zyga has quit [Ping timeout: 272 seconds]
nucatus has joined #yocto
abelloni_ is now known as abelloni
nucatus has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
<Guest9749> Does yocto supporting building images from the tar.bz2 ( using aw files ), without having a WORKSPACE available ?
nucatus has quit [Ping timeout: 252 seconds]
nucatus has joined #yocto
nucatus has quit [Read error: Connection reset by peer]
nucatus_ has joined #yocto
florian has quit [Ping timeout: 265 seconds]
nucatus_ has quit [Read error: Connection reset by peer]
nucatus has joined #yocto
goliath has quit [Quit: SIGSEGV]
nucatus has quit [Ping timeout: 240 seconds]