[00:33] <asac> hmm. those dvi things on babbage boards. are those compatible with VGA? or do they only support digital?
[01:17] <plars> asac: US Central
[01:17] <asac> yeah
[01:18] <asac> so with commenting out the lines
[01:18] <asac> i end up with a console login ;)
[01:19] <asac> and i cnanot log in because of these timestamp issues i suspect
[01:19] <asac> if you paste that file i can show it you ;)
[01:19] <asac> you need to edit that after "Copying Files ..." (i could change it at about 60%
[01:24]  * asac out
[07:46] <Mendocinox> Good morning to everybody
[07:47] <Mendocinox> any Ubuntu issue on ARM9, Anyka 7802L/266Mhz processor it is possible?
[08:46] <lool> Mendocinox: We don't have any kernel for that, but the jaunty / 9.04 userspace should work
[08:47] <lool> later ones will not
[08:58] <Mendocinox> lool: thanks. the distro names 9.04 userspace?
[08:58] <Mendocinox> Where can I find that?
[09:04] <lool> Mendocinox: I mean Ubuntu jaunty / Ubuntu 9.04 for ARM
[09:04] <lool> You can find it at http://ports.ubuntu.com/ubuntu-ports/
[09:05] <lool> Usually accessed with APT
[09:07] <Mendocinox> thank you very much for your help, lool brother
[12:52] <asac> ogra: so we want to try the new kernel asap i guess? who will get that in?
[12:52] <ogra> cooloney will care for imx51 i think
[12:52] <asac> on the other front i would like to not land uboot for imx51 until we have a booting install image. ... unless we dont find what is going on
[12:52] <asac> does that make sense?
[12:53] <ogra> yes
[12:53] <asac> not saying we shouldnt work on uboot ... just not land it until we have an image that works more or less well to hand out. if we think uboot is safe to land we can just do it once we have it though
[12:53] <asac> ogra: do you know when ncommander will be back?
[12:53] <asac> e.g. do we need to find someone else checking dove?
[12:53] <ogra> yeah, i will do some scripting in my holidays on boring days :)
[12:54]  * ogra checks googlecal
[12:54] <asac> hey ... holidays should be holy
[12:54] <ogra> nah
[12:54] <ogra> i'll be bored enough
[12:55] <asac> ogra: so cooloney is imx51 ... who is dove?
[12:55] <ogra> and i have to read mail at least every second day ... i dont like to return from holidays having thethousands of mails waiting
[12:55] <ogra> ericm i think
[12:55] <asac> ericmiao?
[12:55] <asac> yeah
[12:55] <ogra> but we should probably as in #kernel to be sure
[12:55] <asac> maybe he can help us? those issues dont really feel like they start in user space ;)
[12:56]  * ogra gets between 400 and 600 mails per day ... i wont stay away from my mailbox for more than a week
[12:56] <ogra> i think they are a combo of HW and toolchain
[12:57] <asac> lool: status on my dove board ;)?
[12:57] <ogra> i want to have the switch to uboot for imx51 done in my first workweek after my holiday
[12:57] <asac> yes.
[12:57] <ogra> (i.e. by jan. 8th)
[12:57] <ogra> so we can do some testbuilds before A2 freeze
[12:57] <asac> i will probably do some excersizes with uboot just for fun (not really for image, but to get used to the whole procedure etc.)
[12:58] <asac> yeah.
[12:58] <ogra> yeah
[12:58] <ogra> you should get yourself a beagleboard
[12:58] <lool> asac: No, I worked mostly on python policy in the last two weeks
[12:58] <asac> i would like to get a working install this year though
[12:58] <lool> I'm starting to see the end of it
[12:58] <asac> hmm
[12:58] <ogra> its great for exercises on uboot :)
[12:58] <lool> asac: You say on ubuntu-devel@ that thumb2 improves performance, but it generally does not
[12:58] <ogra> or for any exercises :)
[12:58] <asac> lool: thats what was said ;)
[12:59] <ogra> lool, it should according to arm
[12:59] <lool> asac: You said "While this improves performance"
[12:59] <lool> asac: And it does not
[12:59] <ogra> lool, and given that we have smaller binaries it must actually
[12:59] <asac> i only carry forward the marketing stuff communicates
[12:59] <ogra> probably not noticeabled
[12:59] <lool> It decreases cache pressure
[12:59] <lool> But code will actually run slower
[12:59] <ogra> because of compression ?
[13:00] <lool> No
[13:00] <asac> lool: what counts is that the overall performance of the system is supposed to be better
[13:00] <lool> asac: It's just FYI; I personally thought Thumb2 was faster until yesterday
[13:00] <asac> lool: ok thanks ;)
[13:00] <asac> i am not sure what exactly is faster/slower on the CPU level
[13:00] <asac> just that what we are doing is supposed to improve performance summed up
[13:00] <lool> Did someone look at how big the .kos are on armel?
[13:00] <lool> du -hs `find /lib/modules/2.6.32-7-generic -type d -name crypto` => stupidly small numbers
[13:01] <lool> Biggest is 852K    /lib/modules/2.6.32-7-generic/kernel/crypto
[13:01] <asac> lool: the problem is that all modules are copied
[13:01] <asac> its a bug
[13:01] <lool> (uncompressed -- don't see how that could bloat by MBs on armel)
[13:01] <shenki> lool: do you have some sources for your claims (not that i'm questioning you, I'm interested in this topic)
[13:01] <lool> asac: What's the list of dirs?
[13:01] <asac> or are you not referring to the bug?
[13:01] <asac> lool: all dirs. we tracked it down
[13:01] <asac> https://bugs.edge.launchpad.net/ubuntu/+source/cryptsetup/+bug/495161
[13:01] <ubot4> Launchpad bug 495161 in cryptsetup "initramfs cryptroot hook bloats armel initrd by adding >13M of compressed modules" [Critical,Triaged]
[13:01] <lool> shenki: A Freescale guy who told me it was documented in ARM docs
[13:02] <lool> shenki: Note that performance of some programs might improve if they fit in the L2 cache thanks to T2 instead of having to be read from RAM on e.g. every loop
[13:02] <asac> is thumb2 realized in microcode?
[13:02] <lool> shenki: But in general, without taking care of cache it's actually slower
[13:02] <asac> (/me thought arm doesnt do microcode ... but has no clue to be honest)
[13:02] <lool> asac: I have no idea
[13:02] <shenki> lool: the instruction decode slows it down? or...
[13:02] <lool> shenki: I have no idea
[13:03] <shenki> lool: is this in comparision to 'thumb' (not v2) or ARM?
[13:03] <asac> we hopefully will get some benchmarks at some point ;)
[13:03] <lool> I didn't look at that ARM errata, but that guy was reasonnable and very confident on this
[13:03] <lool> shenki: It's thumb2 versus arm
[13:03] <shenki> asac: im thinking i might re-do my tests with thumb2 vs ARMv7 :)
[13:03] <shenki> http://jms.id.au/wiki/TheresSomethingOnMyArm
[13:03] <ogra> asac, heh, we seem to have a race on the bug both duplicating each other :)
[13:03] <shenki> asac: there is a writeup of the tests ive done
[13:03] <asac> ogra: really?
[13:04] <asac> i am just posting things we find
[13:04] <asac> ;)
[13:04] <ogra> me too
[13:04] <asac> the bug seems ok to me
[13:04] <lool> asac: I've read the comments on that bug already
[13:04] <lool> asac: I don't know what the find outputs on armel systems
[13:04] <asac> ogra: i was faster ;)
[13:04] <lool> On my ubuntu install it's really small
[13:04] <ogra> yeah, you definately win :)
[13:04] <asac> lool: the find outputs empty
[13:04] <asac> thats one of the things we are investigating:
[13:04] <ogra> lool, see the last two comments
[13:04] <asac> a) add a safety belt: dont call copy_modules_dir if archcrypto is empty
[13:04] <asac> b) find out why on arm archcrypto is empty in the first place; if the find needs to be adjusted to it.
[13:04] <lool> So your find returns empty
[13:04] <lool> ok
[13:04] <ogra> right
[13:05] <lool> asac: Both have to be addressed
[13:05] <ogra> asac, b) is easy ... there is no crypto dir at all
[13:05] <lool> shenki: I asked about power usage too, but he said it was similar or identical
[13:05] <asac> lool: yes. title of those is:
[13:05] <asac> two things to do here:
[13:05] <asac> a)
[13:05] <asac> b)
[13:05] <ogra> root@ubuntu:/# grep SAHARA boot/config-2.6.31-601-imx51
[13:05] <ogra> CONFIG_MXC_SAHARA=y
[13:05] <ogra> # CONFIG_MXC_SAHARA_POLL_MODE is not set
[13:05] <ogra> # CONFIG_MXC_SAHARA_USER_MODE is not set
[13:06] <ogra> the crypto stuff for imx51 is compiled in
[13:06] <asac> ogra: yeah. so a) is enough ;)
[13:06] <ogra> no modules you could find
[13:06] <lool> asac: I was suggesting to do both because you wrote here "thats one of the things we are investigating"
[13:06] <shenki> lool: what kind of engineer was your freescale friend? (how far down in the stack)
[13:06] <lool> I thought it meant you would only do one of the two
[13:06] <asac> right. sorry
[13:06] <asac> no
[13:06] <asac> both
[13:06] <lool> shenki: *cough*
[13:07] <asac> maybe it was a powerpc fanatic ;)
[13:07] <shenki> :)
[13:07] <asac> i can only say that i can act quicker with 2 thumbs ;) rather than one cut off ;)
[13:07] <ogra> or the office gardener :)
[13:07] <lool> shenki: Actually http://www.arm.com/products/CPUs/archi-thumb2.html shows that thumb2 is not higher performance
[13:08] <lool> shenki: It's faster than *thmb 1*!
[13:08] <shenki> hrm. wtf did they invent thumb2 then!?
[13:08] <lool> So I guess the higher performance stuff comes from thumb1 comparisons
[13:08] <asac> the high level outcome of that is definitly better performance for the whole system
[13:08] <lool> shenki: Well it might overall be better than ARM in some cases
[13:08] <asac> if no net improvement on CPU level, size reduction is good :)
[13:08] <lool> shenki: And your binaries are smaller too
[13:08] <shenki> yeah, cache, memory...all ins
[13:08] <armin76> for windows *g*
[13:09] <lool> asac: You might see larger code performing *slower* though
[13:09] <lool> let's say firefox for instance
[13:09] <shenki> chromium is 30% smaller ARM v thumb
[13:09] <shenki> s/ins/wins
[13:09] <lool> I don't think firefox fits in cache
[13:09] <lool> Anyway, /me returns to python policy stuff
[13:09] <asac> no. but if size is smaller its still faster to get from mem to cpu
[13:09] <asac> even if not in cache
[13:10] <asac> thats my ignorant idea of this
[13:11] <asac> anyway... details ;)
[13:11] <asac> real life will show if this was worth it ;)
[13:44] <asac> plars: do we have a bug about busted dove image? maybe we should open one?
[13:45] <asac> plars: can you confirm that a lucid chroot on modern dove doesnt work at all?
[13:45] <plars> asac: yes, 494831
[13:45] <asac> (to narrow down if its only kernel problem)
[13:45] <asac> bug 494831
[13:45] <ubot4> Launchpad bug 494831 in linux-mvl-dove "Alignment trap/Unhandled fault errors on boot" [Critical,New] https://launchpad.net/bugs/494831
[13:46] <asac> plars: feel free to target such obvious release blockers for lucid
[13:46] <plars> asac: will give it a try
[13:46] <asac> done
[13:47] <asac> ok added tags
[13:47] <asac> also subscribe dmart
[13:48] <asac> subscribed
[13:52] <plars> asac: so do you believe that less likely to be kernel, more likely to be toolchain?
[13:53] <ogra> asac, do we want to duplicate Bug 494827 ?
[13:53] <ubot4> Launchpad bug 494827 in ubiquity "Installing on babbage 3, crashed at ~98%" [Undecided,New] https://launchpad.net/bugs/494827
[14:06] <asac> ogra: yeah
[14:06] <asac> plars: i dont know . i hope its either or ... and not a combination
[14:06] <asac> but starting with a chroot will help checking that imo
[14:07] <ogra> though let me quickly replace the script in a test install and see if ubiquity actually survives
[14:09] <ogra> well, FSVO quickly :)
[14:12] <asac> ogra: it survives
[14:12] <asac> i tried it
[14:12] <asac> it installs etc.
[14:12] <asac> at least when commenting the lines after "Copying files..."
[14:12] <ogra> a full ubiquity run ?
[14:12] <asac> yes
[14:12] <asac> at about 60% you can change the file
[14:12] <asac> and it will just succeed
[14:12] <ogra> well, i'll do it anyway since i want a lucid install
[14:13] <asac> ogra: the install doesnt boot here. seems to be usb-storage problem though
[14:13] <asac> so maybe with a different disc variant it will work
[14:13] <asac> well it boots
[14:13] <ogra> i'll check
[14:13] <asac> just doesnt start X
[14:13] <asac> you end up at the console
[14:13] <asac> and gdm cannot be killed/restarted without locking up the whole system
[14:14] <armin76> feature
[14:14] <ogra> i'll investigate that once i have a proper install
[14:21] <ogra> hmm, ubiquity doesnt really like to be re-run if it crashed once apparently
[14:21] <ogra> thats annoying
[14:23] <asac> ogra: reusing existing partitions is broken too
[14:23] <asac> so delete + create partition to workaround
[14:23] <ogra> i always to a full reinstall
[14:24] <asac> plars: do we have a bug on that already?
[14:24] <asac> hmm.
[14:24] <ogra> no need to delete for that
[14:24] <asac> ogra: maybe your usb is busted now?
[14:24] <ogra> just check "use complete device"
[14:24] <asac> not here ;)
[14:24] <asac> i have a good karmic partition on that i want to keep
[14:24] <ogra> ah
[14:24] <asac> until i have stacked up hardware redundancy
[14:24] <ogra> i have an extra disk for that
[14:25] <asac> yeah
[14:25] <asac> will get that too soon i guess
[14:25] <ogra> a well partitioned disk with separate home etc ...
[14:25] <plars> asac: on what?
[14:25] <ogra> though i started doing my work on SATA recently
[14:25] <asac> 15:23 < asac> ogra: reusing existing partitions is broken too
[14:25] <asac> 15:23 < asac> so delete + create partition to workaround
[14:25] <ogra> so its not that important anymore
[14:25] <asac> ubiquity
[14:25] <asac> plars: ^^
[14:25] <ogra> its partman, not ubiquity
[14:26] <plars> asac: hmm... sounds familiar, like possibly something we filed a while back and got untagged because it was not specific to armel
[14:26] <plars> asac: will have to search around for it
[14:26] <asac> thx
[14:26] <asac> ogra: yeah
[14:26] <asac> also ubiquity is really really slow on arm imo
[14:27] <asac> not sure what they do, but it feels not really designed for speed
[14:27] <asac> similar to update-manager :)
[14:27] <ogra> yes, lool filed a bug for that around jaunty
[14:27] <ogra> still open iirc
[14:27] <asac> actually i edited the hook file at about 58%
[14:27] <asac> then at about 60% the change was gone
[14:27] <asac> feels like it copies everything twice or something
[14:27] <asac> or i didnt hit save properly
[14:27] <ogra> i'll replace the file while langpacks are downloaded ;)
[14:28] <asac> but that doenst make the general slowness go away
[14:28] <ogra> its the throughput ...
[14:28] <asac> grapics driver is also sucky ;)
[14:28] <ogra> the USB controller gets you something like 16MB/s
[14:28] <asac> displaying stuff alone is really slow
[14:28] <asac> yeah
[14:28] <asac> could be
[14:28] <ogra> there is no graphics driver
[14:28] <asac> but but but
[14:28] <ogra> its framebuffer
[14:28] <asac> its also happning for things like timezone selection etc.
[14:29] <armin76> video killed the radio star
[14:29] <ogra> the driver that exists is 100% closed source
[14:29] <asac> i know.
[14:29] <ogra> and we dont include the imx-libs package yet
[14:29] <asac> is that something for restricted?
[14:29] <ogra> i'll push that to the archive during this cycle
[14:29] <asac> hmm
[14:29] <asac> ok
[14:29] <ogra> parts of it ...
[14:29] <ogra> there are binary files for video codecs
[14:30] <ogra> but i split the package already, look in the P3A
[14:30] <ogra> with imx-libs we at least have a 2D gpu API available ...
[14:31] <asac> cool
[14:31] <asac> will check
[14:31] <ogra> and a vpu for gstreamer
[14:31] <asac> have to run for lunch and then prepare the release report
[15:02] <ogra> weird ... ubiwuity is sitting at partitoning at 5% since 20min
[15:02] <ogra> no errors or anything
[15:05] <ogra> err
[15:05] <ogra> so now i'm confused, i got dropped back to the partitioner step
[15:16] <plars> ogra: this sounds like the usb problems I was seeing
[15:17] <ogra> there are no errors anywhere
[15:17] <plars> ogra: I got an on screen error, and a lot of spam in dmesg though
[15:17] <ogra> nothing ...
[15:17] <ogra> dmesg is fine, installer debug log is fine
[15:17] <ogra> it just starts over
[15:17] <ogra> i rebooted now
[15:18] <lool> suihkulokki: Did you manage to get your LD_PRELOAD exec() wrapper working with qemu-arm?
[15:26]  * ogra doesnt get it, same issue, no errors ... the same image worked fine on the same hardware yesterday
[15:27] <asac> JamieBennett: can you check if there is more to add to weekly summary?
[15:27] <asac> https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
[15:27] <ogra> its also extremely slow
[15:28] <ogra> sigh, what is that
[15:29] <asac> ogra: there are bugs with usb imo
[15:29] <ogra> asac, no errors at all
[15:29] <suihkulokki> lool: yeah, I have even a nice demo ready
[15:29] <ogra> and after the first try the disk was properly partitioned
[15:29] <suihkulokki> now I just need to get it uploaded somewhere with a readme
[15:29] <asac> ogra: yes. repartitioning is a problme
[15:30] <asac> did you unmount it before starting ubiquity?
[15:30] <ogra> nope
[15:30] <asac> yo uneed to do that
[15:30] <ogra> i never had to do that
[15:30] <ogra> and i would expect any errors to show up in any log files
[15:30] <asac> right
[15:30] <lool> suihkulokki: Cool!  may I help?
[15:30] <asac> i think its a regression, but we seem to have big bugs on resetting usb devices/ports
[15:30] <ogra> i see the partitioning steps in the logs and in dmesg
[15:31] <lool> suihkulokki: It looks like it's something I definitely want to use instead of the static binary
[15:31] <ogra> and they finish properly
[15:31] <asac> ogra: for me ubiquity crashed
[15:31] <lool> suihkulokki: Do you have a name for it?
[15:31] <asac> and UI stayed up
[15:31] <asac> so you didnt see it
[15:31] <ogra> then ubiquity jumps back to the partitioner
[15:31] <asac> think it forked a process that crashed and then waits for ever fo rthat to end
[15:31] <ogra> no
[15:31] <lool> suihkulokki: Perhaps in qemu itself?
[15:31] <ogra> i can even watch the slideshow while it hangs at 5%
[15:32] <ogra> until it gets me back to the partitioner
[15:32] <ogra> where i then see that it properly formatted and partitioned
[15:32] <asac> good. cant you then continue?
[15:32] <asac> oh reusing existing partitions definitly crashes ubiquitiy ;)
[15:32] <ogra> yes, to get into the same loop
[15:32] <asac> ogra: try advanced.
[15:32] <asac> remove partition, add new ... continue
[15:32] <asac> thats what i used
[15:32] <asac> and it worked
[15:32] <ogra> i *dont* reuse existing partitions
[15:32] <suihkulokki> lool: will you be arount in ~2h ?
[15:33] <suihkulokki> bit busy atm
[15:33] <ogra> i click "use entire disk"
[15:33] <asac> ogra: well. still just try that. if that works we can have someone else gather the details for the bug
[15:33] <ogra> i did the exact same thing three or four times yesterday
[15:33] <asac> ogra: dont use that. maybe thats broken ;)
[15:33] <ogra> and it worked flawless
[15:33] <asac> hmm
[15:33] <asac> well. ;)
[15:33] <asac> maybe reboot and try again ;)?
[15:33] <ogra> i did that two times already
[15:33] <lool> suihkulokki: Yes
[15:34] <asac> ogra: then try what i suggested. use advanced
[15:34] <asac> ;)
[15:34] <lool> Well I might leave a bit at that time, but worst case leave a message here
[15:34] <ogra> i'm using the same image (same SD even) in the exact same HW i used yesterday
[15:34] <ogra> going the exact same way i did yesterday
[15:34] <ogra> well, i'll try your suggestion
[15:35] <ogra> though i dont get why that issue shows up at all
[15:35] <ogra> especially without *any* error messages
[15:35]  * ogra reboots
[15:35] <ogra> asac, i agree though that if its in that state everything gets unusable slow
[15:36] <suihkulokki> as for the name, it is called croco atm
[15:36] <lool> W: Bizarre Error - File size is not what the server reported 65872 1
[15:36] <lool> Tss
[15:38] <suihkulokki> not tried on ubuntu, but I think croco too is affected by https://bugs.launchpad.net/ubuntu/+source/linux/+bug/452175
[15:38] <ubot4> Launchpad bug 452175 in bash "Random segfaults when using ld.so explicitly to start a program" [Medium,Confirmed]
[15:39] <lool> Never seen that one yet
[15:40] <lool> suihkulokki: The loop doesn't segfault for me (on amd64)
[15:41] <lool> while :; do /lib64/ld-linux-x86-64.so.2 /bin/bash -c '/usr/bin/which apt-get'; done
[15:41] <lool> Ah right it's noted in the bug that amd64 works
[15:49] <ogra> sigh
[15:49] <ogra> so i zeroed out the disk ...
[15:49] <ogra> same issue
[15:54] <asac> yes. not sure. i had tons of issues with partman
[15:54] <asac> only way it worked was to remove a partition manually, add it then
[15:54] <asac> i will do another install i guess
[15:55] <asac> ogra: how can i make an install image out of a converted boot image without needing to put everything on it?
[15:56] <asac> is there a trick or should i just do a fresh dd ?
[15:56] <ogra> do a fresh dd
[15:56] <ogra> you would need to manually replace the initrd and change the cmdline
[15:56] <ogra> to get the casper bits
[15:57] <asac> k
[15:57] <ogra> funny is that the led on my usb key flashes madly
[15:58] <ogra> if i wouldnt knoe better i'd say its copying
[15:58] <ogra> *know
[16:01] <asac> ogra: would it be easy for you to check whether its ok with the old kernel?
[16:01] <ogra> ha !
[16:01] <ogra> this time it moved on
[16:02] <asac> see ;)
[16:02] <ogra> formatting just took ages
[16:02] <asac> be patient ;)
[16:02] <ogra> it has never been that slow
[16:02] <ogra> and i use the same USB key for all my test installs since jaunty
[16:02] <asac> ok doing an install on a SD card now
[16:02] <asac> since the ext4 issues feel liks usb related
[16:03] <asac> also i want a fixed hwclock :/
[16:06]  * ogra has no hwclock probs 
[16:06] <ogra> just give up your resistance to ethernet cables ;)
[16:07] <armin76> use reiser4 *g*
[16:08] <asac> haha
[16:08] <asac> nework manager works great ;)
[16:08] <asac> just not on livecd before X
[16:15] <ogra> oho !
[16:15] <ogra> write error on swap device
[16:15] <ogra> i guess thats my issue
[16:16] <ogra> its spilling the console but doesnt show up in any log
[16:17]  * ogra suspects compcache is broken
[16:24] <ogra> oh my
[16:28] <ogra> hmm, calling swapoff -a wasnt so clever it seems
[17:00] <asac> ogra: so my test install is now at apt stage ;)
[17:00] <asac> (test install on SD as usb was broken)
[17:01] <ogra> as USB ?
[17:01] <asac> usb-storage big thing that is
[17:01] <ogra> oh, as usb was broken ...
[17:01]  * ogra read SD as usb :)
[17:01] <asac> hehe
[17:01] <asac> no
[17:01] <ogra> well, there is definately something wonky with swap
[17:02] <ogra> but i couldnt find out if its compcache or the swap device on disk
[17:02] <ogra> the latter would explain your usb issues though
[17:02] <ogra> (that you have to unmount etc)
[17:02] <ogra> and also the slowness
[17:05] <asac> ogra: swap might be related to the usb prob
[17:06] <asac> but not 100% sure
[17:06] <asac> ogra: can i disable this bootsplash thing easily with redboot?
[17:06] <asac> i hav ethe feeling i dont see enough ;)
[17:07] <ogra> install redboot-tools on your x86 machine
[17:07] <asac> hmm. installer downloads language packs if there is net
[17:07] <ogra> yeah
[17:07] <asac> thats bad ;)
[17:07] <ogra> perferct time to apply the crypto fix :)
[17:08] <asac> i dont need lang packs
[17:08] <asac> oh there is a skip
[17:08] <ogra> right
[17:08] <asac> not sure if should hit that ;)
[17:08] <asac> lets wait
[17:21] <ogra> swapoff /dev/ramzswap0 ...
[17:21] <ogra> thats speeding things up a lot
[17:21] <asac> hmm
[17:22]  * asac doesnt try that at 98% ;)
[17:22] <ogra> and i didnt have any issues with partitioning this time
[17:22] <ogra> heh, no
[17:22] <ogra> you have to do it right after boot
[17:22] <ogra> before anything has swapped
[17:24] <asac> 100% ;)
[17:24] <asac> gogogo
[17:24] <asac> its getting late
[17:24] <ogra> 40% in 20min .... new speed record
[17:24] <asac> yes. restarting now ;)
[17:25] <asac> i saw an odd diff when looking through the kernel update we had in lucid
[17:25] <asac> ogra: why was there an update?
[17:25] <asac> thought there were no changes
[17:25] <ogra> merge with the latest upstream source
[17:25] <asac>                 uv_cpu_hub_info(cpu)->m_val = m_val;
[17:25] <asac> -               uv_cpu_hub_info(cpu)->n_val = m_val;
[17:25] <asac> +               uv_cpu_hub_info(cpu)->n_val = n_val;
[17:25] <ogra> if .31 gets updated the branch gets re-merged
[17:25] <asac> either it was a bad bug before
[17:25] <asac> or its a bad bug now ;)
[17:25] <ogra> heh
[17:25] <ogra> i guess the latter
[17:26] <ogra> but lets wait for the new kernel
[17:26] <ogra> patches are there
[17:26] <asac> though n_val = n_val sounds so right ;)
[17:26] <ogra> heh
[17:26] <asac> so our imx51 kernel contact is on vacatioon till end of year?
[17:26] <ogra> not that i know of
[17:26] <asac> me triggers some panic in team ;)
[17:27] <asac> he is not here yet ;)
[17:27] <ogra> depends whom you refer to :)
[17:27] <asac> coloonel
[17:27] <asac> y
[17:27] <ogra> right, i mailed him the link to the tgz
[17:27] <asac> he works offline?
[17:27] <ogra> did he say anything about vacation ?
[17:27] <asac> so .... yay!
[17:27] <asac> the install works
[17:27] <asac> just usb storage was the problem
[17:27] <ogra> he works in asia ...
[17:27] <asac> install on SD works well
[17:27] <asac> i am using it now ;)
[17:27]  * asac happy
[17:27] <ogra> where its 1:30 am now
[17:28] <ogra> great
[17:28] <asac> i guess the m_val above is the problem ;)
[17:28] <ogra> good to hear
[17:28] <asac> for the usb-storage thing
[17:28] <ogra> talk to the kernel team then
[17:28] <asac> we should really get two kernel folks on the team
[17:28] <asac> we have separate kernels anyway
[17:28] <ogra> but thats coming from the upstream core
[17:28] <asac> sure? maybe its a merge issue
[17:28] <ogra> there were no changes in the board patches
[17:29] <ogra> even then its coming from upstream
[17:29] <asac> i wouldnt think that our kernel folks are perfect at merging
[17:29] <asac> especially since they have zillions of patches to go through
[17:29] <ogra> the code didnt change on the imx51 side
[17:29] <asac> right
[17:29] <asac> thats x86
[17:29] <asac> ;)
[17:29] <ogra> so while it might be a merge issue, the *cause* is upstream changes
[17:30] <ogra> i think apw does the rebase
[17:30] <asac> right. merge issue is for me: mistake on rebase
[17:30] <asac> rebasing also requires merging
[17:30] <asac> anyway
[17:30] <asac> that particular hunk ix x86
[17:30] <asac> and hopefully doesnt change anything for us
[17:31] <asac> ogra: what does it take to make a kernel from the fsl code drop?
[17:31] <ogra> i think the most imx51 stuff is in platform specific subdirs anyway
[17:31] <ogra> asac, a .31 tree :)
[17:31] <asac> we have that
[17:32] <ogra> then you should just be able to apply them one by one
[17:32] <asac> i mean we could just clone the current .31 tree
[17:32] <asac> and apply them
[17:32] <ogra> right
[17:32] <ogra> its 170 patches
[17:32] <asac> do we reall yneed to base that on ubuntu tree?
[17:32] <ogra> there is a script in the tarball
[17:32] <asac> we could just use upstream tree and the patches probably will just apply
[17:32] <ogra> for your own stuff upstream should work
[17:33] <ogra> for the distro we need the ubuntu tree
[17:33] <asac> why?
[17:33] <ogra> you need apparmor and friends
[17:33] <asac> hmm
[17:33] <ogra> and aufs
[17:33] <ogra> and the other ubuntu suace patches
[17:33] <ogra> *sauce
[17:33] <asac> so apparmore is not upstream?
[17:33] <asac> what a bad thing ;)
[17:33] <asac> what is ubuntu sauce?
[17:33] <ogra> the stuff on top of the dogfood
[17:34] <ogra> :)
[17:34] <asac> doesnt that mean: arbitrary hack-crap added at some point for odd reasons ;)?
[17:34] <asac> ok. me should stop bitching about kernel trees ;)
[17:34] <ogra> see /lib/modules/$(uname -r)/kernel/ubuntu/
[17:35] <ogra> and i think we also merge staging from greg
[17:35] <ogra> or at least parts of that
[17:35] <asac> what is  lirc?
[17:35] <asac> bunch of modules there and i have no clue why they are there ;)
[17:35] <ogra> infrared remote control
[17:35] <ogra> for dvb cards etc
[17:36] <asac> thats considered esesntial enough?
[17:36] <ogra> apparently :)
[17:36] <asac> to justify forking?
[17:36] <ogra> its not forked
[17:36] <ogra> it sits on top
[17:36] <ogra> like a sauce :)
[17:36] <asac> well. it requires rebasing each and every release
[17:36] <asac> which means that merge bugs can happen
[17:36] <asac> and sneak in ;)
[17:37] <asac> of course better than merging instead of rebasing ;)
[17:37] <ogra> we also develop stuff in tree afaik
[17:37] <asac> in tree?
[17:37] <ogra> that havent been accepted upstream yet but will be soon
[17:37] <ogra> in our tree
[17:37] <asac> yes
[17:37] <asac> but thats also sitting on top i hope
[17:37] <ogra> but better talk to the kernel team about that
[17:37] <asac> and not covered by upstream merges that came later ;)
[17:38] <ogra> i *think* they are knowing what they do ...
[17:38] <ogra> ... sometimes ...
[17:38] <asac> i am not convinced ;)
[17:38] <ogra> ... depending on beer level ...
[17:39] <asac> like i ping rtg everytime getting from him a hard confirm that the harware magic is disabled in wifi drivers
[17:39] <asac> and then during UDS emmet has issues because they are still not disabled ;)
[17:39] <asac> even though rtg confirmed at beta and rc time that its turned off ;)
[17:39] <ogra> merge issues :P
[17:40] <asac> right ;)
[17:40] <asac> anyway. in general situation is much better ;)
[17:40] <asac> than in the past ;)
[17:40]  * JamieBennett needs lirc for his XBMC machine ;)
[17:40] <ogra> there you go
[17:40] <ogra> usecase !
[17:41] <asac> bugabundo also needs 70 firefox extensions
[17:41] <asac> doesnt make it better ;)
[17:41] <JamieBennett> :)
[17:41] <ogra> looool
[17:41] <asac> there are always crackful users out there ;) if you ship something it gets used. - and for them its essential
[17:42] <asac> anyway. /me goes back to productive discussion mode ;
[17:42] <asac> evn though its friday
[17:42] <asac> JamieBennett: so for me lucid images work well with the workaround on SD cards
[17:42] <asac> did you manage to install yet?
[17:43]  * ogra is at 60%
[17:43] <JamieBennett> I haven't tried but I can do an install tonight (I've downloaded the image)
[17:43] <asac> JamieBennett: ok. the image for tomorrow should work oob
[17:43] <JamieBennett> Soooo, today or tomorrow testing?
[17:44] <asac> you can test today and hack cryptroot fs after the file was copied to /target
[17:44] <asac> _or_ tomorrow
[17:44] <asac> with an image that should just work (TM)
[17:44] <asac> but tomorrow is saturday ;)
[17:44] <ogra> thats one day before sunday
[17:44] <JamieBennett> do we get Saturday off or something?
[17:44] <JamieBennett> ;)
[17:44] <ogra> or the day after friday
[17:44] <asac> JamieBennett: not you ;)
[17:44] <JamieBennett> :)
[17:45] <asac> you closed too many work items
[17:45] <asac> thats suspicious
[17:45] <asac> you need more work ;)
[17:45]  * JamieBennett has some hot potatoes in there though
[17:45] <JamieBennett> which I have no control over
[17:46] <ogra> asac, you are scary
[17:46] <JamieBennett> but we like it ;)
[17:46] <asac> hehe
[17:46] <armin76> asac: so hows chromium?
[17:46] <asac> i think you cant be more scared about me than i am already ;)
[17:47] <asac> armin76: running swiftly with full speed
[17:47] <asac> j.k.
[17:47] <asac> startsup
[17:47] <asac> and has some issue with sandboxing
[17:47] <ogra> asac, lets say we get used to it :)
[17:47] <asac> but now i have a real install
[17:47] <JamieBennett> ship it ;)
[17:47] <asac> and i hope it just goes away
[17:47] <armin76> asac: had to touch too much stuff or?
[17:48] <asac> armin76: yesterday and today a bunch of fixes got landed upstrema (including mines)
[17:48] <asac> armin76: no. we upstreamed everything basically
[17:48] <asac> fta doesnt add new patches to packages unfortuantely
[17:48] <armin76> why unfortunately? thats nice if the patches land upstream
[17:48] <armin76> *actually* land, that is
[17:49] <asac> armin76: yes. its fortunately that they land upstream
[17:49] <asac> but that fta doesnt even add a patch to get things going quicker ;) ... its ok
[17:49] <fta> i do, when upstream refuses the patches, otherwise, i prefer to wait 1 day or 2 to get it upstreamed
[17:51] <fta> if you add a patch in a daily that's going to land upstream soon, the next build will fail so you have to touch the package twice just to gain 1 day
[17:51] <fta> and build 3 times
[17:51] <asac> hmm. wer realy have usb-storage issues
[17:51] <asac> i cannot mount my usb disk at all
[17:51] <asac> its not even detected anymore
[17:52] <ogra> asac, really sounds like a 3.0 issue
[17:52]  * ogra wishes he had a 3.0 to verify such things
[17:53] <asac> ogra: once i hvae install chromium here i will try the 2.0 and compare
[17:53] <asac> but i think its really a busted kernel ;)
[17:54] <asac> karmic worked well
[17:54] <ogra> 2.0 is bad
[17:54] <asac> thats why i am looking for cooloney ;)
[17:54] <ogra> they never worked reliably
[17:54] <asac> want someone to blame here ;)
[17:54] <asac> ogra: loic said just graphics had issues
[17:54] <asac> we will see
[17:54] <ogra> i think its a v7 issue
[17:54] <ogra> but i dont see any usb issues on my babbage
[18:04] <asac> ww ... chromium doesnt need additional depends on a fresh install
[18:04] <asac> fta: ;)
[18:04] <asac> everything built-in ;)
[18:05] <ogra> ffmpeg too ?
[18:05] <asac> we have a different package
[18:05] <ogra> ah
[18:05] <fta> there are few libs dlsymed, like opengl for webgl
[18:05] <asac> fta: thast --disable-sandbox?
[18:05] <fta> yes
[18:06] <asac> hmm. doest help ;(
[18:06] <asac> still getting same prob
[18:06] <asac> vitual functions etc.
[18:06] <fta> asac, hm, no, --no-sandbox
[18:07] <fta> do you get a oh snap! somewhere?
[18:07] <asac> sure?
[18:07] <asac> yes
[18:07] <asac> i get "oh snap!"
[18:07]  * ogra had that too on arm
[18:08] <asac> that mens that the browser process died
[18:08] <asac> but no .crash file or something
[18:08] <asac> hmm
[18:08] <ogra> right, was the same for me
[18:08] <ogra> and no errors on cmdline or so
[18:09] <asac> i think its a new issue though
[18:09] <asac> the first one got a backtrace and it didnt find neon symbols
[18:09] <asac> so now we dont use neon
[18:09] <ogra> thats good
[18:09] <asac> which was never intended
[18:09] <ogra> since dove doesnt have neon
[18:09] <fta> asac, http://code.google.com/p/chromium/wiki/LinuxDebugging
[18:09] <asac> not sure how to break at the virtual functio thing
[18:10] <asac> ogra: we sem to have no neon symbols either ... at least not the ones chromium wnated
[18:10] <ogra> i think imx51 has *some* neon
[18:10] <asac> cool
[18:10] <asac> chrome --renderer-cmd-prefix='gdb --args'
[18:11] <ogra> (though someone at UDS said bbg3.0 should have full neon support)
[18:11] <asac> oops
[18:12] <asac> ogra: well. seems that hardware might have it, but our libs didnt have whatever NEON symbol was expected
[18:12] <asac> anyway
[18:12] <ogra> right
[18:12] <asac> waiting for the infinit abort backtrace to finish ;)
[18:12] <ogra> but we cant use it anyway since dove doesnt have it
[18:13]  * asac  installs dbg symbols
[18:14]  * ogra goes afk ... will check back later to look after my babbage
[18:28] <lool> The montavista folks told me gdb is broken with T2  :-/
[18:31] <asac> hmm
[18:31] <asac> thats bad
[18:32] <asac> i get infinite backtrace in libc abort
[18:32] <asac> lets see if dbg symbols help there
[23:04] <ramana> hi - what arch. does the marvell dove board run at ? is it equivalent to the marvell sheevaplug boards ?
[23:13] <lool> ramana: No, dove is v7, sheevaplug is v5
[23:13] <lool> ramana: google for "armada" for dove
[23:13] <ramana> lool: ok thanks.
[23:13] <lool> and for kirkwood for sheevaplug
[23:14] <ramana> aha .. so dove uses armada . I knew that sheevaplug was kirkwood.
[23:17] <ramana> thanks - lool .