**** BEGIN LOGGING AT Tue Aug 08 03:00:01 2017 Aug 08 09:37:41 What does SRC_URI[md5sum] indicate if SRC_URI references more than one thing? A checksum across all of it combined - if so how is that combined? Aug 08 09:38:55 gunnarx: first entry. you can name the entries in src_uri and identify multiple checksums if you're downloading more than one tarball. Aug 08 09:38:59 You're supposed to provide checksums for each part separately according to the manual but not all recipes do that... Aug 08 09:39:09 for each *remote* part Aug 08 09:39:10 ah ok, first entry, thanks Aug 08 09:39:14 file: doesn't need a checksum Aug 08 09:39:32 a bit of magic though - maybe bad style to rely on that... Aug 08 09:39:47 OK, but actually file:// was what led me to start poking around Aug 08 09:40:05 see eg the libtirpc recipe Aug 08 09:40:22 I'm seeing WARNING Unable to get checksum for: (patch file) Aug 08 09:40:34 pastebin the srcuri? Aug 08 09:41:24 sure, I'll put together some info, hang on Aug 08 09:41:53 file:// doesn't need a checksum, but if you're fetching a patch over http or something then you need to specify it Aug 08 09:45:49 https://paste.fedoraproject.org/paste/no3AmNOgvHfRcqOABcZiKA Aug 08 09:46:22 Hmm "file could not be found" - is that the patch file itself, or is it expecting something like .patch.md5? Aug 08 09:47:07 oh Aug 08 09:47:13 the hint is, file not found Aug 08 09:47:20 its trying to checksum the file so it can tell if it changes Aug 08 09:47:30 ah, so it's the patch itself that is not found? Aug 08 09:47:34 totally unrelated to the src_uri checksums Aug 08 09:47:42 yes, file not found is the error Aug 08 09:47:48 ok that's weird Aug 08 09:48:15 anyhow, I learned a bit more about the checksum logic. :) Aug 08 09:48:51 so mismathced versions between meta-linaro and poky presumably Aug 08 09:49:59 but why... poky uses the patch, and provides it of course. Alright, guess this needs some. investigation Aug 08 09:50:16 thanks for helping, rburton Aug 08 09:53:16 gunnarx: meta-linaro probably has a bbappend that is breaking the recipe. Aug 08 09:56:18 Actually it has a .bb file ,binutils-cross_linaro-2.27.bb, which does nothing else than include (require) the three .inc files from poky, from what I can see Aug 08 10:04:41 gunnarx: is your meta-linaro up to date? There seems to be an obvious related change in June Aug 08 10:05:56 OK, thanks a lot - will ask someone else to look into this. Yes I'm looking at a system that is currently on April status of meta-linaro. Aug 08 10:07:08 tbh, I'm not sure if anyone did the upgrades to match our meta-linaro version with pyro. Therein lies some of the issues surely. Aug 08 10:12:32 jku, you're right the fix is right there in the meta-linaro log. Thanks. you've been more helpful than could be expected - let me return if there are still issues after the necessary work has been done here Aug 08 11:38:16 I have just build my first Yocto kernel for the CHIP PRO board. I have the kernel booted and I am now trying to get wifi up and running. When im trying to use the ifup or ifdown commands, I get 'unknown address type "inet" 'Have any of you had that problem? Aug 08 13:21:15 Axton: is this with busybox? do you have ipv4 in DISTRO_FEATURES? Aug 08 15:26:27 hey folks, I've got two different recieps spec'ing two different versions of a software, is it okay to put the PREFERRED_VERSIONS in the meta-user/conf/layer.conf file? Or is this bad practice? Aug 08 15:57:06 mcarss: you could control the default by using DEFAULT_PREFERENCE variable with in the competing recipes Aug 08 15:57:29 binding it in config metadata is better left to ditros Aug 08 15:58:33 look into examples where a package is setting DEFAULT_PREFERENCE = "-1", which means prefer the other one Aug 08 15:58:58 that assumes that recipes for both versions are in the same layer Aug 08 15:59:52 if meta-user has different version for something which otherwise lives in e.g. oe-core then DEFAULT_PREFERENCE wont work and the version from layer with higher priority will be used (older or newer doesn't matter) Aug 08 16:03:23 yes and expected Aug 08 16:04:25 priorities are there for such things even though they are losely used in layer mix Aug 08 16:06:48 khem, JaMA, so I have 1 layer with a recipe that spec's a given version of the SW, and then a support recipe within the meta-user layer that spec's another version of the SW. I am trying to use the latter version Aug 08 16:08:55 mcarss: if they are coming from two different layers then you have to specify it in distro policy Aug 08 16:09:05 may be in your distro.conf or local.conf Aug 08 16:10:21 you can also add checks in the second piece of software that the first is of the expected version -- (preferred version or otherwise) and then if not blacklist the second one to prevent it from producing a compilation failure or incorrect configuration. Aug 08 16:12:06 oh well, it worked when I set it in the meta-user layer.conf, but I could do it in the machine conf Aug 08 16:17:35 it will work in the layer.conf, but it limits other uses and if Yocto Project compliance is a requirement for you, it would likely fail the testing Aug 08 16:18:07 One of the tests is to see if just including a layer modifies the system configuration. If it doesn, then you need to fix it.. Aug 08 16:18:38 (including a layer CAN add changes to recipes via .bbappends and such... but system configurations, like preferred versions and such should only be set by the local.conf or the distro.conf that user has selected Aug 08 16:19:06 yeah, that's reasonable, I think for now I'll go with the distro conf Aug 08 16:19:14 I would expect the next generation of yocto project compliance tests may do additional checking on the .bbappends BTW.. Aug 08 16:19:40 the goal is to allow users to include layers without unexpected (or difficult to disable) side-effects Aug 08 16:21:04 Yep that's definitely important Aug 08 16:23:16 i jumped to a wrong conclusion yesterday regarding devtool. the documentation is much better than i'd thought. my apologies for poo-pooing it yesterday. Aug 08 16:28:17 i was told that i could find which .dts/dtsi files are being used when i "unpack the source with devtool". i've performed a "devtool modify -x recipe" step, so how do i trace which files are being pulled into the build? Aug 08 16:33:06 with or without devtool, how do i find out which dts/dtsi files are being pulled into the build? Aug 08 16:33:41 in the old days, with gnumake, i would find the target and trace from there, or just run the build and watch which files are getting compiled... Aug 08 16:35:46 the scenario is this: we need to modify the muxing, direction, etc. of some signals from an existing build to our own custom build. but apparently the existing build's configuration (dts[i]) have already been submitted to the kernel upstream, so they show up (along with everything else) in the kernel source tree directly. Aug 08 16:35:57 fray, khem, so I tried using the distro conf, but unfortunately that file is changed and the preferred_version line gets deleted when running the configuration script (petalinux-config specifically), not sure if this is really a yocto question, but I don't know that the machine conf will work for me Aug 08 16:39:23 are my questions a) unclear, b) too hard to answer, or c) unworthy of answering? Aug 08 16:58:16 thanks Aug 08 17:10:18 mcarss: see if you can add it to local.conf Aug 08 17:10:26 its a workspace setup issue Ithink Aug 08 17:10:33 which could be specific to petalinux Aug 08 17:12:37 khem, so local.conf would work but it's located in the build folder and again is re-generated, it doesn't seem to be a good place to store if especially when trying to have a git repo which ideally shouldn't have a build folder Aug 08 17:16:02 mcarss: somewhere the config metadata should be allowing you to have static files Aug 08 17:51:00 Is it possible to add a new bitbake fetcher without adding it to poky (i.e. outside the poky repo)? Aug 08 18:00:38 jpew: the poky repo is just bitbake+oe-core+meta-yocto Aug 08 18:00:43 it doesn't have or need its own content Aug 08 18:01:10 so yesa nd no. you dont' add it to poky, but if youa dd it to bitbake, where it belongs, it'll still end up available via the poky repo as well regardless Aug 08 18:01:29 but it is possible to add a bitbake fetcher outside of bitbake itself, and inject it via a bbclass. i.e. see the old bitbake-npm layer Aug 08 18:01:46 would need to know more about what you're really asking to clarify any further Aug 08 18:02:06 kergoth: yes thats what I was wondering. I will look at the bitbake-npm layer. Thanks Aug 08 18:03:38 jpew: it's just python and you can run python at various points from a class, so you basically just create a fetcher class for yourself and add it to bitbake's internal list of available fetchers, and your'e good to go Aug 08 18:03:54 that's what bitbake-npm did, to add an npm:// fetcher, before it went into bitbake proper Aug 08 18:05:48 Yes thats exactly what I want. I'll give it a try Aug 08 18:07:15 it can be nice either to stage something before it goes upstream, or for proprietary / internal fetch methods Aug 08 18:10:58 is there documentation on how to configure a linux-foo.bb file in meta-bar/recipes-kernel? Aug 08 18:11:09 e.g., what name should "foo" be? Aug 08 18:11:22 what does LOCALVERSION specify? (no hits in the manual) Aug 08 18:11:29 SRCBRANCH, etc. Aug 08 18:13:59 the recipe name is largely irrelevent, or just marketing. call it whatever you think is appropriate given where teh sources are coming from Aug 08 18:15:12 that's good to know. Aug 08 18:17:09 SRCBRANCH is just convention, you don't need to use it at all. i don't know where you're getting your kernel recipe from, but it's not a standard variable Aug 08 18:19:15 interesting. why put stuff in these files that don't matter?!? Aug 08 18:20:11 is is coming from the yocto project for the Variscite DART 6UL board, under sources/meta-variscite-fscl/recipes-kernel/linux Aug 08 18:21:12 you should ask the people that wrote the recipe, i'd say Aug 08 18:21:52 no argument there.. Aug 08 18:37:52 so what is LOCALVERSION? Aug 08 18:55:40 nm. got it. Aug 08 19:02:41 if you source oe-init-build-env build-xyz, then what is the top-level recipe to bitbake there? Aug 08 19:09:50 what defines the potential images one can build there? Aug 08 19:18:05 ok that was in the manual. sorry. Aug 08 19:18:14 rtfm! Aug 08 19:35:54 Hi all! I got an issue with yocto pyro/do_rootfs and alsa-lib. Alsa-lib is compiled without errors, but for some reason it is not deb-packaged (although alsa-lib-dbg and alsa-lib-dev are), so do_rootfs fails with "Unable to locate package alsa-lib". My buildhost system is ubuntu 16.04 LTS. Anyone can encounter this too? Pointers welcome. Aug 08 19:51:09 it might be empty Aug 08 19:51:25 add ALLOW_EMPTY_${PN} = "1" in recipe and see if that helps Aug 08 19:54:01 if i have defined my own meta-bar/recipes-kernel/linux/linux-foo.bb, how do i specify it is used for the kernel when building a target in meta-bar/recipes-xyz/images/myimage.bb? Aug 08 19:54:27 khem: Thanks for the tip, I will try :) Aug 08 19:54:40 yates: PREFERRED_PROVIDER_virtual/kernel = "linux-foo" in the machine .conf Aug 08 20:03:43 kergoth: thank you. i see some .conf files with PREFERRED_PROVIDER_virtual/kernel_blah = "blech". what does the "kernel_blah" mean? Aug 08 20:03:56 see the bitbake user manual, specifically the sectiona bout OVERRIDES Aug 08 20:14:04 very good. Aug 08 20:15:46 in the case of PREFERRED_PROVIDER_virtual/kernel, is the MACHINEOVERRIDES applied? Aug 08 20:20:42 (or is it just the naked OVERRIDES?) Aug 08 20:25:17 does bitbake accrete OVERRIDES from all .bb files or is only the OVERRIDE defined in the local .bb file applied to variables in the .bb file? Aug 08 20:30:53 i guess it depends on the syntax used in the variable assignment? Aug 08 20:40:20 can any variable be suffixed with any of DISTROOVERRIDES, MACHINEOVERRIDES, OVERRIDES? thus the project designer must take care to ensure these are all unique? Aug 08 20:41:20 or does the override used depend on the variable? Aug 08 20:42:44 fray: any comments? Aug 08 20:45:58 can any variable be suffixed with any of DISTROOVERRIDES, MACHINEOVERRIDES, OVERRIDES? Aug 08 20:46:06 (and possibly others I've missed) Aug 08 20:46:35 yes.. overrides have no defined format.. just convention to avoid namespace collisions Aug 08 20:46:45 (well they do require them to be lowercase if I remember right) Aug 08 20:49:24 all these vars fold into OVERRIDES finally Aug 08 20:49:51 so whatever is in OVERRIDES seprated by : is effectively a possible value for override distinction Aug 08 20:51:52 i see Aug 08 21:02:29 khem: About my yocto pyro/alsa-lib/do_rootfs problem: Your tip helped/solved. Adding ALLOW_EMPTY_${PN} = "1" in recipe poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.3.bb did the trick. I am one step further. Thanks a lot and have a nice night/day :) Aug 08 21:06:26 Does ${B} and ${S} are actually the same directory ? Aug 08 21:07:29 ranran, not necessarily Aug 08 21:07:57 and for OE builds typically not, unless we force them due to a buggy build system in package Aug 08 21:09:09 Crofton - in kernel recipe I see : cp ${S}/arch/arm/configs/imx7_phyboard_zeta_defconfig ${B}/.config Aug 08 21:09:25 From this I assume that at least for kernel recipe they are the same ? Aug 08 21:10:10 Hello friendos. I am continuing my voyage to figure out u-boot in the Yocto universe. I see that my ./meta-fsl-arm-extra/conf/machine/wandboard.conf has the line 'UBOOT_MACHINE = "wandboard_config"', but I find no further references to that as a file or setting anywhere in the uBoot recipe. Can someone help me understand how that is de-obsfucated into an actual config when building uBoot? Aug 08 21:28:44 distrozapper: thats a bit of workaround though. A better solution would be to remove this library from IMAGE_INSTALL and instead add a RDEPEND for the alsalib package in the recipe of respective package which needs it Aug 08 21:29:13 that will also make the dependencies a bit more clearer Aug 08 21:29:42 majuk: this must be added by recipe via file:// Aug 08 21:30:44 IIRC for uboot UBOOT_MACHINE corresponded to a possible make configure target Aug 08 21:30:47 for uboot Aug 08 21:31:24 there must be a pre-existing defconfig for wandboard somehwere in tree after do_patch Aug 08 21:31:42 Yes, there is. Aug 08 21:32:25 how do i generate a defconfig? Aug 08 21:32:37 cp: cannot stat /home/yocto-project-x5-r1/sources/poky/build_x5/tmp/work/imx6ul_ebtron_x5-fslc-linux-gnueabi/linux-ebtron/1.0-r0/git/arch/arm/configs/imx6ul-ebtron-x5_defconfig: No such file or directory Aug 08 21:33:54 bitbake -c menuconfig ? Aug 08 21:46:10 khem: I see, so thanks for a working workaround AND a better understanding of the "yocto metabolism" ;) Aug 08 21:50:25 khem, ++ Aug 08 21:58:35 np Aug 08 21:59:07 yates: imx6ul-ebtron-x5_defconfig should either come from kernel tree or from yocto metadata Aug 08 22:03:31 khem: by "yocto metadata" you mean from a layer? e.g., meta-blah/recipes-kernel/linux/linux-foo/defconfig Aug 08 22:04:21 or more precisely, would it be meta-blah/recipes-kernel/linux/imx6ul-ebtron-x5/defconfig ? Aug 08 22:05:56 i can copy one of the existing freescale defconfig's, no need to run menuconfig Aug 08 22:09:21 if this file is under the yocto metadata, then where should it be placed? Aug 08 22:10:09 meta-ebtron/recipes-kernel/linux/imx6ul-ebtron-x5/defconfig didn't work. got the same "can't stat" message. Aug 08 22:14:04 yes file should be called imx6ul-ebtron-x5_defconfig Aug 08 22:14:23 khem: yeah, but where do i put it in the layer? Aug 08 22:15:35 that is, i presume yocto copies a file defconfig from somplace in the metadata to tmp/working/blah/imx6ul-ebtron-x5_defconfig, does it not? Aug 08 22:20:03 yates: depends on the recipe. the convention is usually to copy 'defconfig' from WORKDIR to .config, assuming file://defconfig is in SRC_URI, but not everything sticks to that, and some kernel recipes provide a variable to override the path to the defconfig Aug 08 22:20:42 how defconfig ends up as .config, with or without fragments, is not handled fully by the bbclasses, resulting in inconsistency between kernel recipes. Aug 08 22:33:45 here is my kernel recipe: https://da.gd/nFGTi -> https://paste.fedoraproject.org/paste/K3pt86dx4uSL~MBrWs-DWQ/ Aug 08 22:34:45 are the arguments to the "cp" command in the do_preconfigure_prepend() different than the normal linux cp, i.e., "cp 1 2" copies 2 to 1? Aug 08 22:35:10 it's just a shell script, running the same tools you already have on your linux machine Aug 08 22:35:36 regardless, i'd suggest reading recipes-kernel/linux/linux-imx.inc Aug 08 22:35:45 what is WORKDIR ? Aug 08 22:35:49 ok Aug 08 22:36:24 so it's the tmp/blah area Aug 08 22:36:30 ok, that makes more sense. Aug 08 22:38:43 kergoth: ok i read it. not much to it, and i don't see anything regarding defconfig: https://da.gd/aKkLV -> https://paste.fedoraproject.org/paste/0X7hMFaTNO48D-vcopCTrA/ Aug 08 22:39:32 correction: i see something there. Aug 08 22:42:02 what is line 14/15 doing there? Aug 08 22:43:01 i need to read the manual more - isee it is defined in there. **** ENDING LOGGING AT Wed Aug 09 02:59:59 2017