[02:46] <eggonlea> orga: hi, I tried to generate lucid rootfs with rootstock on Karmic PC. It failed on the second stage.
[02:47] <eggonlea> orga: please see http://paste.ubuntu.com/359871/ for the log
[02:47] <eggonlea> orga: I'll try lucid version of rootstock instead.
[02:50] <eggonlea> orga: oh, it's already 0.1.3-0ubuntu1. would take a look at that in LP.
[03:05] <cooloney> eggonlea: yeah, ogra might be online this afternoon, heh
[03:12] <eggonlea> cooloney: thanks
[03:12] <eggonlea> orga: rootstock in LP seems fine!
[03:20] <cooloney> eggonlea: excellent
[08:47] <eggonlea> orga: minimal rootfs could be rootstock'ed. But met segmentation fault error with ubuntu-desktop seed.
[08:49] <eggonlea> orga: log pasted at http://paste.ubuntu.com/359976/
[08:58] <ogra> eggonlea, hmm, that looks bad, could be an issue with the versatile kernel we use (its quite old) i plan to work on rootstock from tomorrow on and will switch it to the archive kernel then
[08:59] <eggonlea> orga: got it. do you have a workable kernel at hand?
[08:59] <ogra> did you try if it happens too if you ise a -minimal image and run apt-get install ubuntu-desktop on it later (either in VM or real HW)
[08:59] <ogra> i dont know if the one in the archive works
[09:00] <eggonlea> same
[09:00] <eggonlea> I tried that.
[09:00] <ogra> http://ports.ubuntu.com/pool/main/l/linux/linux-image-2.6.32-11-versatile_2.6.32-11.15_armel.deb
[09:01] <eggonlea> let me try this.
[09:01] <ogra> you tried what ? :)
[09:01] <ogra> on real HW or in VM ?
[09:02] <ogra> if it happens in VM too then its a pointer to an issue with the old versatile kernel
[09:02] <eggonlea> I tried 1) rootstock -s ubuntu-desktop in VM (fail); and 2) rootstock -s minimal in VM (ok) and then apt-get install ubuntu-desktop on HW (fail).
[09:03] <ogra> hmm, on HW points to a bigger issue thats rather not rootstock related
[09:04] <eggonlea> I will try 1) rootstock -s ubuntu-desktop with your new versatile .32 kernel; and 2) apt-get install ubuntu-desktop in VM if 1) fails.
[09:05] <eggonlea> but I don't think there is any actual difference between 1 and 2, right?
[09:07] <ogra> shouldnt be
[09:08] <ogra> but if it fails on real HW thats very likely not related to rootstock
[09:08] <ogra> but either apt or an issue with the HW
[09:08] <ogra> (or kernel you use on the HW)
[10:46] <ogra> asac, any idea what we do with/without plymouth ? doesnt look like we can build it on arm in a functional way but having any kind of splash would be nice
[10:55] <asac> ogra: the splash solution from karmic doesnt work anymore?
[10:55] <asac> isnt that xsplash?
[10:55] <ogra> usplash
[10:55] <ogra> xsplash is for the time when X is up
[10:55] <asac> right
[10:55] <asac> ok
[10:55] <ogra> plymouth and usplash are for the parts before that
[10:55] <asac> did we use usplash at all?
[10:55] <ogra> yes
[10:55] <ogra> in karmic (it was broken on arm in jaunty)
[10:55] <asac> what speaks against keeping that?
[10:55] <ogra> nobody maintains it
[10:56] <ogra> and i guess the team will demote it if we dont want to keep it
[10:56] <ogra> but i see no solition for plymouth atm so we'd stay without any early splash
[10:57] <ogra> though usplash is said to slow down the new bootprocess (we'd need to talk with Keybuk here i think)
[10:58] <asac> who is leading the plymouth effort?
[10:58] <asac> is that foundations too?
[10:58] <ogra> Keybuk ? not sure
[10:58] <ogra> i think mvo worked on it as well
[10:58] <ogra> likely foundations, yes
[10:58] <asac> ok so its not desktop.
[11:02] <NCommander> asac, ogra, I got a patch for likewise-open, just waiting on test compilation, but hopefully I'll need a sponsor soonish :-)
[11:03] <ogra> NCommander, good work !
[11:03] <NCommander> ogra, it tries to determine how many processors there are from grepping /proc/cpuinfo. I just hardcoded it to 1
[11:03] <NCommander> should make it build on all architectures
[11:04] <ogra> asac, Bug #510585 ... not sure what to set for status etc ... i guess its rather wishlist
[11:04] <ubot4> Launchpad bug 510585 in uboot-imx "uboot-imx should have hush shell support enabled by default" [Undecided,New] https://launchpad.net/bugs/510585
[11:05] <ogra> NCommander, well, might make sense on x86 to use more than one CPU so a patch that only hardcodes it on !x86 would probably be better
[11:06] <NCommander> ogra, that means making the logic a bit uglier since then I need to grep uname but I'll look at it
[11:06] <ogra> cant you use DEB_HOST_ARCH or something ?
[11:13] <asac> NCommander: for parallel building?
[11:13] <NCommander> asac, ogra, its not in the debian/rules file; its from the actual packages build system
[11:15] <ogra> well, then uname might probably be better
[11:16] <asac> NCommander: whats the purpose?
[11:17] <NCommander> asac, <NCommander> ogra, it tries to determine how many processors there are from grepping /proc/cpuinfo. I just hardcoded it to 1
[11:17]  * NCommander kicks jocote
[11:17] <asac> NCommander: that doesnt explain the purpose for me ;)
[11:17] <asac> anyway
[11:18] <asac> give me patch
[11:18] <ogra> asac, speedier builds on SMP machines :)
[11:18]  * NCommander doesn't get why the version number is likewise-open_5.4.0.39949-3 if there's no Debian version :-/
[11:18] <ogra> ask the server team
[11:18] <NCommander> asac, I need to upload to a PPA. jocote has an unclear chroot which I think triggered an FTBFS
[12:04] <Noisi> Hallo Leute :-) ich suche ein Ubuntu arm Toolchain-Howto für 2.4.18-rmk3 armv4l chip arm720t (Owasys-Gerät). Kann mir da jemand weiterhelfen? Ich muss dropbear und appweb portieren und habe arm-linux-gcc als tar bekommen. Einfachen c-code kann ich compilieren. Zur Zeit versuche ich mich an appweb. Würde mich über Tips freuen.
[12:12] <ogra> Noisi, hey, this is an english speaking channel :)
[12:15] <Noisi> ok sorry :-)
[13:09] <ogra> grmpf ... adding the script support to the uboot defaults is harder than i though
[13:09] <ogra> t
[13:14] <ogra> hmm, a "break" command would be so handy
[13:14] <ogra> hush shell is so lame
[14:15] <ogra> GRRR
[14:20]  * NCommander kicks likewise
[14:20] <NCommander> Freaking configure checks
[15:16] <asac> dmart: plars: lucid chromoium with full thumb and neon is here: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3
[15:16] <asac> chromium-browser - 4.0.303.0~svn20100120r36627-0ubuntu1~ucd1+asac2
[15:17] <asac> uploading firefox 3.6 all-static now (had to get quota bumped first)
[15:17] <plars> asac: cool :)
[15:18] <asac> let me know if it starts on imx51
[15:18] <asac> thumb2 actually
[15:20] <asac> i sawved the lucid builds without NEON/thumb2 here: http://people.canonical.com/~asac/tmp/chromium-armel-lucid/
[15:20] <ogra> asac, is that supposed to work on non neon HW ?
[15:21] <asac> ogra: no.
[15:21] <ogra> i.e. b2.5
[15:21] <asac> ogra: thats a benchmark thing
[15:21] <ogra> ah, k
[15:21] <asac> ogra: b2.5 most likely works
[15:21] <ogra> well, i'll try if i ever get my board booted again :P
[15:21] <asac> dmart did some tests and the CPU hangs are not really happen frequently
[15:22] <asac> i just wanted to use the chance that we have a NEON kernel to check if there is a difference
[15:22]  * ogra only saw the uboot prompt since getting up today ... 
[15:22] <asac> hehe
[15:22] <asac> i know that feeling
[15:22] <asac> endless hangs ;)
[15:22] <ogra> but i think i got it now
[15:22] <asac> are the best :-P
[15:22] <ogra> no, no hangs
[15:22] <asac> yes, thats good ;)
[15:22] <ogra> just figuring out a logic that doesnt make hush hsell laugh at me
[15:23] <asac> hehe
[15:23] <ogra> but i think i got it now ...
[15:23] <ogra> if mmc is detected it will try to load boot.scr ... if boot.scr isnt there it will try to load reamdisk ... if ramdisk isnt there it will try to load kernel ...
[15:23] <asac> can we move debian-cd to uboot wihtout hushshell as a first step?
[15:23] <ogra> then it will boot
[15:24] <ogra> if mmc isnt there it will automatically exec the netboot commands
[15:24] <asac> just thinking it would be a good thing for a peer to get started on that spec by writing good hushshell script
[15:24] <ogra> i'll also try to fall back on netboot if kernel isnt found
[15:24] <asac> and you could work on better stuff ;)
[15:24] <ogra> well, i'm done ... just need to test it
[15:24] <asac> ok
[15:24]  * ogra waits for a build to finish
[15:25] <asac> when can this go into debian-cd?
[15:25] <ogra> well, debian-cd will mainly get the uboot-image-script ported
[15:25] <ogra> i just need to add boot.scr generation once uboot works
[15:26] <ogra> but thats mainly four to five lines ...
[15:27] <asac> ogra: how about producing the universal boot.scr we aim at in the uboot-imx package?
[15:27] <ogra> the hard part was to patch uboot to actuaqlly do something with boot.scr in an intelligent way
[15:27] <asac> not for now, but in long run i dont see why we need to do that in debian-cd
[15:27] <ogra> that wont work
[15:27] <asac> why?
[15:28] <ogra> boot.scr will have the cmdline
[15:28] <asac> ok
[15:28] <ogra> for live images thats hardcoded, for installs it needs the UUID
[15:28] <ogra> we need to generate/change boot.scr from flash-kernel or d-i
[15:29] <ogra> but that code is already there thanks to NCommander and lool, thats something we only need to copy
[15:30] <NCommander> ogra, you can probably just use the same extact code in flash-kernel(-installer), and minor modifications to the code in d-cd
[15:30] <ogra> NCommander, yes for flash-kernel, no for d-cd
[15:31] <ogra> our uboot is way cleverer now than the dove one ... we need a lot less code in d-cd
[15:32] <ogra> i added the iteration over filesystems and partitions directly into uboot, no need for complex boot.scr stuff anymore
[15:32] <NCommander> ogra, we should port that code to dove
[15:32] <ogra> its just changes to the default env
[15:33] <ogra> on dove it would likely be more complex though, since you have ide and usb too
[15:33] <NCommander> ogra, thats probably the sanest way to do so, then you can check the variables and iterate as necessary
[15:33] <ogra> babbage only has mmc
[15:33] <ogra> but thats only one more loop
[15:33] <NCommander> ogra, right
[15:33] <ogra> and some inits
[15:37] <ogra> perfect !
[15:38] <ogra> no boot.scr gets me to busybox (because we dont have a default rootdevice set atm)
[15:38]  * ogra deletes uinitrd
[15:39] <ogra> and no initrd just boots the kernel :)
[15:41] <ogra> so users only have to set cmdline at the prompt and run "boot" if they want to tinker manually :)
[15:41] <ogra> the rest happens automatically
[15:42] <ogra> now lets try a boot.scr
[15:44] <ogra> GOSH !
[15:44] <ogra> it WORKS !
[15:44] <ogra> i'm so awesome !!!
[15:44]  * ogra dances
[15:49] <asac> ogra: you are awesome indeed
[15:49] <asac> now get this plumbered into our images ;)
[15:49] <asac> hehe
[15:49] <asac> ok ttyl
[15:50] <asac> have to commute to hamburg
[15:50] <asac> bbl
[15:55]  * ogra will upload in a minute
[15:58] <NCommander> ogra, very nice. I think I need to merge that back into Dove :-)
[15:59] <ogra> NCommander, its not much different from what you do in your boot.scr
[15:59] <ogra> i just use it in the defaults here
[16:01] <ogra> NCommander, http://paste.ubuntu.com/360126/
[16:02] <ogra> i'll modify it a little bit to actually have bootargs_mmc
[16:03] <ogra> (pointing to /dev/mmcblk0p2 by default)
[16:05] <NCommander> ogra, I thought you got the partition numbers set in the environment via the mmcinit command (and assiocated friends)
[16:05] <ogra> from where should i get them ?
[16:05] <ogra> i dont actually know on which partition the kernel or boot.scr lives
[16:06] <ogra> the prob on imx is that we cant save anything
[16:06] <ogra> so the defaults need to be as dynamically as possible
[16:07] <ogra> saved settings need to live in boot.scr
[17:25] <plars> asac: chromium from that archive running fine for me on babbage3
[17:25] <plars> asac: about to try ff3.6
[17:26] <ogra> fine and fast or just fine ?
[17:26] <ogra> :)
[17:27] <plars> ogra: I don't have a good way of benchmarking it, but seem decently quick for the platform (expected somewhat due to lighter weight browser though)
[17:27] <plars> ogra: he seemed interested in whether it comes up at all though
[17:27] <ogra> well, i think even the non neon/thumb2 version feels a lot faster than karmics FF
[17:32] <dmart> asac, ping
[17:32] <ogra> dmart, he is on a train atm
[17:33] <dmart> Thought he might have gone...
[17:33] <dmart> Do you know whether the static build of ff3.6 was uploaded yet?
[17:33] <ogra> no, sadly not
[17:33] <ogra> (knowing)
[17:34] <dmart> I have no babbage3 to test the chromium rebuild yet, unfortunately.
[17:35] <ogra> yeah, mine hasnt grown up either yet ... it was still a 2.5 last i checked :)
[17:37] <dmart> I will try the NEON-ised version later anyway, but it might not work...
[17:37] <ogra> he said it might
[17:37] <plars> https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3 has a FF3.6 build that he made available on the 12th, I think he's planning on putting another one there
 asac, is that supposed to work on non neon HW ?
 ogra: no.
 i.e. b2.5
 ogra: b2.5 most likely works
