/srv/irclogs.ubuntu.com/2013/01/31/#ubuntu-x.txt

=== Quintasan_ is now known as Quintasan
=== yofel_ is now known as yofel
ricotzRAOF, hi :)07:53
RAOFricotz: Yo!07:54
ricotzRAOF, how are you?07:54
RAOFricotz: Pretty good.07:54
ricotzRAOF, good, news about Australia arent that good in the last time07:55
RAOFEh, it's just fires and floods.07:55
ricotzRAOF, could you take a look into updating colord? https://launchpad.net/~ricotz/+archive/staging/+sourcepub/2955146/+listing-archive-extra07:55
tjaaltonRAOF: hey, what happened to piglit getting in the archive? was it dropped?07:55
RAOFricotz: I happen to be doing just that now :)07:55
ricotzRAOF, oh, nice07:56
RAOFtjaalton: Weren't you the one who was going to do that?07:56
tjaaltonwas I? :)07:56
tjaaltonsheesh07:56
ricotzheh07:57
tjaaltonok so the first step is to put the packaging somewhere07:57
ricotzis waffle added already07:57
RAOFtjaalton: I'm pretty sure I wasn't going to be doing piglit. apitrace just made it through AA review, though :)07:57
tjaaltonoh I must've mixed it with apitrace07:58
tjaaltonright-o, it was Sarvatt who packaged it for qa07:58
tjaaltonpiglit that is07:58
tjaaltonok I'll talk with him how to proceed07:58
mlankhorsthmz10:57
ricotzMCR1, hi, i hope 12.100~beta3 works alright?12:23
MCR1ricotz: Yep, it does. Thanx a lot. Fast as always ;)12:23
MCR1(I mean your work, not the driver ;))12:24
MCR1ricotz: Although I doubt that one fix of this release was Linux related ;)12:24
MCR1*even one fix12:24
ricotzyeah, since there are no dedicated changelogs it is hard to say12:26
ricotzmlankhorst, hi, did someone had a look at refreshing mesa packaging for the 9.1 branch yet?12:29
mlankhorstI think tjaalton did slightly12:29
ricotzi got scared away through the buildsys changes which made some patches really diverged12:30
ricotz(otherwise there would have been an update in xedgers)12:30
mlankhorstI'm building X on nexus7 atm for testing the input bugs12:31
ricotzmlankhorst, as a side note, not sure if it is worth to take a snapshot of llvm-3.3 to make it possible to build the r600 gallium driver12:32
mlankhorstoh right 12:32
mlankhorstthat's where I stopped on :P12:32
ricotzmlankhorst, https://launchpad.net/~ricotz/+archive/unstable/+sourcepub/2935469/+listing-archive-extra12:33
tjaaltonthat won't happen12:34
tjaaltonaiui12:34
ricotzunderstandable, could be an option of edgers though12:35
ricotzso the only option is to drop the radeonsi driver12:35
tjaaltonyes12:35
ricotzwhich was done in edgers too12:35
ricotztjaalton, do you finished the packaging update by any chance?12:36
mlankhorstcan't we just make a llvm-mesa package?12:36
ricotzmlankhorst, if so we can use a snapshot too12:37
ricotz3.3 is whole different namespace and doesnt interfere with files of 3.2 or less12:37
mlankhorstactually it would need some better name than that12:37
mlankhorstsomething i could copy to precise when the time comes12:38
tjaaltonmlankhorst: it's possible, talk with doko :)12:38
ricotzllvm-3.3 it is12:38
tjaaltonricotz: didn't touch it since two weeks ago12:38
ricotzthey are coinstallable, no need to rename things here12:38
ricotztjaalton, ok, did it build at this time?12:39
mlankhorstok as long as mesa builds with llvm-3.3, it would be fine by me12:40
tjaaltonricotz: seems so12:41
ricotztjaalton, can you push it to debian git?12:42
tjaaltonricotz: yes, later13:31
mlankhorsttjaalton: hm, with http://cgit.freedesktop.org/~whot/xorg-integration-tests/ do you think we could apply for a MRE for xorg-server?13:51
=== bdrung_ is now known as bdrung
tjaaltonmlankhorst: yes, that's the plan14:04
mlankhorstok we'll need to have some ppa with the updated packages though14:05
tjaaltonyup14:05
mlankhorstI was testing with that actually14:05
tjaaltonI haven't looked at xit yet, how is it used?14:07
mlankhorstthe thing seems to be that xorg-gtest will fail to install due to running some tests of its own in the build step14:08
mlankhorstneeds to be run as real root14:09
mlankhorstand needs /dev/uinput too14:11
mlankhorstCONFIG_INPUT_MISC and CONFIG_INPUT_UINPUT with the uinput module loaded..14:13
tjaaltonah, crap14:16
mlankhorst[ RUN      ] XServer.IOErrorException14:16
mlankhorstXIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":133"14:16
mlankhorst      after 7 requests (7 known processed) with 0 events remaining.14:16
mlankhorstFAIL: xserver-test14:16
mlankhorsto.O14:17
tjaaltonlooks like stephen webb filed an ITP for xorg-gtest yesterday14:31
tjaaltonin debian14:31
mlankhorstit restores the error handler for some reason in RegisterXIOErrorHandler14:33
mlankhorstwtf14:35
mlankhorsthow can it be that old_handler be != _XDefaultIOError14:37
mlankhorstsome linking thing?14:38
mlankhorsthm must be14:39
jcristautjaalton: is that somebody you know?14:53
* jcristau doesn't want to end up with two competing packagings for this thing14:53
tjaaltonjcristau: what now?-)14:54
tjaaltonlost me there14:55
jcristaustephen webb14:55
jcristaure: xorg-gtest14:55
tjaaltonah14:55
mlankhorstjcristau: I'm using the debian packaging14:55
* jcristau is confused14:55
mlankhorstgit+ssh://git.debian.org/git/pkg-xorg/lib/xorg-gtest.git14:56
tjaaltonoh14:56
tjaaltonbregmata is a canonical employee14:56
jcristaumlankhorst: that looks way out of date14:56
mlankhorstyes :/14:56
jcristauraring seems to have a 0.7.0 version14:56
mlankhorsthm but no guarantee it's packaged anywhere though, I'll check14:57
tjaaltonhmm, maybe I should ping him that it's taken care of already?14:57
tjaaltonI didn't know it existed under pkg-xorg14:57
tjaaltonjcristau: would piglit make sense under pkg-xorg?14:58
jcristaudunno14:59
mlankhorsthm shall I just import xorg-gtest into git again then?14:59
tjaaltonit's kinda special, always out of date14:59
jcristauwhat's the use case for a piglit package?14:59
mlankhorsthaving the same measuring rod14:59
tjaaltonright :)14:59
tjaaltonbut having the packaging somewhere is useful14:59
tjaaltonerm15:00
tjaaltonprobably would be fine if I ran piglit first to see what it is :)15:00
tjaaltonas a distro package it probably doesn't make sense15:00
mlankhorstjust a bunch of tests, surprisingly it didn't even lock up on nouveau for me15:01
tjaaltoni most likely did run it during last cycle15:01
mlankhorstI guess I'll just update the xorg-gtest branch from ubuntu to debian-experimental branch in git15:12
mlankhorstfinally got xorg-integration-tests to build15:36
mlankhorstdoesn't pass all tests, though :)15:48
tjaaltonmlankhorst: the llvm-config hack in mesa doesn't seem to work with 9.1, or I'm missing some detail17:05
tjaaltonanyway, I'll push the experimental packaging now..17:05
mlankhorsttjaalton: hm would have to check17:08
=== ogra_ is now known as ogra
mlankhorsttjaalton: what version of autoconf?17:44
mlankhorstlooks like the official way to fake it would be to make a temporary symlink in some temp/bin/llvm-config and then just pass it as --with-llvm-prefix=whatever/temp :/17:46
mlankhorstor we could just patch configure.ac again I suppose17:47
mlankhorstbtw I'm getting this on precise17:47
mlankhorstchecking for llvm-config... (cached) llvm-config-3.217:47
mlankhorst../../configure: line 23315: llvm-config-3.2: command not found17:47
mlankhorstso guessing you need to fixup the build-deps17:47
mlankhorstafk a bit, food17:48
tjaaltongetting the same, it should be right..17:53
tjaaltonheh, build-dep on llvm-3.1-dev18:16
mlankhorst;P18:17
tjaaltonstill fails though18:24
tjaaltonchecking for "/usr/lib/llvm-3.2/lib/libLLVM-3.2.so"... no18:24
tjaaltonchecking for "/usr/lib/llvm-3.2/lib/libLLVMTarget.so"... no18:24
mlankhorstugh seems weird18:25
mlankhorstllvm-config-3.2 --libdir ?18:25
tjaaltoni'm building with sbuild18:27
* mlankhorst should set up git-pbuilder at one point18:33
mlankhorst        NOTE: Mesa is attempting to use llvm shared libraries because you have18:36
mlankhorst        passed one of the following options to configure:18:36
mlankhorst                --with-llvm-shared-libs18:36
mlankhorst                --enable-opencl18:36
mlankhorstlooks like /usr/lib/llvm-3.2/lib/libLLVM-3.2.so does not exist, but /usr/lib/llvm-3.2/lib/libLLVM-3.2.so.2 does..18:37
mlankhorstmaybe a packaging error?18:38
bjsnider.so should be in the -dev package18:45
mlankhorstyeah but libLLVM-3.2.so should probably not be in /usr/lib/llvm-3.2/lib/, but /usr/lib/$(arch)18:45
bjsnideri'm rusty on the rules, hold on a sec18:47
bjsniderthe headers go in /usr/include but the .so goes alongside the actual shared lib18:48
mlankhorstyeah18:48
bjsniderso i suppose the -dev has a problem if it isn't installing the .so18:49
mlankhorstit's installing it, but something is installing libLLVM-3.2.so.1 twice..18:49
bjsniderdpkg -S will tell you what is isntalling a particular file18:53
mlankhorsttjaalton: I'll try to get upstream to accept a patch to test for -lLLVM-3.2 first before it tests the location18:53
mlankhorstlibllvm3.2:amd64: /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.118:53
mlankhorstllvm-3.2-dev: /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so                                                                                                                                                     18:53
mlankhorstllvm-3.2-dev: /usr/lib/llvm-3.2/lib/libLLVM-3.2.so.1  18:53
mlankhorstweee18:53
mlankhorstlooks like a bug in the packaging18:56
mlankhorstI'll leave it for tomorrow :/19:07
bjsniderpretty easy fix in that -dev package though19:17
tjaaltonbryce: is it possible for apport to not report false gpu hangs, at least for released versions?19:36
tjaaltonbug 107362619:39
ubottubug 1073626 in xserver-xorg-video-intel (Ubuntu) "Constant "false gpu hang" system alerts" [Undecided,Confirmed] https://launchpad.net/bugs/107362619:39
brycetjaalton, well we can just shut it off entirely for quantal.  19:52
brycewe probably don't care about gpu hangs on quantal anyway19:53
brycetjaalton, I can take care of that19:53
mlankhorstwe sort of do, due to backport stack\19:54
brycetjaalton, for false gpu hangs in development releases, well I don't think we have a sure fire way to distinguish between false gpu lockups and real ones.19:55
brycetjaalton, is there a packaging way we could have the udev rule only be applied for !stable releases?19:57
jcristauan udev rule that does wget http://archive.ubuntu.com/ubuntu/dists/ and looks if there's a newer version? :)19:58
brycejcristau, :-P19:59
mlankhorstdont we already have something like development release in the motd?20:02
tjaaltonthat's what i was thinking20:03
tjaaltonbryce: where does the 'false' part come from?20:03
brycetjaalton, a dialog pops up and asks the user if they experienced a display lockup recently.  If they say 'no', it adds False.20:22
bryceit mostly works but there's about 10-20% false falses20:22
bryceyou know, I could do something as stupid as just take the release YY.MM and compare it to the current date, and then exit the apport hook if it looks released20:23
bryce 20:25
brycetjaalton, mlankhorst:  but this all begs the question - what do we want to do with the gpu lockup bug reports?20:26
mlankhorstit's annoying though20:28
brycewe can't grok them.  In the past I just forwarded them upstream, but invariably they just got set to incomplete with a random selection from ["Need steps to repro", "Test on newer kernel", "This patch should do it, trust me."], then +3 months and close as unanswered.  Then next cycle all the same GPU lockup bugs error #'s start coming in again...20:28
mlankhorstyeah :/20:28
mlankhorstit's been ok fixing some nouveau bugs myself though but the remaining ones.. also hard to get accepted since there aren't always specific launchpad bugs for it (was it this hangbug or that hangbug..)20:29
brycetjaalton, mlankhorst maybe one of you would have better luck working with upstream on forwarding the lockup bugs?20:29
bryceunfortunately people who use the apport hook to report gpu lockups assume that it collects 100% of required info to fix the bug, so rarely say anything, and never provide steps to reproduce20:31
mlankhorstsort of trying to play upstream for nouveau myself, but without steps to reproduce :/20:31
brycebut people reporting reproducible hangs tend to not know to collect the i915 error file and stuff, so require a lot of handholding to get a proper report20:32
brycemlankhorst, yeah you've done a good job tackling the nouveau bugs.20:33
brycemlankhorst, do you mostly use the reported info, or work with the reporter to get more info, or work just on issues you can repro locally?20:33
mlankhorstmostly reproducible ones, and sometimes just cherry picking stuff from mesa git that looks important20:34
brycehmm, I wonder about having the apport hook locally log lockups, and only prompt to file a bug on the 10th visit20:36
brycethen, we may have a situation more likely to have reproduction steps...20:36
mlankhorstwell the problem with apport is it immediately gets into your face20:36
mlankhorstwhich steals focus and is annoying20:36
brycenot much I can do about that :-)20:37
bryce(well, aside from just disabling it entirely)20:37
mlankhorstyeah needs to be rethought :/20:37
bryceessentially it was --> thus begat whoopsie20:38
brycehowever it pretty much has that same flaw20:38
Sarvattjust showing the crash indicator and not showing the popups unless you click it would be nice20:39
mlankhorstindeed..20:39
mlankhorstor just not endless windows popping up, but something more organized20:40
mlankhorstprobably both20:40
tjaaltonbryce: i've worked with ickle more during the past few weeks to sort out any issues with sna in particular20:41
tjaaltonnot via b.fd.o but irc20:41
tjaaltonhelps that he's subscribed to -intel bugs20:42
mlankhorst\o/20:42
bryceSarvatt, explain?20:44
Sarvattlike if you get a crash, you just get the icon up top telling you, and clicking that brings up all the crashes in order like it does now20:45
brycetjaalton, cool.  Would you mind working with him on our gpu lockup bugs as well?20:45
brycetjaalton, at least for the rest of this cycle.  we can re-evaluate again next cycle if we still are seeing lots.20:45
bryceSarvatt, ah.  I don't think I can fix that though.20:46
tjaaltonsure, some are well known already20:46
Sarvattah yeah wasn't talking about intel, just apport/whoopsie in general20:46
bryceSarvatt, ah gotcha20:47
brycewell, I have been looking into how to condense the X hook dialogs, since I know people aren't really looking at them anyway20:47
mlankhorstideally apport would be able to work without user interaction at all..20:47
Sarvattsudo apt-get install ubuntu-desktop^20:48
SarvattThe following NEW packages will be installed:20:48
Sarvatt  apport apport-gtk unity-lens-shopping whoopsie20:48
Sarvattevery machine i have :P20:48
mlankhorstindeed..20:48
mlankhorstapport panicking over a WARN_ON in kernel I added myself for testing ._.20:48
brycemlankhorst, well, my thinking is this - MOST of the time we do need to interact with the user to get more info, but we can either do it *before* the bug is filed or *after*.  The latter requires manpower to do bug triage and ask questions, the former annoys the user with dialogs...20:49
mlankhorstyes, but we should bug the user only once, instead of repeatedly with newly popping up windows20:50
bryceyeah20:51
mlankhorstand definitely apport should shut up if the same thing happens a second time :/20:51
mlankhorstno need to remind me every reboot a WARN_ON happened20:51
bryceheh20:51
brycewell, with X bugs, what I really want is just to get the damn bugs fixed!  If the apport hook never has to fire off, then it doesn't matter how annoying it is.  ;-)20:52
mlankhorstI do care about stability, but if we never needed those hooks why would we add them? best make them as least annoying and intrusive as possible..20:53
Azelphurbryce: That machine with the 7770 we was talking about the other day, I spent another few hours with it today and figured out what was wrong, the ATI drivers refuse to build against the current kernel in Ubuntu 12.10, I booted it up on 3.5 (17) and was able to install the official drivers from amd.com from the debs produced by --buildpkg and then everything worked.22:22
tjaaltonAzelphur: you probably don't have the headers installed, known bug in 12.1022:26
tjaaltoninstall linux-generic and it should pull them22:27
AzelphurI think I had the headers installed, I found a forum post saying that they apparently don't build against 3.7, which is why I downgraded22:27
Azelphurnext time I have access to that box I'll try it :)22:27
tjaalton3.7 isn't "the current kernel" of 12.1022:30
Azelphurah yea, I also upgraded it to xorg-edgers (in an attempt to solve the issues)22:34
Azelphurso perhaps it's the missing headers package that caused all the issues,t hen :)22:34
bryceAzelphur, :-)22:37
bryceyeah all the ppas we have can sometimes cause as much trouble as worth ;-)22:37
Azelphurwell the ppa wasn't the cause, seems like the missing headers was always the cause22:38
AzelphurI tried to do it the normal way first, the weird stuff only came as attempts to problem resolve22:38
Sarvatt3.7 is the default kernel in xorg-edgers for 12.10 yeah :( but there's a fglrx in the ppa that builds against it22:42
Sarvattit's just called fglrx, not fglrx-updates though22:43
Azelphuryea, I'm blaming the missing headers thing for all my issues :P22:46

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!