[00:00] <InSearchOf> plars, did this weeks meeting get canceled earlier?
[00:35] <plars> InSearchOf: no, it was this morning
[00:35] <plars> InSearchOf: on #ubuntu-meeting
[00:35] <InSearchOf> hmm... maybe there was a lot of them going on... is there an IRC log I can view?
[00:36] <InSearchOf> I need to up the scrollback buffer on xchat :-)
[00:37] <plars> InSearchOf: should be posted on the agenda page, but sometimes it takes a little while to get posted
[00:37] <InSearchOf> cool, thanks plars
[00:38] <plars> InSearchOf: one of the major things we discussed was moving to a wiki page for blueprint status tracking... err, actually updating the status on the blueprint, and using a script to generate the wiki page
[00:38] <InSearchOf> that would be sweet, I need to start looking at the blueprints again... and finally purchase a beagleboard as planned
[00:44] <InSearchOf> ubuntu-mobile?
[08:21] <lool> hi there
[08:29] <ogra> where ?
[09:12] <pat_> hi
[21:03] <NCommander> When two people dream the same dream, its a pointer error
[21:04] <dyfet> maybe it's being reference counted...
[21:13] <lool> ogra_: Around?
[21:13] <lool> ogra_: Did you ever use tools to manipulate the config of an uboot env part?
[21:15] <lool> Does someone have access to a /dev/mtd* device?
[21:15] <lool> I'd like to confirm that mtdN are char devices
[21:29] <NCommander> lool, I thought mtd* were block devices (although its very possible thats variable dependng on the underlying driver)
[21:29] <NCommander> lool, (and I can check on my B2.0 for you as soon as I'm off the phone)
[21:29] <lool> NCommander: mtdblockN are block devices
[21:30] <NCommander> lool, oh ...
[21:30] <lool> NCommander: I'd love if you could confirm for mtdN
[21:30] <lool> I think they are block devices as well, but you're in charge of clearing them with appropriate ioctls
[21:30] <NCommander> lool, its probably got to wait ~30 minutes, since I'm on the phone and my board is disconnected (and requires NFS root ATM, since my harddrive commited suidice)
[21:30] <lool> That's ok
[21:35] <NCommander> lool, qt4-x11 finished on RIMU
[21:35] <lool> COOL
[21:35] <lool> NCommander: So problem solved but we don't know why?  :-/
[21:35] <NCommander> lool, I think we just need to bump the build timeout on this package alone: http://paste.ubuntu.com/224914/
[21:36] <NCommander> (not a great solution, but I really don't want to start rewiring qt's build system)
[21:38] <lool> NCommander: Did you check how long the previous build time when compared to this one?
[21:38] <lool> is it a serious regression or just a small bump and we were lucky to build it so far?
[21:39] <beyossi> Ogra, i followed http://elinux.org/BeagleBoardUbuntu but for some reason it doesn't recognize any device for attaching to eth0. I have a belkins wifi usb dongle connected to my usb-hub (a long with the keyboard and mouce it didn't recognize as well). any idea how to debug it?
[21:55] <beyossi> anybody is familiar with the beagleboard?
[22:04] <NCommander> lool, ok, off the phone
[22:04] <NCommander> lool, what I thnk happened is the requirements for building with -fPIE simply got higher with gcc 4.4
[22:05] <lool> NCommander: That could be
[22:05] <NCommander> ogra did some benchmarks between 4.3 and 4.4 and I think he didn't see a huge difference
[22:05] <NCommander> lool, and QT4 is a massive package. Its similar to upstart w.r.t. to the size of its data files
[22:06] <NCommander> lool, it might be a regression in GCC then again, it might just be we were tethering on the edge before, and 4.4 simply pushed us over
[22:06] <lool> That's what doko's bug is about I believe
[22:06] <NCommander> which bug?
[22:07] <NCommander> lool, I'm pretty content in us bumping the build timeout time if its acceptable by you
[22:08] <NCommander> er, wait
[22:08] <lool> Well i'd like to know how the build times compare
[22:08] <NCommander> On the buildds, the build was axed 18 hours, 23 minutes, 50.2 seconds in
[22:09] <NCommander> The completed build took 20.3 hours
[22:10] <NCommander> (that was building with dpkg-buildpackage -b doing an arch specific upload as per how the buildds do it)
[22:11] <lool> How was the previous one?
[22:11] <NCommander> lool, the last one that fully completed?
[22:11] <lool> Yep
[22:12] <NCommander> 2009-06-22  (took 20 hours, 59 minutes, 26.7 seconds)
[22:12] <NCommander> so it took even longer than the build on rimu
[22:12] <lool> NCommander: Ok; I'm fine with bumping the build time in this case
[22:12] <NCommander> (that was 4.5.1, we're building 4.5.2, so its a different base version)
[22:14] <NCommander> lool, did we figure out what was causing the lzma breakage?
[22:14] <NCommander> or did that simply magically fix itself?
[22:16] <lool> NCommander: It seems it went away on mesa with no reason
[22:17] <NCommander> lool, and on kdelibs :-/
[22:17] <NCommander> (er kde4libs, kdelibs is a separate issue I need to fix)
[22:21] <lool> NCommander: Can you confirm on that mtd issue?
[22:21] <NCommander> lool, sure, give me a moment to hook up the B2 to my laptop and bring up NFS
[22:27] <NCommander> lool, how do I check if its a block or character device? (sorry, I'm drawing a mental blank on how :-/)
[22:34] <NCommander> lool, no MTD support in the FSL B2 kernel
[22:34] <lool> NCommander: file /dev/foo
[22:34] <NCommander> (I have no /dev/mtd*)
[22:35] <NCommander> and nothing in dmesg to suggest anything is detected and just failing to configure
[22:36] <NCommander> ^- lool
[22:36] <lool> Ok thanks
[22:39] <lool> It seems they are char
[22:50] <Sarvatt> cat /proc/devices?
[22:51] <lool> I don't have a system with them
[22:58] <Sarvatt> he would see the mtdchar module loaded too i'd imagine
[23:00] <lool> Sarvatt: indeed; as a char device; thanks!