**** BEGIN LOGGING AT Fri Dec 07 02:59:59 2012
Dec 07 10:19:23 <ant_work> bluelightning: hello
Dec 07 10:24:45 <ant_work> mumbling abot the strange git issue, I see that the recipes have indeed different SRC_URI
Dec 07 10:25:16 <ant_work> SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git
Dec 07 10:25:32 <ant_work> SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.2;protocol=git;..
Dec 07 10:26:59 <ant_work> the 3.4 recipe is like that since first commit
Dec 07 10:27:45 <ant_work> probably it was the first time I've pulled an update for linux-yocto_3.4  w/out rebuilding from scratch
Dec 07 10:39:02 <ant_work> bluelightning: he he
Dec 07 10:39:09 <ant_work> http://cgit.openembedded.org/bitbake/commit/?id=bbf1f6fe594c721a296ca09ee7c583d4a205c591
Dec 07 10:39:57 <ant_work> git -1.7.3.4 on my Gentoo
Dec 07 10:42:59 <bluelightning> but thatcommit went in ages ago...
Dec 07 10:43:04 <bluelightning> (hi)
Dec 07 10:43:58 <ant_work> sounds too similar to be casual
Dec 07 10:49:21 <bluelightning> the question is why is it .git for the 3.4 recipe?
Dec 07 10:50:25 <ant_work> yes, fair question ;)
Dec 07 10:52:23 <ant_work> the bug talks about issues on cloning but after cleanall it re-downloaded and fetched correctly
Dec 07 10:53:35 <ant_work> so I'd say I had what appears a 'missing merge'
Dec 07 10:57:26 <bluelightning> any ideas how that could happen?
Dec 07 10:58:34 <ant_work> well, something similar happens with kexecboot.git if you don't bump PR and the latest commit has a git hash wich looks lower than th eformer value
Dec 07 10:58:53 <ant_work> looking again  http://paste.debian.net/214810/
Dec 07 10:59:29 <ant_work> linux-yocto/3.4.20+git4+6737e890fff2a423fbb022ab1f7f82ef187fd8b1_2+b13bef6377719a488293af196236cc290566fad3-r4.3
Dec 07 11:00:05 <ant_work> how is incremented the  " +gitX+"
Dec 07 11:00:07 <ant_work> ?
Dec 07 11:01:01 <bluelightning> that's handled by the persistdb - if the hash is different from the last one then the number is incremented
Dec 07 11:01:26 <bluelightning> although the PR server is going to be handling that very soon
Dec 07 11:04:23 <ant_work> yes, neverthless here should be straightforward
Dec 07 11:04:30 <ant_work> -LINUX_VERSION ?= "3.4.18"
Dec 07 11:04:30 <ant_work> +LINUX_VERSION ?= "3.4.20"
Dec 07 11:04:35 <ant_work> PR = "${INC_PR}.3"
Dec 07 11:04:35 <ant_work> PV = "${LINUX_VERSION}+git${SRCPV}"
Dec 07 11:10:42 <ant_work> bluelightning: I was about asking you why the dir in /downloads is called /git2
Dec 07 11:10:51 <ant_work> then I found http://cgit.openembedded.org/bitbake/commit/?id=1a0cdc65812f1f12bf4bbea6540a3aaf0f81b4f7
Dec 07 11:11:12 <bluelightning> to keep it separate when fetch2 was introduced
Dec 07 11:11:53 <ant_work> ok, I have only that one (and a single /svn with opkg fwiw, this is another theme)
Dec 07 14:42:53 <nareshbhat> ant_work: ping
Dec 07 14:46:27 <nareshbhat> you are right, looks like I am doing something wrong while passing the --command-line options.  I will try out next week and let you know if I have any questions
Dec 07 14:47:11 <ant_work> hi there
Dec 07 14:48:32 <ant_work> we hope to release a new version with bugfixes and improvements, tomorrow starting around 18-20 UTC we'll be merging patches
Dec 07 14:49:01 <ant_work> try to be online if you have any suggestion
Dec 07 14:52:00 <nareshbhat> ant_work: sure
Dec 07 14:53:02 <nareshbhat> I have V2P-CA15_A7 Cortex A15 target and will test kexecboot next week
Dec 07 14:53:44 <ant_work> have you tested kexec on it?
Dec 07 14:55:38 <ant_work> normal kexec I mean, eglibc or uclibc. We use kexec-klibc here but I'd prefer not to add another variable
Dec 07 14:56:58 <nareshbhat> yep, but as I e-mail I got stuck at "Uncompressing Linux..."
Dec 07 14:57:25 <nareshbhat> probably I need to pass as command line mmc_args=setenv bootargs "console=tty0 console=ttyAMA0,38400n8 root=/dev/mmcblk0p2 rootwait ro mmci.fmax=6000000"; console=ttyAMA0,38400n8
Dec 07 14:57:52 <ant_work> Tequila: pls send us pending patches, we'll try to merge all the forks in github/kexecboot
Dec 07 14:58:30 <ant_work> nareshbhat: this seems uboot stuff
Dec 07 14:59:59 <nareshbhat> yep, I mean I can snip some of the arguments from the above one
Dec 07 15:00:39 <ant_work> afais you just need in boot.cfg   APPEND=console=tty0 console=ttyAMA0,38400n8 mmci.fmax=6000000
Dec 07 15:00:56 <ant_work> the rest is passed by kexecboot itself
Dec 07 15:01:13 <ant_work> well, not   ro
Dec 07 15:01:24 <ant_work> are you sure you need ro?
Dec 07 15:01:44 <nareshbhat> no I will change it to rw
Dec 07 15:02:02 <ant_work> you may add  debug as well
Dec 07 15:03:03 <nareshbhat> I will go through http://kexecboot.org/documentation and make the changes
Dec 07 15:04:48 <ant_work> right
Dec 07 15:04:50 <nareshbhat> One thing I still did't understand how different is kexecboot from kexec ?
Dec 07 15:05:05 <Tequila> ant_work, I don't have any more patch than the one proposed a year ago... I didn't have time to take care more
Dec 07 15:05:07 <ant_work> it's a wrapper around kexec
Dec 07 15:05:17 <ant_work> ok, thanks
Dec 07 15:05:28 <nareshbhat> is there any link I can read/go through ?
Dec 07 15:05:51 <ant_work> well, the docs and the code :)
Dec 07 15:07:26 <ant_work> basically kexecboot adds automatically some options like root= rootfs= rootwait
Dec 07 15:07:44 <ant_work> permitting you to select th eboot device from a menu
Dec 07 15:08:38 <nareshbhat> Ah like GRUB menu options ?
Dec 07 15:08:53 <ant_work> yes, see screenshots
Dec 07 15:10:06 <nareshbhat> ype, that's cool I got it
Dec 07 15:10:11 <ant_work> from userspace you can do the same using kexec but the real use is as a bootloader
Dec 07 15:10:26 <ant_work> thus we embed kexec + kexecboot in the initramfs
Dec 07 15:10:53 <ant_work> (there is any shell, just kexec as init)
Dec 07 15:11:08 <ant_work> err  (there is any shell, just kexecboot as init)
Dec 07 15:11:52 <nareshbhat> that's great I understand :)
Dec 07 15:12:50 <ant_work> for some older devices was a necessity, it seems it can be useful with brand new devices
Dec 07 15:18:34 <nareshbhat> Thanks for the information.  I am leaving for the day..Have a nice day/night.
Dec 07 17:05:24 <ant_work> Jay7: are you around?
Dec 07 17:34:40 <ant_work> bbl
Dec 07 18:54:40 <Jay7> evening
Dec 07 22:10:17 <ant_home> Jay7: still there
Dec 07 22:14:09 <Jay7> here but afk
Dec 07 22:15:58 <ant_home> np, ping if you're around
Dec 07 22:55:58 <Jay7> ant_home: ping
Dec 07 22:56:13 <ant_home> hi
Dec 07 22:57:36 <ant_home> about the hardcoded '0', there are 2
Dec 07 22:58:18 <ant_home> at boot you are on ubi device 0, normally on first volume (0)
Dec 07 22:58:33 <ant_home> on Zaurus we have
Dec 07 22:59:03 <ant_home> not so much space to create volumes :/
Dec 07 22:59:12 <ant_home> many volumes..
Dec 07 23:00:16 <ant_home> I tested doing a single volume per device
Dec 07 23:00:33 <Jay7> I think we may start with hardcoded 0
Dec 07 23:01:08 <ant_home> in theory we should scan all volumes and find the bootable one...
Dec 07 23:01:43 <ant_home> in practice it's always the first (everyone uses same ubinize scrpts)
Dec 07 23:04:58 <Jay7> well.. time to sleep
Dec 07 23:06:01 <ant_home> cu
**** ENDING LOGGING AT Sat Dec 08 02:59:59 2012