=== ssweeny` is now known as ssweeny === nightwish is now known as wrayan === kentb is now known as kentb-out [03:48] We now return you to your regularly-scheduled multi-minute btfrs hissy fit. [04:09] RAOF: sorry you chose to inflict that pain upon yourself :P [04:10] Sarvatt: But it's soooooo shiny! [04:10] kind of amazing how long you've had btrfs problems actually [04:11] pre-nouveau getting merged upstream! [04:16] That hasn't been one continuous btrfs annoyance [04:17] It's generally alternated between hating btrfs and running ext4, wondering whether btfrs will be different this time [04:19] sounds like an abusive relationship === kloeri_ is now known as kloeri [07:31] * smb shuffles in [07:43] smb: plenty of space here, welcome :) [07:44] ppisati, Good morning. :) === fmasi_afk is now known as fmasi [08:05] * apw yawns slowly [08:14] * RAOF pours the bees from the pot. [08:15] RAOF, you are the man [08:15] * apw shows his age [08:15] RAOF, lush [08:15] * apw hopes he has covered it up [08:15] Bask in my self-inflicted pain: http://paste.ubuntu.com/5864165/ === Adri2000_ is now known as Adri2000 [08:30] heh btrfs, that is a good idea === ivoks_ is now known as ivoks [09:25] brb [10:26] * ppisati -> out for lunch === fmasi is now known as fmasi_lunch === cmagina-away is now known as cmagina === fmasi_lunch is now known as fmasi [13:27] jsalisbury, bouncing gomeisa for kernel update === kentb-out is now known as kentb [14:22] smb, ping [14:22] smoser, pong [14:22] https://bugs.launchpad.net/lansing/+bug/1199151 [14:22] smoser: Error: ubuntu bug 1199151 not found [14:22] could you build me a kernel with that ? i know i can build one too... [14:23] plan would be to test on a raring instance, as there'd be no easy way to get the kernel *onto* a saucy instance. [14:26] ah. never mind, smb. [14:26] smoser, huh? bit lost (was looking away for a second) [14:27] never mind. i subscribed you to that bug, but utlemming just reported it that the patch was in our kernel [14:27] Ah [14:49] apw, apply your ext4 patch and I'll upload this morning. there is enough good stuff on tip to warrant an upload [14:51] rtg pushed, do give it a good test === ghostcube_ is now known as ghostcube [15:05] ppisati, rebooting tangerine for kernel update [15:25] apw, Is it not possible to boot the mainline kernels on a Hyper-V host? Does the kernel need drivers that are included in Ubuntu and not Mainline? I'm referring to these Mainline kernels:http://kernel.ubuntu.com/~kernel-ppa/mainline/ [15:44] ppisati: Your ti-omap4 upload had a sad. [15:45] bjf: Well, technically yours, I suppose. :P [15:45] infinity: sad moment? :) [15:45] infinity: which one? [15:45] ppisati: quantal [15:45] ppisati: https://launchpadlibrarian.net/144713745/buildlog_ubuntu-quantal-armhf.linux-ti-omap4_3.5.0-228.41_FAILEDTOBUILD.txt.gz [15:46] Looks like merging the configs needed you to sort out some fallout. [15:46] http://wompwompwomp.com/ [15:47] Wow, someone forked sadtrombone.com [15:47] infinity: crap [15:48] infinity: wait a sec [15:48] apw, anything in particular I should do to test your ext4 patch ? [15:48] jsalisbury, a good question, i am not sure i can think of anything in the later ones ... for recent releases [15:48] I've booted it on an 8.8T file system [15:49] ppisati: Given the unlikeliness of having ath9k on omap4, the path of least resistance is probably just to revert that one config change from master in your merge. [15:49] rtg, i think if we can use it and not lose our filesystems [15:49] liek if you can build a kernel i am happy its not regressing [15:49] I'll do a build... [15:49] cking, CFQ vs deadline could be an MMC wearout thing [15:49] apw, cool, thanks [15:49] (i doubt it matters much in reality, but deadline might be minimally better here) [15:49] jsalisbury, the only thing they might not have is a valid hvp daemon, not sure how to handle that [15:50] ogra_, who knows [15:50] :) [15:50] apw, ok, thanks. I was wondering, so I know if a bisect can be done on Hyper-V using mainline kernels. [15:51] we would have to get signidicantly better merg [15:51] merging to have any obvious delta in writes per flash block [15:53] ogra_, i'm more concerned about the wear causes by excessive logging by unity8 at the mo [15:54] *caused [15:54] cking, thats a temporary thing :) [15:54] phonedations is aware ... we'll cuto down logging massively before release [15:55] ogra_, it's darn hard to make sensible measurements when some processes are telling us what's going on all the time [15:55] is there a way to shut it up? [15:55] oh, you complain about the processes themselves [15:55] hmm, not really ... what we plan to do for release is to quieten syslog as much as we can and to do the same for upstart [15:56] ogra_, well, run fatrace -c from / and you will see lots of happy processes writing away [15:56] but that wont prevent the processes themselves from talking to the logging entity [15:56] I guess I symlink it to /dev/null and I'm happy [15:57] symlink what to /dev/null ? [15:57] the various log files [15:57] ah, yeah, per logfile will work [15:58] just dont like the whole of /var/log ... some apps expect nodes there :) [16:01] * cking nods + sighs [16:10] bjf: how do i trigger a reupload? [16:11] bjf: lp1199276 [16:11] bug 1199276 [16:11] Launchpad bug 1199276 in Kernel SRU Workflow prepare-package "linux-ti-omap4: 3.5.0-228.41 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1199276 [16:12] ppisati, are you saying that you've made additional changes to your branch and you want me to pull that now ? [16:13] bjf: yep, the building was broken [16:13] bjf: https://launchpadlibrarian.net/144713745/buildlog_ubuntu-quantal-armhf.linux-ti-omap4_3.5.0-228.41_FAILEDTOBUILD.txt.gz [16:13] looking [16:16] ppisati, i'm looking at your branch. it has the same version and the history looks the same did you make a change and then just rebase it away? [16:17] bjf: i did an updateconfigs, then i 'git rebase -i HEAD~5', moved it before the new release [16:17] bjf: deleted the old tag, retagged, etc [16:18] ppisati, that ship has sailed, you can't do that [16:18] bjf: ok then, shall i start a new release&c? [16:18] ppisati, yes please [16:19] bjf: shall i change the version in the bug title too? [16:19] ppisati, yup === fmasi is now known as fmasi_afk [16:48] ppisati: It didn't need yet another ABI bump. [16:48] ppisati: 228.42 would have been fine. [16:48] i can fix that part [16:49] though it would be better if ppisati did it and built it [16:49] infinity: the new startnewrelease script now automagically bumps upload and ABI number [16:49] ppisati, yes, but you can still edit the changelog and back that out [16:50] bjf: well, if we do it blindly at every upload now, this is just one of them [16:51] * infinity shrugs. [16:51] The inflation isn't a big deal, it just seems silly for a kernel that no one could possibly have had installed. [16:53] ppisati, is your branch all ready? [16:54] bjf: one sec [16:55] (For the record, you could have reused the version too, if we'd deleted the old one and waited for it to get reaped) [16:55] infinity: that's what i did first [16:56] I think we proved this theory a few weeks ago. [16:56] ppisati: I know. [16:56] ppisati: But I wasn't looking when Brad chewed you out for that. :) [16:56] (Plus, sitting around waiting for LP to scrub all knowlege of the previous upload is annoying) [16:57] (And not worth the effort) [17:01] bjf: ready to go [17:01] ppisati, thanks [17:20] ppisati, uploaded [17:23] bjf: thanks [17:26] apw, just pushed unstable. could you review 83d2cc37d009ec5dfdc3bb05410677b3deba6c6c and make sure the call to ddebug_dyndbg_module_param_cb() is correct. [17:26] * apw looks [17:27] * rtg -> lunch [17:28] * Build armhf using gcc-4.7 [17:29] rtg: ^-- I thought we'd established that 3.10 was fine with gcc-4.8, and it was only the older kernels that needed older compilers? [17:29] At least, that's how I interpreted yesterday's discussion. [17:30] rtg, i think you need to check the all and return 0 if all is set as in pass_unknown_bootoptions() [17:30] rtg, infinity, apw: linux-ppc-3.10.0 uploaded for saucy [17:30] BenC: \o/ [17:30] for that new routine as it is expecting to only see the unknown ones, we don't want it erroring out there [17:30] infinity: If you could test ppc32/ppc64 for me when you get a chance, I'd appreciate it. I'm holding off on linux-meta until then [17:31] BenC: I'm nowhere near any such machines right now, but I might have a POWER7 in front of me sometime next week. [17:32] BenC: I'm not rebooting anything on my home network from across the ocean. [17:32] infinity: Hmm…well, I may just upload meta then and wait for the fallout :) [17:32] I don't expect any problems though [17:32] BenC: How big is your patchset against master these days? [17:33] BenC: If you're getting closer to mainline, I imagine POWER and old skool PowerPC will be fine. [17:33] infinity: about 10 sauce patches, 95% only affects my hardware though [17:33] * infinity nods. [17:33] Probably won't be problematic. Shame I can't test my home machines until August, though. [17:37] BenC: May as well just push the meta now, and let the chips fall where they may. [17:41] infinity: done [17:42] infinity: For reference, I didn't create a new repo, just a new saucy branch in meta git tree [17:50] BenC: Alright. [17:50] BenC: Your kernel was FTBFS anyway. :P [17:51] /bin/sh: 1: bc: not found [17:51] Odd new build-dep there [17:52] You might want to double-check against master. [17:52] It has that build-dep for sure, but you may be out of sync with others. [17:52] I added python-dev too [17:57] infinity, ppisati reported that gcc-4.8 would not compile a bootable kernel for a 3.10 omap, but that 4.7 was OK. its not clear if calxeda failed with gcc-4.8. [17:58] rtg: Hrm, in the discussion, I thought his omap mentions were 3.5/3.6, not 3.10 ... But I'm nowhere near hardware to test right now, so meh. [17:59] infinity, he's gone until Tuesday. [17:59] rtg: We can always revisit again later. It's not like reverting the compiler will hurt anything, until doko starts getting annoyed with everyone who won't let him remove old versions. ;) [18:01] indeed [18:01] BenC: Is 0.2 on its way, or are you testbuilding first out of paranoia? [18:11] BenC: Ahh, there it is. [19:02] BenC: And failed again. [19:05] BenC: Looks like char signedness breakage (which is all over the kernel source, sadly), and a driver that builds with -Werror by default. [19:06] Oh, or just building with -Werror=pointer-sign, which seems sane. [19:08] I wonder why that didn't blow up on ARM. [19:08] Maybe that driver's not built. === mfisch` is now known as mfisch === masACC is now known as maswan === BenC- is now known as BenC === cmagina is now known as cmagina-away === kentb is now known as kentb-out