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