**** BEGIN LOGGING AT Mon Apr 29 02:59:58 2013
Apr 29 06:56:15 <mckoan> good morning
Apr 29 07:28:20 <mattnie> Hello, I can not fetch a firmware file for the raspberrypi.. here is the log of the fetch: http://pastebin.com/w9svcF2N
Apr 29 07:54:46 <apelete> good morning
Apr 29 08:00:52 <silvio_> morning all, hi apelete 
Apr 29 08:04:03 <silvio_> hi bluelightning 
Apr 29 08:04:34 <bluelightning> morning silvio_, all
Apr 29 08:10:44 <mckoan> gm all
Apr 29 08:12:15 <apelete> hi silvio_, bluelightning, mckoan 
Apr 29 08:12:31 <bluelightning> hi mckoan, apelete
Apr 29 08:13:10 <silvio_> hi mckoan 
Apr 29 08:22:48 <hrw> hello
Apr 29 08:24:07 <bluelightning> hi hrw
Apr 29 08:29:58 <rah> ERROR: No recipes available for: /home/rah/phones/shr/shr-core-gta04/meta-openembedded/meta-systemd/oe-core/recipes-connectivity/openssh/openssh_6.1p1.bbappend
Apr 29 08:31:27 <rah> je ne comprends pas
Apr 29 08:32:27 <bluelightning> rah: there is an openssh bbappend in the version of meta-systemd you have checked out that does not match up with the openssh recipe in the version of oe-core you have checked out
Apr 29 08:32:48 <bluelightning> rah: I guess you updated one and not the other
Apr 29 08:33:11 <rah> bluelightning: I updated both
Apr 29 08:33:59 <bluelightning> rah: ok, it looks like openssh was just updated
Apr 29 08:34:07 <bluelightning> rah: and meta-systemd hasn't caught up
Apr 29 08:34:24 <bluelightning> rah: temporarily you can probably just rename the bbappend in meta-systemd to match
Apr 29 08:34:50 <bluelightning> rah: (to openssh_6.2p1.bbappend)
Apr 29 08:38:46 <JaMa|Off> I've pushed fix a minute ago
Apr 29 08:39:28 <bluelightning> JaMa: great, thanks
Apr 29 08:39:41 <bluelightning> rah: ^ update meta-oe and you should be fine
Apr 29 08:40:13 <rah> should that really be a bitbake error?
Apr 29 08:40:26 <bluelightning> rah: what do you mean?
Apr 29 08:41:07 <JaMa> rah: there is an option to make it only warning if you really want
Apr 29 08:41:19 <JaMa> but in many cases fatal error is better
Apr 29 08:41:28 <rah> JaMa: what's the option?
Apr 29 08:41:35 <rah> JaMa: and why is fatal error better?
Apr 29 08:41:43 <JaMa> like in this one you wouldn't be happy to boot upgraded image and get openssh without systemd support
Apr 29 08:41:46 <bluelightning> rah: the problem is if the bbappend no longer matches up with the current version, you'll no longer be getting the changes in the bbappend applied on top of thr recipe
Apr 29 08:42:14 <bluelightning> which is almost always going to be undesirabler
Apr 29 08:42:20 <bluelightning> undesirable
Apr 29 08:42:20 <rah> mmm
Apr 29 08:42:29 <JaMa> BB_DANGLINGAPPENDS_WARNONLY
Apr 29 08:56:22 <rah> JaMa: thanks
Apr 29 09:00:48 <bluelightning> JaMa: FYI, a few of your recent commits have been without -s
Apr 29 09:00:54 <bluelightning> I'm assuming that wasn't deliberate...
Apr 29 09:07:26 <JaMa> wasn't, yeah I need to be more careful
Apr 29 09:07:39 <JaMa> in webos we're using DCO, so I cannot use -s
Apr 29 09:08:05 <JaMa> so I sometimes forget it now when I'm switching back and forth between the two..
Apr 29 09:08:58 <JaMa> I was usually at least adding it when cherry-picking to master branch, but now I have also git chp alias without -s because of webos..
Apr 29 09:10:23 <bluelightning> I checked a while back and unfortunately there's no option to automatically do -s at the repo level
Apr 29 09:10:43 <bluelightning> about the best you could have is a pre-commit hook that fails if the signed-off-by line isn't there
Apr 29 09:14:24 <hrw> JaMa: thanks for merging (lib)memcached
Apr 29 09:14:51 <hrw> can someone check do I have an account on patchwork? and create one if not...
Apr 29 09:15:05 <hrw> I would like to mark my patches as done/superseded etc
Apr 29 09:16:11 <JaMa> hrw: thanks for fixing it :)
Apr 29 09:16:44 <JaMa> you can mark your patches even with normal account created by yourself (if it's still enabled)
Apr 29 09:17:31 <hrw> JaMa: *if*
Apr 29 09:17:47 <JaMa> ah ok
Apr 29 09:17:59 <hrw> JaMa: I know that I had an account there years ago but then not used OE for quite long time...
Apr 29 09:18:00 <JaMa> and I was marking all your patches
Apr 29 09:19:26 <hrw> JaMa: http://patches.openembedded.org/project/oe-core/list/?submitter=4689 is long
Apr 29 09:20:28 <JaMa> ah not for oe-core
Apr 29 09:20:46 <JaMa> I stoped marking my patches for oe-core too, because nobody seems to do it...
Apr 29 09:31:28 <bluelightning> JaMa: I've just gone through and marked a bunch of ones I can see have been applied
Apr 29 09:31:42 <bluelightning> JaMa: unfortunately I think they're a bit less visible with the archived bit set
Apr 29 09:32:24 <JaMa> in oe-core or meta-oe?
Apr 29 09:33:24 <JaMa> I take care only about in-test bundle (patches I'm applying in the end)
Apr 29 09:33:51 <JaMa> patches in bundles like meta-initramfs, meta-webserver etc I just move to right bundle and let layer maintainer to handle them
Apr 29 09:35:16 <apelete> is it possible with oe-core to build a kernel and generate a uImage file directly ? I tried by setting KERNEL_IMAGETYPE = "uImage" in my machine conf but it failed: http://paste.debian.net/1031/
Apr 29 09:35:49 <apelete> tried with this kenrel recipe http://www.seketeli.fr/git/~apelete/meta-handheld.git/tree/recipes-kernel/linux/linux-jlime-ben-nanonote_2.6.36.bb
Apr 29 09:36:03 <apelete> and that machine conf http://www.seketeli.fr/git/~apelete/meta-handheld.git/tree/conf/machine/ben-nanonote.conf
Apr 29 09:36:48 <ant_work> apelete: :)
Apr 29 09:36:49 <apelete> it seems the capability needs to be built into the kernel directly, but I'm not sure
Apr 29 09:36:50 <ant_work> # With 2.6.37 there is not yet uImage target (pending patches)
Apr 29 09:37:03 <bluelightning> JaMa: meta-oe... the oe-core patchwork is a total mess
Apr 29 09:37:57 <apelete> ant_work: saw that, but does it mean a 3.x kernels for instance have uImage target built in ?
Apr 29 09:37:58 <bluelightning> JaMa: fair enough
Apr 29 09:39:27 <JaMa> apelete: kernel.bbclass will still (re)create uImage unless KEEPUIMAGE is set
Apr 29 09:39:45 <ant_work> apelete: iirc uImage target has been added end-2010 for mips
Apr 29 09:43:24 <apelete> ant_work: had an interesting chat with JaMa yesterday, he advised me to get a working BSP before working on distro configuration/creation; just like you were saying a few weeks ago :)
Apr 29 09:44:56 <apelete> so I'm trying to update the kernel for the nanonote and get a minimal image to boot on the device
Apr 29 09:46:29 <pb_> morning all
Apr 29 09:48:54 <ant_work> apelete: seems uImage is not yet default target for mips
Apr 29 09:49:11 <ant_work> see this  http://repository.timesys.com/buildsources/k/kernel/kernel-3.3/linux-3.3-mips-uImage.patch
Apr 29 09:49:24 <ant_work> ..but why do you want uImage?
Apr 29 09:50:03 <ant_work> and why 'linux-jlime-*' instead of plain 'linux' ?
Apr 29 09:50:49 <apelete> ant_work: need uImage because I'm using uboot on the nanonote atm
Apr 29 09:52:19 <bluelightning> ant_work: I'm not sure if having PN matching something in OVERRIDES is a good idea
Apr 29 09:52:34 <bluelightning> ant_work: (if PN = "linux" that matches TARGET_OS which is in OVERRIDES)
Apr 29 09:52:48 <apelete> ant_work: and I just kept the same recipe name from oe-classic, since it was customized by the jlime community at that time
Apr 29 09:53:19 <ant_work> hm.. I remember havin messed with it long ago..
Apr 29 09:53:25 <ant_work> ah, yes
Apr 29 09:53:26 <ant_work> http://lists.linuxtogo.org/pipermail/openembedded-commits/2011-March/055530.html
Apr 29 09:53:57 <ant_work> I mean, start with a recent vanilla 3.x
Apr 29 09:54:20 <ant_work> you're searching for troubles with 2.3x
Apr 29 09:56:00 <bluelightning> apelete: mainline should work according to http://en.qi-hardware.com/wiki/Ben_NanoNote/Kernel
Apr 29 09:56:11 <bluelightning> or, you could build their kernel which has been patched
Apr 29 09:56:44 <ant_work> ideally you'd jump on linux-yocto asap
Apr 29 10:01:48 <apelete> bluelightning ant_work: yes, I was thinking about starting with the Qi-Harware kernel, and then update to the yocto one maybe by applying the same patches on it (if it proves to be working)
Apr 29 10:02:12 <silvio> There is  a way to have two istance of bitbake running on the same phisical machine, for example in two different chrooted enviroment
Apr 29 10:02:17 <silvio> ?
Apr 29 10:03:05 <bluelightning> silvio: you can have two instances as long as they don't share the same build directory
Apr 29 10:03:16 <bluelightning> chroot isn't needed
Apr 29 10:05:25 <silvio> ok thanks
Apr 29 10:06:32 <pb_> out of interest, is there any particular reason that bitbake locks on ${TOPDIR} rather than ${TMPDIR} for its single-instance protection?
Apr 29 10:07:47 <bluelightning> pb_: probably because some things do get written by default into TOPDIR e.g. pseudodone, sstate-cache, auto-update of conf/bblayers.conf
Apr 29 10:09:52 <pb_> sstate-cache is multi-instance safe already, I think.  but yeah, I guess the others probably are a bit of an issue.
Apr 29 10:10:56 <pb_> what's the bblayers.conf auto update?  I don't think I know about that.
Apr 29 10:14:01 <bluelightning> pb_: in the past when we've made changes to bblayers.conf, instead of just bailing out if the version is lower we try to update the conf file automatically
Apr 29 10:14:27 <bluelightning> pb_: the code is in sanity.bbclass
Apr 29 10:14:37 <pb_> right, I see
Apr 29 13:21:21 * pb_ stabs qemu-native for shipping a load of git garbage in its tarball
Apr 29 13:21:50 <pb_> which breaks doing "git clean" at the top level of your build tree, grr.
Apr 29 13:21:56 <Crofton|work> heh
Apr 29 13:22:06 <Crofton|work> I had that trouble with a vendor kernel patch once
Apr 29 13:22:12 <Crofton|work> it contained the git dir
Apr 29 13:22:23 <Crofton|work> so applying the patch to a git tree broke git :)
Apr 29 13:22:35 <pb_> heh
Apr 29 13:25:12 <bluelightning> in the reverse, I had to patch collectd not to use "git describe" when building from a tarball which resulted in it getting versions like "1.4-M5" from the metadata...
Apr 29 13:25:29 <pb_> doh
Apr 29 13:25:34 <bluelightning> (and blowing up during compile because it couldn't convert that to an x.y.z version)
Apr 29 13:26:00 <pb_> yeah, evidently a wide scope for creative screw-ups in this area
Apr 29 13:26:22 * pb_ patches his build scripts to manually rm -rf $TMPDIR before running git clean
Apr 29 14:50:45 <ant_work> pb_: do youhappen to have built kexec-tools on mips recently ?
Apr 29 14:53:40 <pb_> not recently.  We ended up not using kexec in production on any of our products.
Apr 29 14:54:06 <pb_> why do you ask?
Apr 29 14:54:26 <ant_work> it ws broken long ago
Apr 29 14:54:38 <pb_> well, it did build last time I tried.
Apr 29 14:54:41 <pb_> I can give it a go now if you like
Apr 29 14:54:51 <ant_work> I could never runtime-test it :/
Apr 29 14:55:11 <pb_> oh, wait, my kernels probably have CONFIG_KEXEC turned off.
Apr 29 14:55:45 <pb_> actually it turns out we do build (and ship) kexec-tools, contrary to what I thought
Apr 29 14:55:51 <pb_> so I can tell you that it does at least compile for mips :-)
Apr 29 14:56:05 <ant_work> great, thx
Apr 29 14:56:24 <pb_> I have a meeting in 5 minutes but after that I can have a quick go and see whether it actually works or not.
Apr 29 14:56:42 <ant_work> thx
Apr 29 14:56:44 <ant_work> kexec-tools-klibc for mips would probably need some patching :/
Apr 29 14:56:56 <pb_> probably.  we don't use klibc at all, too eleet for us
Apr 29 14:57:25 <ant_work> how to ship a static binary alternatively ?
Apr 29 14:57:27 <ant_work> ;)
Apr 29 14:58:59 <ant_work> afaik there in'ts any easy switch to trigger static compilation of th ebinaries
Apr 29 14:59:00 * pb_ -> meeting
Apr 29 14:59:02 <pb_> bbl
Apr 29 14:59:06 <ant_work> bye
Apr 29 14:59:34 * ant_work cleaning keyboard from the crumbs
Apr 29 15:52:29 <chouimat> morning
Apr 29 16:51:20 <mr_science> moin
Apr 29 17:26:39 <ant_work> pb_: pls let me know
Apr 29 17:26:43 <ant_work> bbl
Apr 29 17:35:34 <jeroen_> hi, I am trying to get oe running on a FreeBSD, at least the bitbake / staging / native building works..
Apr 29 17:37:03 <jeroen_> there is a new challenge, called pseudo, especially since it is documented that is not (easily) portable..
Apr 29 17:37:58 <jeroen_> Does someone know the status of this project in this regard, it does contain an effort to run on a mac, but mentioned to be non functional
Apr 29 17:38:01 <jeroen_> ?
Apr 29 17:38:58 <mr_science> i had some issues with building pseudo on a gentoo multilib install
Apr 29 17:39:52 <mr_science> but i wanted to play with yocto/poky and not pseudo so i switched to a straight 64-bit ubuntu env...
Apr 29 17:42:46 <jeroen_> mr_science: I can imaging that, scanning through the code, it replaces some libc functions
Apr 29 17:44:26 <jeroen_> mr_science: is pseudo optional? I assumed it is a the heart of oe, since it wants to build it before anything else..
Apr 29 17:44:58 <mr_science> don't think it's optional...
Apr 29 17:45:22 <mr_science> the option i avoided was packaging it for gentoo
Apr 29 17:45:48 <mr_science> if its installed in the host, then my impression is that oe won't try to build it
Apr 29 17:46:10 <mr_science> is it in bsd ports?
Apr 29 17:46:15 <jeroen_> mmm, will give it a try..
Apr 29 17:46:38 <jeroen_> but I need to run it as a linux binary, just see what happens..
Apr 29 17:47:35 <jeroen_> no it is not in the ports, but I can make a recipe to install the linux version, see what happens
Apr 29 17:47:48 <jeroen_> my guess is that it will fail horribly
Apr 29 17:47:50 <jeroen_> ;)
Apr 29 17:48:31 <Daemon404> seems a tag strange to be developing ebedded linux stuff on bsd
Apr 29 17:48:35 <Daemon404> s/tag/tad/
Apr 29 17:48:46 <Daemon404> s/ebedded/embedded/
Apr 29 17:48:54 <jeroen_> Deamon404: it is...
Apr 29 17:49:28 <jeroen_> Deamon404: it is a for fun..
Apr 29 17:49:37 <Daemon404> fair enough
Apr 29 17:49:58 <jeroen_> b: there is some activity on FreeBSD for embedded stuff...
Apr 29 17:50:22 <jeroen_> c: and that is the actual reason, I would like to adjust the qt recipe
Apr 29 17:50:46 <Daemon404> ah qt.... i sense pain in your future
Apr 29 17:50:53 <Daemon404> esp. if its qmake related
Apr 29 17:51:11 <jeroen_> having a sdk for freebsd and host linux and vice versa is a good way to test native / nativesdk issues..
Apr 29 17:51:29 <jeroen_> yup it is qmake related ;)
Apr 29 17:51:36 <Daemon404> hah.
Apr 29 18:20:05 <jeroen_> got to reboot to linux-32, bye
**** ENDING LOGGING AT Tue Apr 30 02:59:58 2013