=== jcristau_ is now known as jcristau === tseliot1 is now known as tseliot === mac__v is now known as mac_v [16:04] a friend of mine is having a problem with the intel X driver on karmic [16:04] sometimes, after suspend and resume, his display doesn't come back [16:04] like it stays suspended [16:05] this is on a lenovo X200s [16:05] in dmesg, we get this lovely output [16:05] http://paste2.org/p/500664 [16:05] this is where the fun starts: INFO: task i915/0:358 blocked for more than 120 seconds. [16:06] we can ssh into the system after the failure [16:06] though killing X still doesn't appear to solve the problem, it doesn't successfully restart [16:08] bryce: ^ jcastro suggested you might be able to help [16:14] one final item of note, the machine has two displays, and internal one as well as a second connected via "HDMI" (actually displayport in the ultrabase to a DVI converter to a panel) [16:14] both displays blank when we have the issue [16:21] johnf1911: can you reproduce the problem when the external screen is not connected? [16:22] hmm [16:22] I'll ask him to remove the screen and test [16:22] it looks like it's failing to read EDID [16:22] i2c-adapter i2c-2: unable to read EDID block. [16:22] i915 0000:00:02.0: HDMI Type A-1: no EDID data [16:22] I take it there are known problems like this one? [16:22] those messages are a long time before the error [16:23] 3840seconds after boot versus 40 [16:23] I don't believe that's related, it's probably at gdm/X startup [16:24] if you want to get modes you usually try to get EDID first [16:25] also your /var/log/Xorg.0.log should have interesting information (after reproducing the problem) [16:45] there's nothing in Xorg.0.log [16:46] when he runs the machine at home, without the second display, he's never seen the issue [16:46] he's going to explicitly test it tonight to be sure though [16:46] so it may be related to dual head [16:58] ok [17:03] johnf1911: also it would help if he could follow these instructions: https://wiki.ubuntu.com/X/Backtracing#Using Screen to get backtraces for Suspend/Resume crashes [17:05] ok [17:06] if it crashes again today (seems to be once every 2 days, though it may relate to how often he's away from his machine) we'll do that [17:06] I think he's disabled display suspending [17:06] so if it's related to that we won't have a crash, but we will know that it may be related [17:06] thanks for your help [17:15] np === marjomercado is now known as marjo [18:52] jcristau, what are the rules (or best way) when upstream ships no configure, run autoreconf in debian/rules and/or add the generated files to orig.tar.gz? [19:02] tormod, autoreconf is likely better [19:04] bryce, ok but I see sometimes generated stuff added to the tarball, and googled up some comments about being able to build the package on a less equipped system and so on [19:04] you know it's Debian when they talk about end-users running configure :) [19:05] heh [19:06] well, the autoreconf stuff would be run on the build system, not on the user's system (if I'm understanding the issue right) [19:06] yeah I've been known to just redo the tarball with the config stuff in it myself, however I consider that pretty kludgy [19:07] tormod: autoreconf in debian/rules prior to configure, make maintainer-clean afterwards in the clean rule of debian/rules [19:07] i think that's the general approach [19:07] or rm -rf Makefile.in after make distclean [19:07] the debian way is to ship the tarball as distributed by upstream, with no changes [19:07] bryce, that's what I have heard also, but not what I have seen [19:34] jcristau, if you have time to review, it is about http://git.debian.org/?p=collab-maint/intel-gpu-tools.git;a=summary [21:25] RAOF, are your nouveau packages just upstream git + last ubuntu packaging? [21:25] RAOF, ddx I mean [22:30] tormod: Yes they are. [22:30] Actually... let me check the changelog. :) [22:31] tormod: Yes, yes it is. The DRM component isn't, but the DDX is. [22:35] RAOF, then I can just add it to my auto-xorg-git/update-ppa job [22:36] the only catch is the version, you used git+2009, auto-xorg-git uses git2009 :) [22:36] I can add a tweak for that to my nightly script and drop it when we have 0.11 [22:37] tormod: you've got a nightly git building script? [22:37] may i see? [22:37] i might be able to use a few parts for my banshee daily script [22:38] (which doesn't handle anything other than karmic atm) [22:38] tormod: Sweet. I was meaning to automate the nouveau uploads at some point, I just haven't got around to it. [22:39] hyperair, it uses the auto-xorg-git so it will probably not help much for banshee [22:39] and I still have to run it and type in my gpg key [22:39] ah [22:39] i've solved my gpg problems ;-) [22:39] with a little help from seahorse and alarm-clock-applet [22:40] well since I use my personal gpg key it is not a problem but a feature that I have to enter it :) [22:40] * hyperair pulls out the auto-xorg-git script from bzr [22:41] but I would use a more loose key for some autobuilder thingy [22:41] tormod: well yes, i have to enter my passphrase as well. i just got it automated in the sense that it'll automatically run and prompt me [22:41] alarm-clock-applet inherits the GPG_AGENT_INFO from my gnome-session and runs the script at midnight, then seahorse bugs me for the passphrase [22:42] hyperair, sure, I have all that set up, and I use the seahorse(?) caching so I only type it once [22:42] ah. haha [22:43] for anyone curious this is the script I run (almost) every night to keep xorg-edgers up to date: http://ubuntu.pastebin.com/m64eaaf69 [22:43] ah auto-xorg-git manually creates the tarball eh [22:44] I guess I will push it to the bzr repo as well [22:44] hmm interesting [22:45] * hyperair uses git-buildpackage to build tarballs [22:45] I got quite a bit of things automated there that took hours in the early xorg-edgers days [22:46] that's cool [22:46] hyperair, we could maybe use git-buildpackage here also, but it works as it is [22:46] yeah [22:47] eventually, you guys are gonna reinvent gentoo [22:47] ? [22:47] why so? [22:47] http://pastebin.com/f660a0a8 <-- this is my banshee building script [22:47] pwnguin, we publish binaries... [22:48] pwnguin: by building we really mean preparing source packages to upload [22:48] build everything from git head source [22:48] i know [22:48] the difference is that we have our binaries all built in one place [22:48] thats how it starts [22:48] so users don't have to go about wasting the world's precious energy compiling [22:48] then one day someone decides they want to override the C FLAGS env var [22:48] unlike gentoo users >_> [22:50] pwnguin, we stay close to the normal distro packaging, no CFLAGS tweaking etc [22:50] that's when they switch to gentoo. ubuntu will never become a source-based distro. [22:50] hyperair, I think we lack sufficient drama to reinvent gentoo [22:50] bryce: strongly agree. =P [22:51] hyperair, some nice use of git log in your script, instead of my sed/awk hackery [22:51] tormod: hahah thanks. [22:52] well i've no idea how to use awk =p [22:52] so i kinda make do with sed [22:52] that never stops anyone [22:52] well yes, there are great possibilities with sed. [22:52] * hyperair has never needed to learn awk [22:53] Some people, when confronted with a problem, think [22:53] “I know, I'll use regular expressions.” Now they have two problems. [22:53] RE rulez [22:54] xD [22:54] that's a nice quote. [22:54] “If you have a problem and you think awk(1) is the solution, [22:54] it's the cellular automata of information processing [22:54] then you have two problems.” [22:54] but yeah, RE rules. [22:54] pwnguin: then it's the same, isn't it? =p [22:54] ok enough fanboying [22:55] hyperair: predates RE [22:55] " make(1) is employed sparingly for very simple scripts. sed(1) only required to deal with yacc(1) defi-" [22:55] ciency, namely eliminating name clashes. awk is used once in the bootstrap to perform a relatively simple task [22:55] that should probably be done using ed(1), since: ‘‘If you have a problem and you think awk(1) is the solution, [22:55] then you have two problems.’’ - David Tilbrook [22:55] doh [22:55] i'll stop [22:55] heheh [22:59] hmm i should probably make better use of set -e in my script [22:59] rather than those kludgy || return 1s [23:01] hyperair, or at least chain them with && [23:13] bryce, I was thinking I would help out with bringing mesa git up to date [23:13] I looked at bzr-fast-export and git-fast-import but could not really get it working so I scripting up something else [23:14] tormod, that would be great [23:15] fwiw, I probably won't be much help with xorg-edgers this cycle; I suspect for the LTS our eyes are going to be too far behind bleeding edge [23:16] bryce, won't be done today, but I hope to get it done over the weekend [23:16] kewl [23:16] bryce, ok but please try to push radeon KMS [23:16] yep that's the plan [23:16] although not officially EOL'ing it, upstream seems to care less about non-KMS issues [23:16] * bryce nods [23:17] but you are aiming for mesa 7.7 at least? [23:17] not decided yet [23:19] if it makes it by the end of the year, quite possibly [23:19] if it's late into next year, though, we may have to pass [23:19] xorg 7.5 (and xserver 1.7) I guess since it's already in Debian [23:20] yeah I think we'll be looking very strongly at what is in Debian Testing at chrismastime [23:21] so you are not gonna sync everything in experimental at this point? [23:21] I mean if there are things there which might not make it for Testing before Xmas [23:26] dunno yet, I'm still kind of consumed by karmic stuff at the moment [23:26] but I definitely intend to be more conservative this time through [23:27] there's trade offs though [23:27] the goal of LTS is not to have ancient stuff but rather to have stable stuff that can be supported well going forward [23:27] in some cases the bleeding edge stuff *is* the best choice as it's gotten the most debugging and is more likely to be relevant upstream [23:28] in other cases where a lot of development work has gone on compared with the level of testing, it may be safer to hold back a bit [23:28] at this point I'm not sure where the line needs drawn, component by component, and I hope folks can help give good advice so we can make smart decisions on all of this