**** BEGIN LOGGING AT Thu Aug 22 02:59:58 2013
Aug 22 08:03:59 <bluelightning> morning all
Aug 22 08:15:54 <silviof> morning bluelightning and #oe
Aug 22 08:17:09 <bluelightning> morning silviof
Aug 22 09:03:05 <JaMa> morning all
Aug 22 09:07:00 <woglinde> hi jama
Aug 22 09:07:51 <bluelightning> morning JaMa, woglinde
Aug 22 09:21:58 <ndec> hi. i will repeat what i had writtent during the night, as you might not have seen it, + i think i found a solution... 
Aug 22 09:22:17 <ndec> hi. i am seeing a libjpeg-turbo error: ERROR: Function failed: libjpeg-turbo: LIC_FILES_CHKSUM points to an invalid file: xxx/tmp/work/armv7ahf-vfp-neon-rdk-linux-gnueabi/libjpeg-turbo/8d+1.2.1-r2/trunk/cdjpeg.h
Aug 22 09:22:27 <ndec> it seems that a 'fresh' svn copy of the repo now creates trunk/trunk, hence it doesn't find the file.
Aug 22 09:22:31 <ndec> chaning S to trunk/trunk in the .bb fixes the problem.
Aug 22 09:22:43 <ndec> apparently, i am not alone ;-) https://groups.google.com/forum/#!msg/beagleboard/kTXnTZMFPLE/JTWs6696D8sJ, from a few hours ago.
Aug 22 09:23:12 <ndec> so, basically it seems that the http server has changed, and there is no a redirection to https://svn.code.sf.net/p/libjpeg-turbo/code
Aug 22 09:23:35 <ndec> and the 'trunk' that was an the end of SRC_URI is 'lost' in the redirection
Aug 22 09:24:23 <ndec> e.g. http://pastebin.com/wE8senei
Aug 22 09:24:46 <ndec> now if we use the new redirected svn address is SRC_URI, it works fine.
Aug 22 09:25:25 <ndec> http://pastebin.com/Dz2E7g7s
Aug 22 09:30:43 <woglinde> ndevc creating trunk/trunk is definitly a bug
Aug 22 09:34:37 <ndec> woglinde: it's because of the http redirection that is now on the server.
Aug 22 09:35:44 <ndec> bitbake will compute the full link as 'SRC_URI/module' which is https://libjpeg-turbo.svn.sourceforge.net/svnroot/libjpeg-turbo/trunk@837
Aug 22 09:36:02 <woglinde> hm ah the new sf layout
Aug 22 09:36:05 <woglinde> hm hm
Aug 22 09:36:05 <ndec> and https://libjpeg-turbo.svn.sourceforge.net/svnroot/libjpeg-turbo/trunk is redirected to https://svn.code.sf.net/p/libjpeg-turbo/code/
Aug 22 09:36:52 <ndec> and it breaks all releases... i am on dylan. 
Aug 22 09:36:58 <ndec> bluelightning: ^
Aug 22 09:41:11 <bluelightning> ndec: is there a recent release tarball we could build from rather than svn for this recipe? if so it's probably about time we moved to that rather than building from svn
Aug 22 09:41:28 <ndec> yes, there is one.
Aug 22 09:43:24 <ndec> bluelightning: someone here made that patch to 'workaround'. you want me to send it over?
Aug 22 09:44:34 <bluelightning> ndec: if it's tested and works I'd say just send it as a patch for meta-oe
Aug 22 09:55:34 <ndec> bluelightning: well, currently we use @837 in the recipe which is according to changelog 1.3 pre-beta, with version (in cmakefile) 1.2.80. so this isn't really an ideal solution...
Aug 22 09:55:50 <ndec> especially for dylan, where we should not change the 'version'
Aug 22 09:56:10 <bluelightning> yes, well in dylan we probably should just hack it to build the same version successfully
Aug 22 09:56:12 <ndec> on master, it's probabaly time to use latest from upstream such as 1.3
Aug 22 09:56:22 <bluelightning> ndec: right, just what I was about to say :)
Aug 22 09:56:38 <ndec> i have it built with a bbappend in my layer, with SRC_URI = "svn://svn.code.sf.net/p/libjpeg-turbo/code;protocol=https;module=trunk" 
Aug 22 09:57:02 <ndec> i didn't know about the 'new SF layout', that's going to impact many things no?
Aug 22 09:59:10 <pb_> hi all
Aug 22 09:59:15 <bluelightning> hi pb_
Aug 22 09:59:20 <pb_> morning bluelightning
Aug 22 10:01:12 <ndec> at least for me:
Aug 22 10:01:12 <ndec> $ repo grep svn.sourceforge.net
Aug 22 10:01:12 <ndec> meta-openembedded/meta-oe/recipes-core/jpeg/libjpeg-turbo_svn.bb:SRC_URI = "svn://libjpeg-turbo.svn.sourceforge.net/svnroot/libjpeg-turbo;protocol=https;module=trunk"
Aug 22 10:01:12 <ndec> meta-openembedded/meta-oe/recipes-navigation/navit/navit_svn.bb:SRC_URI += "svn://anonymous@navit.svn.sourceforge.net/svnroot/navit/trunk;module=navit;protocol=http \
Aug 22 10:01:14 <ndec> meta-openembedded/meta-oe/recipes-qt/qcanobserver/qcanobserver-socketcan_svn.bb:SRC_URI = "svn://qcanobserver.svn.sourceforge.net/svnroot;module=qcanobserver;protocol=https"
Aug 22 10:01:16 <ndec> meta-openembedded/meta-oe/recipes-qt/qcanobserver/qcanobserver_svn.bb:SRC_URI = "svn://qcanobserver.svn.sourceforge.net/svnroot;module=qcanobserver;protocol=https \
Aug 22 10:01:19 <ndec> openembedded-core/scripts/jhbuild/modulesets/gnome-2.16.modules:      href="https://svn.sourceforge.net/svnroot/gaim/"/>
Aug 22 10:01:23 <ndec> oops..
Aug 22 10:01:29 <bluelightning> ndec: right, just saw those
Aug 22 10:01:33 <bluelightning> so it's not too widespread
Aug 22 10:01:53 <bluelightning> I wonder what would happen if we just filed a bug with sourceforge to add a more intelligent redirect
Aug 22 10:02:12 <bluelightning> I'll bet we aren't the only ones affected by this
Aug 22 10:02:15 <ndec> i think that would be the right thing to do.
Aug 22 10:02:29 <ndec> pretty much any source base distro, i would say ;-)
Aug 22 10:02:47 <ndec> hopefully ubuntu has bazaar and won't notice ;-)
Aug 22 10:04:58 <JaMa> qcanobserver is broken for some time :/ is someone using that?
Aug 22 10:07:29 <ndec> JaMa: yes.
Aug 22 10:07:40 <ndec> one less bug ;-)
Aug 22 10:08:53 <JaMa> yes for what?
Aug 22 10:09:07 <TimSmith> what does meta-skeleton mean in the oe-core folder? I could not find info on that...
Aug 22 10:13:31 <ndec> ah. sorry. JaMa i read too quickly, i thought you asked if qcanobrowser was broken for the same reason ;-) no i don't use it, otherwise.
Aug 22 10:27:12 <ndec> bluelightning: is the 'response' time generally slower on bitbake-devel? that list doesn't seem to have lots of traffic. my patch about the run.do_xxx link hasn't add any comment in 1 week. not sure if it's expected or not.
Aug 22 10:28:45 <bluelightning> ndec: there are fewer people on that list definitely
Aug 22 10:28:53 <bluelightning> ndec: FWIW, it looked OK to me
Aug 22 10:29:12 <ndec> ok. i'll wait. will ping if nothing happens next week.
Aug 22 10:29:35 <bluelightning> TimSmith: there is a very brief mention of it in the Yocto Project reference manual: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#structure-meta-skeleton
Aug 22 10:30:02 <bluelightning> TimSmith: basically it's a collection of examples of how to use certain pieces of functionality; it's not really meant to be used as-is
Aug 22 10:55:18 * Crofton|work woke up too early
Aug 22 10:55:51 <woglinde> crofton hm than sleep again
Aug 22 11:32:16 <bencoh> is it possible to set a PREFERRED_PROVIDER_something at the image level, or should I feel heretical ?
Aug 22 11:32:23 <bencoh> (virtual/kernel for instance)
Aug 22 12:22:48 <bluelightning> bencoh: nope, it needs to be set at the configuration level, i.e. distro/machine config or local.conf
Aug 22 12:25:41 <bencoh> that's what I was afraid of ... sad
Aug 22 12:27:46 <bluelightning> bencoh: the problem is it's something that influences how packages are built
Aug 22 12:28:15 <bluelightning> bencoh: imagine that you build some user-space driver against one kernel version, it might not be possible to just slot in a different kernel at runtime
Aug 22 12:29:25 <bencoh> yeah, I kinda see the problem here
Aug 22 12:29:53 <bencoh> but that means only one kernel per distro_machine is allowed
Aug 22 12:31:25 <bluelightning> bencoh: pretty much yes
Aug 22 12:31:36 <bluelightning> bencoh: can I ask what's driving the need for more than one?
Aug 22 12:33:13 <bencoh> different images for several "projects" sharing the same distro
Aug 22 12:33:42 <bencoh> with a few minor changes (multimedia kernel, specific software/packages)
Aug 22 12:33:59 <bencoh> (and specific conf files in the rootfs of course)
Aug 22 12:34:56 <bluelightning> hmm ok
Aug 22 12:35:21 <bluelightning> typically I'd recommend separate branches for that kind of thing anyway, it's hard to predict when you'll need to make a change specific to one project
Aug 22 12:35:35 <ant_work> bluelightning: sometimes I'm there while testing i.e. linux-yocto-dev or linux vanilla havinf linux-yocto as preferred provider
Aug 22 12:35:50 <ant_work> ther is some clash of course
Aug 22 12:36:05 <bluelightning> ant_work: for temporary stuff like that setting it in local.conf should be adequate surely?
Aug 22 12:36:59 <ant_work> yes I'd say ( I touch machine.conf personally)
Aug 22 12:37:32 <ant_work> note that there are major issues with modules in rootfs
Aug 22 12:37:56 <ant_work> I bet one should at least wipe tmpdir in order to rebuild images
Aug 22 12:38:11 <ant_work> I only do kernel builds, no idea about userland
Aug 22 12:38:11 <bluelightning> that shouldn't be necessary
Aug 22 12:38:48 <bluelightning> since assuming the modules are built as recipes, they'll depend on the kernel and will thus be rebuilt when a different kernel is selected to be built (assuming you rebuild the image)
Aug 22 12:38:50 <ant_work> once I ended with kernel 3.10 and modules 3.8 :p
Aug 22 12:39:05 <bluelightning> well if you swap out the kernel by hand, you'll get that :p
Aug 22 12:39:26 <bluelightning> I suspect that was the reason for the modules tarball in the old days
Aug 22 12:40:02 <ant_work> sure, I use those when testing existing images
Aug 22 12:43:05 <bencoh> wipe tmpdir ? hmm
Aug 22 12:43:41 <bencoh> I usually just clean/cleansstate linux{,-yocto}
Aug 22 12:46:10 <ant_work> bencoh: the modules you build with the second virtual/kernel are installing the same files provided by the first kernel built
Aug 22 12:47:29 <bencoh> ant_work: are you relating to the idea of having several kernels, or the way I "clean" ?
Aug 22 12:49:21 <ant_work> if you first build with linux-yocto as virtual provider you'll have the -yocto kernel modules installed around
Aug 22 12:49:59 <ant_work> just removing bitbake -c cleansstate linux-yocto will not remove them
Aug 22 12:50:05 <bencoh> hmm
Aug 22 12:50:13 <ant_work> s/just removing//
Aug 22 12:50:14 <bencoh> if you mean "in the rootfs", they're under -yocto
Aug 22 12:50:30 <ant_work> the modules have different names
Aug 22 12:50:33 <bencoh> and in my tmpdir .... they're under -yocto too
Aug 22 12:51:47 <ant_work> chek in /lib/modules of the image
Aug 22 12:51:48 <bencoh> oh, right, the kernel-module-* packages
Aug 22 12:52:18 <bencoh> my /lib/modules/ contains a yocto folder
Aug 22 12:52:25 <bencoh> (3.8.4-yocto-standard for instance)
Aug 22 12:52:31 <ant_work> right
Aug 22 12:52:59 <bencoh> but the packages aren't named after the kernel flavour indeed
Aug 22 12:53:06 <ant_work> if you'd use vanilla 'linux' as virtual/kernel the modules would be 3.8.4
Aug 22 12:53:39 <bencoh> I see your point ... works with vanilla :)
Aug 22 12:53:41 <ant_work> just remember to check this
Aug 22 12:54:51 <ant_work> and about programs linking to kernel headers (not many today), no issues  if the linux version is the same
Aug 22 12:56:43 <bluelightning> the build system can't know whether compatibility will be an issue or not
Aug 22 12:56:55 <bluelightning> you might have backported a whole bunch of API-breaking changes to an old kernel, for example
Aug 22 12:58:13 <ant_work> right, as we did with LZO/LZMA compression on 2.6.2x kernels
Aug 22 12:59:19 <ant_work> the issue was usually udev
Aug 22 13:00:56 <ant_work> bluelightning: in my desperate tests I've transplanted prolly every kernel+modules after 2.6.31 on an old collie image ;)
Aug 22 13:01:07 <bluelightning> heh, right...
Aug 22 13:20:35 <likewise> hi all
Aug 22 13:36:43 <bluelightning> hi likewise
Aug 22 13:42:20 <likewise> in which module/class do we write soft links for the log files (log.do_stuff -> log.do_stuff.<pid>) ?
Aug 22 13:42:50 <likewise> as I would like to add the very same for the run files (run.do_compile -> log.do_compile.<pid>) ?
Aug 22 13:51:40 <bluelightning> likewise: in an interesting coincidence, ndec sent a patch to bitbake-devel to do just that the other day :)
Aug 22 13:51:53 <ndec> hehe
Aug 22 13:52:38 <ndec> though my symlink is from run.do_compile -> run.do_compile.<pid> [guess that was a typo above]
Aug 22 13:53:30 <ndec> likewise: http://lists.openembedded.org/pipermail/bitbake-devel/2013-August/003732.html
Aug 22 13:53:52 <likewise> Haha, wow, what a coincidence.
Aug 22 13:55:34 <likewise> I requested the log link way way back and I think RP implemented that one. So for a developer, it has been little effort on my side (<flush>)... Thanks!
Aug 22 13:56:12 <ndec> the patch applies on master and dylan, btw
Aug 22 13:56:58 <likewise> ndec: brilliant, I think it is non-intrusive and could even be considered for backporting into Dylan.
Aug 22 13:57:46 <likewise> ndec: i.e. should be zero risk of cherry-picking (backport is rather big a word) it in Dylan, I mean.
Aug 22 13:59:45 <ndec> likewise: i use this patch on dylan. our product is using dylan.
Aug 22 14:01:40 <likewise> ndec: your product? RDK?
Aug 22 14:02:11 <ndec> hehe. the 'thing' i am working on, at least.
Aug 22 14:32:03 <TimSmith> I'm trying to update my oe-classic project to the new oe. Should the folder oe-core be the top level folder of my project?
Aug 22 14:35:14 <woglinde> TimSmith look at set setup-scripts fotr angstroem they are a good example deriving from
Aug 22 14:37:18 <bluelightning> TimSmith: you can largely structure things however you like; I tend to prefer to avoid putting repositories inside eachother myself though
Aug 22 14:41:11 <likewise> ndec: Good luck with the 'thing' :) Thanks for the patch.
Aug 22 14:46:21 <TimSmith> ok, thanks
Aug 22 14:49:05 <ndec> likewise: thanks for +1.
**** ENDING LOGGING AT Fri Aug 23 02:59:59 2013