Thursday, 2019-10-24

*** la_croix <la_croix!> has quit IRC00:03
*** davisr <davisr!> has joined #yocto00:11
*** la_croix <la_croix!> has joined #yocto00:11
*** ericch <ericch!> has quit IRC00:12
*** vineela <vineela!~vtummala@> has quit IRC00:13
*** kaspter <kaspter!~Instantbi@> has quit IRC00:58
*** kaspter <kaspter!~Instantbi@> has joined #yocto00:58
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto01:03
*** dreyna_ <dreyna_!> has joined #yocto01:13
*** georgem <georgem!~georgem@> has quit IRC01:13
*** georgem <georgem!~georgem@> has joined #yocto01:13
*** dreyna <dreyna!> has quit IRC01:16
*** learning1 <learning1!~pi@> has quit IRC01:18
*** learning1 <learning1!~pi@> has joined #yocto01:27
*** nslu2-log <nslu2-log!> has quit IRC01:30
*** nslu2-log <nslu2-log!> has joined #yocto01:31
*** kaspter <kaspter!~Instantbi@> has quit IRC01:31
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:32
*** camus <camus!~Instantbi@> has joined #yocto01:35
*** kaspter <kaspter!~Instantbi@> has quit IRC01:36
*** camus is now known as kaspter01:36
*** sirus71 <sirus71!ac3a8b5a@> has joined #yocto02:18
sirus71if I'm building from x86_64 to rapsberry pi 4, and i'm bitbaking meta-toolchain-qt5 how do I get meta-qt5 to use the qmake.conf file found in
*** kaspter <kaspter!~Instantbi@> has quit IRC02:24
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:25
sirus71or if there is a particular forum to post this on02:31
*** sirus71 <sirus71!ac3a8b5a@> has quit IRC03:00
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto03:15
*** camus <camus!~Instantbi@> has joined #yocto03:31
*** kaspter <kaspter!~Instantbi@> has quit IRC03:33
*** camus is now known as kaspter03:33
*** kaspter <kaspter!~Instantbi@> has quit IRC04:14
*** kaspter <kaspter!~Instantbi@> has joined #yocto04:14
*** radeks <radeks!> has joined #yocto04:21
*** camus <camus!~Instantbi@> has joined #yocto04:35
*** kaspter <kaspter!~Instantbi@> has quit IRC04:36
*** camus is now known as kaspter04:36
*** kaspter <kaspter!~Instantbi@> has quit IRC05:04
*** kaspter <kaspter!~Instantbi@> has joined #yocto05:04
*** AndersD <AndersD!> has joined #yocto05:18
*** kroon <kroon!~kroon@> has joined #yocto05:26
LetoThe2ndsven^: thank, will look into it05:49
*** agust <agust!> has joined #yocto05:49
*** camus <camus!~Instantbi@> has joined #yocto05:59
*** kaspter <kaspter!~Instantbi@> has quit IRC06:00
*** camus is now known as kaspter06:00
*** radeks <radeks!> has quit IRC06:07
*** goliath <goliath!> has joined #yocto06:07
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto06:20
*** Micro23 <Micro23!> has joined #yocto06:25
*** TobSnyder <TobSnyder!> has joined #yocto06:32
*** frsc <frsc!> has joined #yocto06:35
*** kaspter <kaspter!~Instantbi@> has quit IRC06:37
*** kaspter <kaspter!~Instantbi@> has joined #yocto06:37
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto06:40
yoctiNew news from stackoverflow: Auditd in Yocto <>06:49
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto06:57
*** camus <camus!~Instantbi@> has joined #yocto06:59
*** kaspter <kaspter!~Instantbi@> has quit IRC07:00
*** camus is now known as kaspter07:00
*** yacar_ <yacar_!> has joined #yocto07:06
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC07:12
yoctiNew news from stackoverflow: U-boot environment is not the same as Linux "fw_printenv" <>07:19
*** tprrt <tprrt!~tprrt@> has joined #yocto07:19
*** mckoan|away is now known as mckoan07:20
*** yann <yann!> has quit IRC07:20
*** goliath <goliath!> has quit IRC07:22
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC07:32
*** kaspter <kaspter!~Instantbi@> has quit IRC07:34
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:35
*** yacar_ <yacar_!> has quit IRC07:42
*** kaspter <kaspter!~Instantbi@> has quit IRC07:56
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:57
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:58
*** Bunio_FH <Bunio_FH!> has joined #yocto08:05
*** kaspter <kaspter!~Instantbi@> has quit IRC08:05
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:06
*** farnerup <farnerup!> has joined #yocto08:10
*** khem <khem!~khem@unaffiliated/khem> has quit IRC08:10
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:12
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto08:12
*** palate <palate!~palate@unaffiliated/palate> has joined #yocto08:22
*** goliath <goliath!~goliath@> has joined #yocto08:28
*** kaspter <kaspter!~Instantbi@> has quit IRC08:34
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:34
*** yann <yann!~yann@> has joined #yocto08:36
*** falk0n <falk0n!> has quit IRC08:45
yoctiNew news from stackoverflow: Holding splash screen until X Server is ready using dbus <>08:50
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto08:52
*** kaspter <kaspter!~Instantbi@> has quit IRC08:55
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:55
*** dreyna_ <dreyna_!> has quit IRC08:58
*** kaspter <kaspter!~Instantbi@> has quit IRC09:12
*** kaspter <kaspter!~Instantbi@> has joined #yocto09:12
*** JaMa <JaMa!> has joined #yocto09:14
*** frsc <frsc!> has quit IRC09:33
*** frsc <frsc!> has joined #yocto09:33
*** VoidNick <VoidNick!> has joined #yocto09:47
qschulzhi all, I'm extremely puzzled by
qschulzLet me explain. We have two identical machines, machineA includes machineB and MACHINEOVERRIDES =. "machineb:". The reason for that is not part of the discussion, but they ARE identical except the name and the overrides.09:51
qschulzwhen we build machineA and then machineB, linux-libc-headers gets recompiled09:51
qschulzbecause it inherits kernel-arch which is adding STAGING_KERNEL_DIR to KERNEL_CC which is machine-specific (it has the name of the machine in it)09:52
qschulzI have very limited knowledge of gcc and flags/parameters so I might misunderstand the addition of -fdebug-prefix-map=${STAGING_KERNEL_DIR}=${KERNEL_SRC_PATH} for all recipes inheriting kernel-arch09:53
qschulzfor me, with my very limited understanding of this, this has its place in module.bbclass, not kernel-arch.bbclass09:53
qschulzthe big issue is that having linux-libc-headers recompiled is that, glibc is also recompiled and then the whole world is recompiled. Then everything is basically machine-specific and it results in extremely long builds09:54
*** radsquirrel <radsquirrel!> has quit IRC09:58
*** radsquirrel <radsquirrel!> has joined #yocto09:59
qschulzDoes anyone know if the original commiter "He Zhe" from WindRiver is on IRC?09:59
qschulzI see rburton isn't here anymore so can't bother him with this :)10:00
RPqschulz: this does sound very much like a bug10:02
RPqschulz: what puzzles me is that we have tests for this kind of contamination10:05
RPqschulz: just because it has the name of the machine in, that doesn't mean it would necessarily rebuild as some paths do get filtered out10:06
qschulzI do not exclude that we've done something wrong in our custom layers though10:06
RPqschulz: have you tried diffsigs?10:06
RP(if you don't know what I mean that is fine, I can explain)10:07
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:08
qschulzRP: afk for 30min, I'll pick up then with whatever you wrote10:08
RPqschulz: basically find the tmp/stamps for linux-libc-headers and run bitbake-diffsigs on the two different sigdata files you see there (earliest task that has different sigs)10:08
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:08
kanavinRP, regarding adding polkit to oe-core (for sysprof and systemd), polkit hard-depends on mozjs, the mozilla javascript engine :(10:23
kanavinRP, so I am leaning towards actually shifting sysprof to meta-oe10:23
RPkanavin: hmm, I think we used to have that in core, probably due to this10:27
*** ykrons <ykrons!~guillaume@> has quit IRC10:27
RPkanavin: I do worry we should really have polkit there for systemd :/10:27
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:28
LetoThe2ndkanavin: RP: if polkit and mozjs get sucked into the systemd defaults, i can already hear screaming and cursing10:29
kanavinRP, I'm not able to find any mentions of mozjs in oe-core10:29
kanavin(in oe-core git log)10:32
kanavinlet's wait and see what rburton says10:32
RPkanavin: is what I was thinking of10:36
RPLetoThe2nd: it would be optional10:37
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:37
LetoThe2ndRP: whoa i just had a heartattack. i misread "it would be optimal210:38
kanavinRP, right. The current mozjs recipes pulls in a few python bits as well:
kanavinpython 2.x bits10:38
RPkanavin: we really don't want py2...10:47
kanavinRP: right, so bringing mozjs into core is not a trivial task10:51
T_UNIXare `python __anonymous` in `.bb` or `.bbappend` simply anonymously injected, or are they addressable/overwritable in a `.bbappend`?10:51
*** Klanticus <Klanticus!~quassel@> has joined #yocto10:55
*** VoidNick <VoidNick!> has quit IRC10:55
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto11:01
RPkanavin: no, doesn't look like it. Nothing ever seems simple :/11:02
RPT_UNIX: the former unfortunately11:02
*** radeks <radeks!> has joined #yocto11:07
qschulzRP: I knew about bitbake-dumpsigs diffsigs but I thought you had something very specific in mind11:12
qschulzRP: anyway. I tried without using our images but just MACHINE=machine abitbake linux-libc-headers followed by same but for machineb. It's not rebuilt (directly taken from sstate-cache, I've no do_install.siggdata so I'm certain it's from sstate-cache11:13
qschulzso I'd say we're fucking up something11:13
qschulz(by we, I mean where I work, not YP :) )11:14
qschulzdo you have any pointers on how to debug this?11:14
qschulzdoes the bitbake-dumpsigs suggestion still stands? Will it help with poisoning from other recipes? (I guess?) Our image is just taking an awful amount of time to build (qtbase :) )11:15
qschulzso the debugging might take some time :)11:15
RPqschulz: diffsigs is exactly how to debug11:15
RPqschulz: it should tell you what is changing11:15
qschulzRP: alright, now the waiting game :) Thx for the help, will let you know if I find something interesting or need help11:17
qschulzsorry for the scare, looks like we messed up and nothing to do with YP :)11:17
qschulzRP: I'm interested in what you meant by " 12:06          RP| qschulz: just because it has the name of the machine in, that doesn't mean it would necessarily rebuild as some paths do get filtered out"11:19
qschulzwhat is this filtering mechanism and where is it used, what for, etc. :)11:19
*** khem <khem!~khem@unaffiliated/khem> has quit IRC11:20
RPqschulz: note you don't need to wait for the build. Just "bitbake linux-libc-headers" for each machine11:20
RPqschulz: you could even just do "bitbake linux-libc-headers -S none" and skip building entirely (will generate the sig files)11:21
*** learning1 <learning1!~pi@> has quit IRC11:21
RPqschulz: if you build in two different locations, you'd want the sstate object to be identical. Paths therefore get filtered out of the sigs11:22
RPsome paths anyway11:22
qschulzRP: this does not reproduce the full build (bitbake linux-libc-headers)11:22
qschulzsorry, this does not reproduce the bug11:22
RPqschulz: but it rebuilds linux-libc-headers?11:23
qschulzIt does not seem so, it's taken from the sstate-cache directly and I don't see anything new in stamps11:23
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto11:24
*** radeks_ <radeks_!> has joined #yocto11:24
*** tprrt <tprrt!~tprrt@> has quit IRC11:24
RPqschulz: so what you told me earlier about rebuilding it isn't quite right :/11:24
RPqschulz: you need to find out what does actually rebuild, then use diffsigs there11:25
*** radeks <radeks!> has quit IRC11:26
*** goliath <goliath!~goliath@> has quit IRC11:28
qschulzRP: sorry, I'm getting all confused. Starting from zero:11:29
qschulzcleansstate of all linux-libc-headers for all machines. MACHINE=machinea bitbake my-image; MACHINE=machineb bitbake my-image; bitbake-ddiffsigs stamps/linux-libc-headers/*/*do_install*11:30
qschulzHash for dependent task linux-libc-headers/ changed from 5ad454ec2f7f2cd3059917a80291509f to c554e27feec0caba02f1f8e9d205480b11:30
qschulzbut wtf because in => do_compile[noexec] = "1"11:33
*** learning1 <learning1!~pi@> has joined #yocto11:33
qschulzdamn... do_compile has set_icecc_env in it11:34
qschulzeven if it's not executed I guess the task hash still matters atm11:34
qschulzRP: this line I think is the only change11:36
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto11:36
*** goliath <goliath!~goliath@> has joined #yocto11:37
*** yacar_ <yacar_!~yacar@> has joined #yocto11:38
T_UNIXRP: thanks!11:42
*** tprrt <tprrt!~tprrt@> has joined #yocto11:46
*** berton <berton!~berton@> has joined #yocto11:46
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto11:50
*** berton <berton!~berton@> has quit IRC11:51
*** berton <berton!~berton@> has joined #yocto11:53
*** radeks_ <radeks_!> has quit IRC12:13
milloniis there an irc channel for automotive grade linux?12:19
mdpmilloni: #automotive12:20
millonithanks! - is that for automotive in general, not agl specifically?12:21
qschulzRP: guess that's the one12:21
mdpmilloni: topic is automotive foss, but it's 99% agl talk12:21
*** litb <litb!> has joined #yocto12:24
litbJaMa, sorry, my issue report on github was incorrect! I wasn't aware that qt configure uses cross canadian schemes for qmake. so it will use qmake built by qtbase-native12:24
litbi will close my issue report in the evening12:24
LetoThe2ndRP: btw, have you seen ?12:29
LetoThe2ndRP: reporter didn't want to create a loging for bugzilla nor register to the ML.12:29
JaMalitb: cool12:32
JaMaqschulz: you mean you're missing this change in our build, right?12:34
qschulzJaMa: I mean that's the one commit which is missing in thud I think. I'm testing right now :)12:35
qschulzGood thing is, if it's really this commit, it's a change in a bbclass, so I can just override this bbclass until we migrate to warrior 2.7.212:36
JaMaqschulz: yes, it's missing in thud, I never sent the backport request for that, but I have it in my "fork"
*** camus <camus!~Instantbi@> has joined #yocto12:37
*** kaspter <kaspter!~Instantbi@> has quit IRC12:38
*** camus is now known as kaspter12:38
qschulzJaMa: I'm surprised it made it to warrior as a backport but not thud, that's all12:39
tlwoernerhas anyone else's build of libcap-ng-native fail today as a result of the upgrade from 0.7.9 to 0.7.10? it looks like a host issue, so i'm hesitant to report it on the mailing list12:39
qschulz(considering thud was still maintained at that time)12:39
tlwoerner-> /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: /z/jenkins-workspace/nightly/cubietruck/build/tmp-glibc/work/x86_64-linux/libcap-ng-native/0.7.10-r0/build/src/.libs/ undefined reference to `pthread_atfork'12:40
JaMaqschulz: backport request sent now12:40
JaMaqschulz: I've fixed it locally while waiting for the backport to warrior to be merged and then I just forgot to send it for thud as well, because sstate-diff-machines was no longer complainig (because of the local fix for that)12:41
*** georgem_ <georgem_!~georgem@> has joined #yocto12:42
qschulzJaMa: Cool, thx.12:43
qschulzno worries :)12:43
qschulzHappy that's it's fixable (and fixed already upstreamed :) )12:43
JaMait's useful to run script as part of your CI to catch these issues early12:43
JaMawith many layers it's a bit problematic, because many layers still have even parsing issues with this and then the script cannot work12:44
JaMae.g. isn't really useful now12:44
tgamblintlwoerner: just tried, got same issue12:45
*** georgem <georgem!~georgem@> has quit IRC12:45
JaMameta-virtualization adds even more issues I haven't reported yet12:45
JaMaERROR: Nothing RPROVIDES 'apache2' (but /home/jenkins/anaconda/build-webos-thud/build/meta-virtualization/recipes-extended/nagios/ RDEPENDS on or otherwise requires it)12:47
JaMaERROR: Nothing PROVIDES 'syslinux' (but /home/jenkins/anaconda/build-webos-thud/build/meta-virtualization/recipes-extended/ipxe/ DEPENDS on or otherwise requires it)12:47
JaMasyslinux was skipped: incompatible with host arm-webos-linux-gnueabi (not in COMPATIBLE_HOST)12:47
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:54
*** VoidNick <VoidNick!~dw@> has joined #yocto12:59
RPqschulz: I had to step away but looks like you found the source of the problem12:59
RPLetoThe2nd: strangely enough no, I have not seen that13:00
LetoThe2ndRP: any objects? can you take it, or want me to formally report/mail it?13:01
RPLetoThe2nd: question is about attribution I guess13:01
qschulzRP: np, I don't expect anyone to answer under a given time (or even at all).13:02
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto13:02
tlwoernertgamblin: okay, thanks for checking! i'll report it in the mailing list13:03
LetoThe2ndRP: well its a rather trivial one, so i guess its fine if somebody just pushes it as "hum i noticed"13:03
RPLetoThe2nd: mailed it out with a guess at what its for13:03
VoidNickHello, I have some problems with yocto warrior release. It fails with the default qemu image. Is it the right place here to get some help?13:05
LetoThe2ndRP: thanks.13:06
LetoThe2ndVoidNick: try pouring your question into a form that can be answered, then yes :)13:06
VoidNickOk, i'll try:13:06
VoidNickFollowing and switching to the warrior branch. The command "bitbake core-image-sato" fails with:  pthread_atfork.c:51: undefined reference to `__dso_handle'13:09
VoidNickHost is Ubuntu 18.0413:09
LetoThe2ndVoidNick: w.0 is massively outdated13:09
LetoThe2nd2.0, i mean13:10
VoidNickok, so I have to do something different?13:11
LetoThe2ndand i actually just gave 2.7.1 a.k.a. warrior a full sato build on ubuntu 18.04 this morning, so i'm relatively sure that its related to your specific box13:12
LetoThe2ndVoidNick: can you retry following this?
zeddiiRP: just cc’d you on my qemumips64 boot issues with v5.4-rcX13:13
zeddiithat’s the earliest I’ve ever gotten around to finding an issue .. normally we find them when there’s no time left :D13:13
JPEWRP: No luck reproducing the Fedora perl non-reproducible error. Has anyone seen it on the AB since?13:14
VoidNickLetoThe2nd: ok, I try13:15
LetoThe2ndVoidNick: also, see my answer at for possible error mitigations, if this comes from seomthing in your specific dev host setup13:20
yoctiNew news from stackoverflow: How to add changed dts-file in kernel in Yocto? <>13:20
yannbuilding mesa on zeus, I get a meson failure saying: ERROR: Unknown variable "_drivers"13:28
RPJPEW: happens most builds :/13:28
*** wertigon <wertigon!> has joined #yocto13:29
yannnever looked at meson before, but that "_drivers" name seems to occur only at that line - surely I can't be the only one to see that issue ?13:29
JPEWRP: Ok, that's actually good. It means the error is (probably) in sstate and if I can get my local build to pull from AB sstate (its not now for some reason), it should be easier to reproduce13:29
JPEWI'll keep trying13:30
wertigonHi, got a big problem trying to build the SDK to our distribution. I run bitbake -c output_sdk test-image and is greeted with two file not found errors on two packages.13:30
RPJPEW: we could get you ssh onto that worker if that would help?13:31
RPzeddii: hmm, forwarded that to someone who might have contacts13:31
JPEWYa, If I can pull the offending packages, I can run diffoscope on them13:32
RPJPEW: halstead can probably get you access13:32
wertigonI get that recipes-devtools/clang/ fails with build/tmp-glibc/work/.../nativesdk-libcxx/.../x86_64-test-linux-llvm-ar: No such file or directory13:33
wertigonAny ideas how to solve it? Been looking around the web but no luck as of yet13:33
JPEWNow that reproducible builds aren't generating 1000s of offending packages, we might try running diffoscope as part of the build logs so we have all the info... maybe there's some way to reduce the CPU/space requirements.13:34
RPJPEW: the host dependency issues with this worry/scare me13:37
RPJPEW: if you can hack the build to stash the different packages into /tmp/somewhere, I can run that on the AB btw13:37
JPEWRP: It might not be that FWIW. Perl does almost nothing correctly to be reproducible :)13:38
wertigonAlso same thing happens with recipes-devtools/clang/compiler-rt_git.bb13:38
LetoThe2ndwertigon: as clang is not in poky nor meta-openembedded, things might be a bit difficult.13:38
*** georgem_ is now known as georgem13:38
JPEWI would not be suprised if there is a "bad" perl build in sstate that only the fedora builder pulls13:38
LetoThe2ndwertigon: maybe khem  can chime in, but i guess your best chance is the mailing list.13:38
kroonwertigon, maybe something todo with ?13:39
*** farnerup <farnerup!> has quit IRC13:39
wertigonYeah, I've inherited a Poky distribution at work and my usual goto reference is on vacation :/13:39
LetoThe2ndwertigon: well then, sounds like you're about to have fun.13:40
*** farnerup <farnerup!> has joined #yocto13:45
*** kaspter <kaspter!~Instantbi@> has quit IRC13:45
*** kaspter <kaspter!~Instantbi@> has joined #yocto13:46
wertigonBummer, I'll test that patch kroon sent and we'll see from there13:47
wertigonI did see SDK was defined as ${SDK}-${OS} in one place13:47
kroonwertigon, you can just check your SDK_VENDOR13:47
kroonwertigon, bitbake -e test-image | grep ^SDK_VENDOR=13:48
yannok that's only happening when mesa is built without dri, and there are other issues lurking behind that, I'll look and submit a patch13:49
*** WillMiles <WillMiles!> has joined #yocto13:51
wertigonSDK image is "-test"13:53
wertigonOr sorry, SDK_VENDOR I mean13:53
wertigonAnd the name of my image is test-dev-image13:54
*** Hellgineer <Hellgineer!> has joined #yocto13:56
HellgineerHi Yocto community!13:57
florianhi Hellgineer13:58
* LetoThe2nd can't greet, is scared.13:59
* jofr hides behind LetoThe2nd13:59
* LetoThe2nd quickly turns round and pushes jofr forwards.13:59
* jofr whisper "Who is that cheerful person and what does he want with us??"13:59
* jofr collapses into a fetal-position.14:00
* Hellgineer wonders if the greeting was a good way to start this conversation14:00
LetoThe2ndHellgineer: that can be answered with a clear "no"14:00
qschulzHellgineer: just put a beer on the table and wait for LetoThe2nd to come out of his hideout14:01
jofrSoftware people can't do "conversation". We're embedded software people. We're WORSE!  :p14:01
LetoThe2ndmh... did i hear "beer"?14:02
* Hellgineer puts a local IPA on the table and steps back14:02
jofrNooooo! It's a traaaaap!14:02
HellgineerDamn it!14:02
* LetoThe2nd looks at bottle,reads, puts bottle back and shrugs "nah i dn't drink IPAs."14:02
jofrI don't think LetoThe2nd even cares if it's a trap or not..  ;)14:03
*** AndersD <AndersD!> has quit IRC14:03
jofrOhh, fine.14:03
HellgineerI heard embedded software people might have knack for structuring Yocto layers (the good way (tm))14:03
LetoThe2ndthat sounds very much like a trick question!14:05
HellgineerThe legend says that three different layer types exists: 1. BSP 2. Distros 3. Software. It is also, from the great Yocto manual, not a good idea to keep Distro layer with recipes, hence many meta-* layers having a *-bsp and a distro one. What is the reasoning behind that?14:07
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC14:07
HellgineerWould it be a sin to have a machine + distro + images in the same meta-* ?14:07
*** kaspter <kaspter!~Instantbi@> has quit IRC14:07
*** kaspter <kaspter!~Instantbi@> has joined #yocto14:08
wertigonNot a sin, no... But it makes more sense to divide it in the way listed14:08
wertigonReason being, you might want to run the distro on more than a single machine (like a rev. 2.0 uses a TI chip instead of a GloFo chip or something)14:09
LetoThe2ndHellgineer: it depends (TM)14:10
* Hellgineer lol14:10
wertigonAnd you might want to have different roles (cluster of 3 RPi that acts as a webserver, FTP and git servers, for instance)14:11
wertigonWith the same hardwar14:11
wertigonFinally you might want to have different profiles for the distro without touching the rest14:11
LetoThe2ndHellgineer: nah, seriously. it pretty much depends if your hardware is fully-customized for a very specific application. if there's little change it could ever be repurposed, then the separation can be left out. whereas if you're on something more generic, or even a platfomr that you can "just buy", then a seperate bsp layer is almost due14:12
wertigone.g. debug / release14:12
LetoThe2ndHellgineer: app / distro layers are a bit more complicated. splitting them up is a kind of "known good practise", yet not always needed. it really comes down to your project, development workflow and also lifecycle management14:13
wertigonThat's why you want to separate hw/sw/distro, but yeah.14:13
LetoThe2ndso, i'd conclude: "if unsure, seperate the three."14:15
HellgineerWow thanks for that, I think I moved a step forward. So with a 'multi-machine' distro with many profiles (ex. STD, SDK, Light, etc...), the best would be to have two diff. meta layers, then separate SW layers accordingly14:16
LetoThe2ndHellgineer: absolutely.14:16
*** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has quit IRC14:19
HellgineerLet's say that the distro would not to include another readily available meta-layer, what is the suggested GIT/CI strategy to make sure that everything is in the Source Directory before launching a build?14:19
HellgineerWould you checkout everything manually before build, or maybe create a new 'internal' repository with the poky repo + the metas. ?14:20
LetoThe2ndHellgineer: can you rephrase? i guess you either mangles the sentence or typoed somewhere so i don't really get the question14:20
LetoThe2ndcheck out everything before build. there's tools and magic for it, basically kas and repo. you can also make a combined distro layer, i think ross has an example somewhere, using git submodules.14:21
Crofton|workgit submodules for the win :)14:22
*** ericch <ericch!> has joined #yocto14:22
HellgineerThat's nice!14:24
HellgineerYou guys are really helpful, thank you very much!14:24
* Hellgineer lefts a big tips on the table, besides the untouched IPA14:25
mckoanthose are git submodule14:26
litbNeed to add ${bindir} to SYSROOT_DIRS for cmake projects, because cmake expects dll files which are installed to bin/ to be present14:26
*** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has joined #yocto14:26
litbI think I should not add it to SYSROOT_DIRS though, to prevent binaries to be put into recipe-sysroot-s. instead, I'm going to _append to do_populate_sysroot14:26
alessioigorI use git-submodules of git-submodules!14:27
halsteadJPEW, Let me know if I can help with access.14:31
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:32
*** wertigon <wertigon!> has quit IRC14:35
*** goliath <goliath!~goliath@> has quit IRC14:40
*** kroon <kroon!~kroon@> has quit IRC14:48
*** tprrt <tprrt!~tprrt@> has quit IRC14:48
VoidNickhave got still the same error: undefined reference to __dso_handle14:51
LetoThe2ndVoidNick: so in that case, what is special about your host? :)14:52
*** Micro23 <Micro23!> has quit IRC14:54
*** VoidNick <VoidNick!~dw@> has quit IRC14:55
*** VoidNick <VoidNick!~dw@> has joined #yocto14:57
*** frsc <frsc!> has quit IRC15:04
VoidNickok it seems that the host pc still lacks some packages.15:05
infmaybe someone stumbled upon this - i'm trying to implement swupdate & u-boot on raspberrypi 3 on warrior... i've managed to figure everyting out based on official examples and meta-swupdate, but u-boot seems to randomly fail to load / save environment from fat (with either "invalid crc" error, or just straight up failing with WARNING at drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()!)15:07
*** kaspter <kaspter!~Instantbi@> has quit IRC15:07
*** camus <camus!~Instantbi@> has joined #yocto15:07
*** camus is now known as kaspter15:09
*** VoidNick <VoidNick!~dw@> has quit IRC15:10
*** frsc <frsc!> has joined #yocto15:10
infrunning in 32-bit mode with this patch but doesn't seem like might cause this?15:10
*** yann <yann!~yann@> has quit IRC15:14
*** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has quit IRC15:17
*** TobSnyder <TobSnyder!> has quit IRC15:19
*** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has joined #yocto15:19
*** yacar_ <yacar_!~yacar@> has quit IRC15:27
*** VoidNick <VoidNick!> has joined #yocto15:30
*** farnerup <farnerup!> has quit IRC15:33
JPEWhalstead: Is it possible I could get ssh access to the fedora30 worker to pull some files off?15:35
*** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has quit IRC15:35
JPEWhalstead: Or anyway of pulling files would work. Doesn't need to be ssh15:36
halsteadJPEW, Yes. Let me see if I already have your ssh public key.15:36
JPEWShould be in meta-mingw15:36
JPEWand poky-contrib15:36
*** Hellgineer <Hellgineer!> has left #yocto15:39
litbhmm, I suspect when I use multiconfig and both of the config need the same -native recipes, the -native recipes will be built twice :(15:39
* armpit hmm Alex's changes look promising for warrior's issue15:39
litbbecause sstate cache is not used during the multiconfig build15:39
JPEWlitb: sstate should be shared between two multiconfig builds in the same invocation as of 3.015:42
litboh nice15:42
*** Bunio_FH <Bunio_FH!> has quit IRC15:43
*** frsc <frsc!> has quit IRC15:44
JPEWlitb: It's worked in back to back invocations for a while (bitbake mc:A:bar && bitbake mc:B:bar), but now it should also share when you do: bitbake mc:A:bar mc:B:bar15:46
litbnice, because when we build our linux firmware + windows/mingw customer programs , both of these will share many -native recipes.15:48
JPEWlitb: Yep15:48
litbalthough I guess back to back execution would not be very slower15:49
litbafter all, there's enough recipes in both such that they saturate the CPU when executed along15:49
JPEWlitb: Ya. I suspect the more useful case there is when you have inter-recipe multiconfig dependencies (i.e. mcdepends)15:50
litbI see15:50
halsteadJPEW, I've sent an e-mail with connection information.15:57
*** DChacon <DChacon!c037362a@> has joined #yocto16:08
JPEWhalstead: Thanks16:15
*** DChacon <DChacon!c037362a@> has quit IRC16:17
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto16:18
lpappwhy do I get two versions in the kernel's ipk filename? build/tmp/deploy/ipk/polatisnic/kernel-3.2.1-r21_3.2.1-r22_polatisnic.ipk16:18
lpappshouldn't it be just build/tmp/deploy/ipk/polatisnic/kernel-3.2.1-r22_polatisnic.ipk16:25
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:26
mckoanlpapp: perhaps a mismatch in the recipe's variables?16:30
lpappwhich variables?16:30
lpappmckoan: this is what I have, ===============================16:32
lpappthe kernel recipe16:32
lpappanything suspiciously wrong with it? Based on your reply, I assume that is not what you get in your builds, the pattern itself?16:32
mckoanlpapp: what's the recipe filename?16:34
lpappyou can see at the top from cat16:35
lpappsame as with the linux-yocto patterns16:35
lpappoops, cat did not make it into the paste, my fault16:35
*** VoidNick <VoidNick!> has quit IRC16:36
lpappmckoan: linux-polatis_3.2.1.bb16:36
*** vineela <vineela!~vtummala@> has joined #yocto16:37
lpappthe other thing is that, this does not seem to make it into the uname: LINUX_VERSION_EXTENSION ?= "-polatis-${PR}"16:37
lpappI would ideally like to resolve both16:37
*** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has joined #yocto16:38
mckoanlpapp: it is normal: kernel-image-4.4.26-yocto-standard_4.4.26+git0+3030330b06_ca6a08bd7f-r0_beaglebone.ipk16:38
lpappnormal as in yocto uses it, but I do not have multiple versions on desktop and to be fair, I like it that way. Why does it have to repeat the version when using Yocto?16:39
mckoanlpapp: no clue, sorry16:40
lpapphmm, I see, thanks, what about the uname issue?16:40
lpappdoc says: LINUX_VERSION_EXTENSION: The Linux kernel CONFIG_LOCALVERSION that is compiled into the resulting kernel and visible through the uname command.16:40
lpappmaybe, daisy did not support it16:40
lpappoh, it did16:41
lpappso, yeah, no clue really16:41
lpappLinux polatisnic 3.2.1-r21 #1 PREEMPT Thu Nov 22 16:32:08 GMT 2018 armv5tejl GNU/Linux16:41
*** mckoan is now known as mckoan|away16:43
*** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has quit IRC16:46
lpappmy colleague added some code to remove old kernel when we are upgrading the kernel...16:48
lpappI think it makes no sense, opinions?16:48
*** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has joined #yocto16:48
lpappIn my opinion, it should be opkg's responsibility... failing that, we should add a post-install script to our kernel package to clean up old kernels in case we are paranoid?16:48
RPlpapp: FWIW the version is in the name so that its possible to install two kernels in parallel17:06
RPlpapp: some users need to do that in for example an upgrade scenario to have a fallback17:06
*** goliath <goliath!> has joined #yocto17:07
litbJPEW, ah cool, yocto 3.0 was released yesterday!17:08
RPlitb: sharing sstate between multiconfigs dyanmically mid build was one of the features :)17:10
*** Bunio_FH <Bunio_FH!> has joined #yocto17:23
*** Bunio_FH <Bunio_FH!> has joined #yocto17:25
JPEWRP: AB doens't seem to have preserved the non-reproducible perl packages for me to diff, so I'm back to trying locally17:32
JPEWUnless I'm looking in the wrong location17:32
*** wbn <wbn!~badegg@2607:5300:60:2ca::1> has joined #yocto17:33
litbJPEW, but this in the 3.0 mega manual is now incorrect?17:33
litb"Support for multiple configuration builds in the Yocto Project 3.0 (Zeus) Release does not include Shared State (sstate) optimizations. Consequently, if a build uses the same object twice in, for example, two different TMPDIR directories, the build either loads from an existing sstate cache for that build at the start or builds the object fresh. "17:34
JPEWYes, that is wrong17:34
RPJPEW: no, its selftest so it won't have it :(17:35
RPJPEW: could we try what I suggested - give me a patch to copy them to /tmp ?17:35
JPEWRP: Ok, I'll do that.17:35
RPJPEW: If you want it faster, hack it to disable other selftests :)17:35
RPJPEW: in fact put that in a poky branch on contrib and I can just run that :)17:36
JPEWRP: Ok17:36
*** Klanticus <Klanticus!~quassel@> has quit IRC17:52
*** Klanticus <Klanticus!~quassel@> has joined #yocto17:52
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC18:07
*** litb <litb!> has quit IRC18:13
*** zwelch <zwelch!> has joined #yocto18:18
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto18:27
*** yann <yann!> has joined #yocto18:37
mischiefdoes anyone know why python3 native packages don't compile with icecc even when it is enabled?18:38
kergothdo we have a tool/script to clear out old taint on tasks?18:49
kergothwithout wiping tmp, that is18:49
kergothhmm, anyone run into a libcap-ng-native build failure on certain hosts when building the utils due to a failure to find pthread_atfork? it seems like it requires -lpthread in LDADD the way it does in the tests, but i'm wondering why it fails to add it automatically via the .la unless something wentw rong with libtool, since the in-builddir .la should still exist18:52
JPEWmischief: No. Perhaps it's not invoking the compiler specified in $CC, or it's passing some argument that icecc doesn't like18:52
JPEWmischief: Or, you have it blacklisted :)18:53
mischiefJPEW: yeah, maybe the former, but it does seem to somehow invoke the right cross-toolchain. i am no pythonista though, can't really figure out the guts of distutils :-(18:58
JPEWmischief: I'm not too familiar with it either. Does it print the compile commands?18:58
*** litb <litb!> has joined #yocto18:58
* kergoth tries using meta-external-toolchain with an oe-built sdk18:58
mischiefseems so19:00
litbwould it make sense to add a 'mingw' disto-feature, so that packages can use this to configure their default PACKAGECONFIGs ?19:01
mischiefanother silly question, is there a way to enumerate all kernel module packages including external modules so i can put them in a image?19:01
litbotherwise, the only remaining thing for packages to arrange for valid config lines is the TARGET_OS override, which isn't as nice to use in PACKAGECONFIG19:02
mischief'kernel-modules' package depends on all in-tree modules but i need out of tree ones as well19:02
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:13
*** Bunio_FH <Bunio_FH!> has quit IRC19:15
*** Bunio_FH <Bunio_FH!> has joined #yocto19:15
*** Bunio_FH <Bunio_FH!> has quit IRC19:16
JPEWmischief: grep for inherit module ?19:19
JPEWmischief: I don't know if there is a better way19:19
mischiefJPEW: i would preferrably do it programmatically, since different $MACHINE needs different modules for us.19:21
mischiefi don't really want to use $MACHINE_ESSENTIAL... since that might contain non-module packages19:22
JPEWmischief: If you had the list of all modules, what would you filter it on to figure out which ones when to which machines?19:24
mischiefthe content of build/tmp/deploy/deb/$MACHINE/kernel-module*.deb is basically what i want, but i suppose that isn't known until the recipes produce the packages19:26
*** tgamblin <tgamblin!~tgamblin@> has quit IRC19:32
*** ericch <ericch!> has quit IRC19:36
*** ericch <ericch!> has joined #yocto19:37
RPkergoth: an rm tmp/stamps/*/*.taint (or similar) would probably work19:50
RPprobably */*/*.taint19:50
*** gnac <gnac!> has quit IRC19:51
*** WillMiles <WillMiles!> has quit IRC21:03
*** zwelch <zwelch!> has quit IRC21:06
RPJPEW: went and succeeded: :(21:13
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto21:13
litb"BitBake finds and applies multiple patches for a single recipe in the order in which it locates the patches" hi! what does this mean?21:15
litbdoes this mean that it's the order in which they appear in SRC_URI?21:16
bluelightninglitb: yes21:17
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC21:17
*** berton <berton!~berton@> has quit IRC21:21
JPEWRP: Ya, I was looking through and most of the failures were from test_devtool_deploy_target, not the perl reproducible test (although there were a few).21:34
RPJPEW: I think its a race depending on what makes it into sstate on the original build when perl is rebuilt :/21:35
JPEWRP: Rebuilds are problematic. You might be able to keep the two patches in master-next to catch it next time; it doesn't really have any overhead when there's no failure21:35
RPJPEW: agreed, I'll try and do that21:37
*** litb <litb!> has quit IRC21:37
* kergoth starts working on oe selftests for meta-external-toolchain, emit an oe/yocto sdk, then for each included external recipe, build the internal and external versions and compare their contents, etc21:50
*** armpit <armpit!~armpit@2601:202:4180:a5c0:d998:942e:6613:6ef4> has quit IRC21:58
*** JaMa <JaMa!> has quit IRC22:08
*** tgamblin <tgamblin!> has joined #yocto22:25
*** goliath <goliath!> has quit IRC22:37
*** m1ster_r0b0t <m1ster_r0b0t!> has joined #yocto22:42
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC22:50
RPJPEW: A new plan - can you rebase those patches onto a failed master-next build? That might retrigger easier?22:58
RPJPEW: I'm about to sleep but someone else may be able to trigger a build. If not, I can sort such a branch tomorrow and trigger worse case22:58
* RP needs to sleep22:59
RPJPEW: I'm thinking if it failed once the broken sstate should be there22:59
*** robbawebba <robbawebba!~rob@> has quit IRC23:02
*** m1ster_r0b0t <m1ster_r0b0t!> has quit IRC23:08
*** ericch <ericch!> has quit IRC23:21
*** Klanticus <Klanticus!~quassel@> has quit IRC23:27
*** agust <agust!> has quit IRC23:27
*** Klanticus <Klanticus!~quassel@> has joined #yocto23:28
*** vineela <vineela!~vtummala@> has quit IRC23:46

Generated by 2.11.0 by Marius Gedminas - find it at!