[01:23] <Sarvatt> mlankhorst: no quantal in winehq? :(
[01:23] <Sarvatt> finally updated
[01:27] <Sarvatt> jeeze having a DE up in 3 seconds is nuts, sata3 ssd's are really worth it
[01:28] <bjsnider> it takes me about 8 secs in precise, is quantal faster?
[01:28] <Sarvatt> maybe its quantal, not sure
[01:28] <bjsnider> i've got an intel 520 here, very fast
[01:28] <Sarvatt> upgraded from a sandybridge macbook air to a thinkpad x1 carbon with a 2x faster ssd and now its 3 instead of 7
[01:30] <bjsnider> home is mounted on the ssd too?
[01:30] <Sarvatt> one big drive yeah
[01:30] <bjsnider> ok, maybe that's it, because i've only got root on the ssd here
[01:31] <bjsnider> maybe i should mount more of home on the ssd
[01:31] <Sarvatt> just going by [     3.063] X.Org X Server 1.13.0 and wifi being ready 5 seconds into the boot in dmesg, takes me way longer to type a password to actually log in
[01:31] <Sarvatt> X is up 7 seconds in in the macbook air
[01:34] <Sarvatt> other laptop has a crappy broadcom that needs the proprietary driver to work that takes way longer to associate, might have something to do with it seeming more laggy
[01:51] <bjsnider> crappy broadcom, but you repeat yourself
=== ripps_ is now known as ripps
[03:57] <tjaalton> ha, darktama closed the nvd9 dp bug after i sub'd to it, saying it's supported. need to file a new bug then
[04:00] <RAOF> Heh
[04:00] <Sarvatt> tjaalton: supported on 3.7 after the rewrite?
[04:01] <tjaalton> Sarvatt: no, 3.5
[04:02] <tjaalton> it almost works, just claims there's no edid
[04:03] <tjaalton> but testing with just the discrete I got it hung with 3.6rc and then it confused the monitor so bad that I had to pull the power plug
[04:07] <RAOF> Awesome!
[04:10] <Sarvatt> tjaalton: sounds like typical DP fare
[04:11] <tjaalton> with debug output I could see the modes, but in the end nouveau would just throw in the towel
[04:11] <Sarvatt> i've had to pull the battery and hold power for 2 minutes to drain the backup on every eDP system at some point :P
[05:58] <mlankhorst> Sarvatt: erm the quantal package for wine is the same as precise, so just set it to precise
[05:58] <mlankhorst> I just didn't want to upload twice
[05:58] <Sarvatt> mlankhorst: but but its compiled with gcc-4.6, thats blasphemy for phoronix
[06:00] <RAOF> What? Not compiled with clang?!?!?!!1111
[06:01]  * ricotz is pushing nvidia 304.48 to xedgers
[06:01] <Sarvatt> no -ffruit-loops by default from 4.7 :(
[06:01] <Sarvatt> yeah its no big deal, thats how the wine ppa has always worked, quantal doesnt go in till after it releases :P
[06:01] <mlankhorst> oh it's mostly laziness really
[06:01] <mlankhorst> I cba to do the extra work
[06:02] <ricotz> mlankhorst, hi, there is no extra work though
[06:02] <ricotz> ;)
[06:02] <ricotz> just a dch and debuild -S -sd
[06:02] <mlankhorst> ^extra work
[06:02] <Sarvatt> there was when ia32-libs was a thing
[06:04] <Sarvatt> ricotz: i'm almost thinking no xserver 1.13 in edgers for precise, what do you think?
[06:04] <Sarvatt> not much point when it will be in the backport ppa
[06:05] <mlankhorst> just alter the scripts to rename *ducks*
[06:05] <Sarvatt> and 12.04.2 come jan
[06:06] <ricotz> Sarvatt, hmm, i see, updating the 1.12 package might be useful then
[06:06] <mlankhorst> xorg-server-crack-edgers
[06:07] <Sarvatt> thats easier, just reuse the old debian/ from the current one once a month or something :)
[06:08] <mlankhorst> oops, need to copy the prime xxv's over
[06:09] <Sarvatt> i woulda said noone would notice if you just left it but yeah people thought we were on mesa 8.x in quantal because of that ppa
[06:09] <mlankhorst> there, now qbp has prime, assuming we get xrandr updated in time and/or the autobind server patch
[06:09] <mlankhorst> yeah I'll update it
[06:10] <Sarvatt> i dont know how you're updating it so hesitant to
[06:10] <mlankhorst> ...?
[06:10] <Sarvatt> dont want to screw it up :)
[06:10] <mlankhorst> I don't understand what you mean there
[06:11] <Sarvatt> oh you already updated it all, was just wanting to update it last week when things changed a lot in quantal but didnt want to step on any toes
[06:12] <mlankhorst> yeah don't worry about that, I do need to push the changed scripts though :)
[06:13] <mlankhorst> -extraversion="~precise1~ppa3"
[06:13] <mlankhorst> +extraversion="~precise1~ppa4"
[06:13] <Sarvatt> which scripts?
[06:13] <Sarvatt> ah in xorg-pkg-tools, how did i miss that
[06:14] <mlankhorst> you didn't think I would do it by hand did you? :p
[06:15] <mlankhorst> only xorg and xorg-lts-quantal, but I need to update those still
[06:16] <Sarvatt> blob naming might be a PITA
[06:16] <ricotz> i dont think blob needs to be renamed
[06:16] <Sarvatt> need to somehow move people from nvidia-current-updates onto nvidia-current-updates-quantal
[06:17] <mlankhorst> Sarvatt: no, we just make nvidia-current-updates work for both..
[06:17] <Sarvatt> true
[06:17] <mlankhorst> iirc that was a bit harder for fglrx though
[06:18] <Sarvatt> artifical abi restrictions are a thing of the past all the sudden, where tseliot made them provide multiple ones
[06:18] <mlankhorst> but hey if that plan fails it's going into the rename bin
[06:18] <Sarvatt> not sure he made 304.xx provide xserver 1.13's abi in -updates in the precise-proposed one though
[06:19] <Sarvatt> but still people would need to be moved from nvidia-current to nvidia-current-updates
[06:19] <mlankhorst> yeah nvidia-current-updates might need provides: nvidia conflicts nvidia to join the rest
[06:20] <Sarvatt> would be nice if the transition from nvidia-current to nvidia-current-updates was automatic somehow, needs to be
[06:21] <mlankhorst> add those conflicts and provides, and it will be..
[06:22] <mlankhorst> or at least probably, not 100% sure
[06:22] <Sarvatt> post release, upload another nvidia-current moving people over to -updates? good idea
[06:22] <Sarvatt> except some people want to stay with a working driver
[06:22] <mlankhorst> I don't think it will be impossible
[06:23] <mlankhorst> don't forget, the rest of the stack already works in a similar way
[06:23] <Sarvatt> best we can do is keep people on a long term support branch, its silly to stay on one driver forever imo
[06:24] <mlankhorst> yeah I plan on just making the old one the default, so if people update they just have to update to newer nvidia driver first, or afterwards
[06:26] <Sarvatt> its really crappy the first lts backport wont even be useful :(
[06:26] <Sarvatt> being done for haswell, but quantal wont work
[06:27] <Sarvatt> limited to the kernel though, we'll have to ship 3.7 or 3.8 even with quantal userspace
[06:34] <mlankhorst> you say that as if it's a bad thing
[06:35] <mlankhorst> would rather test while it's less useful than when it's really a must have
[06:36] <Sarvatt> it was a must have weeks ago, we have a bunch of OEM haswells people are freaking out about :)
[06:36] <mlankhorst> so do what we always do, backport drm into current kernel?
[06:36] <mlankhorst> :D
[06:37] <Sarvatt> oems dont pay for that to happen, everything has to be SRUed :P
[06:38] <mlankhorst> business as usual then :-)
[06:38] <Sarvatt> yep
[06:40] <Sarvatt> every tock is a problem apparently
[06:40] <RAOF> That's been the general case, yes.
[06:40] <RAOF> Although I don't think the GPU side is actually following the tick/tock cadence the same way.
[06:40] <mlankhorst> it's tocktock
[06:40] <RAOF> Probably because the GPU world moves faster.
[06:40] <Sarvatt> sandybridge we shipped with no acceleration at all in 10.10
[06:41] <RAOF> But it did support KMS! That's a pretty neat feature :)
[06:41] <mlankhorst> well with llvmpipe fallback I don't know how useful it is to only support kms
[06:41] <RAOF> Actually, kms + llvmpipe on haswell will probably be reasonably useable :)
[06:42] <mlankhorst> oh I mean that last time I tried llvmpipe glitched quite badly
[06:42] <RAOF> Ah. I think unity's fixed that.
[06:42] <RAOF> If not, they know *exactly* what they need to do to fix it.
[06:44] <Sarvatt> yeah pretty sure i saw them mention a ccsm change that fixed llvmpipe compiz a few weeks ago
[06:45] <Sarvatt> in the cirrus kvm bug
[06:45] <mlankhorst> ah :-)
[06:45] <Sarvatt> https://bugs.launchpad.net/compiz/+bug/1021104
[06:45] <ubottu> Launchpad bug 1021104 in Compiz Core "Severe damage artefacts and flickering when using LLVMpipe" [Medium,Triaged]
[06:57] <tjaalton> unity is better, but compiz still crashes quite easily with llvmpipe
[06:58] <Sarvatt> tseliot: have you given any thought to the q-lts-backports ubuntu-x-swat ppa that is going to go into q after release? -updates drivers you upload to precise need to provide newer abis if they support it for that i think
[07:00] <tseliot> Sarvatt: nvidia-current-updates is already in proposed (same version as the one in quantal), as for the rest, we don't have drivers which support the new ABI yet
[07:01] <Sarvatt> nvidia-current-updates in proposed does, does the precise-proposed one provide the xserver 1.13 abi too?
[07:01] <Sarvatt> somehow blobs are going to need to work with all of that, its going to be a headache
[07:01] <tjaalton> new abi support can be added as soon as the driver (properly) supports it, despite the release it's targeted at
[07:02] <tjaalton> hope that was engrish
[07:03] <tseliot> Sarvatt: we have 304.43-0ubuntu0.1 in precise-proposed but I'll have to hardcode the ABI there too
[07:05] <tjaalton> you have to hardcode the supported abi's in every release since it started :)
[07:06] <tjaalton> *since the package started to hardcode the abi
[07:08] <Sarvatt> going to be extra weird with nvidia-304 starting next release
[07:09] <tjaalton> how so?
[07:09] <Sarvatt> they're already at 306.xx on the windows side after dropping 6xxx and 7xxx
[07:10] <tseliot> also the 304.xx is gonna be a legacy driver...
[07:11] <Sarvatt> somehow transitioning people on 6 and 7xxx using nvidia-current to the new nvidia-304 package, don't even see how thats possible
[07:11] <tseliot> shall I call it nvidia-304?
[07:12] <tseliot> it would make sense
[07:12] <Sarvatt> well you already set that precident with 96 and 173
[07:12] <tseliot> right
[07:12] <tseliot> but no, transitioning won't be easy unless we add some code in Update manager (as we did in the past)
[07:16] <mlankhorst> :(
=== lilstevie_ is now known as lilstevie
[07:33] <RAOF> tseliot: We should really have a debian/supported_abis file for the nvidia/fglrx drivers and generate the Depends from that :)
[07:34]  * ogra_ thought you can do that with a var like ${slib:depends}
[07:34] <ogra_> *shlib
[07:35] <tseliot> RAOF: that's a good idea. Are there any other packages that do this already or would I have to write new code for it?
[07:35] <RAOF> tseliot: You'd need to write new code for it, I think.
[07:35] <tseliot> ok
[07:35] <mlankhorst> I don't see how updating some other file instead of control would help matters?
[07:36] <RAOF> tseliot: I don't suppose there's an easy way to *automatically* discover what ABIs are supported?
[07:36] <tseliot> mlankhorst: right now we update the debian rules which, in turn, uses debian/control.in to generate debian/control
[07:37] <mlankhorst> can't you just use a simple .vars file?
[07:37] <RAOF> Yes.
[07:37] <RAOF> Well, ish.
[07:37] <ogra_> what about ${xviddriver:Depends}, couldnt that just include the abi ?
[07:37] <RAOF> ogra_: It does; but the binary drivers support more than one ABI.
[07:37] <tseliot> RAOF: I'm not sure, maybe I should see if there's something we can extract from their README file
[07:37] <ogra_> RAOF, well, they will only support one in one distro release :)
[07:38] <RAOF> So we want to Depends: xorg-video-11 | xorg-video-10 | xorg-video-13 | ...
[07:38] <ogra_> why ?
[07:38] <ogra_> your xorg will only provide one ABI anyway
[07:38] <tjaalton> tseliot: you can't automate that part..
[07:39] <RAOF> Partially because it's a more accurate description of their dependencies. Partially because I don't think we particularly want to rename+backport the nvidia packages, so having them be forward-compatible is pretty nice.
[07:39] <tjaalton> tseliot: knowing what happened last time
[07:40] <tseliot> tjaalton: yes, it's better if we are in control
[07:40] <tjaalton> xserver has debian/serverminver, similar plumbing would work with the blobs
[07:41] <tjaalton> so debian/control has ${blob:Provides} and debian/rules then replaces that with some string
[07:41] <tseliot> tjaalton: that's just for one ABI though
[07:41] <ogra_> RAOF, apart from the fact that nvidia rarely even keeps up (or is ahead) with the ABi i would agree :) 
[07:41] <tseliot> the serverminver
[07:41] <tjaalton> tseliot: I meant the mechanism
[07:41]  * ogra_ is still waiting for a tegra release that supports more than ABI 12
[07:41] <tjaalton> have a file with the abi's, then rules replaces a string in control
[07:42] <tseliot> tjaalton: right, I'll see how that works and  see if I can reuse the code
[07:42] <RAOF> tjaalton, tseliot: Have a file with the abis, and then a rules fragment that dumps them in .substvars.
[07:43] <RAOF> That's more idiomatic; that's how ${shlibs:Depends} et al are done.
[07:43] <tjaalton> hmm right the xserver example was something else :)
[07:43] <tseliot> either way it's fine by me
[07:44] <tjaalton> use what RAOF suggested
[07:44] <RAOF> gen-abi-substvars: cat substvars >> nvidia-current.substvars ☺
[07:44] <tseliot> ok then
[07:45] <ogra_> RAOF, that would brak on the smiley :P
[07:45] <ogra_> *break
[07:46] <RAOF> Lies! dash is perfectly capable of writing to utf-8 filenames!
[07:46] <tseliot> :D
[08:26] <mlankhorst> ugh guess i better work on my presentation
[08:30] <tjaalton> about?
[08:30] <mlankhorst> optimus
[08:31] <tjaalton> of course..
[08:31] <mlankhorst> and all the kerne lcrap I've been working on I suppose
=== lool- is now known as lool
[09:49] <mlankhorst> ok the xorg-server patch for autobinding seems to work on my laptop
[09:50] <mlankhorst> can someone push out a new xorg-server version?
[10:00] <tjaalton> what's there?
[10:01] <tjaalton> oh that
[10:01] <tjaalton> forgot the udev patch, but I have it here..
[10:02] <tjaalton> need to run though
[10:02] <tjaalton> next week is soon enough :)
[10:02] <mlankhorst> hehe sure
=== yofel_ is now known as yofel