Tuesday, 2019-12-03

RPMarex: not sure how well/tested this is in practise but I'm fairly sure it could be made to work00:00
MarexRP: doesn't linux-yocto and linux-yocto-rt already have a different namespace ?00:00
MarexRP: all right, I will put it on the list of things to investigate, thanks!00:00
RPMarex: the module output names may or may not be, not sure00:00
RPMarex: you're right, PN is already fine there00:01
MarexRP: I will take a look, thanks!00:02
RPkanavin_: https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1307 is odd :/00:14
RP(python2.7 needed by piglit?)00:14
RPThat was in a build with py2 removal so it shouldn't be there?00:14
RPah, that was a ross/next build00:16
RPmine is the much redder build :(00:17
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC00:29
*** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC00:43
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto01:09
*** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC01:36
*** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has quit IRC01:36
*** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has joined #yocto01:51
*** kaspter <kaspter!~Instantbi@> has quit IRC01:57
*** kaspter <kaspter!~Instantbi@> has joined #yocto01:59
*** tz <tz!~tz@orange.tzarc.io> has quit IRC03:41
*** tz <tz!~tz@orange.tzarc.io> has joined #yocto03:45
*** khem <khem!~khem@unaffiliated/khem> has quit IRC05:40
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto05:45
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto05:58
*** toner <toner!~ink@107-199-78-50.lightspeed.mtryca.sbcglobal.net> has quit IRC05:59
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto06:21
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto06:41
*** xtron <xtron!~xtron@> has joined #yocto06:43
*** pohly <pohly!~pohly@p54BD5B80.dip0.t-ipconnect.de> has joined #yocto07:03
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto07:10
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.> has joined #yocto07:26
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:36
*** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto07:37
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto07:42
*** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-klczutozytbzuauq> has joined #yocto07:43
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has joined #yocto07:46
ThomasD13I've created a linux-raspberrypi-rt_%.bbappend file, to add a configuration fragment and a patch to the kernel sources: https://pastebin.com/HKpy2VbU07:49
*** Saur <Saur!pkj@nat/axis/x-qewlovcmryuamlgx> has quit IRC07:49
*** jklare <jklare!~jklare@> has quit IRC07:50
ThomasD13When I build a image with yocto, the patch and configuration fragment got applied to the kernel. However, when I build the eSDK, and build a image with that eSDK, the patch and fragment got NOT applied to the kernel source.07:50
*** Saur <Saur!pkj@nat/axis/x-ttvqjligxffmcicx> has joined #yocto07:51
ThomasD13Have I done something wrong with that bbappend-file?07:51
*** jklare <jklare!~jklare@> has joined #yocto07:52
*** mckoan|away is now known as mckoan07:53
yoctiNew news from stackoverflow: bitbake fails at the simplest recipe <https://stackoverflow.com/questions/50015145/bitbake-fails-at-the-simplest-recipe>07:58
wertigonHmm, thud doesn't seem to have CLANGSDK, but it does have NATIVESDKCLANG08:08
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto08:12
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto08:19
wertigonLooks like thud is SOL, our only option for now is to build the SDK with layers disabled, but at least I know it will be fixed in the future.08:23
*** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-nfrqepxxbhoouxkr> has joined #yocto08:27
ThomasD13I think that cause the missing patching of kernel sources in eSDK: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/scripts/lib/devtool/standard.py?id=7a6a5dcf9c5cefaccd2e4b0741bfba88eb8125d108:37
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC08:38
ThomasD13Can someone explain me, why this has been changed again? Since it was explicit added (http://lists.openembedded.org/pipermail/openembedded-core/2015-November/112242.html)08:38
*** rburton <rburton!~rburton@> has joined #yocto08:52
*** lfa <lfa!~lfa@> has joined #yocto09:03
Ad0I see that most yocto build guides put IMAGE_INSTALL_append in local.conf. but in a custom distro layer, where should this reside?09:08
LetoThe2ndAd0: no09:09
LetoThe2ndthey should reside in an image recipe09:09
LetoThe2ndAd0: https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj - video #209:09
Ad0does he do it "the right way" :=09:10
LetoThe2ndAd0: he does.09:10
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:11
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-ygdifdfwnqedrywn> has joined #yocto09:15
*** goliath <goliath!~goliath@nat001-WLTU1.uibk.ac.at> has joined #yocto09:15
LetoThe2ndAd0: to go totally nitpicking, in that case i would rather have used IMAGE_INSTALL_append instead of CORE_IMAGE_EXTRA_INSTALL. but both should work fine in that context.09:16
Ad0"There's many ways to skin a cat09:17
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:18
qschulzAd0: you're asking LetoThe2nd if what LetoThe2nd said in that video is "the right way" :D09:19
Ad0hahaha :) I had no idea. very cool LetoThe2nd , I will watch them in full09:19
LetoThe2ndqschulz: now you owe me a beer for giving the joke away! :P09:20
qschulzLetoThe2nd: damn it.09:29
wertigonrburton: Your CLANGSDK="" fix works for zeus but unfortunately not thud, but it's ok, I'll just disable the relevant layers for now when building the SDK, and then use your fix once ti upgrades to Zeus :)09:33
wertigonThank you for all help provided yesterday, it managed to solve my issues!09:34
LetoThe2ndbut acutally a good reminder, have to announce the next session09:36
*** iokill <iokill!~dave@static.> has quit IRC09:41
*** iokill <iokill!~dave@static.> has joined #yocto09:43
wertigonOk, one tiny problem left; we need arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/8.2.0/as.exe for our mingw package09:44
wertigonI assume I can just add it as a package somewhere, just wondering which package?09:44
LetoThe2ndwertigon: to me it rather sounds like a packaging problem. shouldn't as be part of the gcc packge?09:50
wertigonLetoThe2nd: That's what I figured as well. I'll rebuild the entire SDK using populate_sdk (used meta-toolchain earlier) and mingw, then we shall see if there are more bugs... :)09:53
rburtonwertigon: probably trivial to backport the fix from meta-clang's zeus branch09:54
*** yann <yann!~yann@> has joined #yocto09:57
wertigonrburton: Probably, I'll do a quick look at the git log if it's in a single or a couple of commits there09:57
wertigonrburton: Though thud is already slowly being phased out in most projects, that's the price you pay being on the bleeding edge and at the same time working with realtime environments :D09:58
*** JaMa <JaMa!~martin@> has joined #yocto10:01
wertigonrburton: Yes, ccfdb47cc4991a seems to be the ticket10:01
Ad0I have an XPS 15 with 4 cores. I have to get a different computer for this10:03
LetoThe2ndAd0: depends.10:03
Ad0why does bitbake add layers with a full home path as default instead of a relative path to a root variable?10:05
Ad0or it seems like it in the videos10:05
LetoThe2ndAd0: the bblayers entries are usually absolute, yes.10:06
wertigonTried cherrypicking SDK now; hopefully it will work, and that makes my life much easier10:09
wertigonrburton: Cherry pick didn't work :(10:09
wertigonrburton: Trying again with CLANGSDK in local.conf (had it in my image conf first)10:11
rburtonyeah its not a image variable10:11
rburtonshould be, but isn't10:11
wertigonOk, it works in my local.conf10:12
LetoThe2ndwertigon: remember, remember: whenever you want to affect something that is *not* in the vey file you are looking at, then it hast to go in a .conf, not a .bb10:12
LetoThe2ndnow aloud, everybody together: "conf data is global, recipe data is local"!10:13
wertigonOr rather, I get past one error but not another one;10:13
wertigon * Solver encountered 1 problem(s): * Problem 1/1: *   - nothing provides clang-cross-canadian-arm needed by packagegroup-cross-canadian-sitara-1.0-r0.x86_64-nativesdk-mingw32 *  * Solution 1: *   - do not ask to install a package providing packagegroup-cross-canadian-sitara10:13
wertigonOh, so it should be able to go into a layer.conf then?10:14
LetoThe2ndit should be. i totally despise hiding stuff in a layer.conf, but there are fringe cases where it can be helpfuil. just make very, very clear in your layer documentation that you stuck something in there.10:16
wertigonYeah, I understand... The way we have things setup here, we have our own custom layer that pulls in everything else10:16
wertigonSo I say it's pretty o.k. to let our custom layer do config shenanigans like that :)10:17
LetoThe2ndwertigon: just think of your coworker or future self who has to debug and understand it in 2 or 3 years time.10:18
*** goliath <goliath!~goliath@nat001-WLTU1.uibk.ac.at> has quit IRC10:18
wertigonI'll let the zeus backporting be for now; seems to be a rabbit hole that goes deeper than I had hoped10:19
LetoThe2ndand *nobody* looks inside a layer.conf, unless being either totally crazy/confused/desperate, or being pointed there by the docs.10:19
wertigonLetoThe2nd: granted, maybe distro.conf then10:20
LetoThe2ndwertigon: yes, thats a WAY better place.10:20
wertigonOk, added it to the proper place now10:29
wertigonNow I just gotta run a populate_sdk, and then everything should work :D10:30
rburtonwertigon: this should be in your distro layer10:53
rburtonlayer.conf is only useful for setting defaults, ie meta-intel uses layer.conf to set preferred provider for zlib as it ships an alternative10:54
kanavin_RP: I reproduced the piglit issue, looking into it.11:09
kanavin_RP: piglit hardcodes a list of suitable python versions, we only need to update to latest revision to have python 3.8 included into the list11:13
kanavin_patch on the way11:13
RPkanavin_: ah, that explains it thanks!11:13
kanavin_RP: the host contamination thing might be tricker as I have not seen it locally, but I'll try11:14
RPkanavin_: I think rburton understands that one?11:14
kanavin_RP: I have not seen an indication from him that he does?11:14
RPkanavin_: I'm not sure which is why I'm asking him11:15
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC11:19
kanavin_RP: patch for piglit sent11:22
rburtonno i haven't seen the host contamination either11:26
kanavin_I am trying with x86 (32bit) MACHINE now, I was using x86-64 target before11:28
kanavin_(as that's the target where it produced the warning?)11:28
rburtonok going to throw my next at the ab again but without py38 to get that bundle into master at least11:28
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto11:38
*** berton <berton!~berton@> has joined #yocto11:42
*** berton <berton!~berton@> has quit IRC11:45
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto11:46
*** berton <berton!~berton@> has joined #yocto11:46
RPkanavin_, rburton: FWIW that contamination usually occurs when something creates a file outside psuedo context. I suspect some of the python pgo code is causing a file to be generated out of context when pseudo isn't active?11:47
rburtonnothing pgo touches should be installed.  *should*11:48
kanavin_RP: possibly, but I am still not seeing it :(11:48
RPrburton: gah, you beat me to starting a test build :)11:49
rburtonmine should be fairly rapid11:49
kanavin_ah!     if bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', True, False, d) and d.getVar('BUILD_REPRODUCIBLE_BINARIES') != '1':11:49
kanavin_        d.setVar('PACKAGECONFIG_PGO', 'pgo')11:49
rburtonhm thats an annoying thing about reproducible11:50
rburtonbecause pgo is good on py11:50
RPYes :(11:50
RPwe need a nearly reproducible option :/11:50
RPor pregenerated profiles I guess11:51
RPactually, there is a huge problem with the host compiler dependency and reproducibility when combined with hashequiv11:52
RPthis arm/x86 host thing I'm chasing also applies with two x86 hosts with different native compilers11:53
wertigonrburton: Yep, added it to distro/mydistro.conf in my distro layer ^^11:53
* RP 's head starts to hurt11:53
wertigonHmmm, question; right now we are basing our distro on Poky and pull in TI stuff from the side;11:54
wertigonhow hard would it be to remove poky from that equation?11:54
rburtonpoky is basically nothing11:55
RPwertigon: there isn't a lot in poky so it wouldn't be hard but probably wouldn't change much11:55
rburtonjust copy/paste the bits in poky.conf that you care for11:55
wertigonYeah, that's what I figured11:55
rburtoni endorse people making their own distro so they don't get a surprise when e.g. poky switches init system11:55
rburtonmake your own distro and you control those changes11:55
wertigonIt's pretty much poky.conf and build environment setup script right?11:55
rburtonthe setup script is oe-core's11:55
wertigonAh, right11:56
wertigonWe're coming up to a cleanup-period now11:56
rburtonhttps://github.com/rossburton/customdistro <-- might be useful11:56
wertigonOk :)11:56
wertigonYeah, that's not really a lot of code11:59
wertigonAnd broken my grammar module seems12:01
wertigonOk, but great - the less messy we can make this the better12:01
*** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC12:08
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:16
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC12:16
kanavin_rburton, RP with or without pgo, I am still not seeing the contamination warnings :-/12:22
yoctiNew news from stackoverflow: What is the difference between PREMIRRORS and SOURCE_MIRROR_URL <https://stackoverflow.com/questions/46449301/what-is-the-difference-between-premirrors-and-source-mirror-url>12:29
ThomasD13wertigon, you said that you switched away from arago. How hard is it, to pull the TI stuff in such a way, that everything works after?12:38
wertigonThomasD13: We switched from Arago in order to have more control over our distribution, though the merge is not fully done yet - first step was to switch to poky with arago as a middle layer12:39
ThomasD13Do you only need to add the specific TI layers? Or is more effort required?12:39
wertigonFrom what we can see, it's not that much extra effort, arago is like poky, a reference distro12:39
wertigonSo you need to create your own distro layer pretty much, which is easier than it actually sounds like :)12:40
wertigonWhen done, we should only have the meta-processor-sdk and meta-ti layers left12:40
ThomasD13wertigon, cool! I thought about the same the last few weeks.12:42
LetoThe2ndwertigon: exactly what we keep preaching here. making an individual application and distro layer is no magic at all!12:42
ThomasD13How you do you handle the MACHINE definition for the TI recipes? Just defining in your own distro layer?12:42
wertigonWe simply copied the machine definitions to our distro layer12:43
wertigonAnd referred them from there instead12:43
ThomasD13okay, so you don't call bitbake with MACHINE=AM45xxx blabla12:43
rburtonreally the machine defintions should be in a separate layer, so you can use those without using their distro12:43
wertigonNo, we still do that ;)  but that's because we support multiple machines with this distro12:44
ThomasD13alright, really cool stuff. Thanks wertigon ;)12:44
wertigonrburton: agree with you there :)12:44
wertigonrburton: When we started this project I wasn't around and the guys that were charged in bravely and completely blind XD12:46
wertigonSo I'm starting to see how to straighten up the structure to make it more managable now :)12:47
rburton+1 :)12:47
wertigonLike with most software projects, if it works it isn't wrong per se, but at the same time it can be made so much better! :P12:49
wertigonSingle-distro-layer-for-everything approach does tend to smell after a while...12:50
LetoThe2nda "while"?12:51
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto12:51
LetoThe2ndyou mean like, 10 minutes, i presume?12:51
wertigonLetoThe2nd: Depends on how much you are trying to cram in there, how much you have been working on it, and how many other guys are involved :P12:52
wertigonBut after 6 months the stench does tend to reach epic proportions12:53
ThomasD13LetoThe2nd, did you record any videos that describe to setup/configure own distribution?12:53
LetoThe2ndThomasD13: not as a focus, but #2, #7 and #8 each contain bits and pieces of it. certainly enough to get started.12:57
wertigonThomasD13: rburton sent this skeleton distro: https://github.com/rossburton/customdistro12:58
wertigonDon't know if that helps any, but picking through the code opened my eyes to how small a distro can be. :)12:59
LetoThe2ndwertigon: you can totally even build without a distro....12:59
LetoThe2ndas i basically do in video #812:59
*** goliath <goliath!~goliath@> has joined #yocto13:02
ThomasD13thanks wertigon. I have to figure out what kind of stuff are normally specified in a "distribution". I think points like which kernel, which init system, etc...13:02
ThomasD13I'm just little bit confused about the border between "Image" and "Distribution"13:03
ThomasD13+ which bootloader13:03
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC13:05
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto13:10
qschulzLetoThe2nd: it's time for your analogy :) ^^^^13:18
qschulzThomasD13: bootloader and kernel selection is machine specific. Init system selection is distribution specific13:19
ThomasD13qschulz: okay, then I assume for example logging system is also distribution specific?13:20
Ad0LetoThe2nd, your videos are awesome because you actually run into errors and show how to solve it13:20
qschulzThomasD13: In my mind a good rule of thumb is, if anything requires recompiling 90% of your stuff and it changes "often", then it should be part of the distro. E.g. toolchain flags, toolchain, libc, init system, ... selection.13:24
qschulzIf it's "just" one package to install in one binary and not the other, usually in an image it's fine13:25
qschulzbut the line is still blurry between distros and images (we use poky so I didn't have much chance to get in-depth in that aspect)13:25
qschulzin my mind13:27
ThomasD13qschulz, I'm relieved that also experts use a "rule of thumb" ;) thanks for your thoughts13:27
qschulzThomasD13: not an expert, merely a contributor :) Grain of salt as always :)13:28
GeneralStupidHi, how do i put uboot into a SPI flash.13:38
GeneralStupidi tried with dd but its not booting.13:38
*** palate <palate!~palate@unaffiliated/palate> has joined #yocto13:39
qschulzGeneralStupid: if it's a NAND, flash_erase the partition before writing and then use nandwrite13:40
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto13:42
GeneralStupidqschulz: where do i find this tools?13:57
GeneralStupidare they part of uboot?13:58
qschulzno, those are Linux tools. mtd-utils I guess?14:05
qschulzin U-boot, nand erase or nand erase.part and nand write. Or can be sf command depending on the U-Boot version you're using and the SPI flash you have. I don't know much more, you can write to #u-boot14:07
qschulzah wait.. IIRC, you're using some imx6 chip. You might have to use imx-kobs or kobs-ng from Linux to flash the SPI otherwise you're missing the DBBT and other fun stuff like this14:09
qschulzRefer to the documentation or vedor for this14:09
GeneralStupidqschulz: imx6 is true14:09
GeneralStupidso mtd-utils should work because its using the linux kernel drivers ?14:10
qschulzmtd-utils is used to write to nand flash, that's all I can say. I don't think you can dd to it like that, I don't know the reason behind (OOB data, bad block management, etc.). There's Google or #mtd for that, but I really don't know what's happening under the hood14:12
qschulzone thing for sure is that you need to erase parts of your NAND before writing to it14:13
*** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has quit IRC14:14
*** wertigon <wertigon!8addfa13@> has quit IRC14:14
*** litb <litb!~jschaub@pd907fca9.dip0.t-ipconnect.de> has joined #yocto14:14
litbhello folks!14:14
litbhow can I mark a .bbappend file specific to a branch name?14:15
litbi.e i have a layer that's supposed to be compatible with warrior and zeus. and I have .bbappend files for versions that are not anymore available in zeus14:15
qschulzmake separate branches14:15
litbso I want to mark those .bbappend files branch-specific14:15
litbno other way around?14:15
qschulzdepend on what's done by the bbappend14:15
litbmaybe make a .bbappend for 'foo_%.bbappend' and within, include 'foo_${PV}.inc' ?14:16
litbah, that's a good idea, I think. but will it work?14:16
qschulzif that's applicable to every version in the same major number or for all versions to date, use %14:16
qschulze.g. foo_3.%.bbappend14:17
litbwill my include approach work aswell?14:17
*** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has joined #yocto14:17
*** wertigon <wertigon!8addfa13@> has joined #yocto14:17
litbqschulz, hmm, I guess that the branch approach is cleaner, after all.14:17
qschulzlitb: also, try to upstream it if you can and if it makes sense for the upstream project14:18
qschulzi.e. patch sent to foo maintainer or patch sent to YP if applicable to the recipe only14:19
*** mckoan is now known as mckoan|away14:20
GeneralStupidqschulz: i just dont get why uboot is not able to find my dtb ( which is present ) anymore :D i have to dig deeper into this stuff.14:33
*** xtron <xtron!~xtron@> has quit IRC14:35
*** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC14:37
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC14:38
qschulzGeneralStupid: where is your dtb present? what do you mean by u-boot is unable to find the dtb?14:40
wertigonRight, why does it say "error: CreateProcess: no such file or directory" when I try to compile hello world on windows cmd.exe?14:41
wertigonthat is, I run cmd.exe, go to my sdk folder, run the environment script and then type14:42
wertigon%CC% hello.c14:42
JPEWwertigon: What version (e.g. zeus, warrior, thud...)?14:43
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto14:47
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has quit IRC14:51
*** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has quit IRC14:52
*** OnkelUlla <OnkelUlla!~uol@ptx.hi.pengutronix.de> has joined #yocto14:53
wertigonI managed to get it to work with a native SDK on WSL, but I need to get it to work on Windows without WSL :P14:56
* wertigon mutters about stupid stubborn corporate policies14:56
JPEWwertigon: Hah, ya. It's designed to work w/o WSL :)14:56
wertigonJPEW: I mean, I managed to get an SDK built for Linux host to work on WSL14:57
wertigonNow I have built an SDK for Windows through mingw14:57
wertigonAnd... Error -_-14:58
JPEWwertigon: Right :)14:58
wertigonI need to open a NEW command prompt14:59
wertigonsince cmd.exe is shittyMcShits14:59
wertigonof command prompts14:59
JPEWwertigon: Indeed. Do you know the exact problem?15:00
wertigonset is not permanent :P15:00
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC15:01
RPJPEW: realised more problems in runqueue, testing a revised version15:01
JPEWRP: Ok, is that on master-next?15:02
RPJPEW: yes15:02
GeneralStupidqschulz: its on the SD card (mmcblk1p1)15:02
RPJPEW: basically I wasn't feeding the revised hash back to rehash based on it15:02
RPJPEW: I ended up shortcutting the whole thing to stop it flipping values back and forth15:03
*** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC15:03
JPEWRP: Ok. I still don't think you are reporting the correct thing to the hash server, I'm drafting a patch to fix it up.15:03
RPJPEW: I think my code may have a "bug" where it should look at all valid setscene tasks and not just covered ones though :/15:03
RPJPEW: entirely possible, I'm getting very confused with it not15:04
RPJPEW: the runqueue change is right but the hashserve side may not be15:04
wertigonHmmm, %CC% shows quite a few brokennesses15:04
JPEWRP: Ok, I'll push my fixup on top of master-next so you can easily squash it in15:04
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto15:04
JPEW(on a contrib branch)15:04
RPJPEW: thanks15:05
wertigonIt has a lot of references to non-existent directories like xxxxxxxxxx.../yyyyyyyy...15:05
JPEWwertigon: Not sure I follow, can you post more detail output?15:05
wertigonSure, hang on15:06
JPEWRP: I think I came up with better argument names: wanted_unihash and current_unihash15:06
RPJPEW: yes, I like that15:07
wertigonJPEW: pastebin.com/dAc8A3Fs15:08
JPEWwertigon: Hah, I thought xxxxx.../yyyy... was some attempt to hide paths, not that you were being literal ;)15:08
wertigonNo, quite literal in this case :P15:09
RPwertigon: I thought you were masking it too! Interesting. I wonder if gcc is doing that internally? :/15:09
wertigonI think it is something that bitbake / meta-mingw does, because I see similar things there15:10
JPEWI think it's trying to posion the paths so that you have to provide the valid ones on the command line15:11
JPEWThe ones provided at configure time can't be known, so they are set to be invalid15:11
wertigonAny way I can fix that?15:12
JPEWwertigon: I'm not sure thats the problem15:13
JPEWCan you try manually running the assembler command it's trying to invoke?15:14
JPEWDoes it work?15:15
wertigonThe system cannot execute the specified program15:16
JPEWOk, the assembler is broken then :)15:16
JPEWThat sounds familiar....15:16
*** ThomasD13 <ThomasD13!~ThomasD13@DSL01.> has quit IRC15:17
*** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has joined #yocto15:17
wertigonArgh... So close to get mingw to work, yet so far -_-15:18
JPEWwertigon: Ya, sorry. The newer releases work a lot better because we added automated AB testing15:18
JPEWYou might try backporting 7697cef ("mingw-w64-{headers,runtime,winpthreads}: Upgrade 5.0.3 -> 6.0.0") to thud15:19
wertigon... It has been blocked by Windows since the program is "downloaded"15:19
JPEWOh, wait15:19
wertigonIs what the error message seems to mean15:19
JPEWDo you have the latest thud?15:19
wertigonWFT :P15:19
wertigonYeah, pretty much15:20
JPEWIncluing the GCCPIE fix in meta-mingw?15:20
wertigonYeah, I seem to have that15:20
JPEWOK. Well, maybe some scanner is blocking it then15:21
wertigonLet's try scanning it for threats with my antivirus15:24
JPEWRP: Hmm, I notice that the new logic only updates the task taskhash if the unihash was reported as equivalent... is there a reason for that?15:24
JPEWwertigon: Do you have some directory that is blacklisted by your various scanners?15:25
JPEWWe have to have one and put our SDKs in it or things get broken15:25
*** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has joined #yocto15:26
wertigonJPEW: I think it's as you say15:27
wertigonIt's a rights permissions issue15:27
wertigongreat :)15:27
wertigonOk, so basically I'm trying to run a program that is not trusted15:28
wertigonWoohoo yay go Windows! :D15:29
wertigonWill need to double check this tomorrow, have a nice evening! :)15:29
roussinmI'm going to resstart a topic from yesterday, why IMAGE_NAME is an hard assignment? Same for IMAGE_LINK_NAME, the only way we found to override is to patch poky on our side or to addtask to our recipe and modify it for each of our images.15:33
*** goliath <goliath!~goliath@> has quit IRC15:41
kergothroussinm: hard assignment where? if it's set in image.bbclass, just define it *after* the inherit line in the recipe, not before15:47
kergothinherits occur *exactly there*. order matters.15:47
kergothalso, even if that didn't work, you could use an override15:47
*** thierryE <thierryE!sid286446@gateway/web/irccloud.com/x-qvnjfbfdtmzbmewz> has joined #yocto15:49
roussinmkergoth: The hard assignment is in bitbake.conf15:50
kergoththen any recipe can override it, as it can any configuration variable. if you want to override it in a distro or osmething, use overrides15:51
roussinmkergoth: So I could do this in theory : IMAGE_NAME_mymachine = "MY_IMAGE_name"15:52
roussinmWe don't want it at the recipe level, but at distro level. So it would be inside our distro configuration file.15:53
RPJPEW: if it couldn't report it I'm not sure what should happen :/15:55
sjolley_YPTM: Monthly Project Meeting Tuesday Dec. 3rd at 8am PDT (https://zoom.us/j/990892712)15:55
sjolley_YPTM: Stephen joined15:55
litbhmm, in zeus there appears to be no recipes-depends.dot file generated by "bitbake -g"15:56
JPEWYPTM: Joshua Watt here15:56
litbhow can I generate that file which is needed by the oe-depends-dot tool?15:57
litbI wanna look why some recipe is being built15:57
kergothroussinm: yes, or _yourdistro, since it's in your distro. of course, globally overriding an image name across all images is asking for pain unless you include the image basename15:57
kergothlitb: bitbake -g yourtarget15:57
litbkergoth, i did that. i did  bitbake -g and specified some "-native" recipe15:57
litbbut there is no recipes-depends.dot created15:57
kergothuse task-depends.dot15:58
kergothrecipe-depends.dot is no longer generated15:58
litbah thanks. we tried that I think with oe-depends-dot. was that tool updated?15:58
kergothyou'll have to specify e.g. yourrecipe.do_populate_sysroot or yourrecipe.do_build or whatever instead of  yourrecipe15:58
kergoththe tool doesn't need to change15:58
kergothit works fine with either .dot file15:58
litbah thanks!15:58
kergothbut the content includes the task names15:58
kergothit's a bit of a pain to use at this point, actually. do_build tends to get sucked in only by the image or whatever due to recrdeptask, which isn't super useful, and it doesn't fully recurse when using the other tasks,15:59
kergothe.g. specifying yourrecipe.do_compile will just say yourrecipe.do_install brought it in, but won't continue past that15:59
* kergoth was messing with it a couple days ago15:59
kergothstill a lot better than nothing, but you'll have to fiddle with it16:00
RPYPTM: Richard has joined16:00
smurrayYPTM: Scott Murray has joined16:00
qschulzGeneralStupid: what are the commands you're running and what exactly is the error? You might need to select your card first if you have multiple mmc devices on your device (use mmc command)16:01
*** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC16:02
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC16:03
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto16:04
vmesonYPTM: Randy MacLeod has joined.16:05
moto-timoYPTM: moto-timo has joined16:07
roussinmkergoth: Thank you! We don't have to patch poky anymore!16:08
tlwoernerYPTM: tlwoerner in on16:10
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:16
*** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC16:16
litbkergoth, hm, i see16:28
litbkergoth, i used do_populate_sysroot, which works because DEPENDS establishes that requirement16:28
vmesonFYI: mark's email (which I haven't read yet. ;-) ) http://lists.openembedded.org/pipermail/openembedded-architecture/2019-December/001709.html16:29
litbah i see, you noted that aswell16:29
*** leon-anavi <leon-anavi!~Leon@> has quit IRC16:31
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC16:35
vmesonpaulbarker: patchtest reviewer/owner: Li, Changqing <changqing.li@windriver.com>16:40
vmesons/owner/maintainer/ I suppose.16:41
paulbarkervmeson: Thanks, I'll send an email today or tomorrow morning16:45
vmesonpaulbarker: super. I look forward to eventually be able to locally check patches!16:46
paulbarkervmeson: That's exactly what I want. I got a weird email from patchtest and couldn't reproduce the issue locally without first fixing patchtest16:47
*** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto16:48
* moto-timo very interested in seeing this work :)16:48
dreynaYP tech meeting minutes here: https://docs.google.com/document/d/1Y5IIuE-z0Ykdl-DwuzUJh52flOZuhN_TSAfw2tdU9pg16:48
*** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has quit IRC16:49
JPEWRP: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/hash-equiv-fixup&id=c4aa1ff11035b67d18fdbcbdf8dc691a96fb3d7e16:50
JPEWkergoth: I've release a beta build for Pyrex: https://github.com/garmin/pyrex/releases/tag/v1.0.0-beta1 . Any feedback you have would be appreciated16:54
*** yann <yann!~yann@> has quit IRC16:56
RPJPEW: hmm, yes. So I'm not reporting enough data16:56
RPJPEW: not quite sure your runququeue change if logic is quite correct but I can see the hashserve piece16:56
JPEWRP: Ya maybe not16:57
RP(newuni == origuni) needs to set remapped = True effectively16:57
JPEWOh, ya, that would make more sense16:58
RPand I think we can actually drop that second if eventually and the rehashes var but one step at a time16:58
kergothJPEW: sure, i'll play with it16:58
*** sjolley_ <sjolley_!~sjolley_@c-71-59-136-149.hsd1.or.comcast.net> has quit IRC16:58
JPEWRP: I was more interested in not reporting the hash to the server if it didn't change :)16:58
paulbarkermoto-timo: Did you say you have GitLab CI set up for meta-python2? Is that on a public repo?16:59
JPEWRP: Drop the "if not remapped" ?16:59
RPJPEW: right, that makes sense, its just the effect on the rest of the code16:59
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto16:59
*** jklare <jklare!~jklare@> has quit IRC16:59
RPJPEW: no, we need that, we just need to tweak the newuni == origuni case17:00
yoctiNew news from stackoverflow: Edit which file /etc/resolv.conf is linked to at boot time <https://stackoverflow.com/questions/59161823/edit-which-file-etc-resolv-conf-is-linked-to-at-boot-time>17:00
*** jklare <jklare!~jklare@> has joined #yocto17:04
*** vineela <vineela!~vtummala@> has joined #yocto17:07
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:24
*** zwelch <zwelch!~zwelch@fluffy.superlucidity.net> has quit IRC17:27
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto17:30
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC17:38
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto17:40
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto17:43
roussinmkergoth: When using overrides, it is possible to use excludes? i.e IMAGE_NAME_mydistro[vardepsexclude] += "DATETIME"17:43
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:49
*** guerinoni <guerinoni!~guerinoni@> has joined #yocto17:50
RPJPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/544 is one of the better runs we've ever had with hash equiv - only one mystery selftest failure so far that looks hash equiv related18:05
RPJPEW: I think I should try your patch :)18:05
JPEWRP: Ya, that's really good.18:06
*** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto18:11
*** litb <litb!~jschaub@pd907fca9.dip0.t-ipconnect.de> has quit IRC18:13
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto18:17
*** nemgti-og <nemgti-og!nemgti-og@gateway/vpn/protonvpn/nemgti-og> has joined #yocto18:18
*** armpit <armpit!~armpit@2601:202:4180:a5c0:51a5:502e:8fc:9836> has quit IRC18:31
RPJPEW: stacked another patch of mine on top of yours in -next :)18:38
RPJPEW: torn between stopping the current build (to restart the hashserv) and letting it finish18:38
RPguess I'll stop it and move on18:39
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto18:48
*** guerinoni <guerinoni!~guerinoni@> has quit IRC18:57
*** rcw <rcw!~rcw@> has joined #yocto19:02
fullstopI'm coming from a buildroot background and I initially found yocto/bitbake to be very cumbersome and painful.  After using it for a bit, I've come to appreciate what it does and how it can be leveraged to my advantage.. so I wanted to send my thanks to everyone who has worked on it.19:04
fullstopbuildroot gets things done quickly and it's easy to work with.. but yocto does it "right" and slaps my hand when I fall out of line.19:05
*** denix <denix!~denix@pool-100-15-86-127.washdc.fios.verizon.net> has quit IRC19:16
RPfullstop: thanks. Out of interest is there anything you think we could/should improve? You've a useful experience of both systems there! :)19:27
tgamblinThere was someone asking for a menuconfig-like interface for the tools, on one of LetoThe2nd's Twitch streams... seems like a fun project, but probably not a priority19:31
RPtgamblin: a lot of our config doesn't lend itself to menus either19:31
fullstopRP: My ultimate goal is a build system which can faithfully recreate a filesystem image, but most of my time has been spent writing recipes.  Understanding the magic there was more difficult than the buildroot syntax.19:32
fullstopFinding that everything builds in tmp was unexpected.19:32
moto-timopaulbarker: I was waiting for git.oe.org to be up, but now my gitlab is public: https://gitlab.com/moto-timo/meta-python219:33
moto-timopaulbarker: it is running on a docker gitlab-runner on a machine at my house19:33
RPfullstop: that naming is bad and would probably be good to change but invasive on the docs :/19:34
moto-timopaulbarker: we can also set it up on gitlab.com/openembedded... I was going to ask once it was public19:34
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto19:34
fullstopSpeaking of docs..19:34
fullstopgoogle LOVES to drop you in in 1.819:34
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-ygdifdfwnqedrywn> has quit IRC19:34
RPfullstop: the recipe syntax sounds like a problem, anything specific or just in general?19:34
moto-timogoogle is getting somewhat better at picking latest, but yes 1.8 seems to be its favorite19:35
RPI wonder why google does that, I've noticed it too :/19:35
RPperhaps time for more invasive redirects...19:35
fullstopHaving a large banner at the top of 1.8 with a link to the latest might be helpful.19:35
moto-timomake scott can embedd google ads in the docs (someone kick me)19:35
fullstopPython does something where you can select the release at the top.19:36
moto-timopython builds with sphinx, we use docbook19:36
RPfullstop: it does have a link, https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html - its just broken :/19:37
RPhalstead: any thoughts on any of this?19:37
fullstopFinding stuff like pkg_postinst_ontarget_${PN} took some time.  I knew what I wanted to do but had to track down the exact name of the target.19:37
RPfullstop: yes, a release selector would be ideal now you mention it19:37
halsteadRP, We've tried some tricks to make Google put the newest docs at the top. They were mildly effective.19:38
RPhalstead: the links to latest doc seem broken, not sure where we need to fix that?19:38
halsteadmoto-timo, Was git.oe.org down for you?19:39
kergothroussinm: vardepsexclude applies to a variable, they won't move from the override version of the variable to the main one. so no. if you need to exclude it conditionally, you'd need to use inline python. in this case you can likely just apply it unconditionally, though.19:39
moto-timohalstead: no. I just meant I was waiting for it to be public and live19:39
moto-timohalstead: zero issues with git.oe.org so far :)19:39
halsteadmoto-timo, It up and live the way you want now correct?19:40
moto-timohalstead: it is working FANTASTIC19:40
* moto-timo owes halstead a beverage19:40
moto-timoarmpit: check out the logo on https://gitlab.com/moto-timo/meta-python2 in your honor19:41
halsteadRP, Latest and current URLs work. Trying to see why they aren't listed on the website.19:41
RPhalstead: look at the link at the top of the 1.8 doc I linked to though19:41
RPhalstead: sorry, I think I misread that19:42
RPfullstop: thanks, we do appreciate the feedback. It does help influence future development19:43
moto-timofullstop: I also started with buildroot, but I had 5 products already in my queue and 10 on the horizon and knew it wouldn't scale (and drive me crazy)19:43
halsteadRP, I see it linking back to the 1.8 manual. I can change that in the static files.19:44
bluelightningmoto-timo: should I add meta-python2 to the layer index now?19:44
moto-timome notices the absense of armpit19:44
RPhalstead: right, pointing at current or latest would be much better19:44
moto-timobluelightning: yes, an email was on my todo list :)19:44
RPhalstead: we could change that in the docs themselves too, I'm not sure where its coming from as I've not looked19:44
moto-timobluelightning: or I can test my login and see if I can add it?19:45
bluelightningmoto-timo: sure, give it a try19:45
fullstopmoto-timo: I dealt with one platform which has been living for about a decade.  I have found the need to share recipes / layers across three platforms now, which is where yocto shines.19:46
fullstopRP: thanks!19:47
kergothfullstop: we'd definitely appreciate any input on the issues. the project has its usability issues, it'd difficult to address many of them without sacrificing the flexibility that's core to the project, though19:47
* kergoth ponders19:47
fullstopOh, one other thing that bugs me but will never be changed... ${sbindir} vs ${WORKDIR}.  The casing.19:48
nemgti-ogHey there. I am new to Yocto and have two questions: 1. /leave19:49
nemgti-ogSorry for that last message :D19:50
kergothah, yes, that's inconsistent. the lowercase target path vars align with autoconf configure arguments, which is probably why it's that way..19:51
kergoththere's a lot of history dragging along.. :)19:51
tgamblinRP: sent the patch for the oeqa skip tests issue, but forgot to put the bug link in the commit message. Let me know if you need a v219:52
fullstopI'm sure.  :-)19:56
RPtgamblin: hmm, you're fixing it in the particular test rather than something more generic :/19:59
RPtgamblin: what happens if some other bit of classSetup fails?19:59
fullstopI see that the link at the top of documentation now points to latest instead of 1.8.  \o/20:00
RPfullstop: we have halstead to thank for that I suspect :)20:00
fullstopthanks, halstead!20:00
*** rcw <rcw!~rcw@> has quit IRC20:01
halstead:) I've edited it in place since old docs don't get rebuilt.20:01
*** rcw <rcw!~rcw@> has joined #yocto20:02
halsteadStill lots of spots to track down. And I think the wording is off now. Since the link is to the latest overall not the latest for that release.20:02
*** pohly <pohly!~pohly@p54BD5B80.dip0.t-ipconnect.de> has quit IRC20:04
tgamblinRP: That should be the only case, no? There are only two classes that I see that inherit that particular version of setUpClass from OEScriptTests, and the second (OEListPackageconfigTests) doesn't seem affected. Unless I am misunderstanding all of the inheritance going on...20:06
*** hpsy <hpsy!~hpsy@> has quit IRC20:06
moto-timobluelightning: layer submitted... it autofilled the cgit info, so I hope that was correct?20:14
frayI publiushed it20:14
bluelightningah that's why I can't see it :D20:15
bluelightninggood job people :)20:15
moto-timothank you fray and bluelightning :)20:15
frayI happened to have been logged into the layerindex when the email showed up.. :)20:15
tgamblinRP: I'll just poke around a bit more and see if I can get more generic with the fix20:16
fraybluelightning / rburton I found out there were a bunch of CVEs we missed in the triage.. they somehow got flagged as 'New-Reserved'.. so I'm moving them to New so we can triage them.. :(20:16
bluelightningfray: ok, how many?20:17
fraynot sure.. guessing a few hundred.. :(20:17
frayI'm having to find and move them by hand.. started searching almost 21k new-reerved..20:17
frayI'm down to "page 622 of 25 per page"20:18
kergothJPEW: having issues passing args to pyrex-init-build-env, they seem to be passed to pyrex.py rather than the PYREX_OEINIT script, at least that's the error i'm getting.20:18
bluelightningfray: it says 406 now I load it20:18
frayI've not yet done the match to see how many pages..20:18
fraywow.. that is more then I expected20:18
kergothJPEW: seeing a pyrex.py usage error about the bitbake path being paseed to oe-init-build-env20:18
bluelightningfray: oh well, we'll get there20:18
fraynumerically I'm up to CVE-2019-12521 ...20:18
fray(dreyna is going to get a 'negative' search implemented in the future so we can do something like "-RESERVED" and select everything WITHOUT reserved in the name)20:19
bluelightningthat would be useful20:20
*** hpsy <hpsy!~hpsy@> has joined #yocto20:20
bluelightningthough I didn't come across too many of those in the triage I did, maybe most of them were already gone20:20
fraytheoretically alof the 'New-Reserved' should start with "** RESERVED ** This candidate has been ...."20:20
bluelightninghmm actually the number is 44420:22
frayI'm still adding ones.. :P20:22
bluelightningah, I see20:22
frayup to CVE-2019-13641 now20:22
frayup to CVE-2019-1510320:28
yoctiNew news from stackoverflow: How to install scipy on yocto warrior <https://stackoverflow.com/questions/59164784/how-to-install-scipy-on-yocto-warrior>20:31
*** armpit <armpit!~armpit@> has joined #yocto20:33
frayup to CVE-2019-16157  ugh20:36
Ad0I guess 4096 MB RAM isn't enough :P20:42
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC20:42
RPtgamblin: https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/524/steps/8/logs/step2d shows there is another class with the same issue. My concern is there are other setUpClass methods so what if those fail? If these really are so problematic and can't be fixed, should we remove them entirely?20:46
fray...and done.. yikes.. I moved 867 items that had gotten hidden.. :(20:48
Ad0is there a way to clean the code for one specific package?20:53
fraybitbake -c clean .. cleansstate .. cleanall recipe20:54
fraychoose one of the three cleans.. documented in the YP manual..20:54
Ad0I guess I have to find the recipe20:54
nemgti-ogHello. I am trying to build a layer from genivi (i.e. meta-ivi). It compains that it cannot find java on some directory under my build directory. Am I correct in my assumption, that I have to get a meta-java layer and simple added by means of the bitbake add-layer command? And does the order in which such layer are added matter? I mean, is it important to add them in a specific order?20:55
tgamblinRP: Right. Will do a little more digging20:55
frayit will be looking for the layers through dependencies (most likely)20:57
frayyou need to make sure conf/bblayers.conf has all ofthe dependencies in it20:57
Ad0fray, thanks! that did the job with bitbake-layers show-recipes .. bitbake -c clean ...20:58
nemgti-oghey fray thanks. Right, but the order in which those dependencies are listed in conf/bblayers.conf is irrelevant?20:58
RPbug 13667 could be 'fun'20:59
yoctiBug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13667 normal, Undecided, ---, richard.purdie, NEW , pid recycling problems in bitbake?20:59
frayorder only matters when there is a conflict (two recipes providing the same thing)20:59
fraywhat is wrong w/ pid recycling?21:00
RPfray: I think its happening faster than the UI code can respond to events21:00
frayohh old pids get stored in the task list?21:00
RPfray: its using pids to id tasks21:00
RPfray: we're cycling back to the same pids in around 5s21:01
RPwell, myabe 22s21:01
fraywhich host system type?21:01
fray(and how many cores)21:01
RPfray: centos721:01
nemgti-ogThank you fray!21:01
RP48 core21:02
frayHmm.. similar (or smaller) to the systems I've been using and I've not seen that... wonder why it's repeating so quickly21:02
kergothdo we need to assign per-task uuids and use them in the events or something?21:02
*** berton <berton!~berton@> has quit IRC21:03
RPheh, thought that bug would be impossible but with that log info, it makes sense and we could plan a fix21:04
*** Azoff <Azoff!foobar@unaffiliated/azoff> has quit IRC21:04
RPSure we've seen it before but never understood why21:05
frayya...  per-task uuids is likely the only answer..  (not necessarily a 'full uuid, could just be a 64-bit number assigned by bitbake itself)21:05
khemsome more unihash stuff21:07
RPkhem: that one has been fixed21:07
khemok cool.21:08
khemlets see21:08
*** tgamblin <tgamblin!~tgamblin@> has quit IRC21:08
*** jhar <jhar!~har@c-75-70-112-20.hsd1.co.comcast.net> has joined #yocto21:09
moto-timoarmpit: check out the logo on https://gitlab.com/moto-timo/meta-python2 in your honor21:14
armpitmoto-timo, very nice21:15
RPkhem: we've had a few iterations since then, its actually coming together a bit now21:24
RPfray: the reasons for using pids made sense at the time ;-)21:25
RPfray: that was a decade ago21:25
frayya, pids are easy and you don't have to transmit them to both sides, since they already know them21:25
RPfray: well, we didn't have task ids back then, everything in runqueue was an index21:26
fraymakes sense21:26
RPwe've subsequently learnt that was stupid21:26
RPfray: now I know what python does behind the scenes, we work with it differently21:27
*** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC21:31
*** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-klczutozytbzuauq> has quit IRC21:35
*** armpit <armpit!~armpit@> has quit IRC21:35
*** JaMa <JaMa!~martin@> has quit IRC21:46
JPEWkergoth: Hmm, OK21:48
__angelohi, building a bsp just pulled,   my_package requires libjpeg.so.62, but no providers found in RDEPENDS_my_package21:50
*** rcw <rcw!~rcw@> has quit IRC21:51
JPEWkergoth: What sort of arguments are you passing? I tried '. pyrex-init-build-env foo' and it seemed to drop me in the correct build directory21:56
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto21:57
kergothJPEW: the first argument is fine22:03
kergoth. pyrex-init-build-env build.foo /path/to/bitbake -> /path/to/bitbake invalid argument22:03
kergothoe-init-build-env accepts two args, and other inits might behave differently, it'd be ideal to pass it through as is22:04
JPEWkergoth: ah! ok22:04
rburtonRP: hm i think my selftest hung.22:04
rburtonor its actually taking 10+ hours22:04
RPrburton: it will be taking 10 hours22:05
RPrburton: wish I knew. Probably involves the NAS22:05
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC22:07
RPrburton: FWIW that worker is very laggy. Its the one we saw the pid roll on22:10
*** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto22:10
RPrburton: there is an ltp build running there the controller doesn't know about22:11
RPrburton: I'll kill the bits I can tell shouldn't be there22:14
RPrburton: its runqemus that get left behind, something wrong with the cleanup22:15
*** sven^ <sven^!~quassel@unaffiliated/sven/x-8293843> has quit IRC22:15
RPrburton: I think its so lagged as its got a lot of file deletion going on in the background22:17
JPEWkergoth: Fixed22:20
kergothJPEW: thanks, i'll give it another go22:20
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto22:22
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC22:26
RPrburton: the worker is lagged on deletion btw. Yes I know about rm_work22:42
RPrburton: specifically deletion of the parallel build dirs in selftest whilst running a build and having background deletion to do as well22:42
RPrburton: oe-selftest has actually finished but its not flushed its console22:43
frayok.. starting to get it22:56
RPfray: starting to get yocto? :)23:18
frayna.. baremetal configurations using YP builder23:18
RPits more fun to speculate ;-)23:19
RPJPEW: some failures in the current -next build with all our changes but not from hashequiv as yet23:20
*** nemgti-og <nemgti-og!nemgti-og@gateway/vpn/protonvpn/nemgti-og> has quit IRC23:33
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC23:39
*** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC23:55
*** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC23:58

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!