[01:52]  * GrueMaster is finding it very hard to concentrate on release testing with the aroma of grilled babyback ribs waifing in through the office window from the grill on the otherside.
[02:00] <jcrigby> NCommander or ogra:is flash-kernel for maverick in bzr?  I can apt-get source it but I have not been able to figure out the bzr lp: url for it.
[02:01] <jcrigby> or GrueMaster:^^
[02:02] <GrueMaster> jcrigby: bzr get http://bazaar.launchpad.net/~ubuntu-core-dev/flash-kernel/ubuntu
[02:03] <jcrigby> GrueMaster:in the interest of not bugging you next time.  How could I figure that out myself?
[02:03]  * GrueMaster is getting a contact hunger buzz from the grill smoke outside his office.
[02:03] <jcrigby> I was able to find it on launchpad for lucid but not maverick
[02:04] <NCommander> jcrigby: generally, its set in the control file and apt-get source will tell you if you call it
[02:04] <jcrigby> ahh
[02:04] <jcrigby> thanks
[02:04] <GrueMaster> NCommander: did you get my SMS?
[02:08] <NCommander> GrueMaster: not yet
[02:08] <GrueMaster> antimony is df.  Can you do a little cleanup and kick edubuntu dvds?
[02:35] <NCommander> GrueMaster: I can't. :-/
[02:35] <NCommander> but I can poke those who can
[02:35] <GrueMaster> If they are available.  elmo already tried earlier on #ubuntu-release.
[02:37] <NCommander> bah
[02:38] <NCommander> GrueMaster: looks like osmething happened in scratch
[02:38] <NCommander> I'm looking
[02:47] <jcrigby> NCommander: I found a couple small annoyances in flash kernel today.  Here is a patch: http://paste.ubuntu.com/473344/
[02:47] <jcrigby> s/flash kernel/flash-kernel/
[02:48] <NCommander> jcrigby: the patch looks good, butr I can't merge it into the repo
[02:48] <jcrigby> do you want me to do a bzr push and a merge req?
[02:48] <jcrigby> for ogra?
[02:49] <NCommander> jcrigby: yes pelase :-), post ogra_cmpc or lool for a merge
[02:49] <jcrigby> ok will do
[03:44] <prpplague> NCommander: ping
[05:24] <NCommander> prpplague: pong
[05:25] <prpplague> NCommander: distcc
[05:25] <NCommander> prpplague: ECONTEXTNEEDED
[05:25] <prpplague> NCommander: hehe
[05:25] <prpplague> NCommander: you do any native builds of ubuntu on arm using distcc with multiple arm systems?
[05:27] <NCommander> prpplague: no, I've only done it to build OpenOffice.org as a standardlone package, and then I used icecc
[05:27] <prpplague> NCommander: ahh ok
[06:08] <lag_> Morning
[07:41] <lag_> cooloney: ?
[08:10] <hrw> morning
[08:11] <lag_> cooloney: TIs Friday release?
[08:11] <lag_> When will it be applied to our kernel?
[08:11] <cooloney_> lag_: oh, i am not sure about that
[08:11] <cooloney_> lag_: but we will get their release next week
[08:12] <cooloney_> lag_: we need to rebase our Ubuntu kernel on their 2.6.35 release next week
[08:12] <lag_> There are some patches which are critical (for me)
[08:12] <lag_> rsalveti also needs the rebase asap
[08:13] <cooloney_> lag_: oh, where are they? and will they be included in TI 2.6.35 release?
[08:13] <cooloney_> lag_: yeah, i c, but we still need to wait from TI
[08:13] <lag_> Yeah I know
[08:14] <lag_> They will be out Friday
[08:14] <lag_> I have the patches
[08:14] <lag_> But they will be available from their tree on Friday
[08:15] <cooloney_> lag_: ok, that's great, after we upgrade to their tree next week, we will get those patches, right?
[08:16] <cooloney_> i will cowork with ndec from TI to make that happen next week.
[08:16] <lag_> That's the theory
[08:17] <cooloney_> so could you please point us out the patches via email. ndec and I can make sure they will be merged next week
[09:16] <medel> hello
[09:16] <medel> I'm new on thit site, I'm using ubuntu on beagleboard (trying to)
[09:17] <medel> could any of you help me whit a easy tutorial?
[09:21] <amitk> medel:
[09:21] <amitk> medel: https://wiki.ubuntu.com/ARM/BeagleNetInstall
[10:24] <hrw> zumbi: present?
[10:24] <hrw> zumbi: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577674 was reopened by you and then requested with moreinfo by doko. Can you provide that moreinfo?
[10:24] <ubot2> Debian bug 577674 in gcc-4.4 "gcc-4.4/cross: broken bi-arch architectures" [Wishlist,Open]
[10:34] <amitk> medel: you can go here and choose your method of install https://wiki.ubuntu.com/ARM/Beagle
[10:34] <amitk> medel: but keep in mind that the netbook install is very slow because the beagleboard only has 256M of RAM
[10:35] <amitk> medel: I suggest doing a netinstall and then install perhaps a xubuntu-desktop or something light weight
[10:36] <hrw> zumbi: sorry, my mistake
[10:47] <sshekar> hello! does anyone know if ubuntu-netbook can support multiple displays? similar to desktop version?
[10:47] <sshekar> I am developing the X display driver for multiple display support & seeing some strange behavior as I enable certain features...so wanted to check if the netbook version supports this?
[11:06] <JamesWStubbs> Hello, I'm doing an Ubuntu port to the iPhone, I'm having a problem with screen rotation using Fbdev and evtouch. Both will work fine in portrait, but for screen estate reasons I need it to be landscape before I can release my images. I've added Option "Rotate" "CW" to xorg.conf, which will rotate the screen when X starts but as soon as the screen is touched the X server closes. I've also tried adding Mode "480x320" to the Display section of xorg.con
[11:15] <lag_> ogra: What's the reason for the crazy partition naming conventions on the daily build?
[11:15] <ogra> crazy ?
[11:16] <lag_> Bonkers
[11:16] <lag_> Loony
[11:16] <ogra> lag_, you mean SERVICEV001 ?
[11:17] <ogra> lag_, tail -40 /lib/udev/rules.d/80-udisks.rules
[11:17] <lag_> 038157b1-ec85-42b0-94e7-7c7e33805661
[11:17] <ogra> we'll add a more sane name and our own udev rule for it beofre final (thats part of jasper)
[11:17] <ogra> huh ?
[11:17] <ogra> thats a UUID not a label
[11:18] <lag_> That's what my computer calls them when I mount them
[11:18] <ogra> yeah
[11:18] <ogra> thats normal if there is no label set
[11:18] <lag_> Can't we set one?
[11:18] <ogra> why ?
[11:18] <lag_> Writing scripts to do my work would be so much easier
[11:19] <ogra> we dont do that anywhere else in ubuntu
[11:19] <lag_> boot and rootfs will do fine
[11:19] <lag_> Nowhere else in Ubuntu uses SD cards
[11:19] <ogra> boot is made invisible after first boot of the image
[11:19] <lag_> Yeah, that's annoying too
[11:19] <ogra> (you didnt try my "tail" above, did you ?)
[11:20] <lag_> I did
[11:20] <ogra> why a user will never ever touch it
[11:20] <lag_> I'm never going to touch it if these annoyances don't go away
[11:20] <lag_> Lol
[11:20] <ogra> beyond having it always on every users desktop is annoying too
[11:21] <ogra> if you dont hide it, it gets automounted and has a static icon on desktop and in the filemanager
[11:21] <ogra> tell me whats more annoying ?
[11:22] <ogra> (for endusers, not for devs!)
[11:23] <ogra> you could file a whishlist bug against oem-config for the hostname configuration, it could set a label (optional) "$hostname-rootfs" or something like that if users really want that
[11:24] <ogra> in normal operation a user will never see the UUID
[11:29] <lag_> I'm not really interested in the auto-mount issue - I have scripts that get around that easy enough
[11:30] <lag_> However, the random chars (no label) makes things very difficult
[11:32] <JamesWStubbs> Anyone got any ideas why when I have fbdev rotated clockwise, X11 closes as soon as the screen is touched using evtouch ?
[11:35] <ogra> lag_, thats what we use everywhere
[11:36] <ogra> lag_, and its induced from the kernel
[11:36] <lag_> Give me a workable label cross-platform (OMAP3/OMAP4)
[11:37] <ogra> thats a moot point for an enduser image, no ?
[11:37] <ogra> an enduser will *never ever* see the uuid
[11:37] <ogra> similar to x86
[11:37] <lag_> I guess I could use the dev node instead
[11:38] <ogra> right
[11:39] <ogra> the automounting used to use real device names "USB Disk 1" etc, upstream decided to instead ise the UUID if there is no label set
[11:39] <ogra> if you want that part chnaged, talk to the gvfs or nautilus upstreams
[11:40] <lag_> That's still annoying - it means I can't have two /dev/sd* devices plugged in at once
[11:40] <sshekar> JamesWStubbs: try evdev instead of evtouch...also pastebin your Xorg.0.log after crash
[11:40] <lag_> Basically it's only a matter of time before I dd over my iPod
[11:40] <lag_> (dd was a bad example, but you get the idea)
[11:44] <JamesWStubbs> sshekar: I'll scp an Xorg log now, unfortunatly evdev isn't ideal due to lack of right click support, I have had landscape and evdev working fine, but right click is needed
[11:46] <JamesWStubbs> sshekar: Would you like a paste of the xorg.conf aswel?
[11:46] <ogra> lag_, thats why i wrote usb-imagewriter ages ago
[11:46] <sshekar> JamesWStubbs:  sure
[11:46] <lag_> What does that do?
[11:46] <ogra> lag_, it's a gui to dd suporessing everything but USB keys and SD cards
[11:50] <JamesWStubbs> sshekar: Would you like the log of me using the Rotate CW option ?
[11:50] <JamesWStubbs> Where evtouch closes the server?
[11:58] <ogra> asac, new launcher works
[12:02] <asac> \o/
[12:02] <asac> thx
[12:04] <JamesWStubbs> sshekar: xorg.conf : http://pastie.org/1077150 Xorg.0.log : http://pastie.org/1077153
[12:08] <hrw> JamesWStubbs: remote input-synaptics from system and retry?
[12:22] <JamesWStubbs> hrw: Ok, trying now
[12:23] <JamesWStubbs> I've blacklisted them, but I'll try removing them
[12:23] <lag_> ogra: Have you filed the ro bug yet?
[12:34] <JamesWStubbs> hrw: sshekar: Same issue after removing synaptics
[12:35] <sshekar> JamesWStubbs: sorry was away....the crash is because of evtouch
[12:36] <JamesWStubbs> The crash doesn't happen in portrait
[12:36] <JamesWStubbs> It's only when I attempt to use landscape
[12:36] <JamesWStubbs> But the face is works when using evdev, proves it evtouch that's the issue
[12:36] <JamesWStubbs> What do you think is causing the issue when trying to use in landscape?
[12:37] <sshekar> JamesWStubbs: ya... I am not sure if it is maintained....probably you need to hack evdev for your use case
[12:39] <JamesWStubbs> sshekar: Do you know of a version of evdev that supports right click?
[12:39] <sshekar> JamesWStubbs: I dont know....you can ask in #xorg or #xorg-devel
[12:40] <JamesWStubbs> Ok, thanks for you help
[12:40] <sshekar> also I would suggest if you can upgrade to latest X...the one you are using is little old
[12:40] <JamesWStubbs> sshekar: It's simply the one in the karmic repo
[12:40] <JamesWStubbs> I keep having problems compiling
[12:40] <JamesWStubbs> I'll do apt-get build-dep xorg
[12:41] <JamesWStubbs> Then when I try to compile the latest from source I keep getting dependencie errors...
[12:41] <sshekar> ok...maybe you can upgrade to Lucid
[12:43] <JamesWStubbs> Lucid is armv7 only
[12:43] <JamesWStubbs> iPhone uses v6
[12:45] <JamesWStubbs> There's a "hacktastic" patch for evdev right click
[12:45] <JamesWStubbs> I'll see if I can get it working
[12:46] <sshekar> ok...all the best...if you want to build X by hand... http://xorg.freedesktop.org/wiki/ModularDevelopersGuide
[12:47] <JamesWStubbs> Thanks for your help, I'll get back on with it.
[12:47] <sshekar> np
[13:57] <lag_> ogra: Who maintains the app which sets up user/timezone/keyboard on Arm?
[13:59] <lag_> ogra: Also, have you put console=tty2 on the cmdline yet?
[14:10] <lag_> ogra: You can't hide forever - I have so many things to bug you about!
[14:10] <lag_> :)
[14:47] <rsalveti> cooloney: lag_ : just a question, do we know already if the TI friday release is going to be based on 2.6.35?
[14:48] <rsalveti> or we're going to have another release based on .35
[14:50] <lag_> mythripk: ---^
[14:55] <mythripk> lag: yes
[14:56] <rsalveti> mythripk: oh, thanks
[14:56] <rsalveti> so probably lots of things are going to change
[14:56] <rsalveti> and it's going to take a while to merge and etc
[14:59] <ogra> lag_, the app is ubiquity
[15:00] <ogra> lag_, and no, we dont put console= on the cmdline since that breaks the splash
[15:02] <lag_> Well without it I can't see anything - ever
[15:03] <rsalveti> lag_: :-)
[15:03] <lag_> Neither can rsalveti
[15:03] <rsalveti> you have to get used to edit the boot.scr all the time
[15:03] <lag_> Which users aren't going to do
[15:03] <ogra> users should have to add hacks to kernel cmdlines :)
[15:03] <rsalveti> why users want to check the uart?
[15:04] <rsalveti> or the kernel log
[15:04] <ogra> tty2 isnt UART :)
[15:04] <rsalveti> yep, I was thinking about uart, but same reason
[15:04] <ogra> lag_ asked about adding console=tty2
[15:04] <rsalveti> you still need to change if you want to see it
[15:05] <ogra> then that should be fixed
[15:05] <ogra> instead of being hacked around
[15:05] <lag_> So fix it :)
[15:05] <ogra> especially in the default setup
[15:05] <ogra> lag_, userspace doesnt touch the console
[15:05] <ogra> must be a kernel issue :)
[15:06] <ogra> btw, about what HW do we talk here ? beagle or panda
[15:07] <lag_> Panda
[15:07] <lag_> Only Panda
[15:07] <ogra> why would console=tty2 change anything ?
[15:07] <lag_> rsalveti: Did you get your answer from mythripk?
[15:07] <ogra> it works fine here
[15:07] <rsalveti> lag_: yep
[15:07] <lag_> ogra: Another question for mythripk
[15:08] <lag_> She's the graphics wizz
[15:08] <lag_> rsalveti: Which was?
[15:08] <rsalveti> lag_: "yes"
[15:09] <lag_> Oh, that was the answer? I thought it was a "yes, what do you want"
[15:09] <rsalveti> lag_: well, she didn't comment about it, so I think that was the answer :-)
[15:10] <ogra> rsalveti, you got a panda currently, right ?
[15:10] <rsalveti> ogra: yep
[15:11] <ogra> rsalveti, did you test the recent image on it ?
[15:11] <rsalveti> ogra: not the latest one
[15:11] <ogra> k
[15:11] <rsalveti> just got out of bed :-)
[15:11] <ogra> heh, indeed
[15:14] <lag_> ogra: Is ureadahead fixed yet?
[15:14] <ogra> huh ?
[15:14] <rsalveti> lag_: probably not, was going to take a look at it today
[15:14] <ogra> doesn anyone know why its broken yet ?
[15:14] <lag_> I thought Tim fixed it
[15:14] <rsalveti> actually this is what I should do today
[15:15] <rsalveti> as now I got my monitor working with panda, and panda is fully working
[15:15] <ogra> lag_, i thought so too, but people are still reporint OOMs
[15:15] <lag_> ogra: Doesn't your daily build runs dies with OOM?
[15:15] <lag_> ogra: Me too
[15:15] <rsalveti> it should give OOM on beagle
[15:15] <ogra> i havent tested on the beagle yet
[15:15] <rsalveti> not on panda, I believe
[15:15] <ogra> it doesnt on panda
[15:15] <lag_> Mine does
[15:15] <rsalveti> hm
[15:15] <ogra> panda is actually errorless here
[15:16] <lag_> Begin: Running /scripts/init-bottom ... done.
[15:16] <lag_> init: ureadahead main process (572) terminated with status 5
[15:16] <lag_> fsck from util-linux-ng 2.17.2
[15:16] <lag_> /dev/mmcblk0p2: clean, 156055/1466880 files, 1853382/15583048 blocks
[15:16] <lag_>  * Starting AppArmor profiles        Out of memory: kill process 1285 (pulseaudio) score 25299 or a child
[15:16] <lag_> Killed process 1337 (gconf-helper) vsz:11900kB, anon-rss:624kB, file-rss:96kB
[15:16] <ogra> install went through in ~10min
[15:16] <lag_> ..
[15:16] <ogra> status 5 isnt OOM :)
[15:16] <lag_> What's status 5?
[15:16] <ogra> it doesnt index MMCs
[15:16] <ogra> exit because it cant treat the disk
[15:16] <ogra> iirc
[15:16] <lag_> Okay
[15:17] <lag_> So why the OOM?
[15:17] <rsalveti> pulseaudio got OOM
[15:17] <lag_> rsalveti: The first of many
[15:17] <ogra> even ureadahead crashing isnt an issue nor the OOM
[15:17] <ogra> the real issue is that it tears down plymouth
[15:18] <lag_> And why does it check for re-size on every boot?
[15:18] <ogra> to update its db i guess
[15:18] <ogra> i havent looked inside ureadahead yet
[15:19] <lag_> No, the filesystem
[15:19] <ogra> but i know that we wont make much use of it anyway on MMCs
[15:19] <ogra> thats a bug GrueMaster mentioned here yesterday
[15:19] <ogra> err, no, wait
[15:20] <ogra> lag_, define "check for resize"
[15:20] <lag_> Resizing root filesystem. Please wait, this will take about ten minutes per 4G ...
[15:20] <lag_> Checking filesystem before resizing...
[15:20] <ogra> then it couldnt write your new boot.scr
[15:20] <lag_> Oh, I have my own boot.scr
[15:20] <ogra> yeah, that doesnt work
[15:20] <lag_> What do I need to add to stop it from doing that?
[15:21] <ogra> use the proper ubuntu root= entry
[15:21] <lag_> k
[15:21] <lag_> Is that all it looks for?
[15:21] <ogra> but even better, just fix the bug that makes you use the wrong initramfs :)
[15:21] <lag_> Wrong initramfs?
[15:22] <lag_> Surely there are only one?
[15:22] <ogra> no, there is an uInitrd and an inird.img
[15:23] <ogra> update-initramfs has a bug that prevents updating the initramfs atm
[15:23] <rsalveti> ogra: do you create another initrd.img after the resize?
[15:23] <ogra> rsalveti, oem-config does
[15:23] <rsalveti> oh, ok
[15:23] <lag_> Sounds like userspace
[15:23] <lag_> ;)
[15:23] <ogra> at the end of the package removal you will see "running post installation trigger: initramfs-tools"
[15:24] <ogra> lag_, yeah, and its already fixed
[15:24] <ogra> lag_, edit update-initramfs, scan for flash-kernel in the code, remove the outer if statement that checks for kernel-img.conf
[15:24] <ogra> then run update-initramfs and all is as it should be
[15:25] <ogra> the fix is in the tree but i was waiting for the freeze to be dropped before i upload
[15:25] <lag_> So when will this find its way into the daily build?
[15:25] <ogra> tomorrow or with your next dist-upgrade
[15:27] <ogra> so now someone explain to me why my beagle doesnt load the boot.scr
[15:27] <GrueMaster> ogra: By default, my beagle won't either after having installed lucid.
[15:28] <ogra> GrueMaster, but if you hold down the user button it will
[15:28] <ogra> since that loads x.loader and u-boot from mmc which in turn should default to load boot.scr first before trying nand or anything else
[15:28] <GrueMaster> If you hold down the button, it loads Xloader & Uboot but for some reason still uses the environment in nand.
[15:29] <ogra> whsy dont i have a bug about that ?
[15:29] <GrueMaster> At least that has been my experience.
[15:29] <ogra> i need to adjust our u-boot to look for boot.scr in any case
[15:30] <GrueMaster> I mentioned it back when you were handrolling images, and you said it was normal.
[15:30] <ogra> file a bug, i'll see what i can do
[15:30] <GrueMaster> Will do.
[15:30] <ogra> i thought i had solved that before
[15:30] <ogra> GrueMaster, btw, all your isotracker entries are in progress still
[15:31] <GrueMaster> Yes, I know.  It takes a while to do all the testing and bug queries I do for a release.  There are some bugs that are still open that I need to add to the iso tracker entries.
[15:32] <ogra> well, pitti is in the process of releasing already
[15:33] <ogra> so having "passed/failed" filles first before you add bugs would be helpful
[15:33] <ogra> *filled
[15:33] <GrueMaster> Ok.
[15:33] <ogra> we'll likely hit the case more often that you test during our night and the release team does the release while you get up again
[15:34] <GrueMaster> We need to ensure I have something to test earlier then.  This image wasn't available until almost 11am my time.
[15:35] <ogra> blame asac
[15:35] <ogra> i was actually planning on having constantly two images per day from monday to today
[15:35] <ogra> to adjust the efl session settings package
[15:35]  * GrueMaster refuses to spew explicitives in a public channel.
[15:35] <ogra> but due to the launcher upgrade that didnt work out
[15:36] <GrueMaster> Don't we have some kind of release freeze policy?
[15:36] <ogra> yes
[15:37] <ogra> asac, asked me for an exception ... and i didnt get that this means to upgrade the while library stack alongside
[15:37] <ogra> so i approved :O
[15:37] <ogra> (so i guess blame me too ;) )
[15:37] <GrueMaster> You didn't know.  He knew better.
[15:38] <ogra> he said he told me, i couldnt remember
[15:38] <ogra> anyway, its over ...
[15:38] <ogra> i wont approve such requests on a monday before a milestone anymore
[15:39] <ogra> so in the future you should have enough images to test during the freeze
[15:39] <lag_> ogra: Talking about filing bugs ...
[15:39] <GrueMaster> I've marked omap4 as passed.  Not sure about the beagle image.  I'm tempted to mark it as fail, as running anything gets a lot of oom messages due to no swap.
[15:39] <ogra> GrueMaster, yeah
[15:40]  * ogra hasnt started the beagle test yet, i tried XM but that didnt change at all
[15:40] <ogra> (mmc is still in readonly)
[15:40] <lag_> ogra: XM isn't going to change - I don't think anyone is working on it
[15:40] <ogra> lag_, huh ?
[15:40] <lag_> ogra> (mmc is still in readonly) - Yes, where's my bug?
[15:41] <ogra> its hard to capture the error for you
[15:41] <ogra> want a bug without error message ?
[15:41] <lag_> Not really!
[15:41] <lag_> Lol
[15:41] <ogra> see :)
[15:42] <lag_> Do the best you can
[15:42] <lag_> Then I can start work
[15:42] <ogra> i will, but i know that rcn-ee has fixes for all issues so why not just review and take them ?
[15:43] <ogra> (or help him improving the code where it doesnt suit)
[15:43] <lag_> I have plans to - one step at a time
[15:43] <ogra> k
[15:43] <lag_> File me a bug :)
[15:44] <GrueMaster> ok, you're a bug.  :P
[15:44] <lag_> File != Call ;p
[15:44] <GrueMaster> oh.
[15:45] <lag_> :)
[15:45]  * GrueMaster needs more coffee.  Couldn't understand that aussie translation.
[15:46] <lag_> Genius! However do you come up with such witty remarks? ;)
[15:46] <ogra> lag_, with love and kisses (and kangaroos), bug 613855
[15:46] <ubot2> Launchpad bug 613855 in linux (Ubuntu) "omap3 beagle XM MMC card always comes up readonly (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/613855
[15:47] <lag_> ogra: See? That wasn't so difficult was it?
[15:47] <ogra> :P
[15:49] <ogra> oh, look !
[15:49] <ogra> http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/alpha-3/
[15:49] <ogra> seems we have a release !
[15:54] <rsalveti> hooray!
[15:58] <GrueMaster> ogra: Bug #613866
[15:58] <ubot2> Launchpad bug 613866 in u-boot-omap3 (Ubuntu) "u-boot loaded from SD should look to SD for boot.scr instead of using nand settings. (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/613866
[15:59] <lag_> So what happens when you guys boot XM?
[15:59] <lag_> I get a purple page with a (non-movable) mouse
[15:59]  * GrueMaster ENOHAVE
[15:59] <lag_> -ENOHAVE
[15:59] <GrueMaster> I don't have one (yet).
[16:00] <lag_> I gathered
[16:00] <lag_> :)
[16:00] <lag_> ogra: ?
[16:00] <rsalveti> lunch!
[16:00] <ogra> lag_, i dont get that far
[16:00] <lag_> @5pm?
[16:01] <lag_> What do you get?
[16:01] <lag_> A log?
[16:01] <ogra> no, a readonly MMC :)
[16:02] <lag_> Use serial and give me a log
[16:02] <ogra> it gets stuck right after trying to mount/umount the partionion
[16:03] <lag_> ogra: I get this: http://paste.ubuntu.com/473561/
[16:04] <ogra> why is modules.dep missing ?
[16:05] <ukleinek> haha, this is the reverse problem to bugs.debian.org/591768
[16:06] <GrueMaster> It looks like either the wrong uInitrd is being loaded.
[16:06] <GrueMaster> s/either//
[16:07] <lag_> I'm going to reflash with the _release_ version
[16:07] <ogra> GrueMaster, there is no wrong initrd wrt module versions
[16:07] <ogra> thats the strange part
[16:07] <GrueMaster> There is if you have a different kernel.
[16:07] <ogra> the modules should always be the same
[16:08] <ogra> how would that happen on our images ?
[16:08] <ogra> i'm indeed assuming lag_ uses our unmodified alpha3 image :)
[16:09] <GrueMaster> I used to get uImage files from the kernel devs to test without getting corresponding uInitrd files.
[16:09] <lag_> ogra: That would be your mistake
[16:10] <GrueMaster> See.  Kernel devs like to munge things up a lot.  :P
[16:10] <GrueMaster> Keeps us confused.
[16:10] <ogra> lag_, how would i be able to make it if there is only one kernel package ? :)
[16:10] <lag_> The kernel you use doesn't work with my monitor
[16:11] <lag_> I must have told you this 100 times :)
[16:11] <ogra> on the XM ?
[16:11]  * ogra hears that for the first time
[16:11] <lag_> No, Panda
[16:11] <lag_> XM doesn't work with my SDHC card
[16:11] <lag_> -110 error
[16:11] <ogra> why did you paste an XM dmesg ?
[16:12] <lag_> I have problems with both and am working on both at the same time
[16:12] <lag_> I can't use the kernel on either daily builds
[16:12] <ogra> thats confusing !
[16:13] <lag_> Welcome to my world
[16:13] <GrueMaster> I told you kernel dev's like to confuse us.
[16:13] <lag_> ;)
[16:13]  * ogra is confused 
[16:14] <ogra> in any case this XM boot doesnt show the -110 erro
[16:14] <ogra> r
[16:14] <GrueMaster> Then lag is (actually) ding his job.  :)
[16:14] <GrueMaster> s/ding/doing
[16:15] <GrueMaster> I think the -110 error is related to the SD class issue I was seeing on Beagle.
[16:16] <lag_> GrueMaster: ogra: bug 591941
[16:16] <ubot2> Launchpad bug 591941 in linux (Ubuntu Maverick) (and 1 other project) "SDHC card not recognized (affects: 2) (dups: 1) (heat: 20)" [High,In progress] https://launchpad.net/bugs/591941
[16:16] <ogra> lag_, on line 279 you start a new boot or what ?
[16:16] <GrueMaster> yep, that's the one.
[16:16] <ogra> (there is no techincally possible way that init-premount runs at that point)
[16:17] <lag_> Nope
[16:17] <lag_> Same boot
[16:18] <ogra> thats not possible
[16:18] <GrueMaster> Looks like a cut/paste overlap.
[16:19] <lag_> FATAL: Could not load /lib/modules/2.6.35-14-omap/modules.dep: No such file or directory
[16:19] <lag_> done.
[16:19] <lag_> Begin: Running /scripts/init-premount ... done.
[16:19] <lag_> From my console
[16:19] <lag_> I'm happy to run it again
[16:19] <GrueMaster> Lines 241-243.
[16:19] <ogra> things like loading binfmt or apparmor setup both happen after the rootfs was mounted, /scripts/init-premount doesnt exist in the rootfs, its only available inside the initramfs
[16:19] <GrueMaster> Very odd sequence.
[16:20] <lag_> I'll run it with the new image - wait one
[16:22]  * ogra really likes the panda image 
[16:22] <ogra> i'm getting in under 15min from pressing powerbutton to a usable system
[16:22] <ogra> and nearly 10 are cleanup stuff of oem-config
[16:25] <lag_> How do I make an initrd for my kernel?
[16:25] <GrueMaster> Yea, I was impressed by that.  My 16G SD card almost flies compared to the images at Sprint.
[16:26] <GrueMaster> lag_: update-initramfs -u <kver>
[16:26] <ogra> bah, my C4 fails with the -100 error too now
[16:26] <lag_> -110?
[16:26] <ogra> yeah
[16:26] <ogra> typo
[16:26] <lag_> Unlucky
[16:26] <lag_> ;)
[16:27] <ogra> well, i dont really care
[16:27] <ogra> XM is more important
[16:27] <ogra> i'm inclined to not add the Cx to the supported HW fo the netbook images
[16:27] <ogra> Cx users should just use rootstocked images with their low ram
[16:27] <ogra> but that indeed requires that we run properly on the XM
[16:41] <ogra> GrueMaster, looking at http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage#Beagleboard%20ARM%20Image%20Testing
[16:41] <ogra> gunzip -k ???
[16:41] <ogra> is that an undocumented goodie or do i just have a gunzip thats weird
[16:42] <GrueMaster> the -k keeps the gz file for zsync.
[16:42]  * ogra needs to use gunzip -c oldfile >newfile
[16:42] <GrueMaster> (might be different as I did a quick update from bunzip2 on the wiki.
[16:42] <ogra> GrueMaster, where is that documented ? unlike bunzip2 gunzip doesnt seem to have a -k
[16:42] <ogra> GrueMaster, right, thats what i mean
[16:42] <GrueMaster> I'll fix it.
[16:43] <ogra> thanks :)
[16:43] <ogra> if there is something like a -k option in gunzip it would be great though
[16:46] <OlivierN> hello all. Does anyone have a machine with two graphics cards ? (not one card with two heads)
[16:47] <GrueMaster> On arm?
[16:48] <OlivierN> So far I am able to configure X to get two separate desktops, /dev/fb0 goes on :0.0 and /dev/fb1 on :0.1. However I did not manage to get a sole big desktop
[16:49] <OlivierN> yep, on OMAP, two LCD panels
[16:49] <OlivierN> In my understanding, xrandr initially planned to support dual graphic cards on v1.3, but in effect this feature is apparently not implemented.
[16:53] <GrueMaster> ogra: fixed the wiki.
[16:53] <ogra> thanks
[16:54] <ogra> OlivierN, right, thats missing in xrandr and xinerama was obsoleted
[17:10] <OlivierN> ogra: thanks. So there is no solution for now. AFAIK, all other X extensions are proprietary (nVidia TwinView, ATI MergedFB, etc)
[17:10] <ogra> right
[17:10] <ogra> xrandr is very poor if it comes to framebuffer support
[17:18] <OlivierN> similarly, evdev input driver seems to always act on screen 0
[21:07] <NCommander> ogra_cmpc: ping?