**** BEGIN LOGGING AT Mon Apr 08 02:59:58 2013
Apr 08 07:06:13 <mckoan> good morning
Apr 08 07:11:05 <silvio__> morning all
Apr 08 07:12:13 <mckoan> silvio__: hi
Apr 08 07:13:12 <likewise> morning
Apr 08 07:17:44 <silvio__> mckoan, hi
Apr 08 07:45:12 <apelete> good morning
Apr 08 07:53:30 <mckoan> gm apelete, likewise, all
Apr 08 08:11:24 <silvio__> hi apelete 
Apr 08 08:12:15 <bluelightning> morning apelete, silvio__, all
Apr 08 08:14:21 <apelete> hi mckoan, silvio__, bluelightning 
Apr 08 08:17:21 <silvio__> hi bluelightning , hi all :P
Apr 08 08:17:27 <silvio__> hi bluelightning , hi all :)
Apr 08 08:21:00 <silvio__> I broken something in my building machine, when I build a SDK, not only my, the gcc executable for i686 are not  deployed inside, some suggest?
Apr 08 08:30:03 <mckoan> silvio__: in that case I delete the whole tmp :-(
Apr 08 08:30:39 <bluelightning> I doubt that will help
Apr 08 08:33:42 <silvio__> mckoan, do you mean tmp-eglibc?
Apr 08 08:35:19 <silvio__> mckoan, or also  out-eglibc and tmp-eglibc
Apr 08 08:41:28 <mckoan> silvio__: I have had random build problems in the past and was caused by file corruption in tmp-eglibc, a total rebuild solved (to me)
Apr 08 08:42:02 <mckoan> of course that wasn't an OE problem
Apr 08 08:47:47 <apelete> speaking of tmp-eglibc, how is the name of that directory chosen ?
Apr 08 08:47:51 <apelete> my tmp directory is named "tmp-eglibc-eglibc" and I wonder if that's normal
Apr 08 08:48:01 <apelete> http://paste.debian.net/248197/
Apr 08 08:49:38 <bluelightning> apelete: what is your DISTRO value?
Apr 08 08:49:48 <bluelightning> apelete: usually this indicates defaultsetup.conf is being parsed twice
Apr 08 08:50:07 <silvio__> my is quite different, I had following folders: 
Apr 08 08:50:26 <silvio__> downloads out-eglibc  sstate-cache tmp-eglibc
Apr 08 08:51:54 <apelete> bluelightning: according to bitbake output my DISTRO is "jlime-2010.1" (the same value as in local.conf)
Apr 08 08:52:43 <bluelightning> apelete: ok... what does bitbake -e | less indicate for TMPDIR? it should show how it is getting set
Apr 08 08:56:05 <silvio__> bluelightning, for my TMPDIR="/home/oe-core/build/out-eglibc"
Apr 08 08:56:52 <silvio__> so I immagine that I have to delete not only tmp-eglibc, but also out-eglibc, I m right?
Apr 08 08:57:20 <silvio__> or is useless? Because I prefer don t remove all builded :(
Apr 08 09:00:05 <apelete> bluelightning: ha, defaultsetup.conf is being parsed twice indeed, you're right: http://paste.debian.net/248200/
Apr 08 09:01:34 <apelete> I copied the file in my conf/distro dir AND included in my distro file too
Apr 08 09:02:10 <apelete> it's only monday and I'm feeling ashamed already...
Apr 08 09:42:10 <apelete> bluelightning: seems it wasn't me after all, defaultsetup.conf is included from bitbake.conf from oe-core
Apr 08 09:43:27 <apelete> I guess I'll remove "require conf/distro/defaultsetup.conf" from my distro conf file then
Apr 08 09:45:01 <bluelightning> apelete: so it is... I did not realise that :/
Apr 08 09:45:08 <bluelightning> sorry if I led you astray
Apr 08 09:46:03 <apelete> no problem, you pointed me on the right track nonetheless
Apr 08 09:49:34 <bluelightning> I've just fixed the migration guide
Apr 08 10:05:42 <apelete> great
Apr 08 10:07:36 <apelete> bluelightning: if I set 'DEFAULTTUNE_ben-nanonote = "mips32el-nf"' instead of 'DEFAULTTUNE = "mips32el-nf"', the setting is not taken into account
Apr 08 10:07:48 <apelete> what am I missing ?
Apr 08 10:08:11 <bluelightning> apelete: what does bitbake -e | less report for DEFAULTTUNE?
Apr 08 10:08:38 <bluelightning> (in the first instance)
Apr 08 10:17:16 <dv_> apelete: dont trust the regular bitbake output when you run it. I had the same problem. bitbake -e should show that you are using mips32el-nf
Apr 08 10:18:02 <dv_> I hope this is fixed in daryl...
Apr 08 10:18:08 <bluelightning> dv_: you mean the "build configuration" output at the start of the build?
Apr 08 10:18:14 <dv_> yeah
Apr 08 10:18:35 <bluelightning> I'm not sure if anyone filed a bug for that one or whether it got fixed
Apr 08 10:18:41 <apelete> bluelightning: here it is
Apr 08 10:18:42 <apelete> $ bitbake -e | grep DEFAULTTUNE
Apr 08 10:18:42 <apelete> # $DEFAULTTUNE [5 operations]
Apr 08 10:18:42 <apelete> DEFAULTTUNE="mips32el-nf"
Apr 08 10:18:52 <dv_> there you go, it is being used
Apr 08 10:19:38 <apelete> yeah, but build ocnfiguration output is showing wrong info like you said dv_ :
Apr 08 10:19:38 <apelete> TUNE_FEATURES     = "o32 bigendian fpu-hard mips32"
Apr 08 10:19:38 <apelete> TARGET_FPU        = ""
Apr 08 10:19:52 <dv_> I had the same problem, as said. I set DEFAULTTUNE_<machine> to a hardfp setting in local.conf , and it didnt show "callconvention-hard" in the build config
Apr 08 10:20:18 <bluelightning> right; and as apelete is using master (correct?) we still have the bug :/
Apr 08 10:20:25 <dv_> but checking with bitbake -e , and looking at the arguments used for gcc by running ps ax showed me that hardfp was indeed being used
Apr 08 10:20:43 <apelete> bluelightning: yes, using bitbake's master branch
Apr 08 10:20:57 <bluelightning> apelete: what about oe-core?
Apr 08 10:21:01 <dv_> bluelightning: I was pointed to a patch in the mailing list, but it didnt help
Apr 08 10:21:12 <apelete> bluelightning: master branch of oe-core too
Apr 08 10:21:16 <bluelightning> ok
Apr 08 10:21:32 <bluelightning> dv_: could you please file a bug at bugzilla.yoctoproject.org?
Apr 08 10:21:38 <dv_> http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/30164 <- this one
Apr 08 10:22:17 <dv_> gotta go now, but will do as soon as I am able to
Apr 08 10:22:24 <apelete> thanks for helping dv_ 
Apr 08 10:23:38 <bluelightning> thanks
Apr 08 10:50:59 * ensc|w hates anonymous python functions in global .bbclass'es; especially these which do d.getVar(..., True)...   devshell bbclass creates now an huge unreadable stacktrace when a SRC_REV=${AUTOREV} can not be determined
Apr 08 10:52:45 <bluelightning> we could of course fix the error handling so a backtrace doesn't occur
Apr 08 10:54:37 <ensc|w> it is still conceptually broken; why does devshell need to expand ${SRC_REV} in the recipe parsing phase?
Apr 08 11:10:39 <bluelightning> ensc|w: probably because it needs to determine PV ?
Apr 08 11:10:52 <bluelightning> without PV you can't have WORKDIR
Apr 08 11:17:53 <ensc|w> bluelightning: I know this; that's why I hate anonymous python functions in global .bbclass'es; especially these which do d.getVar(..., True).  For PV this might be not a direct problem because this variable it expanded at other places too. But such functions introduce silent problems
Apr 08 11:18:39 <bluelightning> ensc|w: what alternative would you suggest?
Apr 08 11:25:09 <ensc|w> avoid such anonymous functions or use d.getVar(..., False).  For the devshell.bbclass case, I am not sure what to do because all the related code is very dirty and it is not obvious to me when/whether global variables (e.g. os.environ in terminal.bbclass) are set/reset
**** BEGIN LOGGING AT Mon Apr 08 11:28:15 2013
Apr 08 11:43:54 <hrw> hello
Apr 08 11:44:13 <hrw> JaMa: can you take a look at my libvpx and tbb patches?
Apr 08 11:55:28 <hrw> hm. external-toolchain-linaro, GCCVERSION = "linaro-4.7" and it tries to build random gcc with 'bitbake gcc'
**** BEGIN LOGGING AT Mon Apr 08 11:59:37 2013
Apr 08 12:00:34 <JaMa> hrw: btw libunwind_1.1.bb is still failing to build on qemuarm as reported before, not sure why it slipped through my prepush check and I've applied it
Apr 08 12:01:02 <hrw> JaMa: was working here ;(
Apr 08 12:04:01 <hrw> ok sorted out gcc - layers priorities matter
Apr 08 12:20:29 <silvio__> hello hrw 
Apr 08 12:25:03 <hrw> hi silvio__ 
Apr 08 13:18:19 <silvio__> I broken something in my building machine, when I build a SDK, not only my, the gcc executable for i686 are not  deployed inside, some suggest?
Apr 08 13:18:36 <silvio__> could related to this?:
Apr 08 13:18:44 <silvio__> ERROR: Nothing PROVIDES 'virtual/i686-angstromsdk-linux-gcc' (but /home/oe-core/build/../stuff/meta-btw/recipes-devtools/tasks/task-test-toolchain-host.bb DEPENDS on or otherwise requires it)
Apr 08 13:49:42 <apelete> bluelightning: removing defaultsetup.conf from the distro conf file introduced an eglibc build error
Apr 08 13:49:46 <apelete> http://paste.debian.net/248236/
Apr 08 13:50:28 <bluelightning> apelete: looks a lot like your DISTRO_FEATURES is empty or at least has no libc-* features in it
Apr 08 13:55:46 <apelete> bluelightning: that's strange, how can it be empty since there is a "include conf/distro/defaultsetup.conf" in bitbake.conf ?
Apr 08 13:56:08 <bluelightning> apelete: use bitbake -e | less to find out what has happened to DISTRO_FEATURES
Apr 08 13:56:56 <apelete> bluelightning: okay, thanks. (gotta be used to bitbake -e)
Apr 08 13:57:23 <bluelightning> apelete: the tracing of operations is brand new (and very useful in these kinds of situations)
Apr 08 13:57:47 <bluelightning> hence why I suggest piping through less rather than grep since grep will filter out that info
Apr 08 14:15:28 <apelete> bluelightning: adding DISTRO_FEATURES += "${DISTRO_FEATURES_LIBC_DEFAULT}" in distro conf seems to fix it (still building, but got past eglibc already)
Apr 08 14:17:02 <bluelightning> apelete: presumably you're setting DISTRO_FEATURES with = ?
Apr 08 14:17:13 <hrw> | checking for arm-oe-linux-gnueabi-gcc... arm-linux-gnueabihf-gcc -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon --sysroot=/home/hrw/HDD/devel/canonical/aarch64/openembedded/build/tmp-eglibc/sysroots/genericarmv7a -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -isystem/home/hrw/HDD/devel/canonical/aarch64/openembedded/build/tmp-eglibc/sysroots/genericarmv7a/usr/include --sysroot=/home/hrw/HDD/devel/canonical/aarch64/openembedded/bu
Apr 08 14:17:16 <bluelightning> (which is fine)
Apr 08 14:17:20 <hrw> fun
Apr 08 14:19:07 <apelete> bluelightning: using += since I let defautsetup.conf manage the DISTRO_FEATURES setting
Apr 08 14:19:29 <apelete> but I'll read the bitbake -e output more closely to undesrtand why the setting was squashed
Apr 08 14:20:19 <bluelightning> hmm
Apr 08 14:24:58 <dv_> bluelightning: the aforementioned bug with the build config belongs to OE core or to bitbake
Apr 08 14:24:59 <dv_> ?
Apr 08 14:27:35 <apelete> bluelightning: built the kernel successfully by adding DISTRO_FEATURES += "${DISTRO_FEATURES_LIBC_DEFAULT}" (instead of require'ing defaultsetup.conf). time to go back to the bitbake -e output and see what differs
Apr 08 14:27:40 <bluelightning> dv_: I think OE-Core since that's where that info is gathered
Apr 08 14:51:16 <hrw>  /usr/bin/arm-oe-linux-gnueabi-arm-linux-gnueabihf-gcc looks wrong...
Apr 08 14:53:25 <dv_> a little bit, yes :)
Apr 08 14:56:21 <apelete> bluelightning: got it, the culprit is bitbake.conf. it is setting DISTRO_FEATURES ?= "" at line 723
Apr 08 14:56:24 <apelete> http://paste.debian.net/248255/
Apr 08 14:56:39 <apelete> (I love bitbake -e already, powerful feature)
Apr 08 14:57:03 <dv_> yeah
Apr 08 14:57:26 <dv_> but when you start digging into OE, or writing complex recipes, you start wishing for a cluster as the build machine :)
Apr 08 14:57:34 <bluelightning> apelete: ok... I guess it expects the distro config to set an appropriate value in that case
Apr 08 14:57:47 <bluelightning> brb
Apr 08 15:00:22 <afournier> i am baking a library that is hosted on github, but using the tarball from the website. once unpacked the name of the directory is something like "username-Project-dXXXX" how can i specify S so it does not care of the XXXX ?
Apr 08 15:00:50 <apelete> dv_: I built an 8-core cpu machine with 16GB of ram because I was digging into OE
Apr 08 15:01:02 <bluelightning> afournier: hmm... you could mv it at the end of do_unpack perhaps...
Apr 08 15:01:22 <afournier> bluelightning: you always have good ideas !
Apr 08 15:01:27 <apelete> dv_: a cluster may be my next build machine ;)
Apr 08 15:02:36 <dv_> apelete: look at what this guy uses: http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg21702.html
Apr 08 15:05:14 <apelete> dv_: wow. well, I am not digging into OE that hard yet :)
Apr 08 15:05:56 <bluelightning> you don't need a huge machine to get reasonable build times: http://www.burtonini.com/wordpress/2012/11/15/yocto-build-times/
Apr 08 15:09:57 <apelete> that's the kind of build times I get on my 8-core AMD cpu with 16GB of ram (using a 256GB ssd instead of hdd though)
Apr 08 15:11:10 <apelete> seems reasonable to me since the machine was not that expensive (bought the parts last january and assembled it myself)
Apr 08 15:12:47 <apelete> wish I had an intel cpu though, but they were too expensive compared to amd counterparts
Apr 08 15:17:43 <dv_> stick lots of ram in your machine, and you are pretty well off already I guess
Apr 08 15:18:18 <dv_> (because then you have a huge disk cache)
Apr 08 15:20:12 <apelete> yeah, and I'm also using a webcache proxy to cache downloaded archives locally (on a 2TB hdd. ssd is for devel purpose only)
Apr 08 15:23:19 <apelete> caching doesn't work for content downloaded from git/svn/scm, but it's better than nothing (I hate it when a download server is offline when I need it)
Apr 08 15:24:19 <bluelightning> we do produce tarballs from scm fetches... won't help if you don't specify a full fixed revision for SRCREV though
Apr 08 15:25:36 <dv_> I have a "yocto-downloads" directory. it is holy and those who delete stuff from it get hunted down by a squad of men in black. :)
Apr 08 15:25:58 <apelete> bluelightning: you mean there are tarballs of scm fetches available on oe mirrors ?
Apr 08 15:26:40 <bluelightning> apelete: I think we do provide those for releases yes
Apr 08 15:26:56 <bluelightning> apelete: but not necessarily for latest master at a given time
Apr 08 15:27:20 <bluelightning> on the yoctoproject.org mirrors that is
Apr 08 15:28:58 <apelete> bluelightning: that means bitbake will fetch from the tarballs instead of the scm if I give it the exact SRCREV in a recipe ?
Apr 08 15:32:55 <apelete> while working on oe-classic I found out that having a dl server going offline is a huge pain in the back, that's why I setup a webcache proxy locally (and I configured it to keep files on the disk for months)
Apr 08 15:35:29 <bluelightning> apelete: ah now I see what you mean by webcache
Apr 08 15:36:04 <bluelightning> apelete: you can set up a local mirror with PREMIRRORS (even easier setup via own-mirrors.bbclass)
Apr 08 15:37:32 <apelete> bluelightning: good to know, wasn't aware of that so I chose to set up squid on my build machine
Apr 08 15:38:08 <apelete> every single download goes through squid, and if the file has been download before, it is served from the hdd
Apr 08 15:38:48 <apelete> except for files hosted on a scm of course
Apr 08 15:39:26 <apelete> s/download/downloaded/
Apr 08 15:44:53 <ensc|w> is it expected that do_package_setscene() is executed for every package everytime when an image is built?  do_fetch + do_write_srcrev + do_build + do_rm_work is called for every package in RunQueue then
Apr 08 15:46:53 <bluelightning> ensc|w: it's a known interaction problem between buildhistory and rm_work in latest master
Apr 08 15:47:13 <ensc|w> ok, thx
Apr 08 15:47:57 <bluelightning> ensc|w: FYI: http://lists.linuxtogo.org/pipermail/openembedded-core/2013-April/037881.html
Apr 08 15:48:17 <bluelightning> I should have a go at doing the postfunc change tonight actually
Apr 08 15:49:23 <dv_> btw how do you call something like VAR[index] ?
Apr 08 15:49:29 <dv_> what is this? a dictionary?
Apr 08 15:49:34 <bluelightning> dv_: that's a varflag
Apr 08 15:49:40 <dv_> ah
Apr 08 15:50:10 <dv_> do the pre/postfunc varflags exist on OE-classic?
Apr 08 15:50:21 <dv_> I have this one recipe that still uses populate_package_prepend
Apr 08 15:50:25 <bluelightning> I'm not sure, but I suspect not
Apr 08 15:50:36 <bluelightning> dv_: that should still be valid...
Apr 08 15:50:46 <dv_> I'd like to replace that with a prefunc. but this recipe is supposed to run with OE-classic as well (specifically OE-classic with arago)
Apr 08 15:51:10 <bluelightning> dv_: that won't be possible because of the tabs/spaces change if nothing else
Apr 08 15:51:16 <dv_> it would solve the issue with the indentations, yocto uses 4 spaces, arago uses tabs
Apr 08 15:51:18 <bluelightning> you'll need to have two different versions
Apr 08 15:51:32 <dv_> but prefuncs are their own functions, they are not simply appended
Apr 08 15:51:43 <bluelightning> indeed
Apr 08 15:51:54 <dv_> which is why I would like to use them. then I need only one version.
Apr 08 15:52:09 <dv_> there would be no mixup of spaces and tabs
Apr 08 15:52:16 <bluelightning> well, I can only say good luck with that - there are other differences
Apr 08 15:52:23 <dv_> :/ oh well.
Apr 08 15:52:31 <bluelightning> it may well work but I'm not sure that it will
Apr 08 15:52:33 <kergoth> it's awy more trouble than its worth. branch and be happy
Apr 08 15:52:36 <dv_> currently I do have two different populate_package_prepend versions
Apr 08 15:52:54 <dv_> I'll stick to that then, as ugly as it may be
Apr 08 16:05:09 <ensc|w> mmh... busybox mount does not work with systemd :(   the 'mount -o remount /' does not make it rw as expected
Apr 08 16:06:51 <kergoth> try an explicit rw, perhaps? mount -o remount,rw /?
Apr 08 16:06:52 * kergoth shrug
Apr 08 16:08:07 <ensc|w> kergoth: systemd's systemd-remount-fs.service calls only 'mount -o remount'
Apr 08 16:08:28 <mr_science> moin
Apr 08 16:08:47 <ensc|w> kergoth: accordingly man-pages, this is the correct thing and mount -o remount should takes options from /etc/fstab
Apr 08 16:12:15 <bluelightning> ensc|w: is it a case that we're currently disabling a busybox option that we need to enable?
Apr 08 16:16:07 <ensc|w> bluelightning: I do not think so; I enabled all mount related options except mtab and see this behavior
Apr 08 16:17:32 <bluelightning> hmm, kind of sounds like a busybox bug then
Apr 08 16:38:24 <hrw> does openembedded-core/scripts/sstate-cache-management.sh works for someone?
Apr 08 16:40:31 <hrw> I have 61404 files in sstate-cache (62GB)
Apr 08 16:41:15 <hrw> ok know why
Apr 08 16:41:42 <hrw> wrong cache dir...
Apr 08 17:17:54 <apelete> bluelightning: built the kernel successfully with the right distro_features setting, at last. (thanks for your help btw)
Apr 08 17:18:07 <bluelightning> apelete: np
Apr 08 17:18:40 <apelete> but I'm still getting a weird error messages at the end of the build:
Apr 08 17:18:40 <apelete> ERROR: Creation of tar /fast/devel/oe-core.git/meta-jlime/build/tmp-eglibc/deploy/tar/kernel-vmlinux-2.6.36-r0.tar.gz failed.
Apr 08 17:18:40 <apelete> ERROR: Creation of tar /fast/devel/oe-core.git/meta-jlime/build/tmp-eglibc/deploy/tar/kernel-dev-2.6.36-r0.tar.gz failed.
Apr 08 17:19:34 <bluelightning> apelete: are you inheriting package_tar somewhere?
Apr 08 17:19:52 <apelete> bluelightning: yes, in my distro conf
Apr 08 17:20:04 <bluelightning> ah right, I suspect that may be broken
Apr 08 17:20:06 <apelete> I have PACKAGE_CLASSES += "package_tar"
Apr 08 17:20:15 <bluelightning> do you use that?
Apr 08 17:20:39 <apelete> the tar file ? ye.
Apr 08 17:20:49 <apelete> s/ye./yes./
Apr 08 17:21:03 <bluelightning> ah ok, what for just out of curiosity?
Apr 08 17:21:41 <apelete> it easier to upload the images to the jlime community that way
Apr 08 17:22:04 <apelete> I could tar it by hand I guess...
Apr 08 17:22:12 <bluelightning> apelete: hang on, tarballs of the image and packages are separate things...
Apr 08 17:22:35 <bluelightning> package_tar is about creating a tarball for individual packages
Apr 08 17:22:54 <apelete> ah, that's not what I want then
Apr 08 17:23:03 <apelete> I want tarballs for my images
Apr 08 17:23:20 <bluelightning> ah right, in that case just ensure tar.gz (or tar.bz2, or just tar, etc.) is in IMAGE_FSTYPES
Apr 08 17:23:47 <apelete> okay, I already got that: IMAGE_FSTYPES = "tar.gz tar.bz2 jffs2"
Apr 08 17:24:08 <bluelightning> ok, so you should be set, and you can remove the package_tar line that's causing errors
Apr 08 17:24:17 <apelete> so I guess I won't be needing the PACKAGE_CLASSES += "package_tar" setting
Apr 08 17:24:21 <bluelightning> right
Apr 08 17:24:26 <apelete> thanks.
Apr 08 17:24:32 <bluelightning> (although to be fair it shouldn't error out like that)
Apr 08 17:27:21 <apelete> it errors but the packages are created nonetheless: http://paste.debian.net/248301/
Apr 08 17:27:48 <bluelightning> hmm, odd
Apr 08 17:29:04 <apelete> anyway, I won't be needing them. I only want tarball of my final image and I still have work to do before getting there
Apr 08 17:29:14 <apelete> thanks for helping :)
Apr 08 17:30:05 <bluelightning> apelete: you're welcome :)
Apr 08 17:31:14 <bluelightning> apelete: just looking at your patch... would you mind adding a header to the included kernel patch mentioning what it does, Upstream-Status and adding your signed-off-by?
Apr 08 17:35:48 <apelete> bluelightning: hmm, the changes I did in that patch are already in the mainline kernel. I just looked at the kernel changesets and applied the same fixes.
Apr 08 17:36:12 <bluelightning> apelete: ah ok, it would be Upstream-Status: Backport in that case
Apr 08 17:36:22 <bluelightning> which is really useful to know when you're updating the kernel recipe :)
Apr 08 17:36:37 <apelete> bluelightning: ok, I'll add it then
Apr 08 17:36:40 <bluelightning> thanks
Apr 08 17:37:19 <apelete> bluelightning: is there an exemple of such an header in OE I can look at to get it right ?
Apr 08 17:37:28 <bluelightning> one sec
Apr 08 17:37:32 <apelete> s/exemple/example/
Apr 08 17:39:05 <bluelightning> apelete: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/dropbear/dropbear/nopw-option.patch
Apr 08 17:39:26 <bluelightning> so not too much info needed really
Apr 08 17:40:18 <apelete> bluelightning: great, thanks. I'll do a patch v3 as soon as I can (maybe tonight)
Apr 08 17:40:41 <apelete> gotta go, see you later.
Apr 08 17:40:45 <bluelightning> apelete: thanks, cya
Apr 08 20:20:42 <JaMa> woglinde: I think I know why you're seeing so many do_package_setscene executions with rm_work, http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/035382.html
Apr 08 20:20:49 <JaMa> No enf
Apr 08 20:20:50 <JaMa> of chain tasks depend directly on do_package anymore.".
Apr 08 20:21:10 <JaMa> probably we have too many task still depending on them
Apr 08 20:23:14 <woglinde> hm
Apr 08 22:31:02 <spacecolonyone> So I've got my own bbappend for a kernel, and in it I do MACHINE_KERNEL_PR_append="foo". I build and deploy my angstrom image all works, but opkg list-upgradable reports my kernel as being upgradable. I don't want this
Apr 08 22:31:56 <spacecolonyone> What have I failed to configure to prevent this. In essence, I'd like to break chain so it NEVER reports it can be upgraded
Apr 08 22:39:04 <ant_home> apelete: no way to boot vanilla kernels on ben-nanonote?
**** ENDING LOGGING AT Tue Apr 09 02:59:58 2013