**** BEGIN LOGGING AT Thu Jan 30 02:59:58 2014 Jan 30 04:38:41 khem, you still around? Jan 30 04:38:51 yes Jan 30 04:39:13 I just rebased the python3 branch Jan 30 04:39:24 I added the openembedded-core-contrib kraj/python3 branch Jan 30 04:39:30 I also fixed the warnings Jan 30 04:39:31 and without changing anything I got: Jan 30 04:39:37 ERROR: ExpansionError during parsing /home/michael_e_brown/cp-2/build/qemu/release-xrev/../../../openembedded-core-contrib/meta/recipes-devtools/python/python3-distribute_0.6.32.bb: Failure expanding variable DEPENDS: ExpansionError: Failure expanding variable DEPENDS, expression was virtual/x86_64-poky-linux-gcc virtual/x86_64-poky-linux-compilerlibs virtual/libc python3 ${@["${PYTHON_PN}-native ${PYTHON_PN}", " Jan 30 04:39:37 "][(d.getVar('PACKAGES', True) == '')]} ${PYTHON_PN}-native which triggered exception SyntaxError: EOL while scanning string literal (DEPENDS, line 1) Jan 30 04:40:11 Do I need to update any config? I was just adding that layer to my existing dora build to make sure everything still compiles before switching over to python3 Jan 30 04:40:38 hmm did you cherry-pick the patches Jan 30 04:40:41 nope Jan 30 04:40:43 or how did you do it Jan 30 04:40:56 just added the whole layer... maybe I screwed something up, but it seemed straightforward Jan 30 04:41:11 you said you were on poky or some sort Jan 30 04:41:18 I checked out the kraj/python3 branch and added it to my bblayers Jan 30 04:41:23 poky, dora branch Jan 30 04:41:55 well poky does not take OE-Core as such it fudges it into a layer of its own Jan 30 04:42:07 so your best approach is to cherry-pick Jan 30 04:42:15 I just posted the series to ml Jan 30 04:42:16 as well Jan 30 04:42:28 Ok. little bit more work. I'll check it out. Jan 30 04:42:30 so you can just pw-am.sh 1 by 1 on dora/poky Jan 30 04:43:17 you will get a conflict on [15/15] python-setuptools: Remove its provided by python-distribute Jan 30 04:43:39 thats because dora has a different version of python-setuptools_1.4.bb Jan 30 04:43:43 that its removing Jan 30 04:43:50 so you can solve that manually Jan 30 04:44:01 other 14 should apply straight forward Jan 30 04:44:05 ok. all new stuff to me, but it looks straightforward. Jan 30 04:44:33 thanks for the direction and pointers Jan 30 04:44:46 np Jan 30 04:45:14 let me know how it goes Jan 30 04:45:43 you will provide testing to them Jan 30 04:45:53 so reply to mailing thread with your results Jan 30 04:45:57 any plan to get this into yocto 1.6? Or is there a target for it? Jan 30 04:46:10 yes I 1.6 should get it Jan 30 04:46:19 hopefully this is last iteration Jan 30 04:46:28 ok. I'll apply and send a note when I get it. Jan 30 04:59:13 khem, second patch in the series fails for some weird reason: Jan 30 04:59:25 $ ./pw-am.sh 66059 Jan 30 04:59:25 + for patchnumber in '$@' Jan 30 04:59:25 + wget -nv http://patches.openembedded.org/patch/66059/mbox/ -O pw-am-66059.patch Jan 30 04:59:25 2014-01-29 22:58:13 URL:http://patches.openembedded.org/patch/66059/mbox/ [20974] -> "pw-am-66059.patch" [1] Jan 30 04:59:25 + git am -s pw-am-66059.patch Jan 30 04:59:26 Applying: python-3.3-manifest: Add python3 manifest file Jan 30 04:59:28 /home/michael_e_brown/cp-2/poky/.git/rebase-apply/patch:19: trailing whitespace. Jan 30 04:59:30 Jan 30 04:59:32 fatal: corrupt patch at line 274 Jan 30 04:59:36 Patch failed at 0001 python-3.3-manifest: Add python3 manifest file Jan 30 04:59:38 When you have resolved this problem run "git am --resolved". Jan 30 04:59:40 If you would prefer to skip this patch, instead run "git am --skip". Jan 30 04:59:42 ah yes Jan 30 04:59:42 To restore the original branch and stop patching run "git am --abort". Jan 30 04:59:46 and... looking at the patch, something is off: Jan 30 04:59:49 http://patches.openembedded.org/patch/66059/ Jan 30 04:59:51 it has a line which is longer than 998 chars Jan 30 05:00:02 which emails cant handle Jan 30 05:00:03 sitecustomize.py is split Jan 30 05:00:07 hmmm Jan 30 05:00:16 I tried to fix it, but I failed somehow Jan 30 05:00:21 clone oe-core-contrib Jan 30 05:00:30 checkout kraj/python3 branch Jan 30 05:00:40 and generate the patches Jan 30 05:00:46 I can do that. Jan 30 05:00:49 git format-patch -15 Jan 30 05:01:06 and then git am them in your poky tree Jan 30 05:01:45 easy enough. let me reclone my tree since you said you rebased everything Jan 30 05:12:25 btw. in angstrom I already have it working with dora Jan 30 05:15:07 thanks. git am is progressing. halfway there. Jan 30 05:15:35 there are some trailing whitespace warnings, btw Jan 30 05:25:45 yes Jan 30 05:45:53 * mranostay yawns Jan 30 07:03:16 khem, got interrupted with girlfriend issues, but I finally got everything applied, and rebuilding same exact image (no python3, still python2) WORKS GREAT, NO PROBLEMS. Next step, I will pull in python3 to see how that works. Jan 30 07:03:50 fantastic Jan 30 07:06:16 there are plenty of other recipes for python universe that I havent contributed Jan 30 07:06:40 essentially things like jinja sphinx pyzmq and stuff Jan 30 07:06:57 once OE-Core patches go in then I will propose them for meta-oe Jan 30 07:09:29 khem, adding python3 fails to build: Jan 30 07:09:33 ERROR: This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Jan 30 07:09:33 Rerun configure task after fixing this. The path was '/home/michael_e_brown/cp-2/build/qemu/release-xrev/tmp/work/x86_64-poky-linux/python3/3.3.3-r0.0/Python-3.3.3' Jan 30 07:09:33 ERROR: Function failed: do_qa_configure Jan 30 07:09:33 ERROR: Logfile of failure stored in: /home/michael_e_brown/cp-2/build/qemu/release-xrev/tmp/work/x86_64-poky-linux/python3/3.3.3-r0.0/temp/log.do_configure.10085 Jan 30 07:09:35 ERROR: Task 461 (/home/michael_e_brown/cp-2/build/qemu/release-xrev/../../../poky/meta/recipes-devtools/python/python3_3.3.3.bb, do_configure) failed with exit code '1' Jan 30 07:09:38 NOTE: Tasks Summary: Attempted 3060 tasks of which 3044 didn't need to be rerun and 1 failed. Jan 30 07:09:40 No currently running tasks (3060 of 3070) Jan 30 07:09:42 Summary: 1 task failed: Jan 30 07:09:46 /home/michael_e_brown/cp-2/build/qemu/release-xrev/../../../poky/meta/recipes-devtools/python/python3_3.3.3.bb, do_configure Jan 30 07:09:49 Summary: There were 2 ERROR messages shown, returning a non-zero exit code. Jan 30 07:09:53 let me look in the log file to see what I can see Jan 30 07:12:11 cc1: warning: include location "/usr/include/ncursesw" is unsafe for cross-compilation [-Wpoison-system-directories] Jan 30 07:13:58 It looks like configure.ac, line 4311: Jan 30 07:14:01 CPPFLAGS="$CPPFLAGS -I/usr/include/ncursesw" Jan 30 07:18:02 michael_e_brown: I bet I fixed it once Jan 30 07:18:25 whats your build OS Jan 30 07:18:34 I am on centos 6 Jan 30 07:18:54 it looks like a clear problem in the stock python configure.ac Jan 30 07:19:03 if you have possibility can you uninstall ncursesw Jan 30 07:19:05 on it Jan 30 07:19:17 yes I know Jan 30 07:19:23 the problem is in python Jan 30 07:19:33 looks like it should be using pkg-config Jan 30 07:20:03 this is a shared build machine... slightly difficult to uninstall Jan 30 07:20:27 btw. you might also want something like https://github.com/Angstrom-distribution/meta-angstrom/blob/angstrom-v2013.12-yocto1.5/recipes-angstrom/packagegroups/packagegroup-python3.bb Jan 30 07:20:34 hmm ok Jan 30 07:21:21 oh, thanks. that packagegroup looks lovely. Jan 30 07:22:11 I'm going to get yelled at tomorrow, but I uninstalled curses devel and everything it depends on and it's compiling now. We ought to patch that configure.ac to use PKG_CHECK_MODULES() Jan 30 07:22:57 oh, wait, HPUX probably isnt doing pkg-config Jan 30 07:22:58 nm Jan 30 07:23:38 Well, I know how *I* would fix this. How would you fix this for the 'official' python3 package? (just curious) Jan 30 07:24:42 OK cooking a patch hang on Jan 30 07:27:49 Another "issue" (may or may not be real, since I'm just starting to move some stuff to python3): python3-fcntl package is empty. Jan 30 07:28:14 $ find . | grep fcntl Jan 30 07:28:14 ./aclocal-copy/fcntl-o.m4 Jan 30 07:28:14 ./build/temp.linux-x86_64-3.3/home/michael_e_brown/cp-2/build/qemu/release-xrev/tmp/work/x86_64-poky-linux/python3/3.3.3-r0.0/Python-3.3.3/Modules/fcntlmodule.o Jan 30 07:28:14 ./Lib/test/test_fcntl.py Jan 30 07:28:14 ./Doc/library/fcntl.rst Jan 30 07:28:18 ./Modules/fcntlmodule.c Jan 30 07:28:20 [michael_e_brown@gitbuild12g106 Python-3.3.3]$ cd ../packages-split/ Jan 30 07:28:22 [michael_e_brown@gitbuild12g106 packages-split]$ find python3-fcntl/ Jan 30 07:28:24 python3-fcntl/ Jan 30 07:28:37 It looks like there is an fcntlmodule.o, but it doesn't end up in python3-fcntl, nor do I see it anywhere else. Jan 30 07:31:16 Ah, looks legit: Jan 30 07:31:19 | Collected errors: Jan 30 07:31:19 | * satisfy_dependencies_for: Cannot satisfy the following dependencies for python3-subprocess: Jan 30 07:31:19 | * python3-fcntl * Jan 30 07:31:19 | * opkg_install_cmd: Cannot install package python3-subprocess. Jan 30 07:31:42 so there is another problem to fix, khem. Jan 30 07:32:37 OK I pushed a patch to contrib branch Jan 30 07:32:48 git pull and cherry pick it Jan 30 07:32:48 Looks like python-3.3-manifest.inc needs an update: Jan 30 07:32:51 FILES_${PN}-fcntl="${libdir}/python3.3/lib-dynload/fcntl.*.so " Jan 30 07:32:59 should be fcntlmodule*.so Jan 30 07:33:08 or just fcntl*.so Jan 30 07:33:24 hmmm Jan 30 07:36:20 let me see if I can reproduce the second problem Jan 30 07:36:22 khem, could you check what you just committed? It appears that you: Jan 30 07:36:27 + file://avoid-ncursesw-include-path.patch \ Jan 30 07:36:32 but did not git add the actual patch file Jan 30 07:37:35 For the fcntl one, maybe python isnt installing it? Jan 30 07:37:36 $ find image/ | grep fcntl Jan 30 07:37:36 image/usr/lib/python3.3/test/test_fcntl.py Jan 30 07:37:48 I'm not seeing the built fcntlmodule.so installed Jan 30 07:38:08 yes Jan 30 07:38:38 OK repushed Jan 30 07:42:57 cool. I learned a new trick. thanks. "=" Jan 30 07:43:22 re-installed the offending ncurses-devel and it got past do_configure Jan 30 07:43:27 now on do_compile Jan 30 07:43:49 np Jan 30 07:45:35 build successful Jan 30 07:45:45 fcntl.so is the module Jan 30 07:45:52 that it should build Jan 30 07:46:03 few years ago I fixed it for python 2 Jan 30 07:46:15 it might need similar stuff with p3 Jan 30 07:59:24 OK I think I know the problem Jan 30 07:59:31 trying out a potential fix Jan 30 08:00:43 ok, good, because I have been looking at it and have no idea what's going on. Jan 30 08:16:50 its a chicken egg problem Jan 30 08:17:01 where mods need libpython to be staged Jan 30 08:17:16 so compile step needs to be divided Jan 30 08:17:29 hopefully that will fix it Jan 30 08:17:52 ok, thanks for looking. bedtime for me. Jan 30 08:18:07 I'll pull and test tomorrow if you have something pushed Jan 30 09:09:22 hi! how do I trigger updating a package feed manifest (Packages*) after bitbaking a previously unused recipe? Jan 30 09:10:05 I mean... 'bitbake gdb' does put ipks in deploy/ipk dir, but the Packages* files don't seem to be updated Jan 30 09:10:16 working with yocto dora Jan 30 09:10:45 g1zer0: bitbake package-index Jan 30 09:12:52 g1zer0: http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html#configuring-the-pms Jan 30 09:13:49 Net147: thx... i definitely missed the right keyword to search the docs... ;-) Jan 30 09:14:46 Net147: it works as expected! Jan 30 09:20:07 good morning Jan 30 09:37:53 Morning every one, Jan 30 09:37:53 I want to create the following custom filesystem /boot (ext3 unmount) / (ubifs ro) /home (ext3 + ecryptfs) /update (ext3 unmount) /update-1 (ext3 unmount), can someone help me please? Jan 30 09:37:53 I found IMAGE_FSTYPES = "ubifs" but that create the entire image, what should I do? Jan 30 09:37:53 Where should I specify this options? Jan 30 09:39:26 morning all Jan 30 09:40:05 TuTizz: we don't have built-in support for creating custom partition layouts, but we do have a work-in-progress tool called "wic" for doing that Jan 30 09:41:50 ok will take a look Jan 30 10:15:03 rburton: hi, do you know how the image gets the information which distribution to use? Jan 30 10:15:50 bitbake reads the DISTRO on parse, which leads to the distro configuration files being read Jan 30 10:16:09 so when the image is being built, bitbake has loaded the distro configuration Jan 30 10:16:58 rburton: ah, ok, and the DISTRO comes from e.g. local config, or the image conf itself, etc. Jan 30 10:17:04 image config = image recipe. Jan 30 10:17:48 you wouldnt put DISTRO= into an image recipe Jan 30 10:18:03 you'd put it in a local.conf or site.conf normally Jan 30 10:18:07 yeah Jan 30 10:18:26 site.conf, that is, when you work with developers on the same thing. Jan 30 10:19:13 bitbake doesn't care what you do with local.conf or site.conf, it just loads both with the intention that one is site-specific and the other is yours. Jan 30 10:19:22 yes. Jan 30 10:19:31 rburton: why do I see the DISTRO variable set in distro configs? Jan 30 10:19:49 it should be set by the user of the distro, yes? Jan 30 10:20:22 or is that for making the name different from the file name? Jan 30 10:20:34 where do you see DISTRO set in a distro config? Jan 30 10:20:44 sec. Jan 30 10:21:20 rburton: ../meta-yocto/conf/distro/poky.conf:1:DISTRO = "poky" Jan 30 10:21:28 ../meta-yocto/conf/distro/poky-tiny.conf:32:DISTRO = "poky-tiny" Jan 30 10:21:36 those deserve a patch, or? Jan 30 10:22:04 patch, no, that's there for a reason. i just don't know what it is. Jan 30 10:22:10 ok. Jan 30 10:22:20 rburton: who may know? Jan 30 10:22:40 my assumption is decoupling the file name for the distro name for customization. Jan 30 10:22:57 there can be no decoupling Jan 30 10:23:16 the distro conf is included by looking for conf/distro/${DISTRO}.conf Jan 30 10:23:20 see bitbake.conf where that is done Jan 30 10:23:59 rburton: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-DISTRO Jan 30 10:26:32 rburton: hmm, that documentation mentions that it should be used from outside the distro config, and then it gives an example when it is used inside. It is a bit incomprehensive for me, I am afraid. Jan 30 10:26:44 bluelightning: then what is the use of it inside the distro config? Jan 30 10:26:59 don't know either Jan 30 10:27:07 it ought to be superfluous Jan 30 10:27:45 OK, I will ask on the mailing list. Jan 30 10:30:55 rburton: I will remove it in my distro conf, if that is safe? Jan 30 10:31:07 I just mimiced poky. :-) Jan 30 10:32:10 oops, the poky mailing list subscription is broken for me. Jan 30 10:32:49 lpapp: not sure, might be there for a reason Jan 30 10:34:11 an "old" reason maybe Jan 30 10:36:06 Hi all! I'm facing this problem while porting a bsp layer from dylan to dora. I can successfully build both kernel and user space. Kernel (3.10) starts smoothly but the user space is broken. This is a bsp for a pretty prehistoric i486sx target. Everything was working fine with latest dylan. During boot, many userspace processes (udevd, connmand, ecc..) get killed by SIGILL. What I came up with after some investigation mak Jan 30 10:36:08 es me suspect something went wrong while building eglibc. Btw: not everything is broken in userspace; i.e. dropbear works and I can connect to the target. I even can debug on target with gdb. I'm not guru-ish enough to figure out what went wrong... Here is a bt from gdb when running one of the failing processes: Jan 30 10:36:21 Program received signal SIGILL, Illegal instruction. Jan 30 10:36:23 0x48f40ca4 in __init_cpu_features () at ../sysdeps/x86_64/multiarch/init-arch.c:52 Jan 30 10:36:25 52 __cpuid (0, __cpu_features.max_cpuid, ebx, ecx, edx); Jan 30 10:36:27 (gdb) bt Jan 30 10:36:29 #0 0x48f40ca4 in __init_cpu_features () at ../sysdeps/x86_64/multiarch/init-arch.c:52 Jan 30 10:36:31 #1 0x48f40f2b in __get_cpu_features () at ../sysdeps/x86_64/multiarch/init-arch.c:191 Jan 30 10:36:33 #2 0x48f40f54 in elision_init (argc=1, argv=0xbffffdd4, environ=0xbffffddc) Jan 30 10:36:35 at ../nptl/sysdeps/unix/sysv/linux/x86/elision-conf.c:65 Jan 30 10:36:37 #3 0x48d953d6 in call_init (l=, argc=1, argv=argv@entry=0xbffffdd4, env=env@entry=0xbffffddc) Jan 30 10:36:39 at dl-init.c:84 Jan 30 10:36:41 #4 0x48d9550b in call_init (env=0xbffffddc, argv=0xbffffdd4, argc=1, l=) at dl-init.c:36 Jan 30 10:36:43 #5 _dl_init (main_map=0x48da8928, argc=1, argv=0xbffffdd4, env=0xbffffddc) at dl-init.c:99 Jan 30 10:36:45 #6 0x48d86d3f in _dl_start_user () from /lib/ld-linux.so.2 Jan 30 10:36:58 that x86_64 sounds suspicious to me... Jan 30 10:37:39 pastebin Jan 30 10:40:00 rburton: ok, will just ask then after some local git history digging Jan 30 10:40:06 av500: you are old, accept it. ;-) Jan 30 10:40:59 I do, kid, I do Jan 30 10:41:23 rburton: RP added it in 2005. :D Jan 30 10:44:28 hi guys, looking for firmware called 'iwlwifi-5000-x.ucode' Jan 30 10:44:34 do I find it anywhere in Yocto? Jan 30 10:44:42 apparently poky/ and meta-intel/ don't support that one Jan 30 10:44:57 Xz: isn't it part if linux-firmware? Jan 30 10:44:57 Xz: is it part of the upstream linux firmware repo? Jan 30 10:45:49 lpapp: I think those names were hardcoded so that overrides worked correctly, even when you use the distro files from local includes that overide them. Its more of a hardcoded sanity check Jan 30 10:46:25 RP: as per linux-firmware recipe I don't see support for that Jan 30 10:46:41 Xz: it's possible that it isn't explicitly split out Jan 30 10:46:46 RP: bluelightning: chip is called Intel WiFi LINK 5100 Jan 30 10:47:05 RP: bluelightning: so if I install whole linux-firmware it will just be there? iwlwifi supports that Jan 30 10:47:44 Xz: you can do that, or you can modify the linux-firmware recipe to split it out Jan 30 10:47:53 Xz: I'd see if that file is part of that recipe. We can always split it out Jan 30 10:48:12 RP: can you mention a scenario when it would not work without it? Jan 30 10:49:04 lpapp: where you include the poky distro from some other local settings file by using a different DISTRO setting? Jan 30 10:50:17 RP: what exactly wouldn't work them? Can you give an expected and actual output? Jan 30 10:50:20 then* Jan 30 10:50:53 lpapp: the expected output would be the poky overrides being applied. The actual output without that is that the overrides do not get applied Jan 30 10:51:16 lpapp: what exactly is causing you a problem with these? Jan 30 10:54:23 RP: "by using a different DISTRO setting?" => you mean before or after the include? Jan 30 10:56:52 RP: my assumption is before. Jan 30 11:01:36 lpapp: before Jan 30 11:01:41 RP: then I do not follow. Jan 30 11:02:45 RP: IMO, this needs a rethrought, currently if you include it after, it goes on even though the end user may have wanted to include it after Jan 30 11:02:54 so it is silently goes further on rather than a warning. Jan 30 11:03:09 lpapp: distroA.conf requires poky.conf, you'd use DISTRO = "distroA" but it would subclass poky and end up looking like poky. This is how distro inheritance used to work Jan 30 11:03:48 poky + your extension. Jan 30 11:03:52 in your distroA. Jan 30 11:03:57 what is the problem in there? Jan 30 11:04:30 lpapp: there is no problem, I'm trying to explain why the metadata is the way it is which I believe is what you asked? Jan 30 11:04:51 I moved to /dev/shm and observing strange problems: chown: changing ownership of `/dev/shm/tmp/work/i586-poky-linux-uclibc/gcc-runtime/4.7.2-r20/image/usr': Operation not permitted Jan 30 11:04:54 have you ever seen it? Jan 30 11:05:11 Yocto fails on 'chown' Jan 30 11:05:17 I think it has something to do with pseudo Jan 30 11:05:33 Xz: er, I don't think you should be using /dev/shm itself as TMPDIR Jan 30 11:05:41 bluelightning: why not? Jan 30 11:05:54 Xz: by all means, mount your own tmpfs and use that, but /dev/shm has a specific purpose Jan 30 11:06:25 bluelightning: I have no root on that machine :( Jan 30 11:07:01 bluelightning: and it has 132GB memory Jan 30 11:07:21 Xz: ask whoever has root to set you up a ramdisk then ;) Jan 30 11:07:25 RP: yes, but it must solve some issue, but I do not see what issue yet. Jan 30 11:07:38 bluelightning: ok, I can sort it out in background Jan 30 11:07:45 bluelightning: but I don't think it will solve my chown problem Jan 30 11:07:52 1) foo.conf -> requires poky.conf Jan 30 11:07:58 2) You use DISTRO = "foo" Jan 30 11:08:04 The end user will build based on foo as expected. Jan 30 11:08:20 lpapp: The value of DISTRO is used in OVERRIDES Jan 30 11:08:23 it is an internal detail that foo is utilizing poky internally. Jan 30 11:08:33 and often you'd want poky in there rather than foo Jan 30 11:08:43 RP: why? Jan 30 11:08:54 lpapp: so the poky distro overrides get used Jan 30 11:09:53 we now have DISTROOVERRIDES so the world has changed since 2005 but the principle still stands Jan 30 11:10:16 RP: if I use distro "foo" I expect DISTRO="foo" to be applied, not DISTRO="poky". Jan 30 11:10:34 lpapp: You might expect that, others do not Jan 30 11:10:43 for me, it does not matter if my interface "foo" replaces "poky" internally one day for something else. Jan 30 11:10:49 apparently I'm not the only one with 'chown' problem Jan 30 11:10:51 https://lists.yoctoproject.org/pipermail/yocto-builds/2012-June/001701.html Jan 30 11:10:58 RP: why would they expect it differently? Jan 30 11:11:08 their interface is "foo", and the internals are just internals. Jan 30 11:11:47 lpapp: by including the poky distro, they likely want all of the "policy" associated with that distro which includes its overrides Jan 30 11:13:18 RP: or may not... Jan 30 11:13:38 lpapp: This is the expected behaviour, I'm telling you that, not debating it Jan 30 11:13:38 it feels a bit like this inheritance method is not yet polished. Jan 30 11:13:49 well, I would expect it different as the author of foo. Jan 30 11:13:54 differently* Jan 30 11:14:09 * RP shrugs Jan 30 11:14:11 lpapp: RP asked you a question earlier - are you trying to solve an actual problem that you are experiencing here? Jan 30 11:14:19 as the author of foo, why would you inherit the poky distro if you didn't want poky's behaviour? Jan 30 11:14:34 * zecke is happy to have his ignore list. :) Jan 30 11:15:10 bluelightning: yes, cleaning up potentially unneeded things. Jan 30 11:15:22 lpapp: so, no then... Jan 30 11:15:33 so yes.... Jan 30 11:16:05 well, I accept that "dummy" stuff are there without knowledge is not an issue for you... but it certainly is for me as the maintainer of the thing. Jan 30 11:16:06 you'll not save any kind of space, build time, etc. by fiddling with this, and you're not actually experiencing any kind of build failure as a result Jan 30 11:16:38 how do you *really* know I do not face an issue due to this any soon? Jan 30 11:16:49 as a maintainer I *would* like to understand what is going on. Jan 30 11:16:54 about the software I need to supervise. Jan 30 11:16:55 because we asked and you didn't answer in the affirmative? Jan 30 11:17:36 "do not try to prevent issues, fix it once you spend enough time with debugging it" Jan 30 11:17:47 that is not my maintainer mentality, but I accept if others see the world differently. Jan 30 11:18:09 (but this is my software after all... and I will certainly drop that definition in my distro conf respectively) Jan 30 11:20:00 this setting would make it impossible to use DISTRO in foo. Jan 30 11:20:06 because:- Jan 30 11:20:15 1) You use it before the requires, it is void Jan 30 11:20:24 2) If you use it after, it will not work for the poky bits. Jan 30 11:20:47 My opinion is that the inheritance for distros is currently broken... IMHO, it is a valid use case to take advantage both layers, but currently you cannot. Jan 30 11:20:51 lpapp: its not impossible to use DISTRO in foo, you can simply make an assignment after the include Jan 30 11:20:52 of* Jan 30 11:21:12 RP: no, you wrote that then the poky bits will not get applied. Jan 30 11:21:41 lpapp: you could add poky to DISTROOVERRIDES at the same time if that is what you wish Jan 30 11:22:31 RP: If I am writing a foo layer depending on poky, I would like to utilize both layer features. Jan 30 11:22:31 lpapp: there are a ton of different ways this can be setup. We've chosen to leave this setup the way it originally started because people have relied on that behaviour for the past 9 years and there is no pressing reason to change that Jan 30 11:22:50 I agree that if we sat down today we might do some things differently. That isn't a luxury we have Jan 30 11:24:39 RP: OK, so you admit that it is not the best, but you prefer compatibility. Jan 30 11:25:43 hmm, I do not see the logs here for 2014: https://www.yoctoproject.org/irc/ Jan 30 11:26:03 lpapp: I think any of the people who've worked on OE for a while will agree there are places where things are suboptimal however yes, we try and have some compatibility Jan 30 11:26:40 RP: OK, that I can accept, but comments like "* zecke is happy to have his ignore list. :)" for a different technical opinion is go a bit far... Jan 30 11:26:48 goes* Jan 30 11:26:56 lpapp: where there is a pressing need for a change, we can and have made changes but we try and reserve those changes for the places we really need them Jan 30 11:27:15 lpapp: that is his choice Jan 30 11:27:17 OK, thanks for sharing your opinion. Now, at least, I understand the reason. Jan 30 11:27:45 RP: sure, and I do not mind, but providing such negative comments in public is not healthy IMHO. Jan 30 11:27:49 (but let us get over that) Jan 30 11:34:27 I have an error with sysroot_stage_all_append, is this name changed? Jan 30 11:36:25 TuTizz: in the kernel? Jan 30 11:36:38 well, in a kernel recipe? Jan 30 11:36:45 yes Jan 30 11:36:56 TuTizz: it changed from a shell to a python function Jan 30 11:37:03 linux_imx.inc Jan 30 11:37:47 TuTizz: you're probably appending shell to a python function and its getting confused Jan 30 11:38:00 yep this is it, thanks Jan 30 11:38:54 what is a better way than deleting the ./tmp/deploy/images/* files myself before creating an imagE? Jan 30 11:38:57 image* Jan 30 11:39:13 I think -c clean did not work for me. Jan 30 11:41:51 yeah, bitbake -c clean myimage does not clean that folder up. Jan 30 11:48:37 "README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt" -> perhaps, that file could document how to clean that folder up then? Jan 30 11:50:37 I think the best way to handle that directory would be a script, similar to the sstate management scripts Jan 30 11:50:58 there is RM_OLD_IMAGES Jan 30 11:51:02 my wish as a user is that it is simpler to copy files from there. Jan 30 11:51:18 (if I do not need to check the timestamp, etc, manually) Jan 30 11:51:21 er RM_OLD_IMAGE, that is Jan 30 11:51:26 and I have a cleaner feeling if only the latest is held in there. Jan 30 11:51:43 that is exactly what that variable does if set to 1 Jan 30 11:51:58 bluelightning: oh, sounds like a local.conf material? Jan 30 11:52:04 yes Jan 30 11:52:11 it's not in dylan though Jan 30 11:52:15 :-/ Jan 30 11:52:31 was introduced in dora Jan 30 11:52:51 right, thanks anyway Jan 30 11:53:02 well, one thing comes up while looking up its documentation... Jan 30 11:53:07 1) Open http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html Jan 30 11:53:14 2) Ctrl-f: RM_OLD_IMAGE Jan 30 11:53:16 3) Go there Jan 30 11:53:24 4) I cannot see any option for the "perma link". Jan 30 11:53:33 how can I easily share it then with others? Jan 30 11:53:48 yeah, we need a way to get permalinks for everything Jan 30 11:53:54 you can guess the link target though Jan 30 11:53:56 well, there is a way Jan 30 11:53:59 right Jan 30 11:54:01 the workarounds have been: Jan 30 11:54:03 1) Guesses Jan 30 11:54:09 2) Get a link to an existing based on a link. Jan 30 11:54:18 (and modify that), but it is suboptimal... Jan 30 11:54:21 is there a bug tracking this wish? Jan 30 11:54:28 bugreport* Jan 30 11:56:15 Xz: It appears there are iwlwifi-5000-*.ucode files in linux-firmware fwiw Jan 30 12:00:18 bluelightning: I solved my chown problem - /dev/shm/mydir must belong to the group I belong to Jan 30 12:01:16 bluelightning: RP: shouldn't something like that be in README? that directory you build yocto in must belong to the same group as user building? Jan 30 12:01:39 I am trying to build a package with depends on perl-native. But when the configure script for the package runs it can't find /usr/bin/perl. Why does perl-native install the perl binary to ${sysroot}/usr/bin/nativeperl Jan 30 12:01:45 bluelightning: RP: otherwise pseudo and chown complain about 'Operation not permited' Jan 30 12:01:57 Xz: I'd never realised that was an issue. We should add a check to sanity.bbclass Jan 30 12:02:07 dguthrie_: your recipe should "inherit perlnative" Jan 30 12:02:25 dguthrie_: did you inherit the perlnative class? Jan 30 12:02:34 if I delete the ./tmp/deploy/images myself, bitbake u-boot does not repopulate that folder with the u-boot binary. Jan 30 12:02:35 dguthrie_: if not, take a look at it and you'll understand why Jan 30 12:02:35 dguthrie_: the reason is, we don't want races between the host's perl and our own built version Jan 30 12:02:40 what could be the reason for that? Jan 30 12:03:05 ok thanks, will inherit from perlnative Jan 30 12:03:12 lpapp: because the stamp file exists telling the build system it doesn't need to deploy it again Jan 30 12:03:21 lpapp: bitbake doesn't track the files in there so it has no idea you deleted it. This is what the README you mentioned earlier warns about Jan 30 12:03:23 lpapp: this is *exactly* why that README_ file is there... Jan 30 12:03:27 bluelightning: but strangely enough, bitbake myimage repopulates that folder Jan 30 12:03:33 bluelightning: nope Jan 30 12:03:35 the image works just fine. Jan 30 12:03:36 lpapp: yep Jan 30 12:03:56 bitbake myimage will repopulate it, but bitbake u-boot will not. Jan 30 12:03:59 lpapp: images are always rebuilt, kernels and uboot come from deploy tasks which don't rebuild every time Jan 30 12:04:19 RP: well, in dylan they were Jan 30 12:04:20 dora is "fixed" in that it won't re-deploy if nothing has changed, right? Jan 30 12:04:21 RP: there is no need to rebuild, just redeploy. Jan 30 12:04:39 I am using dylan. Jan 30 12:05:25 rburton: correct Jan 30 12:05:42 rburton: wemade images use the full sstate checksums and only redeploy when they change Jan 30 12:06:20 bluelightning: so images are always reprocessed in dylan, but packages are not? Jan 30 12:06:29 lpapp: yes Jan 30 12:06:32 strange. Jan 30 12:06:44 lpapp: where by packages you mean other non-image recipes Jan 30 12:06:55 yeah Jan 30 12:07:45 ok, so "bitbake -c deploy -f u-boot" it is, thanks. Jan 30 12:15:47 is there any code name for the next release, already? Jan 30 12:23:16 drevil Jan 30 12:26:26 +1 Jan 30 12:31:52 lpapp: its not been announced yet Jan 30 12:32:11 bluelightning: rburton https://bugzilla.yoctoproject.org/show_bug.cgi?id=5772 Jan 30 12:32:12 Bug 5772: normal, Undecided, ---, melissa, NEW , Add easily obtainable permalinks to the variables in the documentation Jan 30 12:32:13 RP ok, thanks Jan 30 12:49:11 RP: Do you guys have reports that gcc 4.8.1/Linux-3.10 fail? Jan 30 12:49:35 Yocto is intending to move to python 3 in the next release? Jan 30 13:06:04 zecke: I haven't seen anything about that Jan 30 13:06:26 lpapp: we'll probably add recipes for it Jan 30 13:10:11 (someone told me it would) Jan 30 13:10:15 RP: too bad. I have weird return values on read from a AF_UNIX socket. strace itself getting stuck Jan 30 13:11:07 RP: I mean, things like bitbake move to python 3 in 1.6. Jan 30 13:16:52 eiy1quoo Jan 30 13:17:20 time to change that password anyway Jan 30 13:31:39 it's ok, only an internal one :) Jan 30 13:33:52 it's well and truly external now ;) Jan 30 13:34:59 it does not have an uppercase in it which is a usual requirement Jan 30 13:39:00 In dora. Which part of the kernel should depend on kmod? Jan 30 13:40:22 zecke: I thought you sent a patch for that ages ago... Jan 30 13:41:30 lpapp: the real one does have upper case; it a double typo ;) Jan 30 13:41:49 bluelightning: if i did.. it must have been for edison. We are now working on the dora upgrade for the BTS images. Jan 30 13:42:01 jackmitchell: :D Jan 30 13:42:10 zecke: hmm, I just checked back, maybe I was mistaken Jan 30 13:42:32 bluelightning: I sent patches for update-alternatives of uImage. Jan 30 13:44:51 bluelightning: so kernel.bbclass creates a postinst that will invoke depmod Jan 30 13:45:04 bluelightning: but there is no RDEPENDS that lead to the installation of kmod. :( Jan 30 13:45:31 zecke: I think we may have enabled depmod in busybox... Jan 30 13:45:55 bluelightning: that could explain. Jan 30 13:46:35 yes you do. We have a custom defconfig for busybox to enable ifplugd. :} Jan 30 13:47:43 at the same time systemd tries to execute /bin/kmod and that fails too Jan 30 13:49:27 zecke: systemd should have kmod in its RDEPENDS Jan 30 13:50:06 zecke: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=937968bf95e38dcdfc3e7791dc9efaf5f7613f24 Jan 30 13:50:13 khem: so how is the bitbake port work to python 3? Jan 30 13:52:13 bluelightning: haha. more stuff i broke. We kick out dbus from the RDEPENDS. :} Jan 30 13:52:32 zecke: you use systemd without dbus? Jan 30 13:53:48 bluelightning: without dbus-daemon Jan 30 13:54:03 bluelightning: it is using libdbus and communicates over AF_UNIX Jan 30 13:54:07 ah right Jan 30 13:54:37 zecke: FYI you should be able to use _remove in dora for that sort of thing now Jan 30 13:59:34 bluelightning: ah lovely! it appears to work. Jan 30 14:00:14 bluelightning: the BTS is just a TI Davinci DM644x.. a tiny arm core (by modern standards) no need to start daemons that take RAM and don't do useful things Jan 30 14:00:28 zecke: fair enough Jan 30 14:00:42 zecke: btw, are you or any of your colleagues by chance coming to FOSDEM? Jan 30 14:01:35 bluelightning: no one that is involved with the Yocto part but two colleagues will be there. I have to attend a funeral instead. :( Jan 30 14:01:51 zecke: ah, my condolences Jan 30 14:03:27 bluelightning: thanks. I intend to join ELCE and also hand in a talk about using Yocto to build our GSM basestation Jan 30 14:04:30 what is YOCTO #3847? Jan 30 14:06:40 TuTizz: https://bugzilla.yoctoproject.org/show_bug.cgi?id=3847 Jan 30 14:06:40 Bug 3847: enhancement, High, 1.5.1, tom.zanussi, VERIFIED FIXED, New partitioning description and tooling Jan 30 14:06:57 ok ty Jan 30 14:22:37 bluelightning/RP: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854. What is the procedure to get that into the Dora gcc 4.8? Jan 30 14:22:38 Bug 58854: was not found. Jan 30 14:31:13 if I change a patch, will Yocto re-apply it for bitbake -c compile -f virtual/kernel? Jan 30 14:31:40 if anything in SRC_URI changes, fetch and patch re-execute Jan 30 14:32:08 nothing changed. Jan 30 14:32:11 the patch changed itself. Jan 30 14:32:31 that's what i meant Jan 30 14:32:55 if SRC_URI points at a patch, then fetch/patch re-runs if it changes Jan 30 14:33:06 ok, but -c compile -f will not, right. Jan 30 14:33:12 correct Jan 30 14:33:20 bitbake virtual/kernel will recreate the ipkg though? Jan 30 14:33:24 you'er asking explicitly to run compile Jan 30 14:33:26 yes Jan 30 14:33:41 rburton: well, yes and no. Jan 30 14:33:48 bitbake virtual/kernel seems to return instantly. Jan 30 14:33:53 even though I did modify a patch Jan 30 14:33:56 I added three lines. Jan 30 14:34:01 it should rebuild the kernel :-/ Jan 30 14:34:15 yes it should Jan 30 14:35:01 might be some bug somewhere. Jan 30 14:57:58 yoctoproject.org/dev-manual says that in order to submit a patch user has to do 'git format-patch -1' or 'git format-patch HEAD~' Jan 30 14:58:07 don't we want people to use -M flag to git-format-patch? Jan 30 14:58:26 you can Jan 30 14:58:33 lpapp or khem I think was suggesting that yesterday to me Jan 30 14:58:40 do we want to improve doc? Jan 30 14:58:45 and add that -M flag? Jan 30 14:58:52 no idea who is responsible for doc Jan 30 14:59:19 Xz: Scott, yeah, why not. Jan 30 14:59:39 Xz: yes we should fix that in the manual Jan 30 14:59:49 is it 'scot' on this channel? Jan 30 15:00:11 have never seen him here. Jan 30 15:00:19 opk Jan 30 15:00:20 but no Jan 30 15:00:24 could you msg me email? Jan 30 15:00:45 scott.m.rifenbark@intel.com Jan 30 15:00:51 cool, thanks Jan 30 15:26:08 how do I do tell bitbake to use different (shared) download directory? Jan 30 15:26:53 set DL_DIR Jan 30 15:27:05 (if you want to read/write into a local directory) Jan 30 15:27:27 rburton: DL_DIR is rw? so if anything must be downloaded bitbake will use it? Jan 30 15:28:15 DL_DIR is where bitbake's fetchers will check first for files to download, and will put anything it downloads into there Jan 30 15:28:29 (so you really want to share DL_DIR between all of your build directories) Jan 30 15:28:31 cool, is it bitbake or bash variable? Jan 30 15:28:40 bitbake, see your local.conf Jan 30 15:34:03 rburton: thanks, works Jan 30 15:34:49 Xz: this is the sort of thing you can put into a shared site.conf that you copy between all your build folders, if you have several Jan 30 15:35:17 rburton: where do you put site.conf? under conf/ ? Jan 30 15:35:24 that's one place Jan 30 15:35:25 rburton: I'm not using site.conf so far Jan 30 15:35:27 ok Jan 30 15:35:42 personally i have a meta-ross that i add to bblayers, that has a site.conf in it Jan 30 15:36:04 rburton: nice trick Jan 30 15:36:25 i usually set up my bblayers.conf ot include ~/.oe, and put it there Jan 30 15:36:27 lots of ways to do it :) Jan 30 15:36:42 guys, on dylan sanity checker does not catch wrong git version: git version 1.7.12.2 Jan 30 15:37:00 downside to the ~/.oe approach is that you can forget it's there, since its largely out of sight :) Jan 30 15:40:49 anybody goes to FOSDEM'14 ? Jan 30 15:41:01 in Brussels, 1&2 February 2014 Jan 30 15:41:20 Xz: yep, I'll be there Jan 30 15:41:37 Xz: Beth and Belen are also going Jan 30 15:41:42 Xz: and a lot of others Jan 30 15:41:51 Xz: http://openembedded.org/wiki/FOSDEM_2014 Jan 30 15:42:04 will talk to my boss about it Jan 30 15:42:07 :) Jan 30 15:42:38 it's a pity it's so soon Jan 30 15:42:50 I'm working on one demo-robot Jan 30 15:47:46 do you know where do I fix sanity checker for dylan's git version ? Jan 30 15:49:58 Xz: are you also working for intel? Jan 30 15:53:04 bluelightning: if Belen did a presentation I would jump on the first flight :-D Jan 30 15:53:45 mckoan: why ? Jan 30 15:54:57 lpapp: as I told her at ELCE her talks are great like the TED ones :-D Jan 30 15:55:30 probably a matter of charisma ;-) Jan 30 15:59:13 mckoan: ok Jan 30 17:07:41 why is poky not depending on u-boot, but poky-tiny does? Jan 30 17:36:33 what is the point of the nobase.patch? Jan 30 17:37:58 RP: would you accept me splitting this patch into two logical? http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/base-passwd/base-passwd/nobash.patch#n6 Jan 30 17:38:09 RP: that way, it would be easier for me to drop one, and keep the other logical change. Jan 30 17:38:19 IMO, removing "*" is a strange idea... Jan 30 17:38:31 the other change could probably be even upstreamed. Jan 30 17:40:12 lpapp: I support splitting it in 2, it would save me few lines in .bbappend Jan 30 17:41:05 the problem is that even with 2 patches only 2nd one can be dropped without causing the conflict :) Jan 30 17:41:33 do_configure_prepend() { # nobash.patch has interesting side-effect which we still need sed -i 's%^root:[^:]*:%root::%g' ${S}/passwd.master Jan 30 17:41:43 is what I have Jan 30 17:42:11 JaMa: oh, I was just writing an email to openembedded-core in parallel. Jan 30 17:42:12 JaMa: why dont you have image post process function to sed it to whatever value you want Jan 30 17:42:49 JaMa: we need the /bin/sh part, but the /etc/shadow part breaks for us. Jan 30 17:43:05 also, the /etc/shadow part is not in scope for that change based on the change name. Jan 30 17:43:14 filename* Jan 30 17:43:38 JaMa: I am not sure why the no bash part is not upstreamed? Jan 30 17:44:56 do you know the reason for that? Jan 30 17:45:04 I can understand that the shadow part cannot be upstreamed. Jan 30 17:45:43 JaMa: yes, we do such a nasty sed, too! Jan 30 17:45:51 well, something similar. Jan 30 17:49:53 hm, how can I easily disable the banner.sh init script? I want *no* text output to the device's screen, and ideally the splash screen to remain visible until a custom graphical app starts. Jan 30 17:53:05 JaMa: something like this, git show | curlpaste Jan 30 17:53:06 http://codepad.org/lwC4NCOS Jan 30 17:53:06 ? Jan 30 17:54:00 danielki: in poky psplash does a chvt, so you can't see any text output until X starts Jan 30 17:54:20 all you can see is the splash until X does a chvt Jan 30 17:54:39 lpapp ~/Projects/openembedded-core $ . oe-init-build-env Jan 30 17:54:40 Error: The bitbake directory (/home/lpapp/Projects/openembedded-core/bitbake) does not exist! Please ensure a copy of bitbake exists at this location Jan 30 17:55:01 lpapp: oe-core doesn't contain bitbake Jan 30 17:55:36 ah ok, then my problem is probably that I need to get the custom app executed before that chvt. Incidentally, where to best put a startup command? Classic init script? Jan 30 17:56:01 danielki: the chvt from X? Jan 30 17:56:01 rburton: seems so, yes. Jan 30 17:56:20 rburton: this device is not running X Jan 30 17:56:23 ah Jan 30 17:56:37 danielki: what are you using for splash? Jan 30 17:56:42 psplash Jan 30 17:57:27 hm, can't recall what the procedure is for non-x boots Jan 30 17:57:32 maybe I should simply disable the framebuffer console in the kernel config Jan 30 18:00:59 rburton: splash with systemd needs love in OE Jan 30 18:01:24 rburton: I have dietsplash working but something more robust would be nicer Jan 30 18:01:36 in general, systemd needs love IMHO. :) Jan 30 18:02:52 rburton: if I understand correctly, for a real minimal distribution, you only need your own layer, openembedded-core and bitbake. Is that right? Jan 30 18:03:06 lpapp: correct Jan 30 18:03:13 lpapp: that's all poky is, after all Jan 30 18:04:05 yes, but I do not need poky in the future. Currently, we require it in our distro config, but I would like to eliminate it. Jan 30 18:04:28 It is probably not a big work... probably a bit of fiddiling in the layers config and removing the requires from our distro config, and that is pretty much it? Jan 30 18:04:35 fiddling* Jan 30 18:05:14 sure, it's trivial Jan 30 18:07:01 we would still get the Yocto release though, I guess? Jan 30 18:07:14 because Yocto puts openembedded-core and bitbake together to work. Jan 30 18:08:36 I think it was something like LCONF_VERSION = "5" instead of "6" Jan 30 18:08:44 if I get rid of poky, right? Jan 30 18:08:52 yes Jan 30 18:09:01 the bump was due to poky splitting layers Jan 30 18:09:28 when the YP does a release cycle you'll get new bitbake and oe-core alongside poky releases, all simultaneously (as poky is simply the union of other repos) Jan 30 18:09:51 yes Jan 30 18:10:06 but it is still recommended to stick to those releases for oe-core users, right? Jan 30 18:10:22 I am not even sure if oe-core is released separately... Jan 30 18:10:28 (or bitbake for that matter) Jan 30 18:10:44 released, yes. tarballs of said releases, maybe not for oe-core. Jan 30 18:12:05 i tend to recommend git clones following the stable branches. Jan 30 18:12:59 rburton: is there any other place where I need to look for modifications others than the distro.conf and bblayers.conf to eliminate the needless in-between poky layer? Jan 30 18:14:55 once you've fixed bblayers.conf its entirely in your distro conf Jan 30 18:15:10 just copy into it the pieces you want from poky.conf Jan 30 18:15:19 lpapp: that paste doesn't show .bb change, but something like that Jan 30 18:15:35 lpapp: image postprocess function don't play nice with package-management Jan 30 18:15:47 first base-passwd upgrade on target would break root account Jan 30 18:16:26 JaMa: yes, I have done the .bb change after posting that. Jan 30 18:16:38 JaMa: I think you addressed the second to khem? Jan 30 18:16:46 JaMa: why was the bash to sh change not upstreamed? Jan 30 18:17:02 no one has cared yet, or it is invalid upstream? Jan 30 18:17:48 rburton: ok, thanks Jan 30 18:17:55 btw, openembedded-core does not build here from master, http://pastebin.kde.org/pivhwqbtl Jan 30 18:18:06 with master bitbake, literally cloned both a few minutes ago. Jan 30 18:18:53 1. | Makedoc.sh: line 65: /tmp/ldt.cfrIky9Jqa/linuxdoc: Permission denied Jan 30 18:18:57 can you check permissions on your /tmp? Jan 30 18:19:31 * rburton afk Jan 30 18:21:25 ls -ld /tmp Jan 30 18:21:27 drwxrwxrwt 15 root root 420 Jan 30 18:10 /tmp Jan 30 18:22:19 1777, as it should. Jan 30 18:22:32 touch /tmp/foo works Jan 30 18:28:00 lpapp: ah sorry, yes it was for khem Jan 30 18:28:26 I didn't notice it was him speaking in the middle as you both have nick with the same length :) Jan 30 18:28:34 JaMa: hmm yes O_P_M will miss out Jan 30 18:28:50 use colors Jan 30 18:28:54 :) Jan 30 18:29:26 all people are yellow when talking to me :) Jan 30 18:30:43 irssi ? Jan 30 18:31:17 JaMa: maybe he meant different yellows. :) Jan 30 18:32:26 rburton: Removing framebuffer console support from the kernel did the trick :) Jan 30 18:32:32 so if I understand correctly, the bblayers.conf should not even be checked into our PDK repository. Is that correct? Jan 30 18:32:35 khem`: yes Jan 30 18:32:39 It will be generated on the fly out of the sample. Jan 30 18:51:50 JaMa: http://patchwork.openembedded.org/patch/66103/ Jan 30 18:58:39 lpapp: noshadow.patch should probably mention Kevin Tian, but otherwise looks good Jan 30 19:58:48 khem, ping. build worked with new patches, but it doesn't run: Jan 30 19:59:00 # python3 Jan 30 19:59:00 Traceback (most recent call last): Jan 30 19:59:00 File "/usr/lib/python3.3/site.py", line 69, in Jan 30 19:59:00 import os Jan 30 19:59:00 File "/usr/lib/python3.3/os.py", line 659, in Jan 30 19:59:01 from collections.abc import MutableMapping Jan 30 19:59:02 ImportError: No module named 'collections' Jan 30 20:00:37 taking a look now Jan 30 20:01:44 looks like you need to have python3-misc installed by default or nothing will run. testing now. Jan 30 20:04:45 mebrown: yes Jan 30 20:05:10 thanks for reporting it Jan 30 20:05:26 the packagegroup I have always installs python3-misc Jan 30 20:05:43 And I'm still using my old config of cherry picking just the modules I need. Jan 30 20:05:48 it works fine now. Jan 30 20:05:52 thanks for the help Jan 30 20:06:14 Now I can start the "real" work of porting my app. Jan 31 01:30:35 I have a build issue. I'm trying to write a Bitbake recipe for jsoncpp, which uses SConstruct. My .bb is at http://www.rafb.me/results/pwDFfZ25.html. Jan 31 01:31:06 When I run the script, Bitbake complains that: Jan 31 01:31:08 | DEBUG: Executing shell function do_compile Jan 31 01:31:09 | Traceback (most recent call last): Jan 31 01:31:11 | File "/home/ecocar/msu-community-bsp/build_mx6/tmp/sysroots/x86_64-linux/usr/bin/scons", line 187, in Jan 31 01:31:12 | import SCons.Script Jan 31 01:31:14 | ImportError: No module named SCons.Script Jan 31 01:31:23 (Apologies for pastebomb.) What gives? Jan 31 01:47:42 thirtythreeforty: you have not shown the recipe. Jan 31 02:47:00 lpapp, yes I did. It is at http://www.rafb.me/results/pwDFfZ25.html. **** ENDING LOGGING AT Fri Jan 31 02:59:58 2014