Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
qschulz has quit [Remote host closed the connection]
qschulz has joined #yocto
<vmeson>
hmmm, while node executable seemed to decreases in size by ~6% with -fvisibility-inlines-hidden, webkitgtk's libwebkitgtk only decreases by 0.0017% -- I should probably do some completely seperate builds like I did for node. more tomorrow.
<Hubi>
I would like to build 2 images based on 2 different version of one recipe.
<Hubi>
recipe_4.10
<Hubi>
recipe_4.13
<Hubi>
when i try to build it one after another i get error
<Hubi>
644ERROR: recipe-4.10-r0 do_packagedata_setscene: QA Issue: Package version for package recipe-src went backwards which would break package feeds (from 0:4.13-r0 to 0:4.10-r0) [version-going-backwards]
<Hubi>
I try to force it via
<Hubi>
PREFERRED_VERSION_recipe = "4.13" but still same issue accure.
<Hubi>
any tip how to solve that problem?
rob_w has joined #yocto
Chaser has joined #yocto
frieder has joined #yocto
legraps has joined #yocto
joeythesaint has quit [Ping timeout: 260 seconds]
joeythesaint has joined #yocto
legraps_ has joined #yocto
goliath has joined #yocto
legraps has quit [Ping timeout: 252 seconds]
luc4 has joined #yocto
luc4 has quit [Client Quit]
c-thaler has joined #yocto
marka has quit [Ping timeout: 268 seconds]
marka has joined #yocto
leon-anavi has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
Hubi: AFAIK is normal, in such case run bitbake -c cleasstate recipe before building the image
Kubu_work has joined #yocto
ryanj has joined #yocto
mbulut has joined #yocto
<Hubi>
hi mckoan, i just did it b4 your message, and it works, thanks :)
paulg has joined #yocto
alessioigor has joined #yocto
ryanj has quit [Ping timeout: 256 seconds]
<qschulz>
khem: only aarch64 machines here
florian has joined #yocto
<qschulz>
khem: if I read the migration notes properly, I still need to lower OLDEST_KERNEL to match the kernels I'm building if they are <5.15
mvlad has joined #yocto
c-thaler has quit [Quit: Client closed]
<JaMa>
qschulz: correct
luc4 has joined #yocto
luc4 has quit [Client Quit]
MrCryo has joined #yocto
pvogelaar has quit [Ping timeout: 255 seconds]
mbulut_ has joined #yocto
mbulut has quit [Read error: Connection reset by peer]
pvogelaar has joined #yocto
pvogelaar has left #yocto [#yocto]
MrCryo has quit [Quit: MrCryo]
Hubi has quit [Quit: Client closed]
MrCryo has joined #yocto
legraps has joined #yocto
legraps_ has quit [Ping timeout: 268 seconds]
legraps_ has joined #yocto
legraps has quit [Ping timeout: 260 seconds]
prabhakalad has quit [Ping timeout: 256 seconds]
prabhakalad has joined #yocto
Saur_Home31 has quit [Quit: Client closed]
<RP>
qschulz: that would be my understanding too
Saur_Home31 has joined #yocto
alessioigor has quit [Quit: Client closed]
mvlad has quit [Remote host closed the connection]
c-thaler has joined #yocto
fabatera has joined #yocto
prabhakalad has quit [Ping timeout: 252 seconds]
<fabatera>
Hi, I'm getting the following error with nanbield:
<fabatera>
QA Issue: my_package package is not obeying usrmerge distro feature. /lib should be relocated to /usr. [usrmerge]
<rburton>
RP: is that a new worker? we've had that dependency in there for a long time. i wonder what changed...
sotaoverride is now known as Guest5498
Guest5498 has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
ctraven is now known as sotaoverride
sotaover1ide has joined #yocto
<RP>
rburton: is that a new BSP?
<rburton>
RP: yeah maybe we never even ran selftest with meta-arm around
<rburton>
i can make that testcase skip itself in that case
<RP>
rburton: I guess some workers have that present and some don't ?
<rburton>
yeah possibly
leon-anavi has quit [Quit: Leaving]
Saur_Home31 has quit [Quit: Client closed]
Saur_Home31 has joined #yocto
snowurm has quit [Ping timeout: 272 seconds]
linfax has joined #yocto
fabatera has quit [Quit: Client closed]
jmiehe has joined #yocto
tostr has joined #yocto
ehussain has quit [Ping timeout: 268 seconds]
jpuhlman has quit [Read error: Connection reset by peer]
ardo has joined #yocto
jpuhlman has joined #yocto
n245 has joined #yocto
<n245>
Hello, I am looking for information about how to contribute to docs.yoctoproject.org. In particular, I would like to add documentation for a variable which is still not documented.
<rburton>
because somehow I didn't know this and I'll share the knowledge: git-show can show specific files at specific SHAs with "git show ref:path"
<rburton>
so i'm now iterating through a list of shas and showing a json file which is piped into jq
<n245>
yocton and rburton, that was very useful. Thanks!
ardo has quit [Ping timeout: 268 seconds]
aardo has joined #yocto
n245 has left #yocto [#yocto]
<gmask>
Hi community! I'm struggling with some buildpath warnings while updating to scarthgap. Even in basic recipes, output `.debug` files contain absolute paths (the warning says they are "references to TMPDIR"). I thought that the default `DEBUG_PREFIX_MAP` (see `grep -RI prefix-map poky/meta/conf/bitbake.conf`) was enough to get rid of absolute paths in debug symbols, but it seems that there's something missing. Has anyone found this proble
<rob_w>
i want to specify a custom dir and its content to hte wks script as --source ... but i am to dump to figure out the syntax , any hints
<rburton>
gmask: absolutely depends on the build system. typically i've seen that where you also need to pass the mapping to an assembler if there's any .s files that get built. run strings on the file to identify what path it is, to give you a hint as to what bit of the build is failing to pass the right flags.
<rburton>
it could be a simple as a host path being written into generated sources which then end up in the debug symbols
<gmask>
rburton: it's a minimal recipe using make (base class). Only two c files in the source code. No .s files generated. When I compile it manually with the `-fdebug-prefix-map` it works, so it's sth in the yocto config that's off.
<gmask>
Checking the `log.do_compile` logs the flag is correctly passed to the build arguments... Is it possible that the `objcopy` used in `do_package` is somehow recreating those paths?
<RP>
gmask: which directory are you building these in? It isn't directly in WORKDIR with no subdirectory and S set to something else is it?
ryanj has joined #yocto
ryanj has quit [Quit: WeeChat 4.2.2]
<rburton>
gmask: bare make? have you verified that your gcc calls are actually passing the right flags?
<gmask>
RP: No, it uses the default `S=${WORKDIR}/${BPN}-${PV}`
c-thaler has quit [Quit: Client closed]
<gmask>
rburton: This is the weird thing. the `DEBUG_PREFIX_MAP` flags are only passed in the `cc file1.o file2.o -o prog` final compilation, but not in the production of the object files... I'm not sure why
<gmask>
rburton: So in log.do_compile I see three compilation steps: `cc file1.c -o file1.o`, `cc file2.c -o file2.o` and then `cc $DEBUG_PREFIX_MAP file1.o file2.o -o prog`
toric has joined #yocto
<rburton>
gmask: this is why makefiles are horrible. you need the flags to be used in the compile. they should be in CFLAGS, so the recipe needs to do the right thing to make the makefile use them
<RP>
gmask: are you using CFLAGS?
<gmask>
rburton: isn't this supposed to happen automatically? Any base recipe will create a `-dbg` package, so it's assumed that builds should have `DEBUG_FLAGS` in them right?
<rburton>
gmask: makefiles are terrible. if your makefile doesn't use $CFLAGS, or overwrites CFLAGS, then the flags won't be respected
<gmask>
RP: The Makefile has `CFLAGS` yes
<RP>
gmask: are you using our CFLAGS from the environment though? That variable contains the DEBUG_PREFIX_MAP entries
ryanj has joined #yocto
<gmask>
rburton: Is that it? If the Makefile has CFLAGS overwritten then the ones from bitbake are not used?
<rburton>
yes, that's how make works
<rburton>
(see my statement about how make is terrible)
<gmask>
rburton: Ok, I see the problem then... What is the correct way to append more flags from the recipe then?
<rburton>
eg the ifupdown recipe does this in do_compile: oe_runmake 'CC=${CC}' "CFLAGS=${CFLAGS}"
<rburton>
the correct way is to stop using make :)
<gmask>
Haha... I wish I could solve it this way
<tlwoerner>
what's the reasoning why COMPATIBLE_MACHINEs are often enclosed in parenthesis? (i need fodder for the commit message)
<rburton>
i _think_ its because sometimes you see (foo|bar) and then that got generalised to (foo) for no good reason
<rburton>
regex, init
<JaMa>
gmask: or EXTRA_OEMAKE
<RP>
tlwoerner: copy and paste incremental errors. They are regexes
<rburton>
RP: pexpect solution posted to our list, should be in meta-arm soon
rob_w has quit [Remote host closed the connection]
<RP>
rburton: great thanks!
dgriego has quit [Quit: Computer going to sleep]
dgriego has joined #yocto
<gmask>
JaMa: as rburton says, Makefiles are terrible. The src Makefile overrides CFLAGS but does not allow appending to them with some extra variable, so I have to completely rewrite them from the recipe. Not very maintainer-friendly...
<gmask>
rburton: thanks for the insight
<rburton>
i believe passing an explicit assignment to make (like ifupdown above) will overwrite what the makefile says
<rburton>
which works until the makefile also has flags it needs
<RP>
we used to use "make -e" as the default which forced our flags to overwrite
<toric>
so my work is using pseudo outside of yocto in a script that assembles some artifacts. I know we should probably be doing it inside yocto itself, but you work with what you got. Anyway, on one developer machine (mine), Im getting this error:
<toric>
Couldn't stash directory before opening socket: Permission deniedcritical failure: exec of pseudo daemon failed: Permission denied
<toric>
Ive been pulling my hair out for a week trying to figure out why pseudo is failing here, and was wondering if anyone here has seen this.
<JaMa>
gmask: and I agree with him, I'm just saying that you can use EXTRA_OEMAKE variable to pass the variables instead of adding them in each oe_runmake call
<gmask>
rburton: EXTRA_OEMAKE seems the "correct" way to do this. But as you say, you have to copy all the flags from the Makefile
<JaMa>
as some terrible Makefiles might also re-compile in do_install if you forget to pass some variables you did in do_compile
<gmask>
JaMa: Yes, I see it looks like the way to go
Xagen has joined #yocto
<tlwoerner>
RP: oh, are you saying the parenthesis aren't a good idea?
<nwhitlockeizo>
hello. i'm having a problem running qemu with my built yocto setup.
<nwhitlockeizo>
I'm trying to use vfio passthrough to pass a PCI device
<nwhitlockeizo>
`runqemu core-image-x11 nographic qemuparams="-device vfio-pci,host=04:00.0,id=mydevice"` is what i'm using to run it
<nwhitlockeizo>
It's failing with this: `qemu-system-x86_64: -device vfio-pci,host=04:00.0,id=mydevice: vfio 0000:04:00.0: failed to open /dev/vfio/1: Permission denied`
<fullstop>
Would it be possible to make a bbclass which relocates a package? That is, something which will modify the install directory by prepending a string to the path? For example, if a package installed /usr/bin/bash it could be modified to be /app/bin/bash.
<fullstop>
I understand that some paths could be set in config files, etc, but I'm breaking some things out to a separate partition and it would be nice if I could extend a recipe and add a class rather than changing every path.
<JaMa>
gmask: EXTRA_OEMAKE is just to pass some OE variables into make, you still use CFLAGS as before, e.g. EXTRA_OEMAKE = "CFLAGS=${CFLAGS}"
<JaMa>
gmask: and oe_runmake will add them to make command lines
legraps_ has quit [Read error: Connection reset by peer]
sakoman has quit [Ping timeout: 260 seconds]
alessioigor has quit [Quit: Client closed]
Saur_Home31 has quit [Quit: Client closed]
Saur_Home31 has joined #yocto
jmiehe has quit [Quit: jmiehe]
sakoman has joined #yocto
mbulut_ has quit [Ping timeout: 255 seconds]
zpfvo has quit [Remote host closed the connection]
linfax has quit [Ping timeout: 255 seconds]
florian has quit [Quit: Ex-Chat]
rfuentess has quit [Remote host closed the connection]
<rburton>
fullstop: have you tried writing said class and just setting prefix="/app" in it?
fabatera has joined #yocto
<fabatera>
Hi , the error below doesn't make much sense (to me)
<fabatera>
`QA Issue: mypackage package is not obeying usrmerge distro feature. /lib should be relocated to /usr`
<fabatera>
As it only happens when installing to /lib explicitly and not when installing to ${nonarch_base_libdir} (which is /lib in my case)
mckoan is now known as mckoan|away
<fabatera>
The message is misleading, IMO
<rburton>
fabatera: are you sure your nonarch_base_libdir is actually resolving to just /lib? The check looks at the final paths and doesn't care what variable gets used.
<fullstop>
rburton: I have not, but I will.
<qschulz>
how do i debug bitbake refusing to run because of hashserv connection refused?
<qschulz>
(all local, already removed the sock file by hand to no avail)
<fabatera>
rburton you are right, now is /usr/lib (in nanbield)
<qschulz>
(in kas-container)
<JaMa>
fabatera: it's /usr/lib with usrmerge in DISTRO_FEATURES which is included since nanbield (because of systemd)
toric has quit [Remote host closed the connection]
<fabatera>
Just saw that. :) Good to know the reason. Thanks!
<rburton>
use variables, never hardcode a path
<fabatera>
Sure thing, thanks
jmd has joined #yocto
toric has joined #yocto
alessioigor has joined #yocto
<qschulz>
rm -rf cache/ tmp/ made it work /me shrugs
frieder has quit [Remote host closed the connection]
snowurm has joined #yocto
fabatera has quit [Quit: Client closed]
<RP>
qschulz: were there processes left running?
<qschulz>
RP: not possible as I restarted multiple times the container
<RP>
hmm, very strange
<qschulz>
yes, BUT there's a very small chance I had two containers running on the same directories, and also I have no clue how I managed to get into this situation, so I guess let's ignore it until it comes back :)
Saur_Home31 has quit [Quit: Client closed]
Saur_Home31 has joined #yocto
Kubu_work has quit [Quit: Leaving.]
jmiehe has joined #yocto
Saur_Home31 has quit [Quit: Client closed]
Saur_Home31 has joined #yocto
alessioigor has quit [Quit: Client closed]
<yudjinn>
hey I have a conf file I generate from a task. When making a change to the task and rerunning, it doesnt regenerate the file (e.g. the task never reruns as the cache doesnt identify a change)
MrCryo has quit [Quit: MrCryo]
MrCryo has joined #yocto
MrCryo has quit [Remote host closed the connection]
MrCryo has joined #yocto
jmiehe has quit [Quit: jmiehe]
florian has joined #yocto
<qschulz>
what do you do when "making a change to the task"?
<qschulz>
a good thing would be to give a before/after change of your task/recipe so we can see what's happening
<qschulz>
yudjinn: ^
ryanj has quit [Quit: WeeChat 4.2.2]
ryanj has joined #yocto
<yudjinn>
i.e. just changing the function to print "hello" instead of "world" is not seen as a change. this is a `def`'d function called by a task
<yudjinn>
sorry, its IP so I cant share the exact setup, but I can put together an example possibly
<qschulz>
yudjinn: is the task python or shell, is the function pyhon or shell
<qschulz>
and how do you call the function from the task?
<qschulz>
yudjinn: 1) is your function called as the last step of the task?
<yudjinn>
no its right before do_configure and after do_fetch
<yudjinn>
I just did ... in the pastebin figuring it didnt matter
<qschulz>
yudjinn: I meant is make_conf the last instruction in do_make_conf_special
<qschulz>
because if so, you could use do_make_conf_special[postfuncs] += instead
<qschulz>
or even make it a separate task that runs after
<yudjinn>
no, its more like `if PATH is something: make_conf(PATH) else: make_conf(DIFFERENT)`
<yudjinn>
`make_conf` here is just a helper func
<qschulz>
yudjinn: ok, so I think BitBake may not be capable to know that make_conf is a function defined in your file and therefore should be watched over like that
<qschulz>
Now I'm just speculating
<qschulz>
I **think** you could use bb.build.exec_func('make_conf', d) instead of 'make_conf'?
<yudjinn>
so instead of `make_conf(PATH)` do `bb.build.exec_func('make_conf',d) ?
<qschulz>
but also not sure if this watches the content of make_conf
<qschulz>
yudjinn: yes
<qschulz>
yudjinn: you can check with bitbake-dumpsig/bitbake-diffsigs if your changes are taken into account without rebuilding the whole recipe/image
<qschulz>
this is a mechanism that is usually used to have both python and shell code within the same task, but maybe this does enough for invalidating the cache
<qschulz>
otherwise, I would recommend to send a small mail to our ML with a very small example to reproduce this error on master branch with only poky/openembedded-core to reach a few more people (a good chunk of the community is in Europe, and it's currently 8pm so outside of working hours :) )
<qschulz>
which is my hint to leave, so good luck :)
ptsneves has joined #yocto
<yudjinn>
that dumpsig is super helpful, thanks!
snowurm has quit [Ping timeout: 252 seconds]
MrCryo has quit [Quit: MrCryo]
MrCryo has joined #yocto
<geoffhp>
/quit
geoffhp has quit [Quit: Leaving]
florian has quit [Ping timeout: 240 seconds]
snowurm has joined #yocto
MrCryo has quit [Remote host closed the connection]
<dvergatal>
hi all I have created my own recipe for vault pkcs11 provider from hashicrop and I'm having a stupid issue, meaning I have set PACKAGES variable like PACKAGES =+ "${PN} ${PN}-swupdate" and BBCLASSEXTEND = "native nativesdk", and some other recipe is depending on vault-pkcs11-provider-swupdate-native but I'm getting this err that https://pastebin.com/ERcTZ1vL
florian has joined #yocto
berton has quit [Quit: Connection closed for inactivity]
<dvergatal>
ahhh I'm a morron... now I get what is going on DEPENDS is actually installing the whole content of recipe so I should use recipe name instead of package name
jmd has quit [Remote host closed the connection]
toric has quit [Remote host closed the connection]
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
toric has joined #yocto
mvlad has quit [Remote host closed the connection]
pbiel has quit [Ping timeout: 268 seconds]
snowurm has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]