[03:57] <mlankhorst> morning
[03:58] <RAOF> Yo yo!
[04:49] <tjaalton> plymouthd seems to crash here on boot
[04:58] <mlankhorst> because of the race?
[05:00] <mlankhorst> bbbbaaacktrace!
[05:01] <tjaalton> no, it doesn't race anymore after changing lightdm.conf locally
[05:01] <tjaalton> I guess the crash was the reason it was racing so reliably :)
[05:01] <mlankhorst> haha
=== Prf_Jako1 is now known as Prf_Jakob
[08:18] <tjaalton> the plymouth crasher is bug 733453
[08:18] <ubottu> bug 733453 in plymouth (Ubuntu) "plymouthd crashed with SIGSEGV in script_obj_deref_direct()" [High,Confirmed] https://launchpad.net/bugs/733453
[08:19] <mlankhorst> valgrindddd
[08:20] <tjaalton> how to run it during boot?
[08:21] <tjaalton> just edit init/plymouth.conf?
[08:21] <mlankhorst> I guess so, don't see why that wouldn't work
[08:21] <mlankhorst> though you'd want to pipe the output to somewhere
[08:22] <mlankhorst> &>> /run/something
[08:22] <tjaalton> right
[08:23] <seb128> tjaalton, mlankhorst: you also have the good old trip of "mv bin bin.real" and make "bin" a wrapper script calling valgrind bin.real --log-file=/tmp/...
[08:23] <seb128> trip->trick
[08:25] <mlankhorst> seb128: well in case of X I just change the symlink in /etc/X11/X to point to my wrapper script
[08:25] <seb128> well, if you have a symlink, sure you can just change the target
[08:25] <seb128> but most binaries don't have a smylink
[08:26] <mlankhorst> true
[09:08] <tjaalton> hmm, either it's not working or logging is somehow off
[09:08] <tjaalton> --log-file=foo that is
[09:08] <tjaalton> tried /tmp and /run
[09:19] <mlankhorst> tjaalton: root is ro at that point, maybe point to /dev ?
[09:20] <mlankhorst> oh and plymouth might fork
[09:20] <mlankhorst> so you'd need --trace-children=yes
[09:20] <tjaalton> ok
[09:25] <tjaalton> still nothing
[09:28] <mlankhorst> hmz..
[09:28] <tjaalton> hrm, alt-tabbing is slow on ivb
[09:28] <tjaalton> with mesa 9.1
[09:29] <seb128> tjaalton, is plymouth working? your wrapper is correctly +x and call the full path to the binary?
[09:29] <mlankhorst> he's modifying the init script
[09:29] <tjaalton> seb128: yep
[09:29] <tjaalton> tried both
[09:29] <mlankhorst> my guess is root still rootonly since it gets called before mountall
[09:29] <tjaalton> now I have a wrapper
[09:29] <seb128> try doing an echo"test" > /tmp/debug
[09:29] <tjaalton> right
[09:33] <tjaalton> root is ro, nothing
[09:33] <tjaalton> tried /dev, /run, /tmp
[09:34] <mlankhorst> heh
[09:34] <mlankhorst> mkdir /dummy
[09:34] <mlankhorst> and in the init script /sbin/mount -n -t tmpfs /dummy /dummy
[09:56] <tjaalton> didn't get that to work either, maybe need to add an initramfs hook or something
[09:57] <tjaalton> but did check how mesa performance has dropped on gen4 i915..
[09:57] <tjaalton> that or the dash has changed dramatically since precise
[09:59] <tjaalton> lunch ->
[10:05] <mlankhorst> oh cool, git-bzr works well enough to clone a repository
[11:37] <tjaalton> hum, what's bug 1134492 about then
[11:37] <ubottu> bug 1134492 in xorg-lts-quantal (Ubuntu) "xserver-xorg-lts-quantal breaks Kubuntu" [Undecided,New] https://launchpad.net/bugs/1134492
[11:38] <mlankhorst> presumably libegl stuff
[11:38] <mlankhorst> iirc kwin depends on libegl, which we don't install by default
[11:39] <tjaalton> ah
[11:40] <tjaalton> but doesn't kubuntu 12.04.2 use the backport stack?
[11:40] <tjaalton> iirc it does
[11:40] <mlankhorst> the bug is about installing kubuntu-desktop separately, I believe
[11:41] <mlankhorst> oh wait kubuntu-desktop is kept, lts-quantal is installed after
[11:42] <tjaalton> kubuntu-desktop installs just fine here
[11:42] <mlankhorst> it will install fine, the bug is about installing kubuntu-desktop first, then installing xserver
[11:42] <mlankhorst> and having a resolution that will remove kubuntu-desktop i believe
[11:43] <tjaalton> good thing I've booted 12.04.1 off a usb stick
[11:43] <tjaalton> so I can try :)
[11:44] <mlankhorst> I forgot which one it was though
[11:45] <mlankhorst> tjaalton: hah I have a ssd and a chroot, race you to it!
[11:46] <tjaalton> :)
[11:46] <tjaalton> i have a local mirror
[11:47] <mlankhorst> wait libglu gets removed, why ._.
[11:50] <mlankhorst> oh nm
[11:50] <mlankhorst> that user just misconfigured his stuff
[11:50] <mlankhorst> no alarm
[11:50] <mlankhorst> Empfohlene Pakete:
[11:50] <mlankhorst>   libgl1-mesa-glx-lts-quantal
[11:52] <tjaalton> recommends not enabled?
[11:53] <mlankhorst> indeed..
[11:53] <tjaalton> heh
[11:53] <ogra_> note that flavours like lubuntu do that by default
[11:53] <mlankhorst> not my problem
[11:53] <ogra_> (no idea about kubuntu, but they might too)
[11:54] <mlankhorst> though I guess I could explicitly enable it
[12:26] <tjaalton> meh, blur/fade regressed on haswell too
[12:26] <tjaalton> with mesa 9.1
[12:26] <tjaalton> what a fail
[12:27] <tjaalton> the recent work in master made it better but it's still worse than it was with 9.0
[12:28] <mlankhorst> the question we should be asking is whether it can be resolved in time or not :/
[12:36] <tjaalton> right
[12:37] <tjaalton> wonder if git master builds
[12:41] <mlankhorst> not with radeon afaik
[12:54] <tjaalton> bah
=== schmidtm__ is now known as schmidtm_
[14:47] <tjaalton> hm, I could just try reverting the bad commit that caused the perf regression
[15:38] <tjaalton> no change on hsw, although it seems it didn't regress after all..
[15:46] <tjaalton> snb is just as happy with the revert as with the 19 patches
[15:46] <tjaalton> so looks like it worked there
[15:46] <tjaalton> who cares about serious sam 3 performance anyway? :)
[16:10] <bryce> tjaalton, did you chat with slangasek about 9.1 in raring?
[16:29] <seb128> bryce, tjaalton: what's the status on the performances issues of the new version on gen5 cards? that should probably be resolved before talking about landing the update...
[16:30] <Sarvatt> https://devtalk.nvidia.com/default/topic/539249
[16:32] <bryce> seb128, 6 lines up tjaalton says he has been trying to revert the problematic patch; no luck so far
[16:33] <seb128> bryce, ok, I restarted my IRC and didn't have that backlog, thanks
[16:33] <bryce> seb128, I suggested talking with slangasek or another release admin before landing it with any regressions
[16:35] <bryce> seb128, ah I may have misread his comments; sounds like he successfully reverted the change but hasn't yet confirmed the fix on gen5 hardware, I guess
[17:16] <tjaalton> bryce: not yet
[17:18] <tjaalton> bryce, seb128: pitti tested the reverted version, it's better than the ppa version but slightly worse than 9.0.3 on raring
[17:18] <tjaalton> does anyone have IVB to test on?
[17:19] <tjaalton> I do, but it means killing my session :)
[17:19] <tjaalton> so, this latest one with just the one revert on top of 9.1.1 looks like the best solution for now
[18:13] <tjaalton> uploaded -intel 2.21.6
[18:14] <mlankhorst> \o/
[18:14] <tjaalton> fixes at least one bug
[18:14] <mlankhorst> push to git?
[18:14] <tjaalton> done
[18:14] <mdeslaur> so...in quantal, what exactly is supposed to install the proper kernel headers so the nvidia dkms module gets built?
[18:14] <mlankhorst> tjaalton: oh can you add --enable-valgrind to rules?
[18:14] <tjaalton> it's on the queue
[18:15] <mdeslaur> I can't believe this doesn't even work out of the box
[18:15] <tjaalton> mdeslaur: the image should have it, but there was a bug in the builder that removed them..
[18:15] <mlankhorst> ah nm it should have VG enabled afaict
[18:15] <tjaalton> quantal is so passé anyway :)
[18:16] <tjaalton> mlankhorst: well this one should first get past the queue :)
[18:16] <mdeslaur> tjaalton: so if you install nvidia once your quantal is up-to-date, it doesn't actually work without you manually installing the kernel headers?
[18:16] <tjaalton> mdeslaur: correct
[18:16] <tjaalton> I think
[18:16] <tjaalton> haven't tried
[18:16] <mdeslaur> awesome. guess 2013 isn't the year of the linux desktop.
[18:16] <tjaalton> hehe
[18:16] <tjaalton> well technically that was in 2012
[18:16] <mlankhorst> tjaalton: I just want valgrind so I can get rid of most false positives on a default boot, and only get the USEFUL backtraces :P
[18:17] <tjaalton> surely 13.04 will kick butt, and include other bugs
[18:17] <mdeslaur> tjaalton: I included a 6 month SRU grace period :P
[18:17] <tjaalton> mdeslaur: nobody cares about quantal, other than maybe because of the lts backport stack
[18:18] <mlankhorst> that^
[18:18] <mlankhorst> if people cared about quantal my xxv-nouveau would have been accepted a lot sooner in quantal-proposed
[18:18] <mlankhorst> been a month now?
[18:19] <mdeslaur> the people who opposed turning non-lts releases into a rolling release should be _forced_ to do sru maintenance and testing :P
[18:19] <mlankhorst> I'm not against rolling releases, but I think waiting for raring to be released first wouldn't have been a bad idea
[18:20] <mdeslaur> well, that's a separate issue
[18:21] <tjaalton> mdeslaur: yeah rolling ftw, interim releases are a big pita
[18:21] <mlankhorst> nobody cares about the interim :/
[18:22] <mlankhorst> people care more about the quantal lts stack in precise than about quantal
[18:24] <tjaalton> flavors do, but for how long
[18:24] <tjaalton> I hope this can be revisited after T
[18:28] <llstarks> i'd like a rolling repo
[18:29] <llstarks> i'm only on "stable" ubuntu for maybe a day or two each year anyway. release and toolchain upload are now simultaneous though
=== f4bs0 is now known as f4bs
=== erapp_000_ is now known as llstark
=== llstark is now known as llstarks
[23:04] <llstarks> i'm going to test nvidia 319.12, i want to see what xrandr outputs with the new randr 1.4 support for optimus
[23:05] <llstarks> http://us.download.nvidia.com/XFree86/Linux-x86/319.12/README/randr14.html
[23:05] <llstarks> they're basically telling us how to implement it
[23:10] <bjsnider> llstarks, it is good news for optimi users, no?
[23:11] <llstarks> i don't know yet. it's an always-on driver situation. nvidia+modesettng
[23:12] <bjsnider> if you use the nvidia-installer be careful it doesn't overwrite anything
[23:12] <llstarks> i'm still trying to figure out the xorg.conf