**** BEGIN LOGGING AT Fri Jun 03 02:59:58 2016
Jun 03 06:26:41 <qt-x> how to smitch to python 3 ?
Jun 03 06:26:46 <qt-x> switch
Jun 03 08:46:10 <turab> hi, i'm having trouble building krogoth for an imx6 board
Jun 03 08:46:28 <turab> i used Win32DiskImager to copy the .sdcard file, but it doesn't boot
Jun 03 08:46:46 <turab> i found that the gz compressed version is only 7 KB. that doesn't sound right
Jun 03 08:48:24 <turab> followed the instructions on https://github.com/Freescale/fsl-community-bsp-platform, changing jethro to krogoth and adding MACHINE=imx6dl-riotboard when executing setup-environment
Jun 03 08:51:35 <turab> ~49 KB* sorry
Jun 03 08:56:08 <navaati> hi
Jun 03 08:56:51 <navaati> i'm interested in booting my board over nfs, to avoid constantly reflashing
Jun 03 08:58:55 <navaati> however yocto only offers booting qemu on nfs, via a userspace server. Is there a way to use this server on the real network ?
Jun 03 09:38:05 <mckoan> navaati: install nfs-server on your host and configure it, then unpack the .bz2 filesystem resulting from Yocto build and use it
Jun 03 09:42:36 <mckoan> turab: pastebin the content if the final directory (where you have the .sdcard file) using the command ls -al
Jun 03 09:49:31 <turab> mckoan: http://pastebin.com/raw/AnVbPX6R
Jun 03 09:50:29 <turab> note that i replaced sdcard.gz with uncompressed
Jun 03 09:52:07 <mckoan> turab: your file looks perfect
Jun 03 09:52:19 <mckoan> turab: core-image-minimal-imx6dl-riotboard-20160602154517.rootfs.sdcard is 41MB
Jun 03 09:53:07 <turab> i might be being stupid in assuming i'll see any output through HDMI
Jun 03 09:53:31 <turab> i don't have any cable to use the serial port for now
Jun 03 09:55:00 <mckoan> turab: you might insert your SD in your PC and set a static IP in /et/network/interface, then connect to the board with ssh
Jun 03 09:55:26 <mckoan> turab: BTW a serial cable would be the best option when starting with a new board
Jun 03 09:55:51 <navaati> mckoan, i'd like to avoid the kenrel nfs server for some reasons (didn't find a way to restrict it to only one network interface)
Jun 03 11:58:23 <RP> halstead: centos7 is near enough locking up again. There is something about python3 that is unwell on there :(
Jun 03 14:17:25 <TwisteR> cc1plus: internal compiler error: Segmentation fault
Jun 03 14:17:51 <TwisteR> how to avoid this kind of problems during "bitbaking"?
Jun 03 14:18:43 <rburton> what recipe was being built?
Jun 03 14:18:47 <TwisteR> I've tried jethro branch — compiler segfault on qemu
Jun 03 14:19:27 <TwisteR> now I'm trying krogoth — this time qtbase-native
Jun 03 14:19:51 <rburton> so thats your host compiler breaking, not our one
Jun 03 14:20:12 <TwisteR> rburton: qt5-image (from https://github.com/jumpnow/meta-wandboard)
Jun 03 14:20:23 <TwisteR> yes, I realise that
Jun 03 14:20:29 <rburton> report a bug to your distro, its their gcc that is crashing
Jun 03 14:21:22 <TwisteR> maybe I should try not to use parallel build?
Jun 03 14:22:10 <TwisteR> is there a way to pass some kind of '-j 1' to bitbake?
Jun 03 14:23:40 <CTtpollard> TwisteR: yes, PARALLEL_MAKE="" in local.conf
Jun 03 14:23:52 <JaMa> disabling parallel build won't prevent our native gcc from segfaulting
Jun 03 14:24:09 <JaMa> you can also check your disks and ram
Jun 03 14:24:47 <TwisteR> they are ok. The problem persists on the same .c file and line, when I re-launch bitbake
Jun 03 14:43:10 <TwisteR> CTtpollard: thanks, single-threaded build helped this time :)
Jun 03 14:43:43 <TwisteR> now continue bitbaking with parallel build...
Jun 03 14:45:30 <rburton> if a single threaded build stops gcc segfaulting, i'd be worried about thermal or memory issues
Jun 03 14:46:02 <rburton> (parallel oe builds can be used quite effectively as a stress test for hardware)
Jun 03 14:49:26 <TwisteR> rburton: maybe you are right, but two previous builds was finished with segfault on exactly the same file. So, I believe, compiler is under suspiction.
Jun 03 14:50:54 <rburton> indeed, but thermal load can do that
Jun 03 14:52:02 <TwisteR> anyway, thanks for tips!
Jun 03 16:02:06 <halstead> RP, centos7 is also the last builder using xfs. I can replace it with ubuntu1604 and ext4 if that is helpful.
Jun 03 16:03:08 <RP> halstead: literally just sent you an email. It depends what is wrong with centos7 really, whether its python3 in our external tarball, xfs, SMACK or something else :/
Jun 03 16:03:32 <RP> halstead: feel free to kill the current builds, the -next running is basically totally broken.
Jun 03 16:03:58 <RP> halstead: ubuntu 1604 might be more reliable
Jun 03 16:04:32 <halstead> RP, I just started looking. I have a somewhat responsive console as long as I don't try to list any directories.
Jun 03 16:39:49 <halstead> RP, It appears filesystem related. Can I kill both nightly builds do the week's maintenance and replace centos7 with ubuntu1604?
Jun 03 16:42:14 <RP> halstead: yes please!
Jun 03 18:13:50 <kergoth> Hmm
Jun 03 18:14:27 <kergoth> would be nice if it was easier to do a runqemu on a different machine from the one with the oe/poky build
Jun 03 19:53:59 <kergoth> RP: looks like bb.utils.vercmp_part() tries to compare against None, which breaks under 3. probably want to change that to 0 or something where the comparison will at least be valid and consistent?
Jun 03 19:54:11 <kergoth> causes a parse faliure for netmap-modules in meta-networking
Jun 03 19:54:20 <kergoth> i'll submit a patch if that seems reasonable
Jun 03 19:55:17 <kergoth> hmm
Jun 03 19:56:37 <kergoth> easy enough to work around in the recipe by nto passing None in, but the semantics of the function do specifically handle that case at the moment
Jun 03 20:18:32 <fmeerkoetter> i have updated the SRCREV for a recipe to a newer git id.
Jun 03 20:18:55 <fmeerkoetter> bitbake -c fetch qtbase (the package in question) fails
Jun 03 20:19:20 <fmeerkoetter> it tells me: unable to find revision
Jun 03 20:19:30 <fmeerkoetter> but i know that it is there :-)
Jun 03 20:19:47 <fmeerkoetter> i've cloned the repo bitbake is testing myself
Jun 03 20:20:01 <fmeerkoetter> a "git show" will find the id
Jun 03 20:21:33 <fmeerkoetter> happens with all the repos of the qt project
Jun 03 20:21:38 <fmeerkoetter> not only with qtbase
Jun 03 20:22:20 <fmeerkoetter> any idea what i am doing wrong?
Jun 03 20:31:29 <fmeerkoetter> ok, got it
Jun 03 20:31:42 <fmeerkoetter> the answer is the with the RC1 there is a new branch
Jun 03 20:31:45 <fmeerkoetter> 5.7.0
Jun 03 20:31:57 <fmeerkoetter> the fetcher checked on 5.7
Jun 03 21:16:50 <RP> kergoth: interestingly when we fix the codeparser cache, overall build times do improve slightly
Jun 03 21:17:19 <RP> kergoth: that does seem reasonable, a patch would be welcome
Jun 03 22:26:01 <nerdboy> https://bpaste.net/raw/10a39014105b  <=  something choking perl ptest on krogoth?
**** ENDING LOGGING AT Sat Jun 04 02:59:58 2016