**** BEGIN LOGGING AT Mon Jun 15 02:59:58 2020 Jun 15 06:57:21 good morning Jun 15 06:57:33 'mornin Jun 15 08:45:30 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. Jun 15 08:47:07 nucatus: so what is the question? Jun 15 08:47:09 what is the best place to make such customisation? (a) the -extra.conf file (b) *.bbappend file that is set to be compatible with a specific machine? Jun 15 08:47:54 nucatus: it depends a bit, but (b) is a relatively common, non-conf-invasive approach Jun 15 08:48:59 is there a best practice for such customisations? Jun 15 08:49:23 nucatus: you could even do modifications through overriding appends in the module recipe itself, if that suits your metadata layout better. Jun 15 08:49:53 the best practise depends "TM" Jun 15 08:50:32 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. Jun 15 08:51:39 Letothe2nd: they are tend to be more application dependent. The kernel module is added by an application recipe Jun 15 08:52:43 and I was thinking to have a meta-core/recipes-bsp/customisation.bbappend file Jun 15 08:52:59 nucatus: given that still relatively coarse information, i would probably go for an append in the application layer, which triggers on machine Jun 15 08:53:48 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 Jun 15 08:54:54 but then how should I avoid polluting the application layer with machine specific code? Jun 15 08:55:49 I mean, the customisation is a prerequisite for the application recipe where the module is added Jun 15 08:56:08 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. Jun 15 08:57:52 yeap, I see your point! And indeed, it makes sense Jun 15 08:59:07 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 Jun 15 08:59:32 nucatus: well, choose wisely then. Jun 15 09:01:08 Letothe2nd: cool! thanks for your time and answers! I appreciate your efforts!! Jun 15 09:01:28 nucatus: have fun! Jun 15 09:52:21 hi , I want to have tftp in uboot, but my problem is that now I cant ping any device especialy my tftpserver !!! Jun 15 09:52:39 how I can recognize that is my uboot have network driver ?? Jun 15 09:54:05 Moh3N: by joining #u-boot :) Jun 15 09:56:21 is there any chat room for uboot? Jun 15 09:56:33 Moh3N: #u-boot Jun 15 09:56:51 i cant join to this room!! Jun 15 09:57:27 Moh3N: well maybe you need to register on freenode first, thats possible Jun 15 09:58:15 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 ? Jun 15 09:58:30 Letothe2nd thanks Jun 15 09:59:15 Moh3N: again, this is very clearly an u-boot question. please use their channel and/or mailing list. Jun 15 09:59:42 ok, excuseme.thank Jun 15 11:54:10 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 Jun 15 11:54:10 ValueError: could not convert string to float: '78+netconf${TAG}'` Jun 15 11:57:00 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. Jun 15 11:59:22 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. Jun 15 12:00:05 silviof: i guess its just some form of evaluation ordering problem Jun 15 12:07:13 nothing should be treating the PV as a float, so maybe look at the stack to figure out where that is happening Jun 15 12:07:29 PV is not special Jun 15 12:14:36 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}`. Jun 15 12:15:05 that is just stupid :) Jun 15 12:16:04 "Not the usual way." Jun 15 12:21:15 if you want to fix that then setuptools includes a version parsing class Jun 15 13:15:31 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 Jun 15 13:16:01 sveinse: dependencies like what? Jun 15 13:16:31 Letothe2nd: Like an unexpected package being pulled in Jun 15 13:17:55 sveinse: dependencies of your dependencies probably? Jun 15 13:18:40 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) Jun 15 13:19:03 qschulz: task-depends.dot shows immediate dependencies, doesn't it? a -> b Jun 15 13:20:22 Or is bitbake unravel dependencies, e.g. if a -> b -> c, resulting in a -> b, a -> c, b -> c ? Jun 15 13:20:51 Hmm, not that would make the tree enormous Jun 15 13:22:02 the task-depends.dot tree is ginormous.... Jun 15 13:23:44 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 Jun 15 13:23:57 sveinse: it doesn't unravel like that, changing to that form would break things! Jun 15 13:24:40 sveinse: i don't get the joke. for me its pretty common to look at it in code form. Jun 15 13:25:09 RP: thanks. Nor am I trying to. Just trying to figure out what and where the extra dependency is being added or injected Jun 15 13:26:38 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) Jun 15 13:29:46 sveinse: hehe i know what you mean. Jun 15 14:03:10 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 Jun 15 14:04:03 currently, yocto ships the lib in /usr/lib.. default opencv CMakeList.txt says it is in /usr/local.. Jun 15 14:04:18 I can't find where /usr/lib comes from.. Jun 15 14:05:22 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)? Jun 15 14:05:50 PaowZ: hopefully /usr/lib comes from nowhere, its jetzt the generic prefix that yocto sets, and a proper CMakeLists adheres to it. Jun 15 14:06:08 PaowZ: so if you've got something that has /usr/local hardcoded in it, then it is a bug. Jun 15 14:07:47 Letothe2nd: tks for your reply.. interesting.. do you believe it is bug ? https://github.com/opencv/opencv/blob/master/CMakeLists.txt#L122 Jun 15 14:08:06 sveinse: check the DEPENDS/PACKAGECONFIG on the dependent recipes until you find it :) start from the one you know (the ones for sp-system) Jun 15 14:09:05 PaowZ: nope. https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT.html Jun 15 14:09:52 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 Jun 15 14:09:56 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 " Jun 15 14:10:05 PaowZ: and that is perfectly ok. Jun 15 14:11:38 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) Jun 15 14:11:42 sveinse: so case #3 Jun 15 14:11:45 it seems. Jun 15 14:11:59 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 ? Jun 15 14:12:20 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 :/ Jun 15 14:12:48 are you sure it's a build time dependency you're after? and not a runtime dependency? Jun 15 14:13:33 qschulz: I'm trying to hunt down _why_ the depencency exitst (it shouldn't be there), implicit og explicit Jun 15 14:14:02 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. Jun 15 14:14:39 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 Jun 15 14:14:46 hard to find* Jun 15 14:14:55 PaowZ: so my advice is to fix your whatever that tries to use it, instead of whacking libraries out of their standard locations. Jun 15 14:14:56 sveinse: you can see what modifies DEPENDS in the "bitbake -e" output Jun 15 14:15:40 smurray: they've said already that DEPENDS does not have it :) Jun 15 14:16:04 qschulz: yeah, I'm trying to decipher this backlog Jun 15 14:16:19 sveinse: insert $BEER. often helps. Jun 15 14:16:24 smurray: ^^^ Jun 15 14:16:40 Letothe2nd: 10 am here, I've not even had coffee yet Jun 15 14:16:40 Letothe2nd: even on a Monday? Jun 15 14:16:57 smurray: yes and sveinse yes. Jun 15 14:17:32 sveinse: what's the runtime dependency that's getting pulled in that you don't want? Jun 15 14:19:40 Letothe2nd: FHS.. ok.. that means I have to make my CMakeLists.txt comply with FHS .. strange opencv path is not /usr/lib by default.. Jun 15 14:21:22 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 Jun 15 14:22:54 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. Jun 15 14:25:17 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. Jun 15 14:29:26 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 Jun 15 14:31:13 \m/ Jun 15 14:31:16 sveinse: that is correct but it does not mean its unravelling as you describe, its not. If it did, things would actually break Jun 15 14:33:05 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 Jun 15 14:33:05 I detect libs for linkage, after all.. Jun 15 14:35:04 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. Jun 15 14:35:19 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 ? Jun 15 14:36:12 sveinse: the types of dependencies we have make it very hard to give that information in a meaningful way :( Jun 15 14:36:21 hello, i've been trying to build image myself. seems like bitbake server doesn't start: Jun 15 14:36:21 --- Starting bitbake server pid 1959717 at 2020-06-15 20:04:09.366995 --- Jun 15 14:36:21 ERROR: Can't get compiler version from gcc --version output Jun 15 14:36:57 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 :/ Jun 15 14:37:41 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? Jun 15 14:38:03 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 :( Jun 15 14:38:52 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. Jun 15 14:39:07 sveinse: indirect deps are likely from the rdeptask dependencies FWIW Jun 15 14:39:09 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. Jun 15 14:39:57 sveinse: when you render the graph, it should IIRC? but /me shrugs Jun 15 14:40:17 qschulz: let me check, perhaps there is a dot annotation I've missed Jun 15 14:42:12 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 Jun 15 14:42:45 crazoes[m]1: archers usually resort to docker containers for building :) Jun 15 14:42:57 gcc is in path, i can run gcc --version Jun 15 14:43:01 qschulz, sveinse: There used to be such annotations in the recipe graph (if I remember correctly), but that graph is not produced anymore. Jun 15 14:43:29 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.. :) Jun 15 14:45:25 Letothe2nd: I see, I will try that out Jun 15 14:45:56 crazoes[m]1: kas or pyrex are two possibilities for building Yocto within docker Jun 15 14:49:18 qschulz: thanks, checking them out Jun 15 14:50:55 crazoes[m]1: https://www.youtube.com/watch?v=KJHJlOtTdaE for kas Jun 15 14:59:06 qschulz: :) Jun 15 15:00:50 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? Jun 15 15:03:02 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) Jun 15 15:04:41 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. Jun 15 15:05:59 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 Jun 15 15:40:15 Dear Community, Jun 15 15:40:15 Is there any issue - or recommendation to run the bitbake from shared topdir? Jun 15 15:42:34 lukma: What do you mean by "shared topdir"? Jun 15 15:46:49 paulbarker: For example NFS Jun 15 15:47:13 that ./build is in NFS mounted directory Jun 15 15:47:35 lukma: Do you intend to have multiple instances of bitbake building at the same time? Jun 15 15:47:43 build$ bitbake -DD core-image-foo Jun 15 15:47:43 NOTE: Reconnecting to bitbake server... Jun 15 15:47:43 NOTE: Previous bitbake instance shutting down?, waiting to retry... Jun 15 15:48:16 paulbarker: No, I do want to run a bitbake in build which is on network disk Jun 15 15:48:36 And only ./build is there, as e.g. tmp is mounted on the local disk Jun 15 15:49:11 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 Jun 15 15:49:48 paulbarker: thanks again for the gitsm fix, I've merged it as testing seemed god! Jun 15 15:49:51 good! Jun 15 15:50:18 lukma: AFAIK bitbake doesn't like NFS, it won't work Jun 15 15:52:04 So the build directory shall be on the local share ..... Jun 15 15:52:51 s/local share/local storage/g Jun 15 15:59:22 BTW: Is it now possible to run two instances of bitbake? Jun 15 15:59:32 for two distinct yocto builds? Jun 15 15:59:41 (like one is sumo and other is zeus) Jun 15 16:00:26 lukma: yes in two different installation trees Jun 15 16:01:12 mckoan: you mean two separate directories -> like PROJ1 and PROJ2 (and they don't use any common sstate caches) Jun 15 16:04:15 lukma: you can share the sstate Jun 15 16:04:54 lukma: however would be better if you explain what you want to get instead of giving a drop of info each time Jun 15 16:06:25 mckoan: I do have a container Jun 15 16:06:38 which has some directories bind Jun 15 16:07:02 it emulates Ubuntu 16.04 lts Jun 15 16:07:14 I'm wondering if I shall be prepared for any extra issues Jun 15 16:07:25 when I would like to build two projects in the same time Jun 15 16:07:50 those project are placed in to two different directories PROJ1 , PROJ2 Jun 15 16:08:05 (separate build, sstate-cache) Jun 15 16:08:15 PROJ1 is THUD, PROJ2 is SUMO Jun 15 16:08:46 is it possible to connect to the container with two shells and build those two projects in the same time Jun 15 16:11:17 lukma: Sounds fine as long as each project has its own TOPDIR, cache and TMPDIR Jun 15 16:11:30 (I can never remember the variable that sets the cache directory path) Jun 15 16:13:09 and DEPLOY_DIR I'd say as well? basically everything except SSTATE_DIR AND DL_DIR should be on different paths? Jun 15 16:15:59 RP, sakoman: Does https://bugzilla.yoctoproject.org/show_bug.cgi?id=13724 need backported to dunfell? Jun 15 16:19:06 paulbaker: then I shall be fine :) Jun 15 16:19:13 Thanks for help Jun 15 16:25:09 JPEW: Good question, since it is a bug fix I would assume the answer is yes. Are there any possible downsides to taking these? Jun 15 16:35:35 sakoman: its a fairly heavy change to bitbake :/ Jun 15 16:35:53 sakoman: Ya, it also means oe-core would require the latest bitbake Jun 15 16:36:08 Or the latest branch of bitbake? Jun 15 16:36:32 bitbake is backward compatible with older oe-core, but the reverse is not true Jun 15 16:36:46 That sounds like a fairly significant downside! Jun 15 16:37:07 How common/painful is the issue being fixed? Jun 15 16:38:43 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 Jun 15 16:38:52 We didn't for a while :) Jun 15 16:39:11 Its more that people just haven't found this particular use case Jun 15 16:40:24 Given the intrusiveness of bitbake changes I'm inclined to say no . . . Jun 15 16:40:41 sakoman: That's fair. I figured I'd point it out :) Jun 15 16:40:57 I appreciate that! It is so easy to miss stuff Jun 15 16:42:21 RP: Also reminds me, do we need to bump some minimum-bitbake-version in oe-core? Jun 15 16:43:10 JPEW: probably, yes, and the versions in bitbake **** ENDING LOGGING AT Mon Jun 15 20:36:34 2020 **** BEGIN LOGGING AT Mon Jun 15 20:38:15 2020 Jun 15 20:39:33 RP: Before I lie on my presentation: The reproducible builds test is only done for i386 and x86_64? Jun 15 20:39:56 JPEW: just x86_64 Jun 15 20:40:05 RP: Thanks Jun 15 20:40:22 * RP waits for rburton to read that Jun 15 20:41:36 AArch64 would be nice to test also :) Jun 15 21:49:42 is anyone using meta-zephyr? **** ENDING LOGGING AT Tue Jun 16 03:06:37 2020