Monday, 2020-06-15

*** RP <RP!> has quit IRC00:09
*** camus1 <camus1!~Instantbi@> has joined #yocto00:10
*** kaspter <kaspter!~Instantbi@> has quit IRC00:11
*** camus1 is now known as kaspter00:11
*** behanw <behanw!uid110099@gateway/web/> has quit IRC00:37
*** fl0v01 <fl0v01!~fvo@> has joined #yocto02:05
*** fl0v0 <fl0v0!~fvo@> has quit IRC02:05
*** dev1990_ <dev1990_!> has joined #yocto03:15
*** dev1990 <dev1990!~dev@> has quit IRC03:16
*** g0hl1n <g0hl1n!> has quit IRC04:39
*** sakoman <sakoman!> has quit IRC04:49
*** gtristan <gtristan!~tristanva@> has quit IRC04:50
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto04:55
*** agust <agust!> has joined #yocto05:00
*** ibinderwolf <ibinderwolf!> has joined #yocto05:12
*** gtristan <gtristan!~tristanva@> has joined #yocto05:21
*** jobroe <jobroe!> has joined #yocto05:29
*** jobroe <jobroe!> has quit IRC05:31
*** AndersD <AndersD!> has joined #yocto05:32
*** kroon <kroon!~kroon@> has joined #yocto05:33
*** AndersD <AndersD!> has quit IRC05:44
*** pohly <pohly!> has joined #yocto05:52
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC06:02
*** kroon_ <kroon_!~kroon@> has joined #yocto06:09
*** kroon <kroon!~kroon@> has quit IRC06:11
*** kroon_ is now known as kroon06:12
*** kaspter <kaspter!~Instantbi@> has quit IRC06:16
*** kaspter <kaspter!~Instantbi@> has joined #yocto06:16
*** NiksDev <NiksDev!~NiksDev@> has quit IRC06:27
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto06:27
*** rcoote <rcoote!> has joined #yocto06:39
*** camus1 <camus1!~Instantbi@> has joined #yocto06:46
*** kaspter <kaspter!~Instantbi@> has quit IRC06:46
*** camus1 is now known as kaspter06:46
*** sagner <sagner!~ags@2a02:169:3df5:0:e84:c285:65c9:b02e> has quit IRC06:52
*** sagner <sagner!~ags@2a02:169:3df5::edf> has joined #yocto06:52
*** mckoan|away is now known as mckoan06:57
mckoangood morning06:57
*** camus1 <camus1!~Instantbi@> has joined #yocto07:10
*** kaspter <kaspter!~Instantbi@> has quit IRC07:11
*** camus1 is now known as kaspter07:11
*** neheist <neheist!~neheist@> has joined #yocto07:17
*** kaspter <kaspter!~Instantbi@> has quit IRC07:23
*** kaspter <kaspter!~Instantbi@> has joined #yocto07:23
*** camus1 <camus1!~Instantbi@> has joined #yocto07:33
*** kaspter <kaspter!~Instantbi@> has quit IRC07:33
*** camus1 is now known as kaspter07:33
*** nameclash <nameclash!> has joined #yocto07:36
*** yann|work <yann|work!> has joined #yocto07:39
*** amerigo <amerigo!uid331857@gateway/web/> has joined #yocto07:50
*** goliath <goliath!~goliath@> has joined #yocto08:05
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto08:06
*** neheist <neheist!> has joined #yocto08:17
*** camus1 <camus1!~Instantbi@> has joined #yocto08:21
*** kaspter <kaspter!~Instantbi@> has quit IRC08:22
*** camus1 is now known as kaspter08:22
*** vicale <vicale!> has quit IRC08:24
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:29
*** florian_kc is now known as florian08:39
*** nucatus <nucatus!> has joined #yocto08:43
nucatusHello! I'd need an advice about customising a kernel module that is loaded at boot time. This customisation has to be machine specific, because if configures the GPIO pins the module will use and these pins are MACHINE specific.08:45
Letothe2ndnucatus: so what is the question?08:47
nucatuswhat is the best place to make such customisation? (a) the <machine>-extra.conf file (b) *.bbappend file that is set to be compatible with a specific machine?08:47
Letothe2ndnucatus: it depends a bit, but (b) is a relatively common, non-conf-invasive approach08:47
nucatusis there a best practice for such customisations?08:48
Letothe2ndnucatus: you could even do modifications through overriding appends in the module recipe itself, if that suits your metadata layout better.08:49
Letothe2ndthe best practise depends "TM"08:49
*** lfa <lfa!~lfa@> has joined #yocto08:50
Letothe2ndif its a machine bsp layer you control, or not - if the modifications are really board specific, or also application dependent - and so on, and so on.08:50
nucatusLetothe2nd: they are tend to be more application dependent. The kernel module is added by an application recipe08:51
nucatusand I was thinking to have a meta-core/recipes-bsp/customisation.bbappend file08:52
Letothe2ndnucatus: given that still relatively coarse information, i would probably go for an append in the application layer, which triggers on machine08:52
*** RP <RP!> has joined #yocto08:53
Letothe2ndnucatus: if the application has an effect on the customization, its counter-productive to have the append in a lower (read: bsp or "core") layer08:53
nucatusbut then how should I avoid polluting the application layer with machine specific code?08:54
nucatusI mean, the customisation is a prerequisite for the application recipe where the module is added08:55
Letothe2ndnucatus: if the application has to modify hw-dependent things then the application is not freestanding anyways, right? hence the application layer can also bring those modifications. but, and thats the other criterion - that only holds true if the modification and the layer have no other use than this application.08:56
nucatusyeap, I see your point! And indeed, it makes sense08:57
nucatusyes, the customisation is intended for the sole use in that module. It actually configures the module using the KERNEL_MODULE_PROBECONF in a machine specific way08:59
Letothe2ndnucatus: well, choose wisely then.08:59
nucatusLetothe2nd: cool! thanks for your time and answers! I appreciate your efforts!!09:01
Letothe2ndnucatus: have fun!09:01
*** gtristan <gtristan!~tristanva@> has quit IRC09:06
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto09:07
*** rcoote <rcoote!> has quit IRC09:14
*** neheist <neheist!> has quit IRC09:17
*** rcoote <rcoote!> has joined #yocto09:23
*** Moh3N <Moh3N!b23e5c1d@> has joined #yocto09:48
Moh3Nhi , I want to have tftp in uboot, but my problem is that now I cant ping any device especialy my tftpserver !!!09:52
Moh3Nhow I can recognize that is my uboot have network driver ??09:52
Letothe2ndMoh3N: by joining #u-boot :)09:54
Moh3Nis there any chat room for uboot?09:56
Letothe2ndMoh3N: #u-boot09:56
Moh3Ni cant join to this room!!09:56
Letothe2ndMoh3N: well maybe you need to register on freenode first, thats possible09:57
Moh3NI ask this question in this room because I want to know can I manipulate uboot in yocto ?! and can I recognize existance of network driver in my uboot by yocto ?09:58
Moh3NLetothe2nd thanks09:58
Letothe2ndMoh3N: again, this is very clearly an u-boot question. please use their channel and/or mailing list.09:59
Moh3Nok, excuseme.thank09:59
*** Moh3N <Moh3N!b23e5c1d@> has quit IRC10:00
*** creich_ <creich_!> has quit IRC10:09
*** gtristan <gtristan!~tristanva@> has joined #yocto10:09
*** hpsy <hpsy!~hpsy@> has joined #yocto10:09
*** creich <creich!> has joined #yocto10:22
*** amerigo <amerigo!uid331857@gateway/web/> has quit IRC10:25
*** creich <creich!> has quit IRC10:30
*** nucatus <nucatus!> has quit IRC10:34
*** ant_home <ant_home!> has quit IRC10:37
*** nucatus <nucatus!> has joined #yocto10:41
*** kpo <kpo!> has quit IRC10:42
*** kpo <kpo!> has joined #yocto10:49
*** BobPungartnik <BobPungartnik!~BobPungar@> has joined #yocto10:56
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC10:58
*** hipr_C <hipr_C!~Thunderbi@> has joined #yocto11:09
*** gtristan <gtristan!~tristanva@> has quit IRC11:38
*** lukma <lukma!> has quit IRC11:43
*** creich <creich!> has joined #yocto11:45
*** berton <berton!~berton@> has joined #yocto11:53
silviofHow can I manipulate the PV variable? Background is, I make changes to a file that is normally created by dnsmasq. Now I'm adapting the dnsmasq in a `bbappend' and want to manipulate the PV so that the TAG of the repository is included. So that I have about "2.78+netconf1.16". A `PV = "${PV}+netconf${TAG}"` does not work for the time being. A `PV_append` also runs into nothing and throws an exception `which triggered exception11:54
silviofValueError: could not convert string to float: '78+netconf${TAG}'`11:54
*** geheimnis` <geheimnis`!~geheimnis@> has quit IRC11:54
Letothe2ndsilviof: well says you should be able to override it. hence, bitbake -e inspection is due i'd say, to find where the assignment goes astray.11:57
silviofHi Letothe2nd Thanks. Yeahh - I have the feeling that PV is somehow special in such matters. Then I'll follow up on the "-e" tip. Thanks.11:59
*** paulg <paulg!> has joined #yocto11:59
Letothe2ndsilviof: i guess its just some form of evaluation ordering problem12:00
*** geheimnis` <geheimnis`!~geheimnis@> has joined #yocto12:00
*** sagner <sagner!~ags@2a02:169:3df5::edf> has quit IRC12:04
*** sagner <sagner!~ags@2a02:169:3df5::587> has joined #yocto12:04
rburtonnothing should be treating the PV as a float, so maybe look at the stack to figure out where that is happening12:07
rburtonPV is not special12:07
silviofAHHH thanks rburton dnsmasq calculates the download folder from a python one liner `${@['archive/', ''][float(d.getVar('PV').split('.')[1]) > 69]}dnsmasq-${PV}.tar.gz;name=dnsmasq-${PV}`.12:14
rburtonthat is just stupid :)12:15
silviof"Not the usual way."12:16
rburtonif you want to fix that then setuptools includes a version parsing class12:21
*** berton <berton!~berton@> has quit IRC12:21
*** berton <berton!~berton@> has joined #yocto12:22
*** gtristan <gtristan!~tristanva@> has joined #yocto12:31
*** mcfrisk <mcfrisk!> has quit IRC12:39
*** mcfrisk <mcfrisk!> has joined #yocto12:39
*** nucatus <nucatus!> has quit IRC12:41
*** nucatus_ <nucatus_!> has joined #yocto12:41
*** maudat <maudat!> has joined #yocto12:43
*** ericch <ericch!> has joined #yocto13:00
*** kanavin_home <kanavin_home!~ak@> has quit IRC13:08
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:b652:c378:b428:fdf> has joined #yocto13:10
*** sveinse <sveinse!> has joined #yocto13:13
sveinseWhen looking at it shows "pkg.task" -> "depending_pkg.task" right? I've got a recipe which pulls in dependencies I can't find in the .bb file. bitbake -e doesn't list it as a dependency, so how can I approach debugging this? I'm on dunfell13:15
Letothe2ndsveinse: dependencies like what?13:16
sveinseLetothe2nd: Like an unexpected package being pulled in13:16
*** leon-anavi <leon-anavi!~Leon@> has quit IRC13:17
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto13:17
qschulzsveinse: dependencies of your dependencies probably?13:17
Letothe2ndsveinse: yeah but it is really completely unrelated, or a transitive dependency (like qschulz said), or rather an implicit one (like a packaging or cross compilation thing)13:18
sveinseqschulz: shows immediate dependencies, doesn't it? a -> b13:19
sveinseOr is bitbake unravel dependencies, e.g. if a -> b -> c, resulting in a -> b, a -> c, b -> c ?13:20
sveinseHmm, not that would make the tree enormous13:20
Letothe2ndthe tree is ginormous....13:22
*** goliath <goliath!~goliath@> has quit IRC13:22
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto13:23
*** ssajal <ssajal!> has joined #yocto13:23
sveinseLetothe2nd: Its 20 years too late to make Matrix jokes, but you have to look at in code form because there is way too much information to decode it all. :P13:23
RPsveinse: it doesn't unravel like that, changing to that form would break things!13:23
Letothe2ndsveinse: i don't get the joke. for me its pretty common to look at it in code form.13:24
sveinseRP: thanks. Nor am I trying to. Just trying to figure out what and where the extra dependency is being added or injected13:25
*** vmeson <vmeson!> has joined #yocto13:26
sveinseLetothe2nd: Sure. Sorry. A bad one apparently. Again 20 years too late :D  (Someone said to me that one sign that you're getting old is that you're still quoting Matrix)13:26
Letothe2ndsveinse: hehe i know what you mean.13:29
*** NiksDev <NiksDev!~NiksDev@> has quit IRC13:30
*** NiksDev <NiksDev!~NiksDev@> has joined #yocto13:30
*** kroon <kroon!~kroon@> has quit IRC13:38
*** mihai- <mihai-!~mihai@unaffiliated/mihai> has joined #yocto13:49
*** ssajal <ssajal!> has quit IRC13:52
*** leitao <leitao!~leitao@2620:10d:c093:400::5:b870> has joined #yocto13:53
*** AndersD <AndersD!> has joined #yocto13:54
*** ssajal <ssajal!> has joined #yocto13:58
*** sakoman <sakoman!> has joined #yocto13:59
PaowZquestion: do you see where it is stated where the lib is supposed to be delivered, in that recipe ?
PaowZcurrently, yocto ships the lib in /usr/lib.. default opencv CMakeList.txt says it is in /usr/local..14:04
PaowZI can't find where /usr/lib comes from..14:04
sveinseAny ideas at all on how to trace down when the "sp-system.do_build" depends on "system-controller.do_package_write_ipk", when the name "system-controller" is never mentioned in (verified by look at bitbake -e sp-system)?14:05
Letothe2ndPaowZ: hopefully /usr/lib comes from nowhere, its jetzt the generic prefix that yocto sets, and a proper CMakeLists adheres to it.14:05
Letothe2ndPaowZ: so if you've got something that has /usr/local hardcoded in it, then it is a bug.14:06
*** Net147 <Net147!> has quit IRC14:07
PaowZLetothe2nd: tks for your reply.. interesting.. do you believe it is bug ?
qschulzsveinse: check the DEPENDS/PACKAGECONFIG on the dependent recipes until you find it :) start from the one you know (the ones for sp-system)14:08
Letothe2ndPaowZ: nope.
Letothe2ndPaowZ: without digging the specifics, this seems to say exactly what is right: if user provides soemthing (which yocto does) then use that, else go to /usr/local14:09
sveinseqschulz: that's the thing: the recipe has DEPENDS += "" and the -e file for it sais DEPENDS="virtual/arm-oe-linux-gnueabi-gcc virtual/arm-oe-linux-gnueabi-compilerlibs virtual/libc  "14:09
Letothe2ndPaowZ: and that is perfectly ok.14:10
Letothe2ndsveinse: 13:18 < Letothe2nd> sveinse: yeah but it is really completely unrelated, or a transitive dependency (like qschulz said), or rather an implicit one (like a packaging or cross compilation thing)14:11
Letothe2ndsveinse: so case #314:11
Letothe2ndit seems.14:11
PaowZok.. fine.. so Yocto does provide the install path.. right.. it seems we have to comply to what yocto provides, in terms of path.. would that be a bad practice for me to provide another path ?14:11
qschulzsveinse: also, try to find the exact task that depends on a task from system-controller, because sp-system.do_build is not really helpful :/14:12
qschulzare you sure it's a build time dependency you're after? and not a runtime dependency?14:12
sveinseqschulz: I'm trying to hunt down _why_ the depencency exitst (it shouldn't be there), implicit og explicit14:13
Letothe2ndPaowZ: its not something yocto says. its th FHS (feel free to look it up), which basically says that system-wide, non-user-installed libraries shall go to /usr/lib.14:14
qschulzsveinse: well, if you're only looking at DEPENDS and it comes from an RDEPENDS or a RRECOMMENDS, it'll be hard to check, hence my question14:14
qschulzhard to find*14:14
Letothe2ndPaowZ: so my advice is to fix your whatever that tries to use it, instead of whacking libraries out of their standard locations.14:14
smurraysveinse: you can see what modifies DEPENDS in the "bitbake -e" output14:14
qschulzsmurray: they've said already that DEPENDS does not have it :)14:15
smurrayqschulz: yeah, I'm trying to decipher this backlog14:16
Letothe2ndsveinse: insert $BEER. often helps.14:16
Letothe2ndsmurray: ^^^14:16
smurrayLetothe2nd: 10 am here, I've not even had coffee yet14:16
sveinseLetothe2nd: even on a Monday?14:16
*** goliath <goliath!> has joined #yocto14:16
Letothe2ndsmurray: yes and sveinse yes.14:16
smurraysveinse: what's the runtime dependency that's getting pulled in that you don't want?14:17
PaowZLetothe2nd: FHS.. ok.. that means I have to make my CMakeLists.txt comply with FHS .. strange opencv path is not /usr/lib by default..14:19
Letothe2ndPaowZ: please, don't blame opencv. its absolutely common for biuld scripts to target /usr/local as the default install location, to make it easier for users who do not intentionally care. and at the same time using the settings that distribution builders can provide to override them, which will usually be /usr/lib14:21
Letothe2ndPaowZ: so without actually digging that particular package/recipe, it seems that they are behaving absolutely correct. if you assume something to be in a specific location, instead of properly using detection mechanisms like pkg-config, then your thing is broken. not the other ones.14:22
*** berton <berton!~berton@> has quit IRC14:23
sveinseRP: With all due respect, wrt unraveling I think maybe you're wrong. I dumped build/ on a recipe, then added a RDEPENDS to it, and reran bitbake -g. I now see more that just one "a.do_build" -> "b.do_package_write_ipk". I see like 100s of "a.do_build" -> various "*.do_package_write_ipk" for the entire dep tree of that RDEPENDS entry.14:25
sveinsesmurray: yeah, I think I found my culprit. As you and Letothe2nd were saying. It was a indirect RDEPENDS that pulled int one too many. The culprit drowned in the huge dependency list that ended up as the result. Ref ^^. Thanks guys14:29
RPsveinse: that is correct but it does not mean its unravelling as you describe, its not. If it did, things would actually break14:31
PaowZLetothe2nd: I'm no one to blame anybody/anything.. but for users who do not intentionaly care, default path could have been /usr/lib.. even it is stated /usr/lib is for libs for binaries in /usr/bin..that's what I'm saying.. In the mean time, the proposal of /usr/local makes totally sense since it's supposed to contain Tertiary hierarchy for local data, specific to this host." - quoting.. that's interesting and will have impact on how14:33
PaowZI detect libs for linkage, after all..14:33
Letothe2ndPaowZ: then users who do not intentionally care would probably break the whole system if they install things without checking first if those already happen to exist. so nope, you're wrong here. and yes, you actually have to detect inclusion and linkage, instead of guessing/Assuming.14:35
sveinseRP: Is there any information (internally) that can tell why a dependency exitst? Something along the lines of "a.do_build" -> "c.do_package_write_ipk" because a RDEPENDS on b which DEPENDS on c ?14:35
RPsveinse: the types of dependencies we have make it very hard to give that information in a meaningful way :(14:36
crazoes[m]1hello, i've been trying to build image myself. seems like bitbake server doesn't start:14:36
crazoes[m]1--- Starting bitbake server pid 1959717 at 2020-06-15 20:04:09.366995 ---14:36
crazoes[m]1ERROR: Can't get compiler version from gcc  --version output14:36
qschulzsveinse: technically, that would be the job of dot. But considering that it takes hours and hours to create the svg/png/jpeg and the result is barely usable :/14:36
qschulzcrazoes[m]1: ? are they all there? Are you using a supported distro?14:37
sveinseRP: yes, agreed. And my use case is no different unfortunately. It's very hard to identify the real deps when they are hidden in the jungle of indirect deps :(14:38
Saur qschulz: The dot files are good for a lot of things, rendering the graph for a complete image is not one of them. Using grep on the file is a much better solution then.14:38
*** hpsy <hpsy!~hpsy@> has quit IRC14:38
RPsveinse: indirect deps are likely from the rdeptask dependencies FWIW14:39
sveinseqschulz: I'm reading dot manually, which functions ok-ish. However, dot doesn't show the difference between a direct dependency and an indirect one. At least not in the case of RDEPENDS as we just have seen.14:39
qschulzsveinse: when you render the graph, it should IIRC? but /me shrugs14:39
sveinseqschulz: let me check, perhaps there is a dot annotation I've missed14:40
crazoes[m]1qschulz:  building on arch, so no. However, before this build my bitbake core-image-sato command ran.. I had to cancel it and was trying to resume again14:42
Letothe2ndcrazoes[m]1: archers usually resort to docker containers for building :)14:42
crazoes[m]1gcc is in path, i can run gcc --version14:42
Saurqschulz, sveinse: There used to be such annotations in the recipe graph (if I remember correctly), but that graph is not produced anymore.14:43
PaowZLetothe2nd: I was more of discussing around the delivery path more than the fact that users have to detect lib presence prior installing things.. but I get the point, ok.. and will correct my stuff accordingly in order to remain in good practices behaviour.. :)14:43
crazoes[m]1Letothe2nd: I see, I will try that out14:45
qschulzcrazoes[m]1: kas or pyrex are two possibilities for building Yocto within docker14:45
*** sgw <sgw!~sgw@> has quit IRC14:47
crazoes[m]1qschulz: thanks, checking them out14:49
*** sgw <sgw!> has joined #yocto14:50
qschulzcrazoes[m]1: for kas14:50
Letothe2ndqschulz: :)14:59
*** vineela <vineela!~vtummala@> has joined #yocto14:59
*** goliath <goliath!> has quit IRC14:59
sveinseAre there anyone of you that builds for multiple MACHINEs? How do you do that? Run bitbake N times foreach machine, or do you use multiarch config?15:00
qschulzsveinse: multiple bitbakes. For me multiconfig is just to create an image that has some artifacts on two different archs (e.g. soc with cortex-a7 for linux and cortex-m4 for something else)15:03
*** PaowZ_ <PaowZ_!~Vince@> has joined #yocto15:03
sveinseqschulz: cool. We do multiple bitbakes, as our three HWs are based of the same tune, thus a large portion of the pacakges are reusable that doesn't have to be built 3 times.15:04
sveinseI experimented with multiarch, but I found it was slower than the sum of running it three times (back in rocko, haven't tried it recently), and it was unstable so I wouldn't trust it in an prod environment15:05
*** sgw1 <sgw1!~sgw@> has joined #yocto15:06
*** amerigo <amerigo!uid331857@gateway/web/> has joined #yocto15:23
*** Net147 <Net147!> has joined #yocto15:33
*** nucatus_ <nucatus_!> has quit IRC15:33
*** leon-anavi <leon-anavi!~Leon@> has quit IRC15:34
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto15:34
*** AndersD <AndersD!> has quit IRC15:34
*** lukma <lukma!> has joined #yocto15:39
lukmaDear Community,15:40
lukmaIs there any issue - or recommendation to run the bitbake from shared topdir?15:40
paulbarkerlukma: What do you mean by "shared topdir"?15:42
*** Sandrita23 <Sandrita23!18ca2637@gateway/web/cgi-irc/> has joined #yocto15:43
*** goliath <goliath!> has joined #yocto15:45
lukmapaulbarker: For example NFS15:46
lukmathat ./build is in NFS mounted directory15:47
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has quit IRC15:47
paulbarkerlukma: Do you intend to have multiple instances of bitbake building at the same time?15:47
lukmabuild$ bitbake -DD core-image-foo15:47
lukmaNOTE: Reconnecting to bitbake server...15:47
lukmaNOTE: Previous bitbake instance shutting down?, waiting to retry...15:47
lukmapaulbarker: No, I do want to run a bitbake in build which is on network disk15:48
lukmaAnd only ./build is there, as e.g. tmp is mounted on the local disk15:48
paulbarkerlukma: If you've only got one instance of bitbake running at a time it may be ok. Not sure how unix domain sockets work when the underlying filesystem is an NFS mount though you'll need to do some research into that15:49
RPpaulbarker: thanks again for the gitsm fix, I've merged it as testing seemed god!15:49
mckoanlukma: AFAIK bitbake doesn't like NFS, it won't work15:50
lukmaSo the build directory shall be on the local share .....15:52
Letothe2nds/local share/local storage/g15:52
lukmaBTW: Is it now possible to run two instances of bitbake?15:59
lukmafor two distinct yocto builds?15:59
lukma(like one is sumo and other is zeus)15:59
mckoanlukma: yes in two different installation trees16:00
lukmamckoan: you mean two separate directories -> like PROJ1 and PROJ2 (and they don't use any common sstate caches)16:01
mckoanlukma: you can share the sstate16:04
mckoanlukma: however would be better if you explain what you want to get instead of giving a drop of info each time16:04
lukmamckoan: I do have a container16:06
lukmawhich has some directories bind16:06
lukmait emulates Ubuntu 16.04 lts16:07
lukmaI'm wondering if I shall be prepared for any extra issues16:07
lukmawhen I would like to build two projects in the same time16:07
lukmathose project are placed in to two different directories PROJ1 , PROJ216:07
lukma(separate build, sstate-cache)16:08
lukmaPROJ1 is THUD, PROJ2 is SUMO16:08
lukmais it possible to connect to the container with two shells and build those two projects in the same time16:08
paulbarkerlukma: Sounds fine as long as each project has its own TOPDIR, cache and TMPDIR16:11
paulbarker(I can never remember the variable that sets the cache directory path)16:11
qschulzand DEPLOY_DIR I'd say as well? basically everything except SSTATE_DIR AND DL_DIR should be on different paths?16:13
*** alejandr1 <alejandr1!~alejandro@> has joined #yocto16:14
*** alejandrohs <alejandrohs!~alejandro@> has quit IRC16:15
JPEWRP, sakoman: Does need backported to dunfell?16:15
lukmapaulbaker: then I shall be fine :)16:19
lukmaThanks for help16:19
sakomanJPEW: Good question, since it is a bug fix I would assume the answer is yes.  Are there any possible downsides to taking these?16:25
*** nameclash <nameclash!> has quit IRC16:27
RPsakoman: its a fairly heavy change to bitbake :/16:35
JPEWsakoman: Ya, it also means oe-core would require the latest bitbake16:35
JPEWOr the latest branch of bitbake?16:36
JPEWbitbake is backward compatible with older oe-core, but the reverse is not true16:36
sakomanThat sounds like a fairly significant downside!16:36
sakomanHow common/painful is the issue being fixed?16:37
JPEWsakoman: I'm not sure. There was a reported bug and we found it here, but perhaps using mcdepends isn't very common? Or, people just don't know its broken16:38
JPEWWe didn't for a while :)16:38
RPIts more that people just haven't found this particular use case16:39
sakomanGiven the intrusiveness of bitbake changes I'm inclined to say no . . .16:40
JPEWsakoman: That's fair. I figured I'd point it out :)16:40
sakomanI appreciate that!  It is so easy to miss stuff16:40
JPEWRP: Also reminds me, do we need to bump some minimum-bitbake-version in oe-core?16:42
*** nucatus <nucatus!> has joined #yocto16:42
RPJPEW: probably, yes, and the versions in bitbake16:43
*** mckoan is now known as mckoan|away16:47
*** nucatus <nucatus!> has quit IRC16:49
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:50
*** nerdboy <nerdboy!~sarnold@> has quit IRC16:51
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:51
*** nucatus <nucatus!> has joined #yocto16:55
*** leitao <leitao!~leitao@2620:10d:c093:400::5:b870> has quit IRC16:58
*** dreyna <dreyna!> has joined #yocto17:12
*** hpsy <hpsy!~hpsy@> has joined #yocto17:14
*** rcoote <rcoote!> has quit IRC17:25
*** gnac <gnac!> has joined #yocto17:54
*** Sandrita23 <Sandrita23!18ca2637@gateway/web/cgi-irc/> has quit IRC17:59
*** Dracos-Carazza <Dracos-Carazza!> has quit IRC18:05
*** Dracos-Carazza <Dracos-Carazza!> has joined #yocto18:05
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto18:13
*** Dracos-Carazza_ <Dracos-Carazza_!> has joined #yocto18:18
*** Dracos-Carazza <Dracos-Carazza!> has quit IRC18:18
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC18:20
*** Dracos-Carazza_ is now known as Dracos-Carazza18:28
*** ericch <ericch!> has quit IRC18:30
*** pascu <pascu!> has joined #yocto18:35
*** leon-anavi <leon-anavi!~Leon@> has quit IRC18:38
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto18:38
*** pascu <pascu!> has quit IRC18:40
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has joined #yocto18:42
*** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/> has quit IRC19:00
*** nucatus <nucatus!> has quit IRC19:05
*** leon-anavi <leon-anavi!~Leon@> has quit IRC19:07
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto19:07
*** vineela <vineela!~vtummala@> has quit IRC19:07
*** goliath <goliath!> has quit IRC19:08
*** Sandrita <Sandrita!18ca2637@gateway/web/cgi-irc/> has joined #yocto19:25
*** vineela <vineela!~vtummala@> has joined #yocto19:39
*** gnac <gnac!> has quit IRC20:13
*** alejandr1 <alejandr1!~alejandro@> has quit IRC20:14
*** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has quit IRC20:14
*** gnac <gnac!> has joined #yocto20:14
*** hipr_C <hipr_C!~Thunderbi@> has quit IRC20:15
*** vineela <vineela!~vtummala@> has quit IRC20:19
*** armpit <armpit!~armpit@2601:202:4180:a5c0:5030:aa9f:23eb:a3d9> has quit IRC20:21
*** armpit <armpit!~armpit@2601:202:4180:a5c0:f4e2:b142:af1d:6837> has joined #yocto20:23
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto20:29
*** nslu2-log <nslu2-log!> has quit IRC20:36
*** nslu2-log <nslu2-log!> has joined #yocto20:38
JPEWRP: Before I lie on my presentation: The reproducible builds test is only done for i386 and x86_64?20:39
RPJPEW: just x86_6420:39
JPEWRP: Thanks20:40
* RP waits for rburton to read that20:40
JPEWAArch64 would be nice to test also :)20:41
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC20:47
*** pohly <pohly!> has quit IRC20:53
*** vineela <vineela!vtummala@nat/intel/x-yzbehzoybrgcipal> has joined #yocto21:28
*** leon-anavi <leon-anavi!~Leon@> has quit IRC21:38
*** goliath <goliath!> has joined #yocto21:38
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto21:38
jonmasonis anyone using meta-zephyr?21:49
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:b652:c378:b428:fdf> has quit IRC21:57
*** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:b652:c378:b428:fdf> has joined #yocto21:59
*** sgw <sgw!> has quit IRC21:59
*** sgw <sgw!> has joined #yocto22:01
*** vineela <vineela!vtummala@nat/intel/x-yzbehzoybrgcipal> has quit IRC22:33
*** tgamblin <tgamblin!> has quit IRC22:48
*** tgamblin <tgamblin!> has joined #yocto22:48
*** vineela <vineela!~vtummala@> has joined #yocto22:54
*** amerigo <amerigo!uid331857@gateway/web/> has quit IRC23:25
*** goliath <goliath!> has quit IRC23:44
*** leon-anavi <leon-anavi!~Leon@> has quit IRC23:46
*** linuxjacques is now known as jacques23:51
*** tgamblin <tgamblin!> has quit IRC23:59

Generated by 2.17.2 by Marius Gedminas - find it at!