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