[00:25] RAOF: ayt? [00:25] mwhudson: EUNKNACRONYM [00:25] Oh, are you there. [00:25] I guess I've also answered, then :) [00:26] RAOF: i'm doing that terrible thing were i bug a person who i think knows about X [00:26] RAOF: but i'm getting lots of "soft" gpu crashes with sandybridge on recent quantal [00:26] RAOF: do you know anything about that? [00:27] By "soft gpu crashes" what you mean is "apport pops up saying the GPU has crashed, but you haven't noticed anything wrong", right? [00:27] more or less [00:27] it freezes for a second or two, so i know something has happened [00:27] but i don't have to restart [00:28] and there are messages like "[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung" in syslog [00:29] WARNING: at /build/buildd/linux-3.5.0/drivers/gpu/drm/i915/intel_pm.c:2505 gen6_enable_rps+0x706/0x710 [i915]() [00:29] mwhudson: That's probably old crashes all being reported in a batch since your last reboot. [00:29] mwhudson: Check timestamps in /var/crash. If they're all old, just wipe 'em out and try fresh. [00:29] Oh, if you're seeing new hangs in the kernel rungbuffer, ignore me. [00:29] ringbuffer, even. [00:29] infinity: xserver-xorg-video-intel.2013-04-15_12:25:14.100714.crash [00:30] that's about 5 minutes old [00:30] Kay, nevermind. We just had a case of "I rebooted quantal and apport went insane and I'm blaming it on the new kernel" a few days ago. [00:30] So, that's my go-to. :P [00:30] :) [00:41] Sorry s baby attack [00:45] mwhudson: I don't know anything specific about that - have we updated mesa in quantal recently? You say it only recently started? [00:45] RAOF: yeah, it only started a week or so ago [00:46] RAOF: oldest thing in /var/crash is from apr 9, but i don't know if that gets auto-pruned [00:47] * mwhudson times out launchpad a few times [00:49] RAOF: https://launchpad.net/ubuntu/+source/mesa/+publishinghistory does show things from around that time [00:50] Yeah, we would seem to have pulled in the 9.0.3 mesa point release. [00:51] Which would be a plausible cause. [00:52] I don't suppose you'd feel like downgrading to the previous mesa package and seeing if the hangs still occur? [00:55] sure [00:56] ... if i can still download the previous package from somewhere? [00:57] Yeah, launchpad. Let me slurp you up a link. [01:02] mwhudson: https://launchpad.net/ubuntu/+source/mesa/9.0.2-0ubuntu0.1 has links to all the various builds; presuming you're after amd64 packages you can get them from https://launchpad.net/ubuntu/+source/mesa/9.0.2-0ubuntu0.1/+build/4312581 [01:04] that's a lot of packages :/ [01:04] i guess i don't need -dev or -dbg? [01:05] No. [01:05] Nor any of the swx11 ones. [01:06] In fact, you only need the ones that you've currently got installed, which is not likely to be *too* much more than libgl1-mesa-glx and libgl1-mesa-dri [01:07] oh god i have 32 bit mesa installed too it seems [01:07] (probably because of steam?) [01:07] Yeah, that'd be right. [01:08] So, you'll need to grab the i386 versions, too :) [01:10] * mwhudson runs sudo dpkg -i *mesa*9.0.2* in a loop while downloading more and more things [01:10] Yeah, that's about the shape of it. [01:17] sigh [01:17] ok, i think i have that working again :) [01:19] can't restart now but will get back to you later ,,, [01:29] mwhudson: Ta [01:45] any archive admins around? (bug #1069292) [01:45] bug 1069292 in Ubuntu "[needs-packaging] New package tegaki-zinnia-traditional-chinese" [Wishlist,In progress] https://launchpad.net/bugs/1069292 === wedgwood_away is now known as wedgwood === wedgwood is now known as wedgwood_away === baba is now known as hack === hack is now known as megha [04:04] slangasek: you may be right. the thing that pointed towards it was that the skype crasher is very popular and happens right when the program starts, while none of the other packages have any recent crash or "doesn't start" reports === BruceMa is now known as BruceMa_afk === BruceMa_afk is now known as BruceMa [06:36] good morning [06:37] good ****ing === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss === schmidtm_ is now known as schmidtm [07:09] chrisccoulson: bug 1168152 [07:09] bug 1168152 in firefox (Ubuntu) "package kubuntu-firefox-installer 12.04ubuntu1 [modified: usr/share/applications/firefox.desktop] failed to install/upgrade: Versuch, »/usr/share/applications/firefox.desktop« zu überschreiben, welches auch in Paket firefox 20.0+build1-0ubuntu1 ist" [Undecided,Confirmed] https://launchpad.net/bugs/1168152 === doko_ is now known as doko === Riussi_ is now known as Riussi [08:11] pign cjwatson: will there be another translations export of ubiquity-debconf before the 13.04 release? [08:12] apachelogger, http://bazaar.launchpad.net/~mozillateam/firefox/firefox-trunk.head/revision/1668 [08:12] Hm. How do we get out-of-date packaging branches dealt with, again? [08:12] chrisccoulson: ah sweet [08:12] RAOF, open a bug against UDD? [08:13] RAOF, https://bugs.launchpad.net/udd [08:13] seb128: Ta [08:13] yw [08:24] cjwatson: the reason I ask is that the dutch team recently (yesterday) fixed some very visible errors in the installer, and we would like to see those fixes show up in 13.04 if possible === amitk is now known as amitk-afk === Gwaihir_ is now known as Gwaihir === smb` is now known as smb [09:36] trijntje: import, you mean? we usually do one between now and release, yes [09:36] oh, well, export from LP's point of view, import from ours :) [09:36] ev, any progress with the weighting recalculation? [09:37] mpt: good timing (for certain definitions) [09:37] the test of it just timed out while repopulating [09:37] it did 12.9 million reports over the weekend out of some 45 million [09:37] but since we were calculating a new denominator at the same time, I should be able to generate a test graph with the data we have [09:38] What period, do you know? [09:38] period? [09:38] reports are not stored by date [09:38] So, scattered across the whole time since tracking began? [09:39] (technical: cassandra arranges row keys based on a selected partitioner. We use the random partitioner, since the order-preserving partitioner brings serious performance concerns with it) [09:39] mpt: correct [09:39] nice [09:39] if you come over here I can tell you more [09:40] My curiosity is assuaged for now :-) [09:40] :D === security is now known as megha [10:13] robert_ancell: hey, I took a quick look at lightdm in the raring upload queue and was wondering why we need those changes in raring. [10:15] rejecting libcolumbus (commented on the mp) [10:15] stgraber, you would prefer raring to stay on an unstable lightdm version? [10:15] Laney, :-( [10:15] seb128: it wasn't for raring [10:16] seb128: no but there's no indication in the changelog that the current version is unstable [10:16] seb128: it just says that the new one is a bugfix release even though one of the so called bugfixes is actually a new feature [10:16] stgraber, it's 1.5.n (odd numbering = dev serie, a la GNOME) === tkamppeter_ is now known as tkamppeter === amitk-afk is now known as amitk [10:17] huh, thought this was -release [10:17] Laney, k, I though it would be the fix for https://code.launchpad.net/~jpakkane/libcolumbus/lessfuzz-test/+merge/158595 [10:18] no :-) [10:19] seb128: ok. I'll let it through then. I don't think I agree with upstream's definition of "bugfix" but well, it's not causing any actual change in behaviour for the user. [10:19] stgraber, is that because of the vnc option? [10:20] robert_ancell: It'd be great if in the future you could put something in the changelog when moving from an unstable to a stable release. Here all I saw was 1.5.3 => 1.6.0 both of which were referred to as "New upstream bugfix release". [10:20] stgraber, but I guess you could try arguing with robert_ancell over it [10:20] seb128: yeah, the Qt change looks like a bugfix [10:20] seb128: I usually see adding config options (including change to the default/example conffile) as a feature change [10:20] anyway, accepting [10:21] yeah, I agree this one is a bit borderline [10:21] thanks [10:22] stgraber, ok, I'll note that the releases are switching from unstable to stable in the future === MacSlow is now known as MacSlow|lunch [11:52] BenC: your new linux-ppc has belatedly landed [12:14] pitti: I've assigned you to bug 1162931, but I'm happy to work on it myself if you say where I should look [12:14] bug 1162931 in Ubuntu Translations "Calculator app UI is not translated" [Medium,Triaged] https://launchpad.net/bugs/1162931 === MacSlow|lunch is now known as MacSlow [12:14] (looks like there is some list of packages that needs to be updated) [12:17] mitya57, dpm just approved the new templates last week [12:17] not sure if they made it to langpacks yet [12:21] seb128: thanks, I'll mark it as fix committed then [12:21] (the current langpacks were built earlier) [12:22] check that those have the translation or maybe check with dpm [12:23] mitya57, I approved the gnome-calculator last week after I noticed the name had changed. That one and others where that rename happened should appear in the next full language pack [12:23] seb128, ^ [12:24] dpm, hey, when is the next "full" planned? [12:24] dpm: did you approve new GNOME games? [12:24] mitya57, I remember approving gnome-mahjongg and gnome-mines. Was there any other one? [12:25] seb128, we haven't got any one planned, but the LP export is next Wednesday, so it might be worth making that one a full lp [12:26] dpm, well, hard freeze for raring is this week, so that would be good [12:26] dpm: gnome-chess gnome-nibbles iagno quadrapassel gnome-tetravex gnome-robots gnome-klotski five-or-more [12:26] mitya57, thanks. Have all these been uploaded? [12:27] some of those are in universe [12:27] dpm: yes, but $(whatSeb128Says) [12:30] mitya57, seb128, looking at gnome-chess, it seems no translation template has been uploaded: https://translations.launchpad.net/ubuntu/raring/+source/gnome-chess/+imports [12:30] dpm, it's in universe [12:30] same for gnome-nibbles [12:30] ok [12:30] dpm: looks like everything I named is in universe :) [12:31] mitya57, ok, so it seems we're all sorted [12:31] thanks [12:31] dpm, mitya57: thanks === seb128_ is now known as seb128 [12:34] dpm: while you are here: do you have any plans to look at bug 861455 / bug 886968 / bug 886971 / bug 1134393? [12:34] bug 861455 in Ubuntu App Developer site "Fix Qt documentation links" [Low,Triaged] https://launchpad.net/bugs/861455 [12:34] bug 886968 in Ubuntu App Developer site "Very old Qt tutorial" [Undecided,New] https://launchpad.net/bugs/886968 [12:34] bug 886971 in Ubuntu App Developer site "Qt Creator tutorial is not the most recent one" [Undecided,New] https://launchpad.net/bugs/886971 [12:34] bug 861455 in Ubuntu App Developer site "duplicate for #1134393 Fix Qt documentation links" [Low,Triaged] https://launchpad.net/bugs/861455 [12:34] (or is there any branch I can file a MP against?) [12:37] mitya57, wow, that's a quite a few bugs in a row. Give me a few minutes to look at them one by one :) [12:38] dpm: probably some/all of these are duplicates === _salem is now known as salem_ [13:37] people, someone knows a kernel bug ? i am still getting an annoyign bug that leaves me with a black screen after the updates. i thought it was because my intel hd3000 but happens after the updates even with my ati card. [13:38] people, someone knows a kernel bug recently that guives black screen ? i am still getting an annoyign bug that leaves me with a black screen after the updates. i thought it was because my intel hd3000 but happens after the updates even with my ati card. === wedgwood_away is now known as wedgwood [14:08] tseliot: Hrm. [14:08] infinity: yes? [14:08] tseliot: That move to xorg-driver-binary is shiny, but it doesn't mean you can drop the conflict and/or replaces on all the old ones that you have file conflicts with. [14:08] tseliot: Otherwise, upgrades from previous releases will asplode. [14:09] (Or, potentially will) [14:09] infinity: I think I removed conflicts from initial debian releases [14:09] infinity: the rest should be pretty useless too [14:09] You might need to expand that sentence to tell me what it means. [14:10] [also file conflicts should be expressed with breaks/replaces, not conflicts/replaces] [14:10] cjwatson: is it really necessary? [14:10] A hard conflict and nothing else isn't world-ending either. But none of the broken provides/conflicts/replaces madness, since fglrx never actually should have PROVIDED nvidia-foo, etc. [14:11] tseliot: It's absolutely necessary to provide smooth upgrades if there are file overlaps. [14:11] infinity: right, and xfree86-driver-fglrx, xorg-driver-fglrx, fglrx-kernel-source, libamdxvba1, fglrx-modaliases come from very old releases [14:11] tseliot: Normally, keeping the Breaks/Replaces is way cheaper for everyone than trying to figure out whether they're strictly needed. [14:11] tseliot: Since you can't go back in time and make the precise packages provide xorg-driver-binary, you still need to deal with that. [14:12] tseliot: The failure mode is pain for users and results in hard-to-decipher upgrade failures; what's the point in inviting that? [14:12] (You can drop all of that after 14.04, though, and just use the new method) [14:12] infinity: right, they all conflict/replace/provide with fglrx-driver, same as in previous releases [14:13] cjwatson: I'm trying to understand what kind of failure a missing Breaks can cause. This wasn't the case with Nvidia, at least according to my tests [14:13] tseliot: But fglrx and nvidia don't conflict. Is there actually a file overlap between them? [14:13] tseliot: Or was that conflict just poorly-expressed? [14:13] tseliot: see policy for why Breaks in addition to Replaces [14:14] tseliot: As in, precise's nvidia-* and raring's fglrx. [14:14] It's a corner case that's cheap to avoid, so why not avoid it ... [14:14] (Assuming this is actually a case of file overlaps) [14:14] cjwatson: I think it's actually a conflict in this case anyway, they should never be installed together. [14:14] infinity: nope. It was a poor attempt at saying that one package could be replaced by the other instead of making apt complain about having to remove either of them manually [14:14] (Or, that's what I gathered from all the hackish relationships) [14:15] tseliot: If you mean why Breaks instead of Conflicts for file overlaps (in cases where there isn't a real conflict), there's an extensive discussion in the policy manual about that [14:15] tseliot: So, what's preventing me from having precise's nvidia-foo and raring's fglrx installed together now? [14:15] tseliot: And isn't that a Very Bad Thing to let happen, hence all those conflicts in the first place? [14:15] infinity: they conflict/replace/provide one another [14:16] tseliot: But they don't, as of this upload. [14:16] tseliot: See my point? [14:16] infinity: they all conflict/replace/provide xorg-driver-binary [14:17] cjwatson: they don't really overlap [14:17] tseliot: Not in precise... [14:18] tseliot: I'd just keep a conflicts line that lists all the binary drivers that shipped in precise-release and quantal-release (don't worry about updates, since you can make those provide xorg-driver-binary), and leave it be. [14:19] tools such as jockey or its successor, don't remove any other installed driver before installing a different graphics driver, so, if, for example, nvidia-310 is already installed, and you want to install nvidia-304, apt will complain unless they all conflict/replace/provide the same thing [14:19] infinity: I'm planning to update the drivers in Precise too (I forwarded the email to both of you) [14:20] tseliot: Yes, but you can't update the ones shipped in the release pocket. [14:20] tseliot: And while we *technically* don't "support" upgrades from the release pocket only, there's no point in making them gratuitously more difficult. [14:21] infinity: in Precise all the drivers can be installed at the same time without problems. Thanks to the alternatives system only one will be used [14:21] tseliot: Erm, you mean none of those conflicts are in the precise packaging? [14:21] infinity: no, just in quantal and raring [14:21] tseliot: Or, you mean that if they weren't there, they'd be coinstallable and it would sort of work? :) [14:22] infinity: so, they conflict only in quantal and in raring but, even without that, things wouldn't explode [14:23] each driver lives in its own set of directories and the files in common are handled using alternatives [14:23] Hrm. Kay. Then maybe my concern is unfounded. [14:24] (Does jockey/ubuntu-drivers-common manually twiddly alternatives? Ew) [14:24] s/twiddly/twiddle/ [14:24] infinity: jockey certainly does, ubuntu-drivers-common does not [14:24] Okay, so in the post-jockey world, you really can't install two together. [14:24] we really have to many ... [14:24] I mean, you can install them, but the one you want won't necessarily work. :P [14:24] infinity: nope [14:25] * ogra_ wonders if mtp has seen the UI in a recent raring with nvidia card [14:25] *mpt even [14:25] definitely not something my mother would get along with [14:25] infinity: well, it's either one driver or the other... [14:26] Anyhow. If they all conflict in raring, that'll work fine. And I think you've satisfied me on the upgrade front. Ish. [14:26] ogra_: I didn't really work on the UI [14:26] This is all such a mess. [14:26] tseliot, yeah i wonder if thats solvable at all [14:26] infinity: welcome to my world ;) [14:26] ogra_, let me guess, the description of the driver is hundreds of characters long? [14:26] but we definitely have to much choice there [14:26] Why doesn't someone just write an nvidia shim driver that checks your PCI ID and dlopens the right one, and you can ship them all in one? [14:26] That's what the ATI driver does... [14:27] (The free one, not the binary one) [14:27] mpt, well, no, but you have an nvidia-1-* mvidia-2-* nvidia-1-updates nvidia-2-updates nvidia-5-experimanetal etc [14:27] mpt, (example numbers indeed) [14:27] infinity: I guess they simply want you to pick a driver version and use that. This is entirely our problem [14:28] * mpt reads scrollback [14:28] tseliot: Nonsense. You can't just pick one as a distribution, since we have to support multiple cards and they keep bumping them out of support. [14:28] dpm: any progress? [14:28] cjwatson: I'm doing what "7.6.2 Replacing whole packages, forcing their removal" says, and I think it should be fine [14:29] If it's a case of a true conflict and not just a file overlap, sure [14:29] (I didn't check, just triggered on the "conflicts/replaces for file overlaps" notion [14:29] ) [14:29] mpt, http://img6.imageshack.us/img6/6692/screenshotfrom201303140.png thats what i mean [14:29] infinity: I've never said it would make sense ;) [14:30] cjwatson: It's a real conflict, thanks to how well they don't work when installed together. There's apparently no file overlap at all. :P [14:30] heh [14:30] Gotcha [14:30] * mpt wonders why it's "Using" rather than "Use" [14:31] * infinity wonders why those lines start with the same redundant verb at all. [14:31] mpt, well, i dont really care about the wording, but the amount of choice (and actually understanding what they mean) seems awful [14:32] my mom would definitely not get along with it [14:32] infinity, good question ... Because normally there's only two or three of them, and repeating the verb is less waste than having a whole extra "Use:" intro line [14:32] And with that amount of choice they badly need to be sorted [14:32] there wqere three of them in the far past :) [14:32] thats long gone i think [14:32] infinity, AIUI in code this is called "inlining" :-) [14:33] mpt: This is a funrolled loop, clearly. [14:33] But when it gets to six, it starts looking silly [14:33] mpt: Gentoo dialog. [14:33] (what the heck is VDPAU ?!?) [14:33] This reminds me of when we used to show kernels going back years in Grub [14:34] Now we have just "Ubuntu" and "Ubuntu (other options)", or something like that, right? [14:34] Yeah. [14:35] 1) Free, 2) Proprietary and tested, ** divider ** 3..inf) other crap? [14:35] Assuming that one I slotted in (2) isn't a case that exists twice, which it might for some PCI IDs. [14:35] But I guess then you just pick the highest version one. :/ [14:36] In conclusion: Eff you, nvidia. [14:36] which might or might nort work on your card depending on how the nvdidia dev slept last night [14:36] otr only have half baked support for exactly that card etc [14:37] I miss the good old days when their drivers supported everything from the TNT to the latest and shiniest GeForces. [14:37] yeah [14:37] infinity, after five years, today I finally understand that the "funroll loops" in is an actual thing. Thank you. [14:37] Though, I can sympathize with their urge to drop compatibility code for shader emulation and other madness. [14:37] mpt: It's a compiler switch. :) [14:38] you could still ship different binaries in one tarball [14:38] mpt: -funroll-loops does what you'd expect. [14:38] All this time, I thought it was dried fruit leather. [14:38] Hah. [14:42] ogra_, so I can tell you that fewer choices would probably be better, but I am clueless as to which choices to hide or de-emphasize [14:43] mpt, heh, yeah [14:43] More consistently structured titles would be nice, too [14:43] Well, in that screen shot, the only two I would expect people to select are the first one, and the free driver. [14:44] "Regular" users, that is. [14:45] Also, it's not shown in the mockup, but in I suggest that the branch should start by labelling the hardware we're talking about, in this case "Graphics card:" [14:46] (e.g. "Graphics card: NVIDIA G86 (GeForce 8500 GT)") [14:46] infinity, how about steam users ? :) [14:48] ogra_: If we screw it up really badly, they'll end up replacing our dialog with their own. :P [14:48] ogra_: (Steam on Windows has builtin driver updaters for nvidia and ATI) [14:48] haha [14:49] so we should just not change it and wait for the contribution then :) [14:52] mpt: I think initially the "Graphics card: " prefix was there [14:52] not sure why it's not, now [15:02] cyphermox, could you find out? :-) [15:03] mpt: sure. should just be a matter of digging through the branch history [15:03] ta === nenolod is now known as kaniini [16:06] jibel, thanks for the autopkg updates. had some of those done. did you see any other test failures? [16:16] mdz, ping [16:23] infinity, I got two Xen packages in the sru queues for q and p which I would like to see getting accepted for proposed rather sooner that later. Would you be able to work some "magic"? [16:24] smb: Tomorrow, I can. [16:24] infinity, Ok, that would be soon enough for me [16:25] mpt: so much for that theory: http://jsfiddle.net/Ra4xT/4/ (see "Precise (again)") [16:25] it might be a lack of data, but I think I should look for the problem elsewhere before I commit webops to a full run [16:26] ev, are any of those "(original)" lines actually plotted? [16:26] if you click on them they are [16:27] aha [16:27] all the items in the key can be toggled [16:27] unchecking raring makes things much more readable ;) [16:28] ev, is October 11 the date of the first Raring reports? [16:28] (or at least, the first ones included in this sample) [16:28] yeah [16:29] doko, not with 2.7 but there are 4 failures with 3.3 and 3.3dm http://paste.ubuntu.com/5710791/ [16:30] mpt: perhaps it would be interesting to see what this looks like with the weighted data we have, but unweighted [16:30] to see if it's missing data that's proving to be the problem [16:30] that is, taking the the number of instances from the weighted CF and just not weighting them [16:30] I'll do that nowish [16:30] ev, okay, so if the formula was working, then weightedRaring(2012-10-11) = 1/90 * Raring(2012-10-11) = 1/90 * 0.81 = 0.009. [16:30] And it isn't. [16:31] I haven't adjusted raring yet for the second run [16:31] sorry, I've only done precise [16:31] oh. [16:31] probs should've mentioned that === beuno_ is now known as beuno [16:31] ev, that would be the easiest way of telling whether the formula was working, though. Because that's the only date on which all the machines you're seeing for a particular series are brand new. [16:32] ah, I'll run through raring as well. === deryck is now known as deryck[lunch] [16:32] and check that date [16:33] (I'm distinguishing here between "the formula working" and "the formula being correct". We know it isn't correct, but it'll be a lot closer than what we have now.:-) [16:33] :) [16:33] mpt: you do realise we're going to have to give this a fancy marketing name if it gets too far away from "average errors per calendar day" [16:34] jibel, hmm, I didn't see the test_shutil failure [16:34] jibel, is this some kind of summary? note that the failed tests are re-run at the end for details [16:44] hm, no data on systems running raring in this set until 2012-10-23, and even then only 5 [16:44] perhaps I really do need to just bug webops to run the full thing. [16:44] (which would take 2-3 days) [16:44] ev: raring wasn't created until about then. [16:44] oh, strange [16:45] I wonder why we have data from the 11th then [16:45] ev: Any report on raring from 11 October is a misconfigured clock. [16:45] Or something. [16:45] it would imply our clock [16:45] hm [16:45] I'll have to investigate that [16:47] It may have been in existence a bit before the 23rd - would need to check full logs to make sure. But definitely not the 11th, which was a week before quantal release. [16:53] mpt: http://jsfiddle.net/Ra4xT/8/ - added 'Raring (again)' [16:53] I'll get the full data set building (in production) tomorrow [16:55] ev, no need really [16:56] hm? [16:58] ev, November 10th was the 17th day you got reports for Raring. On that day originalRaring = 0.89, so weightedRaring would have to be 17/90 * 0.89 = 0.168 at most, and would probably be much less. But on that graph, it's 0.49. [17:00] ev, whoops, replace "0.89" with "0.81" everywhere above, so weightedRaring would have to be 0.153 at most. The point stands. [17:00] I do worry that the early days of raring are just noise from so few people using it [17:00] slangasek: fyi. bug 1157678 seems to be fixed with a later xserver-xorg-video-intel patch, is this something that should be an FFE for raring, or should wait until the first updates? I know its _really_ late at this point. [17:00] bug 1157678 in xserver-xorg-video-intel (Ubuntu) "unplugging an external monitor from laptop results in corrupted screen. Logging out fixes it." [Medium,In progress] https://launchpad.net/bugs/1157678 [17:01] arges: so the patch applies against the X driver, not against the kernel? [17:01] arges: have you tested cherry-picking this onto current raring? [17:02] slangasek: Yes its X driver. And yes I'm cherry-picking the fix now [17:03] mpt: so something is clearly wrong in the code then [17:03] yep [17:03] okay, I'll have a dig at it tomorrow [17:03] thanks for the math :) [17:04] arges: so it's basically a two-line fix; and there's no FFe needed, this is a bugfix not a feature; if the X folks are ok with it (bryce, tjaalton, mlankhorst?), then we should just take it now === jasoncwarner__ is now known as jasoncwarner [17:05] slangasek: so actually its 9dae6f9f1f169c228929185a8bd94e82afe92574 that fixes the issue (according to Chris Wilson) and that's a pretty large patch. I'm going to test that cherry-picked into the current raring versuion [17:05] arges: ah, ok [17:06] yeah, much bigger change [17:06] most of it's code reorg though [17:07] * bryce looks [17:09] there's some code refactoring there that may be making the patch bigger than it actually is [17:10] bryce: it not a completely clean cherry-pick, but it applies only after a one line move in src/sna/kgem.h [17:12] mm [17:12] arges: Oh, hey, I just ran into that bug this weekend. Yay for it having a fix. [17:13] arges: Anyhow, if you're fixing that, you might also need to fix the driver to not FTBFS. :P [17:13] (Or back out the valgrind changes) [17:13] infinity: : ) yup upstream really helped. [17:13] so essentially it's a) changing from calling sna_mode_has_pending_events() once to "until no events remain" in sna_mode_close(), and b) adding event checking (and a cache cleaning) to sna_mode_resize(). [17:13] infinity: yea looking at that too cause i was going to test the xorg edgers package. [17:13] infinity, what broke exactly? :-/ [17:14] infinity, does removing the added --enable-valgrind in rules fix it? It built fine for me locally. [17:14] bryce: https://launchpad.net/~xorg-edgers/+archive/ppa/+build/4488414 do we need enable-valgrind? === Ursinha is now known as Ursinha-afk [17:14] bryce: Dunno, looks like it's just missing a -I/usr/include/valgrind or something. [17:14] its listed as a dependency [17:15] bryce: I didn't look hard at it, was going to fix tomorrow if no one beat me to it. === Ursinha-afk is now known as Ursinha [17:16] infinity, I'll take care of it. === security is now known as megha [17:17] bryce: so i'm building a test xserver-xorg-video-intel with that cherry-picked patch. How do you guys track patches in this package btw? [17:18] arges, in git [17:18] oooo wheres the git tree? [17:18] https://wiki.ubuntu.com/X/GitUsage [17:18] arges, ^ everything you'd like to know and more [17:18] cool i'll provide a patch that if that makes sense [17:18] bryce: also i have to fix the valgrind.h to backport this patch anyway [17:18] great [17:19] arges, I was just going to revert the --enable-valgrind [17:19] ok either way, just have to use something to get it to build : ) [17:20] (it just slipped it because it was hanging around in the unreleased debian experimental branch) [17:20] bryce: With the current patches applied (which you could revert to the version in the release pocket, I guess), you'll need an explicit --disable-valgrind, since enable is the new default. [17:20] infinity, hmm! [17:21] yep looks like you're right. [17:22] ok in that case, arges go ahead with your fix, that's probably the least invasive solution. [17:22] bryce: Well, that's how I read configure.ac ... But I'm now confused because none of that changed between ubuntu1 and ubuntu2 [17:22] ok its building [17:23] Anyhow, --disable-valgrind is probably less hassle than working up a proper fix for not finding the headers. [17:24] my concern is mainly stability - this is a new feature and if there is one bug somewhere however minor, experience says there's bound to be another... [17:25] bryce: Yeah, but the debdiff between -release and -proposed has no code changes. [17:25] bryce: So changing code now seems like probably not the way forward. [17:27] infinity, you mean because there's nothing aside from the --enable-valgrind in the rules? [17:28] bryce: Yeah... [17:29] well, I'm fine with reverting just that change if that's the cleanest solution, but I'd like to see what arges comes up with first. [17:29] bryce: So, I suspect I misread configure and it defaults to off, since it's clearly not enabled in the previous build. [17:30] bryce: Disabling valgrind is certainly the more tested solution, since we've never successfully built with it enabled. [17:30] bryce: And final freeze is in a few days. [17:30] AS_HELP_STRING([--enable-valgrind], [17:30] [Enables valgrindified ioctls for debugging [default=no]]), [17:31] sounds like, default=no [17:31] bryce: well i just built it with --disable-valgrind, but i'm just trying to test teh cherry-pick for now [17:31] doko, it was a grep FAIL in the logs, here with the traceback http://paste.ubuntu.com/5710948/ , I'll have a look tomorrow morning to eliminate any error that could be introduced by the testing env. [17:31] Yeah, I misread something later in configure.ac ... It was a late night. [17:31] arges, aha alright. [17:31] jibel, thanks! delaying uploads then [17:31] (Not that it's a bad idea to use enable/disable explicitly anyway, so upstream changes don't cause surprises) [17:31] bryce: but i haven't put anything in git, so I can change it accordingly [17:32] infinity, ok good point about final freeze. [17:33] I'll go ahead and revert it. [17:35] ok test build here http://people.canonical.com/~arges/lp1157678.1/ I'll work on the git patch now, since it seems to work for me. [17:37] bryce: is this the tree i need to clone btw: git://git.debian.org/git/pkg-xorg/driver/xserver-xorg-video-intel [17:39] arges: yep [17:40] cool [17:41] arges, yes and use the 'ubuntu' branch [17:42] alright, uploading the --enable-valgrind revert. [17:43] doko: numpy merge I mentioned last week, bug 1168652 [17:43]