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:44 |
RAOF | No. | 00:45 |
RAOF | Silly i386-only drivers. | 00:45 |
RAOF | Fixing. | 00:45 |
RAOF | While mesa builds. And builds. And builds! | 00:45 |
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:46 |
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:47 |
bryceh_ | feels like a bug with the logic for drag-to-maximize (monitors are one-above-the-other) | 00:48 |
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 :) | 00:52 |
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:00 |
bryceh_ | I can test -ati on a couple systems once that's in | 01:01 |
bryceh_ | otherwise, things look good | 01:01 |
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:18 |
bryceh_ | hrm, that's wrong; it's trying to depend on the wrong xserver | 01:19 |
bryceh_ | heh, wayland ppa madness. ok nevermind that one | 01:20 |
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:27 |
RAOF | Hm. Ok. Let's see if I can't fix that… | 01:30 |
bryceh_ | heh, crashed unity on my above/below system | 01:32 |
bryceh_ | ok with a couple more dist-upgrades and reboots the 2u1 system is booting 2u2 ok | 01:35 |
RAOF | Who wants to upload a partial fix for the TLS madness? | 03:31 |
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:39 |
RAOF | Ah, wayland testing. | 03:44 |
RAOF | It is perhaps a *little* bit soon for that :) | 03:44 |
ScottK | Right, first you make him to other stuff so that he can prove himself to be allowed to do wayland testing. | 03:55 |
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! | 05:43 |
tjaalton | RAOF: still need sponsoring? | 07:08 |
tjaalton | ah, looks like not | 07:09 |
* RAOF rather likes disassemble/m | 08:29 | |
ara | RAOF, hello | 09:06 |
RAOF | Heydi ho! | 09:06 |
bryceh_ | heya tseliot | 09:21 |
tseliot | hi bryceh_ | 09:21 |
bryceh_ | RAOF, did you push your latest -intel change to git? | 09:51 |
* RAOF checks | 09:52 | |
RAOF | Aha! Mesa's jumping into the NoOp table. That's obviously not going to work :) | 09:52 |
tjaalton | RAOF: also, mesa needs a push | 09:53 |
RAOF | Gah. Yup. | 09:53 |
tjaalton | git push origin; debuild... ;) | 09:54 |
bryceh_ | you have no idea how happy it makes me to know I'm not the only one that forgets sometimes ;-) | 09:56 |
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:57 |
bryceh_ | we should hack 'git status' into dch or dput ;-) | 09:58 |
jcristau | upstream's modular/release.sh has a "did you push stuff to git" check :) | 10:00 |
tjaalton | yeah something similar might be possible | 10:10 |
Prf_Jakob | Sarvatt: Thanks, with that ati driver built and installed, together with the kernel and firmware package I have kms on my cayman. | 11:46 |
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:33 |
tjaalton | 20 per week | 13:34 |
tseliot | tjaalton: I don't think so | 13:36 |
tjaalton | dkms needs such a feature | 13:38 |
tjaalton | since this will repeat every cycle | 13:38 |
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:41 |
tjaalton | it shouldn't try to build the module | 13:42 |
tseliot | ok | 13:42 |
tjaalton | because otherwise apport kicks in | 13:42 |
tseliot | I think we can ask Mario about it | 13:43 |
tseliot | i.e. whether such feature would be accepted upstream | 13:43 |
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:45 |
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:46 |
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 | 13:47 |
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:17 |
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:18 |
cnd | tjaalton, can you enlighten me on how you generate it? :) | 14:19 |
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:20 |
cnd | tjaalton, ahh, thought there might be a way without rebuilding | 14:22 |
tjaalton | hmm didn't need to touch the changelog | 14:25 |
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:27 |
cnd | tjaalton, thanks! | 14:28 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
tseliot | tjaalton: ok, thanks, I'll discuss it with Mario | 14:47 |
tjaalton | cool | 14:47 |
lesshaste | which package has the radeon driver? | 14:50 |
tjaalton | cnd: libavg failed to build on armel https://launchpad.net/ubuntu/+source/libavg/1.5.4-0ubuntu1/+buildjob/2322628 | 15:07 |
cnd | tjaalton, ahh, I'll take a look | 15:08 |
tjaalton | assembler-goodness | 15:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
cnd | tjaalton, jcristau: yeah, I'm thinking they'll probably just wittle the arch list down to x86 | 15:16 |
cnd | but maybe they can nop the one line that calls an x86 assembly function | 15:17 |
tjaalton | actually the errors on debian were due to missing build-deps it seems | 15:18 |
jcristau | hmm. yeah. | 15:18 |
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 | 15:19 |
cnd | bryceh_, when you get a chance, please upload the new xinput (pitti approved it) | 16:31 |
=== TheHarald is now known as apachelogger | ||
=== Sinnerman is now known as Cobalt | ||
Sarvatt | bryceh_: did you upload intel already? you added a few extra sandybridge ids that shouldn't be in there | 19:47 |
Sarvatt | 0100 0104 0108 are bridge chips not GPU's | 19:48 |
bryceh_ | oh ok | 19:49 |
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 | 19:50 |
bryceh_ | cnd, btw pushed | 21:03 |
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:04 |
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:05 |
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:06 |
bryceh_ | fortunately not | 21:07 |
bryceh_ | they had workers out the next day and got everything back to normal in a couple hours | 21:08 |
cnd | that's good | 21:08 |
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:15 |
jcristau | probably | 22:16 |
jcristau | http://intellinuxgraphics.org/how_to_report_bug.html | 22:17 |
bryceh | bdrung, that looks like a bug we already know about (and I think I forwarded it upstream a while back) | 22:19 |
bdrung | bryceh: bug number? | 22:20 |
bryceh | sec | 22:20 |
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:21 |
bryceh | even though it says terminal programs, people see it in firefox too | 22:22 |
bdrung | i saw it in evolution and liferea too | 22:23 |
bdrung | on all my intel system (including sandybridge) | 22:24 |
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:25 |
bryceh | bdrung, probably testing the git commit that ickle pointed to is the next action | 22:26 |
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:27 |
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:28 |
* RAOF checks his mail | 22:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!