| *** RP <RP!~RP@5751f4a1.skybroadband.com> has quit IRC | 00:09 | |
| *** camus1 <camus1!~Instantbi@222.70.81.223> has joined #yocto | 00:10 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has quit IRC | 00:11 | |
| *** camus1 is now known as kaspter | 00:11 | |
| *** behanw <behanw!uid110099@gateway/web/irccloud.com/x-dairdhfbjqhxwuae> has quit IRC | 00:37 | |
| *** fl0v01 <fl0v01!~fvo@89.244.123.13> has joined #yocto | 02:05 | |
| *** fl0v0 <fl0v0!~fvo@89.244.120.44> has quit IRC | 02:05 | |
| *** dev1990_ <dev1990_!~dev@dynamic-78-8-227-185.ssp.dialog.net.pl> has joined #yocto | 03:15 | |
| *** dev1990 <dev1990!~dev@78.8.181.237> has quit IRC | 03:16 | |
| *** g0hl1n <g0hl1n!~g0hl1n@83-215-125-121.lhau.dyn.salzburg-online.at> has quit IRC | 04:39 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has quit IRC | 04:49 | |
| *** gtristan <gtristan!~tristanva@110.11.227.189> has quit IRC | 04:50 | |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto | 04:55 | |
| *** agust <agust!~agust@p508b67ab.dip0.t-ipconnect.de> has joined #yocto | 05:00 | |
| *** ibinderwolf <ibinderwolf!~quassel@etrn.topcontrol.it> has joined #yocto | 05:12 | |
| *** gtristan <gtristan!~tristanva@110.11.227.177> has joined #yocto | 05:21 | |
| *** jobroe <jobroe!~manjaro-u@p579eb9c9.dip0.t-ipconnect.de> has joined #yocto | 05:29 | |
| *** jobroe <jobroe!~manjaro-u@p579eb9c9.dip0.t-ipconnect.de> has quit IRC | 05:31 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:32 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 05:33 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 05:44 | |
| *** pohly <pohly!~pohly@p5484925f.dip0.t-ipconnect.de> has joined #yocto | 05:52 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 06:02 | |
| *** kroon_ <kroon_!~kroon@213.185.29.22> has joined #yocto | 06:09 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 06:11 | |
| *** kroon_ is now known as kroon | 06:12 | |
| *** kaspter <kaspter!~Instantbi@222.70.81.223> has quit IRC | 06:16 | |
| *** kaspter <kaspter!~Instantbi@222.70.81.215> has joined #yocto | 06:16 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.75.30> has quit IRC | 06:27 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.101.32> has joined #yocto | 06:27 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 06:39 | |
| *** camus1 <camus1!~Instantbi@222.70.81.215> has joined #yocto | 06:46 | |
| *** kaspter <kaspter!~Instantbi@222.70.81.215> has quit IRC | 06:46 | |
| *** camus1 is now known as kaspter | 06:46 | |
| *** sagner <sagner!~ags@2a02:169:3df5:0:e84:c285:65c9:b02e> has quit IRC | 06:52 | |
| *** sagner <sagner!~ags@2a02:169:3df5::edf> has joined #yocto | 06:52 | |
| *** mckoan|away is now known as mckoan | 06:57 | |
| mckoan | good morning | 06:57 |
|---|---|---|
| PaowZ | 'mornin | 06:57 |
| *** camus1 <camus1!~Instantbi@222.70.81.217> has joined #yocto | 07:10 | |
| *** kaspter <kaspter!~Instantbi@222.70.81.215> has quit IRC | 07:11 | |
| *** camus1 is now known as kaspter | 07:11 | |
| *** neheist <neheist!~neheist@117.203.43.69> has joined #yocto | 07:17 | |
| *** kaspter <kaspter!~Instantbi@222.70.81.217> has quit IRC | 07:23 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has joined #yocto | 07:23 | |
| *** camus1 <camus1!~Instantbi@222.67.152.154> has joined #yocto | 07:33 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has quit IRC | 07:33 | |
| *** camus1 is now known as kaspter | 07:33 | |
| *** nameclash <nameclash!~nameclash@ip1f11b23e.dynamic.kabel-deutschland.de> has joined #yocto | 07:36 | |
| *** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 07:39 | |
| *** amerigo <amerigo!uid331857@gateway/web/irccloud.com/x-wsbdhauypxlavjby> has joined #yocto | 07:50 | |
| *** goliath <goliath!~goliath@82.150.214.1> has joined #yocto | 08:05 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:06 | |
| *** neheist <neheist!~neheist@thunix.net> has joined #yocto | 08:17 | |
| *** camus1 <camus1!~Instantbi@222.70.81.228> has joined #yocto | 08:21 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has quit IRC | 08:22 | |
| *** camus1 is now known as kaspter | 08:22 | |
| *** vicale <vicale!~vicale@dyn-13-cust157.netit.se> has quit IRC | 08:24 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 08:29 | |
| *** florian_kc is now known as florian | 08:39 | |
| *** nucatus <nucatus!~nucatus@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto | 08:43 | |
| nucatus | Hello! 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 |
| Letothe2nd | nucatus: so what is the question? | 08:47 |
| nucatus | what 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 |
| Letothe2nd | nucatus: it depends a bit, but (b) is a relatively common, non-conf-invasive approach | 08:47 |
| nucatus | is there a best practice for such customisations? | 08:48 |
| Letothe2nd | nucatus: you could even do modifications through overriding appends in the module recipe itself, if that suits your metadata layout better. | 08:49 |
| Letothe2nd | the best practise depends "TM" | 08:49 |
| *** lfa <lfa!~lfa@217.19.35.51> has joined #yocto | 08:50 | |
| Letothe2nd | if 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 |
| nucatus | Letothe2nd: they are tend to be more application dependent. The kernel module is added by an application recipe | 08:51 |
| nucatus | and I was thinking to have a meta-core/recipes-bsp/customisation.bbappend file | 08:52 |
| Letothe2nd | nucatus: given that still relatively coarse information, i would probably go for an append in the application layer, which triggers on machine | 08:52 |
| *** RP <RP!~RP@5751f4a1.skybroadband.com> has joined #yocto | 08:53 | |
| Letothe2nd | nucatus: if the application has an effect on the customization, its counter-productive to have the append in a lower (read: bsp or "core") layer | 08:53 |
| nucatus | but then how should I avoid polluting the application layer with machine specific code? | 08:54 |
| nucatus | I mean, the customisation is a prerequisite for the application recipe where the module is added | 08:55 |
| Letothe2nd | nucatus: 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 |
| nucatus | yeap, I see your point! And indeed, it makes sense | 08:57 |
| nucatus | yes, 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 way | 08:59 |
| Letothe2nd | nucatus: well, choose wisely then. | 08:59 |
| nucatus | Letothe2nd: cool! thanks for your time and answers! I appreciate your efforts!! | 09:01 |
| Letothe2nd | nucatus: have fun! | 09:01 |
| *** gtristan <gtristan!~tristanva@110.11.227.177> has quit IRC | 09:06 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-plvgjqphphcuxzvx> has joined #yocto | 09:07 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 09:14 | |
| *** neheist <neheist!~neheist@thunix.net> has quit IRC | 09:17 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has joined #yocto | 09:23 | |
| *** Moh3N <Moh3N!b23e5c1d@178.62.92.29> has joined #yocto | 09:48 | |
| Moh3N | hi , I want to have tftp in uboot, but my problem is that now I cant ping any device especialy my tftpserver !!! | 09:52 |
| Moh3N | how I can recognize that is my uboot have network driver ?? | 09:52 |
| Letothe2nd | Moh3N: by joining #u-boot :) | 09:54 |
| Moh3N | is there any chat room for uboot? | 09:56 |
| Letothe2nd | Moh3N: #u-boot | 09:56 |
| Moh3N | i cant join to this room!! | 09:56 |
| Letothe2nd | Moh3N: well maybe you need to register on freenode first, thats possible | 09:57 |
| Moh3N | I 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 |
| Moh3N | Letothe2nd thanks | 09:58 |
| Letothe2nd | Moh3N: again, this is very clearly an u-boot question. please use their channel and/or mailing list. | 09:59 |
| Moh3N | ok, excuseme.thank | 09:59 |
| *** Moh3N <Moh3N!b23e5c1d@178.62.92.29> has quit IRC | 10:00 | |
| *** creich_ <creich_!~creich@p200300f6af4eca108da27579f2181294.dip0.t-ipconnect.de> has quit IRC | 10:09 | |
| *** gtristan <gtristan!~tristanva@110.11.227.177> has joined #yocto | 10:09 | |
| *** hpsy <hpsy!~hpsy@85.203.15.116> has joined #yocto | 10:09 | |
| *** creich <creich!~creich@p200300f6af4eca10000000000000039b.dip0.t-ipconnect.de> has joined #yocto | 10:22 | |
| *** amerigo <amerigo!uid331857@gateway/web/irccloud.com/x-wsbdhauypxlavjby> has quit IRC | 10:25 | |
| *** creich <creich!~creich@p200300f6af4eca10000000000000039b.dip0.t-ipconnect.de> has quit IRC | 10:30 | |
| *** nucatus <nucatus!~nucatus@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC | 10:34 | |
| *** ant_home <ant_home!~ant__@host-79-40-119-117.business.telecomitalia.it> has quit IRC | 10:37 | |
| *** nucatus <nucatus!~nucatus@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto | 10:41 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has quit IRC | 10:42 | |
| *** kpo <kpo!~kpo@bwu34.internetdsl.tpnet.pl> has joined #yocto | 10:49 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.141.89> has joined #yocto | 10:56 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.141.89> has quit IRC | 10:58 | |
| *** hipr_C <hipr_C!~Thunderbi@89.187.178.3> has joined #yocto | 11:09 | |
| *** gtristan <gtristan!~tristanva@110.11.227.177> has quit IRC | 11:38 | |
| *** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has quit IRC | 11:43 | |
| *** creich <creich!~creich@p200300f6af4eca10000000000000039b.dip0.t-ipconnect.de> has joined #yocto | 11:45 | |
| *** berton <berton!~berton@181.220.84.90> has joined #yocto | 11:53 | |
| silviof | How 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 exception | 11:54 |
| silviof | ValueError: could not convert string to float: '78+netconf${TAG}'` | 11:54 |
| *** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has quit IRC | 11:54 | |
| Letothe2nd | silviof: well https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PV 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 |
| silviof | Hi 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!~paulg@135-23-37-86.cpe.pppoe.ca> has joined #yocto | 11:59 | |
| Letothe2nd | silviof: i guess its just some form of evaluation ordering problem | 12:00 |
| *** geheimnis` <geheimnis`!~geheimnis@23.226.237.192> has joined #yocto | 12:00 | |
| *** sagner <sagner!~ags@2a02:169:3df5::edf> has quit IRC | 12:04 | |
| *** sagner <sagner!~ags@2a02:169:3df5::587> has joined #yocto | 12:04 | |
| rburton | nothing should be treating the PV as a float, so maybe look at the stack to figure out where that is happening | 12:07 |
| rburton | PV is not special | 12:07 |
| silviof | AHHH thanks rburton dnsmasq calculates the download folder from a python one liner `http://www.thekelleys.org.uk/dnsmasq/${@['archive/', ''][float(d.getVar('PV').split('.')[1]) > 69]}dnsmasq-${PV}.tar.gz;name=dnsmasq-${PV}`. | 12:14 |
| rburton | that is just stupid :) | 12:15 |
| silviof | "Not the usual way." | 12:16 |
| rburton | if you want to fix that then setuptools includes a version parsing class | 12:21 |
| *** berton <berton!~berton@181.220.84.90> has quit IRC | 12:21 | |
| *** berton <berton!~berton@181.220.84.90> has joined #yocto | 12:22 | |
| *** gtristan <gtristan!~tristanva@110.11.227.189> has joined #yocto | 12:31 | |
| *** mcfrisk <mcfrisk!mcfrisk@kapsi.fi> has quit IRC | 12:39 | |
| *** mcfrisk <mcfrisk!mcfrisk@kapsi.fi> has joined #yocto | 12:39 | |
| *** nucatus <nucatus!~nucatus@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC | 12:41 | |
| *** nucatus_ <nucatus_!~nucatus@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto | 12:41 | |
| *** maudat <maudat!~moda@mtrlpq2848w-lp140-04-70-52-97-241.dsl.bell.ca> has joined #yocto | 12:43 | |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has joined #yocto | 13:00 | |
| *** kanavin_home <kanavin_home!~ak@5.28.66.228> has quit IRC | 13:08 | |
| *** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:b652:c378:b428:fdf> has joined #yocto | 13:10 | |
| *** sveinse <sveinse!~sveinse@7.92-221-150.customer.lyse.net> has joined #yocto | 13:13 | |
| sveinse | When looking at task-depends.dot 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 dunfell | 13:15 |
| Letothe2nd | sveinse: dependencies like what? | 13:16 |
| sveinse | Letothe2nd: Like an unexpected package being pulled in | 13:16 |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 13:17 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 13:17 | |
| qschulz | sveinse: dependencies of your dependencies probably? | 13:17 |
| 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) | 13:18 |
| sveinse | qschulz: task-depends.dot shows immediate dependencies, doesn't it? a -> b | 13:19 |
| sveinse | Or is bitbake unravel dependencies, e.g. if a -> b -> c, resulting in a -> b, a -> c, b -> c ? | 13:20 |
| sveinse | Hmm, not that would make the tree enormous | 13:20 |
| Letothe2nd | the task-depends.dot tree is ginormous.... | 13:22 |
| *** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 13:22 | |
| *** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-nzczakpprbfptvao> has joined #yocto | 13:23 | |
| *** ssajal <ssajal!~ssajal@otwaon1146w-lp140-01-64-229-138-221.dsl.bell.ca> has joined #yocto | 13:23 | |
| sveinse | Letothe2nd: Its 20 years too late to make Matrix jokes, but you have to look at task-depends.dot in code form because there is way too much information to decode it all. :P | 13:23 |
| RP | sveinse: it doesn't unravel like that, changing to that form would break things! | 13:23 |
| Letothe2nd | sveinse: i don't get the joke. for me its pretty common to look at it in code form. | 13:24 |
| sveinse | RP: thanks. Nor am I trying to. Just trying to figure out what and where the extra dependency is being added or injected | 13:25 |
| *** vmeson <vmeson!~rmacleod@192-0-133-244.cpe.teksavvy.com> has joined #yocto | 13:26 | |
| sveinse | Letothe2nd: 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 |
| Letothe2nd | sveinse: hehe i know what you mean. | 13:29 |
| *** NiksDev <NiksDev!~NiksDev@192.91.101.32> has quit IRC | 13:30 | |
| *** NiksDev <NiksDev!~NiksDev@192.91.75.30> has joined #yocto | 13:30 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 13:38 | |
| *** mihai- <mihai-!~mihai@unaffiliated/mihai> has joined #yocto | 13:49 | |
| *** ssajal <ssajal!~ssajal@otwaon1146w-lp140-01-64-229-138-221.dsl.bell.ca> has quit IRC | 13:52 | |
| *** leitao <leitao!~leitao@2620:10d:c093:400::5:b870> has joined #yocto | 13:53 | |
| *** AndersD <AndersD!~AndersD@h-17-226.A137.corp.bahnhof.se> has joined #yocto | 13:54 | |
| *** ssajal <ssajal!~ssajal@otwaon1146w-lp140-01-64-229-138-221.dsl.bell.ca> has joined #yocto | 13:58 | |
| *** sakoman <sakoman!~steve@rrcs-66-91-142-162.west.biz.rr.com> has joined #yocto | 13:59 | |
| PaowZ | question: do you see where it is stated where the lib is supposed to be delivered, in that recipe ? http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/opencv/opencv_4.3.0.bb?h=master | 14:03 |
| PaowZ | currently, yocto ships the lib in /usr/lib.. default opencv CMakeList.txt says it is in /usr/local.. | 14:04 |
| PaowZ | I can't find where /usr/lib comes from.. | 14:04 |
| sveinse | Any 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 sp-system.bb (verified by look at bitbake -e sp-system)? | 14:05 |
| Letothe2nd | PaowZ: hopefully /usr/lib comes from nowhere, its jetzt the generic prefix that yocto sets, and a proper CMakeLists adheres to it. | 14:05 |
| Letothe2nd | PaowZ: so if you've got something that has /usr/local hardcoded in it, then it is a bug. | 14:06 |
| *** Net147 <Net147!~Net147@119-18-5-146.771205.syd.nbn.aussiebb.net> has quit IRC | 14:07 | |
| PaowZ | Letothe2nd: tks for your reply.. interesting.. do you believe it is bug ? https://github.com/opencv/opencv/blob/master/CMakeLists.txt#L122 | 14:07 |
| qschulz | sveinse: 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 |
| Letothe2nd | PaowZ: nope. https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT.html | 14:09 |
| Letothe2nd | PaowZ: 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/local | 14:09 |
| sveinse | qschulz: 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 |
| Letothe2nd | PaowZ: and that is perfectly ok. | 14:10 |
| Letothe2nd | sveinse: 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 |
| Letothe2nd | sveinse: so case #3 | 14:11 |
| Letothe2nd | it seems. | 14:11 |
| PaowZ | ok.. 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 |
| qschulz | sveinse: 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 |
| qschulz | are you sure it's a build time dependency you're after? and not a runtime dependency? | 14:12 |
| sveinse | qschulz: I'm trying to hunt down _why_ the depencency exitst (it shouldn't be there), implicit og explicit | 14:13 |
| Letothe2nd | PaowZ: 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 |
| qschulz | sveinse: 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 question | 14:14 |
| qschulz | hard to find* | 14:14 |
| Letothe2nd | PaowZ: so my advice is to fix your whatever that tries to use it, instead of whacking libraries out of their standard locations. | 14:14 |
| smurray | sveinse: you can see what modifies DEPENDS in the "bitbake -e" output | 14:14 |
| qschulz | smurray: they've said already that DEPENDS does not have it :) | 14:15 |
| smurray | qschulz: yeah, I'm trying to decipher this backlog | 14:16 |
| Letothe2nd | sveinse: insert $BEER. often helps. | 14:16 |
| Letothe2nd | smurray: ^^^ | 14:16 |
| smurray | Letothe2nd: 10 am here, I've not even had coffee yet | 14:16 |
| sveinse | Letothe2nd: even on a Monday? | 14:16 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 14:16 | |
| Letothe2nd | smurray: yes and sveinse yes. | 14:16 |
| smurray | sveinse: what's the runtime dependency that's getting pulled in that you don't want? | 14:17 |
| PaowZ | Letothe2nd: 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 |
| Letothe2nd | PaowZ: 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/lib | 14:21 |
| Letothe2nd | PaowZ: 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@181.220.84.90> has quit IRC | 14:23 | |
| sveinse | RP: With all due respect, wrt unraveling I think maybe you're wrong. I dumped build/task-depends.dot 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 |
| sveinse | smurray: 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 guys | 14:29 |
| Letothe2nd | \m/ | 14:31 |
| RP | sveinse: that is correct but it does not mean its unravelling as you describe, its not. If it did, things would actually break | 14:31 |
| PaowZ | Letothe2nd: 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 how | 14:33 |
| PaowZ | I detect libs for linkage, after all.. | 14:33 |
| Letothe2nd | PaowZ: 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 |
| sveinse | RP: 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 |
| RP | sveinse: the types of dependencies we have make it very hard to give that information in a meaningful way :( | 14:36 |
| crazoes[m]1 | hello, 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]1 | ERROR: Can't get compiler version from gcc --version output | 14:36 |
| qschulz | sveinse: 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 |
| qschulz | crazoes[m]1: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#required-packages-for-the-build-host ? are they all there? Are you using a supported distro? | 14:37 |
| sveinse | RP: 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@85.203.15.116> has quit IRC | 14:38 | |
| RP | sveinse: indirect deps are likely from the rdeptask dependencies FWIW | 14:39 |
| sveinse | qschulz: 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 |
| qschulz | sveinse: when you render the graph, it should IIRC? but /me shrugs | 14:39 |
| sveinse | qschulz: let me check, perhaps there is a dot annotation I've missed | 14:40 |
| crazoes[m]1 | qschulz: 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 again | 14:42 |
| Letothe2nd | crazoes[m]1: archers usually resort to docker containers for building :) | 14:42 |
| crazoes[m]1 | gcc is in path, i can run gcc --version | 14:42 |
| Saur | qschulz, sveinse: There used to be such annotations in the recipe graph (if I remember correctly), but that graph is not produced anymore. | 14:43 |
| PaowZ | Letothe2nd: 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]1 | Letothe2nd: I see, I will try that out | 14:45 |
| qschulz | crazoes[m]1: kas or pyrex are two possibilities for building Yocto within docker | 14:45 |
| *** sgw <sgw!~sgw@134.134.139.72> has quit IRC | 14:47 | |
| crazoes[m]1 | qschulz: thanks, checking them out | 14:49 |
| *** sgw <sgw!~swold@c-71-238-119-71.hsd1.or.comcast.net> has joined #yocto | 14:50 | |
| qschulz | crazoes[m]1: https://www.youtube.com/watch?v=KJHJlOtTdaE for kas | 14:50 |
| Letothe2nd | qschulz: :) | 14:59 |
| *** vineela <vineela!~vtummala@134.134.139.72> has joined #yocto | 14:59 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 14:59 | |
| sveinse | Are 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 |
| qschulz | sveinse: 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@193.252.149.222> has joined #yocto | 15:03 | |
| sveinse | qschulz: 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 |
| sveinse | I 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 environment | 15:05 |
| *** sgw1 <sgw1!~sgw@134.134.139.76> has joined #yocto | 15:06 | |
| *** amerigo <amerigo!uid331857@gateway/web/irccloud.com/x-yunshjgsgtqjanbl> has joined #yocto | 15:23 | |
| *** Net147 <Net147!~Net147@119-18-5-146.771205.syd.nbn.aussiebb.net> has joined #yocto | 15:33 | |
| *** nucatus_ <nucatus_!~nucatus@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC | 15:33 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 15:34 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 15:34 | |
| *** AndersD <AndersD!~AndersD@h-17-226.A137.corp.bahnhof.se> has quit IRC | 15:34 | |
| *** lukma <lukma!~lukma@85-222-111-42.dynamic.chello.pl> has joined #yocto | 15:39 | |
| lukma | Dear Community, | 15:40 |
| lukma | Is there any issue - or recommendation to run the bitbake from shared topdir? | 15:40 |
| paulbarker | lukma: What do you mean by "shared topdir"? | 15:42 |
| *** Sandrita23 <Sandrita23!18ca2637@gateway/web/cgi-irc/kiwiirc.com/ip.24.202.38.55> has joined #yocto | 15:43 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 15:45 | |
| lukma | paulbarker: For example NFS | 15:46 |
| lukma | that ./build is in NFS mounted directory | 15:47 |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC | 15:47 | |
| paulbarker | lukma: Do you intend to have multiple instances of bitbake building at the same time? | 15:47 |
| lukma | build$ bitbake -DD core-image-foo | 15:47 |
| lukma | NOTE: Reconnecting to bitbake server... | 15:47 |
| lukma | NOTE: Previous bitbake instance shutting down?, waiting to retry... | 15:47 |
| lukma | paulbarker: No, I do want to run a bitbake in build which is on network disk | 15:48 |
| lukma | And only ./build is there, as e.g. tmp is mounted on the local disk | 15:48 |
| paulbarker | lukma: 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 that | 15:49 |
| RP | paulbarker: thanks again for the gitsm fix, I've merged it as testing seemed god! | 15:49 |
| RP | good! | 15:49 |
| mckoan | lukma: AFAIK bitbake doesn't like NFS, it won't work | 15:50 |
| lukma | So the build directory shall be on the local share ..... | 15:52 |
| Letothe2nd | s/local share/local storage/g | 15:52 |
| lukma | BTW: Is it now possible to run two instances of bitbake? | 15:59 |
| lukma | for two distinct yocto builds? | 15:59 |
| lukma | (like one is sumo and other is zeus) | 15:59 |
| mckoan | lukma: yes in two different installation trees | 16:00 |
| lukma | mckoan: you mean two separate directories -> like PROJ1 and PROJ2 (and they don't use any common sstate caches) | 16:01 |
| mckoan | lukma: you can share the sstate | 16:04 |
| mckoan | lukma: however would be better if you explain what you want to get instead of giving a drop of info each time | 16:04 |
| lukma | mckoan: I do have a container | 16:06 |
| lukma | which has some directories bind | 16:06 |
| lukma | it emulates Ubuntu 16.04 lts | 16:07 |
| lukma | I'm wondering if I shall be prepared for any extra issues | 16:07 |
| lukma | when I would like to build two projects in the same time | 16:07 |
| lukma | those project are placed in to two different directories PROJ1 , PROJ2 | 16:07 |
| lukma | (separate build, sstate-cache) | 16:08 |
| lukma | PROJ1 is THUD, PROJ2 is SUMO | 16:08 |
| lukma | is it possible to connect to the container with two shells and build those two projects in the same time | 16:08 |
| paulbarker | lukma: Sounds fine as long as each project has its own TOPDIR, cache and TMPDIR | 16:11 |
| paulbarker | (I can never remember the variable that sets the cache directory path) | 16:11 |
| qschulz | and 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@189.154.1.55> has joined #yocto | 16:14 | |
| *** alejandrohs <alejandrohs!~alejandro@189.154.223.206> has quit IRC | 16:15 | |
| JPEW | RP, sakoman: Does https://bugzilla.yoctoproject.org/show_bug.cgi?id=13724 need backported to dunfell? | 16:15 |
| lukma | paulbaker: then I shall be fine :) | 16:19 |
| lukma | Thanks for help | 16:19 |
| sakoman | JPEW: 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!~nameclash@ip1f11b23e.dynamic.kabel-deutschland.de> has quit IRC | 16:27 | |
| RP | sakoman: its a fairly heavy change to bitbake :/ | 16:35 |
| JPEW | sakoman: Ya, it also means oe-core would require the latest bitbake | 16:35 |
| JPEW | Or the latest branch of bitbake? | 16:36 |
| JPEW | bitbake is backward compatible with older oe-core, but the reverse is not true | 16:36 |
| sakoman | That sounds like a fairly significant downside! | 16:36 |
| sakoman | How common/painful is the issue being fixed? | 16:37 |
| JPEW | sakoman: 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 broken | 16:38 |
| JPEW | We didn't for a while :) | 16:38 |
| RP | Its more that people just haven't found this particular use case | 16:39 |
| sakoman | Given the intrusiveness of bitbake changes I'm inclined to say no . . . | 16:40 |
| JPEW | sakoman: That's fair. I figured I'd point it out :) | 16:40 |
| sakoman | I appreciate that! It is so easy to miss stuff | 16:40 |
| JPEW | RP: Also reminds me, do we need to bump some minimum-bitbake-version in oe-core? | 16:42 |
| *** nucatus <nucatus!~nucatus@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto | 16:42 | |
| RP | JPEW: probably, yes, and the versions in bitbake | 16:43 |
| *** mckoan is now known as mckoan|away | 16:47 | |
| *** nucatus <nucatus!~nucatus@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC | 16:49 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:50 | |
| *** nerdboy <nerdboy!~sarnold@47.143.129.44> has quit IRC | 16:51 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 16:51 | |
| *** nucatus <nucatus!~nucatus@lns-bzn-40-82-251-130-58.adsl.proxad.net> has joined #yocto | 16:55 | |
| *** leitao <leitao!~leitao@2620:10d:c093:400::5:b870> has quit IRC | 16:58 | |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 17:12 | |
| *** hpsy <hpsy!~hpsy@85.203.15.116> has joined #yocto | 17:14 | |
| *** rcoote <rcoote!~rcoote@221-224-024-217.ip-addr.vsenet.de> has quit IRC | 17:25 | |
| *** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has joined #yocto | 17:54 | |
| *** Sandrita23 <Sandrita23!18ca2637@gateway/web/cgi-irc/kiwiirc.com/ip.24.202.38.55> has quit IRC | 17:59 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d154318.dynamic.kabel-deutschland.de> has quit IRC | 18:05 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d154318.dynamic.kabel-deutschland.de> has joined #yocto | 18:05 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 18:13 | |
| *** Dracos-Carazza_ <Dracos-Carazza_!~Dracos-Ca@ip4d154318.dynamic.kabel-deutschland.de> has joined #yocto | 18:18 | |
| *** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@ip4d154318.dynamic.kabel-deutschland.de> has quit IRC | 18:18 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-plvgjqphphcuxzvx> has quit IRC | 18:20 | |
| *** Dracos-Carazza_ is now known as Dracos-Carazza | 18:28 | |
| *** ericch <ericch!~ericch@pool-108-34-251-214.prvdri.fios.verizon.net> has quit IRC | 18:30 | |
| *** pascu <pascu!56047422@cpc90280-cove16-2-0-cust33.3-1.cable.virginm.net> has joined #yocto | 18:35 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 18:38 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 18:38 | |
| *** pascu <pascu!56047422@cpc90280-cove16-2-0-cust33.3-1.cable.virginm.net> has quit IRC | 18:40 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto | 18:42 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC | 19:00 | |
| *** nucatus <nucatus!~nucatus@lns-bzn-40-82-251-130-58.adsl.proxad.net> has quit IRC | 19:05 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 19:07 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 19:07 | |
| *** vineela <vineela!~vtummala@134.134.139.72> has quit IRC | 19:07 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 19:08 | |
| *** Sandrita <Sandrita!18ca2637@gateway/web/cgi-irc/kiwiirc.com/ip.24.202.38.55> has joined #yocto | 19:25 | |
| *** vineela <vineela!~vtummala@134.134.139.76> has joined #yocto | 19:39 | |
| *** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has quit IRC | 20:13 | |
| *** alejandr1 <alejandr1!~alejandro@189.154.1.55> has quit IRC | 20:14 | |
| *** jkridner|pd <jkridner|pd!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 20:14 | |
| *** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has joined #yocto | 20:14 | |
| *** hipr_C <hipr_C!~Thunderbi@89.187.178.3> has quit IRC | 20:15 | |
| *** vineela <vineela!~vtummala@134.134.139.76> has quit IRC | 20:19 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:5030:aa9f:23eb:a3d9> has quit IRC | 20:21 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:f4e2:b142:af1d:6837> has joined #yocto | 20:23 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 20:29 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 20:36 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has joined #yocto | 20:38 | |
| JPEW | RP: Before I lie on my presentation: The reproducible builds test is only done for i386 and x86_64? | 20:39 |
| RP | JPEW: just x86_64 | 20:39 |
| JPEW | RP: Thanks | 20:40 |
| * RP waits for rburton to read that | 20:40 | |
| JPEW | AArch64 would be nice to test also :) | 20:41 |
| *** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC | 20:47 | |
| *** pohly <pohly!~pohly@p5484925f.dip0.t-ipconnect.de> has quit IRC | 20:53 | |
| *** vineela <vineela!vtummala@nat/intel/x-yzbehzoybrgcipal> has joined #yocto | 21:28 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 21:38 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 21:38 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has joined #yocto | 21:38 | |
| jonmason | is anyone using meta-zephyr? | 21:49 |
| *** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:b652:c378:b428:fdf> has quit IRC | 21:57 | |
| *** kanavin_home <kanavin_home!~ak@2a02:2450:1011:56f:b652:c378:b428:fdf> has joined #yocto | 21:59 | |
| *** sgw <sgw!~swold@c-71-238-119-71.hsd1.or.comcast.net> has quit IRC | 21:59 | |
| *** sgw <sgw!~swold@c-71-238-119-71.hsd1.or.comcast.net> has joined #yocto | 22:01 | |
| *** vineela <vineela!vtummala@nat/intel/x-yzbehzoybrgcipal> has quit IRC | 22:33 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC | 22:48 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 22:48 | |
| *** vineela <vineela!~vtummala@134.134.137.77> has joined #yocto | 22:54 | |
| *** amerigo <amerigo!uid331857@gateway/web/irccloud.com/x-yunshjgsgtqjanbl> has quit IRC | 23:25 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 23:44 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.197.211> has quit IRC | 23:46 | |
| *** linuxjacques is now known as jacques | 23:51 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC | 23:59 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!