<khem>
ok, which image are you building ? and whats spec of your system ( is it using faster storage )
xmn has quit [Ping timeout: 260 seconds]
xmn has joined #yocto
<PhoenixMage>
khem: Did you see my message re zsh modules?
<PhoenixMage>
I have had no luck trying to work out why they arent compiling
<mischief>
khem: all custom of course
<mischief>
we're on 16 core ec2 instances with gp2 EBS volumes
davidinux has quit [Ping timeout: 255 seconds]
davidinux has joined #yocto
Alexwarrior has joined #yocto
<khem>
PhoenixMage: I have not looked into details
ablu has quit [Ping timeout: 255 seconds]
ablu has joined #yocto
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #yocto
sakman has joined #yocto
<PhoenixMage>
khem: no worries
Alexwarrior has quit [Ping timeout: 245 seconds]
davidinux has quit [Ping timeout: 255 seconds]
davidinux has joined #yocto
ptsneves has joined #yocto
Chaser has joined #yocto
Chaser has quit [Remote host closed the connection]
Chaser has joined #yocto
Chaser has quit [Client Quit]
camus has quit [Quit: camus]
camus has joined #yocto
Chaser has joined #yocto
alessioigor has joined #yocto
linfax_ has joined #yocto
rfuentess has joined #yocto
tnovotny has joined #yocto
mckoan|away is now known as mckoan
goliath has joined #yocto
frieder has joined #yocto
rob_w has joined #yocto
silbe has quit [Ping timeout: 240 seconds]
danlor has joined #yocto
zpfvo has joined #yocto
Kubu_work has joined #yocto
mvlad has joined #yocto
emdevt has quit [Quit: Leaving]
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
mrnuke has quit [Ping timeout: 240 seconds]
leon-anavi has joined #yocto
danlor has quit [Ping timeout: 245 seconds]
mrnuke has joined #yocto
danlor has joined #yocto
varjag has joined #yocto
florian_kc has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
brrm has quit [Ping timeout: 240 seconds]
florian_kc has quit [Ping timeout: 248 seconds]
brrm has joined #yocto
prabhakarlad has joined #yocto
zpfvo has joined #yocto
camus has quit [Read error: Connection reset by peer]
camus1 has joined #yocto
camus1 is now known as camus
florian_kc has joined #yocto
ptsneves has quit [Ping timeout: 240 seconds]
mbulut has joined #yocto
<rburton>
mischief: a build from sstate won't touch autoconf
florian_kc is now known as florian
<rburton>
mischief: if you're not building an image from sstate in single-digit numbers then either the image is huge, you've some slow postinst tasks, or some recipes are not being pulled from sstate
<rburton>
(my personal record is <30s on a ryzen with nvme for core-image-sato from sstate)
danlor has quit [Quit: Client closed]
florian_kc has joined #yocto
ptsneves has joined #yocto
zpfvo has quit [Ping timeout: 258 seconds]
Chaser has quit [Remote host closed the connection]
Chaser has joined #yocto
zpfvo has joined #yocto
<kanavin>
I suspect a large chunk of those 10 minutes is in do_rootfs
<kanavin>
every sometimes I wish for a package manager that can parallelize installation of packages, but alas it does not exist
<kanavin>
it's a 'for p in packages:' affair for all of them
<rburton>
i wonder if apk is faster
xmn has quit [Ping timeout: 260 seconds]
<JaMa>
IMAGE_FSTYPES can also take a while especially if you're building many
danlor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<ablu>
iirc there was some way to specify in a .wks.in file to put the content of a certain folder into a partition... But I cannot figure out how that worked again... Does anyone have a pointer?
<ablu>
I think it was something like "--use-this-folder=$ROOTFS_DIR/usr/"...
danlor has quit [Quit: Client closed]
danlor has joined #yocto
<ptsneves>
ablu: I would do that with the deploy task and then use that deploy's contents
<ptsneves>
the rootfs filesystem is nothing about folders.
<ablu>
ptsneves: Hm. What I am looking for is the syntax for the .wks.in file to specify that folders.
<ablu>
Maybe I built an image when I last did it... My brain starts failling.
<ablu>
In the end I only want to include everything under "/usr/" in a specific partition.
<PhoenixMage>
If I add a package to RDEPEND of a recipe that is included in my image shouldnt that RDEPENDS package get added to the image automatically?
silbe has joined #yocto
<danlor>
PhoenixMage yes, it should
<danlor>
I've been fiddling with the package classes and checking do_rootfs task logs. The pkg_postinst scriptlets are handled in a different way if deb or rpm package class is used. The postinst runs just after pacakage installation if rpm but, if deb, the postinst are executed in alphabetical order after all packages have been installed. This could break
<danlor>
some packages where the postinst execution order matters or that share configs or mechanisms when using package-deb as the package class, couldn't it?
<rburton>
don't rely on execution order
<danlor>
Yep, I always try to follow that recommendation. But I'm experiencing some troubles with the ca-certificates and ca-certificates-java packages for example. The first one is rdepended by the latter. Both have their own pkg_postinst scripts.
<danlor>
The java one installs a cert update hook and rely on the update mechanism of the ca-certificates package.
<rburton>
does the java one just install the hook, or also invoke the update?
manuel1985 has joined #yocto
<danlor>
It just installs the hook, but creates its trust store in its pkg_postinst
<danlor>
Hence, when the ca-certificates invokes the update in its pkg_postinst, the java hook is already there
<danlor>
But not ready
<danlor>
To be executed
<rburton>
the hook should handle that case then
<danlor>
Agree
<rburton>
just make it print a message that its skipping so its obvious to someone debugging it later :)
zpfvo has quit [Ping timeout: 240 seconds]
ptsneves has quit [Ping timeout: 248 seconds]
<danlor>
Yes, I'll do that. Ty!
zpfvo has joined #yocto
danlor has quit [Quit: Client closed]
Net147 has quit [Quit: Quit]
manuel_ has joined #yocto
manuel1985 has quit [Ping timeout: 255 seconds]
danlor has joined #yocto
<PhoenixMage>
Why would a package not show up in the image manifest? Its definitely installed on the image...
mbulut has quit [Remote host closed the connection]
mbulut has joined #yocto
sng_ has joined #yocto
sng has quit [Read error: Connection reset by peer]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
Net147 has quit [Quit: Quit]
Net147 has joined #yocto
Net147 has quit [Changing host]
Net147 has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
bhstalel has joined #yocto
bhstalel has quit [Quit: Client closed]
Tyaku has joined #yocto
vladest has quit [Remote host closed the connection]
Estrella___ has quit [Remote host closed the connection]
Estrella_ has joined #yocto
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
zpfvo has quit [Ping timeout: 255 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 255 seconds]
rob_w has quit [Remote host closed the connection]
zpfvo has joined #yocto
prabhakarlad has quit [Quit: Client closed]
Rich_1234 has quit [Quit: Connection closed]
Rich_1234 has joined #yocto
jmiehe has joined #yocto
mbulut has quit [Quit: Leaving]
bhstalel has joined #yocto
jmiehe has quit [Quit: jmiehe]
linfax_ has quit [Ping timeout: 260 seconds]
goliath has joined #yocto
paulg has joined #yocto
danlor has joined #yocto
Danct12 has quit [Read error: Connection reset by peer]
Perflosopher has quit [Read error: Connection reset by peer]
Perflosopher has joined #yocto
danlor has quit [Quit: Client closed]
frieder has quit [Remote host closed the connection]
ptsneves has quit [Ping timeout: 258 seconds]
Danct12 has joined #yocto
Guest21 has joined #yocto
<Guest21>
Strange “nothing RPROVIDES image-name” error when bitbake image-name and image-name.bb exists in meta-layername/recipes-core/images
<Guest21>
What am I missing here ?
<Guest21>
image-name is a copy of image-dev-name which lives in the same directory and works perfectly …
<Guest21>
Both .bb obviously
<rburton>
the error says *R*PROVIDES?
<rburton>
that's a bug in your recipe
<Guest21>
Sorry no PROVIDES
mckoan is now known as mckoan|away
<rburton>
tried bitbake-layers show-recipes
<Guest21>
rburton: At the moment image-name.bb is a prefect copy of image-dev-name.bb which works
<rburton>
does it do something like setting PN explictly to change the recipe name?
Danct12 has quit [Quit: A-lined: This user has been AVIVA-lined!]
<Guest21>
rburton: bitbake-layers show recipes image-name returns an empty string however image-dev-name works
Guest21 has quit [Quit: Client closed]
Guest21 has joined #yocto
<rburton>
your layer.conf might be using very strict globs so excluding the recipe, or the recipe sets PN and changes its name
<Guest21>
rburton sorry got disconnected
<rburton>
your layer.conf might be using very strict globs so excluding the recipe, or the recipe sets PN and changes its name
<bhstalel>
Maybe image-name is not in PROVIDES ? PN is default of PROVIDES, so PN may be changed in the recipe, check: "bitbake -e image-name | grep ^PN=" and "bitbake -e image-name | grep ^PROVIDES="
zpfvo has quit [Remote host closed the connection]
alessioigor has quit [Quit: alessioigor]
florian_kc has quit [Ping timeout: 260 seconds]
alessioigor has joined #yocto
Danct12 has joined #yocto
<Guest21>
First command returns PN=image-dev-name for bitbake -e image-dev name and error nothing provide image-name for image-name
<Guest21>
Bitbake-getvar -r image-name PN returns an error as well
<rburton>
none of the commands will work if bitbak can't see your recipe
<rburton>
so as i said, check your layer.conf doesn't do something stupid, and then check the recipe doesn't set PN to change the recipe name
leon-anavi has quit [Quit: Leaving]
<Guest21>
neither the recipe or layer.conf modify anything
<Guest21>
What else could stop the recipe being seen by bitbake?
<rburton>
empty the recipe and see what happens
<Guest21>
Empty recipe with just a DESCRIPTION line still not detected
<rburton>
what does the layer.conf set BBFILES to?
<khem>
locally ptest image runs show no issues for me
Guest21 has quit [Quit: Client closed]
goliath has quit [Quit: SIGSEGV]
Guest21 has joined #yocto
<Guest21>
Got disconnected did I miss any suggestion?
<Guest21>
Apparently not :-(
Guest21 has quit [Quit: Client closed]
prabhakarlad has joined #yocto
goliath has joined #yocto
PhoenixMage has quit [Ping timeout: 255 seconds]
PhoenixMage has joined #yocto
<rburton>
Guest33: can you share the image recipe itself?
<mischief>
hm. i checked the buildstats thingy with the pybootchartgui. shows 142s for do_rootfs
<mischief>
i suppose apt is a bit slow
<khem>
mischief: yeah try with opkg backend
<mischief>
is there a way to prevent split packages we won't need? can we just remove the PACKAGES somehow?
<rburton>
they won't be installed so it's just a one-off hit when the recipe is actually built
<rburton>
unless the component takes forever to build or has big dependencies, in which case ideally add a PACKAGECONFIG. changing PACKAGES won't do anything apart from move files or error out with files not being packaged.
<mischief>
some are built quite often
<mischief>
and some of the -dbg packages are up to 50M :-)
<rburton>
sure, but you're only installing them when required, and 50M is nothing
<mischief>
it's time spent to actually do the packaging
<rburton>
now piglit had a 2GB debug package of 99.9% identical generated code, so i turned off debug for that
<mischief>
we don't actually save packages from the deploy dir anywhere so they are reconstructed from sstate every build
<rburton>
packages come from sstate
<rburton>
DEBUG_FLAGS="" will remove all debug flags and you'll build no debug symbols at all, so there'll be nothing to strip. asserting that you'll never need symbols is a strong move, but would save a small amount of time/io.
<rburton>
in case i wasn't clear, if you build an image from sstate then the packages are taken from sstate and the image built from those
<rburton>
deploy is in tmp, therefore transient and generated
<mischief>
in the future we might proceed with PACKAGE_MINIDEBUGINFO
<mischief>
today we don't use -dbg at all anywhere
<bhstalel>
Is there a plan to support DEPLOY_DIR_TAR ? I mean support generating tar files from recipes ? Maybe creating package_tar class ?
<rburton>
bhstalel: how would it contain dependencies between packages?
<rburton>
bhstalel: see 90ce19122802a16e6067f3a2ce3447acf1070fe5 :)
<bhstalel>
What project is 90ce19122802a16e6067f3a2ce3447acf1070fe5 in ?
<rburton>
oe-core
<bhstalel>
meta-openembedded ?
<rburton>
no, openembedded-core
<bhstalel>
Now I see, I did not know it was tried before, but I think some clean is needed, because DEPLOY_DIR_TAR is still defined in bitbake.conf
<bhstalel>
I think I should send a patch
<rburton>
please do
<rburton>
for the use case of "i need this package in a plain tarball for <reasons> which don't involve an image", package_tar mostly worked. but nobody used it because it was broken for years at a time, so we removed it.
<Saur>
RP: Would you accept a patch such as https://pastebin.com/2qNCAAE1? After a colleague pointed out that we cannot enable 64 bit timeval for 32 bit products yet in our platform, I realized that we are probably not alone in that regard. And since there is no `uninclude`, having time64.inc included unconditionally from defaultsetup.conf makes it a bit involved to undo it.
<bhstalel>
rburton I am curious but how did you get the commit ID so fast ? hhh
<rburton>
bhstalel: git log --grep package_tar
florian_kc has joined #yocto
<bhstalel>
Aha 😃
<bhstalel>
Check the map that I sent in docs
<mischief>
ah, well. i guess no quick wins by removing debugging. trying ipk instead of deb now
<rburton>
mischief: i was about to say, my test of turning off debugging for systemd changed the numbers _slightly_
<mischief>
you're removing -g from the compiler invocation or something?
<rburton>
as i said, setting DEBUG_FLAGS=""
<rburton>
tested for just systemd by putting it in the recipe, but you could do it in the distro config and get no debug symbols anywhere
<rburton>
marginal gains and won't change rootfs generation in the slightest
<mischief>
is there a way to keep DEBUG_FLAGS so that PACKAGE_MINIDEBUGINFO would work, but skip the strip/package split for -dbg?
<mischief>
20% gain in packaging seems pretty good
<rburton>
package minidebuginfo does the same split surely
<rburton>
in fact its probably slower to build
<mischief>
rburton: minidebuginfo is injected as a section into the original binary
<mischief>
it is not split, which is why we are interested in using it
<rburton>
not sure i want to know why split matters ;)
<rburton>
INHIBIT_PACKAGE_DEBUG_SPLIT or INHIBIT_PACKAGE_STRIP probably
<rburton>
no idea how the minidebuginfo code _actually_ works and if it makes rash assumptions about where files ended up
bhstalel has quit [Ping timeout: 245 seconds]
Haxxa has quit [Quit: Haxxa flies away.]
<mischief>
my reading of package.bbclass says that it will not work if INHIBIT_PACKAGE_DEBUG_SPLIT is set since it uses the split-off .debug files
Haxxa has joined #yocto
<rburton>
as we've discovered, the splitting process isn't exactly slow
<mischief>
hm
<mischief>
66 seconds to package python3 with ipk :)
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
<mischief>
i will check the rootfs time once all this crap builds
Kubu_work has quit [Quit: Leaving.]
amitk has quit [Ping timeout: 252 seconds]
<mischief>
40 seconds faster for ipk :-)
<mischief>
is there any functional impact from changing from deb to ipk?
<rburton>
you can't use apt on target
<rburton>
if you're not using package management on target there's literally no difference
<rburton>
can i ask why you chose deb? it's not the default
<rburton>
(and the worst supported of the backends)
<mischief>
i have no recollection of why i picked that N years ago for this project
<mischief>
we don't use packaging on target, we're shipping dm-verity protected images anyway
<rburton>
yeah just use ipkg
<rburton>
its faster and the end result should be identical
bhstalel has joined #yocto
Chaser has quit [Quit: Chaser]
bhstalel has quit [Quit: Client closed]
bhstalel has joined #yocto
<JaMa>
Saur: I think you can add empty time64.inc in your DISTRO layer to avoid using it, right?
florian has quit [Killed (NickServ (GHOST command used by florian_kc!~florian@dynamic-093-132-095-131.93.132.pool.telefonica.de))]
florian_kc is now known as florian
florian_kc has joined #yocto
<Saur>
JaMa: Sure, but that is not too obvious to everyone. And it also relies on that the layers are specified in the correct order in BBLAYERS...
<JaMa>
non-existing timedefault.inc doesn't seem much more obvious to everyone
<Saur>
And yes, I have created a time64.inc wrapper that does basically what the patch above does. So I will manage.
<Saur>
Well, my idea was that you can set TIME_MODE to anything but "64" to disable the forced use of 64 bit time_t...
<Saur>
Obviously, if a variable like that is added, it should be documented.
<Saur>
(Off to pick up my kid from floorball practice.)
<zeddii>
tell me you are in Sweden without telling me you are in Sweden!
alessioigor has quit [Quit: alessioigor]
olani- has joined #yocto
olani- has quit [Remote host closed the connection]
olani- has joined #yocto
olani- has quit [Remote host closed the connection]
olani- has joined #yocto
goliath has quit [Quit: SIGSEGV]
shakta has joined #yocto
rber__ has joined #yocto
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
RobertBerger has quit [Ping timeout: 258 seconds]
<sudip>
I am now past the cmake error while trying to upgrade rpm, now at a python error, hopefully the last error
<sudip>
any idea what might be causing "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)" ?
<sudip>
I should not need to specify 32 or 64bit architecture in recipes
<shakta>
I have a bitbake recipe that builds and installs a simple C application. I also want to install a file containing the signature of the application binary. I tried adding a task after compile, before install that generate the signature file. I also extended the install step to install the signature file. The problem is....the application binary that
<shakta>
gets deployed is different than the one I signed. Do I need to move the signature creation task after package task or maybe even after deploy task then?
<mischief>
the program probably got stripped during packaging
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<shakta>
Yup, the binary is the same from compile and in staging. But after packaging it's size has decreased.
mvlad has quit [Remote host closed the connection]
<shakta>
This means I need to create & install the signature after packaging. Since packaging happens after install, it seems this can not be done by simply extending the applications recipe.
<mischief>
there's been some attempts at this kind of thing in the past, like elfsign and signelf
<mischief>
dunno your use case but you might be better served by dm-verity or dm-integrity if you control the fs images
<shakta>
Use case: verify signature of a handful of files on R/W file system from initramfs
<shakta>
dm-verity is no go because needs read only fs (IIRC)
zhmylove has joined #yocto
<shakta>
Haven't looked into dm-integrity or IMA/EVM
kevinrowland has joined #yocto
<shakta>
A manual signing/verify solution seems like the simplest solution to meet use case
<RP>
Saur: you can touch a file in your layer to replace the core one? I'd rather not make it too easy
<kevinrowland>
Is it possible to write a python script that, given a build directory, parses all recipes in BBLAYERS and then lets me basically.. inspect the datastore? Like what bitbake does when it checks that all dependencies of the target recipe are buildable (it will yell at you if one recipe DEPENDs on another recipe that doesn't exist). I assume it's
<kevinrowland>
possible, but wondering if there are any examples floating around.
<RP>
kevinrowland: the tinfoil api is what you want, there are a few tools using tinfoil of differing levels of complexity
<kevinrowland>
For some reason I thought there was a purpose-built python module to do stuff like this, but I'm having no luck googling and grepping
<kevinrowland>
tinfoil! that's the one
<kevinrowland>
RP: thanks very much, IO'
<kevinrowland>
I'll poke around*
<RP>
bitbake-getvar is a really simple one. devtool/recipetool are much more complex users
bhstalel has quit [Ping timeout: 245 seconds]
olani- has quit [Ping timeout: 260 seconds]
Xagen has joined #yocto
Xagen has quit [Client Quit]
Xagen has joined #yocto
paulg has quit [Ping timeout: 240 seconds]
sveinse has quit [Quit: leaving]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]