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