[08:08]  * apw yawns
[08:48] <apw> jxself, i would assume that 3.8.7 was based off the config for the 3.9.x series kernels in saucy, and 3.8.8 was based off the config fo ther 3.10.x series kernels in saucy (which we just switched to)
[08:48] <apw> jxself, and as i don't see that option in the current kernel it would likely default off
[08:49] <apw> one assumes they have gotten rid of the option there because it is always on
[08:49] <apw> a limitation on how the configs are made up for mainline builds
[09:58] <apw> jxself, i have put together a hack to use a slightly closer config (in theory) and the build from that should be popping out in the next hour; if you could see if that works any better
[13:13]  * henrix -> lunch
[13:22]  * ppisati goes out for a bit
[14:10] <Trevinho> Hello, since the upgrade to kernel 3.10 in saucy, I can't boot anymore using the radeon.audio=1 cmdline... 
[14:10] <Trevinho> What can help for debugging?
[14:10] <Trevinho> See bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1195687
[14:10] <ubot2`> Ubuntu bug 1195687 in linux (Ubuntu) "Init crashes with kernel 3.10.0 when using radeon.audio=1" [Undecided,New]
[14:43] <jxself> apw: Thank you for your work on 3.9.8. It appears that everything is back.
[15:04] <apachelogger> what would be the best way to get bug 1196556 fixed in raring?
[15:04] <ubot2`> Launchpad bug 1196556 in linux (Ubuntu Saucy) "Hot plug events not detected in i965" [Low,Triaged] https://launchpad.net/bugs/1196556
[15:06] <xnox> apachelogger: first needs to be fixed in saucy, then can be SRUed into raring.
[15:07] <apachelogger> I am not sure I'd want to do a kernel upload ^^
[16:32] <apw> apachelogger, has the fix even hit linus' tree yet ?
[16:32] <apw> i don't see it
[16:33] <apw> jsalisbury, perhaps one for monitoring ^^
[16:33] <jsalisbury> apw, ack
[16:35] <jsalisbury> apachelogger, I'll keep an eye out for that fix in Linus' tree.  I'll submit and SRU for Raring if it does'nt have the CC to stable
[16:35] <apw> jsalisbury, a star as always
[16:36] <jsalisbury> apw :-)
[16:38] <jsalisbury> apachelogger, If you have a chance, can you test the kernel from: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2013-07-01-saucy/
[16:53] <geekatcmu> Is there an "easy" way for me to find out if/when a particular patch (in this case, the 3.4 XFS accounting patch) was backported into the Precise kernels?
[17:03] <henrix> geekatcmu: option 1: look at precise git tree; option 2: you can try to use this fancy tool: http://o.cs.uvic.ca:20810/perl/cid.pl
[17:04] <geekatcmu> Thanks.
[17:05]  * geekatcmu makes a sad face
[17:06] <geekatcmu> http://o.cs.uvic.ca:20810/perl/cid.pl?cid=3948659e30808fbaa7673bbe89de2ae9769e20a7 doesn't seem to have been back-ported to the Precise kernel.
[17:06] <geekatcmu> Thanks, anyway!
[17:06] <geekatcmu> (it's part of the 3.4 series)
[17:34] <jxself> apw: That makes me wonder: How is the config generated? Is there some program or[D[D[D[D[D[D[D script or something I can reference?
[17:34] <jxself> Hmmm. Not sure why that came out like that.
[17:34] <apw> jxself, we take the config from the release we are targetting and 'make oldconfig' on it with the tree we are building
[17:35] <apw> jxself, though since the changes i make today it now use the nearest ubuntu version within that release
[17:35] <jxself> Ah, that's it? OK.
[21:06] <apachelogger> jsalisbury: will try thanks :)
[22:53] <geofft> Hm, can I bug people with enablement stack questions here? Or is #ubuntu-devel or something more appropriate? 
[22:56] <bjf> it's late in the day but it never hurts to ask
[22:57] <geofft> Basically, I think, 1) when are we expecting to see the -lts-raring graphics stack? (Is it intentional that the -lts-raring kernel exists already?) 
[22:58] <bjf> yes, it's intentional that the -lts-raring kernel exists already. as soon as raring released, the lts-raring kernel was ready
[22:58] <geofft> 2) Is there/will there be a corresponding -eol-upgrade package for the graphics stack as well as the kernel? 
[22:59] <geofft> 3) Is there a metapackage for the latest -lts-whatever? 
[22:59] <bjf> i'm not sure why there isn't a lts-raring graphics stack yet (i think there will be one). i'd expect a similar -eol-upgrade for graphics as kernel
[23:01] <geofft> Well, I don't see an xserver-xorg-lts-quantal-eol-upgrade, either, I think? 
[23:01] <bjf> all the graphics stack folks are in earlier timezones
[23:02] <geofft> OK, guess the end of the day in California is a poor time to ask questions :) 
[23:02] <bjf> are you PST timezone?
[23:03] <bjf> i should know the answers to all of that but i just don't, sorry
[23:04] <geofft> Yes, and also not a morning person unfortunately 
[23:05] <bjf> ack
[23:05] <bjf> so yes, the morning is a better time to reach folks or an email to the ubuntu kernel team mailing list
[23:06] <bjf> geofft, your PDX ?
[23:09] <bjf> slangasek, ^ you know the answers for the graphics stack?
[23:10] <slangasek> mmm, not precisely, sorry
[23:10] <bjf> s'ok, thought maybe
[23:10] <slangasek> I do expect the lts-raring graphics stack before 12.04.3, but I don't know if mlaankhorst has started work on it yet
[23:10] <bjf> ack
[23:10] <bjf> it's coming up quickly
[23:11] <slangasek> but what's eol-upgrade?  is that part of the revised plan ogasawara came up with after sabdfl pushed back on the "automatically upgrade users to the supported stack" question?
[23:12]  * slangasek doesn't know the details on that or where it's documented
[23:12] <bjf> i think it's so we don't leave people hanging on unsupported lts-hwe installs
[23:12] <bjf> "in the wiki"
[23:12] <slangasek> well, in fact the current plan is that people *will* be allowed by default to hang on them
[23:12] <slangasek> because sabdfl objected quite strongly to having them auto-upgraded to a kernel that might regress hardware support
[23:13] <slangasek> so instead they'll be notified when their kernel goes eol
[23:13] <bjf> yes but i thought we were going to provide a "automagic upgrade package" for folks that did want that (but i could have just made that up)
[23:13] <slangasek> but I don't know if there are meant to be additional metapackages in support of this
[23:13] <slangasek> maybe so, I don't know :)
[23:22] <geofft> bjf: SF/Bay Area, actually 
[23:23] <bjf> geofft, ack
[23:23] <geofft> slangasek: Yeah, there appear to be no docs about -eol-upgrade other than its own package description. 
[23:23] <slangasek> right... so you probably want to hit up the person who uploaded it :)
[23:24] <geofft> Hm, can you use the lts-raring kernel with an older graphics stack? Or is the use case overly-new headless servers or something? 
[23:24]  * bjf puts money down on who that was
[23:25] <bjf> geofft, you should be able to use it with an older graphics stack
[23:26] <slangasek> geofft: can you... yes.  Is it supported/validated... no.  The lts-raring kernel is meant to be used in conjunction with an lts-raring graphics stack, which may just not be packaged yet
[23:26] <geofft> sconklin, looks like. "* UBUNTU: Provide an EOL upgrade meta package" 
[23:26] <geofft> https://launchpad.net/ubuntu/+source/linux-meta-lts-quantal/3.5.0.32.39 
[23:27] <bjf> geofft, that's just the regular lts-quantal meta package
[23:27] <bjf> geofft, let me see who added that commit
[23:29] <bjf> geofft, rtg did the commit, he's out this week
[23:32] <bjf> geofft, in the a.m. ogasawara can give all the details
[23:32] <bjf> geofft, you missed her by about 2.5 hrs.
[23:32] <geofft> OK, I'll re-ask tomorrow morning. Thanks! 
[23:32] <bjf> but email is a "fine" thing for this