Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
jclsn07 has quit [Ping timeout: 240 seconds]
tangofoxtrot has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
jclsn07 has joined #yocto
tangofoxtrot has joined #yocto
jclsn07 has quit [Ping timeout: 276 seconds]
Bardon has joined #yocto
jclsn07 has joined #yocto
Bardon has quit [Ping timeout: 246 seconds]
Bardon has joined #yocto
jclsn07 has quit [Ping timeout: 240 seconds]
Bardon has quit [Ping timeout: 246 seconds]
Bardon has joined #yocto
jclsn07 has joined #yocto
jclsn07 has quit [Ping timeout: 248 seconds]
jclsn07 has joined #yocto
jclsn07 has quit [Ping timeout: 276 seconds]
jclsn07 has joined #yocto
jclsn07 has quit [Ping timeout: 246 seconds]
jclsn07 has joined #yocto
RobertBerger has joined #yocto
rber|res has quit [Ping timeout: 276 seconds]
sakoman has quit [Quit: Leaving.]
jclsn07 has quit [Ping timeout: 248 seconds]
jclsn07 has joined #yocto
Tokamak has quit [Ping timeout: 250 seconds]
Tokamak has joined #yocto
jclsn07 has quit [Ping timeout: 255 seconds]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
jclsn07 has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
jclsn07 has quit [Ping timeout: 246 seconds]
camus has joined #yocto
jclsn07 has joined #yocto
jclsn07 has quit [Ping timeout: 246 seconds]
jclsn07 has joined #yocto
jclsn07 has quit [Ping timeout: 255 seconds]
jclsn07 has joined #yocto
jclsn07 has quit [Ping timeout: 256 seconds]
sakoman has joined #yocto
jclsn07 has joined #yocto
jclsn07 has quit [Ping timeout: 248 seconds]
jclsn has quit [Ping timeout: 255 seconds]
Tokamak has quit [Ping timeout: 256 seconds]
Tokamak has joined #yocto
sakoman has quit [Quit: Leaving.]
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 258 seconds]
nemik has joined #yocto
amitk has joined #yocto
camus has quit [Remote host closed the connection]
camus has joined #yocto
alessioigor has joined #yocto
kroon has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<kroon>
Is there a common way to express that one PACKAGECONFIG entry depends on another PACKAGECONFIG entry (for the same recipe) ?
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<kroon>
I see there is the 6:th etry, conflicting packageconfigs, maybe it would be an idea to expand with a 7:th entry for listing dependencies ?
<kroon>
or, maybe better to just let the build fail
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
nemik has joined #yocto
rob_w has joined #yocto
leon-anavi has joined #yocto
rfuentess has joined #yocto
vladest has quit [Ping timeout: 248 seconds]
mckoan|away is now known as mckoan
<mckoan>
good morning
<LetoThe2nd>
yo dudX && mckoan
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
Wouter0100 has quit [Remote host closed the connection]
Wouter0100 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Schlumpf has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
xmn has quit [Quit: ZZZzzz…]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
Baehrune has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Baehrune has quit [Ping timeout: 246 seconds]
alessioigor has quit [Ping timeout: 240 seconds]
Vonter has quit [Ping timeout: 258 seconds]
Sam38 has joined #yocto
MylneVillars[m] has joined #yocto
florian has joined #yocto
<qschulz>
o/
<qschulz>
kroon: you can have an anonymous python function which checks the value of PACKAGECONFIG
<kroon>
right, but i was hoping for a more general solution
prabhakarlad has joined #yocto
camus has quit [Ping timeout: 246 seconds]
camus has joined #yocto
twnqx has joined #yocto
<bigendian>
gm, is there any package as debian smc-tools in yocto ?
<JaMa>
RP: from 852M install.man-make-native-4.3.j2.trace.d.log it looks like make-native ends in neverending loop, will reply to list when I have more information, make from gentoo has the same issue (when just called with full path as /usr/bin/make install.man)
<LetoThe2nd>
bigendian: you can dig around a bit on the OE layerindex, but chances are low then.
<Sam38>
Good Morning! I have a ton of very strange Errors/Warnings:
<Sam38>
[...]Kconfig:2: missing end statement for this entry
<Sam38>
[...]Kconfig:1:warning: ignoring unsupported character '*'
<Sam38>
I am trying to establish my own machine configuration, currently I only have the following two lines in my picozed-zynq7-single.conf
<Sam38>
MACHINEOVERRIDES =. "picozed-zynq7:"
<Sam38>
require conf/machine/picozed-zynq7.conf
<JaMa>
RP: just enabling ccache in other build directory doesn't trigger it, but I've reverted last 3 perl patches from Alex and cannot reproduce it now
<RP>
JaMa: so probably some new make bug exposed by new perl?
<JaMa>
maybe "perl: drop perltoc regeneration" is the one which triggers it
<JaMa>
or maybe it's still a bit random, but I've reproduced it 3 times from master with "oe-selftest -r buildoptions.ImageOptionsTests.test_ccache_tool" and haven't seen it anywhere else
<RP>
JaMa: I guess ccache may speed up the build and expose the race more?
tre has joined #yocto
<JaMa>
it might, but during do_install with -j 2 it wasn't doing much, really don't know, the debug output from make isn't easy to read, will need a bit more time, but first trying to narrow the reproducer even more (if it's one of these 3 small commits, it will be much easier to compare than the whole perl upgrade)
<JaMa>
It's still not reproducible in master with:
<JaMa>
pick 2d3cd5e18be Revert "perl: enable _GNU_SOURCE define via d_gnulibc"
<JaMa>
pick b0476a9ed43 Revert "perl: clean prior to build"
<RP>
JaMa: perl's make usage is a bit of a mess :/
<JaMa>
agreed :)
<twnqx>
why does yocto build host tools things against system glibc, btw? i just had to throw away a whole build dir after upgrading to 2.35
<JaMa>
twnqx: you can use uninative
<RP>
twnqx: how did it break? that doesn't make sense as you're supposed to be able to upgrade glibc without doing that
<twnqx>
well, it says "disabling uninative because your glibc is too new" after rm -rfing build
<JaMa>
twnqx: what release are you using, there is 2.35 compatible uninative in dunfell, kirkstone and master
<twnqx>
well, the internally host-built python3 inside yocto had missing symbols referring to glibc 2.35
<RP>
twnqx: use a more recent uninative, that is safe to update alone in most cases
<twnqx>
pretty sure it's dunfell, let me checjk
<RP>
twnqx: uninative needs to be >= host glibc
<RP>
hence why it shows that warning when it isn't
<JaMa>
twnqx: make sure to have recent dunfell with ^
<twnqx>
heh gcc 12 is nightmare fuel on its own for me
<twnqx>
internal compiler errors all over the place
<JaMa>
but you need this to use libstdc++ built from gcc-12 on host (e.g. ubuntu-22.10 has this)
<twnqx>
yeah, this is unsupported gentoo testing here :)
<RP>
twnqx: expecting older releases to build with the latest and greatest distros isn't entirely fair
<JaMa>
yes, use 12.1.1_p20220528-r1 instead of 12.1.1_p20220604 in gentoo
<JaMa>
0604 snapshot and 12.2.9999 triggeres a lot of ICEs now (e.g. nodejs-native, chromium.. )
<twnqx>
RP: true, but you have support for it now, so things should go well soon
<twnqx>
JaMa, there's also rumors of yet-unknown cpu bugs in zen/zen+/zen2 family CPUs (this is a threadripper 2)
<twnqx>
triggering at least some of the ICEs
<JaMa>
I'm using it on 3970
<JaMa>
do you have a link for these rumors?
<JaMa>
I haven't noticed it in gcc bugzilla yet
<twnqx>
it's on some of the gentoo bug reports for ICEs that crept in ever since gcc 10/11
<twnqx>
and the fact that while !make; do ; helps in many cases seems to indicate at least not a gcc bug
<twnqx>
(the ones in 12 are a different group)
* JaMa
spent too much time bisecting gcc recently just to find out that some patches fix issues in some recipes just to introduce issues in different recipes (e.g. mtk bluetooth stack vs chromium)
<twnqx>
ouch :(
<JaMa>
I didn't know what SFINAE means before that and now I would like to forget again :)
<smurray>
sotaoverride: trying to git clone that repo throws an error saying the certificate has expired, so looks like a Toradex problem
Vonter has joined #yocto
squid_game has quit [Remote host closed the connection]
<sotaoverride>
whats a workaround for when a vendors CA certificate expires, and the yocto fetcher stop working
<smurray>
sotaoverride: email the vendor to fix their hosting, in the meantime maybe bbappend the recipe(s) to change the SRCURI to use protocol=http (instead of https)
alessioigor has joined #yocto
alessioigor has quit [Client Quit]
Vonter has quit [Ping timeout: 276 seconds]
Vonter has joined #yocto
Schlumpf has quit [Quit: Client closed]
<kroon_>
RP, JaMa, kanavin: There is a comment in the perl top makefile: "# clean-modules must go BEFORE clean-generated-files because it depends on config.h!". But I don't see that dependency being explicitly listed
camus has quit [Quit: camus]
<kroon_>
so, doing "make clean" with parallell jobs would ignore that dependency as I see it
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 244 seconds]
<kroon_>
on the other hand i'm not sure if that explains the build failures, although one of the patches relates to makes handling of config.h
nemik has joined #yocto
<JaMa>
kroon_: RP: I've replied to the thread, the explict clean at the end of do_configure is what definitely triggers it, but why it happens only in selftest is still mystery for me
<JaMa>
kroon_: Alex removed config.h from clean-generated-files in 0001-Makefile-do-not-clean-config.h-xconfig.h.patch probably to avoid this
<kroon_>
JaMa, ok, so with that patch, that comment is no longer valid
<kroon_>
im guessing
<JaMa>
yes, that's my understanding as well, but there might be some slight side-effects elsewhere as well (not limited just to config.h) comparing the build directory after do_install with and without the explicit clean shows bunch of missing files like opmini.c, perlmini.c,uudmap.h,bitcount.h,generate_uudmap as well https://pastebin.com/UeVfK7KG
kscherer has joined #yocto
xmn has joined #yocto
<JaMa>
but other than 55 {cpan,dist,ext}*/Makefile files having this bitcount.h and uudmap.h and 145 Makefile.old files there aren't any significant differences in the build directories
<JaMa>
so all of the "new" files were removed by the explicit clean
amitk has quit [Ping timeout: 246 seconds]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
<LetoThe2nd>
also announcing here: the Yocto Project is hosting a get together at Embedded World, on June 23rd, 9:30AM in the catering area of Hall 4. Just show up and have a good time!
ptsneves has joined #yocto
tre has quit [Remote host closed the connection]
Vonter has quit [Ping timeout: 246 seconds]
nemik has quit [Ping timeout: 250 seconds]
nemik has joined #yocto
Habbie has quit [Ping timeout: 258 seconds]
sakoman has joined #yocto
<gordon1>
lets say i'm preparing some customizable image and i want to keep all the customizable files in single dir and not tucked away in 1000 different locations near the corresponding recipes. just for the sake of example, lets say i want to have fstab and authorized_keys for root, i want to have something like conf/custom/fstab and conf/custom/root_authorized_keys, both of files will be picked up by
<gordon1>
corresponding recipe and populated into image
<gordon1>
is there a nice way of doing it?
<gordon1>
will just a symlink suffice?
<gordon1>
or is there a yocto way of doing that? like defining FILESEXTRAPATH to look at that conf dir?
Habbie has joined #yocto
nemik has quit [Ping timeout: 276 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
kroon_ has quit [Quit: Leaving]
amitk has joined #yocto
sotaoverride has quit [Remote host closed the connection]
stephano has joined #yocto
sotaoverride has joined #yocto
rfuentess has quit [Remote host closed the connection]
Vonter has joined #yocto
florian has quit [Quit: Ex-Chat]
florian__ has joined #yocto
Vonter has quit [Quit: WeeChat 3.5]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
Vonter has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
Sam22 has joined #yocto
nemik has quit [Ping timeout: 248 seconds]
Sam38 has quit [Quit: Client closed]
nemik has joined #yocto
Sam22 has quit [Client Quit]
nemik has quit [Ping timeout: 248 seconds]
nemik has joined #yocto
kroon has joined #yocto
dev1990 has quit [Quit: Konversation terminated!]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 246 seconds]
nemik has joined #yocto
jpuhlman has quit [Ping timeout: 240 seconds]
jpuhlman has joined #yocto
florian_kc has joined #yocto
<yudjinn[m]>
I have a prject that uses bazel to build, and also requires numpy during build; I've tried including python2/3-numpy (and their native versions) to no avail, whats a good way to debug whats going on?
<angolini>
I'm getting a set of missing RDEPENDS from python3-pip recipe, and I wonder if this is somehow expected. It's the packages: python3-image (for colorsys) and python3-distutils. Should I send a patch adding the RDEPENDS or there is a better fix?