[17:39] <dmart> b2.5 may not work (but I don't have one to test on)
[17:40] <ogra> yes, thats what i thought too
[17:40] <plars> ogra: just rough guessing.. launching both the 3.6 that's there and the chromium build and pointing at www.ubuntu.com (after a few cache warm-ups of course) the chromium seems to get there in about 6 seconds, FF takes about 10
[17:41] <ogra> yeah
[17:48] <dmart> That's the same kind of result I was seeing
[18:26] <asac> dmart: the static build was uploaded right before i left
[18:26] <asac> had quota issues before
[18:27] <asac> so it got rejected yesterday
[18:27] <asac> let me check
[18:27] <asac> dmart: does the NEON/thumb2 chromium build work well?
[18:28] <asac> dmart: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+build/1459774 ... ffox still spinning
[18:28] <asac> i think will take another hour or so
[18:28] <dmart> I was having board problems and wasn't able to test the new Chromium build yet... also, I have no babbage 3 so it might not work, but I will try.
[18:28] <dmart> This will probably be tomorrow now...
[18:31] <dmart> Got to disappear now, sorry
[18:36] <plars> asac: chromium build is working pretty well for me so far
[18:45] <asac> nice
[18:45] <asac> plars: is that on TO3
[18:45] <asac> ?
[18:46] <plars> asac: yes
[18:46] <asac> have you checked if it hangs up a TO2 or 2.5?
[18:50] <plars> asac: no, but I can pull out the 2.5 and try it if you'd like
[18:52] <asac> dmart: still there?
[18:52] <asac> dmart: one thing mike mentioned up front is that we should disable disk_cache in ffox 3.6 for benching
[18:53] <asac> dmart: so in about:config set browser.cache.disk.enable to false
[18:53] <asac> we probably should have that by default for arm
[18:54] <asac> i will shoot you a mail once ffox 3.6 has finished, so you can check that
[18:54] <asac> plars: would be interesting to see if chromium triggers the problematic NEON stuff
[18:58] <plars> asac: will try it in a bit
[19:09] <plars> asac: nothing extensive tried, but just opening, visiting a few sites, that chromium build is also stable for me with TO3
[19:10] <plars> asac: err. 2.5 too :)
[20:07] <asac> plars: ok, maybe use it a bit longer. good news.
[20:07] <asac> thanks
[20:07]  * asac hopes that upstream didnt decouple neon from armv7=1