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)
camus1 has joined #yocto
camus has quit [Remote host closed the connection]
camus1 is now known as camus
camus1 has joined #yocto
camus has quit [Ping timeout: 258 seconds]
camus1 is now known as camus
hpsy1 has joined #yocto
hpsy has quit [Ping timeout: 258 seconds]
prabhakarlad has quit [Ping timeout: 246 seconds]
rber|res has joined #yocto
goliath has quit [Quit: SIGSEGV]
RobertBerger has quit [Ping timeout: 255 seconds]
hpsy has joined #yocto
hpsy1 has quit [Ping timeout: 265 seconds]
sakoman has quit [Quit: Leaving.]
paulg has quit [Ping timeout: 265 seconds]
Vonter has quit [Ping timeout: 255 seconds]
Vonter has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus has joined #yocto
roussinm has quit [Quit: WeeChat 3.3-dev]
zyga-mbp has joined #yocto
zyga-mbp has quit [Client Quit]
zyga-mbp has joined #yocto
rob_w has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zyga-mbp has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 258 seconds]
camus1 is now known as camus
LetoThe2nd has joined #yocto
<LetoThe2nd> yo dudX
zyga has quit [Ping timeout: 265 seconds]
leon-anavi has joined #yocto
camus1 has joined #yocto
pinpox has left #yocto [The Lounge - https://thelounge.chat]
camus has quit [Ping timeout: 258 seconds]
camus1 is now known as camus
rob_w has quit [Remote host closed the connection]
prabhakarlad has joined #yocto
<mihai> yo
<LetoThe2nd> yo yo ba
<mihai> you lost me
<LetoThe2nd> why?
<mihai> with the 'ba' at the end :)
<mihai> ok that's nice
<LetoThe2nd> :)
kayterina has joined #yocto
Neur0mante has joined #yocto
<mihai> this got me thinking of a trivia chat bot :))
<mihai> it's been a while since I've seen one
argonautx has joined #yocto
tnovotny has joined #yocto
jsandman1 has joined #yocto
rfs613_alt has joined #yocto
jsandman has quit [Ping timeout: 252 seconds]
rfs613 has quit [Ping timeout: 252 seconds]
jsandman1 is now known as jsandman
florian has joined #yocto
florian_kc has joined #yocto
camus has quit [Ping timeout: 265 seconds]
camus has joined #yocto
florian_kc has quit [Ping timeout: 258 seconds]
Guest68 has joined #yocto
rob_w has joined #yocto
florian_kc has joined #yocto
camus has quit [Ping timeout: 255 seconds]
camus has joined #yocto
xmn has quit [Quit: ZZZzzz…]
Schlumpf has joined #yocto
Guest68 has quit [Quit: Client closed]
manuel1985 has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 268 seconds]
camus1 is now known as camus
Neur0mante has quit [Ping timeout: 246 seconds]
rob_w has quit [Remote host closed the connection]
goliath has joined #yocto
camus1 has joined #yocto
camus has quit [Ping timeout: 258 seconds]
camus1 is now known as camus
<LetoThe2nd> howdy! I'll be live in ~15 minutes at https://www.twitch.tv/theyoctojester
jwillikers has joined #yocto
<LetoThe2nd> 2 minutes to got!
paulg has joined #yocto
camus has quit [Quit: camus]
rcw has joined #yocto
zyga has joined #yocto
zyga-mbp has quit [Read error: Connection reset by peer]
<qschulz> oh no, I missed it :(
<LetoThe2nd> qschulz: FAIL!
<qschulz> LetoThe2nd: hope you had fun :)
<LetoThe2nd> things basically worked as expected :)
tperrot has quit [Quit: leaving]
tprrt has joined #yocto
tprrt is now known as tperrot
vd has joined #yocto
<vd> Hi Yocters -- I have a 4Go eMMC and for simplicity sake, I would like to have a wic image taking advantage of its full space. Is there a way for wic to guarantee the exact size of the image?
<vd> for sure I'll use IMAGE_FSTYPES += "wic.something wic.bmap"
kayterina_ has joined #yocto
<qschulz> I think it might make more sense to expand the filesystem at runtime on the target
<qschulz> otherwise you'll need to flash 4GB every time
<qschulz> RPi distros do this usually on first boot (or allow via some tools)
<JPEW> I think systemd can do this for you also
<vd> qschulz that's just for the initial factory image, I figure it might not be big of a deal. Otherwise I must script (re)partitioning and that's not ideal for now :/
frosteyes1 has joined #yocto
<vd> JPEW systemd-repart requires GPT partitions but I'm using MBR still
erbo has joined #yocto
florian__ has joined #yocto
<qschulz> vd: if you flash the factory image in a factory line, you'll spend a lot of money for nothing valuable :)
matthewcroughan has joined #yocto
kmaincent1 has joined #yocto
<vd> qschulz you know how to talk to guys like me don't you
<vd> ok full size wic image aborted
Schlumpf has quit [Quit: Client closed]
<JPEW> vd: FWIW, we put a file on the file system that indicates "this needs resize" and our initrd does it on the first boot
dv|2 has joined #yocto
<vd> JPEW so you think I can script systemd from the .wks file with a bench of --ondisk mmcblk1 --fsoptions x-systemd-makefs etc.?
<qschulz> and we actually put the resizing in the post_install script of swupdate which gets run only outside the factory line (company is basically an OEM and clients reflash with swupdate in their own "factory")
<vd> JPEW I can avoid initrd with factory is booting from an external medium
florian_kc has quit [*.net *.split]
kayterina has quit [*.net *.split]
zeddii has quit [*.net *.split]
erbo_ has quit [*.net *.split]
dvorkindmitry has quit [*.net *.split]
frosteyes has quit [*.net *.split]
matthewcroughan_ has quit [*.net *.split]
kmaincent has quit [*.net *.split]
rewitt3 has quit [*.net *.split]
<JPEW> vd: Ya, something like that. TBH I've never tried it myself
jwillikers has quit [Ping timeout: 240 seconds]
rewitt3 has joined #yocto
jwillikers has joined #yocto
* RP thinks he's losing the plot wondering if ML can help converting overrides magically
<JPEW> RP: ML can solve every problem, because it's Magic!
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #yocto
hpsy has quit [Read error: Connection reset by peer]
rfs613_alt is now known as rfs613
<JPEW> RP: I do think there is a path forward here, as long as we are careful
<RP> JPEW: conversion isn't actually that bad. I have horrendous script here which is mostly doing an ok job
<JPEW> Ya, I think the rub is to make a very simple patch that can be backported to older versions to translate ':' to '_' so the metadata remains compatible
xmn has joined #yocto
tnovotny_ has joined #yocto
vd67 has joined #yocto
vd67 has quit [Client Quit]
tnovotny has quit [Ping timeout: 245 seconds]
<RP> JPEW: conversion script is on there, and the result run against poky. I've not even tried parsing the result yet but it is looking the right direction
<JaMa> "very simple patch" :) 7.4MB .patch for meta-ros with RP's script
<JaMa> ^ isn't expected I guess
<RP> JaMa: This is hardly finished work :)
* RP adds FILES_SOLIBSDEV to the list
sakoman has joined #yocto
<JPEW> RP: Aren't most variables upper case and most overrides lower case?
<RP> JPEW: yes, but function names aren't and function names have overrides
<RP> the rule is that overrides should be lowercase
<RP> and package names too
<JPEW> Right. Functions should end with.... "\s*\(" ?
<JPEW> (any amount of whitespace after the name and an open paren)
<RP> JPEW: maybe. You have things like setVar("do_configure_append")
<JPEW> ah, right. I always forget about that
vmeson has quit [Ping timeout: 265 seconds]
<RP> JaMa: how did it look in general, that variable aside?
<RP> hah, it nearly even parses now. "Nearly" :)
<JaMa> it looks reasonable, but I would need to update vars with many move overrides we're using in this layer
<JaMa> and it's still very big (even github refuses to show the whole diff)
<RP> JaMa: so it needs to be taught about "ros1-distro" and "rpi" but that isn't so bad for a first pass
<JaMa> right and skip bunch of other files which aren't really OE metadata, so I guess everybody will need to adjust this script a bit to apply for his case
<RP> JaMa: right, I'm not sure a one size fits all is possible but I think with some maintainer knowledge and small tweaks, conversion is vaiable
vmeson has joined #yocto
<RP> I did this really to see if it was possible and also, if I can get a converted poky, I can get more data about how the result performs/works
tgamblin has quit [Ping timeout: 240 seconds]
tgamblin_ has joined #yocto
<JaMa> it might be useful to be able to run processfile() on actual .patch files with metadata changes to help with the cherry-picks from older branch to newer (if it updates the diff context as well as the change itself then it might even apply without many conflicts)
<JaMa> and then it might be useful to support reversed conversion (for backports from newer branch to older)
<JaMa> understood, I was also running it mostly to see how big PIA it will be if we do support newer releases in the end
<RP> JaMa: those do sound like nice things to be able to do. A lot will depend on how much interest/help there is in making them work well
<RP> JaMa: is it better or worse than you thought? :)
tgamblin_ has quit [Quit: Leaving]
tgamblin has joined #yocto
<RP> of course the piece breaking in parsing is the image backend code since some bright person decided overrides were great for IMAGE_CMD and friends
<JaMa> RP: the script is better than I thought, but still using it on daily basis for migrating changes between branches still scares me
<JaMa> but I do agree that flag-day supported with a conversion script is better than trying to support both syntaxes for whole LTS cycle
<JaMa> the unmaintained layers won't get the updated syntax, so it just postpones abandoning them for 2 years
<JaMa> hard break will at least force people to decide if they want to support the next LTS release or not
<RP> JaMa: Its a tough situation without easy answer :/
RobW has joined #yocto
rcw has quit [Quit: Leaving]
<JaMa> heh, I just shared completely opposite view of flag-day than Saur[m] on ML :) yeah.. can't make everyone happy :)
tnovotny_ has quit [Quit: Leaving]
<smurray> I'm all for a flag day if it gets us somewhere better wrt the issues now with juggling ?= vs ??= and append vs +=
<smurray> RP: roughly how long do the full oe-selftests usually take on the autobuilder?
<qschulz> Chiming in very quickly on that operator topic, could we have this "dual-support" optional? What I basically mean is a variable somewhere (env variable before bitbake? python cmdline argument?) that disables/enables support for old (current) operator syntax
<qschulz> and disable dual-support by default
<qschulz> that way, it fails by default but people can still use the layers by using this "switch"/variable/whatever you call it
<qschulz> this highlights that something is changing and will require attention in the next few releases
<RP> qschulz: I think we'd have to experiment to know for sure. I suspect there is some backwards compatibility option so old bitbake could parse new metadata
<RP> A lot depends on how invasively you change the format
ant__ has joined #yocto
RobW has quit [Quit: Leaving]
<RP> wow, successful parse
<smurray> RP: re my earlier question, "oe-selftest -a" on my Threadripper machine took ~17 hours, is that completely out there, or potentially reasonable?
<RP> smurray: sounds about right. Try adding -j to parallelise
<RP> smurray: its a lot of tests
<smurray> RP: ah, I was curious about the somewhat single-threaded nature, good tip
<RP> build keeled over quickly, looks like DEPENDS isn't working properly but its kind of amazing it works at all. I updated the branch
<smurray> RP: so I have a local change to shift the asyncio loop creation into the pr/hash equic server child provesses as was discussed, should I add it as an extra patch to pbarker's stack, or merge it into them?
<smurray> heh, need more coffee, my typing is terrible this morning
<RP> smurray: I can't remember what that patchset looks like so I'm not sure :/
<smurray> RP: heh, no worries, I'll tinker a bit and see what seems better
<RP> heh, it actually got a decent way through gcc-cross:do_compile before it exploded this time :)
LetoThe2nd has quit [Quit: Connection closed for inactivity]
rcw has joined #yocto
kayterina_ has quit [Remote host closed the connection]
florian has quit [Quit: Ex-Chat]
florian__ has quit [Ping timeout: 245 seconds]
zeddii has joined #yocto
lexano has quit [Remote host closed the connection]
angolini has quit [Quit: Connection closed for inactivity]
<vd> what is the better .wic compression, size-wise ?
xmn has quit [Ping timeout: 255 seconds]
behanw has joined #yocto
lexano has joined #yocto
leon-anavi has quit [Quit: Leaving]
<rburton> lz4 most likely, but wic images have lots of empty space in them so almost anything will shrink them a lot
<vd> ok
<override> im trying to write my own image recipe. Can I just bring allthe recipes under IMAGE_INSTALL_append to IMAGE_INSTALL += (in my new image recipe)
<vd> JPEW how do you instruct the system to create a new partition at factory? e.g. data
<override> or should I make a packagegroup for these recipes first?
dgriego1 has joined #yocto
<override> is ther a util that can make a packagegroup for all recipes in a layer or something?
<JPEW> vd: we use wic
<JPEW> Using bmaptool helps a lot to because it only copies data that is populated.
<vd> JPEW If I'm not mistaken, for a data partition using all remaining space, this partition cannot be created with wic, right?
dgriego has quit [Ping timeout: 258 seconds]
<JPEW> So even if you have a 64GB disk image, you can use bmaptool + disk resize and only copy a fraction of that in the factory
<vd> bmaptool can use the remaining space for a partition?
<JPEW> You make the partition small and resize on first boot
<JPEW> Bmaptool let's you avoid copying the "dead" space when writing the image in the factory
<vd> I see. If systemd-repart isn't an option (I'm using MBR), what is the recommended way to resize such partition on first boot?
<vd> unfortunately there's no x-systemd.resize mount option
<vd> x-systemd.makefs and x-systemd.growfs won't alter the partition size I think
<JPEW> Ah. We use a initrd for that case
<override> does anyone follow what I tried asking above, or do need to be cleaer?
<vd> override I'm not aware of a meta package which includes all packages provided by a layer, sounds like a bad idea anyway
<vd> if you wish to have the same set of packages in multiple recipes, then you want to define your packagegroup
<override> ok cool, so I dont want that, so I can move past the packagegroup bit.
<vd> if you want to tweak an image recipe, you can edit IMAGE_INSTALL from your local.conf or even bbappend the existing recipe
<override> vd: im writing an image recipe from scratch, i had been tweaking the local.conf that came with the bsp..
<khem> vd: you can look at 96board-tools recipe http://layers.openembedded.org/layerindex/recipe/57412/
<override> so ive added all my recipes for python packages under IMAGE_INSTALL for this new image recipe
<override> I wanted to know whats like the IMAGE_INSTALL equivalent for DISTRO_FEATURES
<override> i was doing some DISTRO_FEATURES_append in local.conf earlier. Now that im writing a new image recipe, id like to take care of the disrto features there aswell
<vd> override packagegroup-base and packagegroup-distro-base contain the packages enabled by DISTRO_FEATURES
<override> vd: so youre saying I should edit packagegroup-base and packagegroup-distro-base?
<override> there isnt like a DISTRO_INSTALL or something I can just call from my image recipe
<override> and whats bb.utils.contains, I see some IMAGE_INSALL stuff in image recipes using it for DISTRO_FEATURES...
<override> im just trying to make sure if thats the only way of goign about taking care of DISTRO_FEATURES install or if there is a class i can inherit in my image recipe which lets me use something like DISTRO_FEATURES_INSTALL
<override> bb.utils.contains in IMAGE_INSTALL is 1)very confusing 2)I dont know the first thing about
<override> guess I might have to do some extensive reading to figure this DISTRO_FEATURES and image recipe bit..
<kergoth> override: https://gist.github.com/kergoth/d2d4f7ed65561e67ef09f258ba73111d is a *very* old doc i wrote but might help?
<override> cool, thanks kergoth: Anthing that keeps me from reading the mega manual!
<kergoth> the mega manual isn't really something you read, certainly not end to end, more a way to search for what you need and read subsets as needed
<JPEW> RP: I agree the fray, the packaging code using `RDEPENDS_${PN}` is just abusing overrides, it's not *really* overrides (and I'd be hesitant to treat them as such)
zyga has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rcw has quit [Ping timeout: 268 seconds]
<fray> to me it's about scope.. global & recipe are 'obvious' and debugable with bitbake.. but there is not package 'scope'
creich has joined #yocto
creich has quit [Client Quit]
LetoThe2nd has joined #yocto
<ant__> someone said it is mostly used in BSP layers, I can confirm, with some prebuilt blobs the shlibs resolver cannot automatically add the rdep
<override> can someone tell me where bb.contains is documented ?
<override> Im trying to make sense of stuff like this - ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'timestamp-service systemd-analyze', '', d)}
<mihai> override: var, val, true, false
<mihai> override: see ./poky/bitbake/lib/bb/utils.py:974
<override> mihai: not seeing poky in my tree
<mihai> override: the poky git
<override> oh, okay. thanks
<override> ok cool, I get what all the params are for now, but d
<override> what data store are we referring to? mihai:
florian has joined #yocto
<override> mihai: is it okay to just add a DISTRO_FEATURES += in an image recipe?
<abelloni> it doesn't work
<abelloni> override: d is the datastore, it is always d
<override> abelloni: well how can I make something like DISTRO_FEATURES_append = " systemd" work from an image recipe
<abelloni> you can't, you have to do that from your distro config
<override> abelloni, where the distro config at?
<abelloni> in conf/distro in any of your layer
<abelloni> if you want systemd, you may look at poky-alt
<override> abelloni my conf just has bblayers.conf local.conf templateconf.cfg
<override> do i have to use devtool or something to setup a distro conf?
<LetoThe2nd> override: abelloni hehe yocto chant #1 applies
<abelloni> this is conf/ in your build dir, I was referring to conf/ in a layer
<override> LetoThe2nd: not sure I follow..
<override> thanks abelloni: i take a look at how poky is setting up systemd
<override> hopefully its doing the distro features under conf
<mihai> override: if you want systemd, you'll probably better of setting INIT_MANAGER = "systemd"
<override> thanls mihai: abelloni: those were the answers I was looking for!
<mihai> np
<override> abelloni: so how does poky select what ecact distro config to use for building an image? from poky-altcfg poky-bleeding poky-tiny..
<override> guess I should look at poky image recipe
<override> which I dont see..
<abelloni> override: DISTRO = in your local.conf
<override> oh so the local.conf under build/conf? sorry im just making sure, so I dont have to deal with blobs and whatever else crap later
<LetoThe2nd> override: this essentially means: a recipe cannot affect another recipe. and as an image is also just a recipe, it cannot affect if other things are built with systemd support or not, and so it cannot select systemd.
<override> LetoThe2nd: good to know. Thanks for that explantion. Now I kinda understand what the whole fuss about conf..
<LetoThe2nd> override: i suggest having a good look at https://youtu.be/o-8g0TPVVGg
<override> LetoThe2nd: abelloni: is there such as thing as local.conf for local layers?
<override> cool LetoThe2nd: taking a look now
<vd> if I have a package foo and I want foo and only foo installed on a (incomplete) squashfs image, should I use IMAGE_INSTALL = "foo" or PACKAGE_INSTALL = "foo" or both?
<LetoThe2nd> override: what would a local.conf for "local layers" (whatever that would be) do?
<override> not sure, i was just seeing a local.conf under meta-poky/conf, so that was throwing me off a bit...
<override> LetoThe2nd: ***i meant to say meta-layers there, not local layers***
<LetoThe2nd> i think you saw a "layer.conf"
<LetoThe2nd> thats not local.conf, thats local.conf.sample. huge difference.
<LetoThe2nd> but there's a layer.conf, just as i said.
<override> got it
<override> Im trying to establish if there's always just one local.conf at all times in the tree?
<override> where I can go set the DISTRO ..
<LetoThe2nd> override: local.conf is not in the "tree". local.conf is in your build. and based an that, yes, there's always axactly one local.conf in a build.
<override> whats the universally accepted definition of a tree?
<LetoThe2nd> no idea.
<zeddii> I think photosynthesis is involved.
<ant__> at one point all was simple
<override> lol i just meant I've just been calling my oe-core directory a tree. Was trying to make sure I dont confuse people. zeddii: photosynthesis is indeed involved.
<LetoThe2nd> zeddii: reminds me of Idefix.
<LetoThe2nd> ant__: behold, i have that on my hilarious social media to do list.
<LetoThe2nd> anyways, i'm off. good night, have metal dreams and remember your headbanging exercises, everybody.
<override> thanks LetoThe2nd:
<override> checking out your youtube
florian_kc has joined #yocto
florian has quit [Ping timeout: 255 seconds]
marc1 has quit [Quit: WeeChat 3.2]
Vonter has quit [Ping timeout: 246 seconds]
florian_kc has quit [Ping timeout: 255 seconds]
florian_kc has joined #yocto
florian_kc is now known as florian
dmoseley has quit [Ping timeout: 245 seconds]
dmoseley has joined #yocto
<vd> does bmaptool looks for a .bmap file of the same name as the image to flash or do you need to specify it?
Vonter has joined #yocto
<rber|res> @vd: it searcher for a .bmap file
<rber|res> e.g. xxx.rootfs.wic.xz and xxx.rootfs.wic.bmap
<JPEW> vd: I think you can also manually specify one with `--bmap`
<vd> I'm renaming the .wic extension so I need to test that
jwillikers has quit [Remote host closed the connection]
<RP> hmm, tinfoil is just too slow to dump out the metadata in the way I want :(
jwillikers has joined #yocto
rber|res has quit [Read error: Connection reset by peer]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
florian has quit [Ping timeout: 255 seconds]
Tokamak has joined #yocto
sgw has quit [Quit: Leaving.]
argonautx has quit [Quit: Leaving]
dv|2 has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
goliath has quit [Quit: SIGSEGV]