**** BEGIN LOGGING AT Mon Jan 12 02:59:59 2015
Jan 12 08:12:26 <mckoan> good morning
Jan 12 08:12:52 <nrossi> mckoan: good morning (although its evening here ;))
Jan 12 08:17:59 <woglinde> gm
Jan 12 08:26:17 <mckoan> nrossi: that's UGT :-D
Jan 12 08:26:25 <mckoan> woglinde: hi
Jan 12 08:39:37 <hrw> ~ugt
Jan 12 08:39:37 <infobot> i heard ugt is Universal Greeting Time. Created in #mipslinux, it is a rule that states that whenever somebody enters an IRC channel it is always morning, and it is always late when the person leaves. The local time of any other people in the channel, including the greeter, is irrelevant. http://www.total-knowledge.com/~ilya/mips/ugt.html
Jan 12 09:03:11 <pwgen> woglinde: found my problem. the oe toolchain is too old and does not support armv7l. seems that there is at least autoconf latest needed.
Jan 12 09:08:47 <koen> pwgen: not a newer gnu-config?
Jan 12 09:08:57 <koen> that's usually the only bit that needs updating
Jan 12 09:11:14 <pwgen> @koen: the fir package that fails is autoconf. config.sub is missing support for armv7l is onlit armv[2345]l supported.
Jan 12 09:11:44 <pwgen> its  autoconf-naitive   not autoconf. 
Jan 12 09:16:17 <koen> config.* will be regenerated by running gnu-configize
Jan 12 09:16:29 <koen> so updating gnu-config and runnning gnu-configize should work
Jan 12 09:16:52 <koen> it's what I did for avr32 and aarch64 autotools issues way back when
Jan 12 09:19:40 <pwgen> hmm gnu-config_git failed with "config-guess-uclibc.patch"
Jan 12 09:24:41 <woglinde> pwgen the toolchain is not to old as koen said
Jan 12 09:25:08 <woglinde> icetea only uses autoconf to configure/setup openjdk
Jan 12 09:25:48 <pwgen> seem i have to write a patch to get gnu-config_git workig.
Jan 12 09:26:09 <woglinde> and the arm-bytecode extension should work on the jetson too
Jan 12 09:26:37 <woglinde> pwgen besides that some should update icedtea to version 2.5.3
Jan 12 09:26:52 <woglinde> I am sorry I have no time for this
Jan 12 09:27:41 <pwgen> i didnt test it, but k1 should be able to preselect the endianess bevore starting the kernel.
Jan 12 09:28:11 <woglinde> that has nothing todo with the endianess
Jan 12 09:28:33 <woglinde> the bigendian support us still at the beginning
Jan 12 09:42:59 <bluelightning> morning all
Jan 12 09:45:30 <woglinde> hi bl
Jan 12 09:48:10 <koen> hey bluelightning 
Jan 12 09:48:18 <bluelightning> hi woglinde, koen
Jan 12 09:50:49 <mckoan> hi bluelightning, koen, all
Jan 12 09:54:27 <bluelightning> hi mckoan
Jan 12 10:19:40 <mago_> morning 
Jan 12 10:25:42 <bluelightning> hi mago_
Jan 12 11:02:44 <mago_> where in meta-oe-core is the dependency on virtual/bootloader added to images? because, unless it's explicitly added by something, why would it get built when you do "bitbake core-image-minimal"?
Jan 12 11:03:44 <mago_> same goes for the kernel really, but in that case it actually does make sense to have the image depend on the kernel because the userspace apps depends on the kernel being present
Jan 12 11:06:16 <ant_work> koen: fwiw I've done a round of builds (master) and all 3.17-yocto kernels do build, hx4700 included
Jan 12 11:06:32 <bluelightning> mago_: I don't see any dependency on virtual/bootloader in oe-core or meta-oe
Jan 12 11:06:51 <bluelightning> ant_work: hi, btw I merged your fix from Friday this morning
Jan 12 11:07:38 <ant_work> hello
Jan 12 11:07:41 <ant_work> thanks
Jan 12 11:11:03 <bluelightning> mago_: perhaps you might be encountering EXTRA_IMAGEDEPENDS += "<bootloader recipe>" (often u-boot) in the machine config?
Jan 12 11:27:04 <mago_> bluelightning: it seems so, yes! thanks
Jan 12 11:47:40 <mago_> bluelightning: is there an image task that one can depend on that gets run everytime any of the RDEPENDS (IMAGE_INSTALL) or EXTRA_IMAGEDEPENDS are changed? My issue is that i've built this image-in-image recipe, it packages the rootfs, the kernel and bootloader into another image (which is later deployed as a FAT partition). My problem is that this image-in-image depends on rootfs-image:do_rootfs, which of course
Jan 12 11:47:42 <mago_> is not run when stuff that isn't part of the rootfs are updated (like the bootloader)
Jan 12 11:48:55 <mago_> right now i've manually added a dependency on the bootloader, like so: do_rootfs[depends] += "${ROOTFS_BASENAME}:do_rootfs virtual/bootloader:do_deploy"  .. but it'd be better if I could just tell bitbake to depend on everything that gets deployed by a certain image
Jan 12 11:49:15 <bluelightning> mago_: well do_install should be run any time RDEPENDS changes
Jan 12 11:49:22 <bluelightning> mago_: er, do_rootfs that is
Jan 12 11:49:33 <mago_> yes, but the bootloader is not a RDEPENDS, is it?
Jan 12 11:49:40 <bluelightning> no, it isn't
Jan 12 11:49:48 <bluelightning> for EXTRA_IMAGEDEPENDS, there isn't really a task you can depend on no
Jan 12 11:50:03 <bluelightning> to be honest I would just add an explicit dependency on the bootloader if that's what you need
Jan 12 11:50:36 <mago_> well, what i really want is to be able to depend on everything that my image deploys to target (so not specifically the rootfs and/or bootloader)
Jan 12 11:50:52 <mago_> but in reality, this is always rootfs+bootloader
Jan 12 11:51:09 <mago_> (unless some machine config adds additional EXTRA_IMAGEDEPENDS, in which case it will break again)
Jan 12 13:13:20 <Crofton|work> gm all
Jan 12 13:15:25 <bluelightning> morning Crofton|work
Jan 12 13:18:43 <mago_> hey
Jan 12 13:24:44 <hrw> morning 
Jan 12 13:25:34 <hrw> does someone (from people going to fosdem) has nolonger needed pcie gfx card?
Jan 12 19:28:42 <Crofton|work> Do we know about this?
Jan 12 19:28:43 <Crofton|work> https://www.youtube.com/watch?feature=player_embedded&v=LKwvtYZ6xBc
Jan 12 19:28:46 <Crofton|work> crap
Jan 12 19:28:52 <Crofton|work> WARNING: QA Issue: ntp-utils requires /usr/bin/perl, but no providers in its RDEPENDS [file-rdeps]
Jan 12 22:08:26 <khem> setuptools do_installs directly into native_sysroot which means when this python package is installed from sstate it wont install these scripts 
Jan 12 22:08:51 <khem> has anyone experienced sstate issues with python recipes using setuptools
Jan 12 22:13:20 <kergoth> i'd say fix it to stop being stupid and write to ${D}
Jan 12 22:13:24 <kergoth> :)
Jan 12 22:15:28 <khem> its daisy so I wondered if its already fixed 
Jan 12 22:15:53 <kergoth> ah
Jan 13 00:08:13 <khem> kergoth: what is incantation to disabl sstate for a given recipe 
Jan 13 00:08:21 <khem> for workaround
**** ENDING LOGGING AT Tue Jan 13 02:59:59 2015