**** BEGIN LOGGING AT Mon Mar 27 03:00:03 2017 Mar 27 05:32:35 ayaka: #MACHINE = "excavator-rk3399" Mar 27 05:32:58 ayaka: sounds interesting, is that from the kickstarter? Mar 27 07:18:21 bluelightning: nice catch on the recursive git calls, that sounds nasty Mar 27 07:18:44 RP: yeah it was a bit ugly :( Mar 27 07:19:29 RP: my first approach was to cache the value but it turned out not to be necessary - all but two of the calls at least for devtool add usage are because of the recursion Mar 27 07:20:00 bluelightning: I think there is caching elsewhere... Mar 27 07:20:03 caching might be useful for a bitbake build though, I wonder how many times we'd still be doing the same git ls-remote Mar 27 07:20:18 possibly Mar 27 07:22:51 bluelightning: "Look in the cache for the latest revision, if not present ask the SCM." - there is code in __init__.py Mar 27 07:23:12 RP: ah right it's at that level, I hadn't looked there Mar 27 07:23:15 great Mar 27 07:24:19 bluelightning: I assume whilst patch3/3 causes output, it doesn't break anything? Mar 27 07:25:47 RP: not that I know of, but I'll admit I have not done extensive testing Mar 27 07:26:23 RP: (and if you want to say, go away and come back when you've tested it, that's fine ;) Mar 27 07:27:24 bluelightning: I'm too nice about things like this, it just means I need to be careful about waiting to merge until its run through selftest Mar 27 07:27:46 sadly devtool's kernel test is still taking hours on the new AB Mar 27 07:28:07 RP: sure... in the mean time I'll try to figure out why a logger set to logging.INFO level is apparently printing out debug messages :( Mar 27 07:28:12 30 hours for selftest was a new record this weekend although that was some gpg issue :/ Mar 27 07:28:22 bluelightning: right, fair enough Mar 27 07:28:34 that's pretty egregious :( Mar 27 07:28:42 why on earth do we need hours for that? Mar 27 07:28:49 is there a bug open? Mar 27 07:29:39 bluelightning: its an autobuilder nfs clone issue causing the devtool kernel thing Mar 27 07:29:59 bluelightning: joshua had allegedly fixed it. Mar 27 07:30:25 hmm ok Mar 27 07:30:25 2017-03-27 01:06:51 - test_devtool_virtual_kernel_modify (oeqa.selftest.devtool.DevtoolTests) ... OK (16386.711s) Mar 27 07:30:31 * RP suspects its not fixed Mar 27 07:30:39 I built a toolchain for windows using meta-mingw, but when I try to etract the .tar.xz on windows I get weird errors: 7-zip says there are data after the end of the archive, also it overwrits data it has already extracted. Mar 27 07:31:16 RP: I wonder if we could change where it's checking out the source to speed things up ? though with RSS it writes the temp stuff under the workdir... Mar 27 07:31:33 bluelightning: its not devtool but the main do_fetch Mar 27 07:31:44 RP: ah ok Mar 27 07:31:56 bluelightning: we have this issue in other places, I just don't understand why the fetcher doesn't update the mirror tarballs :/ Mar 27 07:32:20 although I'd guess the config for that wouldn't be in the test :/ Mar 27 07:35:08 RP: checking the kernel do_compile log I think I've spotted a new missing hosttool Mar 27 07:35:22 /kernel-source/scripts/mkcompile_h: line 46: whoami: command not found Mar 27 08:00:54 Is it possible to speed up oe-selftest by running tests with "runqemu kvm"? Does it matter? Mar 27 08:04:21 "kvm" is definitely faster for me - 5s vs 30s boot line (from the kernel dmesg). Mar 27 08:58:02 hello is it possible to support more than one package provider in a target buikd ? Mar 27 08:58:04 build Mar 27 09:00:35 Is it possible to support more than one package provider in a target build ? Mar 27 09:01:02 ranchu: if you mean "use multiple package managers to install things on the same image": I don't know if it's possible but it sounds mad Mar 27 09:02:52 jku - Right, I meant "package managers". I understand what you mean. you say that it is more reasonable to stick with one package manager. Mar 27 09:02:58 ranchu: you can list multiple PACKAGE_CLASSES: you should then get all the types of packages you listed Mar 27 09:03:40 I mean, packages will be created for all types Mar 27 09:04:26 ranchu: but yeah, pick one :) Mar 27 09:05:31 to summarize, it is possible to have multiple package manager, but it's probably not a good design to have more than one ... Mar 27 09:23:23 joshuagl: is the AB running qemu under oe-selftest with or without kvm? Mar 27 09:23:46 pohly: should be with KVM Mar 27 09:23:53 How is that enabled? Mar 27 09:26:15 I *think* qemu does it automagically if the user it's running as can access /dev/kvm ? Mar 27 09:26:49 the user we run builds as is part of the kvm group Mar 27 09:26:57 No, I don't think it does. "runqemu" needs to be called with "kvm" to get faster execution. Mar 27 09:27:20 It also changes the machine type, so it would be unexpected if qemu did that. Mar 27 09:28:09 sounds like probably without then :-/ Mar 27 09:28:27 I just tried with and without that "kvm" parameter when invoking runqemu, and the difference is very noticable. That's why I was wondering whether it would be worthwhile to take advantage of that during oe-selftest. Mar 27 09:32:41 the autobuilder exports an env var QEMU_USE_KVM which the lib/oeqa/targetcontrol.py module should be using to set the kvm parameter to runqemu Mar 27 09:33:18 pohly: I'm pretty sure we use kvm for selftest somehow. If we don't, I'd want to fix that Mar 27 09:33:52 see OE-Core ebac2c8d1fcd09ebce0659a4abb445e4f1c18571 Mar 27 09:34:45 joshuagl: thanks, that's probably what I was looking for. Mar 27 09:36:10 Hrrm, but it doesn't work for MACHINE=intel-corei7-64 :-( Mar 27 09:38:07 I suppose the machine check was added to avoid kvm for things like arm. IMHO dealing with that via QEMU_USE_KVM with overrides or QEMU_USE_KVM listing the machines for which to use kvm would have been more flexible. Mar 27 09:39:02 RP: speaking of qemu + oe-selftest - what are the changes of still getting enhancements related to that into 2.4? Like my pending patches or a patch which enhances QEMU_USE_KVM? Mar 27 09:39:12 s/changes/changes/ Mar 27 09:39:25 Can't type! I meant "chances" of course. Mar 27 09:39:54 Probably a Freudian mistake: "changes" are risky, and thus the "chances" are low ;-} Mar 27 09:42:04 pohly: I did try and queue them but the patches didn't apply :( Mar 27 09:42:17 RP: which version? Mar 27 09:42:32 V1 should apply, V2 only when taking Robert's patches first. Mar 27 09:42:49 pohly: I thought v2. Something in marinao's patchset bust the AB too and it took me a while to figure out which patches were breaking what :( Mar 27 09:43:12 pohly: I think I've merged Roberts so could you check v2 still apply? I think I did take your first one Mar 27 09:44:31 RP: okay, I'll rebase on top of current master. Mar 27 09:45:07 pohly: thanks Mar 27 09:45:28 pohly: I'm not promising as it is late now for changes like this :/ Mar 27 09:45:36 * RP really needs rc2 built Mar 27 09:45:49 RP: hi, here is a fix for oe-selftest Friday's failure: http://lists.openembedded.org/pipermail/openembedded-core/2017-March/134646.html Can you merge it? Mar 27 09:45:56 Hmm, V2 rebased cleanly for me. Mar 27 09:48:14 ed2: didn't I do that? (and thanks!) Mar 27 09:48:39 RP: yes, I understand the problem. Conflicting with other pending patches hasn't helped, but I should have tried to use oe-selftest earlier. Mar 27 09:50:25 RP: ah, missed that you've already pick it up. Thans. Mar 27 09:51:40 RP: I've sent v3. Mar 27 10:27:36 Is it possible, ina a bbappend recipe, to patch a file specified directly in SRC_URI in a package? Mar 27 10:29:05 For example SRC_URI += "file:///foo.c" in foo.bb package and then in foo.bbappend SRC_URI+="file:///my.patch" where my.patch patches foo.c Mar 27 10:29:41 (should hav been two // and not three ///... but you get the point) Mar 27 10:32:01 yes Mar 27 10:32:06 as unpack happens before patch Mar 27 10:32:08 Default (as I understood it) the patches are applied in the src directory and not the root of the package workdir. Mar 27 10:32:39 So how would I tell the patch to work on files "one step out"? Mar 27 10:40:58 set patchdir in the URL Mar 27 10:42:28 rburton, aah, yes, thank you :-) Mar 27 10:43:42 HI Mar 27 10:44:48 if i set $B something other than WORKDIR , is it the right way to ensure my build is not removed after rm_work is done ? Mar 27 10:48:54 no Mar 27 10:49:14 why do you not want to have the build removed? Mar 27 10:50:10 you can also turn rm_work off Mar 27 11:00:03 joshuagl: cleanall patcgh \o/ \o/ Mar 27 11:05:45 hi everyone Mar 27 11:06:34 i would like to know if it is possible to build a receipe 2 times with different parameters in the same image? Mar 27 11:07:15 no Mar 27 11:07:28 the main goal would be to have a unique image for two different hardware targets (different but very close) Mar 27 11:07:36 images are made from packages, which are made from recipes Mar 27 11:07:45 so you can't build the same recipe twice and have different outputs Mar 27 11:08:03 you *can* have one recipe that includes another and changes the configuration Mar 27 11:08:06 ie mesa vs mesa-gl in oe-core Mar 27 11:08:27 the only way would be to make 2 recipes Mar 27 11:10:51 thank you for your answer rburton Mar 27 11:34:12 I have trouble adding a new recipe and doing devtool-modify on the same. Getting the "compiling from external source tree [correct path]" message, but compiling is still done down in tmp/work/{machine}/.. Mar 27 11:34:25 Looking in run.do_compile I see `cd '/the/tmp/work/machine/pkg-path'; do_compile` Mar 27 11:44:19 quite: that's probably because the build dir != source dir Mar 27 11:45:07 quite: you can tell devtool modify to build from the same directory as the source with -s Mar 27 11:45:52 * bluelightning heads out Mar 27 11:51:46 oh, that's en*light*ning Mar 27 11:52:07 except that buildir always == sourcedir around here. but ahum Mar 27 11:55:21 When installing certain ipk packages on my device I get the following warning: "///var/lib/opkg/info/kernel-devicetree.postrm: line 8: update-alternatives: command not found" Mar 27 11:55:48 It appears to be missing the update-alternatives-opkg package, and installing it manually seem to work Mar 27 11:56:27 However; adding it to my IMAGE_INSTALL_append var doesn't seem to have any effect Mar 27 11:56:56 bitbake run cleanly and produces the image as expected but for some reason the package is still missingh Mar 27 11:57:35 maybe its affected by the runtime package management settings? Mar 27 11:57:57 opkg list-installed doesn't list it either until I install it manually Mar 27 11:58:09 LetoThe2nd, You mean it is somehow "filtered out" ? Mar 27 11:58:27 deva: just guessing. but yes. Mar 27 11:58:45 do you have a lead on where I should start looking? Mar 27 12:00:16 deva: the "package-management" IMAGE_FEATURE Mar 27 12:00:21 deva: do you use that? Mar 27 12:01:04 LetoThe2nd, yup Mar 27 12:01:43 deva: then thats my guess to interfere, as we install kernel-devicetree here too, but we don't get that message Mar 27 12:02:47 LetoThe2nd, So you mean I should try and remove that feature? Mar 27 12:03:19 deva: well i guess you have the feature there for a reason. but of course you can check without it. Mar 27 12:06:42 LetoThe2nd, As understand that feature it builds the initial on-device database of installed packages for the opkg tool, but I may rbe mistaken Mar 27 12:07:49 deva: nah. that feature make package management at runtime possible altogether. so its not just that database hopefully, but the complete tooling Mar 27 12:08:26 LetoThe2nd, So I wouldn't need it to just install new ipk's on the target after deployment? Mar 27 12:09:21 deva: of course you would. thats it purpose. Mar 27 12:10:47 Hmm... seems a bit like a catch22 then, because I need it to install the ipk but it filters out the update-alternatives-opkg which is needed in ordet to install the ipk... Mar 27 12:11:18 ... provided that it is actually the package management feature doing the filtering of course Mar 27 12:12:55 you need to have the package-management feature enabled Mar 27 12:13:04 if update-alternatives isn't present then something odd is happening Mar 27 12:13:53 especially as any package using the update-alternative class automatically gets a dependency on update-alternatives Mar 27 12:14:11 do you have a weird setup? installing the package with opkg as root? Mar 27 12:14:49 I'd say the setup is rather normal, and I am installing as root Mar 27 12:18:13 rburton, I am using systemd but am excluding "systemd-extra-utils" and "systemd-vconsole-setup". Could that somehow affect update-alternatives-opkg? Mar 27 12:18:20 no Mar 27 12:18:38 can you use opkg list_installed to verify that you haven't got update-alternatives-opkg installed? Mar 27 12:19:06 "opkg list-installed | grep alter" comes up empty Mar 27 12:19:27 and /usr/bin/update-alternatives doesn't exist? Mar 27 12:19:27 It does list the rest of the packages on the system Mar 27 12:19:34 no Mar 27 12:19:51 and you do have the package-management image feature enabled? Mar 27 12:20:02 yes Mar 27 12:20:03 becuase not having it would result in it being removed from the image Mar 27 12:22:39 Could one package somehow exclude another? Mar 27 12:23:05 I have both update-alternatives and update-alternatives-opkg in my IMAGE_INSTALL Mar 27 12:23:22 But the update-alternatives is virtual as I understood it? Mar 27 12:24:46 But perhaps I should have any of those and not the opkg either if they are all implcitly pulled in by the package management image feature? Mar 27 12:50:54 deva: they'll be pulled in magically so no need to add any of them Mar 27 12:57:31 rburton, I tried removing them all and opkg is still pulled in, but not update-alternatives-opkg Mar 27 12:58:55 deva: share the rootfs log? Mar 27 13:03:39 rburton, From the workdir? Mar 27 13:04:03 yes, temp/log.do_rootfs Mar 27 13:09:01 rburton, https://pastebin.com/70ti0UNz Mar 27 13:11:25 rburton, It does seem to actively remove it near the end Mar 27 13:12:44 yes Mar 27 13:13:00 because you said you want a read only rootfs Mar 27 13:13:33 because your rootfs is immutable it removes stuff you don't have a need for Mar 27 13:13:45 don't specifyt read only rootfs if you're not actually going to have a read only rootfs Mar 27 13:15:18 I do use a readonly fs but shortly remount it as read-write in order to install packages while developing Mar 27 13:15:52 ... which does seem to work, bar the missing update-alternatives-opkg ;) Mar 27 13:20:48 so just remove read-only-rootfs from your image features Mar 27 13:24:22 rburton, But I need read-only-rootfs... Mar 27 13:24:54 But at least now I know where to look in order to force it to not remove update-alternatives-opkg Mar 27 13:25:18 but if you're remounting as read/write for development then what's the point? it doesn't actually do a lot... Mar 27 13:26:12 I only remount momentarily read-write in order to install a new devuce-tree for example and then back to read-only again Mar 27 13:26:33 The device runs in read-only mode to protect the flash among other things Mar 27 13:27:41 well patches welcome to make the package management removal optional i guess Mar 27 13:28:25 rburton, sure: -) Mar 27 13:28:46 Is it handled in the core-image-minimal recipe? Mar 27 13:29:00 Or where should I start looking? Mar 27 13:29:57 a grep for read-only-rootfs shows that meta/classes/rootfs-postcommands.bbclass does something Mar 27 13:30:06 and so does meta/lib/oe/rootfs.py Mar 27 13:31:07 assigning "" to ROOTFS_RO_UNNEEDED would make it remove nothing Mar 27 13:32:59 rburton, Would ROOTFS_RO_UNNEEDED_remove = "update-alternatives-opkg" work? Mar 27 13:33:22 maybe, but that will still be removing other bits you might want. Mar 27 13:33:30 for development purposes, keep everything on there Mar 27 13:33:44 I'll give it a spin Mar 27 13:40:06 rburton, Setting it in local.conf doesn't appear to have any effect Mar 27 13:49:44 rburton, Setting it hard to "" in core-image-minimal_%.bbappend works Mar 27 13:50:09 Using ROOTFS_RO_UNNEEDED_remove doesn't seem to have an effect Mar 27 13:54:00 rburton, I was mistaken, it also works with ROOTFS_RO_UNNEEDED_remove Mar 27 13:54:10 Thanks a lot for your help :-) Mar 27 13:54:38 so runqemu seems to remove ip from my tap interface everytime it stops. But it does not add one on startup. What should be happening here? Mar 27 13:55:17 I'm using roberts sudo-HOSTTOOLS patch already ... Mar 27 14:02:36 jku: you chouldn't need it since its already in NONFATAL Mar 27 14:03:03 oh didn't notice that Mar 27 14:03:10 jku: it depends whether the interface is preconfigured or not Mar 27 14:03:27 jku: if its not preconfigured, it should be tweaking with ip/sudo Mar 27 14:03:44 jku: its possible your system has ip somewhere the default PATH doesn't find Mar 27 14:08:24 RP: I just let it create a new tap interface, and it works great once... Mar 27 14:10:38 but if ctrl-C that, the tap is left there without ip and then it's "preconfigured": even if I manually add an ip, something removes it when runqemu ends Mar 27 14:12:00 jku: ah, so the cleanup when interrupted is bust? Probably worth a bug Mar 27 14:12:10 yeah that's what it looks like Mar 27 14:15:33 So, my devtool modify-trouble was caused by "S = ${WORKDIR}/git/" in the recipe. That trailing slash messes up this test `elif d.getVar('B', True) == os.path.abspath(d.getVar('S', True)):` in use_external_build() in devtool/__init__.py Mar 27 14:19:01 build/source are the same dir (and bitbake.conf B="${S}"), except that S had a trailing slash, which that abspath took away, causing inequality Mar 27 14:53:04 RP, what you tell me about debug seems not work for me https://paste.fedoraproject.org/paste/1hU1tC-et9pXnY8fh7Kffl5M1UNdIGYhyRLivL9gydE= Mar 27 14:53:17 I think I still need to extract the rootfs Mar 27 15:53:16 hi Mar 27 15:53:50 I’m trying to add a library to my project Mar 27 15:54:30 It builds fine bug i get the error Can't install: no package provides libssh2-1 Mar 27 15:54:38 Not sure why it says libssh2-1 Mar 27 15:54:45 when the package is libssh2 Mar 27 15:55:52 i added libssh2 to my RDEPENDS for my main app package Mar 27 15:57:43 if you link to libssh in a normal way then the RDEPENDS will be done for you Mar 27 15:57:55 just have libssh2 in DEPENDS and you'll be fine Mar 27 15:58:54 hmm, let me try that. Mar 27 16:32:16 @rburton so it builds now but when I open the image file the libs are not located in /usr/lib. I am doing this in do_install install -d ${D}${libdir} Mar 27 16:32:17 install -m 0644 ${WORKDIR}/libssh2-${PV}/src/.libs/libssh2.so ${D}${libdir}/ Mar 27 16:32:18 install -m 0644 ${WORKDIR}/libssh2-${PV}/src/.libs/libssh2.so.1 ${D}${libdir}/ Mar 27 16:32:18 install -m 0755 ${WORKDIR}/libssh2-${PV}/src/.libs/libssh2.so.1.0.1 ${D}${libdir}/ Mar 27 16:32:57 is there something else I need to do for the libs to be placed in /usr/lib Mar 27 16:34:26 why can you not just use 'make install'? Mar 27 16:35:09 are you reimplementing https://layers.openembedded.org/layerindex/recipe/28942/? Mar 27 16:41:26 hi. run in a problem with yocto. i just hope one of the 241 ppl in here could enlighten me. bitbake core-image-minimal tells me, it has no permissions for/with python3. i'm clueless. here are some more details: http://pastebin.ca/3786905 Mar 27 16:41:45 that link is bust Mar 27 16:41:53 is bust? Mar 27 16:42:53 "That is an invalid ID, or the post has expired." Mar 27 16:43:43 strange. works here. do you have a 'own' pastebin or a prefered? Mar 27 16:44:10 any is fine Mar 27 16:45:52 https://paste.debian.net/924628/ Mar 27 16:46:04 better? Mar 27 16:49:14 beeker23: looks like your python3 binary isn't executable Mar 27 16:49:34 i wonder if your build directory is on a directory you can't have executables on Mar 27 16:49:40 but it is. it's also in the path Mar 27 16:49:45 like its a usb stick on ubuntu Mar 27 16:50:04 it's on a ssd and writebale by the user beeker23 Mar 27 16:52:11 and there is also enough free disk scape Mar 27 16:52:16 space Mar 27 16:58:17 something went wrong with the paste: https://paste.debian.net/924630/ Mar 27 17:00:56 i’m not sure what you mean by make install. Thisis what my recipe looks like https://pastebin.com/jHKix2N1 Mar 27 17:01:41 when i execute the python3 script on the shell, the var $cfgscript holds the value ../../../beeker23/YOCTO/build/tmp/work/x86_64-linux/quilt-native/0.65-r0/quilt-0.65/configure Mar 27 17:02:35 the configure script exists and is executable Mar 27 17:05:25 anyone? Mar 27 17:14:36 where does the script get build? Mar 27 17:14:53 it looks like it can't find the python3 exe Mar 27 17:19:44 thats the value of PATH before the python3 would be called: /home/thomax/YOCTO/poky/scripts/native-intercept:/home/thomax/YOCTO/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/thomax/YOCTO/poky/scripts:/home/thomax/YOCTO/build/tmp/work/x86_64-linux/quilt-native/0.65-r0/recipe-sysroot-native/usr/bin/x86_64-linux:/home/thomax/YOCTO/build/tmp/work/x86_64-linux/quilt-native/0.65-r0/recipe-sysr Mar 27 17:19:46 oot-native/usr/bin:/home/thomax/YOCTO/build/tmp/work/x86_64-linux/quilt-native/0.65-r0/recipe-sysroot-native/usr/sbin:/home/thomax/YOCTO/build/tmp/work/x86_64-linux/quilt-native/0.65-r0/recipe-sysroot-native/usr/bin:/home/thomax/YOCTO/build/tmp/work/x86_64-linux/quilt-native/0.65-r0/recipe-sysroot-native/sbin:/home/thomax/YOCTO/build/tmp/work/x86_64-linux/quilt-native/0.65-r0/recipe-sysroot-native Mar 27 17:19:47 /bin:/home/thomax/YOCTO/poky/bitbake/bin:/home/thomax/YOCTO/build/tmp/hosttools Mar 27 17:19:55 ^thomax^beeker23 Mar 27 17:20:10 there is no /usr/bin in the PATH var Mar 27 17:21:15 PATH gets overwritten in the created script - so it can't find python3 Mar 27 17:22:20 and if yocto like to use it's own build python3 it should build it before it gets used Mar 27 17:23:42 * beeker23 sighs Mar 27 17:28:29 rburton: any hint Mar 27 17:28:32 ? Mar 27 17:57:45 beeker23: the usual reason is that you cant have executables in your ~/ so have you verified that they work? python3 will be a symlink inside build/tmp/hosttools Mar 27 18:00:38 rburton: well.. i think it is no good idea to use HEAD/MASTER of yocto. i guess someone didn't test a push Mar 27 18:01:01 works for me! Mar 27 18:01:32 beeker23: seriously, theres a python3 symlink in tmp/hosttools, verify you can run that Mar 27 18:01:35 if you can't then work out why Mar 27 18:01:50 rburton: but it's only with the quilt. and this is part of a meta receipt Mar 27 18:03:37 there is just a directory python3 in build/tmp/hosttools and this only contains a debian_conf Mar 27 18:04:56 yocto tries to build quilt in a very early stage Mar 27 18:06:06 beeker23: do you have python3 installed on your build machine? Mar 27 18:06:12 yes Mar 27 18:06:37 but the script overwrites the path. Mar 27 18:06:44 my hosttools has symlinks to /usr/bin/python3 /usr/bin/touch etc Mar 27 18:07:07 don't know why i don't have it Mar 27 18:07:47 i just cloned the yocto master and bitbake the minimal core image Mar 27 18:08:30 whats the distro running on build host ? Mar 27 18:08:32 (well.. and of cause use meta-rockchip) Mar 27 18:08:35 debian Mar 27 18:08:45 which version ? Mar 27 18:08:58 (freshly dist-upgraded testing) Mar 27 18:10:07 ayaka: include python-misc in your image see if that helps Mar 27 18:10:22 scratch that Mar 27 18:10:42 beeker23: can you pastebin the contents of tmp/hosttools (ls -l) Mar 27 18:11:13 rburton: one sec. i start build from scratch (rm -rf build) Mar 27 18:12:00 I wonder if you have python pointing to some non-standard install Mar 27 18:14:58 waaaaa, i guess i found the issue Mar 27 18:19:03 yes. my fault. bash is not my normal shell - i'm tcsh user. but the bash PATH contained /etc before /usr/bin and made a symlink from /etc/python3 Mar 27 18:20:12 now, i hope, it runs through Mar 27 18:21:05 thanks for have an eye on the channel, rburton & khem Mar 27 18:39:51 can i `make menuconfig` manualy and bitbake again? Mar 27 18:49:11 just `make menuconfig` and copy the .config file to defconfig? is this the way? Mar 27 19:22:09 pohly: Your patch set results in this: https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/233 :( Mar 27 19:22:38 Argh. Checking... Mar 27 19:23:31 How many implementations of launch() are there? I must have missed on. Mar 27 19:23:52 pohly: I haven't looked into it, just that your patch and those errors look very related Mar 27 19:24:01 Yes, it's definitely that. Mar 27 19:26:25 I bet it's the qemutinyrunner.py start(). Mar 27 19:27:26 RP: where can I see what DISTRO is set for the tests which fail> Mar 27 19:27:27 ? Mar 27 19:29:50 beeker23: ah sounds like an interesting bug in os.which or something in python Mar 27 19:30:34 rburton: you mean the wrong sym link? Mar 27 19:30:38 yeah Mar 27 19:30:50 the code just looks for the first thing matching the name in $PATH Mar 27 19:30:56 rburton: was just a wrong PATH Mar 27 19:30:57 which is why it found /etc/python3 Mar 27 19:31:06 yepp Mar 27 19:31:10 it should also check that its an executable file i guess Mar 27 19:31:19 or use `which` Mar 27 19:31:45 the directory is also x-bit Mar 27 19:31:58 yeah, but not a Mar 27 19:32:00 yeah needs to be executable & file Mar 27 19:32:03 'normal' file Mar 27 19:32:06 bb.utils.which is the bug Mar 27 19:32:38 you can earn a star now for a bug fix :-) Mar 27 19:32:55 here you go: * Mar 27 19:34:23 rburton: but am i right? i can `make menuconfig` the kernel and take the changed from .config to defconfig and bitbake again? Mar 27 19:40:20 RP: sorry for the AB failures :-/ In hindsight it is obvious why the patch was incomplete. V4 sent. Mar 27 20:12:26 bluelightning: TinfoilUIException results in a traceback when running bitbake-layers, the toplevel try/except for main() doesn't catch it Mar 27 20:12:31 just as an fyi Mar 27 20:12:54 kergoth: what is that exception caused by in your case? Mar 27 20:13:17 i .. can't remember. maybe a missing base recipe for an append? parse time? Mar 27 20:13:21 ran into it on friday Mar 27 20:15:59 updating our layers from morty to master Mar 27 20:19:39 <_rai_> I need to create a symbolic link on the rootfs for Ostro using bitbake. Essentially I need 'ln -s /lib /lib64' . What's the best way to do this ? Mar 27 20:24:15 _rai_: probably a function called from ROOTFS_POSTPROCESS_COMMAND Mar 27 20:24:23 (in your custom image recipe) Mar 27 20:27:17 <_rai_> bluelightning: would I have to create a new meta layer for that or just create a recipe within another layer ? Or pehaps just add the ln -s to an existing function ? Mar 27 20:29:25 _rai_: you can put the image recipe in any existing layer, but I would encourage you to create your own layer - it's really easy, the yocto-layer script will create one for you Mar 27 20:31:49 <_rai_> bluelightning: yes, I know how to create custom layers. But my attemps at creating the link so far have failed. No errors, just no link. Mar 27 20:33:45 <_rai_> I'm looking at the rootfs-postcommands.bbclass now. I guess this would be an append to a function ? Mar 27 20:34:44 _rai_: I'm writing an example now for you Mar 27 20:34:59 <_rai_> bluelightning: cool, thanks Mar 27 20:35:41 _rai_: https://pastebin.com/N0PNTyEv Mar 27 20:36:06 hmm, actually that ln command is incorrect Mar 27 20:36:36 _rai_: have updated Mar 27 20:37:59 <_rai_> okay Mar 27 20:42:17 <_rai_> Thanks I appreciate it Mar 27 20:48:57 np Mar 27 20:50:59 <_rai_> bluelightning: is there a new pastebin link ? Mar 27 20:51:19 _rai_: nope, same one Mar 27 20:51:38 basically I just dropped both /'s in the ln command Mar 27 20:52:00 <_rai_> ahh I see. I'll give this a shot. Thanks ! Mar 28 01:35:13 what is a good starting point for building arm images? Other than read all the documentation from "in the beginning, God said let there be light..." Mar 28 01:39:45 https://www.yoctoproject.org/tools-resources/videos/getting-started-yocto-project-new-developer-screencast-tutorial perhaps? Mar 28 01:40:21 I'll check it out, thanks Mar 28 01:40:58 been messing with it a little, i made a directory for building things and changed the MACHINE in the local.conf Mar 28 01:42:00 an 'arm image' is just picking a machine which is that arch and bitbaking whatever image you want.. Mar 28 01:42:49 yes i want to make a minimal one first, see if it boots on my raspi Mar 28 01:43:09 well, boots in a simulator first Mar 28 01:55:57 i hope using the latest from the git repo is reasonably safe, from here git://git.yoctoproject.org/poky **** ENDING LOGGING AT Tue Mar 28 03:00:03 2017