[01:14] Counting is hard. Why did we go from -9.16 to -11.17? :P === ricmm_ is now known as ricmm [04:07] infinity, we're using a random number generator now [06:46] apw: mind testing a new -intel version on your gen3? won't fix the slow dash, but I'd like to hear if it works otherwise fine [07:15] moin === smb` is now known as smb [07:25] tjaalton, sure point me at it [07:25] ppisati, moin [07:25] morning [07:25] smb, moin [07:25] * smb lazily waves [07:26] and does not mind putting words in the wrong order [07:30] apw: pushed it to the staging ppa, I'll give the link once it's built [07:33] tjaalton, great, and ... i didn't see anything from Sarvatt yesterday on that test version for that machine, which was implodoing X when going to maps.google.com [07:35] (unless i missed it) [07:37] apw, Ok, so (as you undoubtedly already did) I checked the no-change rebuild of libvirt with the merged xen-4.3 and at least found a libxl connection driver which at least proves the headers and lib from libxen(-dev) are as expected. [07:38] smb, heh no it is far too early [07:38] Oh yeah not today but yesterday. :) [07:40] smb, so on the rdepends, it seems everything other than opennebula built, but i see that hasn't been built since like quantal, so i was going to try and rebuild it in the old place if you didn't alreayd know it is borked either way [07:40] apw, Hm, opennebula.... where did I read that recently...? [07:42] apw: hmm remind me of that one? the mesa revert causes that? [07:44] tjaalton, yeah the version you guys did for me which reverted something for gen3, this does amke it use 1.4 generally but starting chrome and navigating to 1.4 just implodes [07:45] hmm ok [07:50] apw: anyway, the new -intel is at https://launchpad.net/~canonical-x/+archive/x-staging/+build/5068918 [07:51] tjaalton, ok will try and get that tested shortly [07:52] great, thanks [07:52] ah I see bug 1233540 now [07:52] Launchpad bug 1233540 in xorg-server (Ubuntu) "X server core dumped seemingly when starting chromium" [High,Incomplete] https://launchpad.net/bugs/1233540 === fmasi_afk is now known as fmasi === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi [08:35] zequence-work, yo ... am just doing a lowlatency rebase to get you up to the latest in time for kernel freeze === fmasi is now known as fmasi_afk === ivoks_ is now known as ivoks === fmasi_afk is now known as fmasi [09:25] apw: Ah, right [09:25] apw: Is there a orig file for it? [09:34] zequence-work, a good point i will make one of those at the same time [09:34] zequence-work, i am just fixing something i broke :) [09:41] BenC, i am doing some maintenance on linux-ppc, and propose to rebase it for release for you at the saem time [09:44] Seems the dentist took away a piece of my brain, while removing my wisdom tooth today. All that appears in my head now is Bacardi. [09:44] zequence-work, heh ... nice ... i say go with the bacardi option myself [09:52] apw: Yep. Since I can't see any other options right now.. [09:52] So, it's not really an option [09:52] that is a fiar point, just go with it === _ruben_ is now known as _ruben [10:18] /b 9 [10:18] smb, so did you say you had had good test results with libvirt et al on your kit with new xen ? [10:30] Sorry got people and my landlord look at the flat [10:30] Err yes, a very quick test but yes [10:42] smb, ok ... in the queue, infinity is doing the do [10:42] apw, cool, thanks [10:42] now all you have to do is the same for precise :) [10:48] apw: feel free to close #1197451 [10:49] apw, precise? [10:51] Kaloz, i assume you are talking saucy here [10:51] (ie that boots saucy just fine) [10:56] apw: yup, since the resync with 3.11.2 [10:58] Kaloz, sweet closed off for saucy thanks [11:00] henrix, i've acked and applied that perl patch for you [11:00] dunno if you are respinning or just pulling that one fix onto master ... do as you feel fit obviosly [11:01] apw: thanks. bjf asked me to respin ;) [11:01] henrix, either works, go for it :) [11:23] smb: Out of curiosity, did you check this new Xen on an i386 userspace as well? There were some changes in i386/defines whose effect I couldn't quite divine. [11:24] infinity, There where but I don't think we use that file at all [11:25] infinity, At least the package still produces a hypervisor amd64 for i386 [11:25] smb: Yeah, I checked that in your PPA before I accepted. :P [11:25] infinity, Ba just a test [11:33] infinity, But yeah, as far as I read that it looked like that defines file would only have an effect when creating the control file from other files and that step only is done by debian. In fact they guard changes there with md5sums and the thing that runs then fails always because we have no special kernel helper thingy [11:34] (not that I could not fake a md5sum but decided I don't do that if not really needed) [11:37] smb: Fair enough. [11:42] apw: looks like your xserver crash should be fixed by the latest update [11:43] tjaalton, ta, sorry not had a chance to test that yet [11:43] apw: that's xserver update, so do the daily dance before testing chromium :) [11:44] tjaalton, heh [11:59] apw: hey, any news on https://bugs.launchpad.net/ubuntu/+source/git/+bug/1228148 ? [11:59] Launchpad bug 1228148 in git (Ubuntu) "git clone -q ends with "early EOF" error on large repositories" [Undecided,Confirmed] [12:36] Marex, we asked for an update for that machine to bring it somewhere more fixable, that is in progress as far as i know [12:38] Marex, though mid release run up is not the best time to try and get changes [12:38] apw: Works for me, thanks [12:42] apw: it's quite serious breakage tho, not being able to clone from the repo ... [12:42] apw: thanks for looking into it though [12:45] Marex, and only affects you if you don't use -q, so not hightly impacting [12:46] apw: OK, I will remember ubuntu as not fixing severe bugs, no problem [12:47] Marex, it isn't severe because it doens't affect the majority case common use model [12:48] yes it pisses you off, and it isn't at the top of my todo list because we [12:48] oh have a release to do, and kernel freeze on friday, silly me [12:48] and the people who need to do the upgrade are busy, oh prepping our world [12:49] to be pounded shitless by a ... release [12:49] it'd be nice if one would then be able to git clone the stuff you release ... but oh, yeah, roll out stuff, dont care if it's broken [12:49] Marex but one can clone it, as long as you don't use -q [12:50] it is not unavailable, it is unavable for one use case, which you can even fix by [12:50] that's wonderful ... as long as you don't use -q [12:50] git clone FOO [12:50] and then using the tool against a local FOO so you anr't even stopped from working [12:50] and therefore it is not my highesst priority for the very limited hours i have in every dau [12:50] befopre release [12:51] tell me where my analysis of the issue is wrong [12:53] apw: I keep wondering why you dont postpone the release ... do you focus on the actual deadline or on quality ? [12:53] postpone the release because we have a bug in a version of git from a previous release? [12:54] apw: is the current release not buggy too ? [12:54] apw: the patches were picked into master 2 weeks ago or so [12:54] quite possibly, but holding a release for a problem that only affects a neish use case [12:55] would make no sense what so ever, clearly it is not a common use case or someone would have found the issue much much sooner [12:55] there are probabally a 1000 such issues in any release, if you held to fix them all you would literally never release [12:56] apw: the issue was known since like 2009 unfortunatelly, it was reported but noone got around to push it [12:57] right but as it doens't affect the common case, us who use the thing didn't notice [12:57] and its is not like over half my commands every day are git ones, and it literally does not happen [12:57] now, that isn't to say it isn't worth fixing, it is [12:58] and once i have the machine on a level where it can be fixed i will be fixing it [13:00] apw: can you give some ETA at least ? [13:01] i would think we will get the machine upgraded within a couple of weeks [13:05] apw: ok, thanks [13:15] jjohansen, henrix, ppisati: rebooting tangerine for kernel update [13:15] rtg: ack [13:15] rtg: ack [13:16] rtg: i guess you rebooted tangerine [13:16] I guess [13:16] :) [13:17] ppisati, things looked pretty quiet. did I catch you in the middle of something ? [13:17] rtg: no, i was done === fmasi is now known as fmasi_afk [13:35] * henrix -> late lunch [15:39] what's the trick to build a kernel source package ? do_source_package=true fakeroot debian/rules binary-generic doesn't seem to work [15:45] caribou: binary-indep might work better. [15:45] jsalisbury, this hid revert, wasn't there a bluetooth component, or has that been eliminated [15:49] caribou, do you really want a kernel -source package ? [15:49] caribou, rather than a .dsc source pacakge ? [15:50] apw: I just want to be sure that the patch that I added is *indeed* in the package I built [15:59] infinity: ok, will try that [16:21] kees: Thanks for the info. Then I'll set an ACL to allow the user nagios to read it for the check. === kentb-out is now known as kentb [17:03] im writing a kernel module for the power management and I set up an irq to listen on a gpio pin for a toggle and I get the handler to fire but it only fires once, then it wont fire again. Do I have to set the irq up again if I want it to listen again? [17:52] * henrix -> EOD [19:52] sconklin, pushed patches to precise LBM. now builds against 3.2.0-55. I'll let you finish the packaging. [19:53] rtg: ack, thanks! I'll spin it now [20:13] rtg: uploaded [20:13] sconklin, ack [22:46] * rtg -> EOD