[00:37] <hggdh> infinity: quantal done
[00:38] <infinity> hggdh: My hero.  Just waiting on Cert now.  Thanks for fast-tracking your bits. :)
[00:38] <hggdh> infinity: you are welcome
[12:08] <apw> dhanasekaran, that is most likely a kernel issue of some sort
[12:48] <dhanasekaran> apw: I need to update the kerenl
[12:48] <dhanasekaran> apw: or some I need to pass argument in boot arguments
[13:07] <apw> dhanasekaran, i cannot say with the information i have so far, i would recommend filing a bug 'ubuntu-bug linux' from a terminal
[13:08] <apw> dhanasekaran, if this problem is very new (ie just started happening) then you may be able to avoid the issue by booting an older kernel
[13:08] <apw> dhanasekaran, from the grub menu, and if so then we will know when it worked and when it stopped working
[14:24]  * henrix -> late lunch
[15:46] <infinity> henrix: Shankbot appears to have failed to set tasks on https://bugs.launchpad.net/ubuntu/+source/linux-lts-quantal/+bug/1087221
[15:46] <ubot2`> Launchpad bug 1087221 in Kernel SRU Workflow "linux-lts-quantal: 3.5.0-21.32~precise1 -proposed tracker" [Undecided,In progress]
[15:47] <infinity> herton: (I'm going to promote it anyway, but thought you might want to look into why)
[15:50]  * henrix checks...
[15:50] <infinity> henrix: Oh, never mind, I know why.
[15:51] <henrix> infinity: and the reason is... ? :)
[15:51] <infinity> henrix: Same reason the armadaxp and omap4 bugs didn't get twiddled for quantal, they were derivatives of the previous version, which never made it to the promoted state.
[15:51] <infinity> henrix: In this case, a bit more subtle, since it's no longer a derivative of the previous version, but you did re-use the bug that used to be. :P
[15:52] <henrix> ah, makes sense
[15:52] <henrix> i guess...
[15:52] <infinity> Probably not a case worth worrying about, since this needs a bit of human smarts to determine it's "okay" anyway.
[15:52] <herton> henrix, yes, master-bug property on the bug should have been adjusted as well
[15:52] <infinity> (As in, I wouldn't be happy with the bot having marked those two ARM kernels, better for me to look and decide it was a good idea and do it myself)
[15:53] <infinity> But, sure, for the re-used bug bit, you could have fixed it. :)
[15:53] <henrix> herton: ok, got it
[16:38] <dobey> hi all, can anyone tell me if this upstream change is included in the recent kernel updates for quantal? http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=248138b59880a3cc69e9b7f0e06fb0caedd58305
[16:41] <herton> dobey, yes, should be in the quantal kernel released to updates today
[16:42] <dobey> thanks
[16:42] <dobey> then i suppose either that's not the fix i need, or it doesn't work for my problem
[16:43] <infinity> dobey: Or you didn't upgrade?  When he says "released today", he literally means an hour ago or so...
[16:43] <dobey> infinity: i just installed the latest kernel, and rebooted :)
[16:43] <infinity> Ahh, well.  Nevermind, then. :P
[16:44] <herton> Indeed. if you have 3.5.0-21.32, you have the latest update
[16:44] <dobey> but i'm not certain it's the right change. as dnaiel just said "fix is in drm-fixes" and from the changelog it seemed the most relevant change to my bug, which is https://bugs.freedesktop.org/show_bug.cgi?id=51983
[16:44] <ubot2`> Freedesktop bug 51983 in DRM/Intel "[ivb DVI fdi link train fail] Multiple Displays not working on Core i7 3770S" [Normal,Resolved: fixed]
[16:45] <infinity> For the record, I don't see that commit in the quantal kernel.
[16:45] <dobey> oh ok
[16:46] <infinity> herton: You may have fibbed. :P
[16:46] <herton> infinity, I see it here, commit dd86e0283ca61727e133cfae73ae21779188fbb5
[16:46] <infinity> I'm looking at the source, which doesn't contain that code...
[16:47] <dobey> where are the branches for the linux source packages for ubuntu anyway? lp doesn't show any in bzr
[16:48] <herton> dobey, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git
[16:48] <jwi> infinity: looking in ubuntu/i915?
[16:48] <infinity> jwi: Oh, no, looking in drivers/gpu/etc... Which seemed to make sense. :P
[16:48] <jwi> dobey: if you're running ivb, that commit shouldn't make any difference.
[16:48] <infinity> Do we really have two copies of the code?
[16:49] <herton> infinity, strange, well it looks commited. Yes, we have now i915_hsw with haswell backports
[16:49] <jwi> infinity: afaik it's the hsw enablement
[16:49] <herton> infinity, at ubuntu/i915
[16:49] <dobey> hmm
[16:50] <infinity> Right, looks decidedly more committed there.
[16:50] <infinity> That's not confusing in the least. :/
[16:51] <dobey> hrmm
[16:54] <dobey> well, lunch. guess i'll worry about this a bit more later
[18:29] <slangasek> should I be expecting 'git clone http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-quantal.git' to work?  That's the URL listed in the source package's Vcs-Git field, but I'm getting "connection timed out while accessing".
[18:33] <henrix> slangasek: maybe that's just historical, i'm not sure. looks like it's like that since lucid.
[18:37] <slangasek> henrix: let me rephrase the question: I'm trying to get the package source and it's not working.  Where should I be looking?
[18:37] <henrix> slangasek: the correct url should be git://kernel.ubuntu.com/ubuntu/ubuntu-quantal.git
[18:38] <slangasek> ok, thanks
[18:38] <henrix> np
[18:38] <slangasek> should I raise a bug about the broken metadata in the package?
[18:39] <henrix> that's probably a good idea....
[18:39] <henrix> if you do, please let me know the bug #
[18:39] <henrix> i can take a look at that and fix it
[18:40] <henrix> (or investigate why we're using the wrong url)
[18:40] <slangasek> henrix: well, I just tried to clone from the git:// uri and that failed *too* :)
[18:40] <henrix> slangasek: interesting, i pasted the url and it seems to work
[18:41] <henrix> slangasek: maybe you have a different prob then ;)
[18:41] <slangasek> maybe!
[18:42] <slangasek> yep, works from my laptop but not from a dev box on the same network - so it's a local problem.  thanks :)
[18:43] <henrix> np
[19:05] <infinity> henrix: shankbot's lying about promote-to-proposed being ready.  It's confirming the task before the binaries are all in.
[19:05] <infinity> henrix: (It did this for both of Andy's lowlatency uploads, which are still building/publishing)
[19:06] <henrix> herton: ^^ do you think it's still the same problem we saw the other day?
[19:06] <herton> infinity, which bug #?
[19:06] <herton> henrix, may be, if my fix still isn't in
[19:06] <infinity> 1087213 and 1090123
[19:08] <apw> herton, as i was doing the task fiddling for the prepare and upload tasks i may have doen something wrong
[19:08] <apw> herton, i had assumed i should mark the upload-to-ppa etc fix released when completed
[19:08] <apw> was that right
[19:09] <herton> apw, ah, so you set prepare-package to fix released?
[19:09] <apw> yeah cause i had done them indeed
[19:09] <henrix> herton: do you know where the bot is running? is it on people?
[19:10] <apw> henrix, i suspect i am missunderstanding my role ... please tell me how to do it right
[19:10] <apw> herton, even
[19:10] <apw> i had assumed i had two roles, preparing the packages, and uploading them
[19:10] <apw> and that for each i would fix release them
[19:10] <apw> when done
[19:11] <herton> apw, in the bugs with two roles, like this one, the right thing to do is set prepare-package to fix released, like you did, and upload-to-ppa to in progress
[19:11] <apw> yeah, but then it was uploaded, so i moved it fix released too
[19:11] <infinity> "If Upload-to-ppa is present, Workflow Mgr. sets it to completed (status: Fix Released)."
[19:11] <apw> is that the error
[19:11] <herton> apw, yes, that's it
[19:12] <apw> doh
[19:12] <infinity> Looks like the intended workflow is to leave it as "In Progress" and let shankbot automate the rest.
[19:12] <apw> hmmm, then the task should be upload and let build ... but hey ho
[19:12] <herton> apw, my first question should have been if you set upload-to-ppa to fix released... the bot does that
[19:12] <infinity> Though it still feels like a bug that shankbot doesn't do the "it's all built" test before setting promote-to-proposed.
[19:12] <apw> heh i was bound to break it :)
[19:12] <herton> apw, may be, yes, a bit confusing
[19:12]  * apw will know for next time, soz
[19:13] <herton> this two roles separation is only for cases like ti-omap4 or ec2, where someone pushes to git, and other do the upload, may be lowlatency doesn't need that
[19:14] <herton> apw, also you set prepare-package-meta to in progress, the bot takes care of that as well, when you have a new meta
[19:14] <infinity> lowlatency may again need it in the future, once Andy's sorted out getting the studio guys to do the rebases.
[19:14] <herton> oh ok
[19:14] <apw> yeah mostly they will want it, probabally at least for a bit
[19:15] <infinity> Anyhow, I'll just be old-fashioned and wait for visual confirmation that it's all published to the PPA before I copy, no big deal.
[19:15] <infinity> I almost always double-check the bot's work there anyway, out of complete lack of trust. :P
[19:15] <apw> yeah it is all a bit odd, as if the bot checked for the things to finish and boinked the promote task
[19:16] <apw> it wouldn't have to care about the upload or prepare tasks at all, and i could close them
[19:16] <apw> and we have nothing open while building
[19:16] <herton> apw, in summary, you set prepare-package to fix release, and all other prepare-package-* and upload-to* to in progress, bot takes care when build finishes
[19:17] <apw> nng, perhaps it should do prepare-package too, so one can just leave them all open
[19:17] <apw> as it is a little confusing to know you have one you do something different to
[19:18] <herton> apw, it's this way now because prepare-package in this 'two roles' bugs means something a bit different, it's set to fix released when the person doing it prepared the source to be reviewed so who does the upload can push into ubuntu/ and upload
[19:19] <herton> but perhaps this should be refactored, may be creating a new task and stopping subverting the prepare-package task
[19:19] <apw> then all the packages should be fix_released in that case, and all of the non-invalid ones used to select which to check for to handle upload-to-ppa
[19:20] <apw> me having to handle prepare-package one way and prepare-package-meta another in either case is very strnage and liable to trigger wrongness
[19:20] <apw> if we can eliminate that need somehow then all to the good
[19:21] <apw> herton, well i think if you just disconnect the promote-to-xxx from the tasks, makingit only wait for all packages that have prepare-* tasks which are not invalid
[19:21] <apw> then i could use the prepares-* either way and things still work
[19:22] <apw> they would get wacked if open, as should upload-to-ppa, but if they are already closed, who cares
[19:24] <apw> that would make it user tollerant
[19:24] <herton> apw, not sure about this. But I think I could just make the bot verify again that really the packages are on the ppa in any case before the promote-to-proposed is set to confirmed
[19:25] <infinity> That's what he just said. :P
[19:26] <apw> herton, i think if the mentality for any verifiable test, like package source in the PPA (should fix release the corresponding prepare-* task), package built in ppa (close upload-to-ppa), packages in -proposed (close promote-to-ppa)
[19:26] <apw> and also set the approriate next task to Confirmed
[19:26] <apw> then things would flow without anyone ever getting out of sync
[19:26] <apw> as if they do it then we change nothing, if they don't then we fix it for them
[19:27] <herton> yeah, ok I'll implement these extra checks. But I still think that may be we should also remove the upload-to-ppa may be, and just not "overload" the prepare-package task with two meanings
[19:29] <herton> and sure, everything the bot can do to fix something out of sync is good
[19:30] <apw> i think then all i have to do is build and upload them and it should just fix all my tasks right :)
[19:32] <herton> yes, that can be done, I'll do changes towards that. If the bug has the package version, it should handle itself with no trouble
[19:48] <infinity> herton: What's the magic for making the bot and reports ignore a tracking bug?  Just invalidate all the tasks?
[19:49] <infinity> herton: 1090121 and 1090120 should just be closed out, since they're rebase requests for an x86-specific fix.
[19:49] <infinity> (And I'm sick of seeing them on the workflow report) :P
[19:49] <herton> infinity, just closing as duplicate of any other bug should do it
[19:49] <infinity> herton: Ahh, kay, I'll just dupe them to the previous ones I just released, that'll do.
[19:50] <herton> yep, I was thinking of doing the same too, thanks, really they shouldn't stay open
[19:52] <infinity> herton: Done.
[19:52] <herton> cool, thanks
[19:52] <infinity> And this pre-holiday SRU cadence is almost done.  Just two more kernels to verify.
[19:52] <infinity> Which would leave us with a clean slate (and everything in sync!) going into January...
[20:05]  * apw is on the verifications now
[21:00] <apw> infinity, ok i have boot tested all 5 of the kernels making up the P and Q lowlatency kernels