[00:00] <infinity> Oh.  Or maybe the current trunk depends on something from a newer ubuntu-dev-tools.
[00:00] <infinity> Developers running precise.  Crazy talk.
[00:00] <bjf> stable kernel folks are allowed
[00:00] <bjf> we actually support lts
[00:01] <infinity> I run both, to be fair.
[00:01] <infinity> Just that my laptop is raring.
[00:01] <bjf> i can try raring if that makes a diff (i also run multiple)
[00:01] <infinity> And all my other machines are precise.
[00:01] <bjf> same here
[00:01] <infinity> Well, it works here on raring.
[00:01] <infinity> YMMV.
[00:01] <bjf> can't hurt to try ...
[00:01] <infinity> Anyhow, if it doesn't work for some reason, I'll just copy it to a security PPA and be done with it.
[00:02] <infinity> Since I do have access to those.
[00:03] <bjf> nope, same error
[00:03] <infinity> It could just be that you don't have ubuntu-dev-tools installed...?
[00:03] <infinity> At least, I assume that's where that import is from.
[00:03] <bjf> trying
[00:04] <bjf> infinity, that seems to have made a diff
[00:05] <bjf> infinity, it thinks it did it
[00:05] <infinity> Well, we'll know in a minute or two.
[00:05] <infinity> copies are async.
[00:05] <infinity> Yeahp, looks good.
[00:05] <bjf> i see a second one in the ppa
[00:06]  * infinity scores those up.
[00:06] <infinity> You should be able to delete the oopsed quantal one.
[00:06] <bjf> infinity, the signed one is probably in the same situation
[00:06] <infinity> The signed one was uploaded to the archive, not the PPA.
[00:06] <bjf> so we just leave it
[00:06] <bjf> ?
[00:06] <infinity> I've got that covered, yeah.
[00:07] <bjf> ok, i'm backing away, let me know if i need to do anything else
[00:07] <infinity> ;)
[00:07] <infinity> Other than prodding people for rebases, I think we're good now.
[00:08] <infinity> Is this already fixed in raring?
[00:10] <bjf> it had not hit linus' tree the last i looked
[00:10] <bjf> i mentioned it to rtg, i'm not sure what his plan is/was
[00:11] <bjf> let me look at our tree
[00:12] <bjf> infinity, it's on our master-next
[00:56] <infinity> bjf: Say, not to nitpick, since this has been wrong for a few releases now, but why do the linux-signed changelogs say "precise"? :)
[00:56] <infinity> bjf: No point fixing it for this upload, but someone might want to get it right on the next.
[00:57] <infinity> https://launchpad.net/ubuntu/+source/linux-signed/3.5.0-24.37
[00:57] <infinity> https://launchpad.net/ubuntu/+source/linux-signed/3.5.0-25.38
[00:57] <infinity> Etc.
[00:57] <infinity> Oops. :)
[00:57] <bjf> infinity, looking
[00:57] <infinity> bjf: I assume someone just made it precise somewhere in the distant past, and automated tooling has kept it broken. :)
[00:58] <infinity> bjf: And since you upload to the PPA in a targetted fashion, and I copy to the archive in a similarly targetted way, it's never actually mattered.
[00:59] <infinity> bjf: Anyhow.  No big deal for this round, just entertaining.
[00:59] <bjf> infinity, yup, looks like i may have been the one to "break" it in jan.
[00:59] <infinity> Heh.
[00:59] <infinity> Then you can fix it in a week or two. :)
[00:59] <bjf> infinity, tomorrow most likely since this is the start of a cycle
[01:01] <infinity> bjf: Also curious that linux-signed-image doesn't depend on sbsigntool in quantal, but it does in precise and raring...
[01:02] <bjf> infinity, your just all kinds of fun today
[01:03] <infinity> Yeah, I'm great at parties.
[01:09] <infinity> bjf: Again, not world-ending, since that was already wrong in the previous uploads, but if you could fit it in git so it matches precise/raring on the next round, that'd be cool.
[01:09] <bjf> infinity, i've noted it and will correct tomorrow
[01:09] <infinity> bjf: (Not sure how else the packaging differs between linux-signed/quantal and linux-signed-lts-quantal/precise, but it seems on that they should differ at all, except for the linux-extra dep.
[01:09] <infinity> )
[01:09] <infinity> s/on/odd/
[01:09] <infinity> Typing hard.
[01:10] <infinity> bjf: Anyhow, this all looks like it's going to build and be happy, so feel free to run away, I'll sort the promotions myself in a bit when it's all done and do bot/bug faffing.
[08:09] <ppisati> moin
[08:18] <brendand> henrix_, can you help re-orient me in the kernel cadence?
[08:18] <brendand> henrix_, i'm starting to get lost
[08:39] <smb> morning
[08:54] <infinity> brendand: The current cadence is a bit out of whack due to emergency security releases.  We should be back in the normal flow of things in a day or three.
[08:55] <infinity> ppisati: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1132939 could use some urgent attention while I sleep, so I can deal with it in the morning. :)
[08:55] <ubot2> Launchpad bug 1132939 in kernel-sru-workflow "linux-ti-omap4: <version to be filled> -proposed tracker" [Medium,In progress]
[08:55] <brendand> infinity, an estimated date for the next kernels to finish verification?
[08:56] <infinity> brendand: Well, the current set are skipping the whole process, due to the aforementioned security urgency.
[08:56] <ppisati> infinity: saw it, doing the rebase right now
[08:56] <infinity> brendand: So, after that, you'd have to ask bjf about the next cycle.
[08:59] <apw> bjf, linux-signed in Q differs from P or R in that it contains the full binaries, and so doesn't need those other deps as it works different.  we may want to change that, but it is "right" at least
[09:02] <infinity> bjf: Translation, I'll probably work with Andy to make sure it gets changed to match P and R, for sanity and consistency but, yes, it's "correct" right now, as explained.  False alarm earlier.
[09:27] <henrix> apw: i understood that linux-3.5.y.z-queue was being built automatically from git but the latest build seems to be from Feb 16
[09:28] <henrix> apw: do i need to kick it off?
[09:28] <apw> henrix, they are automatic, but i thought there was two parts, the parts i was doing which are based on tags appearing
[09:28] <apw> henrix, and another part which herton did which was maybe a daily
[09:29] <henrix> apw: hmm... ok. so i pushed some commits to -queue yesterday. do you have any idea how do i start a build in there?
[09:31] <henrix> apw: anyway, i'll ping herton later about this. i have .debs i've created manually yesterday so i'll just use those for now
[09:40] <apw> henrix, ack
[10:53] <apw> henrix, erm, there are builds in the mainline builds since the 16th ?
[10:53] <apw> henrix, in the -review ?
[10:54] <henrix> apw: oh, i checked the -queue branch only
[10:54]  * henrix goes look
[10:54] <apw> it is optimising only one build i think
[10:54] <apw> if they are the same
[10:55] <henrix> ah, ok. makes sense
[10:55]  * apw needs to check it is doing it a sane way round
[10:58] <apw> henrix, yeah so if -review has built and matches -queue then we don't bother building that one too
[10:58] <apw> as they would be identicle
[10:58] <henrix> apw: yep, got it.  thanks
[10:59] <apw> i wonder if we should be linking it into there ... maybe we should
[10:59] <henrix> you mean the 'current', right? it could make sense, yeah
[11:00] <henrix> but since very few people will actually look at those, not sure if its worth the trouble
[11:00] <apw> i was more thinking the dates actually
[11:40]  * apw watches raring crater ... great
[12:49]  * rtg_ fixes quantal master-next build
[13:02]  * henrix -> lunch
[13:22]  * rtg_ preps raring kernel for upload, includes CVE-2013-1763
[13:26] <rtg_> uploaded...
[14:45] <Kurdistan> Hi my friend has fujitsu siemens amilo laptop and this is graphical card detail: http://paste.ubuntu.com/5567659/ . The issue is resume back from suspend. It goes to suspend, but when wake up it goes black screen. He really likes 12.04.2.
[14:52] <Kurdistan> I think it is kernel related because there was no fglrx driver in jockey-gtk
[14:56]  * cafetiere whines about i915 page flip hangs in v38 final 
[14:57]  * cafetiere also wonders how he is the first to hit them
[14:57] <Kurdistan> cafetiere, was your message to me? desperate to help my friend I made him switch from windows.. I do not want to look bad
[14:57] <rtg_> cafetiere, isn't there a SAUCE patch just forthat ?
[14:57] <cafetiere> I think that was p
[14:58] <rtg_> cafetiere, UBUNTU: SAUCE: drm/i915: Wait for pending flips to complete before tearing down the encoders
[14:58] <Kurdistan> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1082314 <<<-- I found this but I do not understand anything about it :(.
[14:58] <ubot2> Launchpad bug 1082314 in mesa "Raring wake up from S3 broken" [Medium,Fix released]
[14:58] <cafetiere> Kurdistan: nope whining about my own woes
[14:59] <Kurdistan> cafetiere, oki sorry... :(
[14:59] <cafetiere> rtg_: that is the one but this is during normal boot running
[15:01] <cafetiere> I have Somme pointer from the x people to try, but not being able to use ones own devel box is a pain
[15:11] <smb> Kurdistan, The best way to help your friend is to open a seperate bug report. Just run "ubuntu-bug" on the affected machine. That runs you through some questions and opens a launchpad bug. 
[15:22] <ppisati> brb
[15:44]  * ogasawara back in 20
[15:47] <Kurdistan> smb, he do not have launchpad account.
[15:47] <Kurdistan> but I will ask him if I do not find out ha way and his laptop have really high temp. I am afriad of overheating.
[15:51] <jsalisbury> **
[15:51] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:51] <jsalisbury> **
[16:27] <bjf> brendand, all you all sorted on what's happening wrt kernel SRU cadence now?
[16:30] <infinity> ppisati: What's happening with ti-omap4/quantal?  Just waiting on one of your coworkers to upload to the PPA?
[16:31] <ppisati> bjf: henrix: herton ^^^
[16:31] <ppisati> bug 1132939
[16:31] <ubot2> Launchpad bug 1132939 in Kernel SRU Workflow "linux-ti-omap4: 3.5.0-220.29 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1132939
[16:33] <henrix> infinity: ppisati: ok, i guess we forgot about those branches. thanks
[16:34] <brendand> bjf, a clear idea of when the next testing week will be would be handy right now
[16:36] <infinity> brendand: I'm not entirely clear on when your testing week is, but the next uploads should start today/tomorrow.
[16:36] <infinity> brendand: So, testing is the week or two following, I assume.
[16:37] <brendand> infinity, right
[16:38] <infinity> bjf: So... Setting verification testing to invalid REALLY pissed off the bot.  Let's not do that again. :P
[16:38] <bjf> infinity, lol
[16:39] <henrix> infinity: last week i just set those to 'fix released'. and then, manually, set the 'promote-to-*' to 'confirmed'
[16:41] <infinity> henrix: Yeah, I opted to set verification to fix released after I promoted, so everything stayed automated.
[16:41] <infinity> henrix: But we'd earlier set verification to invalid and the bot commented on the bug every few hours, saying "SOMETHING'S WRONG, AND I REFUSE TO DO ANYTHING ABOUT THIS BUG, BUT I'LL STILL ADD COMMENTS, NYAH NYAH".
[16:42] <infinity> I think it's just being a brat for attention.
[16:42] <henrix> infinity: heh, probably :)
[16:49] <bjf> brendand, this is a prep week, next week is verification, the following week is regression testing
[16:50] <brendand> bjf, ok thanks
[16:53] <bjf> brendand, there was a small error on the interlock schedule which i've just corrected: https://wiki.ubuntu.com/RaringRingtail/ReleaseInterlock
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ## Meeting starting now
[17:00] <jsalisbury> ##
[17:38]  * ppisati -> EOD
[18:40]  * rtg_ -> lunch
[20:18] <zequence> Woa, another Quantal -lowlatency update. What's going on?
[20:18] <bjf> zequence, yesterday was for a high priority CVE
[20:18] <bjf> zequence, today, it's the start of the regular 3 week cycle
[20:19] <zequence> bjf: Ok
[20:19] <bjf> zequence, c'mon, you didn't have anything else to do did you? :-)
[20:20] <zequence> bjf: Actually, I'm taking the chance while I'm being sick to get some mixing done :)
[20:21] <zequence> ..not that updating the kernel takes me a long time
[20:21] <zequence> I just run a script pretty much
[20:21] <zequence> And try not mess up the changelog :P
[20:28] <infinity> bjf: Not to harp, but should I be concerned that you're starting the new Q SRU cycle and no one's uploaded the ti-omap4/Q rebase for yesterday's CVE fiasco? :P
[20:29]  * rtg_ -> EOD
[20:29] <bjf> infinity, i guess i'll have to deal with that myself
[20:31] <infinity> bjf: I think that was the implication made earlier, yeah.
[21:19] <BenC> apw: I've had to revert a few of your config changes on ppc
[21:19] <BenC> apw: namely, all of the built-in self tests for FMAN/BMAN/QMAN were enabled, and really shouldn't be on unless doing extensive (performance hindering) debugging
[21:21] <BenC> Also, had to disable CRASH_DUMP because it really mucks up ppc in general (especially kexec kernel loading)
[21:21] <BenC> CRASH_DUMP makes it so it will be only relocatable to page aligned memory, where as normally we can relocate to arbitrary memory
[21:22] <BenC> And kexec doesn't have a way to detect that and mask/offset the memory when loading the kernel
[21:36] <infinity> BenC: Those are probably valid points for kexec in general which, while we don't officially support on other arches, we probably don't want to hinder.
[21:36] <infinity> apw: ^
[21:56] <BenC> infinity: I'm all for re-enabling it on non-freescale kernels, but as I can't test them with it enabled (and it appears it never was before), I'm hesitant of doing so
[22:10] <infinity> BenC: I was sort of arguing that your reverts might be valid across the board, not that you should revert the reverts anywhere. :)
[22:10] <BenC> infinity: right, I was just saying that I know it keeps our equipment from even booting the kernels, just noting I don't mind if it's enabled in places where that isn't an issue :)
[22:11] <infinity> BenC: Booting is overrated.  What you have there is the fix for every CVE, past, present, and future.
[22:12] <BenC> Optimism runs strong in you
[22:12] <infinity> Yeah, I get accused of that a lot.  Must be my sunny disposition and friendly personality.
[22:25] <infinity> BenC: Does this mean there's a linux-ppc upload coming soon?
[22:25] <BenC> infinity: Yeah, recompiling now to make sure this all works
[22:25] <infinity> BenC: If so, give me a bit of warning, and I can make sure it lands on sagari.
[22:26] <BenC> Ok, thanks
[22:27]  * infinity should probably test your kernels on his PPC750 occasionally to make sure you haven't broken powerpc32.
[22:27] <infinity> I run raring's powerpc64 kernels on another machine, and they're not obviously broken, but my PPC750 is precise.  I suppose installing and boot-testing the odd kernel wouldn't hurt.
[22:28] <antarus> people still use powerpc32? :)
[22:28] <antarus> we were discussing this at scale recently ;p
[22:28] <infinity> antarus: A fair few people do, AFAIK, though I'm just an "old hardware" case.
[22:29] <infinity> antarus: It's an ultra-low-power IBM PPC750 core, so despite being ancient, I don't really feel bad about running it, like I do with, say, old Pentiums.
[22:56] <bjf> infinity, i've uploaded a ti-omap4. i'm prepared for you to tell me all the ways i've screwed it up.
[23:08] <infinity> bjf: Looks fine to me.
[23:08] <infinity> bjf: Sorry to disappoint.
[23:09] <infinity> bjf: I'll get it copied and released as soon as it's built tonight to clear the way for the normal SRU that should follow.
[23:10] <bjf> infinity, still plenty of time to find fault, don't rush.
[23:10] <infinity> bjf: Well, the one thing you did wrong was to mangle the bug so the bot started lying about builds being completed. :P
[23:10] <infinity> bjf: But the source itself looks fine.