<Marian81>
Hi, I have a problem with an .wic file, if the size is less then 2.1G, the wic is generated with grub-efi-bootx64.efi if is above 2.1G grub-efi-bootx64.efi is not populated under the first partition /boot/EFI/BOOT/. Do you have any input?
xmn has joined #yocto
<yates_work>
rburton: 1) rm -fR tmp, 2) bitbake core-image-printer (my custom image adapted from core-image-sate), 3) runqemu qemuarm and verified qemu machine runs, 4) find . -name "run.do_conf*" returned nothing.
<yates_work>
sato
alimon has joined #yocto
<yates_work>
any clues would be appreciated
<yates_work>
from anyone
<yates_work>
does bitbake remove successfully-completed run.do and log.do files?
qschulz has quit [Remote host closed the connection]
lolock_ has quit [Server closed connection]
lolock has joined #yocto
<Marian81>
I will add a mistake in a recipe to find out where the logged are stored ...
qschulz has joined #yocto
<Marian81>
wic ls is giving me "ERROR: Can't find executable 'mdir'"
<yates_work>
btw, i'm running kirkstone
<yates_work>
could it be that this image recipe is downloading preconfigured state from the repos?
<yates_work>
fyi, my goal is to find the ./configure options used by the qtbase recipe
davidinux has quit [Ping timeout: 246 seconds]
<yates_work>
meta-qt5/recipes-qt/qt5/qtbase
Xagen has joined #yocto
davidinux has joined #yocto
amitk_ has quit [Ping timeout: 246 seconds]
lexano has quit [Ping timeout: 246 seconds]
Vonter has quit [Ping timeout: 255 seconds]
Vonter has joined #yocto
GParker_ has joined #yocto
geoffhp has quit [Ping timeout: 252 seconds]
sakman_ has joined #yocto
sakman has quit [Ping timeout: 245 seconds]
KanjiMonster has quit [Ping timeout: 255 seconds]
KanjiMonster has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
Xagen has quit [Client Quit]
vvn has quit [Server closed connection]
vvn has joined #yocto
<khem>
yates_work: yes if there are no run.do_conf* scripts that means it was using it from sstate
<khem>
you are lucky !
<khem>
if you enable rm_work via local.conf INHERIT += "rm_work" then it will delete the build area of the successfully built recipe too
<khem>
Marian81: I think it should `rmdir`
GParker__ has joined #yocto
<khem>
Marian81: let me take it back, I think wic does need mdir which is a tool coming from mtools-native recipe so somehow its missing in your wic image deps
<khem>
add `do_image_wic[depends] += "mtools-native:do_populate_sysroot` in your machine conf or local conf
<yates_work>
khem: aha! i was thinking the cache's were under tmp. doh!
<yates_work>
thank you!
<yates_work>
is there anything wrong with just "rm -fR sstate-cache cache" ?
<yates_work>
instead of using bitbake -c blah
amitk has joined #yocto
khem has quit [Quit: Connection closed for inactivity]
amitk has quit [Ping timeout: 252 seconds]
Ram-Z has quit [Server closed connection]
Ram-Z has joined #yocto
Sai-Kiran has joined #yocto
Schlumpf has joined #yocto
rob_w has joined #yocto
alessioigor has joined #yocto
l3s8g has joined #yocto
Minvera has quit [Ping timeout: 246 seconds]
rfs613 has quit [Ping timeout: 255 seconds]
rfs613 has joined #yocto
Schlumpf has quit [Ping timeout: 245 seconds]
louson has quit [Server closed connection]
rfuentess has joined #yocto
goliath has joined #yocto
davidinux has quit [Ping timeout: 255 seconds]
davidinux has joined #yocto
Schlumpf has joined #yocto
linfax has joined #yocto
Marian81 has quit [Quit: Ping timeout (120 seconds)]
zpfvo has joined #yocto
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
frieder has joined #yocto
<LetoThe2nd>
yo dudX
<Schlumpf>
Good morning
JerryM has joined #yocto
lighteagle has joined #yocto
mkazantsev has joined #yocto
AndreiM has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<AndreiM>
hi guys. I have a little problem while upgrading my project from dunfell to kirkstone with one of my recipes. Maybe you can guide me where to look at (hopefully). This is the issue:
<AndreiM>
log.do_compile.263830
<AndreiM>
Log data follows:
<AndreiM>
| DEBUG: Executing shell function do_compile
<AndreiM>
| NOTE: VERBOSE=1 cmake --build /home/user/oe-core/build/tmp/work/armv7at2hf-neon-tdx-linux-gnueabi/shadowsocks-libev/3.3.5-r0/build --target all --
<AndreiM>
| Error: could not load cache
kpo has joined #yocto
<olani->
yates_work: There is nothing wrong with it, but it's probably overkill. 'bitbake qtbase -c configure' would force bitbake to rerun the configure step and then you can check the files.
<olani->
yates_work: Sorry, that should be 'bitbake qtbase -c configure -f' to force the task to be rerun.
<AndreiM>
in my .bb file I have "inherit cmake pkgconfig" . I'm not using any qt-related recipes
<AndreiM>
sorry, I'm quite new to yocto and it feels a bit overwhelming now :))
ckayhan1 has quit [Ping timeout: 245 seconds]
<olani->
AndreiM: I'm not sure I can help with cmake, but we probably need more of the log to help. Please don't paste it here but use some pastebin server. The recipe too if possible.
<LetoThe2nd>
AndreiM: does your cmake thingy do any network access during compile? such as a shared cache?
GParker_ has joined #yocto
<AndreiM>
I just got the project from github and did not mingle with it's build
GParker__ has quit [Ping timeout: 252 seconds]
<AndreiM>
looks like downgrading to PREFERRED_VERSION_mbedtls = "2.28.2" from 3.4.0 solved the problem. I don't think it's ok on the long term tho
Guest10 has quit [Quit: Client closed]
<AndreiM>
and adding in the recipe:
<AndreiM>
do_compile() {
<AndreiM>
cd ${S}
<AndreiM>
cmake .
<AndreiM>
cmake --build .
<AndreiM>
}
<LetoThe2nd>
AndreiM: the latter is definitely a bug because it breaks the do_configure stage.
<mcfrisk>
sigh, re-clone of kernel git repo. I'll send a revert now..
<AndreiM>
why do you say it's a bug? it did all the steps (hopefully?) right....including the do_install and the later ones
<LetoThe2nd>
AndreiM: the cmake.bbclass makes sure that all necessary bits and pieces for the cross build are in place. by bluntly calling "cmake ." in do_compile, you a) break the dependency chain of compile on configure, and b) almost certain mess up the required parameters.
<qschulz>
AndreiM: nowhere is it mentioned it supports cmake though
Wouter0100670440 has joined #yocto
<qschulz>
(yes I see there's a CMakeLists.txt file, but the instructions mention using autotools
<qschulz>
so maybe use that instead?
<qschulz>
AndreiM: I highly recommend to not use the git submodules in there especially since I believe we have recipes for those?
<qschulz>
libsodium at least I think
<qschulz>
to quote: If your system provides with those libraries, you should not install them from source.You should jump to this section and install them from the distribution repository instead.
zpfvo has joined #yocto
<AndreiM>
qschulz I'll try using autotools instead of cmake. About the submodules, they are part of the project (shadowsocks-libev). Maybe I'll need to modify those sources not to build/install them...
<qschulz>
AndreiM: if you don't fetch them it should find them from the sysroot probably
<qschulz>
if not, you need to patch the build system to find them in the sysroot
<qschulz>
but the isntructions from shadowsocks-libev is to NOT use the git submodules if the libs are already in your system
<qschulz>
so do it the proper way and add/use recipes instead for those dependencies
GParker__ has joined #yocto
Vonter has quit [Ping timeout: 246 seconds]
<AndreiM>
qschulz thanks for the guidance. I'll recreate sadowsocks-libev recipe from scratch and work from that. Sometimes it's easier and safer to do so instead of "upgrading" old stuff
Vonter has joined #yocto
GParker_ has quit [Ping timeout: 245 seconds]
davidinux has quit [Ping timeout: 240 seconds]
<qschulz>
AndreiM: to be fair, I only checked the default branch of thegit repo, haven't checked if this waht you're using.. so maybe not so good advice
mbulut has joined #yocto
ckayhan1 has joined #yocto
davidinux has joined #yocto
kpo has quit [Ping timeout: 252 seconds]
Schlumpf has quit [Quit: Client closed]
mbulut has quit [Quit: Leaving]
Saur has quit [Server closed connection]
Sai-Kiran has quit [Quit: Client closed]
Saur has joined #yocto
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
<olani->
AndreiM: Try 'devtool add' to autogenerate as much as possible.
<RP>
kanavin: that was a lot simpler than I thought it was going to be!
<RP>
It is little things like this which will help everyone - hopefully fewer out of space issues on the AB and less hassle for the admins too as a result
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
<kanavin>
RP: I took time to study both the buildbot docs and then its code (grep for various related keywords), so I would visit every corner of it exhaustively. I have to say documentation alone didn't help, as it doesn't say outright 'alwaysRun' applies to cancelled builds as well.
<kanavin>
I also understand better how the whole thing works now :)
<RP>
kanavin: I'd looked at the docs myself but it certainly wasn't clear! It is helpful to have someone else who knows something about it :)
<RP>
kanavin: I did have a look at that shadow static issue and got frustrated that libtool doesn't appear to follow it's own help text or docs :(
<RP>
I was hoping we could do something like a do_compile:prepend () of sed -i -e 's#mode=link#mode=link -all-static#g' ${B}/*/Makefile
<kanavin>
RP: I got frustrated mostly because the whole thing isn't working cohesively, even though it's all GNU. There's no way to put -all-static in there via autoconf, and there's also no way to add it after the fact with a libtool-specific makefile variable that would pass the flag.
<kanavin>
and toying with things like LDFLAGS would clash in other places.
<kanavin>
RP: did you try the sed hack? did it not work?
<RP>
kanavin: it didn't work, I'm not sure why. libtool claims -all-static is an unknown option
<RP>
kanavin: I'll probably poke more, I just thought I'd share ideas :)
Guest4 has joined #yocto
<rburton>
haha gnu cohesion haha :) of course nothing works together, it's GNU :)
<kanavin>
RP: right I can try to push it a bit more as well by applying the sed thing, it should help in theory and the option does exist, but it's still a hack
tnovotny has joined #yocto
<RP>
kanavin: I appreciate it is horrible, I just worry about other issues more...
<rburton>
speaking of , i should dig out my slibtool branch and see if it works still
<kanavin>
you can install buildbot in debian, and even start masters and workers, but there will not be any web ui! amazing!
<kanavin>
wasted an hour on this or so
<kanavin>
that's why the patch was untested btw, I hate containers with a passion
<kanavin>
I'd say JS-based UI is buildbot's weakest link. something tells me you can do all of these dynamic things with plain html nowadays.
prabhakarlad has quit [Quit: Client closed]
alessioigor has quit [Quit: alessioigor]
<RP>
kanavin: at least they removed the coffeescript!
<RP>
kanavin: the readmes in our autobuilder repo do document how to setup a test environment, easiest is if you create a local user for the purpose
<rburton>
kanavin: as you're now a buildbot expert, do you think its even possible to embed the right <title> tag in the generated html for eg a link to a specfic build? or is the returned html always the same and the content is always generated on the client?
<kanavin>
RP: right, I'll check them next time because anything more serious would've required that
<RP>
rburton: can you be specific about the page you mean?
<kanavin>
rburton, that I have no idea. I dived into specifically the build steps implementation and behavior.
elfenix|cloud has quit [Quit: Connection closed for inactivity]
<Guest4>
I have a recipe A.bb which DEPENDS on another recipe B.bb.
<Guest4>
B.bb only contains headers which are installed to ${includedir}. So ${PN} is empty (ALLOW_EMPTY:${PN} = "1"). The headers are in ${PN}-dev.
<Guest4>
Adding A to an image works fine. However, when building the SDK (do_populate_sdk) the headers from B are not installed. I checked the buildhistory and targets->depends.dot has "A-dev" -> "B-dev" [style=dotted]. Also the package A-dev RRECOMMENDS B-dev. Moreover, I found out that everything works fine when I set an explicit RDEPENDS from A-dev to
<Guest4>
B-dev.
<Guest4>
Can somebody please explain why the RRECOMMENDS does not lead to the installation of B-dev in the SDK? Is this somehow related to oe-core b44b0b9294675f89aa51ff84f532664f4c479677 ?
<RP>
rburton: hmm, I see what you mean about the generated code
<RP>
rburton: I think this is just how it works :(
<rburton>
yeah
<rburton>
mcfrisk: i think your change to testimage so that it sets a default TARGET_IP on slirp is fundamentally broken, and i'm annoyed that i didn't notice until after it merged
<yates_work>
olani-: i see you.
<rburton>
mcfrisk: guests running in slirp can't open ports <1024, so runqemu tells qemu that if the guest opens port 22, actually open 2222. so if you use slirp, you need to set TEST_TARGET_IP to localhost:2222, otherwise the ssh test will hit localhost.
<rburton>
localhost:22 that is
<yates_work>
olani-: sheesh! s/i see you/i see, thank you/
<RP>
rburton: how does that work for multiple images in parallel?
<JerryM>
hey people anyone knowledgeable about sstate and useradd? Im having an issue where an sstate task fails, causing bitbake to return with an error even though it recovered succesfully
<JerryM>
the cause is useradd reports an error while trying to add a group that is added in another package, saying it doesn't exists. the normal recipe has both RDPENDS and DEPENDS on the recipe that add this group, however when restoring from sstate this seems to fail often
<rburton>
RP: it doesn't, this is why slirp isn't as good as tap
<rburton>
most people using slirp are using it inside containers, so that's not a problem
<RP>
JerryM: I think there are open bugs related to that?
<RP>
rburton: how does a container solve that?
<JerryM>
@RP it seems you are correct
<JerryM>
I guess it's a general issue and not just on my end
<mcfrisk>
RP: network namespaces
<RP>
so qemu creates a new network namespace for each image under test?
belsirk has joined #yocto
<mcfrisk>
rburton: I think TEST_TARGET_IP needs to be split, the test frameworks/controller needs the externally visible one, and then inside the running target system another one.
<RP>
JerryM: there are open bugs so if they match it is likely not just you
<mcfrisk>
RP: for example running docker container to build and test images with qemu, slirp there won't be visible to outside of the docker container. like presumably kas
rfuentess has quit [Ping timeout: 252 seconds]
<RP>
mcfrisk: but that container can run multiple testimages in parallel within it somehow?
<mcfrisk>
but multiple containers using different network namespaces e.g. localhost port 2222, can run in parallel
<RP>
mcfrisk: ok, I was thinking you meant a container somehow allowed that limitation to be avoided
<RP>
multiple containers fair enough
belsirk is now known as rfuentess
<JerryM>
I'll keep an eye on that and see if I can find some time to maybe dig into this, I'm not very confident I have enough knowldegde for that though
<mcfrisk>
rburton: is your use case running exported tests with slirp?
<rburton>
no, kas container, so the testimage happens inside the container too
<rburton>
i have a patch to make it 'just work' with the standard setup
<rburton>
but with the current code it looks like the slirp testimage qa test is verifying that the host has a sshd running
<mcfrisk>
bugger. yea target should be 127.0.0.1:2222 but I fear some of the tests will fail due to the port number. selftests are a bit too special for my understanding..
<rburton>
the port is fine, testimage strips it out
rfuentess has quit [Read error: Connection reset by peer]
rfuentess has joined #yocto
wmills has joined #yocto
<RP>
kanavin: of course complete static linking breaks pseudo as it can't see the libc calls :(
l3s8g has quit [Ping timeout: 245 seconds]
rob_w has quit [Remote host closed the connection]
GParker__ has joined #yocto
ckayhan1 has quit [Ping timeout: 255 seconds]
amitk has quit [Ping timeout: 252 seconds]
GParker_ has quit [Ping timeout: 255 seconds]
lexano has joined #yocto
<kanavin>
RP: right, so maybe this should be a custom patch after all, there's a point where sed expressions start to crumble, and it's getting close to that :( or just abandon the idea, and do dynamic linking with handwritten setscene dependencies list as originally proposed :-/
brazuca has quit [Quit: Client closed]
<RP>
kanavin: well, I have a slightly different patch to test
<RP>
kanavin: the impact of the inverted setscene dependencies shouldn't be underestimated :/
<JPEW>
JaMa: I'm horribly confused about how the /data0001 is showing up in the output of `git rev-parse --absolute-git-dir`; AFAICT that path shouldn't be encoded in the mirror tarball at all
zpfvo has quit [Ping timeout: 252 seconds]
zpfvo has joined #yocto
zpfvo has quit [Ping timeout: 252 seconds]
<RP>
kanavin: FWIW the simpler direct static libs approach appears to build
zpfvo has joined #yocto
<RP>
JPEW: someone needs to make our mirror tarballs reproducible? :/
<JPEW>
Git repos shouldn't have absolute paths in them _anwyay_
<RP>
JPEW: something bad does seem to be going on
<JPEW>
Mikko's symlinks are a problem in what I added (which I can fix).... I kinda think the other one is actually some other latent bug
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
ldts has quit [Server closed connection]
ldts has joined #yocto
otavio has quit [Ping timeout: 246 seconds]
rfuentess has quit [Read error: Connection reset by peer]
<RP>
JPEW: can you use os.path.realpath(os.path.abspath()) in the fetcher to avoid that stat stuff?
ptsneves has quit [Ping timeout: 252 seconds]
<JPEW>
RP: I thought about that..... but it depends if you want to handle bind mounts or not
<JPEW>
It proabbly would be OK for symlinks
ptsneves has joined #yocto
ptsneves has quit [Client Quit]
ptsneves has joined #yocto
Kubu_work has quit [Quit: Leaving.]
<rburton>
mcfrisk: aah so it works with qemu as the qemu runner parses the hostfwd options that are passed
otavio has joined #yocto
<mcfrisk>
rburton: but we should fix the port to be 2222? testing that as well.
<rburton>
i don't think so - the qemu runner does that on its own
<rburton>
i just wanted to actually understand the flow
<rburton>
i'll add a bigger comment :)
<mcfrisk>
RP: bummer, not the same test as previously and not instrumented to capture the stderr which contains extra lines
<rburton>
mcfrisk: this is extra fun because the FVP target is a bit like the qemu one but very bare-bones. i didn't know the qemu one would infer port mapping.
<mcfrisk>
Is it possible to sftp/scp transfer some files from target when tests fails? openssh ptests leave a tar ball behind..
<mcfrisk>
rburton: sounds interesting :)
<mcfrisk>
I'm thinking of extending oeqa so we could also write tests using plain serial console, like Lava tests are mostly written
<rburton>
mcfrisk: have a look at the fvp runner in meta-arm, it has the serial console extension (and also power control). we want to slowly move the api into oeqa, but for now its fvp-specific.
<mcfrisk>
rburton: perfect!
mbulut has joined #yocto
mbulut has quit [Client Quit]
frieder has quit [Remote host closed the connection]
zpfvo has quit [Quit: Leaving.]
<JaMa>
JPEW: sorry for confusion about that /data0001, it was just a log from error-report-web where I've noticed that warning and it was on one of the jenkins servers where I didn't know they changed /mnt/mirror-write use (we had writeable NFS mount there, but when the build infra was migrated someone kept the path, but used that for symlink and it doesn't make any sense to point DL_DIR there.. )
<JPEW>
JaMa: np
vladest has quit [Ping timeout: 245 seconds]
alessioigor has quit [Quit: alessioigor]
<JPEW>
Glad it's not actually some serious issue with encoding paths in mirror tarballs :)
alessioigor has joined #yocto
* JaMa
too and it helped to discover why do_fetch was sometimes failing for us on git.libssh.org :)
<JaMa>
our git mirror was incorrectly using unreliably git:// instead of https:// for it and I was wondering why the builds are failing even after fixing the repo on PREMIRROR :)
khem has joined #yocto
kscherer has joined #yocto
kscherer has quit [Client Quit]
goliath has quit [Quit: SIGSEGV]
ptsneves has quit [Ping timeout: 252 seconds]
ckayhan1 has joined #yocto
<halstead>
khem: https://libera.chat didn't end up writing an official guide for setting up our own Matrix bridge. Is that still something you'd like to have?
<khem>
yeah
<khem>
I am using irccloud now a days here :)
<RP>
mcfrisk: shame, is there anything we could do more generically for the logs?
<halstead>
That what I use as well. irccloud is much easier than maintaining my old setup.
<RP>
halstead: I'd not dare tell you what I do! :)
<khem>
so IRC is not as painful as it use to be.
<halstead>
Oh? Well I do have special alerts set up for messages from you RP. ;)
<RP>
halstead: I try not to bother you too much :)
<RP>
halstead: my setup is really old, I should really find something better
<halstead>
I think irccloud is worth the money until Matrix (or something else) becomes the defacto FOSS choice.
<khem>
matrix client (element) sucks, its not as slick as some other implementations
<khem>
but neochat is good if you use linux/KDE
<rburton>
RP: your irc configuration is an abomination
<halstead>
I agree Element is pretty bad. I'll try neochat. There was a new client for Android in beta that might be good when it releases.
<RP>
JPEW: maybe we should abstract that check into a function. I'm just worried it is getting a bit off topic for that location in the code...
<RP>
JPEW: I hadn't considered bind mounts. Would we hit those normally though?
florian has joined #yocto
<JPEW>
mmm, ya probably not. Symlinks can be inconsistent in the same path, but bind mounts probably not. Although realpath is going to have to stat every path component to see if it's a symlink and readlink() it, so I don't think the performance of the stat is worse (it also exits after one iteration in the normal case)
<JPEW>
I guess I could move it to a helper.... like bb.utils.path_is_descent_of()?
<RP>
JPEW: I was thinking of something in bb.utils
<RP>
JPEW: I was less worried about performance and more about just making the code readable
tnovotny has quit [Quit: Leaving]
goliath has joined #yocto
<JPEW>
K
brazuca has joined #yocto
Kubu_work has joined #yocto
prabhakarlad has joined #yocto
amitk has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
florian has quit [Quit: Ex-Chat]
amitk has quit [Ping timeout: 255 seconds]
GNUmoon has quit [Read error: Connection reset by peer]
GNUmoon has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Xagen has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
alessioigor has quit [Quit: alessioigor]
Haxxa has joined #yocto
florian has joined #yocto
jgrossholtz has quit [Read error: Connection reset by peer]
jgrossholtz has joined #yocto
smooge has quit [Server closed connection]
yocti has quit [Remote host closed the connection]
smooge has joined #yocto
yocti has joined #yocto
xmn has quit [Ping timeout: 255 seconds]
yocti has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
yocti has joined #yocto
brazuca has quit [Quit: Client closed]
chep` has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` is now known as chep
jclsn has quit [Quit: WeeChat 4.0.4]
Kubu_work has quit [Quit: Leaving.]
Kubu_work has joined #yocto
Kubu_work has quit [Client Quit]
goliath has quit [Quit: SIGSEGV]
brazuca has joined #yocto
prabhakarlad has joined #yocto
florian has quit [Ping timeout: 255 seconds]
brazuca has quit [Quit: Client closed]
<mischief>
how crazy is it to write a class that generates fake shared object versions? we've got a ton of recipes that dont do any versioning and it breaks shlibdeps. i hacked up one recipe to do this and was thinking of doing it for more..