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