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