**** BEGIN LOGGING AT Thu Sep 26 02:59:59 2013
Sep 26 03:07:34 <thirtythreeforty> New question.  If a bitbake builder needs to fetch code from a git server that requires authentication, what's the best way to handle that?
Sep 26 03:30:15 <ausxxh> noticed python are all under devtools, python is used more and more on the target these days
Sep 26 03:30:42 <ausxxh> not just as devtool
Sep 26 03:48:45 <nrossi> thirtythreeforty: probably the easiest way is with protocol=ssh and use a key-pair
Sep 26 03:49:09 <thirtythreeforty> Key pair, gotcha, nrossi.  So each build machine gets a key.
Sep 26 03:49:44 <nrossi> thirtythreeforty: or just have a role account with the same 'build' user private key on each machine
Sep 26 03:50:05 <thirtythreeforty> better, ok
Sep 26 04:20:22 <thirtythreeforty> Another question, anyone.  If I want to check out the current commit on master when I build, how do I do that?  Is that a good idea, or should I tie it to a specific commit?
Sep 26 04:21:13 <nrossi> thirtythreeforty: You can do it with AUTOREV, there are some drawbacks. Specially it needs to do a ls-remote during the recipe parsing phase
Sep 26 04:21:56 <thirtythreeforty> nrossi, all the Git calls should be across a LAN only, so I'm not worried about network.  Can you point me at those docs?  Looks like what I need
Sep 26 04:21:58 <thirtythreeforty> .
Sep 26 04:22:17 <nrossi> thirtythreeforty: Look at https://github.com/Xilinx/meta-xilinx/blob/master/recipes-kernel/linux/linux-xlnx-dev.bb it is how we do it on the meta-xilinx layer for our kernel
Sep 26 04:22:50 <nrossi> thirtythreeforty: we also setup the AUTOREV in an annon method to get rid of the pesky ls-remote in parsing :)
Sep 26 04:24:29 <thirtythreeforty> nrossi, so:
Sep 26 04:24:40 <thirtythreeforty> SRCREV = ${AUTOREV}
Sep 26 04:24:41 <thirtythreeforty> ?
Sep 26 04:25:14 <thirtythreeforty> (If I don't care about ls-remote)
Sep 26 04:25:43 <nrossi> thirtythreeforty: yep thats it
Sep 26 04:26:06 <nrossi> thirtythreeforty: don't forget the "s though :)
Sep 26 04:26:07 <linu> hi all i got the follwing error while compiling poky on ubuntu machine for arm,actually i am fresher for poky so i could not find any solution in net,error is http://pastebin.com/sfs5ZA1U  can you tell me what is that issues
Sep 26 04:26:21 <thirtythreeforty> ok, thanks a bunch nrossi
Sep 26 04:29:44 <nrossi> linu: try to recompile, looks like something caused corruption of the object file while builing
Sep 26 04:30:00 <nrossi> linu: bitbake -c cleansstate glib-2.0 ; bitbake glib-2.0
Sep 26 04:30:54 <nrossi> linu: opps sorry that should be 'glib-2.0-native'
Sep 26 04:31:49 <linu> nrossi, bitbake -c cleansstate glib-2.0-native ; bitbake glib-2.0-native  right?
Sep 26 04:32:04 <nrossi> linu: yep that should do a full clean and rebuild
Sep 26 04:41:09 <linu> nrossi ya it is working thanks for ur effort http://pastebin.com/vYfZsEV9
Sep 26 04:43:57 <nrossi> linu: good. Yer sometimes you can get obscure errors on corruption. If you similar issues you might have fault hard in your build machine (just keep it in mind)
Sep 26 06:56:02 <BjornArnelid> Good morning
Sep 26 07:29:16 <bluelightning> morning all
Sep 26 08:27:48 <TuTizz> morning, I want to build my own Qt apps, SRC_URI = "svn://1.2.3.4/;protocol=svn;module=myModule;rev=1515;user=me;pswd=mypswd", the recipe failed with : "| ls: cannot access *.pro: No such file or directory"
Sep 26 08:28:35 <TuTizz> where should be the myProject.pro? I put it in svn://1.2.3.4/myModule/myProject.pro
Sep 26 08:31:02 <bluelightning> TuTizz: have you set S to point to the correct subdirectory of ${WORKDIR} ?
Sep 26 08:36:52 <TuTizz> bluelightning, ok that was that, I got a different error now, I will try to fix it by myself, thank you
Sep 26 08:55:43 <mckoan> good morning
Sep 26 08:59:52 <jackmitchell> morning all, what package would I use to get the kernel userspace headers in my sdk?
Sep 26 09:00:16 <soldoKyn> hi to all! in my recipe in order to build I have to include some java header files (/usr/lib/jvm/java-7-oracle/include/ not a standard search path). I've done this with EXTRA_OEMAKE = "'CFLAGS=${CFLAGS} -I..." .it's the only way to do this or maybe there's another a way to extend yocto's search path? thanks!
Sep 26 09:09:09 <jackmitchell> ah, ignore, I was being a fool with grep ;)
Sep 26 10:11:38 <RagBal> I'm getting an error on task do_rootfs that no package provides /usr/bin/env, which package provides it?
Sep 26 10:21:52 <bluelightning> RagBal: here smart tells me busybox provides that... did you perhaps customise your busybox configuration and remove that module?
Sep 26 10:23:01 <RagBal> Not afaik, but will check
Sep 26 10:31:23 <RagBal> Weird, busybox wasn't build yet
Sep 26 10:31:58 <RagBal> Seems like it is executing the task now
Sep 26 10:32:08 <RagBal> Thanks bluelightning
Sep 26 10:32:57 <bluelightning> hmm, that is unusual
Sep 26 10:33:06 <bluelightning> there should be an explicit dependency on busybox somewhere
Sep 26 10:34:44 <bluelightning> normally it is pulled in directly by packagegroup-core-boot
Sep 26 11:02:23 <RagBal> Yea, since I include core-image-minimal I assuemed everything would be ok
Sep 26 13:14:03 <Krz-> There is a script: ./meta/recipes-core/initrdscripts/files/init-live.sh which I would like to patch using bbappend to initrdscripts recipe. Unfortunately when function do_patch kicks off it cannot find init-live.sh file to patch.
Sep 26 13:15:07 <Krz-> Is there some special way of patching such scripts? Just to remind initrdscripts is not a tarball under tmp/downloads. It is just that script copied directly from cloned poky/ directory
Sep 26 13:16:12 <bluelightning> Krz-: it's unusual to need to do that; I guess you could add ;patchdir=.. to the SRC_URI entry for the patch
Sep 26 13:17:06 <Krz-> bluelightning: SRC_URI = "file://my.patch;patchdir=.." ?
Sep 26 13:17:17 <bluelightning> Krz-: yep
Sep 26 13:17:30 <Krz-> bluelightning: great, cheers
Sep 26 13:17:42 <rburton> ${WORKDIR} might be more obvious
Sep 26 13:18:01 <bluelightning> yes that should also work
Sep 26 13:18:10 <Krz-> rburton: bluelightning: yeah, right
Sep 26 13:18:47 <bluelightning> I just got patchdir added to the manual recently although I think it's been supported for some time
Sep 26 13:34:52 <Krz-> in recipe/bbappend if I just do do_install_append and forget about do_install -> it will not be kicked off. Is that right?
Sep 26 13:42:08 <bluelightning> Krz-: well do_install is defined in base.bbclass so that shouldn't be the case - it should still work
Sep 26 13:42:36 <ausxxh> I'm trying to add a python module, http://packages.debian.org/sid/python-configshell
Sep 26 13:42:52 <ausxxh> which depends on http://packages.debian.org/sid/python-epydoc
Sep 26 13:43:13 <ausxxh> which pulls in all those document stuff(texlive,etc)
Sep 26 13:44:25 <ausxxh> guess I should just disable python-epydoc dependency for good? the doc build in debian/ubuntu really should be out of its core
Sep 26 13:44:39 <ausxxh> using debian pkg as a reference for yocto here
Sep 26 13:47:04 <Krz-> bluelightning: it's not working for me in my-image.bb recipe, but maybe image recipes are special case
Sep 26 13:47:52 <bluelightning> Krz-: image recipes are special yes, do_install is explicitly marked noexec because image recipes for the most part shouldn't really be running those tasks
Sep 26 13:48:18 <Krz-> bluelightning: I just wanted do add directory to my image, is that wrong place?
Sep 26 13:49:07 <bluelightning> Krz-: yes; the way to do that would be to add a shell function to create the directory and then add a call to the function to ROOTFS_POSTPROCESS_COMMAND
Sep 26 13:49:13 <bluelightning> (within the image recipe)
Sep 26 13:54:54 <Krz-> should I see my ROOTFS_POSTPROCESS_COMMAND function in 'bitbake my-image -c my-function' ?
Sep 26 14:01:59 <bluelightning> Krz-: it's a variable; it's not really designed to be read outside of do_rootfs
Sep 26 14:04:32 <Krz-> ok, I do install -d ${D}/mydir, but it does not get propagated to my rootfs, it creates directory under tmp/work/.../image
Sep 26 14:04:53 <Krz-> what is the variable for tmp/work/.../rootfs ?
Sep 26 14:05:13 <Krz-> I know it's not: ${D}/../rootfs :)
Sep 26 14:05:53 <rburton> IMAGE_ROOTFS = "${WORKDIR}/rootfs"
Sep 26 14:05:56 <rburton> says bitbake.conf
Sep 26 14:14:54 <Krz-> I have one more problem, I have 2 images and they both use the same conf/distro/my.conf. Inside my.conf I defined IMAGE_FSTYPES, but I want this variable do be different depending on which image I build
Sep 26 14:15:11 <Krz-> but if I move IMAGE_FSTYPES from my.conf to image recipe it does not get picked up
Sep 26 14:15:25 <Krz-> :(
Sep 26 14:15:26 <bluelightning> Krz-: hmm, it should
Sep 26 14:16:39 <Krz-> NOISO = "1" NOHDD = "1" should as well?
Sep 26 14:26:30 <Krz-> basically bitbake -e shows: IMAGE_FSTYPES="ext2 cpio.gz", but my image recipe says: IMAGE_FSTYPES += "ext3 live". However after building I get ext2, cpio.gz and ext3
Sep 26 14:26:32 <Krz-> total mess
Sep 26 14:27:27 <Krz-> to simpify I removed IMAGE_FSTYPES from my.conf, so the only place it gets assigned is image recipe
Sep 26 14:30:15 <bluelightning> Krz-: bitbake -e will not show the value from the image unless you do bitbake -e <image>
Sep 26 14:31:27 <bluelightning> bitbake -e just shows the "global" context
Sep 26 14:31:35 <bluelightning> with no arguments
Sep 26 14:31:52 <Krz-> bluelightning: fair enough, bitbake -e myimage shows: ext3 live ext2 cpio.gz
Sep 26 14:32:07 <Krz-> and live is not produced
Sep 26 14:32:25 <Krz-> but if I move 'live' to my.conf file - it gets created
Sep 26 14:39:14 <RagBal> How can I force Yocto to regenerate my image? It just reports that it has nothing to do, even after I change the image recipe
Sep 26 14:39:26 <rburton> RagBal: -f
Sep 26 14:39:35 <RagBal> Nope, same
Sep 26 14:39:50 <RagBal> Only reports that it has tainted the build for a forced build
Sep 26 14:44:01 * RagBal smacks himself on the head
Sep 26 14:44:07 <RagBal> Forgot to inherit image =x
Sep 26 14:45:38 <fray> bitbake -C rootfs <image>
Sep 26 14:45:40 <fray> that will force it
Sep 26 14:45:56 <rburton> inheriting image will also help ;)
Sep 26 14:46:22 <fray> ya.. w/o it being inherited, it won't show up in the checksum..
Sep 26 14:46:42 <RagBal> It just kept making me a nice rpm package hehe
Sep 26 14:50:58 <Krz-> any suggestion on how to define IMAGE_FSTYPES = "live" inside image recipe and get it working? so far live works for me only when defined inside .conf file :(
Sep 26 15:35:37 <RP> Krz-: IMAGE_FSTYPES_pn-xxxx = "yyy"
Sep 26 15:35:38 <RP> Krz-: where xxxx is the image name
Sep 26 15:36:56 <bluelightning> I'm not sure I understand why setting from the image recipe doesn't (or shouldn't) work though
Sep 26 15:38:16 <RP> bluelightning: me neither :/
Sep 26 15:38:22 <RP> unless its a weak defaults kind of issue
Sep 26 15:50:09 <Krz-> so basically doing: IMAGE_FSTYPES_pn-my-image = "live ext3" inside my.conf does exactly same thing - creates only ext3 image, live not created
Sep 26 16:33:49 <Krz> I have the recipe which just copies a file into tmp/deploy/image directory; how should  I kick it off?
Sep 26 16:33:58 <Krz> I don't think 'IMAGE_INSTALL +=' is clean way
Sep 26 16:55:05 <thirtythreeforty> Krz, I don't understand the question.
Sep 26 16:59:34 <Krz> I created a recipe which just creates a file under tmp/deploy/image. I want this recipe to be executed after I type 'bitbake myimage'
Sep 26 17:00:25 <bluelightning_> Krz: ah right, I was confused about what you were asking for as well
Sep 26 17:00:35 <bluelightning_> Krz: EXTRA_IMAGEDEPENDS += "..."
Sep 26 17:00:39 <thirtythreeforty> make myimage depend on the recipe you created
Sep 26 17:01:34 <Krz> good one, I like it
Sep 26 17:34:35 <Krz> is there any way I can force do_install function always to be called even if it was done in previous run? I used EXTRA_IMAGEDEPENDS to execute my recipe
Sep 26 17:40:40 <bluelightning_> Krz: if you're using do_install to poke stuff into tmp/deploy/image, that's not the right thing to be doing
Sep 26 17:41:10 <Krz> bluelightning_: well I can use whatever else do_ function
Sep 26 17:41:20 <bluelightning_> Krz: you should inherit deploy and add a do_deploy task
Sep 26 17:41:23 <Krz> bluelightning_: might create 'do_deploy' and tdo it there
Sep 26 17:41:29 <bluelightning_> Krz: see  meta/recipes-bsp/u-boot/u-boot.inc for an example
Sep 26 17:42:44 <Krz> bluelightning_: will then do_deploy be executed every time?
Sep 26 17:43:56 <bluelightning_> Krz: no; to do that you'll need to set do_deploy[nostamp] = "1"
Sep 26 17:46:16 <Krz> bluelightning_: OK, I've seen it in some bbclass and wondering what was that
Sep 26 20:43:24 <brm> Hi Guys, Anyone know if you can do single-step driver debugging in eclipse-TCF?
Sep 26 20:52:10 <brm> Hi Guys, Anyone know if you can do single-step driver debugging in eclipse-TCF?
Sep 26 21:36:08 <mranostay> brm: likely
Sep 26 21:36:23 <mranostay> not really the channel for that
Sep 26 21:41:19 <jwessel> dvhart: ping
Sep 26 21:41:39 <dvhart> jwessel, yessir?
Sep 26 21:42:02 <jwessel> I was attempting to use the mkefidisk stuff to help Saul finish up testing.
Sep 26 21:42:05 <jwessel> And I ran into a problem.
Sep 26 21:42:12 <jwessel> parted reports:
Sep 26 21:42:15 <jwessel>  1      1049kB  19.9MB  18.9MB  primary  fat16           boot
Sep 26 21:42:23 <jwessel> fdisk -l reports
Sep 26 21:42:24 <jwessel> /dev/sdd1   *        2048       38911       18432   83  Linux
Sep 26 21:42:38 <jwessel> And the efi loader of course doesn't see the disk.
Sep 26 21:42:52 <dvhart> hrm
Sep 26 21:42:53 <jwessel> I suspect because of some mismatch.
Sep 26 21:43:06 <dvhart> this is with mkefidisk using an hddimg?
Sep 26 21:43:10 <dvhart> which hddimg?
Sep 26 21:43:15 <dvhart> sato minimal lsb ?
Sep 26 21:43:16 <jwessel> So that was my next question.
Sep 26 21:43:26 <jwessel> Oh just core-image-minimal
Sep 26 21:43:54 <jwessel> I wasn't sure how the hddimg was used.  I could have totally done something wrong, or perhaps am supposed to have a different path or something.
Sep 26 21:43:59 <dvhart> So I tested that just today and it's working.....
Sep 26 21:44:19 <jwessel> I was using a real disk for the mkefiimg.
Sep 26 21:44:22 <dvhart> I'm trying to help sort out what's going on here as well...
Sep 26 21:44:26 <dvhart> so you did:
Sep 26 21:44:45 <jwessel> /space/jw/yocto/oe-core/build% ../scripts/contrib/mkefidisk.sh /dev/sdd tmp-eglibc/deploy/images/qemux86/core-image-minimal-qemux86-20130926202025.hddimg /dev/sda2
Sep 26 21:44:45 <dvhart> mkefidisk.sh /dev/hostdevice core-image-minimal-xyz.hddimg /dev/sda
Sep 26 21:44:49 <jwessel> I think that is how you use it?
Sep 26 21:44:58 <dvhart> ah, no 2
Sep 26 21:45:03 <dvhart> just the device at the end
Sep 26 21:45:12 <dvhart> it will add the partition as it partitions the device
Sep 26 21:45:45 <jwessel> ok trying again.
Sep 26 21:46:50 <jwessel> hmm...  No luck there either.
Sep 26 21:47:06 <jwessel> I was suspecting it had something to do with the fact fdisk and partprobe don't agree.
Sep 26 21:47:17 <dvhart> definitely
Sep 26 21:47:23 <dvhart> trying that now
Sep 26 21:47:23 <jwessel> Block size=4096 (log=2)
Sep 26 21:47:31 <jwessel> Is what it picked for my super large disk.
Sep 26 21:47:33 <dvhart> very odd
Sep 26 21:47:40 <dvhart> garbage at the front of the disk?
Sep 26 21:47:50 <dvhart> I though I zeroed that out in mkefidisk
Sep 26 21:47:52 <dvhart> looking
Sep 26 21:48:05 <jwessel> I'll see if I can get a smaller disk this time around.
Sep 26 21:48:57 <jwessel> In all the testing I had done with the EFI I had not seen problems.  Saul reported otherwise.
Sep 26 21:49:18 <jwessel> I think it is just the case that with these > 1tb disk mkefidisk.sh doesn't work.
Sep 26 21:49:28 <dvhart> I think so too
Sep 26 21:49:34 <dvhart> or possibly anything using fat32
Sep 26 21:49:40 <dvhart> but I don't know why that would be
Sep 26 21:49:44 <dvhart> sato images are still fat16
Sep 26 21:50:22 <dvhart> so I'm trying a sato-sdk build now
Sep 26 21:50:37 <jwessel> I don't think the disk would have anything to do with the booting.
Sep 26 21:50:50 <jwessel> This is more about the efi -> grub -> kernel
Sep 26 21:51:07 <jwessel> If that part works, the rest has nothing to do with the patches that are pending :-)
Sep 26 21:51:16 <dvhart> I haven't seen a non-functional mkefidisk image yet, so trying to get to that point so I can investigate
Sep 26 21:51:32 <dvhart> Agreed
Sep 26 21:51:46 <dvhart> sgw sees failures at efi->grub though
Sep 26 21:51:51 <dvhart> so I want to sort that out
Sep 26 21:52:10 <jwessel> Right.  That is the part that I am worried about.
Sep 26 21:52:29 <jwessel> I can debug it, if I can duplicate it.  I have a Simics tunnel creek model.
Sep 26 21:53:09 <dvhart> Heh, you're ahead of me then!
Sep 26 21:54:02 <dvhart> jwessel, one point of interest for me is the cfg change to grub-efi where you fixed the default path, allowing for the grub.cfg location
Sep 26 21:54:21 <dvhart> jwessel, wondering if that somehow impacted other cfg settings for the grub-efi build which manifest with the larger images
Sep 26 21:54:35 <dvhart> e.g. disable some defaults because they aren't listed explicitly in the cfg file
Sep 26 21:55:36 <jwessel> Well the way it should work is to auto locate the grub.cfg.
Sep 26 21:55:56 <jwessel> In the not working version Saul had there was a whole pile of grub commands you can run to try and make it go.
Sep 26 21:56:13 <jwessel> And the real thing I was curious about is where was the actual cfg?
Sep 26 21:59:14 <dvhart> yup
Sep 26 21:59:16 <dvhart> me too
Sep 26 21:59:22 <dvhart> we're at the same point it seems
Sep 26 21:59:31 <dvhart> waiting for qt4 to finish building
Sep 26 21:59:40 <dvhart> I should just pad the crap out of minimal and be done with it
Sep 26 21:59:45 <dvhart> hrm......
Sep 26 22:01:50 <dvhart> sgw_, do you have your large .hddimg in a location I could download it?
Sep 26 22:02:22 <dvhart> might be faster than waiting for QT to finish do_package!
Sep 26 22:02:22 <sgw_> dvhart: I can put it in a google drive, it's 2.5 gig or so
Sep 26 22:02:33 <dvhart> OK, not on one of the ABs already?
Sep 26 22:02:52 <sgw_> no, it's my local web-kiosk build
Sep 26 22:02:56 <dvhart> sgw_, could you start the upload just in case?
Sep 26 22:03:04 <sgw_> sure
Sep 26 22:05:35 <dvhart> sgw_, also, can you report the fdisk -l and parted -l output of the usb stick created from that image?
Sep 26 22:07:34 <dvhart> blarg, running sync on a build system can be..... annoying
Sep 26 22:08:46 <jwessel> I figured out one problem and have a patch for your script if I can get it all working.
Sep 26 22:08:57 <dvhart> great, what was it?
Sep 26 22:09:08 <jwessel> I stopped using the > 1TB drive and switched to using a file that was mounted via losetup
Sep 26 22:09:42 <jwessel> The efi creator doesn't let me use a loop back.
Sep 26 22:09:49 <jwessel> And after I did this I could in fact boot the image.
Sep 26 22:10:30 <sgw_> dvhart: redoing a sato / rw / mkefidisk worked for me this time
Sep 26 22:10:51 <jwessel> Do your targets come up to an EFI prompt or go into the loader?
Sep 26 22:11:07 <jwessel> I find the lack of the startup.nsh leaves me sitting in EFI shell.
Sep 26 22:11:18 <jwessel> For the ISO booter, I wrote out a startup.nsh file.
Sep 26 22:11:22 <dvhart> jwessel, that depends entirely on the firmware
Sep 26 22:11:32 <jwessel> Well I have "crap" firmware.
Sep 26 22:11:36 <sgw_> efi countdown -> grub -> boots
Sep 26 22:11:40 <jwessel> Broken in several ways.
Sep 26 22:11:50 <dvhart> yeah, for crap firmware, you need startup.nsh OR to set the boot path
Sep 26 22:11:59 <jwessel> Fair enough.
Sep 26 22:12:03 <dvhart> jwessel, see the MinnowBoard README on how to specifiy a default boot path
Sep 26 22:12:17 <jwessel> I know how the minnow works :-)
Sep 26 22:12:34 <dvhart> jwessel, even that is a bit obnoxious (admittedly)
Sep 26 22:12:37 <jwessel> I was asking more about if we ought to just write out a startup.nsh to make it go in more situations.
Sep 26 22:13:04 <dvhart> jwessel, if it doesn't interfere with the direct boot path (and I don't think it does) we can do that, no objection
Sep 26 22:13:07 <jwessel> The base tiano core is what I am using and that has ZERO for the default of anything.
Sep 26 22:13:22 <jwessel> For direct boot the startup.nsh is skipped.
Sep 26 22:13:38 <jwessel> It only comes into play when you have these non-standard firmwares as far as I have seen.
Sep 26 22:14:06 <dvhart> we can add that as part of the grub-efi.bbclass
Sep 26 22:14:18 <jwessel> I had a patch for the directboot class to do that.
Sep 26 22:14:30 <dvhart> but
Sep 26 22:14:33 <jwessel> I just didn't send any of it because I thought we ought to bottom out this stuff first.
Sep 26 22:14:41 <dvhart> the problem saul hits is that grub starts, but it doesn't find it's grub.cfg
Sep 26 22:14:46 <dvhart> I have repro'd that yet
Sep 26 22:14:53 <jwessel> Me neither.
Sep 26 22:14:58 <dvhart> jwessel, yes, let's sort this out first
Sep 26 22:15:06 <jwessel> I completely agree.
Sep 26 22:15:13 * dvhart needs a faster RAID0 array
Sep 26 22:15:16 <dvhart> OH COME ON!
Sep 26 22:15:36 <dvhart> debugfs needs to be parallelizable too!
Sep 26 22:16:00 <jwessel> That is why we in general don't build disks that way...
Sep 26 22:16:18 <dvhart> this is still just do_rootfs
Sep 26 22:16:36 <jwessel> There are slow parts to that as well, but the genext2fs or debugfs stuff suck.
Sep 26 22:16:48 <dvhart> definitely
Sep 26 22:16:52 <jwessel> Just give me the tar.bz2 and I'll use a loop back to write it.
Sep 26 22:17:06 <jwessel> That is what we do for the "speedy" way of writing it.
Sep 26 22:17:26 <dvhart> ok done
Sep 26 22:17:54 <dvhart> sgw, sato-sdk is large enough to be FAT32
Sep 26 22:17:56 <dvhart> so, here we go
Sep 26 22:18:26 <sgw_> dvhart: great, I guess we will find out next
Sep 26 22:18:56 <dvhart> something is wonky... mkefidisk keeps reporting -20MB for the rootfs, never seen this before
Sep 26 22:23:27 <dvhart> *smirk* So the ACPI 5 Specification uses acronyms for almost everything.... they wisely opted not to shorten: Platform Interrupt Source Structure
Sep 26 22:27:29 * sgw_ minnow failure?  Must be a parallel build issue
Sep 26 22:29:22 * dvhart thinks it's time for a USB 3 card in the build system and some USB3 keys for writing images
Sep 26 22:34:52 <jwessel> dvhart: I sent the patch to the list for adding loop back support for your disk too.
Sep 26 22:34:55 <jwessel> tool even.
Sep 26 22:35:03 <jwessel> At least with that I can make simulator disks.
Sep 26 22:35:15 <dvhart> thanks, will have a look
Sep 26 22:36:06 <jwessel> Drop me a line if you come up with anything to duplicate the failure, and I'll see about fixing it.
Sep 26 22:36:14 <jwessel> Off to dinner.
Sep 26 22:46:09 <dvhart> sgw_, it boots fine
Sep 26 22:46:26 <dvhart> grub comes up with the menu, etc.
Sep 26 22:47:06 <dvhart> sgw_, so, fdisk -l and parted -l output for your non booting kiosk image?
Sep 26 22:47:36 * dvhart caffeinates
Sep 26 22:52:17 <sgw_> sgw@swold-linux:/tmp$ fdisk -l core-image-web-kiosk-minnow.hddimg
Sep 26 22:52:18 <sgw_> Disk core-image-web-kiosk-minnow.hddimg: 2663 MB, 2663940096 bytes, 5203008 sectors
Sep 26 22:52:18 <sgw_> Units = sectors of 1 * 512 = 512 bytes
Sep 26 22:52:18 <sgw_> Sector size (logical/physical): 512 bytes / 512 bytes
Sep 26 22:52:18 <sgw_> I/O size (minimum/optimal): 512 bytes / 512 bytes
Sep 26 22:52:18 <sgw_> Disk label type: dos
Sep 26 22:52:18 <sgw_> Disk identifier: 0x00000000
Sep 26 22:52:19 <sgw_>                              Device Boot      Start         End      Blocks   Id  System
Sep 26 22:52:19 <sgw_> sgw@swold-linux:/tmp$ parted -l core-image-web-kiosk-minnow.hddimg
Sep 26 22:52:20 <sgw_> sgw@swold-linux:/tmp$
Sep 26 22:57:20 <dvhart> sgw_, sorry - after it is written to a disk with mkefidisk :-)
Sep 26 22:57:38 <dvhart> sgw_, right now I can't reproduce a failure
Sep 26 22:57:47 <dvhart> so far as I can tell, everything works as designed
Sep 26 22:58:02 <dvhart> let me know when your image is uploaded
Sep 26 22:58:06 <dvhart> and I'll try with that
Sep 26 22:58:06 <sgw_> Ok, well I am trying again to build the large image.
Sep 26 22:58:21 <dvhart> try another USB key too :-)
Sep 26 22:59:49 <sgw_> I am using another usb key now also.
Sep 26 23:00:13 <dvhart> if that works, you owe me a soda
Sep 26 23:12:16 <dvhart> sgw_, trying your image now
Sep 26 23:28:30 <dvhart> sgw_, it boots fine
Sep 26 23:29:06 <sgw_> I guess I wasted your time with a bad usb
Sep 26 23:29:25 <dvhart> does your new usb stick work?
Sep 26 23:29:50 <dvhart> the other possibility is some leftover junk that my script isn't clearing (like a GPT signature at the end of drive?)
Sep 26 23:30:10 <dvhart> anyway, with this, I think jwessel's patches should go in
Sep 26 23:30:27 <dvhart> I'm content that it works broadly enough that we can work around any issues that crop up
Sep 26 23:30:59 <sgw_> It seems to be booting with the new stick
Sep 26 23:31:14 <dvhart> my bad for not recommending that initially
Sep 26 23:31:21 <dvhart> that is always the first thing. Flash sucks.
Sep 26 23:31:26 <dvhart> burn that stick
Sep 26 23:31:36 <sgw_> dvhart: still interesting is the various size mis-matches (see pm )
Sep 26 23:32:20 <sgw_> actually nevermind, this is looking better.
Sep 26 23:32:55 <dvhart> ok
Sep 26 23:32:58 <dvhart> cool then
Sep 26 23:33:11 <dvhart> sgw_, do you need me to do anything, or can you and RP take it from here?
Sep 26 23:38:41 <sgw_> I guess we can take it from here.
Sep 26 23:40:58 <dvhart> ok, thanks sgw
Sep 27 00:55:24 <jwessel> sgw_: I found the problem with the negative sized partition.
Sep 27 00:55:45 <jwessel> Turns out if the disk initially has a bad label there is a bug in mkefidisk.sh
Sep 27 00:56:01 <jwessel> It will just write a msdos partition that is toast.
Sep 27 01:13:44 <sgw_> jwessel: so there really was an issue, or just if I had a bad label?
**** ENDING LOGGING AT Fri Sep 27 02:59:58 2013