[05:55] <tjaalton> bryce: what mlankhorst said :) guess it's xserver and at least some drivers today
[07:18] <tjaalton> llvm built, finally
[07:18] <tjaalton> still no sign of doko or sylvestre
[07:18] <tjaalton> I'll just email them
[08:52] <tjaalton> updating libdrm for newer mesa snapshot
[10:07] <mlankhorst> I guess I better test mesa 9.0.2 now then :P
[10:16] <mlankhorst> time to run the piglit tests I suppose
[10:17] <tjaalton> meh, how hard can it be to get reprepro signing work.. i've done this before, years ago
[10:18] <RAOF> What are you trying to do?
[10:18] <tjaalton> to test the builds locally with sbuild
[10:18] <tjaalton> pulling from a local repo
[10:18] <tjaalton> include/export works, now sbuild-update claims the pubkey isn't known
[10:18] <RAOF> http://paste2.org/p/2834017
[10:19] <tjaalton> oh :)
[10:19]  * mlankhorst just builds on launchpad with high priority, evil, I know
[10:19] <mlankhorst> I do feel guilty about it though, so it's ok!
[10:20] <RAOF> tjaalton: Dump in /etc/schroot/setup.d as 60add-local-repository, combine with http://paste.ubuntu.com/1619254/ and you've got a raring-local chroot that builds against ~/Builds
[10:21] <tjaalton> that's neat
[10:21] <tjaalton> I'll probably use reprepro still for some stuff, but this is good enough for builds :)
[10:22] <mlankhorst> but if I had to test before pushing, I'd probably mess up my own raring chroot/netboot image instead. It can do both :-)
[10:22] <RAOF> Arsing llvm
[10:22] <RAOF> What's a man got to do to build mesa in a ppa these days :)
[10:23] <mlankhorst> push dh-exec 0.6 to precise? :P
[10:23] <tjaalton> next I'd like it to build under /run/shm, guess my ssd will wear more quickly because of sbuilding all the time :)
[10:23] <mlankhorst> It needs 0.3 or newer for building llvm-3.2
[10:24] <RAOF> tjaalton: Heh. My sbuild config used to also have raring-tmpfs, too, before btrfs-snapshot.
[10:24] <mlankhorst> tjaalton: it will kill itself even faster here because I'm using encryption, I tested, it's not cpu limited any more after a fix!
[10:24] <mlankhorst> and it's going like 400 mb/s 
[10:25] <RAOF> tjaalton: I could probably find the config I was using to do tmpfs stuff.
[10:25] <tjaalton> that would be nice
[10:26] <tjaalton> my ssd died after one year, so will try to minimize it's use now
[10:27] <mlankhorst> I'm a terrible person, and keep backups for that. :-)
[10:28] <tjaalton> me too, but only of my own $HOME, screw the others :)
[10:28] <tjaalton> or the system files
[10:28] <mlankhorst> oh everything important is in a git repository
[10:28] <tjaalton> still don't have a working smtp config..
[10:28] <RAOF> Actually, from memory I think it's pretty easy - you mount /var/lib/schroot/tmpfs-overlay in /etc/fstab, then use that as the overlay dir in the schroot config.
[10:29] <mlankhorst> since ssd's have been so fast I've been pretty lazy though. I'm just building from ssd since doing otherwise takes more effort and longer
[10:29] <tjaalton> i have 16 gigs of ram, better use it for something!
[10:29] <mlankhorst> I do too
[10:30] <mlankhorst> Cached:         12110996 kB
[10:30] <mlankhorst> it's practically building from memory already
[10:32] <tjaalton> hmm, I should probably clean up my build dir :)
[10:33] <tjaalton> a ton of cruft there slowing sbuild down
[10:33] <mlankhorst> that's why I don't use tmpfs ;-)
[10:34] <tjaalton> the destination is on ssd
[10:39] <tjaalton> E: 60add-local-repository: gpg: keyring `/var/lib/sbuild/apt-keys/secring.gpg' created
[10:39] <tjaalton> E: 60add-local-repository: gpg: keyring `/var/lib/sbuild/apt-keys/pubring.gpg' created
[10:39] <tjaalton> E: 60add-local-repository: gpg: no default secret key: secret key not available
[10:39] <tjaalton> E: 60add-local-repository: gpg: signing failed: secret key not available
[10:40] <tjaalton> did I miss something?
[10:41] <tjaalton> probably should create the key first :)
[10:47] <tjaalton> meh, refuses to install llvm-3.2-dev
[10:52] <tjaalton> RAOF: I guess your sbuild runs update too :)
[10:58] <mlankhorst> did I mess up? :s
[10:58] <mlankhorst> oh wait in sbuild I suppose
[10:58] <tjaalton> nah, it's the repo
[10:58] <tjaalton> well, now it's claiming libdrm* is unsigned
[10:59] <tjaalton> the llvm maintainer promised to add the backend \o/
[10:59] <mlankhorst> \o/
[11:19] <tjaalton> grr
[11:19] <tjaalton>  sbuild-build-depends-mesa-dummy : Depends: libdrm-dev (>= 2.4.39) but it is not going to be installed
[11:26] <mlankhorst> you forgot to bump libdrm-dev? :P
[11:27] <mlankhorst> probably needs to be 2.4.42 there
[11:28] <tjaalton> didn't update the branch yet
[11:28] <tjaalton> this is the apt resolver failing
[11:28] <tjaalton> refuses to install stuff from the local repo
[11:31] <tjaalton> ok, it was 2.4.42-1 test build that was broken
[11:32] <tjaalton> rebuilt -0u1 and it's fine now
[11:39] <tjaalton> mlankhorst: did you test that it built using shared llvm libs?
[11:39] <tjaalton> I got the same issue with gensymbols
[11:40] <tjaalton> or did i
[11:41] <mlankhorst> I'm testing on quantal atm
[11:42] <mlankhorst> I want to get the 9.0.2 sru done first :)
[11:43] <tjaalton> I'll pastebin this.. guess it's normal after all
[11:53] <tjaalton> http://pastebin.com/8bMUBdDU
[11:54] <tjaalton> hm no :)
[11:55] <mlankhorst> do you have the full debdiff to llvm-3.2 btw? I'm missing radeonsi
[11:56] <mlankhorst> hm indeed, tons of symbols
[11:58] <mlankhorst> sounds like it statically linked against libgallium or something
[11:59] <mlankhorst> surprise surprise, it probably did
[12:01] <mlankhorst> oh well build libgallium dynamically and you're fine
[12:03] <tjaalton> is there a separate option for it?
[12:04] <mlankhorst> one line hack would be noinst_LTLIBRARIES -> lib_LTLIBRARIES
[12:05] <mlankhorst> in src/gallium/auxiliary/Makefile.am, but no idea if it works yet
[12:05] <tjaalton> ok
[12:08] <tjaalton> wth, the diff with the upstream branch shows changes all over the place
[12:12] <mlankhorst> aw still broken
[12:13] <mlankhorst> grabbing rbug, svga and some vmw symbols
[12:14] <mlankhorst> could be fixed in the same way I suppose
[12:14] <mlankhorst> either that or I just hack in the visibility things for now
[12:17] <mlankhorst> probably better for now
[12:19] <tjaalton> so my merge of git master on jan 9th created issues
[12:22] <tjaalton> dunno what's the best way to get out of it, other than maybe cleaning them up in a separate commit, or losing history of debian/
[12:23] <mlankhorst> do you want to rewind?
[12:23] <mlankhorst> or move forward
[12:24] <tjaalton> well, rewind wouldn't be that bad
[12:24] <tjaalton> I guess..
[12:27] <mlankhorst> well trying to build it atm, hopefully working this time by adding some visibility cflags back
[12:30] <tjaalton> I'll rebuild the branch, first merge whatever was there before the bad merge, then cherry pick the commits to debian/ after that
[12:31] <mlankhorst> down a lot of symbols..
[12:31] <mlankhorst> still missed a few
[12:37] <mlankhorst> driver_descriptor@Base remaining
[12:38] <mlankhorst> as good as it gets I suppose
[12:39] <mlankhorst> tjaalton: http://paste.ubuntu.com/1620151/
[12:40] <mlankhorst> there's probably a better fix, but meh..
[13:03] <tjaalton> mlankhorst: ok, thanks
[13:04] <mlankhorst> you need to add driver_descriptor@Base to the symbols list btw
[13:34] <tjaalton> sigh
[13:35] <tjaalton> conclusion; git merge does funky stuff
[13:35] <tjaalton> despite merge -s ours
[13:35] <tjaalton> i got exactly the same diff
[13:37] <tjaalton> for some reason it decides the remote is more important
[13:37] <mlankhorst> you can override it. :P
[13:37] <mlankhorst> git checkout whatevercommit . git commit --amend
[13:38] <tjaalton> hmh?
[13:38] <mlankhorst> to amennd the merge commit
[13:39] <tjaalton> what's whatevercommit
[13:40] <mlankhorst> erm what you want the HEAD to look like after merge
[13:40] <tjaalton> sure I can touch whatever but it's work
[13:41] <tjaalton> http://pastebin.com/kGwnuACC
[13:42] <mlankhorst> git rm debian src; git checkout COMMIT src ?
[13:43] <tjaalton> don't want to lose history for debian
[13:43] <mlankhorst> erm skip the rm debian then
[13:43] <tjaalton> hmm
[13:46] <tjaalton> hah
[13:46] <tjaalton> did the trick
[13:46] <tjaalton> amended with the merge
[13:48] <tjaalton> checkout $path sounds interesting..
[13:50] <mlankhorst> :-)
[13:50] <tjaalton> well, it does lose history, so it's not useful for pulling the packaging
[13:51] <mlankhorst> not really? or at least git log debian/ kept working for me
[13:51] <tjaalton> only if your branch had debian/ at some point
[13:52] <mlankhorst> yeah you need to start from debian branch
[13:52] <tjaalton> but if you checkout the upstream branch and then the packaging on top of it
[13:52] <tjaalton> right
[13:52] <tjaalton> works for src/ etc
[13:52] <tjaalton> now where was I ..
[13:52] <tjaalton> have a dozen branches to weed through :P
[15:01] <tjaalton> attached a power meter between the outlet and ups, combined consumption is around max 200W including the monitor and DAC when building mesa with ivb :)
[15:01] <tjaalton> idle is 90-100
[15:03] <tjaalton> libgles2 needed one symbol added, seems fine now
[15:11] <tjaalton> mlankhorst: libxatracker1 is still big, but at least it didn't complain about the symbols
[15:12] <mlankhorst> tjaalton: yeah that was the goal :-)
[15:12] <mlankhorst> I didn't feel like making all those libraries shared just yet
[15:31] <tjaalton> ok now onto the ubuntu branch..
[15:42] <mlankhorst> well radeon piglit results done, now i915 I suppose.
[15:49] <mlankhorst> well afaict no regressions on radeon \o/
[16:05] <tjaalton> ugh, the gallium dricore patches make my head hurt.. I'll just push what I have so far
[16:05] <mlankhorst> want me to rebase the gallium and dricore patches again? :P
[16:06] <tjaalton> well, yeah, all the files 117 touches have vanished :)
[16:06] <tjaalton> for starters
[16:06] <mlankhorst> well I'm waiting on piglit to finish anyway
[16:06] <mlankhorst> why not
[16:14] <tjaalton> mlankhorst: force-pushed
[16:15] <mlankhorst> tjaalton: nitpick, it's not from llvm. it's from libgallium and those other static libs where I added the flags to
[16:16] <tjaalton> well, do it properly and we can drop the patch :)
[16:16] <tjaalton> with a properly-named one
[16:16] <tjaalton> er, replace it with..
[16:16] <mlankhorst> I'm probably just going to push it upstream..
[16:17] <tjaalton> of course, even better
[16:20] <mlankhorst> tjaalton: 117 patch should no longer apply, but the fix is even easier to make :-)
[16:21] <tjaalton> good
[16:23] <mlankhorst> but I think it's better to just check with upstream first
[16:25] <mlankhorst> actually I guess I could just do an ugly hack for now
[16:26] <mlankhorst> seems we don't add version to libgallium in previous patches anyway
[16:28] <mlankhorst> done with libgallium, now dricore gallium..
[16:32] <mlankhorst> oh right, that one was annoying
[16:34] <mlankhorst> it was a bit of abuse since I needed libmesagallium to be done after libdricore, so I had to move it to the mesa/libdricore directory
[16:39] <mlankhorst> wow, only d3d1x is still using makefiles
[16:46] <mlankhorst> ok I'm still thinking about the best way to approach the dricore fix, but gallium was easy
[16:57] <tjaalton> so it wasn't a great idea to push libxi to raring, need to revert the new stuff for now :P
[17:02] <mlankhorst> broke unity?
[17:02] <tjaalton> kde builds
[17:02] <mlankhorst> ah, worse
[17:02] <tjaalton> but probably others too
[17:03] <tjaalton> if includes both XInput2.h and Xfixes.h it'll go boom, duh
[17:04] <mlankhorst> well lets see if it builds now
[17:04] <mlankhorst> oh right
[17:04] <mlankhorst> need new llvm and new libdrm
[17:05] <mlankhorst> tjaalton: I pushed what I have
[17:05] <mlankhorst> it's guaranteed to break on building
[17:06] <mlankhorst> but hopefully that only happens when it finds a new libmesagallium*.so
[17:06] <mlankhorst> if not, let me know
[17:10] <tjaalton> yup, fails
[17:11] <tjaalton> http://pastebin.com/xQM8QVb5
[17:24] <ricotz> tjaalton, hi :)
[17:24] <ricotz> mlankhorst, hey
[17:25] <ricotz> tjaalton, did you notice some conflicts between libxi-dev and libxfixes-dev?
[17:25] <ricotz> /usr/include/X11/extensions/Xfixes.h:274:17: error: conflicting types for 'BarrierEventID'
[17:25] <ricotz> /usr/include/X11/extensions/XInput2.h:173:22: note: previous declaration of 'BarrierEventID' was here
[17:25] <Sarvatt> #ubuntu-devel :P
[17:25] <ricotz> ah good
[17:26] <mlankhorst> ricotz: hello
[17:26] <tjaalton> ricotz: yeah, fixed already
[17:27] <tjaalton> I'll upload another one to the ppa, reverting the revert.. and then libxfixes dropping the old stuff
[17:27] <ricotz> tjaalton, thanks!
[17:27] <mlankhorst> tjaalton: yeah looks like I'm including too much somehow
[17:27] <mlankhorst> I guess you need to exclude state_tracker/st_glsl_to_tgsi.cpp from the 118 patch
[17:27] <mlankhorst> in src/mesa/libdricore/Makefile.am
[17:28] <ricotz> tjaalton, will be barrier stuff move away from xfixes?
[17:28] <ricotz> be/the
[17:28] <mlankhorst> looks funny there anyway, it was probably to work around some issue
[17:28] <tjaalton> ricotz: yes
[17:28] <ricotz> tjaalton, ah i see
[17:28] <tjaalton> slightly different anyway
[17:28] <mlankhorst> tjaalton: anyhow I have to leave for a bit, I think that specific issue should be easy to fix with that hint :-)
[17:29] <tjaalton> mlankhorst: ok, I'll give it a got..
[17:29] <tjaalton> -t
[17:29] <mlankhorst> afk!
[18:04] <tjaalton> fixesproto and lib pushed to c-x/x-s
[18:09]  * mlankhorst back-ish
[18:19] <tjaalton> hmm, could I upload xserver to the ppa then
[18:19] <mlankhorst> did you get mesa running?
[18:20] <tjaalton> ah, no
[18:20] <tjaalton> http://pastebin.com/xQM8QVb5
[18:20] <mlankhorst> that's  the same you posted earlier?
[18:20] <tjaalton> oh right :)
[18:22] <tjaalton> http://pastebin.com/p65CeikP
[18:23] <mlankhorst> oh so that's why I needed that file
[18:36] <mlankhorst> tjaalton: I pushed the fix, I hope..
[18:36] <tjaalton> building..
[18:40] <tjaalton> mlankhorst: http://pastebin.com/axgf3Wst
[18:41] <mlankhorst> still the case? evil!
[18:41] <tjaalton> :)
[18:41] <mlankhorst> I guess it needs to be moved around
[18:43] <mlankhorst> tjaalton: what if you move that egl_gallium_la_LIBADD += $(MESAGALLIUM_LIBS) line in egl-static/Makefile.am all the way down to bottom of the file?
[18:44] <mlankhorst> I'm just guessing, I need to get my hands on a working llvm-3.2 build
[18:52] <tjaalton> mlankhorst: grab it from the ppa :)
[19:01] <tjaalton> mlankhorst: still the same
[19:01] <mlankhorst> oh :/
[19:01] <mlankhorst> I'll look tomorrow
[19:01] <tjaalton> yeah
[19:02] <Sarvatt> tjaalton: going to upload xserver?
[19:03] <Sarvatt> or want me to do it? I can do the drivers too
[19:03] <Sarvatt> oh, long queues :(
[19:04] <Sarvatt> and sorry for not pushing it to expeirmental, didn't realize it was there also
[19:13] <tjaalton> ha, no worries, sorry for being tired/grumpy last night :)
[19:13] <tjaalton> feel free to upload them!
[19:34] <Dandel> Sarvatt: I spotted a major problem with piglit packages :/
[19:35] <Dandel> when running from installed packages, I found out that resume is broken.
[19:36] <Sarvatt> doh, did it just start happening one day or always been like that?
[19:36] <Sarvatt> it's building daily git snapshots and i haven't looked at git in like 8 months
[19:37] <Dandel> it's not a one day issue
[19:37] <Dandel> it's a combination of bugs
[19:39] <Dandel> 1 sec while i get the log from git to find out which commit is the likely culprit. 
[19:40] <Dandel> most likely, it's this file ( in combination): http://cgit.freedesktop.org/piglit/log/framework/shader_test.py
[19:45] <Dandel> Sarvatt: also, on a similar note, piglit really needs to capture the core dumps ( and heap stacks )
[19:49] <bryce> Dandel, agreed
[19:49] <bryce> Dandel, well possibly we need a wrapper
[19:49] <Dandel> bryce: that's actually somewhat easy to "mimic"
[19:49] <Dandel> it already can identify when the test crashes
[19:50] <Dandel> it just needs a little bit of expansion ( based on what xbmc does for their launcher ) to be able to fully capture the stack.
[20:43] <Dandel> Sarvatt: I have a few fixes that should work... want to give em a try?
[23:21] <Dandel> just double checked, and there's some patches on the piglit mailer that seem to address the issue about resuming tests.