[05:51] <kva> hello, all
[05:51] <RAOF> Hello.
[05:52] <RAOF> Ok, so - you've managed to get all the way through to Unity at one point?
[05:52] <kva> yep, from live cd
[05:52] <RAOF> (If it said “your hardware doesn't support Unity” before running unity perfectly well… that's a bug ☺)
[05:52] <kva> unity gave many errors with starting plugins and install link
[05:53] <RAOF> Can you describe your symptoms more?
[05:53] <kva> sure
[05:53] <kva> ok, booting from live cd gives blank screen and error proposing classical desktop
[05:54] <kva> after it it fails to load plugins and permits to run installer
[05:54] <RAOF> You've skipped a lot of pre-X stuff there - what happens before then?
[05:54] <kva> after installing system won't boot
[05:54] <kva> nothing. blank dark screen
[05:55] <kva> problem isn't in X drivers, it's before,,,
[05:55] <RAOF> So, you stick in the CD, boot up, and see…?
[05:56] <kva> dark screen and then message saying that unity won't run on this hardware
[05:57] <RAOF> So, when you turn on your computer you don't get BIOS messages, then a LiveCD boot menu, then something, then the Unity thing?
[05:57] <kva> no boot menu. that's the problem
[05:58] <kva> sure I do get bios messages
[05:59] <RAOF> Hm.  I'm surprised that you don't get the Ubuntu livecd boot menu.
[05:59] <kva> well, I am talking to you using same laptop :-) it boots :-)
[06:00] <kva> no, black screen, maybe boot menu is right there, but I can't see it
[06:01] <kva> even switching to text console doesn't works
[06:02] <RAOF> That's quite odd.
[06:02] <RAOF> If you're on the livecd now, could you please pastebin /var/log/Xorg.0.log and dmesg?
[06:02] <kva> I am on debian
[06:03] <kva> sure I can
[06:04] <kva> what are you're interested in? I can send whole file
[06:04] <RAOF> I'm interested in the whole file, and the whole dmesg, but you'll want to send it to a pastebin.
[06:04] <kva> give me a minute
[06:05] <RAOF> Obviously I'd like these from the livecd session :)
[06:12] <RAOF> kva: No, you should paste the *links* to the pastebin here :)
[06:12] <RAOF> !pastebin
[06:12] <ubot4> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
[06:12] <bryceh> RAOF, mightn't it be better just to have him 'ubuntu-bug xorg' ?
[06:13] <RAOF> bryceh: Yes, it probably would!
[06:13] <bryceh> (him or her)
[06:13] <RAOF> kva: That's a much better idea; run “ubuntu-bug xorg” and give us the bug number.
[06:14] <kva> http://paste.ubuntu.com/557530/
[06:15] <kva> http://paste.ubuntu.com/557531/
[06:15] <kva> once again, I am not running ubuntu
[06:16] <RAOF> But you could do that from the livecd.
[06:17] <kva> sure, but not right now. if you really need it I can try :-)
[06:17] <kva> you have all details on the hardware for now, problem isn't there
[06:18] <RAOF> Yeah.  What I was after was some sort of logs containing the problem, which you obviously can't get from running Debian :)
[06:19] <kva> don't tease me :-) I just reinstalled the system like for 6th time in a row :-) I'll be glad to help
[06:19] <RAOF> Mesa builds much, much, *much* faster with a hot ccache when btrfs isn't making disc access painfully slow!
[06:19] <kva> but right now I have something running :-)
[06:20] <RAOF> kva: You don't have to *install* Ubuntu, just start up the livecd.
[06:20] <kva> ok, let me find it. 5 min
[06:20] <RAOF> And once you're there, “ubuntu-bug xorg” will be the quickest way to collect a bunch of relevant information.
[06:20] <bryceh> what is the problem description here?
[06:25] <bryceh> RAOF, there's a boot sequence outlined at https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
[06:29] <RAOF> bryceh: Ah, that's where that got to :)
[06:34] <kva> hm. sorry I have to download livecd first
[06:35] <kva> I owerwrited it with debian image :-(
[06:36] <kva> which image I can download for you?
[06:37] <kva> I mean which image will give you more details?
[06:37] <RAOF> The latest natty desktop cd would be the most useful one to test.
[06:37] <kva> which one i32 or amd64?
[06:38] <kva> or either
[06:41] <RAOF> Either.
[06:42] <kva> ok, downloading i32
[06:44] <kva> 10 min to go, 5 min to write, hope it'll reboot, you'll be here in a half an hour?
[06:47] <RAOF> Yeah.
[06:47] <RAOF> Hm.  I should perhaps look at the clock first.
[06:48] <RAOF> Mr Clocky says “5:45pm”, which makes half an hour less of a sure thing :)
[06:48] <kklimonda> :D
[06:48] <kva> I am lucky, mine says 7:48 :-)
[06:49] <kva> well, I cannot reboot faster :-)
[06:49] <kva> thank you for your help and good morning and nice dreams :-)
[06:49] <RAOF> Running “ubuntu-bug xorg” will put the interesting logs into a launchpad bug, though.  And you can probably try the things listed on https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
[06:51] <kva> well. problem is that I can't access grub menu... 
[06:52] <bryceh> why not?
[06:52] <RAOF> The livecd won't be using grub, anyway.
[06:53] <RAOF> But you really should be able to get *some* form of boot menu from the livecd.
[06:54] <kva> yup. live cd boots and gives an error, installation on hard drive can't even access to grub menu
[06:54] <RAOF> How are you trying to get access to the grub menu?  You need to hold left-shift during early boot to bring the menu up.
[06:55] <kva> but you're right, symptoms as described
[06:55] <kva> escape, never tried left shift 
[06:56] <evilvish> we dont need grub to boot live cd.. just make sure the BIOS is set to boot the cd first..
[06:56] <kva> sure I did
[06:56] <evilvish> once the cd boots, you'd have two options install/ try
[06:57] <evilvish> if cd is not loading … then either the iso(daily?) is bad atm..
[06:58] <evilvish> bad or broken.. some folks in ubuntu+1 did complain about installation not working..
[06:58] <kva> well, hope I will be able to install irc running livecd :-)
[06:59] <evilvish> kva: or you can just use IRC webchat from firefox.. ;)
[07:34] <kva> oups, it worked anyone here?
[07:49] <RAOF> kva: For a short while, yes.
[07:50] <kva> well, I sent a report but I don't have a number
[07:50] <kva> ubuntu-bug crashed
[07:51] <kva> but it listed all what you wanted :-)
[07:51] <RAOF> ubuntu-bug crashed?
[07:51] <kva> can you catch it up by ip?
[07:51] <kva> yep
[07:52] <kva> it reported that all is sent and crashed so I don't have a number
[07:52] <RAOF> It should have brought up a web browser for you to finish the thing?
[07:53] <kva> nope. only gnome window
[07:54] <kva> well, I can try again, disk is ready
[07:54] <RAOF> Yeah, that would be good.
[07:54] <kva> well, when you're sure :-)
[07:55] <kva> wait for me 5 min
[08:26] <kva> sorry for taking it so long
[08:27] <kva> 705078 and a couple of tries to report about gnome panel applets
[16:09] <Sarvatt> RAOF: looks like theres a new libglapi we need to ship now too
[16:37] <Sentynel> hi guys, the last nvidia update from x-updates seems to have royally screwed my system up
[16:38] <Sentynel> updated today and post-reboot, x wouldn't start, it just hung on a plain screen. wouldn't even accept ctrl alt f1 to drop to tty. I have a) ppa-purged x-updates, b) completely apt-get purged the nvidia-* packages, and c) tried xorg.conf from multiple backups I know worked in the past, as well as using nvidia's software to generate a new one. I am stumped as to what could be left that's causing problems. any ideas?
[16:41] <bjsnider> Sentynel, distro/hardware?
[16:41] <Sentynel> bjsnider: kubuntu 10.10, nvidia 9600GT
[16:41] <Sentynel> 64bit
[16:43] <bjsnider> does it still work without the 270 blob?
[16:43] <Sentynel> if I use the failsafe xorg.conf or completely remove all nvidia packages, I can get it to boot with the free software drivers
[16:45] <bjsnider> i think you should go to the nvforums linux site and generate one of their bug reports and submit it to them. until they release a new blob use the older blob in maverick
[16:45] <Sentynel> the version from the main ubuntu repo doesn't work eitehr
[16:45] <Sentynel> *either
[16:46] <Sentynel> after this issue, anyway; it worked prior to upgrading to the ppa version
[16:49] <Sarvatt> bjsnider: have you used those 270.18 packages? I didn't upload it for maverick/lucid because it has all kinds of problems on xserver 1.9.x here
[16:49] <bjsnider> yep
[16:49] <bjsnider> they work well here
[16:50] <bjsnider> i figured it was safe because nvidia doesn't usually break backwards compatibility
[16:50] <bjsnider> and if they did break something they'll probably release an update quickly
[16:53] <Sentynel> any ideas why the previously working 260.19 version from the main repos is no longer working? if I can just get that restored I'm not personally overly bothered about 270 for the time being
[16:53] <Sentynel> I guess something must have been left over from 270, but I cannae find it
[16:54] <bjsnider> Sentynel, try dkms status
[16:55] <Sentynel> nvidia-current, 260.19.06, 2.6.35-24-generic, x86_64: installed
[16:55] <bjsnider> now try ls -l /usr/lib/nvidia-current
[16:55] <bjsnider> make sure all of the versions match 260.19.06
[16:56] <Sentynel> yup
[16:56] <Sentynel> AH
[16:56] <Sentynel> er
[16:56] <Sentynel> no
[16:56] <Sentynel> grep fail
[16:56] <Sentynel> everything matches 260
[16:57] <bjsnider> have you got any strange stuff on your system, like xorg/mesa stuff from other ppas?
[16:58] <Sentynel> nope, this is the only vaguely graphics related ppa I've used
[17:18] <bryceh> RAOF, anything needing uploaded?
[17:36] <Sentynel> man, I can't get anywhere. only thing I've found which might be vaguely related is nvidia-detector returns "none"
[17:40] <Sentynel> any way of getting useful error output out of the x server trying to start?
[17:41] <jcristau> don't use nvidia is a good start
[17:42] <Sentynel> unfortunately I need a CUDA capable card
[18:21] <kva> strange, problem Sentynel had is quite close to mine...
[18:21] <Sentynel> kva: please tell me you fixed it
[18:21] <kva> but I am not using nvidia
[18:21] <kva> nope
[18:21] <Sentynel> arse
[18:22] <kva> just managed to send a bug report I hope
[18:22] <kva> also black screen and no text console at all
[18:22] <Sentynel> that's the one
[18:23] <kva> but that's on intel card, not nvidia
[18:23] <bryceh> "black screen" is a generic symptom, not a specific bug
[18:23] <bryceh> you guys could both have that same symptom but completely different underlying bugs causing it
[18:23] <kva> well, I explained, from live cd it boots finally but after install no chances
[18:23] <bryceh> also black screen bugs tend to be very hardware specific, so since you don't have the same hw it's 99.999% certain you *don't* have the same bug
[18:24] <bryceh> troubleshooting directions @ https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
[18:24] <kva> I won't be so sure, it has something to do with brightness controls
[18:24] <kva> maybe
[18:25] <bryceh> what we're telling reporters right now is to boot natty xorg-edgers and file a bug with 'ubuntu-bug xorg' (or attach info to an existing bug report via 'apport-collect <bug-num>'), and then we can forward the bug upstream.
[18:25] <kva> it has nothing to do with X directly, because even before X there's blank screen
[18:25] <kva> already done that this morning
[18:26] <kva> 705078
[18:26] <bryceh> also, the majority of black screen bugs on intel/ati/nouveau are actually bugs in the kernel kms/drm code, so testing a newer kernel snapshot can be worthwhile to do
[18:26] <bryceh> kva, yeah, so you're already narrowing it to kernel most likely
[18:26] <kva> sure
[18:27] <kva> but I am writing you from debian running older kernel
[18:27] <kva> same hardware :-) I am scared
[18:28] <kva> so when debian upgrades the kernel it won't start anymore? any ideas how I can report the problem so you can pin it?
[18:30] <kva> strange point is that livecd is working somehow after with a bunch of errors, but installed system won't even boot
[18:30] <bryceh> well those errors might be pertinent
[18:31] <bryceh> you should write them down and include them in the report
[18:31] <bryceh> e.g. maybe it's disabling something in livecd that it doesn't disable with install
[18:32] <bryceh> I don't know what kernel version debian plans to update to in the future, but if they happen to go to the same version you're on now it wouldn't surprise me to hear the bug is there too.
[18:32] <kva> well, actually I have a suspicion. I saw very fade, not black screen with choice try/install I know how it looks like
[18:32] <bryceh> but I'm guessing the problem will not be present in a .38 kernel, and I suspect debian will be targeting something newer than .37
[18:33] <kva> because to start livecd to the point where it lights up takes some punching on enter. you see what I mean?
[18:36] <bryceh> kva, nope sorry
[18:37] <kva> well, very fade screen with sidebar with choosing language on right and two big square buttons left - try, right - install
[18:38] <kva> normally it should be bright readable screen
[18:39] <kva> after pressing try it boots, after it says that unity isn't supported by my hardware and proposes to change session
[18:39] <kva> messages about changing session are well readable
[18:40] <kva> unity shall run normally, I don't see any problem. compiz runs
[18:41] <kva> are you able to access logs from my report this morning?
[18:48] <bryceh> kva, what's the bug #?
[18:48] <kva> 705078
[18:48] <kva> I attached logs to it this morning
[18:49] <kva> it was suggested and it's likely this one
[18:49] <bryceh> kva, no that bug belongs to Mario Limonciello, you need to file your own
[18:49] <kva> there's no logs attached from me?
[18:50] <bryceh> who suggested your issue was 705078?  That doesn't seem to match the problem you've described.
[18:50] <bryceh> kva, nope no logs on that bug from anyone but mario
[18:50] <bryceh> besides, it's not appropriate to attach your logs to someone else's bug report ;-)
[18:50] <kva> well. ok I have livecd so I'll reboot and file my own :-)
[19:04] <Sentynel> if anybody has any bright ideas for files or configuration that could be left over from the 270 drivers, now would be a good time, otherwise I'm going to have to reinstall, I fear
[19:09] <kva> well, 707088. need any more details?
[19:10] <kva> it proposed to file it against xserver but I am totally sure it's not where it belongs
[19:11] <kva> bryceh: that helps?
[19:12] <bryceh> kva, yes that helps a lot
[19:13] <bryceh> in fact, this proves indeed it is the same bug as 705078
[19:15] <bryceh> kva, I coded a patch for that bug, which you could test if you like.  Install this PPA:  https://launchpad.net/~bryce/+archive/bug705078/+packages
[19:15] <kva> well, could you join it to it? there were bugs launching applets, but I don't think that applets are in cause
[19:15] <bryceh> yeah those are unrelated issues (and I think already known)
[19:15] <bryceh> ok I'll join it
[19:16] <kva> well, I can't test it, patching livecd is a strange thing :-) but well, hope it helped you. will test when new livecd shows up
[19:17] <kva> thank you
[19:18] <kva> by the way, if you can pass it to where it belongs, livecd doesn't has any irc client which I know of, even chatzilla won't install on that version of firefox
[19:18] <kva> pidgin installs but well, you have to do it manually
[19:19] <bryceh> you need to bring that up elsewhere, we just look at X issues here
[19:19] <bryceh> I think they are pointing people to using web irc clients now
[19:19] <kva> sure, that's not really my concern here
[19:20] <jcristau> web irc clients?  eww.
[19:20] <kva> :-)
[19:21] <kva> soon we won't need hard drives, we'll boot from web :-)
[19:21]  * jcristau hates the web so much..
[19:22] <bryceh> jcristau, not to mention those damn kids on your lawn
[19:22] <evilvish> kva: we already have that.. cloud computing ;)
[19:23] <bryceh> anyway, I agree... I dunno why we haven't moved to a dvd image or something.  seems like we waste too much time shaving the .iso down to fit on cds and lose too many niceties as a result
[19:23] <kva> but really issue isn't there. if you can track it... from first purple screen till starting X the screen is completely blank, after it there's unity error and finally crash like this
[19:24] <kva> sure, I am burning iso on dwd-rw :-)
[19:24] <kva> losing like 3G of useful space
[19:25] <evilvish> irc client wont be a priority in the default even if we switch to dvd, irc is for geeks  :D
[19:25] <Sarvatt> RAOF: please please pleaseee dont upload ati based off debian-experimental branch, I get a crapload of complaints when r600g is broken
[19:25] <bryceh> evilvish, it is needed for providing tech support
[19:26] <kva> chatzilla is fine for me, just firefox coming with natty isn't supported yet :-) but well, that's not against you :-)
[19:27] <evilvish> bryceh: yea.. but still techsupport should not be the priority, it should just work ™  :)
[19:27] <kva> lol! :-)
[19:27] <bryceh> evilvish, I like the idealized world you live in ;-)
[19:27] <evilvish> ;)
[19:27] <kva> since when bleeding edge linux is just working without tricks and patches? :-)
[19:28] <evilvish> kva: you dont need to install any plugin, just use » http://webchat.freenode.net/
[19:29] <kva> well, never knew it :-) anyway you can install pidgin running from livecd image, I tested
[19:31] <cnd> bryceh, RAOF: I wanted to give you guys a heads up that we will likely be keeping the xserver gesture patches in natty
[19:31] <cnd> there are resource issues that are causing the change in plans
[19:31] <cnd> do you know what's going on with those patches in alpha 2 (pre-xi2.1 merging)?
[19:32] <cnd> I plan to forward port the patches onto xi 2.1 changes after alpha 2
[19:32] <evilvish> kva: we are already embedding it on some of the sites » http://unity.ubuntu.com/contact-us/ , http://loco.ubuntu.com/irc/ , once it gets better protection, we could just have a bookmark in FF linking to #ubuntu … 
[19:33] <evilvish> (else we'd have spam bots attacking)
[19:33]  * evilvish wanders off.. ;)
[19:33] <bryceh> cnd, I've not been tracking them upstream no.
[19:34] <bryceh> cnd, sounds like there are still potential abi bumps upstream coming in the next week or so, so we might hold off on xserver updates a bit longer
[19:34] <bryceh> was anticipating getting mesa in today but sounds like raof may need another day or so
[19:34] <cnd> bryceh, meaning they would drop into ubuntu after alpha 2?
[19:34] <bryceh> I think we can merge in newer drivers this week
[19:35] <cnd> but still the old xserver?
[19:35] <bryceh> cnd, potentially
[19:35] <bryceh> cnd, personally I'd really like to see all this get in for alpha-2 though.
[19:36] <bryceh> cnd, right that'd be new drivers, old xserver
[19:36] <cnd> k
[19:36] <bryceh> but I need to sort out plans with raof
[19:37] <bryceh> cnd, given that you're thinking of using the same patches as before, does that lessen your requirements for xserver 1.10?
[19:38] <cnd> bryceh, nope :)
[19:38] <cnd> 1.10 is needed for multitouch
[19:38] <cnd> our patches are for gestuers
[19:38] <Sarvatt> 1.10 or input abi 13 from 1.11...?
[19:39] <cnd> we really want 1.10, but either way we'll be patching in input abi 13 from 1.11
[19:39] <cnd> 1.9 just makes my life crazy hard :)
[19:40] <Sarvatt> were going to need to force IgnoreABI in xorg.conf for the nvidia blob in jockey for this non standard input abi tseliot
[19:40] <Sarvatt> ah not here
[19:41] <bryceh> Sarvatt, file a bug
[19:41] <bryceh> food, bbiab
[19:56] <ricotz> Sarvatt, hi :), is xserver update complete, it segfaulted with the latest xserver update on intel (without the intel driver update)
[19:57] <Sarvatt> ricotz: nope, new xserver video abi break got uploaded last night and i didnt see it until a few hours ago, things are still building
[19:57] <Sarvatt> actually, it looks like it's all built now
[19:57] <ricotz> Sarvatt, so the nvidia blob 270 wont run with this update?
[19:58] <Sarvatt> it wouldn't run with the last one
[19:58] <Amaranth> well that was fun :)
[19:58] <Amaranth> upgraded xserver-xorg-core from edgers but didn't have the -intel to go with it, hello segfault
[19:59] <Sarvatt> Amaranth: should be all fixed now, sorry about that.. a new server with the abi break got uploaded last night and the drivers didn't get updated but its all fixed up now
[19:59] <ricotz> Sarvatt, ok, i will try on my intel again ;)
[19:59] <Amaranth> yeah, it's all fixed now
[19:59] <Amaranth> now to get the data bryceh wanted
[20:01] <Sarvatt> RAOF: is this edgers-scratch branch you're pulling xserver packaging from public anywhere?
[20:04] <tjaalton> Sarvatt: nvidia doesn't care about the input abi ;)
[20:04] <tjaalton> only the input drivers do
[20:05] <Amaranth> huh, I think apport is crashing while trying to collect info
[20:05] <ricotz> tjaalton, so 270 might run with all other drivers updated?
[20:05] <tjaalton> ricotz: probably
[20:06] <ricotz> tjaalton, would be a hard time to revert everything if it fails :P
[20:06] <Sarvatt> oh I guess it might load anyway, they use input for their hotkey stuff.. [  2354.991] (WW) NVIDIA: This server has an unsupported input driver ABI version (have 12.1, need < 12.0).  The driver will continue to load, but may behave strangely.
[20:08] <Sentynel> ricotz: just a warning, upgrading to the 270 drivers completely screwed up my (kubuntu 10.10 64bit) system; currently reinstalling it
[20:08] <Sarvatt> i'm using 270.18 on the 0111 checkout of xserver 1.10, glx wont load because of the newer x extension abi though
[20:08] <ricotz> Sentynel, i already using it with xserver 1.10 on natty
[20:10] <Sentynel> ricotz: well, it appears not to work with the older xserver in maverick, for me at least
[21:36] <tjaalton> Sarvatt: oh, bah
[21:38] <Sarvatt> ricotz: yep nvidia 2D is busted now too with the latest server update
[21:50] <RAOF> Sarvatt: Yeah, it's a private git.debian.org repository.  You should be able to find it in ~raof-guest/public_git/xorg-server.git
[21:54] <bryceh> morning RAOF
[21:54] <RAOF> Morning bryceh.
[21:55] <bryceh> tjaalton, Sarvatt, RAOF, alpha-2 is coming up soon
[21:55] <RAOF> Feel like a little running of the unity teststuite on a new mesa?
[21:55] <bryceh> RAOF, sure
[21:56] <RAOF> Let me add the changelog entry and push.
[21:56] <bryceh> what issues exist for us to solve in order to get the X stack into alpha-2 ?
[21:57] <bryceh> I think that basically means getting it all uploaded by Friday, which gives us a few days for any final fixes
[21:58] <RAOF> We need a new x11proto-randr & x11proto-xext to build the server, a rebuild of evererything against the new server, and a new wacom upstream release.
[21:58] <Sarvatt> do we really want to do a libdrm-nouveau1a transition?
[22:00] <RAOF> What we *really* want to do is have a libdrm-nouveau2 transition, but that requires upstream participation.
[22:00] <bryceh> For  x11proto-randr & x11proto-xext, is that just a merge from debian?  would it break anything if we went ahead and uploaded that now?
[22:00] <kva> RAOF: we found my problem but it isn't linked with X for real, any ideas where I can ask?
[22:00] <RAOF> x11proto-randr & -xext require updating to a snapshot; they haven't seen a release yet.
[22:00] <bryceh> kva, your next step is to test the PPA I pointed you at.
[22:01] <kva> bug report is already treated by bryceh
[22:01] <bryceh> RAOF, that's ok
[22:01] <kva> well, problem is before starting X
[22:01] <RAOF> bryceh: So, it requires more than a merge from debian, but should be easy.
[22:01] <bryceh> RAOF, is the version in xorg-edgers the one we'd want in?
[22:01] <kva> all is cool :-)
[22:01] <RAOF> bryceh: Yeah.
[22:02] <bryceh> RAOF, Sarvatt, tjaalton, shall I go ahead and upload those two packages from xorg-edgers now?
[22:03] <RAOF> Ah, they'd want a cleaner changelog.
[22:03] <bryceh> I can take care of that
[22:03] <bryceh> tjaalton, didn't you have a script for doing rebuild requests?
[22:04] <bryceh> it would be nice if we could minimize the amount of driver broken time after updating the xserver
[22:05] <RAOF> I'd be ok with the x11proto-{randr,xext} from edgers being uploaded.
[22:05] <bryceh> regarding wayland, is there an existing release that just needs packaging or merging, or are we still awaiting the release?
[22:06] <RAOF> A release of wayland, or it's dependencies?
[22:06] <bryceh> er
[22:06] <bryceh> s/wayland/wacom/
[22:06] <bryceh> sorry finger muscle memory
[22:06] <RAOF> Heh.
[22:06] <bryceh> in any case wacom probably isn't a blocker
[22:06] <RAOF> I've got it packaged locally, needs uploading.
[22:07] <RAOF> It's a member of -input-all, which makes it moderately blockerfull.
[22:07] <bryceh> RAOF, ok can you dput it somewhere for me to grab?  Or shoot me a debdiff or whatever
[22:08] <RAOF> Certainly.
[22:09] <bryceh> ok, libdrm-nouveau1a 
[22:10] <bryceh> Sarvatt sounds concerned that's going to be a bit messy, what do you think raof?
[22:10] <RAOF> I don't think it'll be too bad.  We're already committed to rebuilding all its rdepends.
[22:11] <RAOF> I don't think that it'll prove to be much of a problem, and it will prevent people getting segfaulty partial-upgrades.
[22:12] <bryceh> alright
[22:12] <bryceh> ok, now to drivers...  we've got an -intel Q4 release we should package up... you planning on tackling that RAOF?
[22:12] <RAOF> Yes.
[22:13] <Sarvatt> intel is already ready in git
[22:13] <bryceh> ok, I looked at pulling the -ati rc snapshot, but it needs new mesa iirc so held off.  Looks easy - do you want to do that too or shall I?
[22:13] <Sarvatt> was really hoping we could avoid libdrm-nouveau1a so I didn't do libdrm yet but ah well
[22:13] <bryceh> Sarvatt, well I mean the actual release, not the git snapshot
[22:13] <RAOF> I've done libdrm
[22:13] <Sarvatt> http://sarvatt.com/downloads/patches/101_select_between_classic_and_gallium_dri.patch
[22:14] <Sarvatt> refreshed radeon patch for git
[22:15] <RAOF> We might also want to consider switching to r600g by default, but that can easily wait for a call-for-testing.
[22:16] <bryceh> yep
[22:16] <Sarvatt> http://sarvatt.com/downloads/patches/radeonbgnr.patch bgnr patch for radeon that works with xserver 1.10 too
[22:16] <bryceh> we'll have a few weeks after a2 before FF where we can fiddle with the buttons and switches
[22:17] <bryceh> Sarvatt, thanks
[22:18] <bryceh> RAOF, did you run into any other glitchy bits putting 1.10 into edgers that we need to account for?
[22:18] <RAOF> bryceh: http://cooperteam.net/Packages/ has wacom.
[22:18] <Sarvatt> wondering what we should version a radeon git checkout, I think 6.13.2+gitfoo might be best
[22:19] <RAOF> There were a couple of obscure drivers that needed a snapshot; siliconmotion was one.
[22:19] <bryceh> RAOF, great, got it.  Does that need to wait for 1.10 or can it get uploaded now?
[22:19] <Sarvatt> siliconmotion doesn't compile in git
[22:20] <Sarvatt> http://sarvatt.com/downloads/patches/siliconmotion-ABI.patch
[22:20] <Sarvatt> needs that
[22:20] <bryceh> ok
[22:21] <RAOF> Oh, and synaptics.
[22:21] <bryceh> Sarvatt, looks like that'd be safe to go in now
[22:21] <RAOF> Synaptics can be uploaded pre-1.10 and rebuilt.
[22:22] <Sarvatt> we are going to get an insane amount of bugs about synaptics :(
[22:22] <bryceh> I guess any bits we can upload *before* xserver 1.10, the simpler the transition will be, since everything'd just need a no-change rebuild
[22:22] <bryceh> Sarvatt, why's that?
[22:22] <bryceh> is there functionality lost with 1.10?
[22:22] <Sarvatt> have you used it yet?
[22:22] <RAOF> I was thinking of uploading post 1.10, but you're right, and buildd time is cheaper than the annoyance.
[22:23] <Sarvatt> they switched to a new acceleration mechanism that is unusable out of the box on all 5 of my laptops
[22:23] <bryceh> Sarvatt, just what is in xorg-edgers but didn't notice anything weird
[22:23] <bryceh> RAOF, yeah esp. for drivers, they don't take long to build
[22:24] <bryceh> Sarvatt, revertable?
[22:24] <Sarvatt> haven't figured out how to fix it yet, was reverting it from edgers but needs quite a lot of reverts now
[22:24] <bryceh> Sarvatt, can you file a bug report about it so we can have something to track and dupe bugs to?
[22:24] <Sarvatt> http://who-t.blogspot.com/2010/06/new-synaptics-acceleration-mechanism.html
[22:25] <Sarvatt> sure
[22:25] <bryceh> sounds like something we could fuss with post-a2
[22:25] <bryceh> mm, yeah looks like something we might want to turn off until there is a way to configure it
[22:26] <bryceh> Sarvatt, I think you're right we'd get a lot of bug reports otherwise ;-)
[22:26] <Sarvatt> I wish it was just slower like the blog post says
[22:26] <RAOF> We could also mess with the default settings in gnome-settings-daemon.
[22:26] <Sarvatt> but I cant move the pointer more than 1CM without it stopping
[22:30] <RAOF> I didn't notice a problem on my netbook when I tried it, but maybe I should try harder.
[22:30] <bryceh> RAOF, when you feel mesa 7.10 is ready to go in, ping me or send an email with pointer what needs uploaded.
[22:30] <RAOF> bryceh: Thanks.
[22:32] <jcristau> bryceh: yuo should stop sponsoring him so he needs to get core-dev privs :)
[22:32] <jcristau> you, even
[22:32] <RAOF> My application page is up :)
[22:33] <Sarvatt> hmm http://git.gnome.org/browse/gnome-control-center/commit/?id=59248ed8ba5ff58248f63c0e208c133de538d046
[22:33] <bryceh> jcristau, well if we weren't under a deadline ;-)  But actually I suspect he's accumulated enough sponsors to apply now.
[22:34] <RAOF> Sarvatt: But we can't pull that in, because it depends on gsettings.
[22:35] <bryceh> RAOF, ok also Sarvatt mentioned debian is in process of pulling 7.10 in there; might be best if we base the natty package on their stuff, or at least on the same source package
[22:38] <RAOF> Ah, yeah.  Some in-flight duplication :(
[22:38] <jcristau> RAOF: thanks for getting that osmesa build issue fixed btw
[22:39] <RAOF> Everytime I have to touch the buildsystem I think “autotools is the worst build system, apart from all the other ones that have been tried”
[22:39] <jcristau> +1
[22:39] <Sarvatt> just in time for talloc to get ripped out of the mesa build system on friday :)
[22:39] <RAOF> For the dricore patch I even went so far as to look at resurrecting some of the old autotoolification branches, but... urgh.
[22:40] <RAOF> Sarvatt: What, really?
[22:40] <jcristau> RAOF: they're in the process of NIHing it
[22:40] <RAOF> Superb.
[22:40] <jcristau> because omg lgpl.
[22:40] <RAOF> I knew that was a source of friction, but seriously?
[22:40] <RAOF> Gah.
[22:42] <RAOF> Ah, yes.  There it is.
[22:47] <Sarvatt> hmm looks like we need git synaptics instead of 1.3.0 too?
[22:47] <bryceh> RAOF, btw you can probably close out https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-in-mm
[22:50] <RAOF> Done.
[23:00]  * bryceh rolls eyes at #wayland
[23:18] <Sarvatt> bryceh: http://www.listshow.net/201101/kernel-team/45590-removing-debugfs.html ....
[23:19] <bryceh> ouch
[23:20] <albert23> hmm, isn't ureadahead using that too?
[23:21] <Sarvatt> yeah
[23:21] <jcristau> Sarvatt: as long as they keep it enabled for non-release kernels maybe it's not too bad.
[23:24] <RAOF> Ok.  What's changed that makes GM45 system lock so dependably.
[23:24] <Sarvatt> between which versions?
[23:25] <bryceh> jcristau, I'd agree
[23:26] <RAOF> Betwee yesterday and today.
[23:26] <RAOF> So last night's -intel upgrade is a good candidate!
[23:28] <RAOF> Ah, there we go.  dmesg finally has something interesting in it.
[23:28] <RAOF> Survey says: deadlock in gem!
[23:29] <Sarvatt> RAOF: no change between 0122 and 0124 intel uploads
[23:29] <Sarvatt> haven't updated mesa because it needs a new libglapi package
[23:30] <RAOF> Master does, yeah.
[23:30] <Sarvatt> uploading intel with that latest commit just incase
[23:31] <RAOF> This is not with edgers, it's with natty.
[23:31] <Sarvatt> ohhh
[23:31] <Dr_Jakob> Sarvatt: You don't need to do the libglapi thingy.
[23:32] <Dr_Jakob> Sarvatt: also libglapi is not seperate from libGL and you need to update them in lockstep.
[23:32] <RAOF> If you want to support gles without gl then you ned libglapi, right?
[23:33] <RAOF> Packaging can handle the update in lockstep; we'll just have =version as the dependency.
[23:33] <Dr_Jakob> no, if you want to run GL and GLES in the same applictaion you would need libglapi.
[23:33] <jcristau> i think we want libglapi
[23:34] <jcristau> the update in lockstep part is fine.
[23:35] <Amaranth> ooh, I am intrigued
[23:35] <Amaranth> Why would you have GL and GLES in the same app though?
[23:35] <bryceh> RAOF, Sarvatt, tjaalton, et al: kinda rough but here's a todo list from our earlier discussion - https://wiki.ubuntu.com/X/Roadmap/Natty - take a gander and see if anything's missing or needs clarification
[23:36]  * bryceh re-foods.  bbiab
[23:37] <jcristau> Amaranth: olv says it's a legitimate use of egl
[23:37] <jcristau> i'm inclined to believe him.
[23:37] <Dr_Jakob> it is..
[23:38] <Amaranth> Well, I suppose it is
[23:38] <Amaranth> I mean, if you can share between OpenGL ES and OpenVG I suppose OpenGL and OpenGL ES is possible but I can't imagine a reason for doing so
[23:39] <Sarvatt> Amaranth: http://lists.freedesktop.org/archives/mesa-dev/2010-December/004550.html
[23:39] <Dr_Jakob> the actual use case was to detect of one of the implementation where software I think.
[23:39] <Amaranth> ah, that makes sense
[23:40] <Amaranth> But how do you link to both? Or do you just link to libglapi?
[23:40] <Dr_Jakob> It doesn't look like those changes when into 7.10 so its all unrealesed stuff.
[23:42] <Amaranth> Oh, I see, you'd link to libglapi instead?
[23:42] <Sarvatt> yeah this is going in a PPA that I try to update from git daily, but the past few weeks have brought major changes weekly so its been fun :)
[23:43] <Amaranth> A guy in my team is actually implementing something like this too, a sort of gl proxy library
[23:44] <Amaranth> If ARM vendors provided mesa-based drivers it seems we wouldn't need it :/
[23:45] <Amaranth> oh, he commented on the thread :)
[23:47] <Dr_Jakob> Amaranth: team beeing?
[23:47] <Amaranth> Dr_Jakob: linaro graphics working group
[23:48]  * Dr_Jakob <-- Jakob Bornecrantz
[23:48] <Dr_Jakob> Was in one or two meetings.
[23:48] <Amaranth> dunno, I just started this month :)
[23:48] <jcristau> Amaranth: one case olv mentioned was an app using gles and a toolkit, and the toolkit using desktop gl
[23:49] <Amaranth> jcristau: Oh, yeah
[23:50] <Dr_Jakob> if you are using a toolkit you really should be using what the toolkit provides
[23:52] <jcristau> sometimes people don't, though.
[23:54] <RAOF> Gah.  Not plymouth.
[23:56] <Dr_Jakob> are you guys going to run r300g by default btw?
[23:56] <RAOF> We have for essentially all of Natty.
[23:56] <Dr_Jakob> ok
[23:57] <RAOF> We'll consider r600g by default after some testing with 7.10, too.