[01:24] <rsalveti> amelim: did you change the x-loader binary to be the one compatible with overo?
[01:24] <rsalveti> just to be sure
[01:24] <rsalveti> it seems that no display is recognized, and that's why X can't start itself
[09:21] <hrw> morning
[09:21] <fairuz> hrw: morning
[10:07] <ogra> janimo, is your local sfdisk lucid ?
[10:07] <ogra> (note that the build server runs lucid, if you test such changes you should use a chroot)
[10:08] <dcordes_> morning
[10:14] <janimo> ogra, natty
[10:14] <ogra> yeah, thought so
[10:14] <ogra> it probably behaves differently between natty and lucid
[10:14] <ogra> but your partition table is created fine as the log shows
[10:15] <janimo> ogra, I have no idea of the builds systems internal operations so my patch was best effort and Works For Me
[10:15] <ogra> the error message about the missing table is normal
[10:15] <janimo> sure
[10:15] <ogra> you could just add an || true ;)
[10:15] <ogra> then set -e wont break on it
[10:20] <janimo> ogra, so on lucid sfdisk actually returns non-0 there?
[10:20] <ogra> no idea
[10:20] <janimo> I put an echo $? after that line and it was 0
[10:21] <janimo> if that is ocnfirmed than indeed || true is a workaround
[10:21] <ogra> i guess its simply that it outputs to stderr
[10:21] <janimo> but set -e does care about exit code only
[10:21] <ogra> the original line redirects both, stderr and stdout to null
[10:21] <janimo> can I log in and try a build on the server?
[10:21] <janimo> I cannot debug easily this way
[10:22] <ogra> i dont think you can if you arent in the cdimage team
[10:23] <janimo> ah, the team I woved to avoid being tricked into joining
[10:23] <janimo> ok
[10:23] <ogra> with a lucid chroot on an x86 machine you should have the same setup ... though note that builds dont run as root
[10:24] <janimo> ogra, does the script behave the same otherwise?
[10:24] <janimo> is it the same as inthe public bzr branch?
[10:26] <janimo> ogra, ah, I completely missed the >/dev/null thing. Even after being told before
[10:26] <janimo> that may be it
[10:26] <janimo> I coudl only test this by pasting bits of the script locally somehow that poart gt dropped
[10:26] <janimo> even if this is not the cause of the bug it still needs to be there for consistency
[10:28] <ogra> right
[10:28] <ogra> though i would suspect its the cause
[10:49] <ogra> janimo, for headless you will also need a line in debian-cd Makefile
[10:51] <ogra> in tools/boot/natty/common.sh too
[10:51] <ogra> (not that important since we dont use preseeding (yet))
[11:05] <lool> janimo, ogra: Ah you folks are reviewing the debian-cd changes?
[11:06] <ogra> lool, yes, i'm actually integrating them atm, needs a bunch of additional changes
[11:07] <lool> Ok; I was about to review it, but I see Michael applied, and then revertede
[11:07] <lool> And you seem to be reviewing
[11:07] <ogra> lool, oh, that change
[11:08] <ogra> yeah, he blindly applied and ran a testbuild
[11:08] <ogra> then reverted when it failed
[11:09] <ogra> lool, i'm on the headless image changes, not the partition alignment ones
[11:12] <lool> Oh actually I thought I had written parts of tools/boot/*/post-boot-armel+omap, but I did not
[11:12] <lool> There are some oddities there
[11:14] <ogra> lool, tell me
[11:15] <lool> it mixes bc and $(()) for computation, there is no check on data overlaps
[11:16] <ogra> h, te mix is likely because two persons worked on it
[11:16] <lool> This might give rounding errors:
[11:16] <lool> IMG_SIZE_BLOCKS="$((($BOOT_SIZE + $IMAGE_SIZE + 512 - 1) / 512))"
[11:16] <lool> It's ok because BOOT_SIZE is a multiple of 512, but would it not be, it would give a too small number
[11:16] <ogra> we never had any since lucid
[11:17] <ogra> the script is two releases old already, it has at least no blocker bugs ...
[11:17] <lool> In janimo's changes, I preferred 0x0C and ",,,-" instead of "C" and ",+" but that's cosmetic
[11:18] <ogra> well, janimo's changes fail atm
[11:18] <ogra> http://paste.ubuntu.com/577608/
[11:18] <ogra> i suspect its simply because the sfdisk output of stderr isnt redirected
[11:19] <lool> ah there is a bug
[11:19] <lool> Hmm
[11:20] <lool> ogra: This seems like fdisk failing to me
[11:20] <lool> Probably because it's confused
[11:20] <ogra> well, it creates the part table
[11:20] <ogra> which looks fine in the output
[11:21] <ogra> imho its just ignorable
[11:21] <lool> Yes, but it wont help your failure
[11:21] <lool> I'd rather keep the stderr/stdout output
[11:21] <ogra> and add || true ?
[11:21] <lool> You can pass -L to sfdisk to avoid some warnings
[11:21] <lool> ogra: I don't think sfdisk fails
[11:22] <ogra> but sfdisk is the only thing that changed
[11:22] <lool> Hmm I wonder if this is because it's a sparse file
[11:22] <ogra> yes
[11:23] <ogra> the error it spills about the missing partition table is normal
[11:23] <ogra> i really think its set -e thats stops it because there is output on stderr
[11:25] <lool> sfdisk doesn't fail for me here
[11:25] <lool> I tried running the commands locally
[11:25] <lool> I did get BLKRRPART: Ioctl() inappropré pour un périphérique
[11:26] <lool> with -L I avoid the warning: Warning: partition 1 does not end at a cylinder boundary
[11:26] <lool> ogra: set -e doesn't care about stderr
[11:27] <ogra> are you sure ? i know it doesnt in bash, how about dash ?
[11:27] <lool> VATSIZE gets set to 73696+
[11:27] <lool> that's bogus
[11:28] <lool> problem is that all commands are silenced, so you don't see the actual errors
[11:28] <lool> the problem is with the mkdosfs call failing
[11:29] <lool> It fails because VATSIZE is set to 73696+ instead of 73696 or so
[11:29] <ogra> hmm, yeah
[11:30] <lool> So the issues are a) fdisk output is in cylinders, that is not suited for partitions not aligned to cylinders as is the case here
[11:30] <lool> You can use fdisk -u to use sectors instead (but of course you need to multiply the size)
[11:31] <lool> b) all commands are run with stderr closed, which makes it hard to see failures or to debug
[11:31] <lool> c) mixture of sfdisk, parted, and fdisk
[11:31] <ogra> i wouldnt call c an issue :)
[11:32] <lool> This is definitely shooting yourself in the foot IMO
[11:32] <ogra> well, then everything would have to be sfdisk, the other two dont provide the needed felxibility
[11:33] <lool> ogra: Yes I'm sure about stderr and set -e  :-)  this is POSIX; search for errexit in the dash man page to get a description of how set -e works
[11:33] <janimo> lool, I put C instead of 0xC as that was in manpage examples too (it said those numbers are hex) but I agree it is cosmetic and I am fine either way
[11:33] <ogra> beyond that we dont know if the code works at all yet, it needs to be generic enough to not break the ROM code if you dd the image to a totally random SD
[11:33] <lool> janimo: I find it confusing if the part id is "12", so I prefer always prefixing hex with 0x
[11:34] <lool> So I've worked recently on the OMAP boot layout
[11:34] <lool> I can say that you're not checking for a possible error condition
[11:34] <lool> I don't have OMAP4, so I don't know whether OMAP4 ROMS are affected
[11:34] <lool> But OMAP3 ROMs are
[11:35] <lool> if the boot partition (first fat partition with bootable flag set => your first partition) has an odd number of sectors, the ROM can't read MLO from it and fails
[11:35] <lool> this is unrelated to placement
[11:35] <lool> Just size
[11:35] <lool> Basically size needs to be a multiple of 1KiB on OMAP3 for MLO to be picked up
[11:35] <ogra> i think the rom code looks at CHS though
[11:35] <lool> No
[11:35] <lool> It does not
[11:35] <ogra> hmm, i thought TI told me so
[11:36] <ogra> at least for omap3
[11:36] <lool> which is the other think I was going to suggest: if you don't care about support for older x-loader, then I wouldn't worry about 255/63; you could use 128/32 for instance, and that would avoid the warnings
[11:36] <lool> ogra: The only piece of code which I've found to care about the CHS was x-loader, and this was in old version of x-loader; in fact, it didn't really care about CHS
[11:37] <lool> It hardcoded the vfat partition to be at +63s (start at sector 63)
[11:37] <ogra> right
[11:37] <ogra> i thought the rom code had the same to find x-loader
[11:37] <lool> I don't think you have any x-loader in OMAP4, and you don't care since you're providing x-loader anyway
[11:37] <lool> I can say that the x-loader in maverick for instance was still broken
[11:37] <ogra> we indeed do have x-loader in omap4
[11:37] <lool> so for Linaro, I keep support for creating the boot partition at +63s just for maverick images
[11:38] <lool> So I'm pretty sure your images wont boot on OMAP3
[11:38] <ogra> and we do care about older ones since we provide upgrade capability nowadays
[11:38] <lool> I can't say for OMAP4, would love to know
[11:38] <ogra> or rather we do care about older partitioning with newer code
[11:39] <ogra> we dont care about old code with new partitioning
[11:39] <lool> aligning at 4 MiB means that the start sector is even, while the boot partition's start sector is odd (63) so it's guaranteed that your boot partition, if it goes up to the rootfs, will be an odd number of sectors
[11:39] <lool> ogra: What I'm saying is that it doesn't matter because you provide MLO in your images
[11:39] <lool> It's only relevant if you're providing a broken old NLO
[11:39] <lool> MLO
[11:39] <lool> but I would hope you have a new x-loader at this point
[11:39] <ogra> which is the case for pre-XM beagles
[11:40] <ogra> since they ship MLO in nand which is relevant for first boot
[11:40] <ogra> not so much afterwards anymore though
[11:43] <lool> ogra: But do they read MLO from SD or from NAND when SD is available?
[11:45] <lool> janimo: Didn't hear much from you, did the above make any sense?
[11:45] <ogra> they read MLO from nand, then read u-boot from nand and then try to read boot.scr from sd
[11:46] <lool> Then the question is which MLO version they have in NAND
[11:46] <lool> Well actually it doesn't matter
[11:46] <lool> since they read u-boot from NAND too
[11:46] <lool> and u-boot isn't affected
[11:48] <ogra> well, someone should merge it with the fixes and do a testbuild
[11:48] <ogra> i'm still concerned about having enough testing with random SD cards though
[11:49] <lool> I don't see how it relates
[11:49] <ogra> the existing code is proven to work with any SD card today, i dont want to lose that capability
[11:49] <ogra> because our image isnt aligned at all to the hardware
[11:50] <ogra> i dont trust the TI rom code until i have enough test data
[11:50] <lool> I don't understand what you mean
[11:50] <lool> like SanDisk versus Patriot etc.?
[11:50] <janimo> lool, yes the above makes sense
[11:50] <ogra> the image isnt aligned to any actual CHS value of the HW
[11:50] <janimo> I'll try to make some more tests locally
[11:51] <ogra> that only happens during jasper repartitioning
[11:51] <lool> ogra: Uh the hardware doesn't have any CHS
[11:51] <janimo> I did not look into changing fdisk parted to keep the diff small but apparently that is not enough
[11:51] <lool> ogra: CHS is a concept related to the format of the partition table, it dates from the 70s or so
[11:51] <ogra> i know
[11:51] <lool> but the SD card only sees reads and writes at various offsets
[11:51] <ogra> i'm talking about the rom code
[11:52] <ogra> i know you said above that it shouldnt care about CHS
[11:52] <ogra> but io really only trust that after i have seen testing data
[11:52] <janimo> the info above is more than I could find on various omap wikis
[11:52] <janimo> I was also under the impression it needs VFAT starting at 63 and that is 'somehow' cares about old style CHS
[11:52] <lool> janimo: I gathered it in my brain with a lot of pain over the last year  :-)  it's also in the linaro-image-tools' comments
[11:53] <lool> I wish we had some boot design documents for boards/SoCs
[11:53] <janimo> lool, actually the comments in the script still state that :)
[11:53] <ogra> the rom code is a super fragile pile of possible errors, that scares me, today we have a working concept which i dont want to risk
[11:53] <lool> janimo: You might be looking at the packaged version
[11:53] <lool> janimo: the one in bzr is very different
[11:53] <ogra> thats why i want to see test data before saying we make the new code our default
[11:53] <janimo> lool the public bzr branch
[11:53] <janimo> OMAP3 requires very specific CHS partitioning that can't easy be done with parted
[11:53] <janimo> so we'll use sfdisk to properly make the necessary partition layout
[11:54] <lool> janimo: yup, the main lp:linaro-image-tools one
[11:54] <janimo> by specific I assumed it meant the 255/63/10
[11:54] <lool> janimo: I don't think OMAP3 requires any CHS partitioning
[11:54] <lool> It's just these two limitations I mentioned
[11:54] <janimo> lool, not the image crate tool, the debian-cd scrip6t I modified has this comment
[11:54] <ogra> lool, linaro-image-tools operates on hardware (existing SD cards), no ?
[11:54] <lool> the documentation which states that you have to use 255/63 is just to allow creating the boot partition at +63s
[11:54] <lool> janimo: Oh ok
[11:55] <lool> janimo: Yeah, that's likely; it's what all the wikis say, but it's just completely wrong historical assumptions  :-)
[11:55] <lool> ogra: I don't understand the Q.
[11:55] <janimo> " the first primary partition must contain a FAT32 partition formatted with 255 heads and 63 sectors"
[11:55] <lool> ogra: you can write image files or straight to SD
[11:55] <janimo> omapzoom wiki
[11:55] <janimo> maybe not the most authoritative sources I admit
[11:55] <lool> janimo: Yeah, that's bullshit  :-)
[11:55] <janimo> but the only ones I could find
[11:55] <ogra> lool, files that work on every SD card i dd them to ?
[11:56] <lool> It's very hard to get the straight dope on how the SoCs boot like
[11:56] <janimo> ok
[11:56] <lool> ogra: Sure, well it wont boot an imx51 with an OMAP image
[11:56] <lool> :-)
[11:56] <ogra> lool, right, but it creates a partitioned img file i can dd ?
[11:57] <lool> ogra: Sure
[11:57] <lool> ogra: It can do that with --image-file
[11:57] <ogra> ah, i thought it needs an SD as target media
[11:57] <lool> or --image_file rather
[11:57] <lool> ogra: nope, you can create images and dd them later, or boot them in QEMU; give it a try!
[11:58] <ogra> i will once i have some spare time :)
[11:58] <ogra> i'm still fighting with the debian-cd changes for headless atm
[11:58] <ogra> janimo, we really need to get you access to antimony (cdimage) for future projects
[11:59] <janimo> ogra, ok
[11:59] <ogra> the private vs public stuff means that i have to add a good bunch of stuff
[11:59] <janimo> or I should just pick task which are not related to image building :)
[12:00] <ogra> and etc/config seems to actually be totally different
[12:00] <ogra> janimo, haha, yeah, indeed
[12:00] <lool> janimo: that's a sane choice  :-)
[12:00]  * ogra must admit that he actually never looks at the public branch
[12:02] <ogra> i have merged all your code now ... now on to the headdache bits ... make-web-indicies is a pain
[12:02] <ogra> hmm, i wasnt aware we have a preinstalled-mobile image
[12:03] <ogra> i dont think anyone has ever built that, why is there code
[12:03] <lool> Where's the other debian-cd branch?
[12:03] <ogra> AH
[12:03] <ogra> The Mobile Image allows you to unpack a preinstalled preview of the
[12:03] <ogra> Plasma Mobile workspace onto an SD card.
[12:03] <ogra> kde stuff :)
[12:04] <ogra> lool, its all on antimony
[12:04] <lool> I mean what other changes are being proposed?
[12:06] <janimo> ogra, indeed I saw a lot of confusing dead-looking code in the build scripts
[12:07] <ogra> lool, one sec
[12:53] <ogra_> janimo, livecd-rootfs changed, applied to trunk, packaged and uploaded
[12:53] <ogra_> i'll do a new test after it was published
[12:55] <janimo> ogra_, thanks
[12:55] <ogra_> i always forget if BuildLiveCD changes need lamont or if trhats automatically ... but we'll see
[13:28]  * ogra_ sighs about the slow publisher
[13:30] <apachelogger> rsalveti: seems your qt gles change is incomplete
[13:30] <apachelogger> p   libqt4-dev        Depends  libglu1-xorg-dev | libglu1-mesa-dev | libglu-dev
[13:32] <rsalveti> apachelogger: well, I believe it was properly changed for a previous revision
[13:32] <rsalveti> didn't check the current one
[13:32] <rsalveti> let me see
[13:32] <apachelogger> the ubuntu11 upload only features changes to opengl-dev
[13:33]  * apachelogger wonders why -dev should have any relationship with gl stuff actually
[13:34] <rsalveti> apachelogger: the original patch had libglu1-mesa-dev [!armel] | libglu-dev [!armel],
[13:35] <apachelogger> rsalveti: http://launchpadlibrarian.net/65213847/qt4-x11_4:4.7.1-0ubuntu10_4:4.7.1-0ubuntu11.diff.gz
[13:35] <apachelogger> only for qt4-opengl-dev
[13:38] <rsalveti> apachelogger: -dev and build-depends
[13:38] <apachelogger> then the upload is flawed
[13:38] <apachelogger> :S
[13:38] <rsalveti> apachelogger: why?
[13:40] <rsalveti> -dev is just to avoid installing the wrong headers and such
[13:40] <apachelogger> rsalveti: the first hunk of the ubuntu11 diff is build-deps the second hunk is -opengl-dev
[13:40] <rsalveti> and build-depends enough to build with the proper support
[13:40] <apachelogger> -dev however remained unchanged
[13:40] <apachelogger> or
[13:40] <apachelogger> maybe
[13:40]  * apachelogger might have been in a wrong chroot
[13:40] <rsalveti> qt4-x11_4.7.1-0ubuntu12 seems fine here
[13:40] <apachelogger> let me check again
[13:42] <apachelogger> oh
[13:43] <apachelogger> rsalveti: ok, my bad
[13:43]  * apachelogger now faces the question why kdelibs then installed glu as build-dep :S
[13:44] <rsalveti> kde needs further changes, not sure kdelibs
[13:44] <apachelogger> rsalveti: possibly not that many changes
[13:44] <apachelogger> libplasma links against libgl (due to a silly glapplet class, which is actually unmaintained...)
[13:45] <apachelogger> I think this causes runtime problems
[13:45] <rsalveti> apachelogger: I believe this was removed at trunk already
[13:45] <rsalveti> at least linaro was working on it
[13:46] <apachelogger> rsalveti: the glapplet?
[13:46] <rsalveti> apachelogger: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/46b3025245ee6b22cfa8d2a898756f5c075d822e
[13:47] <apachelogger> groovy
[13:47] <apachelogger> patchy patchy patchy :D
[13:47] <rsalveti> :D
[13:50] <ogra_> grmbl ... now the source is published but the binary isnt
[13:50]  * ogra_ hates the publisher
[14:33] <apachelogger> rsalveti: uploaded kde4libs with that patch
[14:34] <rsalveti> apachelogger: cool
[15:32]  * rsalveti lunch
[15:34] <sabayonuser2> hi has any one tried kubuntu mobile  with motorola charm
[15:44] <dcordes_> sabayonuser2: what's the CPU architecture ?
[15:46] <sabayonuser2> its an android phone so I guess it should be ARM
[15:46] <alf> rsalveti: https://bugs.launchpad.net/ubuntu-omap4-extras-graphics/+bug/732053
[15:46] <ubot2> Launchpad bug 732053 in ubuntu-omap4-extras-graphics "GLES2 drivers don't advertise the GL_OES_texture_npot extension" [Undecided,New]
[15:47] <rsalveti> alf: cool, will take a look
[15:48] <GrueMaster> sabayonuser2: Try the #kubuntu-mobile channel.  That's where they focus on that image.
[15:49] <dcordes_> sabayonuser2: the question is which arm version (what instruction set is supported)
[15:58] <Neko_> hey guys
[15:59] <dcordes_> sabayonuser2: you will first have to sort out what processor you have no matter what kind of image
[16:04] <amelim> rsalveti: In regards to the x-loader for the overo, I compiled the one found here and uploaded it as the MLO on the SD card git://www.sakoman.com/git/x-loader.git
[16:05] <amelim> same with the u-boot
[17:11] <rsalveti> amelim: you could just grab the package x-loader-omap3-overo
[18:34] <ogra> rsalveti, good question why we dont speak here :)
[18:34] <rsalveti> :-)
[18:34] <ogra> http://cdimage.ubuntu.com/ubuntu-headless/daily-preinstalled/20110309.1 should actually get an image now
[18:35] <rsalveti> awesome
[18:35] <rsalveti> will need a blog post after this
[18:35] <rsalveti> maybe today
[18:35] <rsalveti> something the arm community is waiting for months
[18:35] <ogra> as soon as we know it builds and boots :)
[18:35] <rsalveti> sure sure :-)
[18:35] <ogra> years :)
[18:35] <rsalveti> yeah
[18:35] <alf> rsalveti: ogra: I am considering using a natty image (replacing maverick) with the SDP (omap4). Would you recommend it?
[18:36] <ogra> alf, works, kind of
[18:36] <rsalveti> alf: keep same kernel
[18:36] <rsalveti> no proper x-loader support for sdp yet, so you should also use the one you're using now
[18:36] <rsalveti> but, give it a try
[18:37] <rsalveti> alf: you can also wait the headless image
[18:37] <ogra> whats the SDP ?
[18:37] <ogra> blaze ?
[18:37] <rsalveti> ogra: like blaze
[18:37] <rsalveti> but without that beautiful case
[18:37] <ogra> "like" ?
[18:37] <rsalveti> it's huge
[18:37] <ogra> ah
[18:37] <rsalveti> like old omap boards
[18:37] <rsalveti> alf: headless should be a very small image
[18:37] <rsalveti> alf: then you can install what ever you need
[18:38]  * alf shudders
[18:38] <rsalveti> don't know what you currently need :-)
[18:38] <alf> I 'd rather get it up front than wait for it to install :)
[18:40] <alf> rsalveti: ogra: I 'll try it (tomorrow) and let you know how it goes
[18:40] <alf> thanks
[18:40] <rsalveti> cool
[18:40] <GrueMaster> alf: I have the natty alpha 3 image running on my blaze, using the x-loader & u-boot.bin from http://people.canonical.com/~rsalveti/maverick/blaze/
[18:40] <ogra> take the alpha
[18:41] <alf> GrueMaster: ogra: nice, thanks
[18:42] <ogra> grmpf, still something missing it seems
[18:43] <GrueMaster> I don't think the publisher knows how to handle .raw files.
[18:44] <ogra> there are no raw files this time
[18:45] <ogra> and the publisher never gets to see a raw file
[18:47] <ScottK> janimo: Why did you still build Qt with gc4.4 on armel?  I thought the gcc4.5 fix was in?
[18:47]  * ogra fires off a full build, somehow i lost my rootfs
[18:49]  * ogra hopes http://cdimage.ubuntu.com/ubuntu-headless/daily-preinstalled/...9.2 will work now
[18:55] <janimo> ScottK, the Qt build started before the gcc build had finished
[18:55] <ScottK> janimo: Ah.  Makes sense.  Are you going to upload it again once the build is done?
[18:56] <janimo> but more importantly to have a 4.7.2 built with a known working gcc, in case something is weird we know whether to look for the issue in Qt or gcc
[18:56] <janimo> ScottK, if no other Kubuntu patches are queued we will do an upload
[18:57] <janimo> although I'd rather let people with more Qt packaging experience do the next upload. There is a 7Mb patch now in debian/ whih I think was not meant to be there
[18:57] <janimo> was noticed by cnd yesterday
[18:58] <janimo> ScottK, so hopefully we'll see whether the neon/smp issues are cleared with the new 2.4.7 build and then next upload should switch back to 4.5
[18:58] <ScottK> OK.
[18:59] <ScottK> Riddell is the best one to do it, but he's at a conference this week.
[18:59] <ScottK> Qt build system is funky, so the patch doesn't suprise me.
[19:01] <janimo> ScottK, I meant to drop the thumb build fix patch as the membarrier one is a superset of that but gave up because of a few faild patch attempts.
[19:01] <janimo> so they now stack
[19:02] <ScottK> That works.  That's one of the primary use cases for quilt (stacked patches)
[19:05]  * ogra always thought quilt was something to hide your bits 
[19:37] <ogra> janimo, GrueMaster, rsalveti http://cdimage.ubuntu.com/ubuntu-headless/daily-preinstalled/20110309.2/
[19:37] <ogra> happy playing :)
[19:38] <rsalveti> ogra: awesome
[19:38] <janimo> ogra, wonder why omap3 is 8Mb larger? Any idea?
[19:38] <janimo> ogra, indeed, you may as well have had this spec assigned to you
[19:38] <janimo> no way I could have made that patch work without tweals without access to the servers
[19:38] <janimo> :)
[19:38] <ogra> janimo, i would have postponed it without your preparation
[19:39] <janimo> ogra, ah, good then
[19:39] <ogra> the changes i had to do were a lot last thanks to that
[19:39] <ogra> s/last/less/
[19:40] <ogra> GrueMaster, happy with the name ?
[19:41] <GrueMaster> Works for me.
[19:41] <ogra> lets just hope we never get a chicken arch ;)
[19:42] <GrueMaster> aww.
[19:43] <rsalveti> :-)
[19:53]  * ogra fixes A2 mentioning ...
[19:55] <ogra> hmm, now to find a time when to build them from crontab
[19:56] <janimo> right after/before the netbook images?
[19:56] <ogra> no, right after we have kubuntu
[19:56] <ogra> right before kubuntu-mobile
[19:56] <ogra> ah, no, thats live
[19:57] <ogra> preinstalled is after kubuntu actually
[19:57] <ogra> 7me puts it on 23:45 UTC
[19:58] <GrueMaster> Too bad we can't use them as a base for ubuntu/kubuntu preinstalled images.  Seems to me we are duplicating some effort as all of these images share the same base.
[20:00] <ogra> how would you solve that ?
[20:01] <ogra> the headless image is a good testbase for debconf based oem-config
[20:02] <ogra> gah
[20:02] <ogra> 23:45 might not be a good idea
[20:03] <ogra> the images will always be a day behind
[20:54] <GrueMaster> Well, ubuntu-preinstalled-headless boots past jasper.  But that's it.  No oem-config, no serial terminal.  Just a console login with a hostname of sycamore (yea, that's another bug).
[20:54] <GrueMaster> But it is a step in the right direction.
[20:54] <ogra> did you check all consoles ?
[20:54] <ogra> oem-config might come up at an unexpected one
[20:55] <ogra> i'm not sure the server team tests oem-config server installs
[20:55] <GrueMaster> yep.  login in f1-f6, nothing beyond that.
[20:55] <ogra> bad
[20:55] <GrueMaster> And serial looks the same as it does on standard images.
[20:56] <ogra> yes
[20:56] <ogra> i mentioned that before
[20:56] <ogra> we dont have code that switches the cmdline between images yet
[20:56] <ogra> it uses the same code netbook uses atm
[20:57] <ogra> no oem-äconfig is indeed bad
[20:57] <ogra> i see it in the manifest
[20:57] <ogra> so i wonder why it doesnt start
[20:57] <ogra> can you check if /var/lib/oem-config/run exists so we can exclude jasper from being bad
[20:59] <GrueMaster> Yea, it's there.
[20:59] <GrueMaster> I'll add a test user so I can at least log in.
[21:03] <ogra> or a root pw :)
[21:04] <ogra> might be that the cmdline version of ubiquity-dm is just broken
[21:04] <amelim> rsalveti, GrueMaster: I'm able to boot on the Overo using Alpha 3, an overo u-boot I compiled earlier, and x-loader-omap3-overo
[21:04] <amelim> Thanks for the assist
[21:04] <GrueMaster> amelim: Cool!
[21:06] <GrueMaster> Grr.  Need to get video to not suck.  Mainly blame my HDMI switch for autoswitching to a different system on reboot.
[21:09] <GrueMaster> Ok, logging in as root (after mucking with the passwd) I can launch oem-config with "start oem-config", so it must be something in upstart or init.
[21:10] <GrueMaster> Also, didn't ask for system name.  Odd.
[21:10] <GrueMaster> Oh, nevermind.  Did the network time update first.
[21:18] <amelim> :/ Now I have to figure out why my USB peripherals aren't working...
[21:18] <amelim> They function fine on the same hardware setup during a boot of the preflashed angstrom image
[21:28] <rsalveti> amelim: cool