Monday, 2019-12-09

*** nrossi <nrossi!nrossimatr@gateway/shell/> has joined #yocto02:38
*** Bunio_FH <Bunio_FH!> has quit IRC02:49
* armpit arrrg... zeddii forgot to update kernel-cache version for 4.14.. should be .154 now02:52
*** bcran <bcran!> has joined #yocto02:57
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto03:36
*** nslu2-log <nslu2-log!> has joined #yocto04:43
*** armpit <armpit!~armpit@2601:202:4180:a5c0:49d0:4aef:f5f:565e> has quit IRC05:40
*** armpit <armpit!~armpit@2601:202:4180:a5c0:1527:dedf:f05:266c> has joined #yocto05:53
*** pohly <pohly!> has joined #yocto06:19
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has quit IRC06:22
*** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has joined #yocto06:33
*** AndersD <AndersD!> has joined #yocto06:44
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:01
*** goliath <goliath!> has joined #yocto07:03
*** guerinoni <guerinoni!> has joined #yocto07:05
*** rburton <rburton!> has joined #yocto07:06
*** ThomasD13 <ThomasD13!> has joined #yocto07:07
*** agust <agust!> has joined #yocto07:28
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC07:33
*** alessioigor <alessioigor!> has joined #yocto07:35
*** yann|work <yann|work!> has quit IRC07:55
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:57
*** lfa <lfa!~lfa@> has joined #yocto08:02
*** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto08:05
*** goliath <goliath!> has quit IRC08:07
*** lucaceresoli <lucaceresoli!> has joined #yocto08:10
*** diego_r <diego_r!> has joined #yocto08:22
*** hpsy <hpsy!~hpsy@> has joined #yocto08:36
*** TobSnyder <TobSnyder!> has joined #yocto08:43
*** yann|work <yann|work!~yann@> has joined #yocto08:58
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:05
*** goliath <goliath!~goliath@> has joined #yocto09:12
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:13
*** Bunio_FH <Bunio_FH!> has joined #yocto09:17
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:31
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:35
*** florian_kc is now known as florian09:41
RPkhem: FWIW the binutils upgrade looks fine on the AB09:48
*** sashko <sashko!~sashko@> has joined #yocto09:51
sashkohi! is there a way to remove inherit from a recipe with bbappend?09:51
yoctiNew news from stackoverflow: How to exclude opencv compilation from Yocto image? <>09:51
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:52
LetoThe2ndsashko: no, i dont' think so.09:54
RPsashko: not really, no10:01
RPkhem: binutils looks fine10:10
*** hpsy <hpsy!~hpsy@> has quit IRC10:14
*** hpsy <hpsy!~hpsy@> has joined #yocto10:14
*** silviof <silviof!silv-iomat@gateway/shell/> has quit IRC10:16
*** nrossi <nrossi!nrossimatr@gateway/shell/> has quit IRC10:16
*** bachp <bachp!bachpmatri@gateway/shell/> has quit IRC10:16
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC10:19
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto10:24
rburtonif it wasnt 10am i'd crack open a gin to celebrate10:31
LetoThe2ndrburton: so, why not?10:32
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:32
RPrburton: haha :)10:36
RPIts nice to reach this point10:36
LetoThe2nddrinking at 10am?10:39
LetoThe2ndhell yeah!10:39
*** JaMa <JaMa!~martin@> has joined #yocto10:55
LetoThe2ndis there some variable that is unique to a bitbake run?10:59
RPLetoThe2nd: DATETIME ?10:59
LetoThe2ndRP: will cause headaches probably, as it triggers the non-deterministic warnings11:00
RPLetoThe2nd: so you just vardeps exclude it?11:00
LetoThe2ndbut then it will lift the recipe out of being run i  only DATETIME has changed, right?11:02
rburtonLetoThe2nd: what do you want to do with this unique variable11:08
LetoThe2ndrburton: we're still trying to tackle a problem with inter-multiconfig dependencies that are caused by specific image types.11:09
LetoThe2ndbut we're really, really close to just stick in a nostamp on the fetching task in the depending multiconfig recipe by now, so much human time has already been burnt that the additional cycles start to appear cheaper.11:11
*** nrossi <nrossi!nrossimatr@gateway/shell/> has joined #yocto11:14
*** silviof <silviof!silv-iomat@gateway/shell/> has joined #yocto11:14
*** bachp <bachp!bachpmatri@gateway/shell/> has joined #yocto11:14
rburtonRP: doing a build spin of next here before giving it my +1 :)11:17
RPrburton: fair enough11:20
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC11:20
yoctiNew news from stackoverflow: How to get the ARM tool chain with poky? <> || Having Angstrom build and Poky build in one repository <>11:22
kanavin__RP: thanks, I probably was far too optimistic about the big upgrade patchset. Certainly should be approached piece by piece.11:32
RPkanavin__: I'd pushed out all the problem pieces I could spot and -next is now building ok. I'll probably take -next as it stands and build M1 with that, then we can work through the problematic pieces in M211:33
*** berton <berton!~berton@> has joined #yocto11:42
*** berton <berton!~berton@> has quit IRC11:47
*** berton <berton!~berton@> has joined #yocto11:50
rburtonRP: next looks good11:54
RPrburton: cool. I shall merge. Does this mean we're ready for M1?11:55
RPrburton: there are other patches around but I think we draw the line here?11:55
rburtonjust rebasing mut to see what else i had hanging around11:56
rburtonoh theres a cve fix which might be super useful11:56
RPrburton: which one?11:56
rburtonthe cve-check one11:56
RPrburton: master updated fwiw11:57
RPrburton: ah, the version one11:57
rburtonjust testing now11:57
RPrburton: ok, let me know. Tempted to then roll M111:57
rburtonupstream-status fix on the list ;)11:59
RPrburton: ah, will merge12:00
rburtoncve check fix appears to be fine12:05
RPrburton: instantly have another 10 patches in -next, including live removal12:05
RPrburton: M2 though I think12:05
rburtoni need to double check all the other bits about live removal12:05
RPrburton: I will trigger M1 then, thanks12:06
*** distrozapper <distrozapper!> has joined #yocto12:09
*** distrozapper <distrozapper!> has quit IRC12:14
rburtonRP: fire in the hole!12:20
Ad0maybe a dumb question, but can't qemuarm machine config have a UBOOT_MACHINE  ?12:28
LetoThe2ndAd0: you could probably make it use one, but its uncommen.12:30
LetoThe2ndAd0: for most people it like, "u-boot get out of my way as quickly as possible". and as qemu can directly boot into a kernel, theres no reason even to get *into* your way first.12:31
Ad0I see12:32
kanavin__RP: I am not sure I understand the errors here, particularly the at-spi2 stuff seems to be building a previous version rather than the one I sent an update for?
RPkanavin__: It could well be I got lost in the patches with that. I dropped them simply as I was hitting failures and couldn't quite see what was wrong12:35
kanavin__RP: right, or maybe you dropped at-spi2-atk, but not at-spi2-core or atk, and that caused a mismatch12:36
RPkanavin__: right, its possible. I had to do something to try and partition the problems so I was pretty ruthless with failures. Rsend them in the next batch and we can test in isolation with the right patchset12:37
kanavin__RP: yep, generally centos 7 seems to be getting in the way of updates more and more lately :-/12:39
RPkanavin__: right, we are working on centos8 but that has different problems michael is working on12:39
*** berton_ <berton_!~berton@> has joined #yocto12:40
*** berton <berton!~berton@> has quit IRC12:43
yoctiNew news from stackoverflow: Yocto / OE : recipe with CMake install a shared library .so <>12:52
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC13:14
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto13:17
*** guerinoni <guerinoni!> has quit IRC13:34
*** bluca <bluca!~bluca@> has joined #yocto13:50
ThomasD13Are here some linux memory specialists? :) Regarding physical and logical addresses (ioremap vs phys_to_virt)14:03
*** AndersD <AndersD!> has quit IRC14:06
LetoThe2ndThomasD13: you have a considerably higher chance of getting an answer if you ask about your *actual* problem14:10
* zeddii sees armpit’s question / comment from last night .. I pushed the kernel-cache update this morning.14:11
ThomasD13Thats the way to go: I'm on a AARCH64 device. I allocate via "request_mem_region" 256 MB starting from physical address 0x4000 0000. After mapping this memory via "ioremap_nocache" into kernel virtual address space, I have noticed a difference when I use "phys_to_virt" function.14:16
*** iceaway <iceaway!~pelle@> has joined #yocto14:16
iceawayI am trying to include mono in my image, so I have cloned the meta-mono layer and checkout out the branch for my Yocto version (sumo). When I try to include Yocto I get the following error: nothing provides mono-gac needed by mono-
ThomasD13I'm little bit confused about this. I thought the purpose of  phys_to_virt should be to translate physical addresses to virtual ones.14:18
ThomasD13But the address I got from phys_to_virt seems to be wrong in my case.14:18
iceawayBut the mono-gac package SHOULD be provided by the mono-package itself. If I do bitbake mono-gac I get: mono RPROVIDES mono-gac14:18
qschulziceaway: there's a difference between provides and rprovides. provides is used to resolve DEPENDS and is at least the name of the recipe (can be something else if there's a PROVIDES set in the recipe). rprovides is for packages so either to resolve RDEPENDS or IMAGE_INSTALL, RRECOMMENDS, etc...14:23
iceawayqschulz: ahhh did not see the little 'r' there.14:25
iceawayIf I do "bitbake -e mono" and look for DEPENDS, it does not DEPEND on mono-gac but it RDEPENDS on it. Not sure if that makes me any the wiser though on how to resolve this.14:31
qschulzI don't remember how the error message is crafted, but might be that a dependency if mono is missing mono-gac14:33
iceawaySo If I only include mono in my image (which depends on mono-gac), would not bitbake automatically pick up and build/include the mono-gac dependency?14:38
qschulzit does not depend on mono-gac, it rdepends on it is what you said14:39
qschulzbut yes, however it should be an issue at build time, what the error message you sent is saying14:39
*** bernardoaraujo <bernardoaraujo!uid179602@gateway/web/> has joined #yocto14:42
*** fl0v0 <fl0v0!> has joined #yocto14:46
*** junland <junland!~junland@> has quit IRC14:47
qschulziceaway: can you paste somewhere the whole error log?14:48
*** junland <junland!~junland@> has joined #yocto14:48
iceawayqschulz: sure! give me a minute.14:50
*** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC14:52
fl0v0Hi, can somebody explain to me how the do_merge_delta_config task in the linux recipe (imx) is supposed to work? I get the merged defconfig in the WORKDIR but it doesnt seem to be used. Do i need a extra task to copy it somewhere? (The recipe:
*** AndersD <AndersD!> has joined #yocto14:53
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto14:59
*** AndersD <AndersD!> has quit IRC15:07
fl0v0just found out, that the correct merged config is in './build/config.old'. But the '.config' contains the unmerged config. Any ideas?15:09
qschulziceaway: the recipe looks correct though. PACKAGECONFIG ??= "gac" and PACKAGECONFIG[gac] = ",,mono-gac" with mono-gac being a package with files defined in FILES_${PN}-gac15:12
qschulzfl0v0: what's run after merge_delta_config? (i'm looking for preconfigure task especially)15:16
iceawayqschulz: Yeah I think it looks reasota15:18
iceawayreasonable too.15:18
fl0v0qschulz: do_preconfigure is run after merge_delta_config15:19
*** roussinm <roussinm!> has joined #yocto15:20
fl0v0do_merge_delta_config (30346): log.do_merge_delta_config.3034615:20
fl0v0do_copy_custom_device_tree_files (30345): log.do_copy_custom_device_tree_files.3034515:20
fl0v0do_preconfigure (30774): log.do_preconfigure.3077415:20
fl0v0this is an excerpt from log.task_order15:20
qschulzfl0v0: I meant what's inside that task. If you can point a git repo with the file with that task it'd be good help I think15:22
RPrburton: hashequiv build breakage on rc1. After it all worked :/15:23
fl0v0qschulz: there seems not much to be happening in that task :/ thats the whole log:15:25
fl0v0DEBUG: Executing shell function do_preconfigure15:25
fl0v0DEBUG: Shell function do_preconfigure finished15:25
fl0v0i try to find it. it must be inherited by   recipes-kernel/linux/linux-imx.inc15:27
fl0v0This file is here
fl0v0what on the other hand includes the poky kernel.bbclass15:30
JPEWRP: Have a link?15:32
RPJPEW: ^^^15:33
JPEWrburton: I think the last piece for reproducible core-image-sato and core-image-full-cmdline is your pod2man changes15:33
fl0v0qschulz: found it
RPJPEW: probably too15:33
RPJPEW: and is something different15:34
JPEWRP: Looks like the sstate object that it's looking for isn't actually in the sstate cache?15:40
RPJPEW: right, question is why it selected that object in the first place :/15:41
RPJPEW: I was looking at the OE-Core one15:41
JPEWRP: Did you add in the code to check for the existence of sstate objects before accepting a unihash from the server?15:42
RPNOTE: Task /home/pokybuild/yocto-worker/qemuarm-oecore/build/meta/recipes-devtools/gdb/ unihash changed to 06d1a23427579c4e46c34048c11b1d78ac57c1da43f67810efd37450f8e9c43f15:42
RPThat eSDK can't find that15:42
rburtonJPEW: woot woot15:42
rburtonJPEW: will finish and post15:42
RPJPEW: we have no choice but to accept unihashes from the server :(15:43
*** ericch <ericch!> has joined #yocto15:43
RPJPEW: question is how a unihash can exist but not be in sstate :/15:43
JPEWRP: OK. I thought we had done some validation on them, but I think I misremember15:43
RPJPEW: you may be thinking of how we report equiv if sstate exists?15:44
JPEWRP: Yes, thats probably it.15:44
armpitzeddii, thanks15:44
RPJPEW: I wonder if there was cleanup of the sstate cache we raced with :/15:45
JPEWRP: Possibly. How often does that happen?15:45
RPJPEW: we age out things not accessed for 30 days15:45
JPEWRP: So, I suppose the hash equiv database doesn't get cleaned out at the same time?15:50
JPEWBecause there really isn't anyway to do so (currently)15:50
RPJPEW: correct. I'm not 100% sure this what has happened here either, it would seem unlikely active sstate artefacts would be removed :/15:53
*** rcrudo <rcrudo!> has quit IRC15:54
*** ThomasD13 <ThomasD13!> has quit IRC15:55
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC15:57
*** rcrudo <rcrudo!> has joined #yocto15:57
*** goliath <goliath!~goliath@> has quit IRC15:57
fl0v0qschulz: reordering the tasks seems to have helped. compiling now. Thank you for the pointer15:58
qschulzfl0v0: how did you re-order?15:58
fl0v0addtask merge_delta_config before do_configure after do_patch do_preconfigure15:58
qschulzfl0v0: Quite confused by what they're doing here. Please test without sstate-cache as well to check that your modifications aren't benefitting from a side-effect ;)16:02
fl0v0i just turned on optimization for size. if the binary is smaller after compiling, it should be working :)16:04
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC16:07
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto16:08
fl0v0qschulz: yep it worked :)16:08
*** TobSnyder <TobSnyder!> has quit IRC16:11
qschulzfl0v0: worth sending a patch to meta-freescale I think. At least to let them know it does not work as expected and that what you did fixed it. They may even come up with a better solution16:17
*** hpsy <hpsy!~hpsy@> has quit IRC16:18
JPEWtlwoerner: I sent some patches for meta-rockchip, did you happen to see them?16:18
fl0v0qschulz: i think its an error of variscite, not freescale. But have to check the other freescale recipes to make sure16:19
tlwoernerJPEW: that's awesome! thanks! no i haven't seen them yet, i'm deep in "the coding cave" ;-)16:20
tlwoernerJPEW: panfrost! w00t!16:22
tlwoernerthe holidays have come early16:22
JPEWtlwoerner: Ya, it works reasonably well, and it's getting better all the time.16:22
* tlwoerner has a get-together planned with main panfrost developer for january :-)16:24
tlwoerneri'm glad to see it's (obviously) part of mesa now, last time i looked, it was still outside16:24
tlwoerneri'm hoping to get away from all that gpt stuff and move to wic sometime too...16:26
RPJPEW: I checked and that sstate artefact isn't there. I'm wondering if we could make hashequiv self healing16:26
JPEWtlwoerner: Ya. FWIW, you don't *have* to do GPT. Just writting the bits to the right offset is sufficent16:26
RPJPEW: i.e. when something is reported back, check sstate, if it exists, great. If not, send a delete request to hashequiv16:26
JPEWRP: Yes, thats what I was thinkng16:26
*** ericch <ericch!> has quit IRC16:27
*** ericch <ericch!> has joined #yocto16:27
JPEWRP: Deleting might be more complicated... can we make the sstate artifact with the correct name?16:27
*** ericch <ericch!> has joined #yocto16:27
RPJPEW: hmm, maybe16:27
JPEWe.g. rename, or perhaps even re-run the sstate packaging task16:27
RPJPEW: probably not in all cases16:28
RPJPEW: for an initial change yes but not for one as things ripple out16:28
tlwoerner... then i need better handling for kernel configs/defconfig16:28
JPEWtlwoerner: Ya, that would nice. Thankfully, the panfrost kernel driver is on by default for aarch64 and armv6 defconfigs :)16:29
JPEWRP: Delete would be OK, but it might have consequences because you would have to remove all matching unihashes16:30
RPJPEW: could you change it to a different hash?16:30
JPEWRP: Ya, I just was thinking that. Rename them all to the taskhash of the task that just ran16:30
tlwoernerJPEW: armv6?16:31
JPEWtlwoerner: armv716:31
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has joined #yocto16:31
tlwoernerah, sorry didn't see the ed line16:31
RPJPEW: what if we don't have a task which just ran though? :/16:33
*** lquirion <lquirion!> has joined #yocto16:34
roussinm By default TARGET_FPU is empty on AArch64, any reason for it?16:36
tlwoernerroussinm: isn't FPU non-optional on AArch64?16:39
tlwoerner(so it's probably on by default and can't changed?)16:40
roussinmtlwoerner: you mean the compiler knows which FPU to use?16:42
RPJPEW: wondering if I can somehow rescue the current build...16:42
*** goliath <goliath!> has joined #yocto16:43
RPJPEW: perhaps I just wipe the hashequiv DB :/16:43
*** adelcast <adelcast!~adelcast@> has quit IRC16:43
*** yann|work <yann|work!~yann@> has quit IRC16:45
*** andycooper <andycooper!uid246432@gateway/web/> has quit IRC16:55
roussinmI have an image with NO_RECOMMENDATIONS ?= "1", but I would like to have the recommendations when I build the sdk ( bitbake my_image -c populate_sdk ).16:57
roussinmRight now we have added the NO_RECOMMENDATIONS to the extrawhitelists and exported in the cmdline, but it feels like a hack.16:58
*** adelcast <adelcast!~adelcast@> has joined #yocto17:02
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC17:05
*** nmoos <nmoos!~moosnat@unaffiliated/moosnat> has joined #yocto17:08
JPEWRP: If we did the check at the time a unihash was reported as changed from the server that should be sufficent17:15
JPEW(because that is always in the context of a task)17:15
JPEWRP: In fact, I think if report_unihash() did a d.setVar('BB_UNIHASH', new_unihash), it might just work as expected17:18
JPEWsstate would make the object with the new unihash name, or do nothing because it already exists17:19
*** fl0v0 <fl0v0!> has quit IRC17:20
RPJPEW: I guess we could try a rebuild with that17:26
rburtonJPEW: fwiw i'm still seeing a number of buildpath warnings17:29
rburtoni've turned on buildpaths, which is a hint of something that will break reproducbile17:29
rburtoneg WARNING: libdnf-0.28.1-r0 do_package_qa: QA Issue: File /usr/lib/ in package libdnf contains reference to TMPDIR [buildpaths]17:29
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto17:29
RPJPEW: I'm just going to try it, risky but I don't have a better idea right now17:31
*** diego_r <diego_r!> has quit IRC17:32
*** Bunio_FH <Bunio_FH!> has quit IRC17:42
roussinmtlwoerner: just found a message from the mailing list saying that if it's empty, TARGET_FPU, that means default is hard for that architecture.17:44
tlwoernerroussinm: nice! (which is what i assumed and was trying to say above)17:46
JPEWrburton: Huh. I'll have to turn that on. I wonder why the test passes in that case...17:47
roussinmtlwoerner: just annoying that I had to search through the mailling list. Looking at the megamanual documentation, maybe it's something worth adding?17:48
*** vineela <vineela!vtummala@nat/intel/x-vrgqahzapjmcvuok> has joined #yocto17:48
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto17:53
*** jklare <jklare!~jklare@> has quit IRC17:58
*** micka <micka!> has joined #yocto17:59
*** jklare <jklare!~jklare@> has joined #yocto18:01
tlwoernerroussinm: the tuning files, surprisingly, change often enough. keeping the doc in sync with the tuning files would be a lot of work, and risk a lot of confusion if ever they didn't agree. maybe a more general doc update explaining how machine configs point to tune files and how to read a tune file in general would be better?18:36
roussinmtlwoerner: it's surprising indeed. In that case, I would agree on a more general approach, yes.18:38
*** yann|work <yann|work!> has joined #yocto18:46
*** lfa <lfa!~lfa@> has quit IRC18:56
millonihm silly question, is the sdk supposed to be MACHINE-specific?19:00
milloniwould "/opt/${DISTRO}/${SDK_VERSION}" make a good alternative for SDKPATH?19:01
millonisorry, that's the current value in poky19:02
milloniwould ""/opt/${DISTRO}/${SDK_VERSION}-${MACHINE}" make a good alternative for SDKPATH?19:02
millonior perhaps even redefining SDK_VERSION as something like:19:04
milloniSDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}', 'snapshot')}-${MACHINE}"19:04
*** mischief <mischief!> has joined #yocto19:10
mischiefis there a way to generate a package dependency graph?19:10
JPEWmischief: bitbake -g19:14
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:15
mischiefJPEW: i'm aware of the option but i don't care about the tasks. most of the edges in here are useless. i want to see what gets written into the package dependencies, not task dependencies19:16
milloniin older versions, bitbake would generate several graphs - one of them was a graph of dependencies between recipes19:19
millonithere was also a graph of dependencies between packages19:19
millonii dont know why they're gone now, these two were certainly more useful than the graph of tasks :/19:20
JPEWhuh, ya. I guess it doesn't do that anymore.19:20
millonii know i could probably extract a graph of recipes from the graph of tasks but it seems too difficult to figure out how to do that and then automate19:20
mischiefright.. i wasn't really looking to write a bespoke graph algorithm on monday morning.19:21
millonimischief: find the commit that removed the option to create a graph of recipes and revert it?19:22
millonii'd be interested to know why that option was removed though19:22
yoctiNew news from stackoverflow: BitBake add tmux package to image <>19:23
millonihm okay19:24
JPEWmischief: That's not the one you are looking for19:25
JPEWmischief: You want the file19:25
mischiefno such file is generated.19:25
JPEWmsichief: Correct, but it used to be generated19:26
JPEWmischief: Find the commit that removed, not the one that removed recipe-depends.dot19:27
mischiefdoubt a revert would work but i guess i can try to patch it in19:31
JPEWmischief: Hmm, it does look like something was lost there when the was removed. It doesn't look like the newer file outputs the runtime dependencies19:38
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto19:43
mischiefhaha, even the file output by this is 1.6MB, making dot slow to a crawl still19:44
JPEWmischief: I've never actually bother graphing it, I just read through the text & grep for what I'm looking for19:45
millonisame for me, i found that graphical representation is much more difficult to interpret, due to its size19:54
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC19:56
*** goliath <goliath!> has quit IRC20:23
*** andycooper <andycooper!uid246432@gateway/web/> has joined #yocto20:25
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto20:38
*** JaMa <JaMa!~martin@> has quit IRC20:43
roussinmWhy do I have to be at BUILDDIR to be able to invoke bitbake?20:59
rburtonin latest bitbake, you don't21:06
rburtongood reason to upgrade?21:07
roussinmWe just upgraded to Zeus.21:09
roussinmIs it after?21:09
rburtonsumo onwards, in fact21:09
rburtonthat is with the oe-core/poky oe-buildenv-internal script, so if you've a custom distro that doesn't use that script then it needs fixing21:10
roussinmOh man... I just saw... some senior at work hacked something, which prevents it....21:10
rburtonoe-core 82eeb934997c9eaa6443079dfb649a89872a222c was the fix there21:10
roussinmWe do have the script21:11
roussinmIn a local.conf we do `require ${PWD}/../local.conf`21:11
roussinmThat can't work unless you have at BUILDDIR21:11
rburtonthats horrible ;)21:13
rburtonuse BBPATH?21:13
rburtonshould be $(BUILDDIR) and is exported21:13
roussinmwhy a subshell?21:13
rburtonhabit, ignore that21:13
rburtonexport BBPATH21:14
rburtonsays the script21:14
*** berton_ <berton_!~berton@> has quit IRC21:14
roussinmHmm it fails because it tried to concatenate all the paths from the BBLAYERS paths. When using ${BBPATH}21:27
roussinmOh I see, all the layers appends to the BBPATH variable.21:29
*** yann|work <yann|work!> has quit IRC21:30
armpitzeddii, I got a kernel oops on Arm for 4.18.45 on thud on the AB.. I need to triage it local and will open a bug if need be21:35
*** tgamblin <tgamblin!~tgamblin@> has quit IRC21:36
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto21:43
*** yann <yann!> has joined #yocto21:44
*** pohly <pohly!> has quit IRC21:46
roussinmrburton: so in theory if we do `require ../company-local.conf`21:51
roussinmIt should be "cleanish" ?21:51
rburtoncompany-local.conf sounds a lot like it should be site.conf in your own layer21:51
rburtonany file called conf/site.conf in a layer is included automatically21:52
rburtonsite-wide settings that are not distro-specific21:52
rburtoneverything else should be in your distro21:52
rburtonthen your local.conf can be templated using your layer21:52
roussinmSo you are saying that, for example, DL_DIR should be inside a layer?21:52
rburtonif its a company-wide setting then sure.  sstate_mirrors is a good example if you have a central server.21:53
roussinmWe use that company-local.conf for compagny wide settings.21:53
rburtoni'd look at moving that to site.conf then21:54
roussinmbut that configuration file has to be the same for all machines.21:54
rburtonright, has to be generic settings21:55
roussinmOh, but we have different directories for each machines `/builds/yocto/machine1..5`. When we source the environment we source for a specific machine. If we use site.conf it would be duplicate inside each machine?22:00
roussinmMaybe we shouldn't have a seperate directories for each machine?22:01
*** dv_ <dv_!> has quit IRC22:04
*** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC22:12
*** goliath <goliath!> has joined #yocto22:12
*** dv_ <dv_!> has joined #yocto22:22
*** tgamblin <tgamblin!> has joined #yocto22:36
*** agust <agust!> has quit IRC23:04
tlwoernerJPEW: still around?23:24
*** sstabellini <sstabellini!sstabellin@gateway/shell/xshellz/x-vrxobbleezmitueb> has quit IRC23:25
RPJPEW: Still erroring: :(23:36
RPJPEW: I guess I'll need to check the patch actually did what we hoped/wanted it to :/23:38
yoctiNew news from stackoverflow: Add OP-TEE to Yocto <>23:54

Generated by 2.11.0 by Marius Gedminas - find it at!