[00:07] <Sarvatt> bryceh: wow, thank you very much for that endorsement! I haven't even filled out the application yet! :)
[00:14] <bryceh> no prob
[00:45] <bryceh> you can probably hit pitti, raof, and tjaalton up for them too I'd imagine.  Might be worth getting one from a non-X guy too if you know anyone
[01:59] <bryceh>  "Wayland+Unity = Weyland-Yutani?"
[01:59] <ion> hah
[02:00] <ion> The combination should have a similar logo, but with a U in the background instead of the V. :-)
[02:00] <ion> instead of the Y i mean.
[02:17] <RAOF> Come on, build!  Poppa needs a new libdricore!
[02:28] <bryceh> man, airlied is harshing on anyone with a ubuntu bent on #wayland
[02:29] <bryceh> (and after mark's announcement, there's a *lot* of ubuntuers on #wayland)
[02:29] <RAOF> I should probably add #wayland to my list of idling channels.
[02:34] <bryceh> it's been rather humorous the last few days
[02:35] <bryceh> TONS of newb questions.  "When will Ubuntu be moving to Wayland?"  "What the difference between X and wayland?"  "How does Wayland handle network transparency?"
[02:36] <RAOF> MAGIC!
[02:36] <ion> Hah
[02:38] <RAOF> But you could actually do some rather funky network transparent stuff with fake drm devices if you wanted to.
[02:38] <bryceh> randomly, I discovered two other canonical folks interested in doing wayland-related work on the channel, whom I'd never met or known before
[02:39] <bryceh> yeah the n.t. stuff is a faux issue
[02:39] <RAOF> I know Robert Ancell is interested in making lightdm work for wayland.
[02:39] <bryceh> but if you're a magazine author, it makes it sound like you understand deep X jujitsu if you mention it
[02:39] <RAOF> :)
[02:45] <ion> I think it would be great for X to be a thin layer that draws Wayland windows, in equal position with native Wayland programs as well as implementations of other networked UI protocols. Adequately small programs that do one thing as well as possible, Unix style. :-)
[02:48] <RAOF> You can run X as a wayland client right now; there's even some work to make it more performant in that case.
[02:50] <ion> cool
[04:12] <ScottK> Sarvatt: If you have something that needs sponsoring, let me know.  Then I could comment on your application as a sponsor (which carries more weight).
[04:48] <bryceh> Sarvatt, http://launchpadlibrarian.net/58860810/buildlog_ubuntu-maverick-i386.xserver-xorg-video-intel_2%3A2.12.0-1ubuntu6~bryce_FAILEDTOBUILD.txt.gz
[16:45] <ricotz> stgraber, hello, is there a new (minor) release of ltsp planned? will it be compatible with lucid?
[18:17] <stgraber> ricotz: nothing is planned so far for lucid, though I know a colleague of mine backported my upstream snapshot of LTSP (ldm and ltsp) to lucid (currently in https://launchpad.net/~mgariepy/+archive/backports for testing, will be copied to https://launchpad.net/~revolution-linux/+archive/ppa once tested)
[18:17] <stgraber> ricotz: once it's copied in ~revolution-linux, it means that my company is using it in production and that most features will have been tested
[18:18] <stgraber> ricotz: we know that the current package has a small bug with ltsp-remoteapps (new feature we implemented last week) but should be fixed upstream this afternoon and backported again
[18:21] <ricotz> stgraber, thanks for answering, i would use them in a critical environment, currently i use the maverick packages comiled under lucid
[18:21] <ricotz> stgraber, i saw there was quite some progress since the latest release, so i was just curious
[18:23] <ricotz> stgraber, so there no dependency changes which arent available with lucid
[18:24] <ricotz> stgraber, introducing new features in a micro release update doesnt sound that good, arent there any sru update considered?
[18:32] <stgraber> ricotz: well, sru are there for bugfixing and I'm not really sure of what I'd bugfix in lucid. For our customers we usually work with the PPA as we can do our changes upstream, release and then backport + test before deploying.
[18:36] <ricotz> stgraber, there are always bugs ;-), and the lucid lts release is a good candidate for using it with ltsp in a buisness environment
[18:37] <ricotz> stgraber, i will have a look at the ppas you mentioned
[19:19] <Sarvatt> hmm, radeon mesa classic drivers support egl now too
[20:57] <bryceh> heh http://www.phoronix.com/scan.php?page=news_item&px=ODc2Nw
[20:58] <ion> :-)
[21:38] <bryceh> Sarvatt, http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/versions-current.html
[21:39] <Sarvatt> woohoo, thanks bryce!
[21:40] <Sarvatt> hate how auto syncs dont show up on natty-changes
[23:06] <Sarvatt> darn, just when I thought we could start syncing xterm - http://sarvatt.com/downloads/xterm_266-1_i386.build
[23:08] <jcristau> sigh
[23:14] <jcristau> and dickey's autoconf stuff is some custom weird version, so patching it is going to be fun
[23:15] <Sarvatt> coming soon to a wheezy near you!
[23:16] <jcristau> easiest would probably be to report it to him, and ask if he can add -lfontconfig for 267
[23:23] <Sarvatt> more fun!
[23:23] <Sarvatt> /usr/bin/ld: main.o: undefined reference to symbol 'XGeometry'
[23:23] <Sarvatt> /usr/bin/ld: note: 'XGeometry' is defined in DSO /usr/lib/libX11.so.6 so try adding it to the linker command line
[23:23] <Sarvatt> /usr/lib/libX11.so.6: could not read symbols: Invalid operation
[23:24] <RAOF> What a pointless message!
[23:25] <Sarvatt> and now this after -lfontconfig -lX11
[23:25] <Sarvatt> /usr/bin/ld: cachedGCs.o: undefined reference to symbol 'XmuReleaseStippledPixmap'
[23:25] <Sarvatt> /usr/bin/ld: note: 'XmuReleaseStippledPixmap' is defined in DSO /usr/lib/libXmu.so.6 so try adding it to the linker command line
[23:25] <Sarvatt> /usr/lib/libXmu.so.6: could not read symbols: Invalid operation
[23:26] <RAOF> Someone will have a good reason why ld can't just do the right thing.
[23:27] <Sarvatt> like http://wiki.debian.org/ToolChain/DSOLinking ?
[23:31] <RAOF> That doesn't seem
[23:31] <Sarvatt> sane? agreed
[23:31] <Sarvatt> it builds with http://sarvatt.com/downloads/patches/xterm-linking.patch
[23:32]  * RAOF wants his desktop-unity.  Vertical space is a non-renewable resource.
[23:32] <Sarvatt> plink.sh agrees the linking is needed at least
[23:34] <Sarvatt> surprisingly I have way more than I know what to do with now :)
[23:34] <Sarvatt> i've been using 1024x600 99% of the time for the past 2 years and just switched to 1920x1080, dont know what to do with it
[23:36] <RAOF> Well, there's the first 3D bug to deal with in the compiz 0.9.2 switch; the new compiz hits an assert somewhere in r600g on evergreen.
[23:37] <JanC> hm, Intel works on Xephyr-with-OpenGL-support? that would be useful to have...
[23:38] <Sarvatt> looks like fedora links against ncurses instead of libtermcap and does a sed on the Makefile after configure to add the -lXmu 
[23:39] <Sarvatt> xephyr? hosted X is the new hotness!
[23:39]  * Sarvatt runs away from wayland talk
[23:42] <RAOF> Bah.  Dear intel: kindly release Sandybridge, so I can get a faster laptop.  Kthxbye.
[23:44] <Sarvatt> I broke down and got one now, not exactly confident sandybridge 3D on linux will be worth a crap in the next year and settled for a real GPU :)
[23:45] <RAOF> But the CPU itself is so shiny and fast!
[23:46] <RAOF> Someone just needs to make a 12" gaming laptop for me.  I'd even accept 13" :)
[23:49] <RAOF> With nice new ATi graphics, a large rust-bucket hdd and a smaller superfast ssd, a quad core, 8GiB RAM, and 9 hour battery life.
[23:50] <RAOF> And maybe a pony.
[23:50] <JanC> Sarvatt: yeah, I saw something about the "hosted Xorg" too, not sure if it supports OpenGL? in any case, something that can be used to let multiple users use OpenGL on 1 multihead graphics card...  ;)
[23:51] <RAOF> That should work now with kms, right?
[23:52] <JanC> hm, I should look up documentation on that then