**** BEGIN LOGGING AT Thu May 29 03:00:01 2014 May 29 06:44:41 how to force no clean ${WORKDIR}? I put inherit +="rm_work" into local.conf May 29 06:47:20 remove it May 29 06:48:37 koen: hx4700 today? May 29 06:51:04 koen: in case, the irqs.h patch went upstream, remove it May 29 07:37:03 The documentation says that FULL_OPTIMIZATION's default value is "-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2" May 29 07:37:25 inside bitbake.conf it is FULL_OPTIMIZATION = "-O2 -pipe ${DEBUG_FLAGS}" instead? May 29 07:37:47 I want to compile something with O1 May 29 08:10:33 awesome! May 29 08:10:47 I see this run-postinst package May 29 08:10:51 it solves all my problems May 29 08:11:13 now I can justify why I always say version bump is the best course of action May 29 08:11:21 gotcha May 29 08:22:46 why do recipies point to these kinds of repos? May 29 08:22:55 ---> SRC_URI = "git://anongit.freedesktop.org/systemd/systemd;branch=master;protocol=git May 29 08:23:17 what if I want to make it lower, I cannot browse that url for tags, no idea where that repo comes from May 29 08:23:52 I guess I can check it out and see that way but... so much work May 29 08:25:43 khem: http://pastebin.notk.org/pastebin.php?show=d4cbea45 built for arm with -O2 (tested for cortexA9) May 29 08:25:48 pompomJuice: you can use SRCREV May 29 08:26:09 against github? May 29 08:26:23 against git May 29 08:26:39 checking... May 29 08:27:02 khem: (complete gcc call : arm-oe-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/home/bencoh/oe-core/build/tmp-eglibc/sysroots/cubox-i -Wall -O2 -g -I. -I../.. -lrt -o dvb_gen_si dvb_gen_si.c ) May 29 08:27:38 ant_work: the problem is for example I want to modify that systemd_211.bb recipy to be systemd_204.bb May 29 08:27:40 oops May 29 08:27:52 for some reason bitbake recipies are not built that way anymore? May 29 08:28:02 PV from filename outdated? May 29 08:28:33 usually the versioned recipes d/l a tarball May 29 08:28:36 so I go into the file and change the SRCURI manually, but I can't because the SRC_URI points to a git repo that is not online May 29 08:28:44 aah May 29 08:28:53 why tarball when it is better? May 29 08:28:56 oop May 29 08:28:57 or not May 29 08:28:58 nm May 29 08:29:02 git is not better May 29 08:29:14 ma bad May 29 08:29:50 see: http://tinyurl.com/pr8s3my May 29 08:30:43 makes sense because a rebuild destroys your companies internet for a while May 29 08:30:53 why cant they fix git to prune mode May 29 08:31:02 or gief head bytes only May 29 08:32:32 for example, systemd_211 contains this SRCREV=3a450ec5 May 29 08:32:43 I cannot find that rev on github/systemd May 29 08:33:22 cant find it on anongit either May 29 08:33:33 maybe this anongit spies on me? May 29 08:34:42 maybe this anongit version is recipy spesific? May 29 08:35:38 you can find the tags in github May 29 08:35:40 i.e. May 29 08:35:41 https://github.com/systemd/systemd/tree/v211 May 29 08:36:38 so https://github.com/systemd/systemd/archive/v211.zip May 29 08:37:03 but it is much easier to specify a SRCREV in your .bbappend May 29 08:37:19 I still don't know why we disallowed git tags in SRCREV btw ;) May 29 08:38:02 personally I don't like the github interface May 29 08:38:35 but yes, you can see the tags, hidden besides branch combo May 29 08:40:47 kernel.org cgit is much more clear imho May 29 08:41:42 * ant_work wonders who asked for the picture of the committer on each github patch May 29 08:42:50 cgit <3 May 29 08:44:55 morning all May 29 08:47:20 where is it morning now? May 29 08:47:26 You must be in the ocean May 29 08:47:33 or west coast May 29 08:47:46 http://www.total-knowledge.com/~ilya/mips/ugt.html May 29 08:47:55 gm bluelightning May 29 08:48:01 I am with bencoh on this one May 29 08:48:11 now I have to work with hashtags instea of human tags May 29 08:48:26 thats like going backwards? May 29 08:48:47 must be a security issue im sure May 29 08:48:50 pompomJuice: I'm in the UK ;) May 29 08:48:58 you bastard May 29 08:49:02 late sleeper May 29 08:49:38 ;) May 29 08:50:00 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration-1.6-matching-branch-requirement-for-git-fetching May 29 08:51:07 ;nobranch=1 May 29 08:51:09 woop May 29 08:51:27 I just happen to get those validation errors now May 29 08:51:35 which is strange I did not expect them May 29 08:51:51 Fetcher failure: Unable to find revision 606c24e3bd41207c395f24a56bcfcad791e265a5 in branch v204 even from upstream May 29 08:51:58 git://github.com/systemd/systemd.git;branch=v204;protocol=https May 29 08:52:11 SRCREV = "606c24e3bd41207c395f24a56bcfcad791e265a5" May 29 08:52:20 that is legal, but got rejected May 29 08:53:05 is that the hash of the tag or the hash of the revision it points to? May 29 08:53:09 because the former will not work May 29 08:55:04 checking... May 29 08:55:16 what I normally do is May 29 08:55:20 go here --- > https://github.com/systemd/systemd/tree/v204 May 29 08:55:32 click on latest commit copy sha May 29 08:55:41 that is the sha that is not working May 29 08:55:58 so I donno about tags and things... don't think that sha is a tag at all... May 29 08:56:07 just HEAD in a branch May 29 08:56:31 but yea with the nobranch=1 May 29 08:56:33 it will work May 29 08:57:25 well, that should work... May 29 08:57:31 wait you said former wont work...? May 29 08:57:57 AFAIK you cant have SRCREV on something that is not a annotated tag? May 29 08:58:01 I meant that tags have a hash all of their own, which is different from the actual code revision they point to May 29 08:58:03 in 1.6? May 29 08:58:40 btw, v204 is a tag, not a branch, so specifying that as the branch is where things are going wrong... May 29 08:58:49 aah May 29 08:58:50 take it slow May 29 08:59:33 completely messed that up May 29 08:59:34 lol May 29 09:06:07 I'm struggling to change systemd_211 to build 204 May 29 09:06:11 now im getting May 29 09:06:12 Failure expanding variable do_fetch[file-checksums], expression was ${@bb.fetch.get_checksum_file_list(d)} which triggered exception ValueError: need more than 1 value to unpack May 29 09:13:19 that's a bug May 29 09:13:39 could you help me to reproduce it? May 29 09:14:43 trying to understand the code and docs, what is a SCM? May 29 09:14:52 basically May 29 09:15:35 to reproduce -> copy systemd from oe-core to mata-copmany/recipies May 29 09:16:04 rename systemd_211.bb systemd_204.bb May 29 09:17:58 SCM = source code manager (i.e. version control system) May 29 09:17:59 let me get a patch May 29 09:20:05 http://hastebin.com/ubucewasig.diff May 29 09:20:29 patch systemd_204.bb with that May 29 09:20:35 then try to build the recipy May 29 09:22:30 that patch applies on 211, needs to be 204 May 29 09:22:33 but yea May 29 09:22:44 pompomJuice: if you create your .bb why don't you d/l the tarball? May 29 09:22:46 that just says 211 cause that is how I made the patch May 29 09:22:55 uuhm May 29 09:23:03 shit May 29 09:23:04 ok May 29 09:23:05 lol May 29 09:23:11 pompomJuice: if you add a .bbappend you only have to care about SRCREV May 29 09:23:28 serious May 29 09:23:31 lol May 29 09:23:35 ok let me try that May 29 09:23:38 well, and PV May 29 09:23:47 depends on the reicpe May 29 09:24:03 yea May 29 09:24:14 could be that I tried that and it failed May 29 09:24:17 let me try it again May 29 09:25:35 pompomJuice: aha, got it... it's the trailing semicolon you've added in the SRC_URI line May 29 09:25:48 it shouldn't choke on that, but that's why it is at the moment May 29 09:25:56 * bluelightning shall fix May 29 09:25:57 lol May 29 09:26:05 pesky May 29 09:26:28 ant_work May 29 09:26:40 systemd_211.bb does not lend itself to be appended May 29 09:26:46 take the SRC_URI for example May 29 09:26:50 id have to copy it all May 29 09:26:53 and that might change May 29 09:26:57 not cool May 29 09:27:04 but yea I hear ya May 29 09:27:17 why does the SRC_URI need changing? May 29 09:29:00 well, if I append the recipy May 29 09:29:26 id need to change/override the SRC_URI... that URI contains more than just the git url, but some patches too May 29 09:29:32 say tomorrow someone adds another patch May 29 09:29:35 I wont get it May 29 09:30:02 I suspect it will be easier for you to create a 204.bb using the tarball and set your PREFERRED_VERSION accordingly May 29 09:30:03 since I overwrite it with yesterdays SRC_URI that was adapted to take in the tarball instead of the git repo url May 29 09:30:14 I agree May 29 09:30:21 pompomJuice: I understand that you're trying to change the first line of SRC_URI, I'm just not sure why... May 29 09:30:27 oh May 29 09:30:29 hehe May 29 09:30:48 I inherited this project that got baked into kernel 2.6.37 and that kernel only supports up to 204 May 29 09:30:50 disaster May 29 09:31:10 right, but can't 204 be fetched from the original repository? May 29 09:31:14 so we are running on borrowed time here May 29 09:31:44 No I had trouble because of that semicolon;) May 29 09:32:19 wait May 29 09:32:22 there is a way May 29 09:32:26 I'm just thinking you probably shouldn't need to change SRC_URI at all May 29 09:32:33 just PV and SRCREV May 29 09:32:40 oh yea May 29 09:32:49 but that brins me to my earlier issue May 29 09:33:12 (I mean, unless the current SRC_URI includes stuff that is incompatible with 204, such as patches specific to 211 - not sure if that is the case) May 29 09:33:34 yea May 29 09:33:39 it does May 29 09:33:42 now I remember May 29 09:33:49 I actually took the last working 204 recipy May 29 09:34:16 that broke in 1.6 because the postinst stuff got moved to a package instead ( this is what I am after, this is why I am upgrading from 1.5 to 1.6) May 29 09:35:47 I am seeing some strange things in systemd_211.bb May 29 09:36:01 file://0001-uClibc-doesn-t-implement-pwritev-preadv.patch May 29 09:36:24 Index: systemd-209/src/libsystemd/sd-bus/test-bus-memfd.c May 29 09:36:34 that patch refers to 209? May 29 09:36:36 anyway May 29 09:36:44 maybe it goes from src upwards May 29 09:37:08 since the patch is effectively applied with -p1 that part of the path is ignored May 29 09:37:13 aah May 29 09:37:18 so it goes from src May 29 09:37:23 makes sense May 29 09:37:29 it is possibly an indicator that the patch is designed for v209 and upwards though, so it may fail to apply to v204 May 29 09:37:38 absolutely May 29 09:37:54 angstrom yocto 1.6 might fail with systemd 204 May 29 09:38:00 we are walking a tightrope here May 29 09:38:06 I dont like it May 29 09:38:12 but that is the kinds of things we deal with May 29 09:38:20 I am suprized I got this far May 29 09:38:29 systemd possibly has 5000 bugfixes a day May 29 09:38:34 yet I can roll it back May 29 09:38:39 bizarre May 29 09:38:55 using sysvinit is not an option? May 29 09:39:02 I use angstrom May 29 09:39:23 not sure is that the def way to go there? systemd is nice and does more for me that sysvinit does at the moment May 29 09:39:36 systemd is actually the core of everything we do on the device May 29 09:39:52 before was udev, now systemd is the nightmare ;) May 29 09:39:54 the irony being it is the one damn program that I cannot upgrade May 29 09:40:11 systemd 204 should be buildable - but it does seem like overriding the entire SRC_URI value is the right way to go actually May 29 09:40:13 have you printed one of those "graphs" yet May 29 09:40:15 haha May 29 09:40:19 I printed it May 29 09:40:22 then I saw it May 29 09:40:23 if patches are added to the core recipe I think you actually won't want those anyway May 29 09:40:25 then I gave up May 29 09:41:16 systemd dependicy graphs May 29 09:41:32 absolute madness May 29 09:49:59 ok it is building again... May 29 09:51:17 best thing I can do now is migrate anything that does not patch systemd211 to my systemd204 since those might be oe/angstrom spesific May 29 11:07:33 bluelightning, hey. are you familiar with the output of bitbake -S printdiff ? I wonder if there is a problem in master since the output looks kind of strange, at least on my setup here May 29 11:08:18 kroon: not completely (I had occasion to try it yesterday), but what are you seeing? May 29 11:10:13 bluelightning, the output says bitbake cannot reuse certain cached artefacts from sstate, still, when I bitbake the recipe it seems to run completely from sstate cache May 29 11:10:34 hmm, that's odd May 29 11:10:48 are you using SSTATE_MIRRORS at all? May 29 11:12:05 no. but I am big fan of wipe-sysroot/cleanup-workdirs/sstate-cache-management, and I almost always do incremental builds May 29 11:12:50 so i thought maybe i'm hitting some rare corner case here May 29 11:13:17 success angstrom yocto 1.5 to 1.6 only took 2 days May 29 11:13:23 good job men! May 29 11:13:55 kroon: hmm... well it would appear to be broken somehow by the sounds of it May 29 11:14:22 does it report what the actual difference is? May 29 11:15:12 bluelightning, yeah i get reports about things that changed for a couple of depending packages May 29 11:16:29 it looks ok on a fresh daisy build May 29 11:17:12 oh well. i'll see if I can do something about it, otherwise perhaps file a bug May 29 11:21:18 can someone explain how this run-postinsts package works? May 29 11:33:17 if I am on oe-angstrom build I can safely ignore any uClibc patches right? we use elibc May 29 12:22:38 pompomJuice: be prepared, soon it will be musl libc May 29 12:24:37 lol May 29 12:25:08 I guess glibc will be for LSB comaptibility May 29 12:25:20 only May 29 12:28:46 this is a longshot but May 29 12:29:58 ant_work: ask yourself for which archs LSB is defined May 29 12:30:02 I moved now fro 1.5.1.6 and I get basic kernel panic unable to mount root -> http://hastebin.com/galeforigu.sm May 29 12:30:16 how can that be? May 29 12:30:23 did not change the kernel at all May 29 12:30:28 or my image May 29 12:30:39 anyone else get this... maybe I get a freeby here May 29 12:30:42 pompomJuice: which filesystem is on p2 ? May 29 12:30:59 double checking May 29 12:31:16 ext4 May 29 12:31:18 yea May 29 12:31:51 created like this: EXTRA_IMAGECMD_ext4 += " -i 4096 -O ^huge_file -O ^has_journal -E stride=2,stripe-width=256 -b 2048" May 29 12:32:02 and you set rootfstype=ext4 on the cmdline? May 29 12:32:08 and ext4 is builtin? May 29 12:32:16 I thought my tuning broke it so I took it back to this -> EXTRA_IMAGECMD_ext4 += " -i 4096 -O ^huge_file" May 29 12:32:18 still same error May 29 12:32:19 and if it's a module, is it present in th erootfs? May 29 12:32:37 it should be as this worked on 1.5 May 29 12:32:41 id be suprosed May 29 12:32:57 surprised if I changed aything that broke that, or I cant see how May 29 12:33:11 that error you posted says "failed to mount", which usually means "fs driver not installed" May 29 12:33:13 I only changed minor cosmetic issues with some recipies, other than that 1.6 works out of the box May 29 12:33:18 yea I know May 29 12:33:23 same kernel as I said May 29 12:33:33 let me check though May 29 12:33:43 maybe sunspot activity changed my kernel config May 29 12:34:58 checking... May 29 12:35:27 something is up May 29 12:35:31 I cant mount it in linux either May 29 12:37:45 seems to be garbage May 29 12:39:24 where can I see in the logs what it was doing when creating that FS? May 29 12:40:04 when I grep mmcblk0p2 in my image work folder I get nothing May 29 12:40:44 it's like the partition is made but no mk2fs.ext4 is being run.. May 29 12:41:41 and you set rootfstype=ext4 on the cmdline? May 29 12:41:44 testing that now May 29 12:41:51 but I doubt it May 29 12:43:59 aah wait May 29 12:44:15 I have one more part I forgot to backport, ... May 29 12:45:21 yea May 29 12:45:48 there is a meta-angstrom/conf/distro/angstrom-v2014.06.conf that I need to backport May 29 12:47:14 wait i dont have to anymore May 29 12:47:29 that redicilous line that restricted systemd to a particular version has been removed May 29 12:47:30 woop May 29 12:47:54 don't get excited May 29 12:48:03 hehe May 29 12:48:04 there will be a line for 213/214 soon May 29 12:48:16 ok then I will not remove the tech I built to override that May 29 12:48:27 I wanted to check by you if my trick is legit.. May 29 12:49:17 I create a meta-company/conf/distro/angstrom-v2014.06.conf that contains the override and the include to the original file inside meta-angstrom...? May 29 12:49:20 is that legal? May 29 12:49:22 it worked May 29 12:49:38 include ${ANGSTROM_BASE}/conf/distro/angstrom-v2014.06.conf May 29 12:49:38 PREFERRED_VERSION_systemd = "204" May 29 12:54:03 where in the logs can I find the part where it is creating that partition? May 29 12:54:15 I am unclear as in what part it happens May 29 12:54:23 I assumed it was in the do_rootfs on the image part May 29 12:54:28 but I dont see anything.... May 29 12:58:26 log.do_rootfs for the image I would suggest... May 29 12:58:37 ok so it is there.. May 29 12:58:38 checking... May 29 13:09:55 the rootfs image seems to work... May 29 13:09:59 when I mount the file... May 29 13:16:42 qemu-img convert -f raw "${SDIMG}" -O vmdk ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.sdcard.vmdk May 29 13:25:50 looks like these dudes made a new image.bbclass to make an SDCARD image that is vmdk May 29 13:25:56 I suspect this has been done in the meantime May 29 13:25:59 how? May 29 13:37:03 I see the vmdk.bbclass uses ext3? is that better than ext4 for sdcards? May 29 13:37:15 or is ext3 ext4 w/o journalling? May 29 13:38:14 ext3 has journalling May 29 13:38:23 ext4 has extents and other things May 29 13:38:59 since our fstype is ext4 with journalling.. pretty vanilla like you would have on your desktop... surely that is not correct? May 29 13:39:22 sorry May 29 13:39:27 I have in the meantime removed journalling... but I have no idea what is the best setup for a embedded device that boots of an SDCARD... May 29 13:39:32 ext4 has journalling and extents May 29 13:39:32 I added noatime May 29 13:39:42 I see May 29 13:40:04 would you use ext4 or ext3 on SDCARD that has low io? May 29 13:40:11 ext4 May 29 13:40:22 higer io still ext4? May 29 13:40:26 es May 29 13:40:28 yes May 29 13:40:36 ext4 is pretty much always better May 29 13:40:48 then why does the vmdk.bbclass use ext3? May 29 13:40:53 dunno May 29 13:41:25 actually I have no idea what I am reading here.. May 29 13:41:32 I generate sd card images outside OE since I need root privs for some operations May 29 13:41:38 it has a dependency on ext3, its not using ext3 May 29 13:41:48 hectic May 29 13:42:01 what kind of image creation commands require root, and why would they? May 29 13:42:23 GPT partitioning May 29 13:42:34 gpt installs the backup block at the end of the disk May 29 13:42:42 so you need a real sdcard May 29 13:42:45 among other things May 29 13:43:16 I added this to my oinage May 29 13:43:20 IMAGE_FSTYPES = "ext4 vmdk" May 29 13:43:33 but I see no vmdk being produced... what am I doing wrong May 29 13:43:48 never used vmdk images May 29 13:43:54 shit May 29 13:43:56 ok May 29 13:44:06 takes long to flash onto the sdcard? May 29 13:44:06 and most of the sdcard images produced are useless May 29 13:44:20 a 40MB root partition May 29 13:44:25 so I need to resize it May 29 13:44:38 and resizing takes longer than creating it from scratch May 29 13:44:48 well it seems at the moment that my partition is being magled by this vmdk process that was in this custom sdcard-image.bbclass in our project... May 29 13:44:56 can I just replace it with stock image.bbclass...? May 29 13:45:07 no idea May 29 13:45:12 ok.. May 29 13:45:44 if you do a bitbake myinage May 29 13:45:53 what file to you normally flash to your sdcard then? May 29 13:46:20 you extract the tar.gz on a partition - that's all May 29 13:46:46 we used to have winimage May 29 13:49:51 koen: if you are short in time I can build for hx4700 and upload on github May 29 13:50:02 tolchain is already built May 29 13:50:04 +o May 29 14:16:28 I disabled journalling on our ext4 that runs on sdcard May 29 14:16:39 but then someone yanked the power and the fs broke May 29 14:16:47 an fsck.ext4 solved the problem... May 29 14:17:03 what would be the reccomendation if you want to extend your sdcard image life May 29 14:17:30 our sdcard is 8GB in size, 4 GB of it acts like a rolling buffer May 29 14:18:55 1) don't powercycle the card May 29 14:18:59 2) don't write to the card May 29 14:19:14 it seems powercycling kills the cards faster than writing to them May 29 14:23:44 a rolling buffer is prolly a sure way to kill it ;) May 29 14:25:02 wait May 29 14:25:07 let me explain further May 29 14:25:17 because this issue is a massive bother for me May 29 14:25:26 our device logs electricity May 29 14:25:29 at a huge rate May 29 14:25:37 then spits the data into a local sqlite3 db May 29 14:25:44 that is the "rolling buffer" May 29 14:25:55 then the data is uploaded to the mother server May 29 14:26:09 I have noticed that our devices come back after 3 months or so with corrupt filesystems May 29 14:26:26 I presume it is because the sdcard was warn out... but I am a noob I have no feeling for these things... May 29 14:26:46 in this channel however I am sure someone knows the answer May 29 14:26:50 "huge" rate ? May 29 14:26:55 well May 29 14:27:00 it depends May 29 14:27:19 let me ask the data dude May 29 14:27:38 depends on how it is logging May 29 14:28:31 I would say May 29 14:28:33 worse case May 29 14:28:43 it will fill up that 4GB in 6 months or so May 29 14:28:55 but May 29 14:29:01 it could also fill that up in 2 days May 29 14:29:12 so we wont deploy a device with such settings May 29 14:30:33 but the device must go into a factory and we dont wanna maintain it for the next 5 years May 29 14:35:35 back to the hole vmdk issue May 29 14:36:28 I make development builds on a Oravle VBOX VM on my windows PC... heresy I know... May 29 14:36:35 the USb interface is dog slow May 29 14:36:46 so normally I would copy the vmdk out into windows and write it May 29 14:36:51 but now vmdks are bad May 29 14:36:59 what would be the alternative? May 29 17:18:17 Any chance someone can tell me how to force the rootfs to complete despite conflicts? May 29 17:19:47 blilly: what is the conflict? May 29 17:22:48 bluelightning: turns out that qt4-x11 and qt4-embedded will happily coexist, unless you build qtserialport with dev, then it pukes on qt-assistant and friends May 29 17:23:41 (qt4-embedded ? undead from the past ?) May 29 17:23:57 blilly: it sounds like you have a dependency on the main qt4-x11 or qt4-embedded package, which almost certainly is not what you want (because that pulls in absolutely every package that Qt builds, rather than specifically the packages you would normally want) May 29 17:24:09 bencoh: still "current" in Qt4 May 29 17:24:13 qtserialport is cmake based, right? May 29 17:25:02 bluelightning: turns out I'm ok with having it pull everything in, since the image is meant for demonstration/development May 29 17:25:08 koen: yes, I believe so May 29 17:25:24 the stock findQT cmake macros suck May 29 17:25:47 (isn't qtserialport qt5?) May 29 17:26:47 koen: my understanding is that exists in both places May 29 17:27:06 or can May 29 17:30:23 blilly: so the short answer is there's no way to force do_rootfs to ignore conflicts, you will have to resolve them May 29 17:30:53 one way to do that is not to install all of qt; just install those packages you need and exclude the overlapping packages May 29 17:31:27 ultimately I need the includes, and couldn't care less about the rest May 29 17:31:52 but am not sure how to accomplish that May 29 17:33:50 probably just explicitly install all of libqt*-dev May 29 17:34:47 where you can find the actual names under packages-split in the workdir for the Qt recipe i.e. bitbake -e qt4-x11-free | grep ^WORKDIR= May 29 17:34:59 bbl May 29 17:35:06 bluelightning: thanks May 29 20:00:45 hi May 29 20:01:33 i need help in making an os for my beaglebone board May 29 20:01:54 i am new to oe could any one help me getting started May 29 21:31:54 bluelightning: Thanks again, that did the trick. May 29 21:37:46 gokukameha: You should look here: https://www.yoctoproject.org/download/texas-instruments-arm-cortex-a8-development-board-beaglebone , here: beagleboard.org/project/yocto-project/ , and the #beagle IRC channel May 29 21:38:28 gokukameha: http://www.crashcourse.ca/wiki/index.php/Building_for_BBB_using_OpenEmbedded and here also May 29 21:55:17 * darknighte signs off for a long birthday weekend May 29 22:26:29 JaMa: we owe you all a beer for the 14 days build ;) May 29 22:31:06 ant_home: hehe, thanks May 29 22:31:38 /who | wc -l looks like right amount of beers for next 14 days :) May 29 22:32:46 at least for june ;) May 29 22:36:33 ant_home: you haven't seen how we dring good czech beer :) May 29 22:36:49 ups, first typo after 6 beers :) May 29 22:37:03 heh **** ENDING LOGGING AT Fri May 30 02:59:59 2014