**** BEGIN LOGGING AT Tue Jul 26 02:59:56 2011
Jul 26 09:16:26 <bluelightning> hi all
Jul 26 09:38:29 <yuke> RP__: ping
Jul 26 09:44:58 <yuke> RP__: need to off office now. sent you a email on the SRC_URI BPN handling
Jul 26 09:45:22 <RP__> yuke: ok, thanks
Jul 26 09:48:25 <RP__> yuke: I've replied. I also noticed patches 9 and 10 didn't come through :/
Jul 26 15:47:20 <nitink> Good Morning All !
Jul 26 17:16:36 <sgw> Tartarus: ping
Jul 26 17:16:43 <Tartarus> pong
Jul 26 17:17:22 <sgw> Tartarus: are you planning a v3 of the siteinfo changes based on Phil's comments?
Jul 26 17:17:35 <Tartarus> Was it more than just rp-pppoe?
Jul 26 17:17:50 <sgw> Don't think so from what I could see.
Jul 26 17:18:14 <Tartarus> Then no, just expecting you to not pick up that one part of the series
Jul 26 17:18:39 <Tartarus> Everything should apply pretty easily
Jul 26 17:19:07 <Tartarus> (and even then, the rp-pppoe bit is for a package not in oe-core, it'd just be consolidating the wrong info, eg BE machines are doing it wrong now)
Jul 26 17:19:19 <Tartarus> I'm trying core-image-lsb-sdk build for ppc now that I can then throw on a board
Jul 26 17:19:22 <Tartarus> and see what's what
Jul 26 17:20:36 <sgw> Ok, great.  And Khem's recent request is orthogonal to your change. Touching a different part of siteinfo stuff, right?
Jul 26 17:21:47 <Tartarus> yeah
Jul 26 17:22:56 <sgw> Tartarus: khem Ok, working on the next consolidated pull with siteinfo changes included.
Jul 26 17:26:04 <Tartarus> thanks
Jul 26 18:52:49 <davest> Blog post for the M2 release: http://www.yoctoproject.org/blogs/davest/2011/fresh-yocto-code-m2-milestone-release-embedded-linux-goodness
Jul 26 19:43:10 <Tartarus> yay, oe-core is working right wrt loading multi site files
Jul 26 19:43:34 <Tartarus> configure: loading site script /scratch/oe-core-template/meta-oe/meta-oe/site/en
Jul 26 19:43:34 <Tartarus> dian-big
Jul 26 19:43:34 <Tartarus> configure: loading site script /scratch/oe-core-template/oe-core/meta/site/endia
Jul 26 19:43:34 <Tartarus> n-big
Jul 26 19:43:45 <Tartarus> meta-oe has the right value, oe-core hs the wrong (intentionally, to test)
Jul 26 19:43:47 <Tartarus> meta-oe won
Jul 26 19:58:57 <Tartarus> sgw: OK, rp-pppoe + correct siteinfo pushed to oe.dev, once the current consolidated pull request is out and merged I'll add dropping the oe-core bits to my list
Jul 26 19:59:03 <Tartarus> s/oe.dev/meta-oe/
Jul 26 20:01:42 <sgw> Tartarus: ok
Jul 26 20:02:06 <sgw> should be out later this afternoon, waiting for a couple of builds to finish
Jul 26 20:03:29 <Tartarus> k
Jul 26 20:04:12 <jefferai> this is weird --
Jul 26 20:04:12 <jefferai> jmitchell@antikythera ~/yocto  $  source poky/oe-init-build-env
Jul 26 20:04:12 <jefferai> bash: /home/jmitchell/yocto/poky/scripts/oe-setup-builddir: Permission denied
Jul 26 20:04:31 <jefferai> but, if I change that to instead source oe-setup-builddir instead of running it as a script
Jul 26 20:04:33 <jefferai> then it's happy
Jul 26 20:05:01 <jefferai> ah
Jul 26 20:05:02 <jefferai> nm
Jul 26 20:05:19 * jefferai wonders why the hell noexec is on in this filesystem
Jul 26 21:04:36 <zenlinux> doing a build from scratch using latest master today. shared-mime-info fails during do_compile: http://pastebin.com/gt5sEjr5
Jul 26 21:11:59 <zenlinux> taking a hint from a previous commit by khem, I've tried building with PARALLEL_MAKE disabled, and it's still barfing during the xmllint checking
Jul 26 21:31:49 <jefferai> dvhart: I'm attempting to run bbmatrix, but something is failing -- not sure hat
Jul 26 21:31:50 <jefferai> what
Jul 26 21:31:58 <jefferai> just did a core-image-minimal build myself without a hitch
Jul 26 21:32:23 <dvhart> what are you seeing?
Jul 26 21:33:12 <jefferai> http://paste.pocoo.org/show/447028/'
Jul 26 21:33:15 <jefferai> it goes on a bit...
Jul 26 21:34:00 <dvhart> hrm
Jul 26 21:34:05 <jefferai> scrolls right through
Jul 26 21:36:26 <dvhart> are you doing something to clean the tmp dir or the buildstats?
Jul 26 21:36:35 <dvhart> the script just assumes they are available
Jul 26 21:36:49 <jefferai> no, in fact, the script cleaned the tmpdir
Jul 26 21:36:54 <jefferai> the first time I ran it
Jul 26 21:37:18 <dvhart> so when you built manually, did tmp/buildstats exist at the end of the run?
Jul 26 21:37:45 <jefferai> this was the first attempt: http://paste.pocoo.org/show/447031/
Jul 26 21:38:04 <jefferai> I'm not sure -- I didn't look
Jul 26 21:38:19 <jefferai> I was just building to make sure I had all of the toolchain running on Gentoo :-)
Jul 26 21:38:45 <dvhart> do you still have bb-matrix-8121/04-05-build/04-05-bitbake.log around?
Jul 26 21:38:53 <jefferai> nope, but I can run this again if you want
Jul 26 21:38:54 <jefferai> sec
Jul 26 21:38:56 <dvhart> please
Jul 26 21:39:11 <dvhart> I'm guessing the build is failing somehow
Jul 26 21:39:20 <dvhart> and the tmp/buildstats doesn't show up
Jul 26 21:39:25 <dvhart> we need to catch that
Jul 26 21:39:29 <jefferai> hah
Jul 26 21:39:32 <jefferai> no /usr/bin/time
Jul 26 21:39:36 <dvhart> bwahahaha
Jul 26 21:40:06 <dvhart> so a patch to the script to test for that will be gladly accepted and quickly acked ;-)
Jul 26 21:40:06 * jefferai wonders why that isn't part of gentoo's system profile
Jul 26 21:40:29 <jefferai> will do
Jul 26 21:40:31 <dvhart> yeah, I'm surprised it doesn't have /usr/bin/time as well
Jul 26 21:41:05 * jefferai uninstalls time so that he can test the broken behavior again :-)
Jul 26 21:47:09 <jefferai> ok, patch ready
Jul 26 21:47:21 <jefferai> I assume you want it via git-format-patch?
Jul 26 21:48:50 <dvhart> jefferai, that's fine.
Jul 26 21:51:16 <nitink> fray: can you help me with this : http://pastebin.com/PShYtvU5 ?
Jul 26 21:53:15 <jefferai> do I send it to yocto@ or poky@?
Jul 26 21:54:33 <dvhart> technically, I guess it goes to oe-core
Jul 26 21:55:07 <jefferai> really? bb-matrix is in contrib, I thought it was upstream
Jul 26 21:57:01 <dvhart> oe-core/scripts/bb-perf
Jul 26 21:57:07 <dvhart> oe-core/scripts/contrib/bb-perf
Jul 26 21:57:16 <dvhart> that in turn gets pulled into poky.git
Jul 26 21:57:23 <dvhart> it is rather non-obvious
Jul 26 21:57:26 <dvhart> we're working to improve that
Jul 26 22:02:22 <fray> nitink eek.. thats a failure when building for the SDK right?
Jul 26 22:02:30 <nitink> no
Jul 26 22:02:40 <fray> cat: /disk0/pokybuild/build-multilib-x32/tmp/deploy/rpm/solvedb-sdk-ml_package_archs.conf: No such file or directory
Jul 26 22:02:43 <RP__> fray: no, but its something in the sdk code...
Jul 26 22:02:44 <nitink> fray: it is core-image-minimal with atom-pc
Jul 26 22:02:45 <fray> that makes it seem like it is.. Hmm
Jul 26 22:03:22 <fray> the error (at the end) is exactly that.. the items that are needed were not provided by anything within the system image..  it tried to use the soledb-sdk configuration file to do the reconciliation..
Jul 26 22:03:26 <nitink> my local.conf has:
Jul 26 22:03:26 <nitink> MACHINE ?= "atom-pc"
Jul 26 22:03:26 <nitink> DEFAULTTUNE = "core2-x32"
Jul 26 22:03:26 <nitink> TUNE_PKGARCH = "core2-x32"
Jul 26 22:03:39 <fray> figure out why it did that and you've got the cause..
Jul 26 22:03:54 <RP__> nitink: so you don't have multilib enabled, right?
Jul 26 22:04:00 <nitink> nope
Jul 26 22:04:10 <jefferai> ok, sent
Jul 26 22:05:08 <nitink> RP__: multilib is not enabled
Jul 26 22:05:59 <fray> what branch are you using?
Jul 26 22:08:21 <sgw> RP__: ping, possibly another tune file issue:ERROR: locale_arch_options not found for target_arch=i686
Jul 26 22:08:21 <sgw> ERROR: Function 'unknown arch:i686 for locale_arch_options' failed
Jul 26 22:09:05 <nitink> fary: rpurdie/ml4 + x32 commits + meta-x32 layer
Jul 26 22:09:16 <nitink> fray ^^^
Jul 26 22:09:50 <RP__> sgw: perhaps drop the X86ARCH32 ?= "i686" from tune-core2
Jul 26 22:10:18 <nitink> fray: binutils, gcc, glibc, linux-libc-headers, linux recipes are coming from meta-x32
Jul 26 22:14:36 <sgw> RP__: did you hear about the pstage_fetch failure?
Jul 26 22:14:56 <RP__> sgw: no?
Jul 26 22:15:48 <sgw> RP__: Only on the autobuilder right now, checkout http://pastebin.com/0eMPaYz0
Jul 26 22:17:21 <sgw> RP__: from my initial debugging seems to be having problems with SSTATE_DIR, it creates a build/"/yocto/testing/build/sstate/"/ directory with the " as directories.
Jul 26 22:17:33 <RP__> sgw: interesting
Jul 26 22:18:36 <sgw> RP__: I will keep digging
Jul 26 22:22:22 <fray> nitink, I need to know what is in your /disk0/pokybuild/build-multilib-x32/tmp/deploy/rpm/  directory.. an ls will be enough
Jul 26 22:30:31 <nitink> fray: http://pastebin.com/QyFswyqH
Jul 26 22:34:22 <fray> line 69 of package_rpm.bbclass
Jul 26 22:34:30 <fray> cat /dev/null > ${RPMCONF_HOST_BASE}.conf
Jul 26 22:34:32 <fray> make that
Jul 26 22:34:40 <fray> cat /dev/null > ${RPMCONF_HOST_BASE}-${archvar}.conf
Jul 26 22:35:29 <fray> thats all I can think of..  I have to run for a bit... sorry
Jul 26 22:38:03 <RP__> jefferai: Could you add a Signed-off-by line to your patch please? :)
Jul 26 22:41:35 <jefferai> RP__: if you tell me how
Jul 26 22:41:59 * jefferai isn't really sure of the purpose of the author adding a signed-off-by line with themselves
Jul 26 22:44:24 <nitink> fray: giving it a try...
Jul 26 22:44:26 <RP__> jefferai: http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#resources-contributions
Jul 26 22:44:52 <RP__> jefferai: that tells you what you're certifying with it :)
Jul 26 22:45:59 <jefferai> RP__: ah
Jul 26 22:47:06 <nitink> fray: http://pastebin.com/Z9yLxzh8
Jul 26 22:47:38 <nitink> and I see tinylogin, busybox packages are built as part of core-image-minimal
Jul 26 22:48:33 <RP__> nitink: It sounds very like the wrong package architectures are being used
Jul 26 22:48:59 <RP__> nitink: what is PACKAGE_ARCHS and what directory are the packages themselves in?
Jul 26 22:49:39 <nitink> RP__: build-multilib-x32]$ ls tmp/work
Jul 26 22:49:39 <nitink> all-poky-linux         atom_pc-poky-linux-gnux32    x86_64-linux
Jul 26 22:49:39 <nitink> all-poky-linux-gnux32  core2-x32-poky-linux-gnux32
Jul 26 22:50:22 <RP__> nitink: bitbake -e | grep PACKAGE_ARCHS
Jul 26 22:51:45 <nitink> RP__: PACKAGE_ARCHS="all any noarch x86_64-x32 core2-x32 atom_pc"
Jul 26 22:52:19 <RP__> nitink: and what does ls tmp/deploy/rpm/ show?
Jul 26 22:53:26 <nitink> RP__: http://pastebin.com/1YtC9fWW
Jul 26 22:55:37 <RP__> nitink: Notice how your logs never say Generating solve db for /disk0/pokybuild/build-multilib-x32/tmp/deploy/rpm/core2-x32
Jul 26 22:56:08 <RP__> nitink: its in PACKAGE_ARCHS and the directory is there and presumably contains packages so the question is why isn't the rpm code looking there
Jul 26 22:57:01 <nitink> does core-image-minimal-1.0-r0 see different PACKAGE_ARCHS ?
Jul 26 22:57:20 <RP__> nitink: shouldn't...
Jul 26 22:57:41 <RP__> nitink: you can try bitbake core-image-minimal -e | grep PACKAGE_ARCHS
Jul 26 22:58:04 <nitink> it is seeing: PACKAGE_ARCHS="all any noarch x86_64 atom_pc"
Jul 26 22:58:24 <nitink> so I think this issue will not happen for qemux86-64 machine
Jul 26 23:04:03 <RP__> nitink: I'm slightly concerned bitbake -e and bitbake image -e are not showing the same thing. I guess I'm misunderstanding your config :/
Jul 26 23:04:18 <RP__> nitink: but it sounds like a likely source of the problems
Jul 26 23:04:38 <nitink> RP__: I think I found the source of the problem
Jul 26 23:05:58 <nitink> this is wrong for core-image-minimal PACKAGE_EXTRA_ARCHS_tune-core2-x32="x86_64"
Jul 26 23:06:09 <nitink> I don't understand why is it different than other recipes
Jul 26 23:06:28 <RP__> nitink: it certainly looks wrong...
Jul 26 23:07:36 <nitink> RP__: it is set well in the config: ./include/tune-core2.inc:PACKAGE_EXTRA_ARCHS_tune-core2-x32 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64-x32} core2-x32"
Jul 26 23:11:01 <ant_home> RP__: I haven't a clear idea about the PR value for new recipes from oe-dev. Needing reset to r0?
Jul 26 23:12:10 <ant_home> or oe-dev's PR +1 ?
Jul 26 23:14:08 <RP__> ant_home: PR +1 sounds reasonable
Jul 26 23:17:22 <dvhart> jefferai, did you see the beagleboard xm revC suggestion from gary on the list? looks promising
Jul 26 23:20:47 <jefferai> about uboot?
Jul 26 23:21:53 <nitink> RP__: still don't have a clue, why only for core-image-minimal is not seeing PACKAGE_EXTRA_ARCHS_tune-core2-x32 correctly
Jul 26 23:22:46 <nitink> RP__: it is seeing this instead: ./conf/bitbake.conf: PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} ??= "${TARGET_ARCH}"
Jul 26 23:23:34 <nitink> so the conf/machine/include/tune-core2.inc file is not parsed for core-image-minimal recipe ???
Jul 26 23:26:02 <jefferai> dvhart: if you mean the thing about u-boot, I'll try it out after bb-matrix is done
Jul 26 23:26:11 <jefferai> so next week?  :-)
Jul 26 23:26:12 <dvhart> jefferai, :-)
Jul 26 23:26:16 <dvhart> right
Jul 26 23:26:51 <jefferai> the first build took an hour
Jul 26 23:26:54 <jefferai> 04/04
Jul 26 23:27:16 <dvhart> and what range are you using?
Jul 26 23:27:20 <dvhart> not going past 10?
Jul 26 23:27:20 <jefferai> which means 6 days?
Jul 26 23:27:24 <jefferai> um, the default
Jul 26 23:27:31 <jefferai> but that's a good point
Jul 26 23:27:46 <jefferai> I didn't really look, since I figured you'd want complete statistics
Jul 26 23:27:58 <dvhart> going past 10 is probably a waste of cpu cycles
Jul 26 23:28:02 <dvhart> and disk life
Jul 26 23:28:04 <jefferai> yes, probably
Jul 26 23:28:04 <dvhart> ;)
Jul 26 23:28:09 <jefferai> pfft, disks are cheap :-)
Jul 26 23:28:14 <jefferai> well
Jul 26 23:28:19 <jefferai> then I'll restart with 10 as a max
Jul 26 23:28:32 <dvhart> save you a couple days in the long run
Jul 26 23:28:37 <jefferai> which will bring it down to 1.5 days
Jul 26 23:28:45 <jefferai> instead of 6
Jul 26 23:28:54 <dvhart> much more reasonable
Jul 26 23:29:30 <ant_home> ever tried without ccache and with all in a big tmpfs?
Jul 26 23:29:43 <dvhart> ant_home, we have
Jul 26 23:29:44 <jefferai> ant_home: apparently someone tried with tmpfs and it didn't help much
Jul 26 23:30:07 <ant_home> I had less improvements than expected on 'normal' hw
Jul 26 23:30:09 <dvhart> tmpfs was faster than SSD, SSD was faster than RAID0 spinning rust, which was faster than a single spindle
Jul 26 23:30:35 <jefferai> but IIRC tmpfs > SSD > RAID0 >>>> single spindle
Jul 26 23:30:38 <dvhart> but in my experience some 60% of the gain can be had with RAID0 with 2 spinning disks
Jul 26 23:30:43 <ant_home> ccache was trashing the hdd, I had to nuke that
Jul 26 23:30:44 <dvhart> right
Jul 26 23:30:56 <jefferai> hm, 40% ain't nothing
Jul 26 23:30:59 <jefferai> :-)
Jul 26 23:31:17 <dvhart> so the price-performance knee of the curve is at RAID0
Jul 26 23:31:32 <dvhart> after that you got a lot less performance per dollar spent
Jul 26 23:31:34 <jefferai> RAM is cheap :-)
Jul 26 23:31:45 <ant_home> dvhart: don't ask me about raid0...lost last Deathstars years ago...
Jul 26 23:32:11 <dvhart> raid0 for build disks should be fine - just not for irrecoverable data
Jul 26 23:32:18 <dvhart> my OS is on an SSD, /build is on RAID0
Jul 26 23:32:19 <nitink> RP__, fray: the problem seems to be in image.bbclass
Jul 26 23:32:30 <dvhart> but year - nobody should run deathstars
Jul 26 23:32:40 <nitink> RP, fray: it has PACKAGE_ARCH=$MACHINE_ARCH
Jul 26 23:32:40 <jefferai> deathstars?
Jul 26 23:32:47 <dvhart> Deskstart
Jul 26 23:32:48 <RP__> nitink: Are you actually including the tune file in the machine you're using?
Jul 26 23:32:49 <dvhart> gah
Jul 26 23:32:51 <dvhart> Deskstar
Jul 26 23:32:53 <jefferai> ah
Jul 26 23:33:01 <jefferai> eh, every manufacturer has had its issues
Jul 26 23:33:03 <dvhart> they earned their nick name though
Jul 26 23:33:13 <jefferai> for a long time they were fantastic
Jul 26 23:33:14 <RP__> nitink: Note PACKAGE_ARCHS != PACKAGE_ARCH
Jul 26 23:33:19 <nitink> RP__: I am not doing anything like that
Jul 26 23:33:22 <ant_home> dvhart: wife has OSX on its hdd, I have various linux on my hdd and a Win just for fun. Last summer a furious compile trashed the multiboot disk. Wifey was not happy :/
Jul 26 23:33:23 <dvhart> these guys were an outlier in terms of failure rates for a while :-)
Jul 26 23:33:33 <jefferai> Seagate has had its troubles too
Jul 26 23:33:47 <jefferai> even though before and after those issues they've been super solid
Jul 26 23:34:00 <dvhart> jefferai, yeah, you need to read up on each model
Jul 26 23:34:05 <jefferai> used to be every western digital drive I ever saw died, but these days people love them...
Jul 26 23:34:08 <dvhart> sometimes even manufacturing batch numbers :/
Jul 26 23:34:18 <jefferai> yep...fortunately newegg has a few thousand reviews of every model, usually
Jul 26 23:34:32 <nitink> RP__:: correct, but core-image-minimal was seeing atom-pc as PACKAGE_ARCH and otherwise it was core2-x32
Jul 26 23:34:47 <nitink> RP__: changing it does not help anyway :-/
Jul 26 23:35:03 <dvhart> ant_home, right - which is why I keep my builds on completely seprate dedicated drives :)
Jul 26 23:35:25 <dvhart> that and I have an uncanny habit of destroying hardware
Jul 26 23:35:27 <RP__> nitink: I need to sleep I'm afraid
Jul 26 23:35:35 <RP__> 'night all
Jul 26 23:35:39 <nitink> RP__: ok , good night
Jul 26 23:35:40 <dvhart> RP__, I thought you had transcended and no longer slept
Jul 26 23:35:53 <dvhart> RP__, ;-) night
Jul 26 23:36:05 <ant_home> dvhart: the disks are twin, even same batch iirc. Did not dare to repeat raid0
Jul 26 23:36:37 <dvhart> ant_home, that's is actually the worst way to config RAID0 :-)
Jul 26 23:36:45 <RP__> dvhart: heh ;-)
Jul 26 23:36:49 <dvhart> disks from the same lot tend to have similar failure rates
Jul 26 23:36:57 <dvhart> and therefor are more likely to fail together
Jul 26 23:37:09 <dvhart> but with RAID0, it doesn't actually matter - one disk fails and your done
Jul 26 23:37:27 <sgw> found the pstaging_fetch issue, looks like a leaky environment variable issue
Jul 26 23:37:35 <dvhart> which is why, again, I only recommend it for reproducible data - like build partitions
Jul 26 23:37:36 <ant_home> he, the two barracudas are sleeping
Jul 26 23:39:46 <jefferai> ant_home: yeah, if possible order disks from different vendors at different times
Jul 26 23:39:54 <jefferai> batches tend to fail in, well, batches
Jul 26 23:40:14 <jefferai> also there is some research that showed that the more time it's been since your last failure, the longer you're likely to go until your next failure
Jul 26 23:40:24 <jefferai> because hard drives tend to fail early
Jul 26 23:40:39 <jefferai> and batches tend to fail with the same problems at around the same time
Jul 26 23:40:41 <ant_home> see, I've been SCSI guy for ten years w/out hassle
Jul 26 23:40:52 <ant_home> issues started with cheap disks :)
Jul 26 23:40:54 <jefferai> which is why you should, if possible, have two hot-spares instead of one in an enterprise system :-)
Jul 26 23:41:16 * dvhart has seen plenty of SCSI drive die
Jul 26 23:41:21 <jefferai> yeah, me too
Jul 26 23:41:24 <dvhart> in enterprise class systems
Jul 26 23:41:28 <ant_home> not soo early
Jul 26 23:41:39 * sgw has killed plenty of SCSI drives!
Jul 26 23:41:53 <jefferai> dvhart: btw, second generation sand force SSDs are great
Jul 26 23:42:12 <jefferai> http://www.tomshardware.com/reviews/vertex-3-sandforce-ssd,2869-3.html has a good overview
Jul 26 23:42:15 <dvhart> but, IMO, it isn't technically RAID if you use enterprise drives (the I part, in particular) ;-)
Jul 26 23:42:22 <jefferai> hah
Jul 26 23:42:29 <jefferai> I wish you could tell storage vendors that
Jul 26 23:42:44 <dvhart> hehe
Jul 26 23:42:46 <jefferai> the "enterprise" version of a $100 drive shouldn't cost me $2k
Jul 26 23:42:48 <jefferai> yet it does
Jul 26 23:42:55 <ant_home> yep, raid>1 of expensive drives and you sleep
Jul 26 23:43:34 <jefferai> barring a controller failure, 2nd gen sand force drives claim that they will basically never have an error
Jul 26 23:44:38 <ant_home> the compression story is worth some discussion imho
Jul 26 23:45:08 <jefferai> of course, this isn't quite true :-)
Jul 26 23:45:33 <jefferai> but they keep 12.4% or so of the drive away from your grubby hands so that they will always have blocks to use to replace flash cells that are worn
Jul 26 23:45:48 <ant_home> well, is almost like jffs2 on nand
Jul 26 23:45:50 <jefferai> and also to use to keep things snappy without TRIM, which is nice
Jul 26 23:46:40 <ant_home> yes, I'll wait for no-trim SSD's
Jul 26 23:47:38 <jefferai> http://db.usenix.org/events/fast07/tech/schroeder/schroeder_html/index.html and http://research.google.com/archive/disk_failures.pdf
Jul 26 23:47:46 <jefferai> ant_home: they're here, called sandforce 2 :-)
Jul 26 23:48:46 <jefferai> OCZ Vertex3 240GB is a good one...
Jul 26 23:49:17 <jefferai> nini all
Jul 27 00:24:03 <ant_home> good night
Jul 27 00:33:39 <nitink> fray: got the image building now
**** ENDING LOGGING AT Wed Jul 27 02:59:57 2011