**** BEGIN LOGGING AT Wed May 08 02:59:58 2013
May 08 07:59:14 <mckoan> good morning
May 08 08:03:40 <ant_work> hi marco
May 08 08:11:30 <bluelightning> morning all
May 08 17:23:48 <sgw_> Khem: around?  I think we are close to throwing the switch on 4.8, any other issues we need to look at?
May 08 17:27:28 * fray is looking forward to that...
May 08 17:35:35 <JaMa> sgw_: xserver-xorg does not fail for you?
May 08 17:36:05 <sgw_> JaMa: in what way? build or runtime?
May 08 17:36:18 <JaMa> sgw_: even target gcc-4.8 is still failing to build for qemux86-64 on jenkins (build on other MACHINEs) was fixed by that dependency change
May 08 17:36:23 <JaMa> build
May 08 17:37:54 <sgw_> JaMa: I have built world for x86-64 and on the Autobuilder with gcc4.8 enabled.
May 08 17:38:48 <JaMa> and no failures?
May 08 17:39:33 <sgw_> No, I will rebuild again locally to verify.
May 08 17:40:02 <JaMa> my last logs are a bit useless because every ERROR message is burried deep in 600MB log caused by 3.9M lines from webkit-efl failure (caused by newer binutils)
May 08 17:40:25 <sgw_> ouch
May 08 17:40:39 <JaMa> but in my previous "State of bitbake world" mails I've shown how xserver-xorg and other recipes fail with gcc-4.8
May 08 17:54:14 <sgw_> Jama: It just built fine for me, I am bulding and then boot sato, maybe your settings are different?
May 08 17:58:00 <JaMa> yes I'm close to distroless setup
May 08 17:59:34 <sgw_> Jama, I will set up a OE-Core build and see if it's something pokyish that's let's it work
May 08 18:20:04 <kergoth> Hmm, we should look at making the contents of DEPLOY_DIR_IMAGE more consistent
May 08 18:31:03 <sgw_> JaMa: confirmed with a pure oe-core build and 4.8 that xserver-xorg is building, so I wonder what other/different settings you have?
May 08 18:31:16 * sgw_ heads out for a swim
May 08 18:42:19 <otavio> Hello folks, I got one user complaining about same issues as https://lists.yoctoproject.org/pipermail/yocto/2013-March/014670.html
May 08 18:42:27 <otavio> He is also using Ubuntu 10.04
May 08 18:42:37 <otavio> and got exactly same trap
May 08 18:42:46 <otavio> do someone knows what causes it?
May 08 18:52:25 <rburton_> otavio: there isn't anything in the metadata that even says HUP
May 08 18:52:34 <otavio> rburton_: yes
May 08 18:52:37 <otavio> rburton_: I agree
May 08 18:52:46 <otavio> rburton_: but it is fully reproducable
May 08 18:52:52 <rburton_> otavio: get a copy of the generated script?
May 08 18:53:03 <rburton_> i.e. in that mail, the run.do_configure
May 08 18:53:07 <otavio> rburton_: Ok
May 08 18:53:38 <otavio> rburton_: hold on, he is e-mailing it to me
May 08 18:53:44 <otavio> rburton_: I paste it in a minute
May 08 18:54:11 <otavio> rburton_: he got *exactly* same error, same package, same task
May 08 18:55:03 <otavio> rburton_: I checked bitbake code and found nothing which could explain it as well
May 08 18:55:10 <rburton_> otavio: if its that reproducable, a set -x would help too
May 08 18:55:30 <otavio> rburton_: the set -x in run?
May 08 18:55:50 <rburton_> yeah, turn on the bash print debugging stuff
May 08 18:56:05 <rburton_> can you just do that and re-run the script, or does it assume more environment
May 08 18:56:49 <otavio> rburton_: sure, doing it
May 08 18:57:14 <otavio> rburton_: http://pastebin.com/t01RsHSK
May 08 18:57:51 <rburton_> but but but it doesn't say trap!
May 08 18:58:27 <Garibaldi_1> is there a way to build a ipk-based rootfs that leaves the installed package database but doesn't include the opk tools?
May 08 18:59:26 <rburton_> Garibaldi_work: not afaik.  why would you want to do that :)
May 08 18:59:41 <rburton_> you can't install the tools later to use the database as you've removed the tools...
May 08 19:00:05 <otavio> rburton_: yes; what is even more confusing is it does work when called by hand
May 08 19:00:10 <rburton_> Garibaldi_work: you can probably hook into the image creation and remove opkg if you really want
May 08 19:00:15 <rburton_> otavio: epic
May 08 19:00:17 <Garibaldi_work> rburton_: yeah, but I have opkg-cl in my toolchain, I can add/remove to a base rootfs before I build the image.
May 08 19:00:37 <Garibaldi_work> and I'd like for it to know what was already installed
May 08 19:00:49 <rburton_> otavio: and i can't see anything obvious that is calling another script
May 08 19:01:31 <otavio> rburton_: me neither; he is now changing busybox.inc and adding set -x on configure task
May 08 19:01:38 <otavio> rburton_: so we can have the log
May 08 19:01:41 <rburton_> otavio: my only suggestion is to hack set -x into bitbake itself so the generated script has it right at the beginning
May 08 19:01:48 <otavio> rburton_: let's see if it helps
May 08 19:01:55 <rburton_> yeah, that might be enough, hopefully the set doesn't happen after the bad trap
May 08 19:02:01 <Garibaldi_work> rburton_:  our model is a bit different, we provide an SDK along with one or more root filesystems.  We let users customize the filesystem then build a VM from it.
May 08 19:03:32 <otavio> rburton_:
May 08 19:06:09 <rburton_> Garibaldi_work: a ROOTFS_POSTPROCESS_COMMAND hook might be a reasonable place to just opkg remove opkg
May 08 19:07:48 <otavio> | + merge_config.sh -m .config
May 08 19:07:48 <otavio> | trap: 80: SIGHUP: bad trap
May 08 19:07:48 <otavio> | ERROR: Function failed: do_configure (see /home/ragan/poky-dylan-9.0.0/build/tmp/work/armv5te-poky-linux-gnueabi/busybox/1.20.2-r7/temp/log.do_configure.11919 for further information)
May 08 19:08:54 <rburton_> aha
May 08 19:11:16 <rburton_> ooh, i was looking at a danny repo
May 08 19:12:33 <rburton_> 	trap clean_up SIGHUP SIGINT SIGTERM
May 08 19:12:38 <rburton_> well, that's the bloody line
May 08 19:12:51 <otavio> rburton_: where is it?
May 08 19:13:15 <rburton_> usr/bin/merge_config.sh in your native sysroot, installed by kern-tools-native
May 08 19:13:26 <rburton_> i wonder if this is a bash-specific syntax
May 08 19:13:31 <rburton_> change the header to /bin/bash
May 08 19:15:45 <rburton_> right i need to cook
May 08 19:15:54 <rburton_> otavio: but that's a step close good luck ;)
May 08 19:16:12 <otavio> rburton_: yes, he is trying it
May 08 19:16:28 <Garibaldi_work> rburton_: thanks — I was just looking at doing that
May 08 19:19:34 <otavio> rburton_: yes it fixes it
May 08 19:28:41 <otavio> Is Bruce around?
May 08 19:29:38 <bluelightning> zeddii: ^^
May 08 19:30:39 <otavio> zeddii: http://pastebin.com/vCmfkHt2 <= this fixes the 10.04 issue in busybox build. This seems to be bash specific.
May 08 19:32:09 <otavio> zeddii: This was initially reported at https://lists.yoctoproject.org/pipermail/yocto/2013-March/014670.html
May 08 19:32:19 <otavio> zeddii: and is full reproducable
May 08 19:34:36 <JaMa> do I remember correctly that oe_runmake was using make with "-e" by default and then it was removed (as causing more harm then good)/
May 08 19:34:39 <JaMa> ?
May 08 19:38:30 <kergoth> JaMa: afaik it still does so, but does MAKEFLAGS= so it doesn't pass the -e into submakes. it was a terrible thing, really. it did buy us 90% of builds working with minimal recipes, but it's too implicit and has too much potential of overriding important makefile variables
May 08 19:38:34 <kergoth> but i could be wrong
May 08 19:38:43 <kergoth> i'm the one that put the -e MAKEFLAGS= into EXTRA_OEMAKE in the first place :)
May 08 19:38:45 * kergoth hangs head in shame
May 08 19:39:45 <JaMa> :)
May 08 19:40:00 <JaMa> I'm debugging one issie with qmake generated Makefiles
May 08 19:40:33 <kergoth> the use of -e also encourages having the large number of variable exports in bitbake.conf. imo vars like CFLAGS should be exported in autotools.bbclass, or explicitly by the recipe knowing its buildsystem will obey it
May 08 19:40:36 <JaMa> sad part is that some variables we want from env and some not
May 08 19:40:37 <JaMa> CFLAGS        = -pipe $(OE_QMAKE_CFLAGS) -O2 -pthread -D_REENTRANT -Wall -W -fPIC $(DEFINES)
May 08 19:40:40 <kergoth> otherwise the recipe  should pass all the vars in through EXTRA_OEMAKE explicitly
May 08 19:41:01 <JaMa> and OE_QMAKE_CFLAGS is exported correctly, but then whole CFLAGS is overwritten from env (and -fPIC lost and build fails)
May 08 19:41:11 <kergoth> hmm, it could be interesting to make a list of the recipes that use default EXTRA_OEMAKE
May 08 19:41:18 <kergoth> ahh
May 08 19:41:43 <kergoth> that would explain it. perhaps qmake.bbclass should override the default EXTRA_OEMAKE to something sane for that particular buildsystem
May 08 19:42:46 <JaMa> yes that's probably best way to fix it
May 08 19:43:23 <kergoth> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n473 - yep, still default
May 08 19:43:26 <kergoth> :\
May 08 19:44:05 <kergoth> you know, in oe-lite, they have make and c bbclasses, so the default deps on the toolchain, makefile handling, etc are split out, so INHIBIT_DEFAULT_DEPS doesn't need to exist
May 08 19:44:07 <JaMa> maybe there was only some discussion on ML about changing the default, because I remember it from somewhere :)
May 08 19:44:12 * kergoth nods, probably
May 08 19:44:58 <JaMa> are you using/developing oe-lite or just watching their work? I've seen you mention it few times
May 08 19:46:48 <kergoth> just try to keep an eye out, it seems to be a nice staging area for stuff that'd be nice to have in oe, but is tough to do wthout breaking compatibility :)
May 08 19:47:07 <kergoth> oh jesus
May 08 19:47:13 <kergoth> i changed a bb.warn to bb.note in do_package
May 08 19:47:19 <kergoth> lets watch the world rebuild!
May 08 19:47:22 * kergoth shoots self
May 08 19:51:09 <JaMa> still more important change then extra whitespace :)
May 08 19:52:03 <kergoth> hehe
May 08 19:52:04 <kergoth> true
May 08 19:52:56 <kergoth> we really need typing in bitbake, and then potentially checksumming of the compiled python ast, potentially filtered, thereby avoiding formatting issues causing changes
May 08 19:56:23 <kergoth> question: how are folks handling their git.yoctoproject.org hosted repositories relative to the ones they may have hosted elsewhere? I'm sure there are folks that have mirrors of their layers for whatever reason, e.g. the bsp layer folks, meta-fsl-arm/whatever, anyone know how people are managing that? I'd like to set up a github mirror of meta-mentor, but I don't know which repo should be definitive and which the mirror, and how to
May 08 19:56:23 <kergoth>  keep them in sync cleanly :)
May 08 20:01:16 <rburton_> otavio: i expect to see a patch or bug filed :)
May 08 20:01:37 <otavio> rburton_: I pasted the patch to him
May 08 20:01:49 <otavio> rburton_: I hope he catches up there
May 08 20:06:31 <kergoth> bluelightning: how does one go about altering the config for a layer in the layerindex? e.g. the dependencies
May 08 20:06:42 <kergoth> bluelightning: or is it parsing README for that?
May 08 20:07:18 <rburton_> otavio: just did a bit more poking - yes, not supporting SIG* is a dash thing
May 08 20:07:29 <bluelightning> kergoth: no, no parsing for that info - if you're one of the maintainers, create an account with the same email as your entry and then you should be able to edit the layer
May 08 20:08:13 <rburton_> otavio: and to be fair, POSIX says no SIG prefix
May 08 20:10:31 <kergoth> bluelightning: ah. i registered with my personal email instead of my work email, oops :) should i create a second account?
May 08 20:11:06 <bluelightning> kergoth: if you like, or if you prefer I can just change the email on your account
May 08 20:11:25 <bluelightning> up to you
May 08 20:11:54 <kergoth> bluelightning: that'd work, kergoth account, change the email from kergoth@gmail.com to chris_larson@mentor.com
May 08 20:12:12 <kergoth> thanks
May 08 20:12:45 <kergoth> meta-mentor's deps as recorded in the readme are just oe-core, but in fact it needs meta-yocto too, so need to fix the readme and also update the index entry
May 08 20:12:45 <kergoth> heh
May 08 20:14:14 <bluelightning> kergoth: done
May 08 20:14:21 <kergoth> k, thanks
May 08 20:14:34 <rburton_> otavio: turns out this is fixed upstream :
May 08 20:14:46 <rburton_> otavio: i just did a kernel clone, and its bloody fixed
May 08 20:15:16 <otavio> rburton_: ?
May 08 20:16:05 <rburton_> otavio: the root cause of the trap bug was fixed in january 2012 by our darren hart
May 08 20:16:25 <rburton_> now dinner
May 08 20:16:27 <rburton_> tata
May 08 20:26:39 <zeddii> otavio, I was heads down on an issue. can you drop me an email with the details ? I'll pick it up later.
May 08 20:27:02 <otavio> rburton_: so it will be part of 1.4.1?
May 08 20:37:50 <kergoth> Anyone thought about adding a variable for the full pleasant-to-read name of a given machine/board/bsp, the name used in marketing literature?
May 08 20:38:00 <kergoth> a machine analogue to DISTRO_NAME, really
May 08 20:38:14 <kergoth> we sort of have that in the commented machine .conf metadata, but not in the metadata
May 08 20:42:14 <bluelightning> kergoth: I thought about it, but then I discovered we have the nicely-formatted comments already
May 08 20:42:29 <bluelightning> kergoth: and amazingly people have actually been completing them despite the fact that AFAICT we aren't using them anywhere
May 08 20:42:42 <bluelightning> (except for the layer index now)
May 08 20:42:44 <kergoth> that is amazing indeed
May 08 20:43:53 <bluelightning> the question is what would putting that into the metadata buy us? would we be able to make use of it anywhere?
May 08 20:45:38 <kergoth> its a good question, today at mentor we need such information for installer creation, so it's maintained out of band, but we should be able to alter it to extract it from the machine .conf headers, but first it'd need to figure out which of the configured layers is the machine layer
May 08 21:11:54 <Crofton|work> am going to try creating issues here
May 08 21:12:01 <Crofton|work> and bitching to people I know
May 08 21:49:24 <Garibaldi_work> If I have a scm-based package, where SRCREV = "${AUTOREV}", is there some variable that exposes what version we actually picked up?
May 08 21:50:51 <Garibaldi_work> for example, I see linux-yocto has a version string, but I don't see it used within the recipe
May 08 21:51:51 <kergoth> SRCREV probably has it. examine bitbake -e
May 08 21:55:18 <Garibaldi_work> I see SRCREV="AUTOINC"
May 08 21:57:03 <Garibaldi_work> If I do a -e for linux-yocto, I see things like SRCREV_machine_qemux86-64="42ddf06111efe45f3c36012d5a04a1eeb9781f42"
May 08 21:57:29 <Garibaldi_work> I thought maybe that's something that git.py is exposing, but I didn't see it there either
May 08 21:58:29 <Garibaldi_work> maybe that's coming from the recipe itself
May 08 21:58:47 <Garibaldi_work> yeah...
May 08 21:59:56 <Garibaldi_work> even thought I'm picking of the latest, it'd be nice to be able to record some metadata to say what version I picked up when I built the image
May 08 22:05:14 <JaMa> Garibaldi_work: why not use PV = "1.2.3+gitr${SRCPV}" like other recipes?
May 08 22:05:26 <JaMa> Garibaldi_work: maybe I don't understand your question correctly..
May 08 22:07:33 <JaMa> or do you want .bbclass which finds out "1.2.3" from last tag? meta-openembedded/meta-oe/classes/gitpkgv.bbclass
May 08 22:07:45 <Garibaldi_work> no, SRCPV might be what I'm after
May 08 22:08:21 <Garibaldi_work> ok
May 08 22:09:30 <Garibaldi_work> JaMa, yeah — that's helpful, thanks.  We have a custom in-house scm and a fetcher for it, but I see in 'bitbake -e': expansion of SRCPV threw ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception AttributeError: 'CustomScm' object has no attribute '_build_revision'
May 08 22:09:52 <Garibaldi_work> sounds like that needs a bit of work
May 08 22:22:38 <kergoth> heh, indeed
**** ENDING LOGGING AT Thu May 09 02:59:58 2013