[00:44] <Sarvatt> doh, can't even pass LDFLAGS to configure in debian/rules to make xterm build anymore now that gcc changed to default --as-needed apparently
[00:46] <jcristau> fun.  i didn't try --as-needed, thought --no-add-needed would be where most problems would come from
[00:46] <RAOF> Can't you just pass --no-as-needed in LDFLAGS?
[00:47] <RAOF> (Before fixing the buildsystem, of course?)
[00:47] <jcristau> meh, --as-needed is just wrong..
[00:47] <Sarvatt> I dont know how to properly fix this and am just trying to get things building locally at least, https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/677129
[00:48] <ubot4> Launchpad bug 677129 in xterm (Ubuntu) "Please merge xterm 266-1 (main) from debian unstable (main) (affects: 1) (heat: 10)" [Wishlist,New]
[00:48] <Sarvatt> how I "fixed" it to build locally was probably totally wrong :)
[00:52] <jcristau> Sarvatt: run make with EXTRA_LOADFLAGS="-lX11 -lfontconfig"
[00:52] <jcristau> seems to work
[00:54] <jcristau> (ugly workaround, but meh)
[00:55] <jcristau> built for me with http://paste.debian.net/100177/ anyway
[00:57] <Sarvatt> fails needing -lXmu still
[00:58] <jcristau> bleh
[00:58] <jcristau> -lXmu is getting passed here
[00:58] <jcristau> i get -lXft -lXaw7 -lXt -lXmu -lXt -lSM -lICE -lutempter -ltermcap -lX11 -lfontconfig
[00:59] <jcristau> Sarvatt: does gcc 4.4 in natty also do that?  if not you could set CC=gcc-4.4 :p
[01:00] <Sarvatt> yeah I'm so tempted to just CC=gcc-4.4 everything :D
[01:01] <jcristau> sounds like thomas has a patch
[01:07] <Sarvatt> darn, fixes everything but -lX11
[01:09] <Sarvatt> ah crap, missing a new big bang theory :)
[01:09] <RAOF> The internet will have archived it for you :)
[01:10] <Sarvatt> indeed
[01:22] <ScottK> There was a change where the order of LDFLAGS matters now and it didn't before.
[01:22]  * ScottK doesn't recall details.
[01:25] <jcristau> i'm still hoping to avoid the as-needed madness in wheezy
[02:19] <ScottK> At least a Debian release cycle is a little longer to deal with it.
[11:32] <lesshaste> does anyone else have problems with X hanging after a recent update? It just hangs for a few minutes especially when I am running kile. I can go to a VT and strace kile where I see "kile: cannot connect to X server"
[16:37] <Sarvatt> RAOF, bryceh: seen this nugget of awesomeness? http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg00803.html
[17:30] <bryceh> Sarvatt, wow, exactly what we need
[18:21] <ScottK> Wow.  No sarcasm.  Very unusual.
[18:21] <ScottK> (unless my sarcasm meter is way off)
[18:22] <bryceh> ScottK, haven't had my coffee yet
[18:24] <Sarvatt> thats something we were talking about at UDS and turns out someone already did it, very awesome :)
[20:48] <bryceh> Sarvatt_, I'm going to update my mesa snapshot in wayland, and am going to use the latest snapshot in xorg-edgers
[20:48] <bryceh> Sarvatt_, anything I should be aware of?
[20:49] <bryceh> Sarvatt_, also, should I use the debian/ for xorg-edgers or the one from maverick (or natty?)
[20:50] <Sarvatt_> nope, it doesnt really matter if you're not disabling stuff
[20:51] <Sarvatt_> only differences are that it builds the xorg state tracker, has the changes needed to build 7.10, builds vmwgfx, r300g is default, and doesn't have ARB_fragment_shader disabled on gen3 intel
[20:52] <Sarvatt_> also it installs nouveau_vieux for older nvidia
[20:53] <Sarvatt_> well, now that I remember it also installs a bunch more into /usr/lib/dri/gallium for manual use like r600g and swrastg
[20:54] <bryceh> openvg1?  Looks like I had disabled that in my build
[20:54] <Sarvatt_> dunno why
[20:54] <Sarvatt_> thats in ubuntu too
[20:55] <Sarvatt_> the configure flags to enable it in 7.10 are different though
[20:55] <bryceh> think I had a build error vs. egl
[20:55] <bryceh> but I'll try it again enabled
[20:55] <Sarvatt_> oh you passed --disable-gallium and broke the world :)
[20:56] <bryceh> Sarvatt_, what's the commented out i965 gallium 'kill it with fire' stuff?
[20:56] <bryceh> yeah could be
[20:56] <Sarvatt_> i965 gallium driver is severely broken
[21:01] <bryceh> vmware?
[21:01] <bryceh> that'd given be build issues before
[21:02] <Sarvatt_> when you passed --disable-gallium?
[21:02] <bryceh> no after I'd re-enabled gallium
[21:02] <bryceh> you'd also mentioned at the time something about it being sketchy
[21:03] <Sarvatt_> it builds fine on stock natty, i did it last week
[21:03] <Sarvatt_> yeah it's sketchy but is fixing up every copy worth it? :D
[21:03] <Sarvatt_> it's in dri-experimental
[21:05] <bryceh> well I'll give it a try
[21:05] <Sarvatt_> want to start merging 7.10 snapshots in git in preparation and just use that instead of edgers?
[21:05] <bryceh> maybe yeah
[21:05] <bryceh> I'll just go with this for now though
[21:29] <soren> How can I check if a given card is supported? Didn
[21:29] <soren> t there used to be a list of pci id's and how they corresponded to drivers?
[21:30] <bryceh> soren, that's changed.  there's now a file in sysfs for the driver which lists the pci id's the driver supports
[21:31] <bryceh> nouveau_context.c: In function ‘nouveau_context_init’:
[21:31] <bryceh> nouveau_context.c:132: warning: passing argument 4 of ‘nouveau_channel_alloc’ makes pointer from integer without a cast
[21:31] <bryceh> /usr/include/nouveau/nouveau_channel.h:51: note: expected ‘struct nouveau_channel **’ but argument is of type ‘int’
[21:31] <bryceh> nouveau_context.c:132: error: too many arguments to function ‘nouveau_channel_alloc’
[21:31] <bryceh> make[7]: *** [nouveau_context.o] Error 1
[21:31] <bryceh> Sarvatt_, ^ maverick build of mesa failed there
[21:31] <soren> bryceh: Oh, it moved into the kernel?
[21:31]  * soren hasn't kept up, clearly.
[21:31] <bryceh> soren, yeah you may have seen mention of 'KMS'
[21:31] <Sarvatt_> bryceh: bah, libdrm :(
[21:31] <soren> bryceh: Right.
[21:32] <soren> bryceh: Just thought there was still a bit of that stuff left in "userspace".
[21:32] <bryceh> Sarvatt_, well maybe it'll build in the ppa where I have a newer libdrm snapshot
[21:32] <Sarvatt_> guess I had a newer libdrm in the chroot it built in, sorry about that :(
[21:32] <bryceh> this system builds fast but I don't want to install random libdrms and stuff
[21:33] <soren> bryceh: Do you have a maverick or natty system handy to check if 1002:3151 is supported there?
[21:33] <soren> bryceh: I
[21:33] <bjsnider> Sarvatt_, did you see that amusing email from linus today?
[21:34] <bjsnider> http://lists.freedesktop.org/archives/dri-devel/2010-November/005615.html
[21:35] <jcristau> i found dave's reply better
[21:36] <Sarvatt_> same
[21:38] <bjsnider> i'm surprised that the intel driver is smaller than nouveau, i mean fewer lines of code
[21:38] <Sarvatt_> soren: "0x3151","RV380_3151","RV380",,,,,,"ATI FireMV 2400 (PCI)"?
[21:38] <soren> Sarvatt_: Yup.
[21:38] <soren> Sarvatt_: On Lucid,I don't see it in modules.pcimap, at least.
[21:39] <Sarvatt_> yeah dont see it here either
[21:39] <Sarvatt_> I see it in the ddx though
[21:39] <jcristau> bjsnider: less variations in hw
[21:39] <Sarvatt_> alias:          pci:v00001002d00003152sv*sd*bc*sc*i*
[21:39] <Sarvatt_> alias:          pci:v00001002d00003150sv*sd*bc*sc*i*
[21:40] <Sarvatt_> waaaay less
[21:40] <soren> Sarvatt_: http://www.spinics.net/lists/xorg/msg50868.html
[21:40] <soren> Sarvatt_: That one lists it in an Xorg.log. that seems somewhat promising.
[21:41] <soren> ..but now that the kernel's involved, I'm not sure my logic is sound.
[21:43] <Sarvatt_> make it a duplicate of whatever 1002:3155 uses and see if it goes splat :)
[21:43] <soren> Sarvatt_: Trouble is I'm trying to work out if I should buy it.
[21:44] <Sarvatt_> "0x3151","RV380_3151","RV380",,,,,,"ATI FireMV 2400 (PCI)"
[21:44] <Sarvatt_> "0x3155","RV380_3155","RV380",1,,,,,"ATI FireMV 2400 3155 (PCI)"
[21:45] <bjsnider> Like I know the goal here is to create the perfect kernel for hardware Linus owns...
[21:45] <Sarvatt_> tried asking in #radeon? probably just an oversight 3151 didn't get added to the list, newer revision or something not many people have
[21:46] <soren> Sarvatt_: I didn't, but I will now. thanks!
[21:48] <Sarvatt_> hmm
[21:48] <Sarvatt_> soren: this might be interesting https://bugzilla.redhat.com/show_bug.cgi?id=581927
[21:48] <ubot4> bugzilla.redhat.com bug 581927 in xorg-x11-drv-ati "MULI-GPU FireMV 2400 missing pciid + dual screen issue" [Medium,New]
[21:49] <soren> Sarvatt_: thanks!
[21:51] <Sarvatt_> soren: why not go for a hd 5xxx single gpu? they come with up to 6 dp connectors
[21:52] <bryceh> soren, maverick - http://pastebin.com/EeQfiUzr
[21:52] <bryceh> soren, natty - http://pastebin.com/Kh7ea0WF
[21:52] <Sarvatt_> multi-gpu solutions aren't going to be fun
[21:54] <soren> Sarvatt_: No particular reason (other than complete ignorance).
[21:54] <Sarvatt_> a firepro 2460 might be a better option (and cheaper)
[21:55] <soren> Sarvatt_: Excellent. That's the other one I'm considering.
[21:56] <soren> Sarvatt_: I just couldn't even find a PCI id for it, so didn't know where to start.
[21:56] <soren> Sarvatt_: Rocking. I'll just grab one of those.
[21:57] <soren> Sarvatt_: Thanks!
[21:58] <Sarvatt_> 1002:68F1
[21:58] <Sarvatt_> supported by fglrx too if you care about that :D
[21:58] <soren> Sarvatt_: How did you find it?
[21:58] <soren> I looked in an up-to-date pci.ids
[21:58] <soren> No dice.
[21:58] <Sarvatt_> googled FirePro 2460 pci id, its in the description of the second result
[21:59] <Sarvatt_> "ATI FirePro 2460 (FireMV)" = ati2mtag_EvergreenGL, PCI\VEN_1002&DEV_68F1
[21:59] <soren> And here I was, using grep like a sucker.
[21:59] <soren> Sarvatt_: Wicked. Thanks!
[21:59] <Sarvatt_> soren: do you care about 3D performance at all?
[22:00] <bryceh> Sarvatt_, ok the mesa built locally (finally) on my test laptop.  Got a whole mess of W's and E's tho
[22:00] <Sarvatt_> if you're going firepro there are consumer variants that are much faster with 6 displayport outputs even
[22:00] <bryceh> just lintian stuff I guess
[22:00] <jcristau> bryceh: it's mesa, anything other than a mess would be wrong ;)
[22:00] <bryceh> http://pastebin.ubuntu.com/534397/
[22:01] <soren> Sarvatt_: I suppose the price tag is accordingly higher?
[22:01] <Sarvatt_> soren: http://www.newegg.com/Product/Product.aspx?Item=N82E16814102888&nm_mc=OTC-Froogle&cm_mmc=OTC-Froogle-_-Video+Cards-_-Sapphire+Tech-_-14102888
[22:01] <Sarvatt_> not really
[22:01] <Sarvatt_> its at least 8-10x faster of a card
[22:01] <bryceh> I gather all the latest-debian-changelog-entry-without-new-version is just because of pitti's dropping of the changelogs?  Any way we could easily suppress that warning?
[22:02] <soren> Sarvatt_: 3d doesn't really matter.
[22:02] <soren> Sarvatt_: And I like the passive cooling bit.
[22:02] <Sarvatt_> I haven't read up on things lately, there may even be 6870's with 6 dp outputs now too at a cheaper price
[22:02] <Sarvatt_> ah yeah, that firepro is nice in that area, 13 watts max power usage too
[22:03] <Sarvatt_> but its a lot of extra money for the firepro name :)
[22:03] <Sarvatt_> lemme dig around, might be able to find something else
[22:04] <bryceh> re: linus' email... they could cut down on drm churn if they had a better non-code mechanism to deal with monitor and card quirks
[22:06] <soren> Sarvatt_: Thanks, man. I really appreciate it. I gave up on keeping track of graphics cards years, and years and years ago.
[22:08] <Sarvatt_> only 5870's with 6 mini-dp and that firepro 2460 with 4 it looks like, darn
[22:08] <soren> Sarvatt_: They don't have to mini-dp's if that makes a difference.
[22:08] <Sarvatt_> that 2460 is amazingly slow though so I really hope you don't plan on doing anything 3D related
[22:08] <soren> In fact, I prefer DVI.
[22:09] <Sarvatt_> soren: do you have dispayport monitors?
[22:09] <soren> Sarvatt_: Nope.
[22:09] <bjsnider> bryceh, what kind of mechanism?
[22:09] <Sarvatt_> oh thats a problem
[22:09] <soren> Sarvatt_: Yeah, I'd need dongles.
[22:09] <Sarvatt_> active dongles if you use more than 2
[22:09] <Sarvatt_> quite expensive
[22:10] <bryceh> bjsnider, e.g. DeviceTree
[22:10] <Sarvatt_> soren: oh nice! http://www.amazon.com/Accell-B087B-005B-DisplayPort-Single-Link-Certified/dp/B004071ZX0/ref=pd_cp_e_1
[22:10] <Sarvatt_> they got quite a bit cheaper, they used to be over $100 each
[22:11] <Sarvatt_> the active part is really important, you are limited to 2 monitors otherwise if you aren't using native displayport
[22:15] <soren> Sarvatt_: They're (unsurprisingly, I guess) quite silent about that in the product description.
[22:15] <soren> Sarvatt_: Or vague, at least.
[22:16] <soren> Sarvatt_: I would have thought an active component would have some sort of power source.
[22:16] <Sarvatt_> http://www.botchco.com/agd5f/?p=51
[22:17] <Sarvatt_> the evergreen hardware: part of it explains how complicated it is :D
[22:18] <Sarvatt_> hmm, looks like I was mistaken
[22:18] <Sarvatt_> oh nope, "However, you are limited to two active non-DP monitors (due to there only being two PLLs) at a time."
[22:18] <soren> Right.
[22:19] <soren> It's not entirely clear to me if I could get by with two active and two passive converters.
[22:19] <soren> The card seems to come with just one passive converter.
[22:20] <Sarvatt_> passive ones work for up to 2 non displayport monitors, you could have 2 single link DVI with passive converters and 4 native dp at once
[22:21]  * Sarvatt_ is just assuming your monitors dont require dual link dvi
[22:21] <soren> I think I've reached the threshold for how much information I can take in on a Friday evening.
[22:22] <soren> Sarvatt_: Thanks! this has been great. I'll ponder it over the weekend.
[22:22] <Sarvatt_> no worries, good luck with it
[22:27] <Sarvatt_> bryceh: hmm, I haven't noticed any no changelog lintian warnings..
[22:29] <bryceh> Sarvatt_, I figured it out
[22:29] <Sarvatt_> no dh_installchangelogs?
[22:30] <Sarvatt_> yeah no lintian warning, just built xterm
[22:31] <Sarvatt_>         #XXX: FIXME - causes error with copyright file(?!)
[22:31] <Sarvatt_>         #dh_installdocs
[22:31] <Sarvatt_>         #dh_installchangelogs ChangeLog
[22:32] <Sarvatt_> sorry yeah you figured it out :)
[22:41] <Sarvatt_> bryceh: already fix up cairo locally or want me to upload it?
[22:42] <Sarvatt_> (optional)__gnu_lto_v1@Base 1.10.0
[22:42] <bryceh> Sarvatt_, go for it