tjaaltonthe parentheses look confusing :)05:39
brycehtjaalton, the ones around (**experimental** beta) ?05:43
brycehthey appear traditional05:44
tjaaltonthe double ones05:44
tjaaltonnot just for the new driver05:44
brycehoh, gotcha.  yeah, that is a bit weird.  But yeah, traditional05:44
brycehthe first set is part of the title, the second set is added by "something else"05:44
brycehthe important thing here is *yay* experimental drivers install and work05:45
brycehand, *yay* patched up jockey displays everything properly05:45
tjaaltonisn't 304 the stable series and not beta?05:46
brycehpretend it's beta05:46
brycehthe important thing is it's getting sorted as *last*.  Currently the sort is random.05:46
tjaaltonon another note, the #1 intel bug seems to be fixed now, been surprisingly quiet the past 10h05:47
brycehand actually the version in beta right now is a new version (3.04.48) not otherwise available via jockey in precise05:47
tjaaltonnot in the distro yet though05:48
brycehtjaalton, sweet, what was the bug?05:48
tjaaltonbug 96674405:48
ubottuLaunchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Precise) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed] https://launchpad.net/bugs/96674405:48
brycehoh hells yeah05:48
tjaaltonthere's an additional kernel commit that ickle sent to intel-gfx05:48
brycehtjaalton, good work05:49
brycehbtw, I had a call with Intel today in regards to stack updates on 12.0405:49
tjaaltonmost of it was convincing ickle that the bug with suspend & resume is the same one with a normal dmps cycle that people were hitting (as well) :P05:50
tjaaltonnot the backports stuff?05:50
brycehthey'll be providing us with new packaged versions of all the various pieces they want updated on 12.04.  ddx driver, mesa, cairo, etc. etc.05:51
brycehtomorrow I will be hooking them up05:51
brycehwith a PPA they will be posting this stuff to for testing.05:51
tjaalton-intel 2.20.9, libdrm 2.4.39, mesa 8.0.5.. what else?-)05:52
brycehthat, and cairo, intel-vaapi-driver, libva, and...05:53
brycehthey're creating a dkms package of i915 kernel module + dependent modules.05:54
tjaaltonso they'll run the tests and then later ack them for SRU?05:54
tjaaltonthat'll be fun :)05:54
brycehno SRU; ultimate goal will be to get into x-updates.05:54
brycehtjaalton, so in fact I need to touch base with you, Sarvatt, RAOF, and other folks concerned about x-updates, that updating these pieces in x-updates is going to be acceptable.05:55
tjaaltonno objections there05:55
tjaaltonit's opt-in anyway05:56
brycehthink I'll post an email to xorg-devel tomorrow05:56
tjaaltonubuntu-x you mean?-)05:56
brycehthere might be some concern about changing mesa for x-updates since it's also used for updating nvidia and fglrx05:56
tjaaltoni've not used x-updates at all.. will take a closer look soon05:56
tjaaltonbryceh: shouldn't matter05:57
brycehyeah I know.  But I just want to make sure we're all in agreement.05:57
RAOFI'm perfectly happy for intel to push updates into x-updates; that seems eminently sensible.06:02
tjaaltonlet's trick their qa folks into subscribing to -intel bugs.. ;)06:04
brycehRAOF, thanks.  Yeah that's my opinion as well.06:04
brycehtjaalton, haha06:04
tjaaltongen4 chips seem to be getting gpu lockups on quantal06:05
tjaaltonmore than the others06:05
tjaaltonbryceh: so it's them pushing the updates there, or they'll suggest the versions and we upload?06:06
tjaaltonguess the latter would work best06:07
brycehtjaalton, so far it's the  latter06:07
tjaaltonoh hey, looks like the xserver regression with the previous sru for precise that got reverted is fixed now06:08
brycehtjaalton, tomorrow I'll create a staging ppa for them under ubuntu-x-swat.  Later when they feel things are sufficiently good to go they'll cue us to pull stuff into x-updates06:08
tjaalton[PATCH] dix: fix crash on XI 1.x grabs on disabled devices. (#54934)06:08
tjaaltonunless I'm mistaken06:09
tjaaltonbryceh: ok06:09
brycehgreat, what's the bug #?06:09
tjaaltonbug 1021517 (fixed by reverting the sru)06:09
ubottuLaunchpad bug 1021517 in xorg-server (Ubuntu Precise) "Xorg-server crashes reproducible with GIMP usage" [High,Fix released] https://launchpad.net/bugs/102151706:10
tjaaltonbryceh: you could use x-staging for that06:15
tjaaltonwhich reminds me, time to clean it up06:16
brycehtjaalton, ah good idea, I'll consider that06:16
tjaaltonit's only used once per release06:16
tjaaltonand now with -proposed not even that06:17
brycehre bug 1021517, good to hear that's finally getting sorted06:17
ubottuLaunchpad bug 1021517 in xorg-server (Ubuntu Precise) "Xorg-server crashes reproducible with GIMP usage" [High,Fix released] https://launchpad.net/bugs/102151706:17
brycehtjaalton, they may prefer to have a new ppa just for complete isolation.  But I'll think about it tomorrow.06:18
brycehnow that we can fairly easily delete ppas, no harm in creating extras.06:19
tjaaltonit's empty now06:19
tjaaltontime to delete x-retro?-)06:21
tjaaltonoh well, deleted the obsolete packages (for hardy, jaunty, karmic)06:24
tjaaltonhmm so x-staging & x-testing, what's the difference?06:25
tjaaltoncleaning up -testing06:26
brycehtheoretically x-retro should still have a use, although admittedly there's probably nothing for it now06:42
brycehyeah, x-staging and x-testing are probably redundant.06:43
tjaaltonthey're all clean now :)06:44
tjaaltonsorry, left a couple of packages in retro06:44
brycehwe need more community contributors.06:48
jcristaubryceh: you had timo, but then you hired him!07:18
brycehjcristau, indeed... sensing a pattern...07:20
brycehof course, once wayland takes over, we won't have anymore bugs.07:22
* bryceh waves07:29
mlankhorstbryceh: can you endorse my dev application? Also nice work on that nv_exp screen :-)07:30
brycehmlankhorst, alright07:32
brycehmlankhorst, btw time to start thinking about how we can start getting folks testing the LTS point release X stack.  you probably should get in contact with Jono about getting some attention on it in Oct.07:34
mlankhorstI think that's a topic for uds07:34
tjaaltonthere's some oibaf dude doing stuff all on his own: https://launchpad.net/~oibaf/+archive/graphics-drivers07:35
tjaaltonnever heard of him07:35
mlankhorstbut ok I'll just upload all drivers to the ppa again in a bit07:36
mlankhorstI sort of want to have wine-1.5 upgrading properly with the q-lts-backport ppa before I want more widespread testing on it07:37
brycehmlankhorst, good.  Yeah I think UDS may be postponing it too far, you may regret it later.  But if you can get testing started now, you'll be in a much better position when UDS rolls around.07:38
mlankhorstwell the real challenge IS going to be getting fglrx working, the rest should be fine07:38
tjaaltonthere's a compatible version in quantal now07:38
brycehyeah I saw there's a new version today07:39
mlankhorstok in that case I'll just re-upload the entire stack07:39
brycehtjaalton, "oibaf" sounds familiar for some reason07:39
tjaaltonit was on phoronix once, I think07:39
brycehtjaalton, would you mind touching base with him and see if he'd be interested in joining swat?  Looks like a useful fellow.07:40
mlankhorsttjaalton/raof: can you endorse my dev application?07:40
brycehmight be he's only interested in building a side-empire; of course that's fine too.  We should invite him to be part of the team none-the-less.07:41
tjaaltonbryceh: yeah, I could07:41
tjaaltonmlankhorst: sure07:42
mlankhorstrebuilding q-lts-backports atm :-)08:31
mlankhorstweird, my other system has the corrupted bg too09:41
mlankhorstit was still trying the old background but that one was probably removed09:44
mlankhorstso instead it did the insane thing and never drew anything at all :-)09:45
mlankhorstnow I fear that my -all package might not show up in armhf :(09:56
ogra_mlankhorst, why wouldnt it ?10:08
mlankhorstcopied it from a ppa that didn't have it enabled and it didn't list it10:09
ogra_oh, yeah, PPAs are spethial10:09
mlankhorstso just rebuilding now, just in case10:09
mlankhorsttrying to get armhf q-lts-backports too10:11
mlankhorsthttps://launchpad.net/~mlankhorst/+archive/ppa armhf enabled version10:16
ricotzmlankhorst, you probably want to use the newer wayland snapshot while you are using one10:17
mlankhorstricotz: I just take whatever is going to end up in quantal, it's just to satisfy build-depends10:18
ricotzmlankhorst, updating wayland like this will break the current precise mesa if this matters10:20
mlankhorstsigh, I guess the solution would be to rename wayland too?10:20
ricotzi guess so10:20
mlankhorstdoes weston need updates too in that case?10:21
ricotznot sure if this is worth a trouble to prevent runtime breaks but it will break the precise mesa build at least10:21
ricotzmlankhorst, yes, if you want to keep it working ;)10:22
mlankhorstRAOF: ping?10:22
tjaaltonlets just update wayland/weston in precise10:23
tjaaltonnot that it's any use, but neither is the old version10:24
mlankhorstyeah and have it depend on the renamed packages10:24
mlankhorstit should be possible to just use new mesa with old xorg10:24
tjaaltonahh right10:24
tjaaltonnow i see10:24
mlankhorstwon't be really useful10:24
tjaaltondamn build-depends10:24
tjaaltonor just remove the old wayland/weston :)10:25
tjaaltonmaybe not possible, dunno10:25
ricotztjaalton, removing them sounds like a better idea10:25
tjaaltonhmm, same effect really10:25
mlankhorstit's in universe though10:26
tjaaltonmesa needs newer libwayland-dev, so it has to be updated, and no reason to keep the old one10:26
tjaaltonweston maybe10:26
tjaaltonit doesn't matter10:26
mlankhorstoh its not, in main10:26
mlankhorsthowever we could probably update it and make it depend on the new stack if needed10:27
tjaaltonthe old one is obsolete anyway10:27
tjaaltonso just sru whatever ends up in quantal10:27
mlankhorstI'll leave it at the new version for now, I think it builds just fine without the new mesa so there shouldn't be an issue10:27
tjaaltonhmm, there's still the old version in precise, new will end up in -updates10:28
tjaaltonor is it10:28
tjaaltonI don't know how that archive s*it works :)10:28
tjaaltonright, you can use the old one explicitly, -updates will have the new one10:29
mlankhorstyeah it's great fun with all those depends10:29
tjaaltonand mesa is happy10:29
mlankhorstcould try if old mesa builds against new wayland10:30
tjaaltonunless the old mesa isn't happy with the new version (in case there'll be bugfixes)10:30
tjaaltonecho :)10:30
mlankhorst-EAGAIN really10:31
mlankhorstand I didn't even upload xorg-server yet :(10:34
mlankhorstalthough at that part the fun stops since everything is easy from there..10:35
ricotztjaalton, thanks :)10:44
mlankhorstI should probably add the renamed linux kernel to recommends as well10:46
tjaaltonricotz: the other one needs an ffe first10:47
tjaaltonlibbluray looked more like a bugfix release10:47
ricotztjaalton, libaacs is fine already10:49
ricotztjaalton, hmm, my name doesnt come up as uploaded in launchpad for libbluray10:49
tjaaltonooh, syncpackage supports fakesync10:52
cos-hello, ubuntu-bug asks to get technical help first before submitting a new bug but i guess i'll just do it first13:35
tjaaltonjust file the bug13:38
cos-i'm a bit confused about how to set up a elo serial touchscreen.13:41
cos-i tried to follow these instructions https://help.ubuntu.com/community/EloTouchScreen13:41
cos-.. but it says evtouch has been removed from ubuntu13:41
cos-the touch screen is detected by xorg (after running inputattach) but i'm not sure how to configure it13:42
tjaaltongoogle for peter hutterer's blog13:42
cos-should the InputClass definition in xorg work without evtouch?13:42
tjaaltonthere should be instructions for setting it up with -evdev13:43
cos-thanks, found it13:43
cos-i already filed this, but i suppose evdev is the way to go https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-elographics/+bug/105810913:44
ubottuLaunchpad bug 1058109 in xserver-xorg-input-elographics (Ubuntu) "Elographics touch event freezes Xorg" [Undecided,New]13:44
tjaaltonyeah, iirc13:45
cos-i believe i tried everything in this post http://who-t.blogspot.fi/2012/07/elographics-touchscreen-setup.html13:46
cos-i don't have the touchscreen here at work so i could verify but i'll try again next week13:47
cos-the actual problem is that y-coodrinate is reversed and the evdev InvertY option does nothing13:47
tjaaltonok, that's a bug then13:49
cos-should i file it?13:50
smartboyhwcos-, should13:50
cos-if it helps, i can lend the hardware to devs in finland if needed.. and possibly elsewhere unless shipping is very expensive13:51
tjaaltonheh, i'm in espoo13:51
cos-i'm coming to wärk:fest in 3 weeks and could bring the hw with me if needed13:53
ubottuLaunchpad bug 1058120 in xserver-xorg-input-evdev (Ubuntu) "InvertY option is ignored on ELO touchscreen" [Undecided,New]13:58
* mlankhorst wonders if launchpad will time out from simply copying over mesa for 4 archs14:18
=== yofel_ is now known as yofel
mlankhorstwell my local system is definitely beating the launchpad builders23:10

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