**** BEGIN LOGGING AT Fri Jul 06 03:00:01 2018 Jul 06 05:58:25 good morning/* Jul 06 05:59:11 i am reading yocto technical faq trying to undersand how oe-pkgdata-util list-pkgs works Jul 06 06:00:11 the example says: oe-pkgdata-util list-pkgs -p recipename Jul 06 06:00:24 what is 'recipename' in this context? Jul 06 06:01:43 and where is the 'pkgdata directory' for a recipe? Jul 06 06:02:56 or, if this directory is missing, how can it be created? Jul 06 06:05:08 i believe recipename is exactly what it says like in the target for bitbake Jul 06 06:09:30 recipe name is any of the .bb file e.g. foo_1.0.bb then recipename is foo Jul 06 06:10:07 pkgdata directory is created during build Jul 06 06:10:34 khem, but foo is also acceptable, right? Jul 06 06:10:34 its under TMPDIR Jul 06 06:10:45 yes foo is what you need to specify Jul 06 06:10:55 thank you Jul 06 06:11:10 let me try the pkgdata thing Jul 06 06:14:17 is there a manual for devtool or oe-pkgdata-util ? Jul 06 06:19:57 https://www.yoctoproject.org/docs/2.6/dev-manual/dev-manual.html#viewing-package-information-with-oe-pkgdata-util Jul 06 06:21:03 thank you very much, khem Jul 06 08:09:22 morning Jul 06 08:11:25 RP: good morning Jul 06 08:23:00 New news from stackoverflow: yocto recipe for an application that uses dlib and opencv Jul 06 08:50:43 Actually I was facing the following issue while building my Yocto SDK on Docker container Code: sudo docker build --tag="akash/eclipse-che:6.5.0-1" --tag="akash/eclipse-che:latest" /home/akash/dockerimage.yocto.support/ Sending build context to Docker daemon 26.93MB Step 1/5 : FROM eclipse/cpp_gcc ---> 8397ec8fd9d1 Step 2/5 : ENV META_TOOLCHAIN=poky-glibc-x86_64-meta-toolchain-cortexa7hf-neon-vfpv4-toolchain-2.4.3.sh ---> Usin Jul 06 08:51:35 Step 3/5 : RUN wget -O /tmp/$META_TOOLCHAIN "=$META_TOOLCHAIN" ---> Using cache ---> 674e007553da Step 4/5 : RUN chmod +x /tmp/$META_TOOLCHAIN ---> Using cache ---> 5f558946851e Step 5/5 : RUN /tmp/$META_TOOLCHAIN ---> Running in b5909d0fe10c Poky (Yocto Project Reference Distro) SDK installer version 2.4.3 ================================================================= You are about to install the SDK to Jul 06 08:52:31 Proceed[Y/n]? Extracting SDK.............done Setting it up...ls: cannot access '/home/akash/rpil/rpi-build/tmp/environment-setup-cortexa7hf-neon-vfpv4-poky-linux-gnueabi': No such file or directory SDK relocate failed, could not get executalbe files The command '/bin/sh -c /tmp/$META_TOOLCHAIN' returned a non-zero code: 1 Jul 06 08:54:20 Though environment setup-* is present in my tmp directory,it still shows that this file is not present. Jul 06 09:53:14 New news from stackoverflow: Is it possible to use Yocto Tool offline? Jul 06 13:26:31 does yocto provide a default-way to handle systemd drop-ins? Jul 06 13:54:08 packages? Jul 06 14:36:14 Hi All, I would like to add the ability to extract defconfig or .config file (on run-time) from my running yocto system. Does any of you have a suggestion on how to achieve that? Jul 06 14:37:40 I am aware of the yocto manual note which says that out-of-the-box, yocto never ships `defconfig` or `.config` file. However, I still want to do this. Jul 06 14:43:50 burakSenic: if you kernel has CONFIG_IKCONFIG enabled, then (at run-time, on the device) you can extract its configuration from /proc/config.gz Jul 06 14:44:06 bitbake -c configure and then do a bitbake -c devshell .. and copy the appropriate file someplace else Jul 06 14:45:39 tlwoerner: I already tried that, however, /proc/config.gz doesn't exist. As well as /boot/config-* doesn't appear in my image. Jul 06 14:46:29 jof: thank you for your response. I will try your suggestion. Jul 06 14:47:58 burakSenic: I think I may have misunderstood your question, though. What I was suggesting was getting it at build-time. Not runtime like you requested. Jul 06 14:50:45 jof: Gotcha! First, thank you for your support and clarifying your response! Yes, I am interested in runtime, but build-time may just do the trick for me. I need to have a look and test it. Jul 06 14:52:51 * zeddii_home waits to see if his new devsrc survives the multib configured build ….. running tasks (4009 of 8007) … it’ll be a bit yet :D Jul 06 15:04:22 zeddii_home: good luck! :) Jul 06 15:07:55 for whatever reason, my build machine seems to be crawling along … oh well Jul 06 15:08:50 zeddii_home: cold sstate from the vacation? Jul 06 15:09:00 its amazing how much sstate we reuse Jul 06 15:09:16 and that automake upgrade toasted it all Jul 06 15:09:59 burakSenic: if /proc/config.gz does not exist at runtime, then something is fishy wrt your kernel build configuration Jul 06 15:10:26 rburton: should I fire -next? Jul 06 15:10:36 rburton: I think I don't have the problematic bits of mut Jul 06 15:10:47 RP: give me a sec there's some more bits in mut now Jul 06 15:11:00 burakSenic: i.e. either CONFIG_IKCONFIG is not enabled in your build, or something is overriding it Jul 06 15:11:12 rburton: I added your two meson bits Jul 06 15:11:49 RP: you need to push then ;) also got two setuptools changes Jul 06 15:12:52 rburton: it is there! Jul 06 15:13:27 rburton: let me grab the other two Jul 06 15:17:32 Speaking of sstate, I had another go at the hash-equivalence based on RP's feedback. It's getting closer to something presentable if anyone want to take a look: poky-contrib/jpew/hash-equivalence Jul 06 15:17:50 Still not quite ready for the mailing list I think... Jul 06 15:20:32 tlwoerner: Thank you for following up. So, I generated my defconfig with `bitbake -c menuconfig linux`. This creates a .config file and yocto manual says one can directly copy this file and rename it as "defconfig". I did all these and check the generated .config file that I saved after I was done with menuconfig interface. The .config has CONFIG_IKCONFIG, CONFIG_IKCONFIG_PROC and the other flags that letter one of these depends on Jul 06 15:21:15 tlwoerner: Do you have any clue what can override this? Jul 06 15:30:20 JPEW: btw, if you want to send out some of the cleanups and keep the branch simpler I'm happy to take those Jul 06 15:31:22 RP: Ok, I'll do that Jul 06 15:32:09 JPEW: I usually do that myself to try and preserve sanity Jul 06 15:39:53 hello, I'm bumping Yocto layers and the kernel I'm using doesn't build with gcc7 (it's not an upstream kernel), is there a way to change the GCC version used? Jul 06 15:43:56 RP: Does bitbake-devel get pulled into OE-core contiuously like meta-oe, or just when bitbake has a release? Jul 06 15:44:29 poky master tracks oe-core master and bitbake master Jul 06 15:44:38 OK, thanks Jul 06 15:44:52 i suspect thats what you meant :) meta-oe isn't involved, and oe-core isn't a generated repo Jul 06 15:45:09 Oh, sorry, yes that is what I meant! Jul 06 15:47:42 JPEW: rburton beat me to it Jul 06 16:55:58 I'm using an ancient branch of poky (2.0) and running into the git deprecated argument "--set-upstream". Is there a way to patch git.py without forking the poky repo? Jul 06 16:56:42 Referring to bitbake/lib/bb/fetch2/git.py Jul 06 17:03:46 nope, either fork poky, fork bitbake itself, or deal with a local modification. can't tell bitbake to load git.py from elsewhere Jul 06 17:07:09 gabrbedd: If you're running an ancient branch anyway, what's the harm in backporting the change to your repo? Jul 06 17:07:24 It's not like there's going to be any changes to the 2.0 branch upstream Jul 06 17:07:49 @kergoth: thanks Jul 06 17:08:31 @neverpanic: Up until now, all our stuff points to the upstream yocto repo. Haven't needed to clone it to add our own patches. Jul 06 17:08:57 sounds like it's time Jul 06 17:10:19 yep Jul 06 17:10:54 TBH, I think it's time to get on a newer branch... but I gotta arm wrestle a few people to agree... Jul 06 17:11:06 been there, good luck :) Jul 06 17:56:24 rburton: r Jul 06 18:42:45 Buh, I can't find someone at 3M that is willing to let me rub this datasheet error in their face. Jul 06 18:42:51 whoops wrong channel Jul 06 22:04:04 * RP hugs strace. Mystery who bothered me for ages solved :) Jul 06 22:14:51 relating to the deploy/ipk/Packages{.gz} Jul 06 22:15:23 i have a image which *do not* requires myapp.ipk, how ever i sometimes build myapp.ipk Jul 06 22:15:37 bitbake -g is your friend Jul 06 22:15:39 and i never delete the deploy/ folders Jul 06 22:16:18 i wanted to ask if the Packages looses the reference to myapp.ipk Jul 06 22:16:20 or not Jul 06 22:17:27 bitbake -g is a dependency graph generator, can you kindly elaborate on the relation of the graph to Packages ? Jul 06 22:21:12 ah, no, that package feed includes all generated binary packages. but directly using that feed long term isn't ideal, if you want a feed with more controlled contents, best to maintain it yourself Jul 06 22:22:29 desert: we do have code which filters the packages the rootfs sees during construction which partly solves that problem. I know we use it for rpm, can't remember if we do for opkg offhand Jul 06 22:23:35 what i want to do is publish the whole deploy/ipk/* straight from the build server to a remote server Jul 06 22:24:30 im worried that when I build myimage (which does not have myapp.ipk) and then rsync the ipk/ folder I might have the myapp.ipk but a wrong Packages{.gz} Jul 06 22:25:27 New news from stackoverflow: Minnowboard Max Bootloader [on hold] Jul 06 22:25:51 can I trust that *all* the *.ipks are considered into the Packages regardless their need into the current image built? Jul 06 22:26:19 Or maybe i can run another command, something of the likes of Jul 06 22:26:53 gen-packages /some/ipks/*.ipk > /some/ipks/Packages Jul 06 22:27:06 if such a command exists Jul 06 22:28:08 desert: "bitbake package-index" does exactly that, considers all packages Jul 06 22:28:43 good, so in order to guarantee Packages.gz to have ALL the ipks I must run that, right? Jul 06 22:29:36 I was hoping it's already run on every bitbake run Jul 06 22:30:06 desert: no, it does what you tell it and doesn't guess what you might want ;-) Jul 06 22:30:32 good, this is the exact solution to my problem, thanks a lot Jul 06 22:30:59 * desert goes to implement an additional step into the CI pipelines Jul 06 23:29:43 hey, any one play with untangling python dependencies on the target side in a build? Mainly, I end up getting gcc on the target pulled in just by doing python-requests :( **** ENDING LOGGING AT Sat Jul 07 03:00:00 2018