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
<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
<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>
-FILES_SOLIBSDEV = ""
<JaMa>
+FILES:SOLIBSDEV = ""
<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?
<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..
<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..
<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?
<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..
<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>
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?
<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]