<DvorkinDmitry>
I have an app without ./configure. It is installed with "make install" only. So "prefix" is not exist at final step. How can I set it correctly?
manuel_ has joined #yocto
<LetoThe2nd>
DvorkinDmitry: it should be available direcly in ${prefix}
leon-anavi has joined #yocto
<DvorkinDmitry>
LetoThe2nd, ok. But I have to modify default call "make DESTDIR=${D}" somehow. How to do it correctly?
xmn has quit [Ping timeout: 260 seconds]
<DvorkinDmitry>
"make DESTDIR=${D} install", i mean
goliath has joined #yocto
<LetoThe2nd>
DvorkinDmitry: why not just provide a custom do_install?
otavio has quit [Ping timeout: 256 seconds]
otavio has joined #yocto
<DvorkinDmitry>
LetoThe2nd, no problem. But what is the preoper destination macro? the tool should be installed as -native too, so I need to write DESTDIR=${D}/<prefix> somehow correctly
<LetoThe2nd>
DvorkinDmitry: already said: ${prefix}. so supposedly ${D}/${prefix}
<DvorkinDmitry>
LetoThe2nd, thank you
<LetoThe2nd>
DvorkinDmitry: please inspect the values before blindly copying, though.
zpfvo has quit [Ping timeout: 260 seconds]
<DvorkinDmitry>
LetoThe2nd, the installation path is correct, but it does not finally exists at myimage/recipe-sysroot-native/ anyway. The tool is needed to build the final image
zpfvo has joined #yocto
gho has quit [Quit: Leaving.]
<LetoThe2nd>
DvorkinDmitry: then you probably also need to look into packaging.
<DvorkinDmitry>
LetoThe2nd, what may be wrong there?
gho has joined #yocto
<LetoThe2nd>
DvorkinDmitry: no idea right off the cuff and distracted now, sorry.
<DvorkinDmitry>
LetoThe2nd, the tool should be just exist in the image builddir to be available for the image creation cmd IMAGE_CMD_my
<DvorkinDmitry>
LetoThe2nd, wow! If I write oe_runmake 'DESTDIR=${D}/${bindir}' install it appeared!
<DvorkinDmitry>
when It was oe_runmake 'DESTDIR=${D}/${prefix}' install it did not installed.. hmmm
kotylamichal has joined #yocto
Guest9123 has joined #yocto
<PhoenixMage>
FYI there is an entry in the 4.0 release notes "u-boot: Convert ${UBOOT_ENV}.cmd into ${UBOOT_ENV}.scr" but no doco on it.
<PhoenixMage>
To the source code we go!
Guest9123 has quit [Quit: Client closed]
jpman has joined #yocto
<jpman>
Hello! I have some questions regarding running unit tests for a custom application in a CI environment.
<jpman>
I can build the application and the unit tests for target using the generated SDK. But I would also like to build the unit tests for x86 so they can run directly in the CI environment.
<jpman>
The problem is getting all the dependencies setup correctly with the same versions and configurations as on the target.
<jpman>
I tried to do it manually, but I was thinking bitbake could help with this?
<kotylamichal>
Hi, I found an issue (probably) with devtool and want to ask if it is the correct behavior or maybe I should create bugzilla issue/patch on ML. In short version: create recipe libcryptopp_6.0.0.bb → run devtool modify libcryptopp → change version of .bb file to libcryptopp_8.7.bb → exit from Yocto shell (i use KAS container for that) → enter again to Yocto shell. Now I got an error with no recipe for append file libcryptopp_6.0.
<kotylamichal>
0.bbappend created in workspace/appends folder
<qschulz>
kotylamichal: tha'ts expected
<qschulz>
devtool is creating a bbappend for the recipe in the devtool workspace
<qschulz>
if you remove the recipe onto which the bbappend should apply, bitbake will throw an error
<qschulz>
it is not related to devtool, just to the mechanism devtool is using under the hood (bbappends)
<qschulz>
kotylamichal: what would you have expected to happen, maybe there's something we can do/think about to align with user expectations
<kotylamichal>
qschulz: hmm, maybe it will be better to remove all recipename_*.bbappend from worspace/appends during executing `devtool reset recipename` ? I tried this and doesnt work in my case, removing this file manually was only one solution
d-s-e has joined #yocto
<qschulz>
This is a reasonable request I'd say. Maybe you can open a bug/feature request on our bugzilla but FYI, AFAIR, devtool is not receiving much love lately :/
hiyorijl[m] has quit [Read error: Software caused connection abort]
hiyorijl[m] has joined #yocto
gho has quit [Ping timeout: 260 seconds]
florian has joined #yocto
<kotylamichal>
qschulz: thanks, I will do that
gho has joined #yocto
<rburton>
DvorkinDmitry: can you point us to the makefile that you're trying to install? for plain makefiles there is no standard, so you can't ask us: you have to read the makefile
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
manuel__ has joined #yocto
Payam has joined #yocto
manuel_ has quit [Ping timeout: 260 seconds]
ejoerns[m] has quit [Read error: Software caused connection abort]
ejoerns[m] has joined #yocto
zpfvo has quit [Ping timeout: 240 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
Guest28 has joined #yocto
gho has quit [Ping timeout: 268 seconds]
d-s-e has quit [Ping timeout: 260 seconds]
<rburton>
RP: so i can replicate the weird hashequiv behaviour with langdale. you need a buildtree to hand so it just repackages lots.
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<RP>
rburton: right, sounds like we need to debug it
<rburton>
found a bug in a bbdebug call
<rburton>
WARNING: Invalid arguments in bbdebug: (1, 2, 'Found unihash 5a0d0d2be865d66404e423a9f54a48456215fabd00488b6a5ff21f38c84d120f in place of 5a0d0d2be865d66404e423a9f54a48456215fabd00488b6a5ff21f38c84d120f for /home/ross/Yocto/poky-langdale/meta/recipes-core/glibc/cross-localedef-native_2.36.bb:do_populate_sysroot from unix:///yocto/ross/build-langdale/hashserve.sock')
jpman has quit [Ping timeout: 260 seconds]
gho has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
seninha has joined #yocto
<rburton>
bitbake could do with finer grained structured logging so i can filter the logs easily after the event
zpfvo has joined #yocto
rob_w has quit [Remote host closed the connection]
gho has quit [Ping timeout: 248 seconds]
gho has joined #yocto
ericson2314 has quit [Read error: Software caused connection abort]
ericson2314 has joined #yocto
<rburton>
huh wtf
<rburton>
RP: either something weird is happening or my brain needs another coffee
<rburton>
siggen.py does hashequiv_logger.debug((1, 2)[unihash == taskhash], 'Found unihash ...")
<rburton>
so depending on that test passes 1 or 2 as the first argument
<rburton>
but the debug function warns
<rburton>
Invalid arguments in bbdebug: (1, 2, 'Found unihash ...')
<rburton>
ah, i think there's a wrapper function
<rburton>
yes
<RP>
rburton: I think we got rid of the levels stuff so that might no longer work
<rburton>
yeah .debug() doesn't want a level, i think it needs to call bbdebug directly
<RP>
should now be debug() or debug2()
<RP>
we were trying to make the logger more standard python iirc
<rburton>
RP: iptables is a recipe which starts needing a rebuild, hashequiv kicks in a changes the unihash, does everything from sstate, then decides to run do_package anyway
mvlad has joined #yocto
<PhoenixMage>
I have added kernel-modules to MACHINE_EXTRA_RRECOMMENDS which to my understanding means I should get ALL my kernel modules in /lib/modules/* but I am only getting a few. How can I fix it?
<RP>
rburton: first task to run is libgcc do_package
<qschulz>
PhoenixMage: all that are built and if they aren't added to a blocklist such as BAD_RECOMMENDATIONS
<qschulz>
I am not sure if kernel-modules only brings in the kernel modules built by the kernel recipe or also the ones from out-of-tree kernel drivers (I would intuitively say only the ones from the kernel recipe)
<PhoenixMage>
qschulz: I have a heap (icluding nic drivers) that are in modules*tgz that were built in the kernel tree but dont get installed
<RP>
rburton: yet NOTE: Setscene task /home/ross/Yocto/poky-langdale/meta/recipes-devtools/gcc/libgcc_12.2.bb:do_package became valid
<PhoenixMage>
atm I mount the emmc and manually untar them to get my nic to work which is not the workflow I am after lol
gsalazar has quit [Remote host closed the connection]
<RP>
DEBUG: SState: Found valid sstate file /yocto/ross/sstate/6c/e3/sstate:libgcc:core2-64-poky-linux:12.2.0:r0:core2-64:10:6ce3d3175929641684794ed2ed62e3588720c59154d884d146a5e66e254304ab_package.tar.zst
<RP>
DEBUG: Stampfile /yocto/ross/build-langdale/tmp/stamps/core2-64-poky-linux/libgcc/12.2.0-r0.do_package.6ce3d3175929641684794ed2ed62e3588720c59154d884d146a5e66e254304ab not available
<RP>
rburton: the question is why did it skip libgcc do_package from sstate even though it was there
gsalazar has joined #yocto
alessioigor has quit [Quit: alessioigor]
<RP>
rburton: can't tell from the log, will need debugging :(
<rburton>
urgh
<rburton>
my reproducer is bitbake core-image-minimal, add "true" to autoconf's update_gnu_config(), bitbake core-image-minimal.
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #yocto
tomzy_0 has quit [Quit: Client closed]
<rburton>
RP: i wondered if it was the image's recrdeptask on do_packagedata that was upsetting it
<RP>
rburton: do_package is an odd one as in theory it isn't needed if package_qa, package_write_rpm and others are available
Guest28 has quit [Quit: Client closed]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
<RP>
rburton: I audited the runqueue codepaths and an going to try with a little more debug added, I could spot some paths which don't have logging
<RP>
I worry one of them is a harddeps one :(
<RP>
rburton: DEBUG: /media/build1/poky-langdale/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.19.bb:do_package has an unavailable hard dependency so skipping
<RP>
rburton: this is what I was afraid of
<RP>
linux-libc-headers was the first thing to repackage in my build
<rburton>
grumbles at langdale on aarch64 only getting 43% sstate usage against the AB
<rburton>
i wonder if i actually let it run, will the equiv give me more
<rburton>
maybe i should try that
hcg has joined #yocto
<rburton>
RP: -DDD log is quite moany isn't it
<rburton>
DEBUG: /home/ross/Yocto/poky-langdale/meta/recipes-devtools/qemu/qemu-helper-native_1.0.bb: while parsing sstate_task_postfunc, in call of bb.build.exec_func, argument 'intercept' is not a string literal
<d-s-e>
Where can I find some documentation how to write a recipe for a go project? The existing ones have a lot of confusing GO_* variables and stuff ..
<rburton>
d-s-e: go-helloworld is a pretty minimal example by the look of it. alternatively meta-virtualisation has a lot of go in.
<rburton>
RP: i wonder if we're pipelining http requests correctly when using sstate mirrors. i bet the check path uses a new session so new socket
jpman has joined #yocto
jpman has quit [Client Quit]
Tokamak has joined #yocto
<d-s-e>
rburton: Yes, I have seen that, but it's not really clear to me, what is the purpose of those variables, how do I use them, do I need to set them anyway.
Tokamak_ has quit [Ping timeout: 260 seconds]
prabhakarlad has joined #yocto
<RP>
rburton: yes, -DDD is very moany :(
<RP>
rburton: we're supposed to be. I think those all happen in the same context to try and be efficient
camus has quit [Ping timeout: 268 seconds]
kotylamichal has quit [Ping timeout: 256 seconds]
Xagen has quit [Ping timeout: 268 seconds]
hcg has quit [Quit: Client closed]
hcg has joined #yocto
Xagen has joined #yocto
cambrian_invader has quit [Ping timeout: 268 seconds]
<rburton>
RP: i'll poke at some point. tried using the ab sstate and half the connections got 503'd
<RP>
rburton: sounds like something we should mention to halstead
hcg has quit [Ping timeout: 260 seconds]
goliath has quit [Quit: SIGSEGV]
alejandrohs has quit [Ping timeout: 256 seconds]
d-s-e has quit [Ping timeout: 260 seconds]
<vvn>
is one expected to remove the usrmerge distro feature when using the musl libc or is there a patch to apply since kirkstone?
alejandrohs has joined #yocto
tomzy_0 has quit [Quit: Client closed]
d-s-e has joined #yocto
sgw has joined #yocto
cambrian_invader has joined #yocto
d-s-e has quit [Quit: Konversation terminated!]
Minvera has joined #yocto
frieder has quit [Remote host closed the connection]
seninha has joined #yocto
mthenault has quit [Ping timeout: 260 seconds]
kscherer has joined #yocto
gls_ has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
<halstead>
It looks like the new Fedora 37 worker is behaving so far.
<halstead>
sstate.yocto.io is another story eh? I'll check it out.
yolo has quit [Remote host closed the connection]
<rburton>
halstead: i think it got upset with too many connections? would be interesting to know if that was the problem, or something else.
<halstead>
rburton: It does limit connections to keep itself available for multiple users. We were being knocked offline by crawlers and vulnerability scanners. I suppose we need to allow more for legitimate users based on your test.
<rburton>
i wonder if the connection pipelining isn't working, i'd have expected there to be not that many connections at once
sgw has quit [Quit: Leaving.]
manuel__ has quit [Remote host closed the connection]
<halstead>
rburton: perhaps... It's currently set to allow 15 requests per second averaged over 10 minutes and 40 connections at once.
<rburton>
ah. even with perfect pipelining i bet i make 64 connections
<rburton>
I can throttle that down and see what happens
prabhakarlad has quit [Ping timeout: 260 seconds]
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
goliath has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
m4ho has quit [Ping timeout: 256 seconds]
prabhakarlad has joined #yocto
gho has quit [Quit: Leaving.]
<rburton>
halstead: i did another build and it got a slew of http failures
<rburton>
it *should* have had just 16 connections
alessioigor has joined #yocto
florian_kc has quit [Ping timeout: 260 seconds]
florian has quit [Ping timeout: 268 seconds]
alessioigor has quit [Client Quit]
<halstead>
rburton: Any idea how many total connections were attempted over what time period?
<rburton>
halstead: theoretically, 16 in about a second :)
<halstead>
rburton: I can bump it from 15 to 16. :P
<rburton>
trying to figure out perf runes to get it to trace socket connections
<halstead>
rburton: Sorry, I meant how many requests.
<rburton>
*requests*, a lot
<halstead>
rburton: Can I set your IP to ignore the limiter and have you run a build? Then I can look at the logs to better understand.
<rburton>
sure
gls_ has quit [Quit: gls_]
zpfvo has quit [Remote host closed the connection]