=== jcristau_ is now known as jcristau | ||
=== tseliot1 is now known as tseliot | ||
=== mac__v is now known as mac_v | ||
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:04 |
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:05 |
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:06 |
johnf1911 | bryce: ^ jcastro suggested you might be able to help | 16:08 |
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:14 |
tseliot | johnf1911: can you reproduce the problem when the external screen is not connected? | 16:21 |
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:22 |
johnf1911 | 3840seconds after boot versus 40 | 16:23 |
johnf1911 | I don't believe that's related, it's probably at gdm/X startup | 16:23 |
tseliot | if you want to get modes you usually try to get EDID first | 16:24 |
tseliot | also your /var/log/Xorg.0.log should have interesting information (after reproducing the problem) | 16:25 |
johnf1911 | there's nothing in Xorg.0.log | 16:45 |
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:46 |
tseliot | ok | 16:58 |
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:03 |
johnf1911 | ok | 17:05 |
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:06 |
tseliot | np | 17:15 |
=== marjomercado is now known as marjo | ||
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? | 18:52 |
bryce | tormod, autoreconf is likely better | 19:02 |
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:04 |
bryce | heh | 19:05 |
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:06 |
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:07 |
tormod | jcristau, if you have time to review, it is about http://git.debian.org/?p=collab-maint/intel-gpu-tools.git;a=summary | 19:34 |
tormod | RAOF, are your nouveau packages just upstream git + last ubuntu packaging? | 21:25 |
tormod | RAOF, ddx I mean | 21:25 |
RAOF | tormod: Yes they are. | 22:30 |
RAOF | Actually... let me check the changelog. :) | 22:30 |
RAOF | tormod: Yes, yes it is. The DRM component isn't, but the DDX is. | 22:31 |
tormod | RAOF, then I can just add it to my auto-xorg-git/update-ppa job | 22:35 |
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:36 |
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:37 |
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:38 |
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:39 |
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:40 | |
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:41 |
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:42 |
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:43 |
tormod | I guess I will push it to the bzr repo as well | 22:44 |
hyperair | hmm interesting | 22:44 |
* 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:45 |
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:46 |
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:47 |
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:48 |
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:50 |
tormod | hyperair, some nice use of git log in your script, instead of my sed/awk hackery | 22:51 |
hyperair | tormod: hahah thanks. | 22:51 |
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:52 | |
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:53 |
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:54 |
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:55 |
hyperair | hmm i should probably make better use of set -e in my script | 22:59 |
hyperair | rather than those kludgy || return 1s | 22:59 |
tormod | hyperair, or at least chain them with && | 23:01 |
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:13 |
bryce | tormod, that would be great | 23:14 |
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:15 |
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:16 | |
tormod | but you are aiming for mesa 7.7 at least? | 23:17 |
bryce | not decided yet | 23:17 |
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:19 |
bryce | yeah I think we'll be looking very strongly at what is in Debian Testing at chrismastime | 23:20 |
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:21 |
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:26 |
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:27 |
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 | 23:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!