[00:54] <Sarvatt> lol man, I feel like an idiot
[00:54] <Sarvatt> i've been trying to get that ati gallium patch working right, but every time i changed it i only installed xserver-xorg-video-ati so i wasn't even testing the new changes :)
[01:00] <Sarvatt> so the little one line change works, here i was rewriting it all
[01:25] <Sarvatt> yep patch looks good to go, can't seem to break it. sent it to dri-devel and xorg-devel
[01:43] <m3ga> i'm trying to boot lucid on a tablet device but something during boot screws up the graphics. i've tried booting with 'single' and 'text' on the kernel command line but that doesn't help.
[01:43] <m3ga> i suspect something in the kernel initialisation is tweaking something it shouldn't.
[01:44] <m3ga> if i put init=/bin/bash on the command line i get a prompt and can remount the usb-key rw. but i'd like to fix this.
[01:44] <m3ga> any clues on how to move forward?
[01:45] <RAOF> m3ga: Try with “nomodeset” on the kernel command line.  That'll disable kernel modesetting, which should stop the kernel touching your display hardware quite so much.
[01:47] <m3ga> RAOF: bingo. I have a login prompt. thanks!
[01:47] <RAOF> m3ga: What hardware is that?  Could you please file a bug?
[01:48] <m3ga> its a 'hanvon B10' tablet. what package should i log a bug against?
[01:49] <m3ga> nice tablet btw. 1.3G Celeron. all intel devices. pretty sure the graphics is *not* gma500.
[01:49] <RAOF> Run “ubuntu-bug linux”.  That'll file a bug against the kernel, which is the problem here.
[01:49] <m3ga> cool. will do.
[02:11] <m3ga> RAOF: false alarm. i was booting the karmic kernel by mistake. the lucid kernel does the right thing even without 'nomodeset'.
[02:13] <Sarvatt> pretty sure its because it has an lvds without a lid so the old karmic kernel just thought there were no screens, they fixed that in .32
[02:14] <m3ga> ah, that makes sense
[02:15] <Sarvatt> i was writing patches for an insane amount of similar chinese knockoff intels with the same problem and was glad they changed the default.. crappy bioses :)
[02:15] <m3ga> now getting a kernel message '[drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 27'
[02:15] <m3ga> is that a crappy bios? :-)
[02:16] <Sarvatt> can just ignore it unless things are broken?
[02:16] <m3ga> ignoring for now
[02:23] <m3ga> RAOF: this is the hardware : http://www.hanvon.com/en/products/touchpad/touchpad_B10.html
[02:56] <Sarvatt> m3ga: can you sudo lspci -vvnn | pastebinit ?
[02:56] <Sarvatt> just curious, looks like a fun toy :)
[02:57] <m3ga> Sarvatt: give me half an hour or so
[03:02] <Sarvatt> most likely the wufu just isnt supported yet without external drivers, vendor id 05E1 prodict id 0100 are the important parts, looking now
[03:19] <bjsnider> wufu?
[03:24] <Sarvatt> m3ga: the drivers are pretty nasty, overwrites policykit, disables your sources and makes you only use their mirror in taiwan, and they only have modules for karmic even though it says its for lucid
[03:27] <Sarvatt> i went over the blobs in the there but it doesnt look like any wifi chipset i know about
[03:28] <Sarvatt> m3ga: just google 3dsp wifi linux and see if you can find any guides, better off just replacing it with anyther card though :)
[03:29] <Sarvatt> Thanks a lot for you using our products. We would like to provide source code to you! but it will be very hard to maintain and support due to its complicacy. and I believe the day we open source code will come soon.
[03:29] <Sarvatt> i like that response :)
[03:42] <Nafai> Hi guys :)
[03:42] <Nafai> so something I upgraded in the last couple of days is causing nvidia-settings to segfault on startup
[03:43] <Nafai> but even after installing the dbgsym package, the gdb backtrace may not be that useful :(
[03:43] <Nafai> http://gist.github.com/438631 
[03:51] <bryceh> Nafai, lynx or meerkat?
[03:51] <Nafai> lynx
[03:52] <bryceh> alright, couldn't even begin to guess, sorry
[03:52] <bryceh> I guess, figure out what it was you upgraded and try downgrading it.  ;-)
[03:57] <Nafai> :)
[04:02] <Sarvatt>  nvidia-settings --no-config work?
[04:03] <Nafai> Nope, same problem
[04:03] <Sarvatt> http://ddebs.ubuntu.com/pool/main/n/nvidia-settings/
[04:05] <Nafai> already have that installed :(
[04:11] <Sarvatt> can ya grab debug packages for all of the rest of the depends too and get a bt full?
[04:12] <Sarvatt> i can't reproduce on stock lucid, got any wacky gtk related ppa's enabled? :)
[04:12] <Sarvatt> oh
[04:12] <Sarvatt> ** (nvidia-settings:3303): CRITICAL **: menu_proxy_module_load: assertion `dbusproxy != NULL' failed
[04:12] <Sarvatt> yep its gtk
[04:13] <Sarvatt> iget the same segfault it looks like with geany if i have indicator-appmenu open
[04:14] <Nafai> ah, that probably is it
[04:14] <Nafai> I can do a ppa purge on that
[04:17] <Sarvatt> nvidia-settings is open source btw if you want to figure out why - http://cgit.freedesktop.org/~aplattner/nvidia-settings/tree/
[04:27] <m3ga> Sarvatt: what kind of crack must they be smoking to think that replacing the normal sources.list is acceptable?
[04:30] <Sarvatt> its to stop you from upgrading away from their policykit replac...err rootkit
[04:33] <m3ga> i'm currently evaluating this for the company i work for. if it works out we'd be buying them in lots of 1000
[04:34] <m3ga> i'll come back to wifi after i get X working
[04:36] <Sarvatt> x isnt working?
[04:36] <Sarvatt> well the touchscreen most likely has problems
[04:37] <Sarvatt> RAOF: i'm kind of confused by mesa/LLVM
[04:37] <Sarvatt> i mean, it looks like llvm support is all or nothing
[04:37] <Sarvatt> i see the llvm symbols in the libs and stuff, but llvm isn't getting pulled in as a dep?
[04:37] <RAOF> Well, it certainly wanders all through the code.
[04:38] <RAOF> That seems odd, unless a lot of llvm is inline or something.
[04:39] <Sarvatt> not to mention it looks like enabling llvm makes the gallium stuff x86/SSE2 only so not really compatible with i686 we have going? i dunno
[04:39] <RAOF> Really?  Wow.
[04:39] <RAOF> Well, we could always… build mesa _yet_ another time :)
[04:41] <Sarvatt> i enabled llvm in edgers because it was supposed to speed up swtcl chipsets with r300g but i think i'll back that out for sure.. :D
[05:08] <Sarvatt> i think i hate the nvidia-graphics-drivers build system more than mesa's and it's nothing but shuffling around files...
[05:42] <superm1> Sarvatt, i thought tseliot spent a lot of time cleaning it up the last cycle
[05:43] <superm1> what's janky about it now?
=== Bernardo is now known as Bernardo|Away
=== Bernardo|Away is now known as Bernardo
=== Bernardo is now known as Bernardo|Away
=== Bernardo|Away is now known as Bernardo
=== Bernardo is now known as Bernardo|Away
=== Bernardo|Away is now known as Bernardo
[07:16] <Sarvatt> oh I don't know, the 53 nested variable maze in the rules is fun to maintain when they completely redo the package layout upstream :)
[07:17]  * Sarvatt tries to figure out what PIPE_CAP_DEPTHSTENCIL_CLEAR_SEPARATE is why its busted on nouveau
[07:31] <RAOF> Sarvatt: How far through the fun of forward-porting the intel 2.7 DDX to 1.9 did you get?
[07:32] <Sarvatt> /usr/lib/dri-gallium totally breaks glx over ssh
[07:33] <Sarvatt> good question, i dont remember
[07:33] <Sarvatt> let me try to find where i was working on it
[07:34] <RAOF> Because I was talking to (I think!) ickle in #intel-gfx, and he suggested that an essentially-equivalent task was to add a non-GEM codepath for the current DDX, and that he wasn't averse to participating in such an enterprise.
[07:36] <Sarvatt> sheesh i've got 2663 directories in my git packaging directory, i know i was working on it in a stupid subdirectory like temp8/ or something too
[07:36] <RAOF> Yay organisation! :)
[07:37] <RAOF> Also, there's some more nvidia-graphics-drivers goodness in the xorg apport script now, attempting to detect manually-installed nvidia drivers and grabbing the appropriate logs for forwarding them upstream.  Feel free to suggest improvements.
[07:38] <Sarvatt> why not just make it run nvidia-bug-report and attach those logs? :)
[07:43] <RAOF> Because nvidia-bug-report is a little bit evil.  Particularly - it'll always dump the log in the current directory, whatever that might be.  Also, it's less easy to get at the data in nvidia-bug-report.log.gz
[07:47] <Sarvatt> i can't find anything, guess I didn't do more than 2.8.0 :(
[07:47] <Sarvatt> or i trashed it already
[07:48] <Sarvatt> ah i remember now, i was going through the list then i found http://cgit.freedesktop.org/~airlied/xf86-video-intel/ and got caught up messing with that
[07:48] <RAOF> Is that a 2.2 DDX + patches?
[07:51] <Sarvatt> yeah from RHEL, backported a crapload of kernel changes for new hardware to UMS
[07:51] <Sarvatt> i got kind of discouraged about 2.7.1 because I remembered that was the peak of intel driver crappiness :)
[07:52] <bryceh> peak?
[07:52] <Sarvatt> yeah jaunty!
[07:52] <Sarvatt> i mean both EXA and UXA completely blew and it wasn't hardly usable
[07:52] <bryceh> yep
[07:53] <RAOF> I don't think I _had_ an intel graphics card for Jaunty.
[07:53] <Sarvatt> oh jaunty was 2.6
[07:53] <Sarvatt> http://global.phoronix-test-suite.com/index.php?k=profile&u=robert-14462-8152-19051
[07:54] <bryceh> right, 2.6.  *shudder*
[07:57] <RAOF> Right.  Let's crash i965_dri.so and see if I can't get a better backtrace this time…
[07:58] <RAOF> Gah.  Alternatively, it could be a bug that only appears when not built with -O0
[08:03] <bryceh> Sarvatt, mm - http://people.ubuntu.com/~fta/ppa-dashboard/ubuntu-mozilla-daily--ppa.html
[08:03] <Sarvatt> oh he's been changing that, looked different last i saw it
[08:06] <Sarvatt> oo he released the source! https://code.edge.launchpad.net/~fta/+junk/ppa-dashboard.trunk
[08:10] <RAOF> So, gaussian blur on a GM45 does not provide the world's most responsive desktop environment.
[08:12] <hyperair> 965 doesn't like it either
[08:12] <Sarvatt> i dont even like any blur with ambiance/radiance RGBA
[08:12] <hyperair> rather, it doesn't like any kind of blurring.
[08:15] <RAOF> So, now lets see if using the version built with -O2 segfaults.
[08:18] <Sarvatt> python-launchpadlib in jaunty doesn't support anonymous login :(
[08:22] <Sarvatt> http://sarvatt.com/dashboard/
[08:22] <bryceh> Sarvatt, jaunty?
[08:22] <bryceh> Sarvatt, might be a newer version in a ppa
[08:23] <Sarvatt> yeah latest ubuntu I can run on my VPS since upstart doesn't work in openvz
[08:23] <bryceh> oh bummer
[09:08] <bryceh> yay lp #589811 is fixed
[09:08] <ubot4> Launchpad bug 589811 in xorg-server (Ubuntu Maverick) (and 2 other projects) "My email address is in Xorg.0.log so users email me directly for support (affects: 1) (heat: 281)" [High,Fix released] https://launchpad.net/bugs/589811
[09:28] <Sarvatt> lol
[09:29] <Sarvatt> i dont even see email that isn't labeled anymore because i've got so much like that, got too trigger happy subscribing to bugs for awhile there too :)
[09:31] <Sarvatt> dont think i'll get around to refreshing the lcdfilter patch in cairo, 13 hunks failed
[09:32] <RAOF> Isn't it 1am or somesuch ungodly time where you are?
[09:32] <Sarvatt> and it doesn't build with gcc-4.5 apparently, boo!
[09:32] <Sarvatt> 4:31
[09:32] <Sarvatt> :)
[09:33] <Sarvatt> debian isn't packaging cairo-perf with this, think i'll add that
[09:34] <Sarvatt> people are going to complain if i upload cairo without the lcdfilter patch though :(
[09:34] <Sarvatt> maybe not so much since firefox bundles cairo
[09:34] <seb128> our firefox bundles the lcdfilter patch though
[09:35] <seb128> we got lot of complain when we didn't have it
[09:35] <Sarvatt> yeah thats what I mean, wont be that big a deal since crappy firefox was the big complaint :)
[09:35] <seb128> lol
[09:43] <Sarvatt> what was the trick you guys use to regenerate 99_autoreconf.patch?
[09:44] <hyperair> autoreconf -vfi?
[09:44]  * hyperair doesn't like autoreconf patches, they're bulky.
[09:49] <Sarvatt> yeah same here, just all the darn desktop packages use it. i found it in an old log, cdbs-edit-patch
[09:51] <seb128> Sarvatt, cdbs-edit-patch 99_autoreconf.patch
[09:51] <seb128> autoreconf
[09:51] <seb128> rm -r autom4te.cache
[09:51] <seb128> exit
[09:52] <seb128> Sarvatt, we are moving to run autoreconf in the rules this cycle
=== 17SAAXETA is now known as gomyhr
=== apachelogger is now known as fluffymaster
=== go is now known as gomyhr
[10:22] <Sarvatt> so source format 3 packages get their patches applied at source extraction time? this build kept failing because git checkouts don't work since they weren't applying the patches, plus the clean rule completely doesn't actually clean it
[10:22] <Sarvatt> clean rule does         rm -f *-stamp, stamps are *-stamp-*
[10:58] <Sarvatt> ok no lcdfilter patch is not an option, this is horrible :)
[11:44] <maxb> Sarvatt: The (slightly odd to me) convention that bzr-builddeb is encouraging is to keep the *patched* source package under version control
[11:45] <Sarvatt> oh joy...
=== 50UAAE0BQ is now known as gomyhr
[13:34] <tseliot> Sarvatt: have you tested nvidia 195 with kernel 2.6.35? (note I haven't had the time to test and rebuild the driver yet)
[13:37] <Sarvatt> no, i've only tested 256.29 but people are saying 195.24 works with a no change rebuild against the new server. i've noticed a bug where nvidia-current was getting installed on non nvidia with a dist-upgrade once it's providing xserver-xorg-video-7 though, i think the only reason it's not happening to people now is because xserver-xorg-core breaks nvidia-current
[13:37] <Sarvatt> i dropped the provides in x-updates
[13:38] <tseliot> Sarvatt: I fail to see why that would happen
[13:38] <Sarvatt> it's easy to test, boot an alpha 1 livecd and sudo apt-get update && sudo apt-get dist-upgrade on non nvidia once it's rebuilt in the archives and it'll offer nvidia-current
[13:39] <Sarvatt> i cant figure it out either
[13:39] <Sarvatt> been trying to for weeks
=== fluffymaster is now known as apachelogger
[13:39] <Sarvatt> it happened when i moved xorg-edgers to 1.8 too
[13:40] <tseliot> I'll have to check the xserver package then
[13:40] <Sarvatt> when it's rebuilt i'll boot the livecd and do a simulated install and try to figure it out some more
[13:41] <Sarvatt> also nvidia_supported no longer works with nvidia-256, i had to hardcode the modaliases from the last working one :(
[13:41] <tseliot> Sarvatt: another thing: do you know if we have this patch in Maverick? http://bugs.freedesktop.org/attachment.cgi?id=35383
[13:42] <tseliot> I'll rework nvidia_supported too, as soon as I have some time to look at the nvidia package
[13:43] <Sarvatt> yes we do
[13:44] <Sarvatt> there's an ordering issue somewhere screwing up nvidia-current but i am completely stumped about it
[13:45] <tseliot> ordering issue?
[13:46] <Sarvatt> yeah the order its trying to resolve packages with dist-upgrade is wacky with xserver-xorg-core having breaks on the old abi's
[13:46] <tseliot> aah, ok
[13:47] <Sarvatt> if you have a machine that hasn't updated to xserver 1.8 yet, you can add the x-updates ppa and try a dist-upgrade and see what it offers to see what i'm talking about
[13:48] <Sarvatt> i just went through it all again yesterday but i guess ya weren't in the channel
[13:48] <Sarvatt> <Sarvatt> The following NEW packages will be installed:
[13:48] <Sarvatt> <Sarvatt>   baobab gnome-dictionary gnome-screenshot gnome-search-tool gnome-session-common gnome-system-log libprotobuf6 libprotoc6 libx11-xcb1
[13:48] <Sarvatt> <Sarvatt>   libxcb-dri2-0 linux-headers-2.6.35-2 linux-headers-2.6.35-2-generic linux-image-2.6.35-2-generic nvidia-current nvidia-settings
[13:49] <Sarvatt> thats on a fresh install of alpha 1 with fglrx installed doing a dist-upgrade
[13:49] <tseliot> that definitely doesn't look good
[13:49] <Sarvatt> with x-updates enabled
[13:50] <Sarvatt> with edgers I pinned it down to xserver-xorg-video-nv being screwed up and if i purged that it stopped trying to offer nvidia-current
[13:51] <tseliot> how did xserver-xorg-video-nv cause the system to install nvidia-current?
[13:51] <tseliot> shouldn't it be replaced by nouveau instead?
[13:52] <tseliot> note: I haven't installed maverick or created any maverick chroot yet
[13:59] <Sarvatt> hmm
[14:00] <Sarvatt> i wonder if its because xserver-xorg-video-nv provides xf86-video-driver-riva128 and it thinks that has video abi 6 early in the dependency resolution
[14:01] <Sarvatt> thats the only thing i can think of, kees had a similar problem earlier where he couldn't upgrade xserver-xorg-core because it thought something was providing xserver-xorg-video-6 still until he purged -nv
[14:02] <Sarvatt> if you dist upgrade while something provides video-6 the first thing it does is try to remove video-all
[14:03] <Sarvatt> so xserver-xorg-video-all | xserver-xorg-video-7 can get fulfilled for xserver-xorg
[14:04] <Sarvatt> i bet thats it actually, i'll test it out today
[14:04] <tseliot> good, let me know how it goes
[18:04] <ripps> I'm having trouble using my webcam with any gstreamer based client
[18:04] <ripps> I have a backtrace, would the fact I'm using xorg-edgers interfere?
=== Bernardo is now known as Bernardo|Away
=== Bernardo|Away is now known as Bernardo
[18:18] <johanbr> ripps, there are apparently xv issues with recent gtk
[18:19] <johanbr> you can try launching cheese with "XLIB_SKIP_ARGB_VISUALS=1 cheese"
[18:22] <ripps> johanbr: ah that works. I've got a ton of wrappers for that in my bin/. There needs to be a better way to handle the argb incompatibilities
[18:22] <johanbr> I'm sure people are working on it
[18:25] <ripps> I guess I'll create some wrappers for cheese and empathy
=== Amaranth_ is now known as Amaranth
=== Bernardo is now known as Bernardo|Away
[18:53] <ripps> woot! looks like wacom-dkms successfully worked when upgrading kernel.
[18:54] <ripps> Let's reboot and see if it really worked.
=== Bernardo|Away is now known as Bernardo
[19:30] <ripps> lol, it looks like rbga is being disabled again for gtk
=== Bernardo is now known as Bernardo|Away
=== apachelogger_ is now known as apachelogger
[20:28] <Sarvatt> kinda funny, I was actually enjoying RGBA themes now :) don't understand why they weren't enabled by default though, the only thing we got from all that seemed to be crashes?
[20:37]  * Ng wonders if there is any visibility of issues relating to USB input devices locking up
[20:38] <Ng> I've not seen it myself, but someone mentioned it to me in context of http://ubuntuforums.org/showthread.php?t=1497247
[20:40] <Sarvatt> Ng: you're evil, i actually read that.. :)
[20:41] <Ng> how is that evil?
[20:41] <Ng> I never go to the forums other than when people are talking about issues to me
[20:41] <Sarvatt> it's scary how much bad info is contained in one thread
[20:42] <Sarvatt> "my mouse doesn't work" "reinstall nvidia" "intel 8xx is broken change to vesa fix your mouse"
[20:42] <Sarvatt> noone even gave any details of their hardware :)
[20:44] <Sarvatt> like is it locking up after suspend, or after multiple plug ins or anything?
[20:45] <Sarvatt> its almost guaranteed the problem will be in dmesg when it happens
[20:47] <Sarvatt> Ng: did that flickering screen problem ever get fixed?
[20:48] <seb128> Sarvatt, "the only thing we got from all that seemed to be crashes?"
[20:48] <seb128> Sarvatt, we needed to land the change to know about those
[20:49] <seb128> Sarvatt, we also allow other teams to pick up and land themes etc 
[20:49] <Ng> Sarvatt: I don't think so, but I've not been paying lots of attention to it
[20:50] <Sarvatt> oh, I mean the CSD/RGBA stuff was completely transparent to me from a user's perspective, the only thing I noticed with it enabled was the crashes until I found out I could manually enable RGBA in the theme 
[20:51] <Sarvatt> i think less people would be complaining if they could actually see it in action :)
[20:51] <Sarvatt> because it shut me up from complaining once i did
[20:52] <seb128> right
[20:52] <seb128> well we need both, we need to know about issues and we need to get it used
[20:52] <seb128> seems to design team doesn't have a theme ready to use yet
[20:52] <seb128> and we collected technical issues we needed to know about now
[20:52] <seb128> so we turn it off until we have time to work on those
[20:53] <seb128> it's likely going to be back on after alpha2
[20:53] <Sarvatt> i've been using ambiance with rgba and it looks great
[20:53]  * Sarvatt nods
[20:53] <Ng> Sarvatt: I'll see if I can get the affected person to check dmesg when it happens and file a bug
[20:54] <seb128> in practice bratsche does our gtk work and is busy on the appmenu work now
[20:54] <Sarvatt> poke me if you can, I'll help :)
[20:54] <seb128> that should land in alpha2 for UNE
[20:54] <seb128> once that's working he will be back on rgba work
[20:54] <seb128> then we will enable it again
[20:54] <seb128> we don't win anything out of crashes right now
[20:59] <Sarvatt> cairo 1.9.8 checks out good on R600 at least - http://sarvatt.com/downloads/cairo/tests/
[20:59] <Sarvatt> couldn't run the pdf tests because they need poppler >= 13.2
=== Bernardo|Away is now known as Bernardo
[21:35] <Sarvatt> apw: do you know if 586 is going to continue being the default target for the i386 kernel in maverick?
[21:36] <Sarvatt> i imagine our binutils/gcc using i686 are already making userspace incompatible with the few processors that 586 supports that 686 doesn't
[21:40] <apw> Sarvatt, i would have thought so
[21:40] <apw> if it hasn't already of course
[21:42] <ripps> what exactly is the reason for the switch to i686?
[21:43] <apw> ripps, as i understand it its time for a clean break so we can take advantage of the newer features
[21:44] <ripps> apw: what kind of features?
[21:44] <apw> ripps, we are optimising for h/w that is almost non-existant, the majority case is i686 and above... they are paying a penaltiy for a very very few systems
[21:45] <apw> and as those systems are very old already and can stay on lucid for 3 years, now was deemed the time to make a change if we were
[21:45] <apw> but as for the politics, it was not my decision, nor was i present when it was made
[22:01] <Sarvatt> i for one am super happy about the change :)
=== apachelogger is now known as fluffymaster
[22:53] <geser> RAOF: do you know if moving glx.h from /usr/include/GL/glx.h to /usr/include/glx.h in maverick was intended? this seems to break some other software which checks for GL/glx.h
[22:54] <jcristau> sounds like a bug
[22:55] <geser> then the last mesa upload broke it
[22:56] <geser> mesa 7.8.1-1ubuntu has it installed in /usr/include/GL/glx.h, the same 7.8.1-2 from Debian experimental but 7.8.1-3ubuntu1 in maverick installs it now in /usr/include/glx.h
[22:57] <Sarvatt> argh
[22:57] <Sarvatt> http://sarvatt.com/downloads/mesa-modified-third.txt
[22:57] <Sarvatt> indeed it does
[22:58] <Sarvatt> want to yell at me yet jcristau? :)
[22:59] <jcristau> not unless you insist
[22:59] <jcristau> shit happens
[23:00] <Sarvatt> hmm, maybe that wasnt the most recent file list
[23:00] <Sarvatt> dri.pc is screwed up in origin/ubuntu too
[23:00] <geser> looks like the changes to mesa-common-dev.install dropped the GL directory:
[23:00] <geser> -usr/include/GL/gl.h
[23:01] <geser> +dri/usr/include/GL/gl.h usr/include
[23:01] <geser> and so on for the other files
[23:02] <Sarvatt> yeah that should be dri/usr/include/GL/gl.h usr/include/GL :(
[23:03] <Sarvatt> the merge was all screwed up, didnt fix up the new locations
[23:05] <Sarvatt> yay more mesa test builds incoming :)
[23:20] <Sarvatt> ugh, yeah I see why, there was something strange with the build in that other things from debian/tmp/dri needed the extra path in the .install but mesa-common-dev was the exception
[23:20] <Sarvatt> dri/usr/include/EGL usr/include works for libegl1-mesa-dev but mesa-common-dev needs dri/usr/include/GL/gl.h usr/include/GL
[23:21] <Sarvatt> adding dri/usr/include/EGL usr/include/EGL to libegl1-mesa-dev made it install to usr/include/EGL/EGL
[23:22] <Sarvatt> test building to be sure and will fix up the ubuntu branch's bad merge after if noone else gets them :D
[23:26] <shadeslayer> Sarvatt: bug 594863 regarding the above issue
[23:26] <ubot4> Launchpad bug 594863 in mesa (Ubuntu) "glx.h moved, causes FTBFS in other packages (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/594863
[23:27] <Sarvatt> it'll be fixed soon if you didn't read the scrollback :)
[23:28] <Sarvatt> there's a lot more messed up in the ubuntu package than just glx.h
[23:30] <RAOF> Gah!
[23:31] <bryceh> good morning raof
[23:31] <RAOF> bryceh: Good morning
[23:32]  * RAOF adds “test that things can build against it” to the set of pre-mesa upload checks.
[23:33] <Sarvatt> did you even merge anything?
[23:33] <Sarvatt> it doesnt look like you did, weird
[23:34] <jcristau> i try to debdiff against the previous changes file usually.  but sometimes i don't have that, and sometimes i miss stuff
[23:35] <RAOF> I use git for that; I diff against debian-experimental and origin/ubuntu.
[23:41] <Sarvatt> how did you merge?
[23:42] <RAOF> With git.
[23:42] <RAOF> You wouldn't have seen it, because I didn't push until just then.
[23:43] <RAOF> I'll be back in ~15 minutes.  Need to shift to to my brother's house which _isn't_ being rewired today.
[23:43] <Sarvatt> i mean what commands did you use? whatever you did didn't actually go through?
[23:43] <Sarvatt> oh ok
[23:47] <Sarvatt> http://sarvatt.com/downloads/files-five.txt
[23:49] <Sarvatt> looks right to me