**** BEGIN LOGGING AT Wed Oct 19 02:59:58 2016 Oct 19 07:31:56 Curl will release a new verision on Nov 2nd with 11 security advisories, are the upcoming release maintainers aware of this?? Oct 19 07:32:00 https://curl.haxx.se/mail/lib-2016-10/0076.html Oct 19 08:16:50 huh, anyone experienced root losing access to poweroff/reboot? Oct 19 08:16:58 root@zero-gravitas:~# poweroff Oct 19 08:16:59 poweroff: must be superuser. Oct 19 08:17:11 root@zero-gravitas:~# id Oct 19 08:17:11 uid=0(root) gid=0(root) groups=0(root) Oct 19 08:17:36 hmm, never seen that anywhere else, so I'm thinking it must be something I fucked up in my local.conf Oct 19 08:20:54 what about init 0? Oct 19 08:26:31 ah, I'll try that next time I boot the board Oct 19 08:26:42 but both «reboot -p» and «poweroff» refused Oct 19 08:44:16 LocutusOfBorg: Any words of wisdom for today? Sent you an e-mail about the objcopy issue I am having with exported sdk. Oct 19 08:50:47 muppe, I'll look soon Oct 19 08:51:26 no problem. I added this one in qmake.conf: QMAKE_OBJCOPY = arm-poky-linux-gnueabi-objcopy Oct 19 08:51:40 Seems to work now. Maybe something explodes later... Oct 19 09:28:40 fragfutter: init 0 worked, thanks! Oct 19 09:43:52 if i enable x11 distro feature, mesa-gl becomes part of the build Oct 19 09:44:15 not sure which recipe enables it for x11 Oct 19 09:45:14 zeenix: can't answer for that specific case, but http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#usingpoky-viewing-dependencies-between-recipes-and-tasks might be helpful Oct 19 09:45:53 generate task-depends.dot and search for mesa-gl dependencies in it Oct 19 09:46:17 Ulfalizer: well `bitbake -g -u depexp ` shows depends for mesa-gl Oct 19 09:46:24 but not rdeps Oct 19 09:46:49 which is why i thought it's likely being enabled for distro feature rather than some other recipe's requirement Oct 19 09:47:19 If I wanto to modify the kernel configuration for my build, it's enough modifying the defconfig file that is in sources/meta-somelayer/recipes-kernel/linux/ Oct 19 09:47:44 ? Oct 19 09:47:55 you should still get some kind of task dependency in there i think. otherwise there'd be no guarantee that the mesa-gl packages are generated. Oct 19 09:49:09 can't remember the details off the top of my head, but i'm pretty sure distro features just trickle through to settings inside recipes and bbclasses as well Oct 19 09:49:20 everything's done via tasks in the end Oct 19 09:49:54 Ulfalizer: will check but the issue is mesa-gl *is* being built Oct 19 09:50:56 zeenix: did you check task-depends.dot? anything related to mesa-gl in it? Oct 19 09:51:36 see the paragraph that starts with "to ensure that the..." in http://www.yoctoproject.org/docs/2.2/ref-manual/ref-manual.html#var-RDEPENDS as well. it was rewritten recently. Oct 19 09:53:22 file is in the process of being opened :) Oct 19 09:53:37 or dotty is hung Oct 19 09:54:02 use a text editor. without pruning, the graph is completely unreadable. :) Oct 19 09:54:13 the format is human-readable Oct 19 09:57:03 scripts/contrib/graph-tool might be useful too Oct 19 09:59:43 hmm.. dot file points to two culprits Oct 19 09:59:46 i'll check them.. Oct 19 10:18:50 muppe, interesting issue Oct 19 10:20:03 not sure why it isn't run Oct 19 10:20:12 do you run the qmake from the yocto /opt sdk? Oct 19 10:24:09 LocutusOfBorg: /opt/xxxxx_raspberrypi3/2.0.2/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake Oct 19 10:27:54 interesting I remember some qmake.conf somewhere Oct 19 10:28:09 it should have the correct values, unfortunately I don't have anymore my sdk with qt5 stuff inside Oct 19 10:28:14 I deleted it a while ago :) Oct 19 10:28:32 I would like to know if maybe your qmake files have something hardcoded Oct 19 10:28:38 because I don't remember such issues Oct 19 10:30:37 haven't touched them (at least no intentionally). Just created the sdk, ran the env setup and ran qmake. Oct 19 10:56:07 but you need to rerun qmake Oct 19 10:56:11 to generate new Makefiles Oct 19 10:59:09 I'm pretty sure I did that. Oct 19 11:03:38 not sure sorry :/ Oct 19 11:13:14 LocutusOfBorg: the makefile is supposed to re-run qmake if necessary Oct 19 11:14:58 mmm if you change the CC? Oct 19 11:15:03 not really sure Oct 19 11:15:06 $(CC) I mean Oct 19 14:02:28 which conf file has all the ENV variables like ${STAGING_DIR} set? Oct 19 14:05:23 something is triggering a rebuild of linux-yocto every time I try to build my image. Is there something more fine grained than bitbake-whatchanged to figure out why that is happening? Oct 19 14:06:16 bitbake-whatchanged's output includes lots and lots of recipes, but I suspect that there's one or two that are causing this Oct 19 14:24:21 m2: bitbake-diffsigs -t? Oct 19 14:30:31 so if I have two versions of a recipe, how does yocto determine which version to use in a image layer specifciation? Oct 19 14:36:46 higher, by default Oct 19 14:37:03 you can set PREFERRED_VERSION if you want to pick a specific version Oct 19 14:37:25 and layer priorities will kick in too, a higher priority layer with a lower version will still pick the lower version if everything else is equal Oct 19 14:38:01 yes, i recall layer priorities now. Geez been a long time. many thanks Oct 19 14:42:06 so i am getting a could not inherit file classes/python3-dir.bbclass Oct 19 14:42:44 and I have python3 in my native version Oct 19 14:42:56 this means that my target does not have a python3 Oct 19 14:43:24 which makes sense, i don't see that in my classes as available Oct 19 14:46:02 Hi all. Is there a known issue with gdb on jethro? When i run my binary w/o gdb it runs just fine, but if i start it with gdb i get this: http://pastebin.com/raw/JmTF5UHp Oct 19 14:50:42 davis: it means you're using meta-python or similar from master, but not oe-core master Oct 19 14:51:59 i guess, i see that our fs has python3 for native but not for the target, Im rsyncing things over, generally making a mess of things. im optimistic something positive will shake out. Oct 19 15:10:08 Does anybody know in which python package the module 'netrc' is packaged? Oct 19 15:11:00 because i cant find it anywhere in the .bb or inc Oct 19 15:13:52 fl0v01: use oe-pkgdata-util Oct 19 15:13:53 $ oe-pkgdata-util find-path '*/netrc.py' Oct 19 15:13:53 python3-misc: /usr/lib/python3.5/netrc.py Oct 19 15:13:53 python-misc: /usr/lib/python2.7/netrc.py Oct 19 15:14:11 (or when in doubt just pull in python-modules, and get the entire library) Oct 19 15:14:14 Thanks! Didnt knew about this tool Oct 19 15:26:11 hi Oct 19 15:27:24 i changed something in defconig, but when I recompile it, it doesn't create a new image. how can this be? Oct 19 15:38:03 did you tell bitbake to make a new image? Oct 19 15:38:35 how? Oct 19 15:38:51 bitbake myimagename Oct 19 15:38:59 yes i did Oct 19 15:39:21 what do you mean by changed something in defconfig? where did you change it? in your layer, or in the source tree? Oct 19 15:39:48 if you changed it in the build tree then you need to do bitbake mykernel -C compile to tell it that it needs to rebuild Oct 19 15:39:50 i changed one value in this file: https://github.com/mytechpg/meta-mytechpg/blob/master/recipes-kernel/linux/files/6002_mptcp.cfg Oct 19 15:40:02 sorry wasn't defconfig Oct 19 15:40:09 that suggests that the config file wasn't actually being pulled in Oct 19 15:46:02 looks like bitbake mykernel -C compile solved it but, now i'm getting these errors: "Taskhash Mismatch" and "is tainted from a force run" Oct 19 15:47:12 the taint message isn't an error. it's a warning, and is expected. the -C and -f arguments force tasks to run despite bitbake's awareness, tainting the checksum until it's cleaned Oct 19 15:48:14 to solve the taskhash mismatch i do compile as long as the error is gone? Oct 19 15:58:02 khem: Hmm, I wonder what would happen if I tried to use meta-clang with meta-sourcery. would it work? Oct 19 15:58:05 * kergoth adds to his list Oct 19 16:03:51 there is a new image, but it's still the same value in the above mentioned file. Oct 19 16:15:26 neverpanic: thanks, I'm trying that... Oct 19 17:06:01 I'm trying to build an image as readonly and keep getting errors with pixbuf. Looking at the `intercept_scripts/update_pixbuf_cache` script it is trying to call qemuwrapper which can't be found. What is the qemuwrapper? Oct 19 18:32:50 kergoth: meta-clang should work fine with sourcery Oct 19 18:33:04 kergoth: it does not replace core toolchain Oct 19 18:33:25 khem: Yet. ;) Oct 19 18:33:28 it just adds another one into the mix Oct 19 18:33:44 behanw: heh yes Oct 19 18:33:56 that's what i was thinking, k, will give it a shot. i'm wondering if the multilib configuration could mismatch Oct 19 18:34:20 kergoth: yeah multilib stuff is untested with meta-clang Oct 19 18:34:28 * kergoth nod Oct 19 18:34:28 khem: Great work on meta-clang btw! Oct 19 18:34:39 behanw: thx Oct 19 18:34:59 right now I moved master to use 4.0.0 ( trunk ) Oct 19 18:35:08 Cool Oct 19 18:35:18 nice Oct 19 18:35:19 if someone is interested then we have 40 odd pakages to fix Oct 19 18:35:31 http://errors.yoctoproject.org/Errors/Build/23323/?limit=50 Oct 19 18:35:40 http://errors.yoctoproject.org/Errors/Build/23329/?limit=50 Oct 19 18:35:57 this include meta-openembedded btw Oct 19 18:36:13 oe-core is much cleaner Oct 19 18:36:36 some of the warning messages are amusing Oct 19 18:37:14 seems many are -Wreturn-type errors only ;-) Oct 19 18:37:29 rob_w: there are mix Oct 19 18:37:45 I also saw a clang crash for x86 Oct 19 18:37:54 which I need to narrow down Oct 19 18:38:01 khem: Some are disturbing as well. Oct 19 18:38:17 Possible pointed misalignment in mdadm on Intel. Oct 19 18:38:22 Not that Intel can't handle that Oct 19 18:38:36 But it's worrying that it was designed that way Oct 19 18:38:51 (with a packed structure with possible pointer misalignment Oct 19 18:39:13 behanw: yeah Oct 19 18:39:18 *sigh* Oct 19 18:39:30 there is all sort of stuff its discovering Oct 19 18:40:04 Seems clang is still giving more useful feedback to developers than gcc... Oct 19 18:40:17 Despite gcc's many advances to close the gap. Oct 19 18:41:01 that's actually why i started thinking about trying to use meta-clang with meta-sourcery, i wanted to use clang for a specific recipe to see if it gave me an error that was easier to make sense of ;) Oct 19 18:41:34 kergoth: I'm not sure if they still do it, but google used to compile all their C++ code with gcc and clang. Oct 19 18:41:44 that's interesting Oct 19 18:42:12 if success, the binary from gcc was used, but the error output from clang was returned from the compile cluster on error Oct 19 18:42:39 Only reason clang binary isn't used (yet) is long history of gcc binary testing at google Oct 19 18:43:12 gcc has improved since then of course. Oct 19 18:43:43 But compiling with 2 compilers is actually a great way to make sure your code is valid. Oct 19 18:44:06 Since the C-standard is interpreted differently by different compiler implementations. Oct 19 18:44:09 behanw: the fact now we have colored diagnostics in gcc and gcc being compiled using g++ indicates that clang has put gcc feet to fire in positive way Oct 19 18:44:21 khem: Yup Oct 19 18:44:28 Though it took them years to do that. ;) Oct 19 18:44:34 when I was asking for it as a young lad I was told to shut up Oct 19 18:45:09 I just used colorgcc Oct 19 18:45:27 yeah I know. Oct 19 18:45:30 Funny how the gcc ecosystem mostly is made of wrappers. Oct 19 18:45:37 my fad for eyecandy stuff never leaves me Oct 19 18:45:48 And the clang ecosystem has all sorts of tools containing clang compiler tech. Oct 19 18:46:02 khem: #eyecandyallthethings Oct 19 18:46:36 I suppose gcc has many plugins now. But many of those have been ported from clang. Oct 19 18:46:38 Just sayin' Oct 19 18:46:43 may be thats why I use KDE, osx atom.io Oct 19 18:46:49 list is lonh Oct 19 18:47:00 LOL. Both have a lot of eye candy. Oct 19 18:47:10 Atom is indeed an impressive modern editor. Oct 19 18:47:11 yes gcc is lot better Oct 19 18:47:21 than before no dowbt Oct 19 18:47:32 c++ compliance has improved leaps and bounds Oct 19 18:48:01 Indeed. Oct 19 18:48:08 And gcc extensions lessened. Oct 19 18:48:10 Thank goodness. Oct 19 18:49:15 I will keep knocking the compatibility issues and submit them upstream whenever I have time Oct 19 18:49:32 I wish I had more time... Oct 19 18:49:57 one usecase we can drive is the static analyser, we have a class for coverity internally, I dont see why we cant extend that to clang scanner Oct 19 18:50:13 Exactly Oct 19 18:50:16 that itself is a good usecase Oct 19 18:53:30 kergoth: layer has some bbappends so keep that in mind they may not be fully covered by toolchain-clang override Oct 19 19:38:16 behanw: as of last year I still heard the 'we compile with clang just for the error messages' story, so I'd expect this to be still current Oct 19 19:39:01 neverpanic: Thanks for the update Oct 20 00:59:30 Hi Oct 20 02:28:56 neverpanic: some projects have been using clang for more eg. webkit **** ENDING LOGGING AT Thu Oct 20 02:59:59 2016