| hggdh | infinity: quantal done | 00:37 |
|---|---|---|
| infinity | hggdh: My hero. Just waiting on Cert now. Thanks for fast-tracking your bits. :) | 00:38 |
| hggdh | infinity: you are welcome | 00:38 |
| === _ruben_ is now known as _ruben | ||
| === yofel_ is now known as yofel | ||
| === henrix_ is now known as henrix | ||
| apw | dhanasekaran, that is most likely a kernel issue of some sort | 12:08 |
| dhanasekaran | apw: I need to update the kerenl | 12:48 |
| dhanasekaran | apw: or some I need to pass argument in boot arguments | 12:48 |
| 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:07 |
| 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 | 13:08 |
| * henrix -> late lunch | 14:24 | |
| === rsalveti_ is now known as rsalveti | ||
| 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:46 |
| infinity | herton: (I'm going to promote it anyway, but thought you might want to look into why) | 15:47 |
| * henrix checks... | 15:50 | |
| infinity | henrix: Oh, never mind, I know why. | 15:50 |
| 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:51 |
| 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:52 |
| infinity | But, sure, for the re-used bug bit, you could have fixed it. :) | 15:53 |
| henrix | herton: ok, got it | 15:53 |
| 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:38 |
| herton | dobey, yes, should be in the quantal kernel released to updates today | 16:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| infinity | For the record, I don't see that commit in the quantal kernel. | 16:45 |
| dobey | oh ok | 16:45 |
| 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:46 |
| dobey | where are the branches for the linux source packages for ubuntu anyway? lp doesn't show any in bzr | 16:47 |
| 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:48 |
| 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:49 |
| infinity | Right, looks decidedly more committed there. | 16:50 |
| infinity | That's not confusing in the least. :/ | 16:50 |
| dobey | hrmm | 16:51 |
| dobey | well, lunch. guess i'll worry about this a bit more later | 16:54 |
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| 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:29 |
| henrix | slangasek: maybe that's just historical, i'm not sure. looks like it's like that since lucid. | 18:33 |
| 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:37 |
| slangasek | ok, thanks | 18:38 |
| henrix | np | 18:38 |
| slangasek | should I raise a bug about the broken metadata in the package? | 18:38 |
| 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:39 |
| 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:40 |
| henrix | slangasek: maybe you have a different prob then ;) | 18:41 |
| slangasek | maybe! | 18:41 |
| slangasek | yep, works from my laptop but not from a dev box on the same network - so it's a local problem. thanks :) | 18:42 |
| henrix | np | 18:43 |
| 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:05 |
| 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:06 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 | |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| apw | they would get wacked if open, as should upload-to-ppa, but if they are already closed, who cares | 19:22 |
| 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:24 |
| infinity | That's what he just said. :P | 19:25 |
| 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:26 |
| 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:27 |
| herton | and sure, everything the bot can do to fix something out of sync is good | 19:29 |
| apw | i think then all i have to do is build and upload them and it should just fix all my tasks right :) | 19:30 |
| 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:32 |
| infinity | herton: What's the magic for making the bot and reports ignore a tracking bug? Just invalidate all the tasks? | 19:48 |
| 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:49 |
| herton | yep, I was thinking of doing the same too, thanks, really they shouldn't stay open | 19:50 |
| 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... | 19:52 |
| * apw is on the verifications now | 20:05 | |
| apw | infinity, ok i have boot tested all 5 of the kernels making up the P and Q lowlatency kernels | 21:00 |
| === henrix is now known as henrix_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!