[00:44] <bryceh_> RAOF, ok testing going ok so far on some -intel systems but it appears -ati/-radeon is getting uninstalled
[00:44] <bryceh_> also -video-all and -geode get uninstalled
[00:44] <RAOF> Ah, geode.
[00:44] <RAOF> Did I actually upload that?
[00:45] <RAOF> No.
[00:45] <RAOF> Silly i386-only drivers.
[00:45] <RAOF> Fixing.
[00:45] <RAOF> While mesa builds.  And builds.  And builds!
[00:46] <bryceh_> yep, wrong ABI for -ati, says it depends on abi 9
[00:46] <bryceh_> good news is with latest updates unity on dual-head looks a LOT better
[00:47] <bryceh_> although I can't drag windows from external monitor to lvds for some reason (titlebar gets stuck).  Works going the other way though
[00:48] <bryceh_> feels like a bug with the logic for drag-to-maximize (monitors are one-above-the-other)
[00:52] <RAOF> I wouldn't be surprised if unity didn't like that one bit.
[00:52] <RAOF> One on top of the other isn't a common case :)
[01:00] <bryceh_> it's a docking station with the monitor on a ledge above it, so top/bottom makes most sense
[01:00] <RAOF> Yeah, I've used that ordering before, too.
[01:00] <bryceh_> plus probably not a bad thing to be testing an unusual use case ;-
[01:00] <bryceh_> )
[01:00] <RAOF> And things were kinda broken :)
[01:01] <bryceh_> I can test -ati on a couple systems once that's in
[01:01] <bryceh_> otherwise, things look good
[01:18] <RAOF> Man.  Release your shiny new laptops, Sony, so I can build mesa for amd64 and i386 in under 2 hours.
[01:18] <bryceh_> hmm, lots of held-back packages  - http://paste.ubuntu.com/580381/
[01:19] <bryceh_> hrm, that's wrong; it's trying to depend on the wrong xserver
[01:20] <bryceh_> heh, wayland ppa madness.  ok nevermind that one
[01:27] <bryceh_> nope, I'm wrong
[01:27] <bryceh_> on one machine it dist-upgraded to 2:1.9.99.902-2ubuntu2 (and stuff broke as pastebinned)
[01:27] <bryceh_> on another machine it sees 2u2 but only upgrades to 2u1
[01:30] <RAOF> Hm.  Ok.  Let's see if I can't fix that…
[01:32] <bryceh_> heh, crashed unity on my above/below system
[01:35] <bryceh_> ok with a couple more dist-upgrades and reboots the 2u1 system is booting 2u2 ok
[03:31] <RAOF> Who wants to upload a partial fix for the TLS madness?
[03:39] <ScottK> You all ought to go grab this guy: https://lists.ubuntu.com/archives/ubuntu-qa/2011-March/001485.html and explain to him he's supposed to be helping you out.
[03:44] <RAOF> Ah, wayland testing.
[03:44] <RAOF> It is perhaps a *little* bit soon for that :)
[03:55] <ScottK> Right, first you make him to other stuff so that he can prove himself to be allowed to do wayland testing.
[05:43] <RAOF> Argh.  What's happening here?  The disassembly of glGetString shows a perfectly well-behaved crazy dispatch function, but *calling* glGetString through the PLT appears to go to the wrong place!
[07:08] <tjaalton> RAOF: still need sponsoring?
[07:09] <tjaalton> ah, looks like not
[08:29]  * RAOF rather likes disassemble/m
[09:06] <ara> RAOF, hello
[09:06] <RAOF> Heydi ho!
[09:21] <bryceh_> heya tseliot
[09:21] <tseliot> hi bryceh_
[09:51] <bryceh_> RAOF, did you push your latest -intel change to git?
[09:52]  * RAOF checks
[09:52] <RAOF> Aha!  Mesa's jumping into the NoOp table.  That's obviously not going to work :)
[09:53] <tjaalton> RAOF: also, mesa needs a push
[09:53] <RAOF> Gah.  Yup.
[09:54] <tjaalton> git push origin; debuild... ;)
[09:56] <bryceh_> you have no idea how happy it makes me to know I'm not the only one that forgets sometimes ;-)
[09:57] <RAOF> tjaalton: Wheras I like to check that things build *before* pushing to pkg-xorg, so it doesn't work quite as well!
[09:57] <tjaalton> heh, ok
[09:57] <tjaalton> test the build before dch -r
[09:57] <tjaalton> :P
[09:58] <bryceh_> we should hack 'git status' into dch or dput ;-)
[10:00] <jcristau> upstream's modular/release.sh has a "did you push stuff to git" check :)
[10:10] <tjaalton> yeah something similar might be possible
[11:46] <Prf_Jakob> Sarvatt: Thanks, with that ati driver built and installed, together with the kernel and firmware package I have kms on my cayman.
[13:33] <tjaalton> tseliot: is there a way to disable building fglrx dkms for kernels newer than what the driver supports?
[13:33] <tjaalton> new bugs keep flowing in, where the build fails against a backported kernel version
[13:34] <tjaalton> 20 per week
[13:36] <tseliot> tjaalton: I don't think so
[13:38] <tjaalton> dkms needs such a feature
[13:38] <tjaalton> since this will repeat every cycle
[13:41] <tseliot> tjaalton: do you mean a feature to make it skip module builds when using unsupported kernels?
[13:41] <tjaalton> tseliot: for those kernels, yes
[13:41] <tseliot> tjaalton: or are you thinking that it should return a different error
[13:42] <tjaalton> it shouldn't try to build the module
[13:42] <tseliot> ok
[13:42] <tjaalton> because otherwise apport kicks in
[13:43] <tseliot> I think we can ask Mario about it
[13:43] <tseliot> i.e. whether such feature would be accepted upstream
[13:45] <tjaalton> btw, why is _get_newest_kernel* from dkms's common.postinst duplicated in nvidia-current.postinst?
[13:45] <tjaalton> at least they look identical
[13:46] <tseliot> because I originally implemented that function in the nvidia package and then it was accepted in DKMS
[13:46] <tjaalton> ah
[13:46] <tseliot> I can get rid of it
[13:47] <tjaalton> _is_kernel_name_correct too
[13:47] <tseliot> I have other stuff I'm working on for nvidia so I could add that to my todo list
[13:47] <tseliot> yep
[13:47] <tjaalton> ok
[13:47] <tjaalton> cool
[14:17] <cnd> tjaalton, if you're still up for it, the source package for libavg is attached to bug 733247 now
[14:17] <ubot4`> Launchpad bug 733247 in libavg (Ubuntu) "Please upgrade to libavg v1.5.4 (affects: 1) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/733247
[14:18] <cnd> I've been mentoring OXullo on packaging, he seems to have left the source.changes file
[14:18] <cnd> do you need that, or can you generate that yourself?
[14:18] <tjaalton> I can generate it
[14:19] <cnd> tjaalton, can you enlighten me on how you generate it? :)
[14:20] <tjaalton> dunno if there's a better approach than just extracting the source and debuild -S
[14:20] <tjaalton> the changelog needs a touch too
[14:22] <cnd> tjaalton, ahh, thought there might be a way without rebuilding
[14:25] <tjaalton> hmm didn't need to touch the changelog
[14:27] <cnd> tjaalton, I wondered why you would have needed to do that
[14:27] <tjaalton> dunno, some old habit I guess
[14:27] <tjaalton> cnd: anyway, uploaded
[14:28] <cnd> tjaalton, thanks!
[14:40] <tseliot> cnd: do you happen to know something that broke dragging here in LP: 733989 ?
[14:40] <tseliot> bug 733989
[14:40] <ubot4`> Launchpad bug 733989 in xserver-xorg-input-synaptics (Ubuntu) "dragging with Dell Mini 10v track pad is unforgiving (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/733989
[14:40] <cnd> tseliot, let me check
[14:41] <cnd> tseliot, I doubt anything has changed
[14:41] <cnd> there is a difference in natty though
[14:41] <tseliot> cnd: what difference?
[14:41] <cnd> we've enable semi-multitouch in the kernel driver
[14:41] <cnd> but I don't believe this should be causing click and drag to behave differently
[14:41] <cnd> I could be wrong though
[14:42] <cnd> actually, I may be wrong
[14:42] <tseliot> cnd: is there a way to disable it?
[14:42] <cnd> tseliot, let me check
[14:43] <cnd> I was driving the patches for the semi-multitouch functionality
[14:43] <cnd> but then I handed them off to someone else upstream
[14:43] <cnd> and actually, I'm not even sure if semi-multitouch is there :)
[14:43] <tseliot> cnd: ok, thanks
[14:44] <cnd> no, it's there
[14:44] <cnd> tseliot, do you have a mini to test with?
[14:44] <tseliot> cnd: yes, kind of
[14:45] <cnd> tseliot, ok, I'd suggest trying it out
[14:45] <cnd> there was one point where I added a hack to the kernel driver
[14:45] <cnd> to mask out touches in the button area
[14:45] <cnd> so that click and drag still worked
[14:45] <cnd> we may need to add that in
[14:46] <tseliot> cnd: yes, the main problem is that the screen doesn't work at times...
[14:46] <cnd> ugh
[14:46] <tjaalton> tseliot: filed bug 735505 against dkms
[14:46] <ubot4`> Launchpad bug 735505 in dkms (Ubuntu) "RFC: add a mechanism to disable building a module for known bad kernels (affects: 1) (heat: 6)" [Wishlist,New] https://launchpad.net/bugs/735505
[14:47] <tseliot> tjaalton: ok, thanks, I'll discuss it with Mario
[14:47] <tjaalton> cool
[14:50] <lesshaste> which package has the radeon driver?
[15:07] <tjaalton> cnd: libavg failed to build on armel https://launchpad.net/ubuntu/+source/libavg/1.5.4-0ubuntu1/+buildjob/2322628
[15:08] <cnd> tjaalton, ahh, I'll take a look
[15:08] <tjaalton> assembler-goodness
[15:09] <jcastro> hi, are we supposed to be looking for volunteers? https://wiki.ubuntu.com/X/Testing/ProprietaryDrivers/Natty/WeeklyProgram
[15:09] <jcastro> I ran into this page and said "oh maybe I can help here."
[15:10] <cnd> tjaalton, yeah, looks like it just won't work on arm...
[15:10] <cnd> I'll point this out to Oxullo, maybe he can fix it up
[15:10] <tjaalton> jcastro: there's no publid driver to test on ati
[15:11] <tjaalton> cnd: if it's not meant to build there, it can be fixed easily
[15:11] <tjaalton> *public
[15:11] <cnd> tjaalton, what do you propose to fix it?
[15:11] <cnd> other than actually fixing the source
[15:12] <cnd> do you mean to take arm out of the debian/control arch list?
[15:12] <tjaalton> cnd: it's "Architecture: any", change that to "i386, amd64"
[15:12] <cnd> yeah
[15:12] <tjaalton> or is it x86
[15:12] <tjaalton> dunno :P
[15:12] <tjaalton> i386, duh
[15:13] <tjaalton> powerpc failed too
[15:13] <jcristau> seems consistent with https://buildd.debian.org/status/package.php?p=libavg
[15:13] <tjaalton> hehe, right
[15:16] <cnd> tjaalton, jcristau: yeah, I'm thinking they'll probably just wittle the arch list down to x86
[15:17] <cnd> but maybe they can nop the one line that calls an x86 assembly function
[15:18] <tjaalton> actually the errors on debian were due to missing build-deps it seems
[15:18] <jcristau> hmm.  yeah.
[15:19] <jcristau> tjaalton: actually.  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580678#22
[15:19] <ubot4`> Debian bug 580678 in src:libavg "libavg - FTBFS: checking whether the Boost::Thread library is available... no" [Serious,Open]
[15:19] <jcristau> -msse ftl
[15:19] <tjaalton> uh
[16:31] <cnd> bryceh_, when you get a chance, please upload the new xinput (pitti approved it)
=== TheHarald is now known as apachelogger
=== Sinnerman is now known as Cobalt
[19:47] <Sarvatt> bryceh_: did you upload intel already? you added a few extra sandybridge ids that shouldn't be in there
[19:48] <Sarvatt> 0100 0104 0108 are bridge chips not GPU's
[19:49] <bryceh_> oh ok
[19:50] <bryceh_> wasn't clear from https://patchwork.kernel.org/patch/159971/
[19:50] <Sarvatt> guess it doesn't matter in the intel hook, i just added them to the compiz blacklist and blocked compiz on sandybridge systems using discrete gpus in the past :P
[21:03] <bryceh_> cnd, btw pushed
[21:04] <cnd> bryceh_, thanks :)
[21:04] <cnd> bryceh_, btw, we find out on thursday where we're moving to
[21:04] <cnd> exciting times
[21:04] <bryceh_> cnd, awesome :-)
[21:05] <bryceh_> cnd, if it turns out you're moving to Portland, bring a good umbrella.  It's been raining in sheets the last few days
[21:05] <cnd> ugh
[21:05] <cnd> now you tell me...
[21:05] <cnd> :)
[21:05] <bryceh_> and really windy
[21:06] <bryceh_> the other day I watched a humongous limb fall out of one of the trees onto my neighbor's roof
[21:06] <cnd> uh oh
[21:06] <cnd> did it do much damage?
[21:07] <bryceh_> fortunately not
[21:08] <bryceh_> they had workers out the next day and got everything back to normal in a couple hours
[21:08] <cnd> that's good
[22:15] <bdrung> i have font glitches (http://img192.imageshack.us/f/glitches.png/). against which package should i file a bug report? against the intel driver?
[22:16] <jcristau> probably
[22:17] <jcristau> http://intellinuxgraphics.org/how_to_report_bug.html
[22:19] <bryceh> bdrung, that looks like a bug we already know about (and I think I forwarded it upstream a while back)
[22:20] <bdrung> bryceh: bug number?
[22:20] <bryceh> sec
[22:21] <bryceh> https://bugs.freedesktop.org/show_bug.cgi?id=34584
[22:21] <ubot4`> Freedesktop bug 34584 in Driver/intel "[i945gm] Screen Corruption with new Xorg stack with terminal programs (bisected)" [Critical,New]
[22:22] <bryceh> even though it says terminal programs, people see it in firefox too
[22:23] <bdrung> i saw it in evolution and liferea too
[22:24] <bdrung> on all my intel system (including sandybridge)
[22:25] <bdrung> bryceh: should i comment this bug or open a new one?
[22:25] <bryceh> yep, it isn't a terminal-specific issue but something to do with text rendering so affects multiple apps
[22:25] <bryceh> bdrung, comment that bug
[22:26] <bryceh> bdrung, probably testing the git commit that ickle pointed to is the next action
[22:27] <RAOF> That should be available in the drm-intel-next kernel.
[22:27] <bryceh> doesn't sound like there's high confidence it would fix it, but feedback one way or the other would probably help move things forward
[22:27] <bdrung> i am running linux-image-2.6.38-999-generic_2.6.38-999.201103141005_amd64.deb
[22:28] <bdrung> the drm-intel-next kernel is affected too
[22:28] <bryceh> RAOF, btw do you mind chiming in on cnd's email?  I don't know offhand why that doesn't work, maybe you have a guess.
[22:28] <bryceh> bdrung, ok so yup that is probably going to be useful feedback for ickle
[22:31]  * RAOF checks his mail