<JosefHolzmayr[m]>
wCPO: oh that was you sending the patch?
<wCPO>
JosefHolzmayr[m]: yep, need to contribute where you can.
<JosefHolzmayr[m]>
wCPO: thank you very much. this particular patch stood a bit out for me and brightened my morning. ping me when its merged, please.
<user123>
can anyocan anyone help me to resolve the error which i have put it in pastebin https://pastebin.com/8nW7cnDd i am facing this error when enabling multilib support for multimedia image.ne help me to resolve the error which i have put it in pastebin https://pastebin.com/8nW7cnDd
<user123>
<user123> i am facing this error when enabling multilib support for multimedia image.
camus has quit [Ping timeout: 240 seconds]
camus has joined #yocto
pgowda has quit [Ping timeout: 256 seconds]
<wCPO>
Is it recommend to using --in-reply-to for sending revised patches?
camus has quit [Ping timeout: 245 seconds]
<qschulz>
wCPO: -v 2 to git format-patch + optional --cc for each person that reviewed the earlier versions
<wCPO>
qschulz: gotcha, thanks!
<qschulz>
wCPO: if that is you who sent the extra-space patch, I was wondering if the extra-space shouldn't be expressed in terms of multiple of sector size?
<qschulz>
so basically, move the += extra-space before the *= sector_size
jmiehe has quit [Quit: jmiehe]
jmiehe has joined #yocto
lexano[m] has quit [Ping timeout: 250 seconds]
SamuelDolt[m] has quit [Ping timeout: 250 seconds]
kranzo[m] has quit [Ping timeout: 245 seconds]
hmw[m] has quit [Ping timeout: 245 seconds]
jonesv[m] has quit [Ping timeout: 245 seconds]
te_johan has joined #yocto
agherzan has quit [Ping timeout: 256 seconds]
twinning[m] has quit [Ping timeout: 252 seconds]
CarlesFernandez[ has quit [Ping timeout: 252 seconds]
<wCPO>
qschulz: I did consider it and accidentally did it (whoops 500GB image). Using just bytes is simpler I think (no 1GiB/512) and what happens if the sector size change (512->4096)? No sure the latter is a big concern tho
<qschulz>
I imagine the extra space to be specific to the machine and the image
<qschulz>
so if the sector size changes so should the extra-space?
kranzo[m] has joined #yocto
<qschulz>
maybe the other way around would be to align the extra-space on the sector size?
jonesv[m] has joined #yocto
moto_timo[m] has quit [Ping timeout: 245 seconds]
Saur[m] has quit [Ping timeout: 252 seconds]
Alban[m] has quit [Ping timeout: 252 seconds]
<qschulz>
and still express it in terms of bytes, just that it'll be rounded up to the next sector size?
kayterina has joined #yocto
agherzan has joined #yocto
<wCPO>
Hmm. WIC is already doing some aligning. I don't think it is a bit issue if the last sector isn't aligned, fdisk or whatever tool you are using would align it correctly
twinning[m] has joined #yocto
CarlesFernandez[ has joined #yocto
lexano[m] has joined #yocto
te_johan has quit [Ping timeout: 256 seconds]
hmw[m] has joined #yocto
Saur[m] has joined #yocto
Alban[m] has joined #yocto
moto_timo[m] has joined #yocto
SamuelDolt[m] has joined #yocto
tnovotny has joined #yocto
manuel1985 has joined #yocto
rostam98[m] has quit [Quit: You have been kicked for being idle]
<kanavin>
RP: I think to untangle the lttng-tools ptest fails I should go ahead, and compile it inside qemu, and run it the way it's suppose to. Fixing cryptic fails without a working reference point is a struggle (I fixed some that were obvious incorrect ptest packaging mistakes but more remain).
<RP>
kanavin: can we improve the logging to resolve the cryptic issues?
<RP>
kanavin: are you meaning doing that just to sort the issues or change the way that ptest works permanently?
<kanavin>
RP: I mean that to better understand why something fails I want to have a reference point where that same something works.
<manuel1985>
My CI is failing in the following way: `Exception: Exception: KeyError: 'getpwuid(): uid not found: 9999'`
<manuel1985>
Path . is owned by uid 9999, gid 9999, which doesn't match any user/group on target. This may be due to host contamination.
<RP>
kanavin: that seems sensible
<kanavin>
RP: and the best way to do that is to build and run tests from the source tree - that doesn't mean the ptest will do the same, just that I would hopefully understand what is wrong.
<manuel1985>
can multiple poky versions share the same sstate cache?
<manuel1985>
(not at the same time)
<kanavin>
RP: although making ptest re-build the tests is a tempting prospect :) there's a bit much custom tweaking going on there.
<manuel1985>
uid/gid 9999 exists on the build machine. It's the user the CI builds run in. But the build itself is dockerized. Yocto runs inside the kas contianer.
gsalazar has joined #yocto
<RP>
kanavin: I'd really prefer not to do that
<RP>
kanavin: working with upstream to declare the info we need to make the tweaking less needed may be an option if we could propose something neatish
mithro has quit []
<kanavin>
RP: is there a place where I can chat with upstream?
<qschulz>
manuel1985: yes multiple poky versions can reuse the same sstate cache directory but they won't reuse the sstate-cache because it is specific to poky versions (it's part of the filename of sstate cache entries)
<kanavin>
are they here?
mithro has joined #yocto
<manuel1985>
qschulz: Thank you
<kanavin>
RP: the good news is that so far I am not seeing sporadic fails: everything seems reproducible, and there are just 3 types of fail left
<kanavin>
all cryptic though
camus has joined #yocto
<RP>
kanavin: #lttng on oftc
<RP>
kanavin: they did used to be here but not since the libera move I think
user123 has quit [Ping timeout: 252 seconds]
Pierre-jeanTexie has quit [Ping timeout: 245 seconds]
Pierre-jeanTexie has joined #yocto
flynn378 has quit []
flynn378 has joined #yocto
Tartarus has quit []
Tartarus has joined #yocto
cengiz_io has quit []
cengiz_io has joined #yocto
te_johan has joined #yocto
camus has quit [Ping timeout: 256 seconds]
te_johan has quit [Ping timeout: 245 seconds]
camus has joined #yocto
eduardas has joined #yocto
<kanavin>
RP: thanks :) I built lttng-tools from source inside qemu, and 'make check' passed the tests with flying colours. The difference seems to be in ptest packaging somewhere...
Domon has joined #yocto
<kanavin>
no need to bother upstream yet then
<wCPO>
Is oe-selftest run from scratch over every run? I just ran a single test and it took 7547.129s. Now I tweaked the test and started oe-selftest again with specific test and it has already been running for +40 min.
<kanavin>
wCPO, depends on where your sstate is
<kanavin>
you need to take it somewhere where it can be shared between the runs
<wCPO>
kanavin: oh yeh, totally forgot to enable it for my openembedded-core repo :(
* wCPO
is still learning
<JaMa>
is there already bug report for duplicated/trippled logging from failed tasks? I think it was mentioned on ML long time ago, but cannot find that thread now
<wCPO>
"Build directory /foo/build-st already exists, aborting", do I need to remove it everytime I want to run oe-selftest?
<kanavin>
wCPO, generally, yes, but it's not a big deal if sstate is held outside of that dir
<kanavin>
there might be a switch to avoid that somewhere
<wCPO>
kanavin: --keep-builddir must be the option
<rburton>
that sounds like a bug tbh, it should be cleaned up
madisox has quit []
te_johan has quit [Ping timeout: 256 seconds]
madisox has joined #yocto
<wCPO>
rburton: I did Ctrl+c the oe-selftest, so likely it just didn't got to the delete part, also explain why there is a --keep-builddir option, but I still want it to reuse the sstate directory
<wCPO>
kanavin: oe-selftest creates the directory and local.conf (where the sstate directory is set), so I'm not exactly sure how to set a different sstate directory for it
BCMM has joined #yocto
<kanavin>
wCPO, it copies local.conf from your existing builddir
ad__ has quit [Quit: ZNC 1.7.2+deb3~bpo9+1 - https://znc.in]
ad__ has joined #yocto
camus has quit [Quit: camus]
rber|res has quit [Quit: Leaving]
rber|res has joined #yocto
<wCPO>
Is yocto automatically pulling in the -dev package when building a recipe?
jmiehe has quit [Remote host closed the connection]
<rburton>
wCPO: if you mean in DEPENDS, then DEPENDS is recipe not package
jmiehe has joined #yocto
paulg has joined #yocto
pgowda has joined #yocto
ad__ has joined #yocto
ad__ has quit [Changing host]
<wCPO>
rburton: so if the systemd recipe has DEPENDS = "util-linux" it will pull in util-linux-dev when building the systemd package?
<rburton>
sort of
<rburton>
it pulls in the sysroot for the util-linux recipe, which is similar to but is not the -dev package
<rburton>
the sysroot just needs the development headers/links, no binaries or data or anything else runtime
<wCPO>
rburton: thanks for the explanation, it make sense :)
abiliomarques has joined #yocto
<abiliomarques>
hi, I'm starting with Yocto, and I noticed something. With many layers coming from different sources, I might need to use some tool to keep track of them. For other projects I've used git submodules and repo, but was wondering if yocto has it's own way of working (similar to what you do with recipes, where you fetch source code from a remote)
<abiliomarques>
any advice?
<rburton>
submodules and repo works
<rburton>
kas is another alternative that also handles the configuration file for you
pgowda has quit [Ping timeout: 256 seconds]
pgowda has joined #yocto
prabhakarlad has quit [Quit: Client closed]
pgowda57 has joined #yocto
<abiliomarques>
thanks :)
pgowda57 has quit [Client Quit]
prabhakarlad has joined #yocto
<RP>
JaMa: I'm wondering if we could just get rid of BBINCLUDELOGS
te_johan has joined #yocto
<RP>
zeddii: is there a reason we're still on go 1.16.5 and not 1.16.7 ?
<zeddii>
nope. anything with 16.x shouldn't cause issues.
<RP>
There are open CVEs for 1.16.5 so upgrading would be nice :/
<RP>
kanavin: don't suppose you have that patch? :)
te_johan has quit [Ping timeout: 252 seconds]
* RP
finds a hardknott patch
Vonter has quit [Ping timeout: 250 seconds]
<abiliomarques>
I learn by example, and so I was wondering if there is any well structured yocto project that can serve as a "template" to start working on a custom distro
yates_work has joined #yocto
frieder has joined #yocto
<yates_work>
does yocto build cross-gcc for target T on host H using <build>/tmp/work/H-linux/gcc-cross-T?
<yates_work>
e.g., H = x86_64 and T = csky: <build>/tmp/work/x86_64-linux/gcc-cross-csky
<rburton>
pretty much yes
<JPEW>
The SBOM has landed!
<rburton>
yates_work: the gcc-cross recipe is actually gcc-cross-$TARGET, and all native stuff is in HOST-linux
<rburton>
JPEW: \o/
<RP>
JPEW: it has, thanks!
<JPEW>
Thanks to rburton and sgw; they did a lot of the smoke testing :)
<RP>
JPEW: you should have mentioned you needed it setting fire to! :)
Vonter has joined #yocto
<yates_work>
rburton: right, ok.
<yates_work>
rburton: i'm trying to wrap my head around whether this is true or false: when the cross gcc is built, it mostly used the (host-)native gcc, but implicit linker files such as crti.S must be assembled with an existing cross-assembler. True or False?
<rburton>
you don't need any cross tools to bootstrap
<yates_work>
i don't know what "bootstrap" means, but i am asking specifically about building the gcc cross compiler. i am having an issue with the cross-compiler that (i believe) goes back to how the crti.S is assembled, and i'm having trouble tracking down exactly where this happens.
<RP>
yates_work: gcc-cross depends on binutils-cross which providers a cross assembler and is built using the host gcc
<yates_work>
to make it a little more convoluted, it appears crti.S is assembled as part of the libgcc submake from (cross)-gcc's main Makefile.
<yates_work>
RP: ok, thanks - that makes sense.
sakoman has joined #yocto
<yates_work>
i patched gcc_10.3.bb with a bbappend to compile the crti.S (and crtn.S) with the -DPIC option: http://paste.debian.net/1210256/
<yates_work>
but apparently that patch is not making it into the cross-build of libgcc here: tmp/work/x86_64-linux/gcc-cross-csky/10.3.0-r0/gcc-10.3.0/build.x86_64-linux.csky-poky-linux/csky-poky-linux/libgcc/
<yates_work>
does the oe system use a different gcc recipe than gcc_10.3.bb when building these cross-components like libgcc?
<rburton>
there's a number of recipes in that folder
<rburton>
have a look and you'll see the split
<rburton>
hint: one of them is called libgcc :)
<yates_work>
rburton: ok thanks - i'll look
jwillikers has quit [Remote host closed the connection]
frieder has joined #yocto
<yates_work>
rburton: so meta/recipes-devtools/gcc/libgcc_10.3.bb is only used for the cross-build of libgcc (in the above-referenced folder)?
<yates_work>
(i realized since i joined the chat this morning that i really don't want to be patching the native gcc...)
jwillikers has joined #yocto
<yates_work>
help me! i'm in recipe hell! :)
roussinm has joined #yocto
<yates_work>
I'm like Lazarus asking for a drop of water on the tongue...
<yates_work>
rather, the rich man asking Lazarus for...
kayterina has quit [Remote host closed the connection]
cocoJoe has quit [Quit: Client closed]
<RP>
yates_work: gcc is a little special in that there is one "source" recipe in a shared workdir that powers them all
<RP>
yates_work: (gcc-source would be the one to patch)
<abiliomarques>
my qemu image doesn't seem to have DNS... any hint on why?
camus has joined #yocto
<kanavin>
abiliomarques, because the promise for qemu images is that they only connect to the host, not to the whole internet. You can manually fix this up if needed.
<abiliomarques>
@kanavin, any advice on how to do it?
<kanavin>
abiliomarques, what is the use case?
<abiliomarques>
just want to try running docker in a yocto built image... want to try fetching an image from dockerhub
<abiliomarques>
is just an experiment to check that I have everything properly set up before I go to real hardware
<kanavin>
abiliomarques, I've done this years ago so don't remember exactly. You need to set up DNS resolution config and check that the IP routing via host works.
<abiliomarques>
I did it inside of the image, even added dnsmasq to it, but it didn't help
<abiliomarques>
I can reach 1.1.1.1 and 8.8.8.8
<abiliomarques>
(ping)
<abiliomarques>
you mean /etc/resolv.conf?
<kanavin>
yeah
<kanavin>
but first check that you can reach other things than the host by ip address
<abiliomarques>
somehow I think I wrote /etc/resolv.conf bad ... now it seems to be working
<rburton>
RP: fix sent, and an improvement for spdx too
<rburton>
RP: sorry, i knew i had to fix that up but forgot :(
vd97 has quit [Quit: Client closed]
fabatera[m] has joined #yocto
te_johan has joined #yocto
vd has joined #yocto
<RP>
rburton: thanks, one of those thins
rfuentess has quit [Remote host closed the connection]
<RP>
rburton: spdx patch doens't apply
<rburton>
hm
<rburton>
oh pants, sorry
<rburton>
not my day, obviously!
<rburton>
i left half of the patches out :)
<rburton>
take the selftest fix, i have some branch wrangling to do for the spdx one
<RP>
rburton: done :)
<barath>
sry for butting in; does anyone know if there's a "best practices" type of guide for making sure sstate is reusable across hosts?
<barath>
building the same image first on host A, then trying to build the same on host B which has access to A's sstate-cache and host B still rebuilds a bunch of stuff... and I'm finding it difficult to manually compare sigdata and siginfo files
te_johan has quit [Ping timeout: 252 seconds]
<kanavin>
barath, it usually comes down to just a handful, or maybe only one recipe doing something non-deterministic, e.g. factoring the current timestamp into the build input
<kanavin>
you can try to see which is the first recipe that gets rebuilt, and that's probably the offending one
gsalazar has quit [Read error: Connection reset by peer]
<barath>
thanks kanavin, I've been trying that. guess I gotta try harder. would bitbake's -v flag be the best way to make sure that I dont miss what's rebuilt built first, or is there a better way/log?
<RP>
barath: look at the logs in tmp/log/cooker/
<vd>
how can I recompile only the DTS ?
<kanavin>
barath, a trick that may also work is setting up an identical build on the same host in a different build directory. If sstate works, you should only see setscene tasks.
<qschulz>
vd: use dtc manually?
<vd>
erk
<vd>
we're using a build system! :)
<barath>
thanks @RP, didn't know about the cooker
<barath>
and good point about trying it on the same host, though I'm pretty sure that works... I'll see. thanks both of you :)
mckoan is now known as mckoan|away
prabhakarlad has quit [Quit: Client closed]
eduardas has quit [Quit: Konversation terminated!]
tnovotny has quit [Quit: Leaving]
florian has quit [Quit: Ex-Chat]
arun has joined #yocto
arun has quit [Quit: Client closed]
ant__ has quit [Ping timeout: 252 seconds]
prabhakarlad has joined #yocto
manuel1985 has quit [Quit: Leaving]
<JPEW>
Am I going to run into a lot of problems if I do `SSTATE_SKIP_CREATION_task-populate-sdk = '0'` ?
<JPEW>
(I have an expensive SDK I want cached in sstate for... reasons)
<RP>
JPEW: I can't remember why we did that...
<JPEW>
I guess I'll try and see if it breaks :)
gsalazar_ has quit [Ping timeout: 240 seconds]
florian has joined #yocto
<sgw>
rburton: still around? Looks like your recipetool patch was incomplete and caused some failures in -next (maybe you arlready know)
whuang0389 has joined #yocto
florian has quit [Ping timeout: 244 seconds]
<vd>
does utf8.pm come with the "perl" recipe?
<vd>
yeah it install perl-module-utf8... somehow I have a /usr/bin/perl executable but not the ut8.pm module, weird.
te_johan has joined #yocto
<vd>
is that possible that I have perl but not perl-module-utf8 installed somehow?
te_johan has quit [Ping timeout: 252 seconds]
<smurray>
vd: iirc, you need to either specify specific modules' packages or the perl-modules sort of meta package to get modules beyond the very basic ones
<vd>
it seems weird that perl-module-utf8 isn't part of the very basic ones
<vd>
but ok thanks!
nerdboy has quit [Ping timeout: 250 seconds]
<smurray>
vd: it's packaging is very fine grained, as the whole set is quite large
nerdboy has joined #yocto
nerdboy has joined #yocto
vd has quit [Quit: Client closed]
jmiehe has quit [Ping timeout: 245 seconds]
whuang0389 has quit [Quit: Client closed]
<sgw>
rburton: I just figured out you had submitted an uipdated patch, and that worked locally for me!
vd has joined #yocto
<zeddii>
anyone have experience debugging the PR Service ? JPEW ? smurray ?
<smurray>
zeddii: what are you seeing?
<zeddii>
it not working! I'm doing something dense, and am just not seeing what's wrong. I'm trying to do some demo slides for the binary arfiacts ELC talk, and my efforts are crashing and burning.
<fray>
zeddii what do you need for it?
<zeddii>
what #@$@# doc is it described in ? the yocto manuals are returning me nothing when I search for it. I only get hits on the wiki, which I'm not sure is up to date.
<fray>
what part of it do you need docs for.. general usage/configuration or?
<zeddii>
just the setup as a start, so I can confirm I haven't f'd it up.
<smurray>
there's a section in the dev manual about it, but it's not super detailed
<fray>
normally I just follow what is in the local.conf.sample.extended
<zeddii>
at this point. I'm already composing my email to the LF apologizing for not having my recording and slides in on the 7th :D
<zeddii>
since I'm out of time and patience at the moment.
<zeddii>
which I guess proves the point of my talk ;)
<fray>
(I realize the above is far from an explanation, more of a 'do this')
<smurray>
in theory you just run bitbake-prserv with the ip/port to listen on and tell it the path to the sqlite db file
<zeddii>
yah. I set PRSERV_HOST = "localhost:0" in my local.conf, but I'm just not seeing PR bumps where I'd expect.
<fray>
(remote pr service is similar.. ya, as smurray said you can run it w/ an ip/port)
<zeddii>
maybe I need to rm -rf tmp and start a new build.
<fray>
PR numbers won't bump IF you have reproducible_builds enabled AND the output didn't change..
<fray>
so the old fashion 'touch this file' won't trigger the PR bump
<fray>
you need to change something in a file that is packaged to trigger a PR bump, as the system will hash the output and compare that to a hash of the last output.. if they are the same "hash-equivalency" kicks in and the new hash is set to be equivalent to the old hash.. and no PR
<fray>
(that behavior changed when hash equivalency went in roughly gatesgarth timeframe)
<zeddii>
should I see a pr-service process that stays alive after I've started it once ? or is it started and killed each time ?
<fray>
PR service will stay alive if you manually start it as a remote 'service'. Otherwise I believe it's transient during the build
<fray>
when I debug things, I usually run it as a 'remote' service with debug enabled.. then I can see connects/disconnects and such
<zeddii>
ah. and I don't have anything in my conf for hash equiv, that isn't needed for the pr service, right ?
<fray>
I think hash equivalency is on by default these days
<zeddii>
yah. that's what I thought, but I'm doubting everything now.
<fray>
if you need me to take a look at a config or other change, let me know
sakoman has quit [Quit: Leaving.]
<smurray>
hash equiv is turned on in poky.conf, but it's not on by default
<zeddii>
I'm using poky, so I should be covered.
<smurray>
the oe-selftest for prserv tests the modified source case, so it should be working
frieder has quit [Ping timeout: 252 seconds]
* zeddii
looks there.
<smurray>
it patches m4, iirc
amitk has quit [Remote host closed the connection]
sakoman has joined #yocto
te_johan has joined #yocto
te_johan has quit [Ping timeout: 256 seconds]
florian has joined #yocto
<mattsm>
Any idea why some pc (pkgconfigZ) files are not included in an SDK? I see the corresponding libs there so I'd think those would go hand in hand
te_johan has joined #yocto
te_johan has quit [Ping timeout: 252 seconds]
Vonter has quit [Ping timeout: 252 seconds]
frieder has joined #yocto
<mattsm>
I had to include the -dev package in the image for the sdk to contain the right pkgconfig file
frieder has quit [Remote host closed the connection]
jmiehe has joined #yocto
jmiehe has quit [Quit: jmiehe]
abiliomarques has quit [Ping timeout: 245 seconds]
florian has quit [Ping timeout: 252 seconds]
te_johan has joined #yocto
te_johan has quit [Ping timeout: 256 seconds]
alejandrohs has quit [Ping timeout: 250 seconds]
ant__ has joined #yocto
zyga-mbp has quit [Ping timeout: 244 seconds]
zyga-mbp has joined #yocto
vagaruy has joined #yocto
te_johan has joined #yocto
Gaffel has quit [Quit: What's that?]
vagaruy has quit [Remote host closed the connection]