[12:53] <unity_supporter> Does anyone know whether the x-team is going to revert the intel i845 graphic driver back to intel or it is going to be fbdev like maverick (the mail archive is empty)?
[13:29] <brobostigon> afternoonings everyone.
[13:30] <brobostigon> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/715096
[13:30] <ubot4`> Launchpad bug 715096 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[i945gm] GPU lockup (ESR: 0x00000001 IPEHR: 0x02000011) (affects: 22) (dups: 15) (heat: 233)" [High,Incomplete]
[13:30] <brobostigon> is there anything more i can add to that bug to get things moving, i lost some serius work yesterday because of it.
[14:03] <Sarvatt> RAOF: I had to refresh 113_tls.diff in edgers to apply to master, hope I didn't break it in the process -- http://bazaar.launchpad.net/~xorg-edgers/mesa/packaging/revision/79
[14:53] <Sarvatt> RAOF, wgrant: radeon HD 5770 is fine with unity on edgers on i386, it must be amd64 specific
[14:53] <Sarvatt> or it was fixed in the past few days of updates
[16:48] <Sarvatt> multiarchifying mesa will be a fun adventure
[16:50] <jcristau> Sarvatt: pretty much like anything involving mesa, right?
[16:51] <Sarvatt> yeah, need to add guinness to the build-deps
[17:08] <Sarvatt> RAOF: hmm, yeah, amd64 only is screwed with 113_tls.diff and git mesa
[17:10] <Sarvatt> i386 sandybridge laptop is fine, amd64 one is trashed with unity. rebuilding without it to see if it fixes it just to be sure
[17:32] <Sarvatt> yeesh, http://cgit.freedesktop.org/mesa/mesa/commit/?id=6c324777a685d28d0a81d23157e4863240552999 makes unity infinitely more usable on sandybridge
[17:33] <Sarvatt> our 7.10 + that, no more 5 second waits to input text into the search popup
[17:33] <Sarvatt> wish I caught that before feature freeze..
[17:34] <jcristau> call it a bugfix
[17:36] <vish> Sarvatt: make sure to mention that to didrocks or njpatel..  ;)
[17:39] <Sarvatt> would be nice if sandybridge could go 5 minutes without a [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 69936, at 69936], missed IRQ? on 2.6.38
[18:04] <Sarvatt> oh goodie, hangchecks look to be fixed in current linux master
[19:42] <Sarvatt> wgrant: I backed 113_tls.diff out of mesa in xorg-edgers for now btw
[21:59] <wgrant> Sarvatt: Thanks.
[22:13] <LLStarks> hey bryceh, is nvidia-173 broken? it wants to remove a ton of packages.
[22:14] <bryceh> haven't really looked at nvidia so far this week, but I see we have a large number of new bugs filed
[22:14] <Sarvatt> yeah no nvidia-96 or 173 for natty
[22:14] <LLStarks> can i just use the binary from the nvidia site?
[22:15] <LLStarks> nouveau 3d is busted on this box. can't load unity.
[22:15] <bryceh> LLStarks, most likely won't help
[22:15] <LLStarks> can't brute-force it?
[22:15] <Sarvatt> it wont work, and it'll break things when you do get it installed to boot
[22:16] <bryceh> LLStarks, with the IgnoreABI stuff?  Not sure that's suitable in this case
[22:18] <LLStarks> how about edgers?
[22:20] <bryceh> I suspect only downgrading xserver would be sufficient to make 173 work
[22:21] <LLStarks> that's a bit much since i'd have to downgrade everything else. what's killing 173 atm?
[22:21] <tjaalton> the fact that it doesn't work with xserver 1.10
[22:22] <RAOF> Sarvatt: Radeon HD5xxx works fine here with mesa master + the tls fixes + amd64?  I presume that the problem is in the particulars of 113_tls.diff; it probably needs to be updated for master.\
[22:22] <LLStarks> is this something that will be fixed or just temporary?
[22:22] <tjaalton> depends on nvidia
[22:23] <LLStarks> wow. way to go nvidia. leave legacy support high and dry. are they finally deprecating the two?
[22:23] <LLStarks> i hope edgers nouveau will work with unity.
[22:23] <LLStarks> *crosses fingers*
[22:23] <tjaalton> it's the same story every cycle, they are low prio
[22:24] <LLStarks> ah. then that's okay.
[22:31] <bjsnider> LLStarks, typically those old drivers are updated within 24 hrs of a new ubuntu release but not before. they just don't have the manpower for it
[22:31] <LLStarks> heh\
[22:31] <LLStarks> grrr. software rasterizer only? gallium y u no work?
[22:32] <RAOF> With nouveau?
[22:32] <tjaalton> you need libgl1-mesa-dri-experimental for nouveau
[22:32] <LLStarks> yeah
[22:32] <LLStarks> it is
[22:32] <LLStarks> installed
[22:32] <LLStarks> i have an nv34
[22:32] <LLStarks> fx 5200
[22:33] <bjsnider> new hardware would be a better idea, if possible
[22:33] <LLStarks> this is just a screw-around box
[22:33] <RAOF> Time for everyone's favourite LIBGL_DEBUG=verbose!
[22:35] <LLStarks> lemme paste
[22:38] <blah> libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
[22:38] <blah> libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
[22:38] <blah> http://pastebin.com/Snc93SFK
[22:39] <LLStarks> really hofstra? really? you didn't give that pc a hostname?
[22:41] <LLStarks> whatever
[22:42] <LLStarks> raof, how's it look?
[22:45] <RAOF> LLStarks: That doesn't seem to include the LIBGL_DEBUG=verbose output?
[22:46] <blah> libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
[22:46] <blah> libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
[22:46] <tjaalton> LLStarks: do you have nouveau kms on?
[22:46] <blah> libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
[22:46] <blah> not sure
[22:46] <blah> think so
[22:46] <blah> i had a pretty plymouth
[22:46] <tjaalton> post the full server logfile somewhere
[22:46] <blah> k
[22:47] <blah> http://pastebin.com/188iEmc8
[22:48] <tjaalton> [    22.034] (EE) [drm] failed to open device
[22:48] <tjaalton> so you are using vesa..
[22:49] <tjaalton> nouveau blacklisted perhaps
[22:49] <blah> how can that be? i had a native plymouth
[22:49]  * blah checks
[22:49] <tjaalton> that's grub2 doing the mode handover
[22:49] <blah> ah
[22:50] <blah> 	Kernel modules: nouveau, nvidiafb
[22:51] <blah> \nothing listed in use
[22:51] <blah> OH
[22:51] <blah> wait
[22:51] <blah> nvidia-installer-disable-nouveau.conf
[22:51] <blah> lol
[22:52] <blah> wouldn
[22:52] <blah> work before that either though
[22:52] <blah> brb
[22:53] <tjaalton> you're on the x team and didn't even check your logfile >;)
[22:54] <LLStarks> yeah, i had the nvidia installer blacklist.
[22:55] <LLStarks> using nouveau now
[22:56] <tjaalton> the symlink is probably listed as a conffile, so a normal removal of the nvidia package doesn't delete the file
[22:56] <LLStarks> still no unity
[22:56] <jcristau> i didn't think you could have symlinks as conffiles
[22:57] <tjaalton> jcristau: dunno then, could be wrong
[22:57] <jcristau> or me.
[22:58] <tjaalton> at least nvidia-current.conffiles doesn't list it
[22:58] <LLStarks> okay, lemme paste a new xorg log.
[22:58] <tjaalton> why?
[22:58] <LLStarks> tjaalton, this was the nvidia.com binary
[22:58] <bjsnider> nvidia-current does not install that file, nore create any such link. it does blacklist nouveau by creating another conf file
[22:58] <tjaalton> LLStarks: ok, you lose then
[22:58] <LLStarks> because, unity doesn't load and the desktop icons just flash
[22:59] <bjsnider> that file was probably created by nvidia's installer, which he shouldn't be using
[22:59] <tjaalton> nvidia-graphics-drivers.conf -> /etc/alternatives/nvidia_modconf
[22:59] <tjaalton> that's in /etc/modprobe.d
[22:59] <tjaalton> here
[22:59] <tjaalton> LLStarks: what was the name of the file?
[23:00] <LLStarks> it didn't work before either.nvidia-graphics-drivers.conf
[23:00] <LLStarks> ack
[23:00] <LLStarks> nvidia-graphics-drivers.conf
[23:00] <LLStarks> in modprobe.d
[23:01] <tjaalton> nvidia-current does install that file
[23:01] <bjsnider> that file is created by ubuntu, but the file mentioned by blah isn't
[23:02] <tjaalton> so the nvidia.com binary creates the same file? hard to believe
[23:02] <bjsnider> the file he mentioned was called nvidia-installer-disable-nouveau.conf
[23:02] <LLStarks> wait. one sec.
[23:03] <tjaalton> ok missed that
[23:03] <LLStarks> wait, it was disable nouveau or what you said
[23:03] <LLStarks> not the nvidia-graphics-drivers
[23:03] <tjaalton> ok then, so created by the nvidia installer
[23:03] <LLStarks> sorry for the brainfart
[23:04] <bjsnider> LLStarks, you used the nvidia-installer?
[23:04] <Sarvatt> LLStarks: I had to disable nouveau_vieux in edgers for the past few uploads because the build is broken
[23:04] <blah> new xorg: http://pastebin.com/xk0K91j6
[23:04] <Sarvatt> should be fixed in tomorrows upload
[23:04] <blah> bjsnider, i tried it. didn't get past blacklisting nouveau.
[23:05] <blah> libGL: OpenDriver: trying /usr/lib/dri/tls/nouveau_dri.so
[23:05] <blah> libGL: OpenDriver: trying /usr/lib/dri/nouveau_dri.so
[23:05] <tjaalton> Sarvatt: this uses nouveau_dri, not vieux
[23:06] <blah> i think everything but unity-3d works fine now
[23:06] <tjaalton> blah: everything looks normal there
[23:07] <LLStarks> there's also the well-documented graphical corruption
[23:07] <LLStarks> but that's another day, another battle
[23:16] <LLStarks> thx


[01:15] <axw> hey wallyworld_, did you see my message on Friday about authorized_keys?
[01:15] <wallyworld_> um
[01:15] <axw> about modifying for the ubuntu user
[01:15] <wallyworld_> if i did i forgot
[01:15] <wallyworld_> i don't think i saw
[01:16] <axw> wallyworld_: maybe I'm just missing something, but I don't see where the ubuntu user is specified when the worker modifies authorized_keys
[01:16] <wallyworld_> it's not
[01:16] <axw> shouldn't it be? that's what we log in as
[01:17] <wallyworld_> the current auth keys file with the key from bootstrap doesn't specify the ubuntu user does it?
[01:18] <wallyworld_> so i'm just adding additional keys in the same way
[01:18] <axw> wallyworld_: I'm pretty sure cloud-init will put it in the ubuntu user's one
[01:19] <axw> well, it must, since we log in as that during bootstrap
[01:19] <wallyworld_> i assumed that the auth keys would be added to /home/ubuntu/.ssh/...
[01:19] <wallyworld_> i guess it depends what ~ resolves to
[01:20] <wallyworld_> i'm sure i checked though
[01:20] <wallyworld_> and the ubuntu user auth keys file was the one that got updated
[01:20] <wallyworld_> but now i'm doubting myself
[01:21] <axw> wallyworld_: I didn't see it getting updated, but I did see /root/.ssh/authorized_keys had some updated keys in it
[01:21] <wallyworld_> hmmm. maybe i didn't check then. but i thought i did
[01:22] <wallyworld_> i'll do a fix if necessary
[01:22] <axw> I'll have another look in a bit
[01:22] <wallyworld_> i could have sworn i checked etc but maybe not
[01:22] <wallyworld_> i guess if the processes are running as root, the ~ will not resolve to ubuntu
[01:23] <axw> right
[01:23] <wallyworld_> too bad that they are running as root :-(
[01:23] <axw> I was wondering whether we should be using something less generic than "ubuntu" now
[01:23] <wallyworld_> i sorta assumed perhaps that we would not do something that silly :-(
[01:23] <axw> like create a "juju" user at init time
[01:24] <axw> then manual provisioning would be less of a special case regarding key management
[01:24] <wallyworld_> that makes sense. get ready for a whole lotta bikeshedding though :-)
[01:24] <axw> :~(
[01:24] <wallyworld_> well maybe not, there's always a first time :-)
[01:28] <wallyworld_> so cloud init does explicitly rely on a specific user being set (default ubuntu)
[01:28] <wallyworld_> so looks like i need to do a fix
[01:30] <axw> okey dokey
[01:31] <axw> wallyworld_: will things break horribly if the ubuntu user doesn't exist?
[01:31] <axw> (manual provisioning doesn't yet create it)
[01:31] <wallyworld_> i don't *think* so, but am not sure
[01:31] <axw> no worries, I can test later
[05:24] <wallyworld_> axw: i fixed the ssh auth keys user issue. turned out to be a bit of a bitch cause of the way our tests override ~. if you get a chance, could you take a look? https://codereview.appspot.com/40650049
[05:25] <axw> wallyworld_: cool, thanks, will have a look now
[05:25] <wallyworld_> ta
[05:25] <wallyworld_> i tested live on hp cloud
[05:28] <axw> wallyworld_: why not use osenv.Home() on Windows too?
[05:28] <wallyworld_> axw: does windows support $HOME? i wasn't sure and didn't think it did
[05:29] <axw> wallyworld_: just had a look, osenv.Home() does different things for Windows
[05:29] <axw> not $HOME, but $HOMEDRIVE
[05:29] <axw> or %HOMEDRIVE% at any rate :)
[05:29] <wallyworld_> but will that return the user home dir
[05:29] <wallyworld_> or the drive letter?
[05:29] <axw> umm
[05:30] <axw> wallyworld_: it's %HOMEDRIVE%%HOMEPATH%
[05:30] <axw> with a slash in between
[05:30] <wallyworld_> either way, our tests won't work on windows as is
[05:30] <axw> true
[05:30] <wallyworld_> so i think a todo is ok and we can fix the tests wheneever we want to run on windows
[05:31] <axw> fair enough
[05:31] <wallyworld_> our tests also just assume all paths with ~ are of the form ~/foo
[05:47] <wallyworld_> axw: thanks for looking, i'll fix the little issues
[05:47] <axw> wallyworld_: nps, thanks for fixing
[05:48] <wallyworld_> including nuking bob :-)
[05:48] <axw> :)
[06:16] <wallyworld_> axw: that's merged now
[06:16] <axw> wallyworld_: thanks!
[06:16] <axw> I'll test it with manual later
[06:16] <wallyworld_> np, thanks for letting me know about the issue
[06:17] <wallyworld_> i'm off for a bit to take the dog for a bath. he rolled around in some shit at the park yesterday and he stinks :-(
[07:41] <axw> grr, my wireless keeps dying
[08:18] <wallyworld_> try another channel?
[08:51] <axw> well it recovers if I restart networking, so I don't think it'd be interference
[16:34] <natefinch> fwereade, are you around?