<khem>
RP: figured the mips issue, its actually a problem in clone3 wrapper for mips, now sharpening my asm tooth to fix it
<gmorell>
hmm what's the correct way to include libclang.so in a recipe
Daanct12 has joined #yocto
<khem>
gmorell: you need meta-clang and then in the recipe you need to link with it add DEPENDS += "clang"
<gmorell>
hmm, I've done that already and added an hour to my build ;) but it still doesn't seem to find libclang.so sadly and I was wondering if there was some environment var that needed to be set there
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
khazakar has quit [Quit: Connection closed for inactivity]
<khem>
RP: I have fixed the mips issue potentially see https://git.yoctoproject.org/poky-contrib/log/?h=yoe/mut ( 3 glibc patches on top of tree ), started some qemumips and qemumips-alt jobs on AB lets see how it goes
<khem>
gmorell: yes clang is big and OE is built from source so I am not surprised about added build time. Can you look inside your build tree of your recipe ( recipe-sysroot ) for libclang.so
<khem>
see if its staged
<gmorell>
yeah ill check on that
<gmorell>
yeah I do have that for that recipe pkg/git-r0/recipe-sysroot/usr/lib/libclang.so
<khem>
ok then show me how your app is specifying it on linker cmdline
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<gmorell>
it's a dependency that pulls it in, I'm just trying to get it to actually build lemme redact/pastebin the traceback
<jclsn>
Not really a Yocto question, but does someone know if it is possible to set a default audio volume for a sink in the device tree and not asound.state?
<rber|res>
The YP is also used in another particle accelerator in Switzerland ;)
<Xogium>
rber|res: ah, howdy there. Just wanted to thank you again for trying to investigate my weird build failure the other day. Whatever it was, I can't reproduce it anymore, at all. I nuked the build directory and it never happened again
<alessioigor>
rber|res: Great!
<rburton>
alessioigor: nice
rfuentess has quit [Remote host closed the connection]
<rber|res>
@Xogium: You're welcome. I saw the diffs and it looked to me like more changes were necessary, but - well. I also have some interesting issues with kernel modules and a recent master branch at the moment ;)
rfuentess has joined #yocto
<Xogium>
rber|res: nah, we did the exact same thing in the end ;p that's the craziest thing. I atomized the build dir, recreated it again, set machine to stompduck2 (I hadn't changed the layer at all since), and it just worked
<rber|res>
@Xogium: so much to reproducible builds ;)
<Xogium>
but to make it work the very first time I had to force bitbake to run a particular task, wks_template or something. I don't remember the name of
<Xogium>
yep :p
<Xogium>
I guess nothing for it now but to keep an eye on it and see if it ever happens again (I very much doubt it)
<rber|res>
@Xogium: Aha - so it might be reproducible after all. Sounds to me like for some magic reason some dependency is not run - the task you are talking about, which creates the wks file.
<Xogium>
if it is reproducible, I have not found how to reproduce it yet, and neither did the two people who did the exact same build as me for a test
<Xogium>
it might be reproducible but *very* intermitantly
<rber|res>
maybe a race condition
<Xogium>
yeah, that's what I think
<Xogium>
that kind of reminds me of the issue I dug up in the kernel a few years ago ;)
luc4 has joined #yocto
<rber|res>
I experienced something where the build sometimes worked and sometimes it did not and the solution was a [depends]
<Xogium>
basically I found out the hard way (testing a watchdog with a kernel panic to see if it would work properly), that sometimes, somehow, under very specific conditions, the kernel could escape it's very own infinite loop after a panic due to preemption and keep running whatever remained on cpu0
<Xogium>
took us about 3 weeks to dig that one up, and the whole time I thought I was going insane
<Xogium>
I was stunned speechless when I kept being able to ping my panicked test board on the network, ssh in, and do all sorts of things
<Xogium>
but only sometimes
<Xogium>
unless I used nosmp ;p
<rber|res>
Hehe - sounds spooky
<Xogium>
yes, very much so
<Xogium>
I was like, how the hell is it still running ? Oh, watchdog is being fed on cpu0...
<Xogium>
and now on cpu1 so it got stopped and the system reboots normally
Daanct12 has quit [Quit: WeeChat 4.2.1]
<manuel1985>
How does yocto implement the readonly-rootfs feature? I know it creates a /var/volatile, but where does it mount /var/volatile/etc on /etc? On my system `systemctl list-units --type=mount` lists 'etc.mount', but 'systemctl cat' doesn't find it and it's not in '/run/systemd/transient' either. I'm pretty puzzled.
Daanct12 has joined #yocto
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
otavio has joined #yocto
yannd has joined #yocto
Daanct12 has quit [Quit: WeeChat 4.2.1]
<ablu>
manuel1985: /etc is kept (mostly) readonly with Yocto's readonly-rootfs. Some individual files are bind mounted to make them writable. Overall systemd has it's own understanding of stateful and stateless systems.
<ablu>
There are a bunch of options here... Personally I am not a huge fan of the Yocto "readonly-rootfs" feature and prefer the systemd configurations. But it all really depends on what you want and need :)
<frosteyes>
FYI - just sent at pach for the kernel-devsrc issue I mentioned the other day. It was missing some RDEPENDS.
rob_w_ has joined #yocto
rob_w has quit [Ping timeout: 264 seconds]
lexano has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
prabhakar has quit [Ping timeout: 252 seconds]
prabhakarlad has joined #yocto
prabhakar has joined #yocto
Minvera has joined #yocto
olani has quit [Remote host closed the connection]
zhmylove has joined #yocto
olani has joined #yocto
<zhmylove>
Hey everyone! I have multiple recipes that using a single git monorepo. Sometimes my do_fetch fails due race condition trying to lock git refs that are already exist, thanks to parallel do_fetch execution for those recipes. Is there any way to mitigate this?
<rburton>
if the url is the same then it shouldn't be racing, the first should lock and clone and the others wait
<rburton>
(unless your DL_DIR is on a filesystem with broken locking...)
prabhakarlad has quit [Ping timeout: 250 seconds]
Saur_Home has quit [Quit: Client closed]
Saur_Home has joined #yocto
<LetoThe2nd>
How to get into the right mood for the upcoming FOSDEM weekend:
<LetoThe2nd>
- buy a sixpack of Belgian beers
<LetoThe2nd>
- stock up on fries (double friture!)
<LetoThe2nd>
- binge watch the recordings from last years OE Workshop
<zhmylove>
The FS is ext4, mount options are "rw,relataime". I've also made a simple test using flock(1) and advisory locking works properly. Would you suggest to debug git-ssh fetcher or something else?
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
wmills_ has joined #yocto
rob_w_ has quit [Quit: Leaving]
mlaz has joined #yocto
mlaz has quit [Quit: mlaz]
mlaz_ has joined #yocto
sakman has joined #yocto
mlaz_ is now known as mlaz
sakman1 has joined #yocto
KorG has joined #yocto
sakman has quit [Ping timeout: 276 seconds]
sakman1 is now known as sakman
zhmylove has quit [Ping timeout: 260 seconds]
linfax has quit [Ping timeout: 276 seconds]
Xagen has joined #yocto
Guest41 has joined #yocto
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #yocto
sakman has quit [Ping timeout: 276 seconds]
<Guest41>
Hello Team
<Guest41>
I'm facing a issue while running bitbake
<arielmrmx>
on both recipes i can see a: python populate_packages_prepend ()
<arielmrmx>
those are in fact, identical
<arielmrmx>
also, by reading into the DEBIAN_NOAUTONAME_{pn} documentation I understand that making it "1" I would avoid renaming the package, So I did
<arielmrmx>
however I had to add: d.appendVar('DEBIAN_NOAUTONAME_' + pkg, '1') for each d.getVar('PACKAGES').split()
frieder has quit [Remote host closed the connection]
<arielmrmx>
and that removed some verbosity about
<arielmrmx>
NOTE: package name mapping done: libopencv-core -> libopencv-core3.4
<arielmrmx>
dozens of opencv were not renamed anymore as seen in log_do_package_write_ipk
<simonew>
Maybe it is not in the recipe (have not checked them now), but due to automatically added runtime dependencies
<arielmrmx>
i had imagined that by adding DEBIAN_NOAUTONAME_{libopencv-blabla}="1" then no renaming would occur (i was right) but
<arielmrmx>
the RPROVIDES seems still wrong
<arielmrmx>
further strangely, the header of the IPK