[05:46] <micahg> hi, does DEB_BUILD_ARCH = armel for the native builders?
[08:02] <hrw> morning
[09:59] <lool> micahg: Yes; but it's usually a bad idea to check this
[11:09] <StaRetji> is there a link for geexbox image for arm platform?
[11:53] <ogra> looking at the u-boot packaging i now understand why lool didnt want to do the package split
[11:53] <ogra> sigh
[11:56] <ogra> no compat file, no build deps, debian/rules looks horrid ...
[11:57] <ogra> why cant people just use a proper build system instead of making up debian/rules by hand
[12:04] <lool> ogra: I actually committed an u-boot-tools package in the Debian git repo this morning
[12:04] <ogra> oh, cool
[12:05] <ogra> this rules file is just painful
[12:09] <ogra> lool, any ETA when that will be in debian (i need it asap so i'm pondering to add it as patch for ubuntu)
[13:40] <apw> GrueMaster, can you remember what failed in your testing of omap from natty master
[13:53] <micahg> lool: what's the proper way to check if something is an arm build vs not arm?
[13:57] <hrw> micahg: 'arm build' as 'build on arm' or as 'build for arm'?
[13:57] <micahg> hrw: build on arm
[13:58] <hrw> 'uname -m' may be but debian packagers will want to kill you for it probably
[13:59] <micahg> right, I was looking at DEB_BUILD_ARCH, but apparently, that's not the best way?
[14:03] <hrw> micahg: why you need check?
[14:04] <micahg> hrw: --enable-thumb2 fails the firefox build on non-armel builds
[14:04] <hrw> ah
[14:05] <hrw> rules2:  ifneq (,$(findstring $(DEB_TARGET_ARCH),armel hppa ia64 sparc))
[14:05] <hrw> micahg: so use DEB_TARGET_ARCH check
[14:06] <hrw> DEB_BUILD_ARCH = amd64 DEB_TARGET_ARCH = armel is 100% proper btw
[14:06]  * micahg is getting DEB_TARGET_ARCH not supported on maverick
[14:07] <hrw> let me check how gcc do that
[14:07] <lool> micahg: It's uncommon to check the architecture of the buildd
[14:07] <lool> micahg: Usually you test what you're building /for/
[14:08] <lool> DEB_HOST_ARCH is the Debian architecture of the machine the package will run on
[14:08] <hrw> rules.defs:  TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2>/dev/null)
[14:08] <hrw> rules.defs:DEB_TARGET_ARCH              ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH)
[14:08] <hrw> ops
[14:08] <lool> micahg: It would also be best to test the GNU CPU or something similar rather than the Debian architecture name; for instance the Debian armhf port is very similar to armel, but wont be covered by your test
[14:09] <hrw> sorry - it is done by different way in gcc
[14:10] <lool> micahg: Perhaps you could explain your specific problem?  I'm not sure I can comment on which var you should use, as you only asked about native builds but I might have missed when you explained what you're building
[14:10] <lool> hrw: The packages like gcc which have the concept of a target architecture are fairly rare
[14:10] <micahg> lool: well, I need to add a build option to arm only for firefox
[14:11] <lool> micahg: Right, that's a good example of a case where you'd test DEB_HOST_ARCH, and *not* DEB_BUILD_ARCH
[14:11] <lool> micahg: The main difference is when cross-compiling; when cross-compiling, DEB_BUILD_ARCH might be amd64 while DEB_HOST_ARCH is still armel
[14:12] <micahg> ah, so HOST_ARCH is the right one, ok, that's good to know for the future
[14:18] <micahg> thanks lool
[14:27] <janimo_> micahg, I think it's a simpler change to not check at all and let ff configure drop the option if it is not suitable for the current arch
[14:45] <micahg> janimo: I tried with it on for amd64 and the build failed
[14:47] <janimo> micahg, did it pass march arm to gcc?
[14:47] <lool> micahg: Just saw your firefox changes; would you mind if we discussed these for a sec?
[14:48] <micahg> lool: actually, I'm about to catch a bug, can we chat in a few hours?
[14:48] <micahg> *bus
[14:48] <lool> micahg: Sure; I will send you an email
[14:48] <micahg> janimo: I have to check the build log
[14:48] <janimo> lool, you mean the change in the latest upload or something else?
[14:48] <micahg> lool: thanks
[14:48] <lool> janimo: Yes, the THUMB2 one
[14:49] <janimo> lool, I suggested that one to micahg to fix the FTBFS. Tested on a panda before that.
[14:49] <janimo> the details may need to be done differently but I think that flag needs to be passed
[14:50] <lool> janimo: Yup; do you want to be Cc:ed?
[14:50] <janimo> lool, sure
[14:50] <lool> Hmm apt-cache showsrc janimo wont give me your email address
[14:50] <janimo> jani at ubuntu.com
[14:51]  * lool <- tired
[14:51] <lool> janimo: thanks
[14:59] <ogra> lool, is there any ETA for the debian u-boot upload or do we need to add the package split as ubuntu patch to get it in this week ?
[14:59] <ogra> (i think you disconnected above when i asked before)
[15:08] <lool> ogra: I've contacted Clint this morning to ask him to review these changes; they will hit Debian NEW in any case, so that will probably take some time; however, it wouldn't be too bad to copy the NEW package in Ubuntu
[15:09] <ogra> lool, do you get any notification you could forward if that happens ?
[15:12] <ogra> (i mean if it hits NEW, I'll care for teh sync requests etc)
[15:54] <lool> ogra: Unfortunately, one can't sync from NEW; if I'm doing the upload, I'll tell you once it's done
[15:54] <ogra> thanks
[15:58] <GrueMaster> Morning (barely).
[16:00] <GrueMaster> ogra: rsalveti:  apw: The issues I saw with the previous omap kernel prior to the break was that it literally didn't boot.  I couldn't get any feedback past u-boot loading the kernel.  Not even output from earlyprintk.
[16:02] <GrueMaster> I'm installing the new kernel now.
[16:10] <rsalveti> GrueMaster: yeah, I'll also try it here, and then try to fix it if it doesn't work
[16:11] <GrueMaster> Hmm.  Currently, it appears to be stuck on installing the linux-headers package.
[16:13] <apw> installing things in general is slow i think if you have the older dpkg
[16:13] <rsalveti> doesn't seems to boot, will now debug to see why
[16:13] <GrueMaster> Looks like I was getting a segfault loop of some sort.  Rebooting.
[16:14] <apw> rsalveti, thanks
[16:14] <apw> rsalveti, are u gettting any console output at all ?
[16:15] <rsalveti> apw: nops
[16:15] <apw> rsalveti, that sound fun to debug
[16:16] <rsalveti> apw: :-)
[16:16] <ogra> sounds like an issue with the console driver
[16:17] <ogra> do you have a monitor attached or do you try purely with serial ?
[16:17] <rsalveti> hm, ok, got something with earlyprintk
[16:26] <davidm> folks, the weather report for Dallas is cold next week Daytime 8.3C and nighttime -2.77  Colder then usual around here
[16:26] <davidm> For some of you that is warmer then you are at but for us it's cold
[16:28] <rsalveti> ouch, very cold for me hehe
[16:28] <rsalveti> it's around 30C everyday around here
[16:28] <rsalveti> good to know
[16:29] <GrueMaster> I vote we relocate to Sao Paulo.
[16:29] <rsalveti> hehe :-)
[16:29] <ogra> at least i wont catch a cold
[16:30] <ogra> we have constantly around -3°C here (day and night)
[16:34] <rsalveti> ogra: apw: GrueMaster: ok, did boot, you now need to use ttyO2 instead of ttyS2, like panda
[16:34] <rsalveti> because of the newer console driver
[16:35] <ogra> awesome
[16:35] <rsalveti> but I'm now getting tons of mmc i/o errors
[16:35] <rsalveti> probably a different issue, more debugging
[16:35] <GrueMaster> I had tried that when I tried the older kernel.
[16:35] <apw> rsalveti, sounds good!
[16:35] <rsalveti> apw: will test it more around here, and compare the config with linaro's one
[16:35] <apw> GrueMaster, the kernel he is testing is two -rc's newer than the one you tested before xmas
[16:36] <GrueMaster> I know.
[16:36] <GrueMaster> Just saying that I had tried both serial port settings.
[16:38] <apw> GrueMaster, good to know, as that means things have improved by osmosis
[16:41] <rsalveti> apw: ogra: GrueMaster: full maverick desktop up and running
[16:41] <rsalveti> rebooted and now I didn't get any i/o error
[16:42]  * rsalveti trying again
[16:42] <ogra> wohoo
[16:42] <ogra> apw, so can we get omap3 back ?
[16:42] <rsalveti> no calltrace during the bootlog
[16:42] <rsalveti> I believe this could be a good start
[16:42] <rsalveti> then we can just improve over the time, with more testing and etc
[16:43] <ogra> yeah
[16:43] <rsalveti> at least I believe it's good enough to get images
[16:45] <apw> rsalveti, did you say that you have booted this one successfully ?
[16:45] <ogra> yes he did :)
[16:45] <rsalveti> apw: yup, 2 times
[16:45] <apw> GrueMaster, does it boot for you too ?
[16:45] <ogra> who cares about GrueMaster :P
[16:45] <rsalveti> let me know try with a normal beagle
[16:45] <rsalveti> tried with a beagle-xM
[16:45] <rsalveti> *now
[16:45] <GrueMaster> I'm having other non-kernel related issues atm.  Will try again shortly.
[16:45] <ogra> he always manages to break even the super solid things ;)
[16:46] <GrueMaster> It's my job, that's what I do.
[16:46] <GrueMaster> I was hell with my toys.
[16:46] <ogra> lol
[16:47] <rsalveti> haha
[16:48] <apw> ogra, ok tehcnically i can get this renabled yes, so you are going to use this kernel not the linaro in your images, thats the decision
[16:49] <apw> and your team is going to sign up to keeping it tested and working
[16:49] <ogra> yes
[16:49] <ogra> and yes
[16:49] <rsalveti> :-)
[16:50] <GrueMaster> bring it, big guy.
[16:52] <GrueMaster> rsalveti: Did your patch for the serial port error on XM ever get integrated into the maverick kernel?
[16:52] <ogra> i think i saw some noise about it this week
[16:52] <rsalveti> GrueMaster: it's commited already I believe
[16:52] <rsalveti> let me check again
[16:54] <ogra> yup, mail says "applied"
[16:55] <GrueMaster> ok, haven't seen it in proposed yet.
[16:55] <ogra> not uploaded
[16:55] <apw> yeah -proposed is somewhat behind Fix Committed over this xmas perios
[16:55] <rsalveti> not uploaded, it's commited at the master-next
[16:55] <apw> period
[16:56] <rsalveti> ogra: apw: GrueMaster: ok, also working fine at my beagle c4
[16:56] <rsalveti> so it seems to be good enough
[16:56] <ogra> yay
[16:57] <apw> ogra, so we are saying beagle is the target for the omap kernel
[16:57] <ogra> apw, XM
[16:57] <rsalveti> apw: yep, xM will be our main use case
[16:57] <rsalveti> as it's now quite popular
[16:57] <rsalveti> and faster than a normal beagle
[16:57] <apw> so the acceptance criteria for that omap kernel is 'works on Beagle XM'
[16:58] <ogra> ++
[17:00] <rsalveti> yup
[17:04] <loafhead> MADISON, Wis. - Madison police are looking for a burglar who gave back a bottle of tequila after the homeowner hit him in the head.
[17:04] <loafhead> oops
[17:04] <loafhead> wrong window ;)
[17:27] <rsalveti> apw: the config seems fine comparing with the older one from maverick and with linaro's one
[17:28] <apw> rsalveti, thanks for the confirmation
[20:52] <GrueMaster> My 8G Class 10 SD cards finally came in.  Woohoo!
[20:53] <rsalveti> luck bastard
[20:58] <armin76> 8g class= nice, new class? :D
[20:59] <ogra> class 10 isnt that new
[20:59] <ogra> rsalveti, do you need any? i can buy them at the discounter and bring you some to the rally
[21:00] <rsalveti> ogra: would be good to have, I have none around
[21:00] <rsalveti> ogra: how much it cost usually around there?
[21:00] <ogra> i'll have to check, i'll just bring a few, if you dont want them (or they are to expensive) i'll take them back again
[21:01] <rsalveti> ogra: cool, would like at least 2 :-)
[21:01] <ogra> ok
[21:01] <rsalveti> np, just to know, here the problem is that I can't find them easily
[21:01] <rsalveti> or without spending too much money
[21:01] <GrueMaster> I bought 2 8G for just under $30.  Last cycle, they were $45 each.
[21:02] <rsalveti> nice, good price
[21:02] <GrueMaster> amazon.com