[20:58] <apw> Amedee (N,BFTL), that fix is marked for stable, so I would expect it to get backported naturally by the stable folk and integrated.


[11:31] <de-facto> so what options would i have in gnome for a screensaver? i installed gnome-screensaver, but it does not have ANY options in settings, wheni launch it via cli it just says its already running, well GREAT, where can i configure this?
[11:32] <de-facto> is gnome-screensaver broken atm? or are there better options? what about xscreensaver instead?
[11:43] <jbicha> gnome-screensaver these days intentionally only blanks the screen
[11:50] <de-facto> hmm but gnome itself already can do that, i dont understand the purpose for the existence of gnome-screensaver then
[11:50] <de-facto> are there any options for having a classic screensaver like in the old gnome2 days?
[11:51] <jbicha> gnome uses gnome-screensaver to blank the screen
[11:52] <jbicha> you can try xscreensaver; I don't know how difficult it is to integrate with GNOME 3
[11:53] <de-facto> it was not installed on my box and it had that lockscreen blank out already
[11:56] <de-facto> i dont understand why all those options got removed, every release it seems there are less features avail
[11:56] <de-facto> for example there was a dialogue for choosing the pixel ordering of screens in gnome2
[11:57] <de-facto> was done really well, nice and clean and worked just perfectly
[11:57] <de-facto> nowerdays i have to click through dconf and find that setting there everytime i use gnome 3 on a BGR screen
[11:58] <de-facto> if i dont know that black magic, i would have to sit back and arrange myself with rainbow colored fonts
[11:58] <de-facto> in old gnome2 i just would have to be curious enough to click on settings and there, problem solved
[11:59] <jbicha> gnome-screensaver dropped support for doing more than blanking screens about 5 years ago
[11:59] <de-facto> yeah so its useless nowerdays, what for would i need gnome-screensaver then if it does exactly the same that gnome already can do without it?
[12:02] <jbicha> blanking the screen is all most people need now
[12:03] <jbicha> you're right that gnome-screensaver is not installed by default now; I forgot
[12:28] <de-facto> well it seems xscreensaver does not integrate at all with gnome, so i disable screen lock in gnome and let xscreensaver do it on its own :(
[13:58] <LinDol> hi all
[17:34] <noggerfroggereli> Hi, guys may i ask a question here?
[17:35] <noggerfroggereli> i didnt' remember to disable nvidia proprietary drivers before version upgrading to 16.04
[17:36] <noggerfroggereli> and tty7 is as dark as night
[17:37] <noggerfroggereli> i would like to know there is a way to simply revert to intel graphics from command line so i can install nvidia drivers properly?
[17:37] <noggerfroggereli> is there*
[17:37] <noggerfroggereli> :p
[18:29] <sej> u are lucky today
[18:30] <sej> oops he is offline
[18:30] <sej> nvm
[20:46] <tux|dude> Hi
[20:47] <tux|dude> Just installed gnome remix yesterday. Made the jump from kubuntu. Found that while I liked plasma 5 it still had a few issues


[12:06] <asac> fta: there?
[12:06] <fta> asac, yep but not for long
[12:07] <asac> fta: ho ;) ... great
[12:07] <asac> fta: so debian folks go nuts ... ;)
[12:08] <asac> fta: they said they cant wait longer for chromium ... and then after discussing they said that a security team guy of debian wants to maintain it
[12:08] <asac> actually he wanted to take it over
[12:08] <asac> i suggested that he joins your team
[12:09] <asac> and told him to chat with you and me about what the rules would be in a branch
[12:09] <asac> err in our bzr branch
[12:10] <asac> fta: anyway. first step would be to upload this weekend.
[12:11] <asac> fta: which a debian developer needs to do at first, but after that and applying for Dm status in debian for that package you can upload to debian directly and then sync to ubuntu
[12:11] <asac> i just wanted to ask if uploading to debian directly is ok with you
[12:11] <fta> *sigh*
[12:12] <fta> more bureaucracy
[12:12] <asac> fta: but after that you get a guy that said he can deal with the security mess for chromium ;)
[12:13] <asac> and not pain because debian starts to build their own chromium way of packaging
[12:13] <asac> or something stupid like that
[12:14] <fta> well, the problem i see here is that if that security guy works on it, it will be in the beta part, he won't maintain head and dev
[12:14] <asac> fta: is that a problem?
[12:14] <asac> i mean in general i see that its better if he could help everywhere
[12:15] <asac> but isnt help on one side an improvment?
[12:15] <fta> that means even more merges between the branches
[12:16] <fta> help is good, i just feel i won't be able to keep track, that's it
[12:16] <asac> fta: well. what i think what he will do is a) keep his own branch
[12:16] <asac> for stable package maintenance and do cherry picks
[12:16] <asac> or
[12:16] <asac> he would just do release management ... in the sense that he uploads beta or stable releases that are done anyway
[12:17] <asac> e.g. we do all stable/beta bumps in our branches anyway, dont we?
[12:17] <asac> so he could take some version he thinks is good and upload that and do the paperwork for debian security team at least
[12:17] <asac> then we can check if he does good work and use the same tags as he does (so no need to figure exactly what to upload)
[12:18] <fta> ok, i have no strong feeling about all that, it's meant to happen anyway so be it
[12:18] <asac> i think he should come here and you can talk about what would be possible/not possible.
[12:19] <asac> fta: ok. you said you have not much time today? when should i get him here?
[12:21] <asac> fta: by the way. did you ever hear if chromium linux is supposed to be on stable for 5
[12:21] <fta> nope
[12:22] <asac> this beta madness really .... ;)
[12:22] <asac> but welll thats how it is.
[12:24] <asac> fta: let me know when i should get giuseppe in here ;)
[13:21] <asac> Derevko: hey ;)
[13:21] <Derevko> hi
[13:21] <asac> fta: ^^ ... he is debian peer i spoke about
[13:22] <asac> we were talking about what to release to debian usually
[13:22] <asac> Derevko: so currently beta channel is the best we have
[13:22] <asac> Derevko: that means if my suggestion makes sense we would look in the releaseblog what was last announced
[13:23] <asac> and consider packaging that
[13:23] <Derevko> asac: yes, I agree
[13:23] <asac> however, the problem then begins ... we dont know what the releases you see on that RELEASE url
[13:23] <asac> were about.
[13:23] <asac> they could a) be experiments/improvments etc.
[13:23] <Milos_SD> Hi. When will dom.ipc.plugins.enabled start working on Firefox 3.7 from this PPA? :(
[13:23] <asac> or b) reression fixes for that push
[13:23] <asac> regression fixes for that push ;)
[13:23] <asac> so thats where i am still in the dark ;)
[13:24] <asac> we could assume that regression fixes would be annonuced
[13:24] <asac> I will take the action to check that with the chromium folks
[13:24] <asac> Derevko: so ok; whats last on beta release bog?
[13:24] <asac> 5.0.342.9
[13:25] <asac> so if my theory is riht, we should be able to find that on the beta branch
[13:25] <asac> hmm
[13:25] <asac> i think we should make fta do release commits for all versions if thats a good scheme
[13:27] <asac> great. launchpad gives internal server error
[13:27]  * asac branches
[13:28] <asac> hmm.
[13:28] <asac> fta: i think the tagging could be improved
[13:29] <asac> fta: this is what i see with bzr log --include-merges on .beta branh
[13:29] <asac> http://paste.ubuntu.com/421645/
[13:29] <asac> so there you seemed to have merged the packaging for the .9 release
[13:29] <asac> from .head
[13:29] <asac> (so seems they release .9 everywhere)
[13:29] <asac> up to beta
[13:30] <asac> anyway.. i think the .head commit should be something like ...0ubuntu1~head ... then we could have tagged the real commit on .beta branch like 0ubuntu1~beta
[13:30] <asac> e.g. in a release commit after the .beta merge
[13:31] <asac> Derevko: so atm i think its the latest .beta packaging ... which is the upstream version we have on release blog
[13:32] <asac> Derevko: we could maintain a downstream branch from .beta ... and whenever we pick something merge it don
[13:32] <asac> down
[13:33] <asac> as we might need to change Maintainer: etc. though in the end we could do tha ton the real branches ... but hav eto sync with fta as his bot might need to get fixed to do the versioning etc. right
[13:33]  * asac talks too much
[13:33] <asac> feels like swamping Derevko ... maybe play around and build the branch ;)
[13:44] <Derevko> asac: I was under the impression that lp:chromium-browser was the main branch from where the Ubuntu lucid packages (and so also the Debian packages will?) were built, but perhaps I'm wrong.
[13:45] <asac> Derevko: do you have that branched? please paste bzr info inside
[13:46] <asac> let me see
[13:46] <asac> thats .head indeed
[13:46] <asac> checking out
[13:47] <Derevko> asac: http://paste.debian.net/70437/plain/70437
[13:47] <asac> Derevko: yeah. seems thats currently the case
[13:47] <asac> Derevko: so we need to talk to him
[13:48] <asac> as long as we have a single branch thats fine. but imo that should be .beta
[13:48] <fta> sorry, i was off (and i'm back just for ~10min)
[13:48] <asac> no problem
[13:48] <asac> fta: can you explain why you release beta releases from .head?
[13:48] <fta> i tag and release in .head,
[13:49] <fta> then i merge in the beta branch just for the beta ppa
[13:49] <asac> and if you release _all_ beta releases from .head or if there might be a beta release from .beta for some circumstances
[13:49] <asac> fta: what do you do if they do a cherry pick release on beta channel
[13:49] <asac> and dev etc. have already moved on?
[13:49] <asac> just a retroactive release?
[13:49] <fta> well, it tried many things, releasing from beta then merging back to head, or the opposite
[13:50] <asac> fta: why do you need to merge back beta releases?
[13:50] <asac> i would think its just one commit on the beta branch after the merge
[13:50] <fta> changelog mostly
[13:50] <asac> true. so ok
[13:50] <asac> for the case i metntioned you could probably just branch out an old revision
[13:50] <asac> do the release there
[13:50] <asac> merge back into .head?
[13:50] <asac> and into .beta ;)
[13:51] <asac> (for ppa)
[13:51] <asac> i guess something like that hasnt happened yet?
[13:51] <fta> i'm constantly improving .head, but head is sometimes/often ahead, so it's a merge vs cherry pick fight
[13:52] <fta> one way or another, i have to merge one and either cherry-pick or revert the other
[13:52] <fta> (by revert, i don't mean uncommit, just commit a reversed patch)
[13:53] <fta> rollback
[13:53] <asac> fta: so to understand when head has moved away, you branch out the old versoin that was closest? do the release there and merge that back into .head?
[13:53] <asac> wouldnt that make senes?
[13:53] <asac> we do that for firefox when that moved ahead and it works quite well
[13:53] <asac> (though chromium is a bit of a different situation with there super volatile versions ;))
[13:54] <fta> nope, i bzr diff from the previous release, and drop everything that is too far ahead
[13:54] <asac> fta: in the branch?
[13:54] <fta> yes
[13:54] <asac> so the brnach goes backwards sometimes?
[13:54] <fta> that's what your paste is showing
[13:54]  * asac reads opens it again
[13:54] <fta> not really, it recommit the changes on top just after the release
[13:55] <fta> -it+I
[13:55] <asac> fta: why not doing it like i suggested? that would be kind of a logical way.
[13:55] <asac> its kind of not nice changelog wise, yes. but it works i think ;)
[13:55] <fta> it's not perfect, but that's the best way i could find to manage 3 channels in parallel with less differences
[13:56] <fta> as i said, the master branch is .head
[13:56] <fta> no merge in there
[13:56] <asac> so for the last beta release we could hav branches 512
[13:56] <asac> we bake a beta release there. then just merge it back because of changelog and also merge that into the .beta branch
[13:57] <asac> preparing the release is a manual operation anyway
[13:57] <asac> its just a retroactive mini branch
[13:57] <fta> it's possible, it's just not the way i did the last 4~5 releases
[13:57] <asac> yeah. maybe think about it ... i think thats less hazzle that way
[13:58] <asac> anyway i think i know what to do then
[13:58] <asac> for upload we release just the last version announced ;)
[13:58] <asac> easy enough
[13:58] <asac> then when something is in stable releases we only upload that what was announced either as regression fix or a security update
[13:59] <asac> now we have to find out what that is ;)
[13:59] <asac> also we hope that regression fixes are announced ;)
[13:59] <asac> and that those bumps without announce (if there are any) usually is for adding new stuff
[14:00] <fta> just to clarify, when i fix a bug, i do it in .head so it's immediately available to the crowd, then it will be in the next release if it's not urgent otherwise i create an incremental release immediately
[14:00] <fta> (i have to run now)
[14:00] <asac> fta: ok. so you decide what you backout based on importance? e.g. you dont revert all?
[14:01] <asac> thanks
[14:01] <asac> ttyl
[14:02] <asac> Derevko: so that makes some sense.
[14:02] <asac> Derevko: at least for now ... pick the tag associated with the release we want
[14:02] <asac> e.g. branch that ... then change the debian/control as we need and upload ;)
[14:03] <asac> then next time ther eis a release we want, merge that tag to that branch and upload
[14:03] <asac> maybe we should collapse changelogs
[14:03] <asac> then we can at some point think about how to do the debian packaging in the branch so it becomes upstream there
[14:04] <fta> you should branch one of those: http://paste.ubuntu.com/421663/
[14:04] <asac> (in the .head branc)
[14:04] <asac> yeah
[14:06] <asac> Derevko: add fta, me, you as the uploders and the chromium alioth mailinig list as maintainer ;)
[14:06] <asac> Derevko: are you good at perl?
[14:07] <asac> i messed up the licensecheck.pl thing ... e.g. there is a sort problem ... so generating licenseinfo updates is bad to read in diff
[14:07] <asac> never had time to fix it ;)
[14:09] <asac> my @values = values %{$$data{$dir}{$license}};
[14:09] <asac> i think that need to be sorted
[14:10] <Derevko> asac: no sorry
[14:11] <asac> heh. np
[14:31] <Milos_SD> Hi. When will dom.ipc.plugins.enabled start working on Firefox 3.7 from this PPA?
[16:40] <chrisccoulson> Milos_SD - i will fix that tomorrow if nobody has done that before then
[16:40] <chrisccoulson> oh
[16:40] <chrisccoulson> he didn't hang around ;)
[19:01] <fta> asac, i can teach you
[19:01] <fta> asac, by what do you want to sort the hash?
[21:07] <BUGabundo> even|ng


[01:02] <RAOF> bryceh: Revised mesa with better changelog, debian changelog in source.changes, and actual building on i386 is up on cooperteam.net.
[01:05] <bryceh> RAOF, awesome thanks
[01:06] <RAOF> Oh, and perhaps incidentally, it also works ;)
[01:06] <bryceh> RAOF, btw the previous mesa had been failing to build
[01:06] <bryceh> # Also get rid of other files which aren't installed. Do not
[01:06] <bryceh> # use -f to ensure we notice disappearing files:
[01:06] <bryceh> set -e; for file in dri/usr/include/GL/glfbdev.h dri/usr/include/GL/glu.h dri/usr/include/GL/glu_mangle.h dri/usr/include/GL/mesa_wgl.h dri/usr/include/GL/osmesa.h dri/usr/include/GL/vms_x_fix.h dri/usr/include/GL/wglext.h dri/usr/include/GL/wmesa.h dri/usr/lib/libGL.so dri/usr/lib/pkgconfig/gl.pc usr/include/GL/glext.h usr/include/GL/glfbdev.h usr/include/GL/gl.h usr/include/GL/gl_mangle.h usr/include/GL/glxext.h usr/include/
[01:06] <bryceh> v/pkgconfig/gl.pc ; do rm debian/tmp/$file; done
[01:06] <bryceh> rm: cannot remove `debian/tmp/usr/lib/i686/cmov/libGL.so': No such file or directory
[01:06] <bryceh> make: *** [binary-arch] Error 1
[01:06] <bryceh> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
[01:06] <bryceh> E: Failed autobuilding of package
[01:06] <RAOF> bryceh: Yeah, that's what I fixed for i386.
[01:06] <bryceh> hadn't had a chance to investigate it yet though.  Will try again with your new package
[01:06] <RAOF> if you were to build that package on amd64 it would have built just fine :)
[01:07] <RAOF> It's becaues Debian build i686 swrast packages on i386 and we don't.
[01:07] <RAOF> Or even because.
[01:08] <bryceh> huh interesting
[01:08] <bryceh> dpkg-source: info: upstream files that have been modified:
[01:08] <bryceh>  mesa-7.10.1~git20110215.cc1636b6/src/mesa/drivers/dri/common/dri_util.c
[01:08] <bryceh>  mesa-7.10.1~git20110215.cc1636b6/src/mesa/drivers/dri/radeon/radeon_bocs_wrapper.h
[01:08] <RAOF> Yeah.  From debian's cherry-picks.
[01:09] <RAOF> Debian cherry-picks into the debian diff, and I think we should too.
[01:09] <RAOF> It means the cherry-picks get automatically dropped when they get included in the upstream tarball.
[01:12] <RAOF> Hm.  Sam's out at work.  I'll have to make my *own* coffee this morning!
[01:16] <bryceh> heh
[01:16] <bryceh> I will be joining you in a cup, even though it's after 5pm
[01:31] <bryceh> go little processor go, let's get this mesa built
[01:32] <RAOF> I could throw up binaries if you wanted.
[01:35] <bryceh> nah it just finished
[01:35] <bryceh> might not be a bad idea in the future though
[01:36] <bryceh> otoh can't hurt to doublecheck the build
[01:37] <bryceh> I'm installing libgl1-mesa-dri_7.10.1~git20110215.cc1636b6-0ubuntu1_i386.deb libgl1-mesa-glx_7.10.1~git20110215.cc1636b6-0ubuntu1_i386.deb libgles2-mesa_7.10.1~git20110215.cc1636b6-0ubuntu1_i386.deb
[01:38] <bryceh> anything else worth putting in for testing purposes?
[01:38] <bryceh> well, lets start with this... rebooting
[01:39] <RAOF> ...
[01:39]  * RAOF is too slow :)
[01:43] <bryceh> metacity looks fine...
[01:44] <bryceh> ew, unity looks like trash
[01:45] <RAOF> What card?
[01:45] <bryceh> RV770
[01:46] <bryceh> actually it was fine after I did a screen refresh
[01:46] <bryceh> guessing it's a dual-head issue, since only the left screen showed it
[01:47] <RAOF> Ah, yeah, entirely possible.
[01:47] <bryceh> (it redrew the left portion of the screen in the middle of the screen)
[01:47] <bryceh> anyway, otherwise so far so good
[01:47] <RAOF> Nux is easily confused about where things should be.
[01:47] <bryceh> also to be honest I'm not sure that effect might have been there previously
[01:47] <RAOF> Apart from, I presume, alt-tab still segfaulting in mipmap generation code :)
[01:47] <bryceh> oh yeah lemme try that
[01:48] <RAOF> (Still segfaulted here, and also did so on master, so I'm quite confident that yours will segfault too ;))
[01:48] <RAOF> Oh.  That looks ominous!
[01:49] <bryceh> yep sure did
[01:49] <bryceh> also, left screen weirdness reproduces 2-for-2
[01:49] <RAOF> Is there any dynamic xrandr happening?
[01:49] <bryceh> fonts are all stretched out
[01:50] <RAOF> Is gdm cloned, and on login unity starts before g-s-d sets up the spanned desktop?
[01:50]  * RAOF doesn't see that, possibly because g-s-d sets up the second head before unity has got far enough to care.
[01:50] <bryceh> gdm is not cloned
[01:51] <RAOF> Although it sounds exactly like what happens when I plug or unplug a second head.
[01:51] <bryceh> I set up side-by-side dual head and set as system default
[01:51] <bryceh> so login prompt appears only on the left screen
[01:51] <bryceh> but
[01:51] <bryceh> I have a bunch of apps that start up in my .xprofile
[01:51] <bryceh> and I've found they sometimes will initiate prior to the window manager being "done" loading
[01:52] <bryceh> so I get fun things like xchat not having the themed decorations, and gnome-terminal windows that shift around once the panels launch
[01:53] <bryceh> goodness unity is buggy
[01:54] <bryceh> if the launcher is over a gnome-terminal session, gnome-terminal appears to steal the mouse events
[01:54] <RAOF> I should possibly take up Jason's call and do the (apparently pretty easy) dynamic xrandr integration stuff.
[01:54] <RAOF> Hm, that doesn't happen here :)
[01:55] <bryceh> fwiw I'm also running apw's 2.6.38-4-generic pre-release kernel thingee, although that probably doesn't matter
[01:55] <bryceh> (however now plymouth works all of a sudden)
[01:56] <RAOF> Heh!
[01:56] <cnd> RAOF, bryceh: an update: I've got touch events integrated into the pointer event stream properly now
[01:56] <cnd> after redoing most of the stack
[01:56] <RAOF> cnd: Yay!
[01:56] <bryceh> ironically for ~1-2 min boot it displays the ubuntu logo for barely 1 sec
[01:56] <cnd> I'm now just fixing up touch event handlin
[01:56] <cnd> g
[01:57] <cnd> the code is a bit of a mess right now, so once I have it working I need to clean it up a little
[01:57] <RAOF> cnd: I think it's a fair call that Xserver 1.10 is not being released today; when do you want to incorporate Xi 2.1?L
[01:57] <cnd> but it will still be hairy when it's ready to go, probably early next week
[01:57] <bryceh> cnd, so I take it you wouldn't like to hear that the unity guys want us moved back to xserver 1.9 so -nvidia will work?
[01:57] <cnd> bryceh, (!)?
[01:57] <cnd> as in, roll back for natty?
[01:58] <cnd> or roll back just for right now?
[01:58] <cnd> I had heard the nvidia drivers still worked, but there was some politics with abi versioning and the distro
[01:58] <bryceh> cnd, just kidding (although they did ask...)
[01:58] <cnd> gah!
[01:58] <cnd> if you can't tell, I'm a bit on edge...

[01:59] <cnd> been working the last 11 days straight
[02:00] <cnd> and I've been bashing my head against the wall trying to figure out pointer grabs :)
[02:00] <cnd> took me three days to figure it out
[02:00] <cnd> there can't be many people in the world who understand it...
[02:00] <RAOF> The few, and the proud.
[02:00] <cnd> I'd venture a guess of only 3 now :)
[02:01] <cnd> I can't say I'm very proud
[02:01] <cnd> I'm very afraid
[02:01] <bryceh> that kinda describes a lot on the XInput side of things
[02:01] <cnd> afraid that any time there's a bug in xinput now, I'll have to handle it :)
[02:02] <bryceh> yay!
[02:02] <RAOF> I'm not sure that should be a fear so much as a certainty.
[02:02] <cnd> :(
[02:02] <cnd> ok, it's 9 PM here and I think things are headed in the right direction
[02:03] <cnd> so I'm going to call it quits for the evening
[02:03] <bryceh> night cnd
[02:03] <cnd> bryceh, RAOF: btw, when would you say is drop dead date for getting stuff into ubuntu before feature freeze?
[02:03] <cnd> I'm aiming to have things ready on monday, but just in case
[02:04] <RAOF> Absolutely drop-dead?  Probably wednesday evening, my time.
[02:04] <cnd> RAOF, ok, hopefully it doesn't come to that :)
[02:04] <cnd> btw, I'll be dropping X MT support for trackpads...
[02:05] <cnd> I just don't think the protocol makes sense for trackpads as it is
[02:05] <cnd> so it'll sadly just be touchscreens that get all the gooey xi 2.1 stuff
[02:05] <RAOF> If push comes to shove I can do another FF firedrill.
[02:05] <cnd> RAOF, I don't think anyone wants that again :)
[02:05] <bryceh> hmm, I probably should focus on wayland for a few days and get some stuff updated there before FF
[02:06] <RAOF> Yeah, probably a winner.
[02:06] <RAOF> Hm. I wonder if “doesn't absolutely suck when plugging in monitors” would be regarded as a Unity feature :)
[02:07] <bryceh> RAOF, the real question is do we have any recourse when it does?
[02:07] <bryceh> I mean, aside from classic ;-)
[02:07] <RAOF> Well, that would be a slam-dunk FFe I guess.
[02:12] <RAOF> Does this work now that I'm no longer strnduping a random memory address?  Lets ask Science!
[02:15]  * apw wonders if others have noticed as sudden change in brightness control, i think i am getting 3 brightness changes for each key press ... confirmed there is only on press in the input stream
[02:15] <bryceh> RAOF, I'm going to call this mesa good.  I've run several gl-ish things and am satisfied it's not going to bugger children.  Any last minute regrets?
[02:15] <apw> RAOF, does unity dump core for you if you plug a wide monitor into your intel kit?  if i end up with more than 2k width it just exits
[02:16] <RAOF> bryceh: I haven't thought of any regrets yet :)
[02:16] <bryceh> alrighty here we go
[02:17] <RAOF> apw: I “happily” get above 2k width (modulo the crazy positioning), but this is a GM45 which has a nice big texture limit.
[02:17] <RAOF> Canonical should sponsor me a couple of nice big monitors so I can test other, non-laptop things :)
[02:18] <apw> yeah i hear its a texture limit
[02:19] <RAOF> compiz probably shouldn't dump core, but it also probably won't work.
[02:19] <bryceh> it should refuse to start up in such a case
[02:19] <RAOF> Unless dx feels like making compiz use RandR 1.4 where available.
[02:20] <RAOF> At which point it actually *could* work, as long as no head is individually > any of the texture limits.
[02:20]  * RAOF suspects RandR 1.4 support is *way* down the TODO.
[02:20] <apw> so it sounds like there no plan to fix this?
[02:21] <apw> that common platforms will be working, plug in a projector and blam
[02:21] <RAOF> Does metacity kick in nicely?
[02:21] <apw> nope you end up dead in the water with no window manager, well last i checked
[02:21] <RAOF> If nothing else, that should be fixed.
[02:21] <bryceh> [ubuntu/natty] mesa 7.10.1~git20110215.cc1636b6-0ubuntu1 (Accepted)
[02:22]  * apw sighs, one more thisn to test
[02:22] <RAOF> Woot!  Now that I'm not trying to copy a random piece of memory as a file path this works :)
[02:22] <apw> bryceh, more fun coming down the pipe?
[02:24] <RAOF> Well, it will at least allow nvidia users to test unity :)
[02:25] <apw> ohh that reminds me, i am seeing corruption on scroll in gnome-terminal, sort of foreground stippling over the text
[02:25] <bryceh> alright that's enough unity for me
[02:25] <apw> have been for some time, known?
[02:25] <bryceh> apw, yep new mesa snapshot
[02:25] <apw> heh fun fun fun
[02:26] <bryceh> apw, funny you should ask, I just went through a bunch of terminal corruption bugs today
[02:26] <apw> hopefully that -4 kernel will be accepted tommrrow, seems i missed the AAs today
[02:26] <bryceh> crap, forgot to test that with unity
[02:26] <bryceh> apw, anyway so far there are 3 different terminal corruption bugs we know about (all different)
[02:26] <apw> i see it come and go on scroll up, and at times i have felt it was 'repeatable' such that a scroll down where available would reverse it
[02:27] <apw> heh, then till some of those are gone i'll assume its known :)
[02:27] <apw> is that a compiz issue or more mesa-ery
[02:28] <bryceh> my guess would be you're having this one - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/717114
[02:28] <ubot4> Launchpad bug 717114 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack with terminal programs (affects: 4) (dups: 1) (heat: 22)" [Medium,Incomplete]
[02:29] <bryceh> apw, at this point we don't know what's to blame.  I posted some questions to the bug to help narrow it down
[02:29] <bryceh> apw, any thoughts or insights you can share might help (e.g. maybe you can help rule out the kernel as a suspect)
[02:30] <apw> yeah see them
[02:30] <bryceh> offhand I'm going to guess we have some mesa issues, and I'm curious if raof's new mesa I just uploaded will help
[02:30] <apw> i'd say its improved, is less reproducible recently
[02:31] <apw> i've been ignoring it, i'll try and get a feel for how often i really see it
[02:31] <apw> and then try out the older kernel
[02:33] <apw> bryceh, i assume you know what it looks like.  i have it right now in a wndow where scrolling down one shows it, one more and its ok again and reversing through the same 3 lines seems the same
[02:34] <bryceh> apw, here's what I'm guessing - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/710961/+attachment/1831040/+files/Still-Present.png
[02:34] <ubot4> Launchpad bug 710961 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack (dup-of: 717114)" [Undecided,Incomplete]
[02:34] <ubot4> Launchpad bug 717114 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack with terminal programs (affects: 4) (dups: 1) (heat: 22)" [Medium,Incomplete]
[02:34] <apw> looking closly at it, the 'dammage' is actually a ghost of what was on that line before the scroll, about half the lines vertically have not been cleared
[02:36] <bryceh> apw, is this with compiz or without?  (Classic Desktop w/out effects?)
[02:36] <apw> its more pronnounced than that, but the same range, exactly two lines of fookage each time it occurs
[02:36] <apw> this is with unity, compiz
[02:37] <apw> the example there is also exactly two lines of text which are bust
[02:37] <RAOF> Hm.  That looks a bit like the damage bug that got fixed in -1ubuntu6.
[02:37] <bryceh> alright lemme restart into unity and try reproducing it myself
[02:38] <apw> RAOF, i updated earlier today, whats that version of so i can check
[02:38] <RAOF> xserver-xorg-video-intel; it's quite old, though, so you almost certainly already have it.
[02:39] <apw> 2:2.14.0-1ubuntu9
[02:39] <apw> bryceh, i find that its normally most obvious in a long less
[02:39] <apw> i also note its pretty much output specific
[02:40] <apw> ie if you see it on a couple of lines of a less output, it willl  be there again if you scroll
[02:40] <apw> a few pages away and back to the same point
[02:41] <RAOF> That's a bit strange.  I don't think there's anything Xy that should do that sort of caching except for the glyph cache.
[02:43] <RAOF> And that doesn't look like glyph cache corruption.
[02:45] <bryceh> hmm, not seeing anything weird with xterm+less+kern.log or gnome-terminal+less+kern.log
[02:46] <bryceh> well, with xterm I notice the border seems messed up
[02:46] <bryceh> ah not messed up, just transparent.  Weird.
[02:47] <bryceh> compiz shadow is really irritating
[02:47] <apw> RAOF, ok this corruption is definatly in the window, it can be covered and exposed and its still in there
[02:48] <bryceh> apw do you see it *only* with terminals or does it show up in any other client apps?
[02:48] <bryceh> e.g. scrolling slashdot.org in firefox
[02:48] <apw> i have never notices any corruption of anything else no
[02:49] <apw> not for launchpad pages for instance which i use almost as much
[02:49] <RAOF> Hm.  (a) why is the crda regulatory daemon setting my zone to FR, (b) my, aufs is generating a lot of dmesg backtraces.
[02:50] <bryceh> hmm, unity is significantly more tolerable with gnome-panel manually launched
[02:50] <RAOF> xterm doesn't seem to be having any troubles here.
[02:50] <bryceh> yeah no corruption for me either
[02:51] <bryceh> apw, what video driver, -intel?
[02:51] <apw> http://people.canonical.com/~apw/misc/corruption.png
[02:51] <apw> intel yes
[02:51] <apw> this is a N450 netbook
[02:51] <bryceh> oh you know what, I override the default terminal theme stuff
[02:51] <RAOF> That looks like it's reasonably easy to generate?
[02:52] <RAOF> N450 means... i945?
[02:53] <apw> note that the shadowing is clearly text which is not on the window, but has been visible recently
[02:53] <apw> 00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller
[02:54] <RAOF> The shadowing?  You mean, the interleaved text?  That looks like it's from quite nearby in the buffer.
[02:54] <RAOF> apw: grep "intel(0): Chipset:" /var/log/Xorg.0.log?
[02:54] <apw> yeah its from nearby but not the page above or below
[02:54] <apw> [    13.397] (--) intel(0): Chipset: "Pineview GM"
[02:55] <bryceh> yeah even with default theme, not reproducing on -ati / rv770
[02:55] <RAOF> Not reproducing on GM45
[02:55] <bryceh> although this is with the new mesa and your -rc4 kernel
[02:56] <RAOF> Ok. g33
[02:56] <RAOF> Ah, that's why unity hates big screens, too.
[02:57] <RAOF> (For you).
[02:57] <apw> yeah a very very common platform, we need to replace all those macs in design with soemthing normal people have
[02:57] <apw> so they get some pain from these kinds of bugs
[02:57] <bryceh> mm, this is new:
[02:57] <bryceh> [  685.163321] [drm:subconnector_show] *ERROR* Unable to find subconnector property
[02:57] <bryceh> [  685.163349] [drm:select_subconnector_show] *ERROR* Unable to find select subconnector property
[02:57] <bryceh> [  685.222891] [drm:subconnector_show] *ERROR* Unable to find subconnector property
[02:57] <bryceh> [  685.222917] [drm:select_subconnector_show] *ERROR* Unable to find select subconnector property
[02:58]  * RAOF wonders idly how hard it would be to port compiz to RandR1.4 to stop apw bitching :)
[02:59] <RAOF> Hm.  If I reboot my irc bouncer and flip the bios switch I can also have access to an i915-driven GPU.
[03:00] <apw> RAOF, my plan is to offer my laptop to our leader for a presentation and see how long it takes to get fixed after it explodes
[03:00] <RAOF> :)
[03:01] <apw> bryceh, well none of the code which produces that error is new ... so hrm
[03:01] <Sarvatt> apw: does it go away if you move the mouse to the top left of the screen? :)
[03:01] <apw> Sarvatt, which ?
[03:01] <ScottK> apw: Bigger question is would you still be around to find out?
[03:02] <Sarvatt> apw: the corruption, sorry
[03:02] <apw> ScottK, heh indeed
[03:03] <apw> Sarvatt, heh no, i get a nice unity launcher pop over it, but no change in the corruption
[03:03] <Sarvatt> also curious if it happens on .37
[03:03] <Sarvatt> ah alrighty, saw one case of a corruption problem with a fix just posted on the intel-gfx list but they said it went away when the mouse was in the top left
[03:04] <apw> now that is somewhat odd fix is it not?
[03:04] <apw> yeah .37 is my next test
[03:05] <Sarvatt> nah they fixed it properly, that was just a symptom the guy had
[03:05] <Sarvatt> http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/2949
[03:05] <Sarvatt> 2.6.38 is proving to be all kinds of "fun" on intel
[03:06] <bryceh> tell me about it
[03:07] <apw> ok back ... on .37 ... the triple brightness issue is still here so i can ignore that as a kernel issue
[03:11] <apw> its hard to prove a negative, but i've done more wibbling to reproduce it, i managed to reproduce it 3-4 times in the same period on .38, nothing so far on .37
[03:13] <bryceh> mm interesting
[03:13] <RAOF> Oh, hurrah.
[03:14] <bryceh> apw, btw while we have your attention... any updates on the -intel/vesafb conflicts (bug #702090)?  the bugs keep rolling in daily on that one
[03:14] <ubot4> Launchpad bug 702090 in xserver-xorg-video-intel (Ubuntu Natty) (and 4 other projects) "i965gm GPU lockup if vesafb is left loaded (EIR: 0x00000010 PGTBL_ER: 0x00000100) - *ERROR* EIR stuck: 0x00000010, masking (affects: 36) (dups: 25) (heat: 287)" [High,Triaged] https://launchpad.net/bugs/702090
[03:14] <apw> bryceh, not had a chance to fiddle with the ordering there
[03:14] <apw> mr watson and i were meant to get together to discuss it this week and its nto yet happened hrm
[03:16] <Sarvatt> apw: if 2.6.38-rc1 works too you might want to try https://patchwork.kernel.org/patch/571511/ and https://patchwork.kernel.org/patch/572241/
[03:17] <apw> how the heck does it work without those !
[03:19] <Sarvatt> <3 2.6.38 so far
[03:20] <Sarvatt> broadcom fail in it invalidated 3 days of hibernate testing here, i'm grumpy :)
[03:21] <apw> broadcom is always fail
[03:23] <Sarvatt> apw: those commits are in drm-intel-next too, not sure when you guys build those? could just check in the morning
[03:26] <apw> we rebuild at 10am utc i think it is
[03:28] <apw> ahh awsome that 'skip FDI & PCH enabling for DP_A' fix looks to be on the intel fixes branch, so i assume destined for .38
[03:29] <bryceh> ok EOD'ing
[03:29] <bryceh> apw, btw looks like your kernel solved my nfsv4 woes, thanks
[03:29] <apw> yay for new kernels
[03:31] <RAOF> Yay!  I can now actually interact with the grub menu on my radeon system now!
[03:33] <RAOF> Oh, bother.  My evergreen card doesn't have *any* acceleration without KMS, so I can't test the ums fallback.
[03:41] <RAOF> Whoops.  Moderately easy to crash firefox with WebGL
[04:02] <RAOF> How big a NOT E6510 do you need to have in the bug title before users with E6510 hardware stop posting on it? :)
[05:37] <bryceh> strange, my gnome-terminal sessions all froze up and my music started repeating the same broken lyrics over and over in a loop
[05:37] <bryceh> oh wait, I'm listening to techno, it's supposed to sound like that
[06:57] <bryceh> RAOF, I tried on my i945 dell mini...
[06:57] <bryceh> RAOF, gnome-terminal doesn't show the corruption
[06:58] <bryceh> RAOF, weirdly, I launched xterm and got a >frozen< xterm window.  No cursor, completely unresponsive.
[07:04] <hyperair> hi. does anyone know about ubuntu's x with intel chipsets not sending out XRRNotifyEvents to clients?
[07:04] <hyperair> it seems to work with xorg-edgers, but not with the stock X in maverick
[07:06] <RAOF> bryceh: I'll have the switch-to-gallium stuff ready an hour or so after making, then eating dinner.
[07:10] <bryceh> hyperair, first I've heard of it, but I don't really deal with maverick bugs
[07:11] <bryceh> RAOF, sounds good; ping me when it's ready
[07:11] <hyperair> bryceh: hmm strange. basically i plug in a monitor into the VGA port, and only after manually polling the hardwrae with XRRGetScreenResources does the event come in
[07:11] <hyperair> bryceh: but that X call causes X11 to hang momentarily
[07:12] <lilstevie> I have X dying and respawning, is there a way of getting more detailed logs from what is killing it as Xorg.0.log has nothing about errors
[07:13] <bryceh> lilstevie, I'd look in /var/log/gdm for errors
[07:13] <bryceh> also Xorg.0.log.old
[07:13] <lilstevie> unfortunantly doesnt give me any errors
[07:14] <bryceh> lilstevie, ok then start X up in gdb run it to a crash and then gather a full backtrace
[07:14] <lilstevie> k
[07:15] <bryceh> actually probably easier to start X and then attach gdb to it (pidof X to get X's pid, then run gdb /usr/bin/Xorg, and then attach <pid>)
[07:15] <bryceh> see http://wiki.ubuntu.com/X/Backtracing for more tips
[07:15] <lilstevie> X on its own doesnt crash
[07:15] <lilstevie> just doesnt work
[07:16] <bryceh> hyperair, well the automatic XRR kernel events stuff is fairly new, it may just be a missing feature from maverick
[07:16] <hyperair> bryceh: ah, so it's a kernel events thing? is this a new feature in the kernel, or in X, or somewhere else?
[07:16] <bryceh> lilstevie, I don't know what you mean by "doesn't work"
[07:16] <bryceh> hyperair, yeah
[07:16] <bryceh> hyperair, new kernel drm feature
[07:16] <lilstevie> bryceh: the screen backlight flashes on then off again
[07:16] <hyperair> okay, that narrows down my search a bit, thanks =)
[07:17] <lilstevie> http://pastie.org/1577791 <- this is Xorg.0.log.old
[07:17] <bryceh> hyperair, I'm not sure if the kernel bubbles the event up to X and then that passes it to clients, or if clients listen directly for kernel events
[07:18] <hyperair> bryceh: no, the clients get it via some XRR stuff
[07:18] <bryceh> hyperair, if X passes things along it's conceivable the X we shipped in maverick simply lacked the feature, but I wasn't paying attention to X during maverick so raof would be the one to ask
[07:18] <hyperair> okay thanks.
[07:18] <hyperair> RAOF: ^^ =D
[07:19] <RAOF> hyperair: It requires kernel events (which *were* in Maverick) to be picked up by the DDX and forwarded to X; I'm not sure if the latter was in Maverick.
[07:20] <bryceh> lilstevie, oh you're not running natty?
[07:20] <lilstevie> bryceh: no maverik
[07:20] <lilstevie> maverick
[07:21] <bryceh> lilstevie, dunno then, you might have something misconfigured, hard to say
[07:21] <lilstevie> trying to port to a new device
[07:21] <lilstevie> but struggling to figure out what is broken
[07:21] <bryceh> you're right though that it's not crashing, just exiting.  the log seems to be complaining about input device stuff
[07:22] <lilstevie> hm
[07:22] <bryceh> hard to make any guesses without more info, you could try http://askubuntu.com
[07:22] <hyperair> RAOF: oh so kernel events were in maverick, i.e. kernel <= 2.6.35?
[07:22] <hyperair> RAOF: what's DDX?
[07:22] <lilstevie> the nexus S has the same SoIC and that seems to work with x
[07:22] <bryceh> DDX is the X driver
[07:23] <bryceh> so that would be like xserver-xorg-video-intel as opposed to the intel driver inside the kernel
[07:23] <bryceh> hyperair, https://wiki.ubuntu.com/X/Glossary
[07:24] <hyperair> bryceh: thanks
[07:24] <hyperair> RAOF: i'm trying to look in the kernel git log for the introduction of this whole hotplug kernel events thing so i can figure out how new a kernel i need.
[07:34] <bryceh> wow http://www.semiaccurate.com/2011/02/15/atom-dead-strangled-slowly-intel/
[07:34] <bryceh> harsh!
[07:34] <bryceh> "The other major problem facing Atom is software, especially drivers. Intel has a track record in making graphics drivers that are simply unmatched in the world of chipmaking. I can honestly say that I can not think of a single company that has made drivers as badly as Intel for as long, even if you take the awful hardware into account. Even a blind dog occasionally finds a bone, unless they work for Intel making graphics driv
[07:34] <bryceh> ers."
[07:34] <lilstevie> lol
[07:34] <lilstevie> but true
[07:35] <RAOF> hyperair: Hm.  I may have had it backwards; the DDX component may have been there but the kernel component not :)
[07:36] <hyperair> RAOF: nah, i just tried upgrading to xorg-edgers on this computer and it suddenly started workgin
[07:36] <bryceh> Sarvatt, ^^ you'll find that link an interesting read I think
[12:14] <RAOF> Dear lord, mesa.  Do you *really* need to take that long to build?
[12:15] <jcristau> maybe we should get rid of some (all?) of the osmesa packages
[12:17] <RAOF> Or at least build only one.
[12:18] <RAOF> I'm sure the user of the 16bit renderer will be *devastated*
[12:19] <RAOF> Of course, it doesn't help that I'm doing an i386 and amd64 build in parallel.
[12:19] <tjaalton> heh
[12:19] <tjaalton> what are those osmesa-stuff for, anyway?
[12:23] <RAOF> It's an offscreen software rasteriser, from what I gather.
[12:24] <RAOF> As for what anyone *uses* that for… well, mesa-dev@ attests to there being at least one dev who notices when it breaks.
[12:25] <tjaalton> heh, ok
[12:30] <RAOF> bryceh, tjaalton: Radeon gallium transition stuff is in http://cooperteam.net/Packages ; build order is mesa -> xserver with -ati going whenever.
[12:32] <RAOF> Note: Due to mesa taking forever to build I haven't actually tested building the xserver against that mesa in a clean chroot.
[12:32] <tjaalton> RAOF: ok, so mesa is good to upload?
[12:33] <tjaalton> and xserver too, since the build-dep is bumped
[12:33] <RAOF> It should be good to upload.
[12:34] <tjaalton> yeah they all are
[12:34] <RAOF> But it's not thoroughly tested here.
[12:34] <tjaalton> bah, it's the weekend anyway :)
[12:34] <tjaalton> soon
[12:34] <RAOF> In some places sooner than others :)
[12:34] <tjaalton> right, so Sarvatt and bryceh can fix the pieces that are left behind :)
[12:35] <RAOF> I'll throw the binaries up on cooperteam, too; save you some bulid time.
[12:36] <tjaalton> ok, thanks
[12:36] <tjaalton> I'm trying to make some sense to this "xinput1 broken" -bug..
[12:36] <tjaalton> but, after the break->
[12:38] <RAOF> Now with bonus binaries.
[12:38] <RAOF> And with that, bed.
[12:51] <tjaalton> ok, lets try mesa then (don't have radeon)
[12:55] <tjaalton> wat, there's no menu in mumble anymore?
[12:56] <tjaalton> +h
[12:56] <tjaalton> duh
[14:18] <seb128> bryceh, there?
[16:34] <seb128> bryceh, let me know if you are around, I want to discuss about the retracers
[16:34] <seb128> I stopped those to investigate that xorg retracing issue but I would need an xorg crash to be submitted to be able to do that
[17:51] <cnd> bryceh, I did a ppa-purge of xorg-edgers (which I should have done a while ago...)
[17:51] <cnd> but now my keyboard doesn't work anymore..
[17:51] <cnd> any ideas?
[17:52] <tjaalton> do you have evdev installed?
[17:52] <cnd> I've debugged in the server, and I know that key events are getting generated
[17:52] <tjaalton> ok
[17:52] <cnd> tjaalton, yes, still installed
[17:52] <cnd> but they seem to get filtered out?
[17:52] <cnd> in _XkbFilterXF86Private
[17:52] <cnd> I don't know anything about how keyboard events work...
[17:53] <cnd> I'm just wondering if there's some magical change to stuff in xorg-edgers
[17:53] <jcristau> nobody does, it's all black magic
[17:53] <tjaalton> xorg-edgers doesn't have much, maybe the ppa-purge removed something vital
[17:53] <tjaalton> well, there's stuff but still
[17:54] <tjaalton> but filtering sounds odd
[17:57] <tjaalton> though it sounds what's happening with mumble (XI1 app)
[17:57] <tjaalton> +like
[17:57] <cnd> yeah, but this isn't even generating core events...
[17:57] <tjaalton> hm
[17:57] <cnd> I'm going to try to purge my xorg-unstable ppa
[17:57] <cnd> then reinstall it
[18:07] <cnd> hmm, still no luck
[18:07] <cnd> I'm going to apt-get dist-upgrade and reboot
[18:07] <tjaalton> oh you aren't on current natty?
[18:07] <cnd> I am
[18:07] <tjaalton> k
[18:07] <cnd> but I haven't updated in a few days
[18:07] <tjaalton> yeah that shouldn't make a difference..
[18:07] <cnd> I know
[18:08] <cnd> but I figure if I'm screwing up the machine
[18:08] <cnd> I might as well go all the way :)
[18:08] <tjaalton> right :)
[18:19] <cnd> grr... still nothing
[18:28] <tjaalton> cnd: you've seen the mumble bug? shouldn't XI1 apps continue working just as before with XI2, or do they need to be ported over?
[18:29] <cnd> tjaalton, I have seen it, haven't had time to investigate
[18:29] <cnd> they should continue to work as normal
[18:29] <cnd> so it's a bug
[18:29] <tjaalton> yeah
[18:30] <tjaalton> best to file it upstream then and discuss it there
[18:34] <cnd> tjaalton: I wonder if it has to do with input methods
[18:34] <cnd> do you know anything about them?
[18:35] <tjaalton> XIM? not really
[18:36] <tjaalton> GlobalShortcutX: Using XInput 2.0
[18:36] <tjaalton> yet the app is for XI1
[18:38] <tjaalton> ah that's not from the app
[18:55] <cnd> btw, I don't think it's XIM
[18:56] <cnd> this all seemed to start when I downgraded from libx11-1.3.4 in xorg-edgers to 1.3.3 in natty
[18:56] <cnd> and there's some xkb stuff in libx11
[18:56] <cnd> so I'm going to try to upgrade back to it
[18:56] <cnd> hmmm... there's no libx11 there anymore...
[18:57] <cnd> I may be screwed :)
[18:58] <tjaalton> you have some self-compiled stuff for multitouch?
[18:59] <tjaalton> eh, so we have an ancient libX11
[19:00] <tjaalton> wonder if 1.4.1 could fix mumble
[19:00] <cnd> I do have stuff for multitouch
[19:00] <jcristau> *cough* klongon crap *cough*
[19:00] <jcristau> klingon, even
[19:00] <cnd> I'm all confused...
[19:00] <tjaalton> jcristau: haha
[19:01] <cnd> I just want my keyboard to work!
[19:01] <tjaalton> cnd: dunno if there's some ABI break doing what you see
[19:01] <cnd> tjaalton, it doesn't work on stock natty packages
[19:01] <cnd> I've ppa-purged everything
[19:01] <cnd> I think some xkb file has been screwed up
[19:02] <cnd> some setting somewhere
[19:02] <tjaalton> what packages does it touch?
[19:02] <cnd> trust me, I've downgraded them all again :)
[19:02] <tjaalton> crap, forgot about RAOF's mesa/xserver/ati
[19:02] <tjaalton> cnd: I know, but if your multitouch'y packages need something to be rebuilt
[19:02] <jcristau> tjaalton: friday, 8pm, what could possibly go wrong.
[19:03] <jcristau> or is it 9 over there
[19:03] <tjaalton> jcristau: right. I'll get another beer
[19:03] <jcristau> :)
[19:03] <tjaalton> (not working anymore btw)
[19:03] <jcristau> cheers
[19:04] <tjaalton> bryceh: do you want to take over mesa/xserver/ati from RAOF? I can test them, but if something breaks after uploading them I'd be either in bed or..
[19:05] <tjaalton> yeah 21:04 here
[19:05] <tjaalton> oops :05
[19:05] <bryceh> tjaalton, sure
[19:06] <tjaalton> bryceh: got the link?
[19:06] <tjaalton> bryceh: http://cooperteam.net/Packages
[19:07] <bryceh> oh cool, debs too
[19:07] <tjaalton> yeah
[19:11] <cnd> tjaalton: GAH! it was libx11-1.3.4
[19:11] <tjaalton> cnd: :)
[19:11] <cnd> so, downgrading from libx11-1.3.4 breaks your keyboard!
[19:12] <tjaalton> good, I'll merge 1.4.1 to see if it helps with mumble
[19:12] <cnd> I'd like 2 hours of my life back now :)
[19:12] <tjaalton> hehe
[19:12] <tjaalton> hmm, libxi 1.4.1 available
[19:12] <tjaalton> we have 1.4.0
[19:13] <tjaalton> nothing too special there
[19:14] <bryceh> cnd, that's weird
[19:15] <tjaalton> but I'll sync the packages that don't have any diff
[19:15] <tjaalton> couple of libs
[19:15] <bryceh> abi change between previous and libx11-1.3.4?
[19:15] <bryceh> tjaalton, yeah probably a bunch that could be sync'd http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/versions-current.html
[19:16] <tjaalton> yeah looking at that now (been a looong time..)
[19:16] <bryceh> there's also drivers that I think the only changes are the rebuilds after the last abi bumpery
[19:17] <tjaalton> ooh and new xbacklight and xbitmaps
[19:17] <jcristau> tjaalton: exciting, right? :)
[19:18] <tjaalton> super-
[19:19] <cnd> bryceh, it can't really be abi
[19:19] <cnd> because I had downgraded everything
[19:19] <cnd> drivers and server
[19:20] <cnd> but I don't have any alternative explanation either...
[19:20] <bryceh> could something have statically linked against it?
[19:20] <tjaalton> you've built something against libx11 1.3.4
[19:20] <cnd> tjaalton, no, I was running stock ubuntu packages
[19:21] <cnd> I had gotten rid of all my stuff
[19:22] <tjaalton> ok
[19:22] <Sarvatt> cnd: libx11 1.3.4 isn't even in xorg-edgers natty?
[19:22] <cnd> Sarvatt, it must have been at one point
[19:22] <tjaalton> confirmed that focus-follows-mouse doesn't dig on unity..
[19:22] <cnd> and it's still there in the maverick and lucid series I believe
[19:22] <Sarvatt> nope can guarantee it hasn't been
[19:23] <tjaalton> or the menubar
[19:23] <Sarvatt> sounds like ya didnt purge edgers before going maverick -> natty?
[19:23] <cnd> Sarvatt, perhaps?
[19:23] <Sarvatt> gotta be it
[19:24] <Sarvatt> to fix that i add xorg-edgers maverick to sources, apt-get update then purge the ppa before upgrading so it knows all the crap in the old release to remove, kind of a pain in the butt :(
[19:25] <cnd> yeah
[19:27] <Sarvatt> thats.. odd
[19:28] <Sarvatt> the libx11 checkout in there was back from when 1.3.x was master
[19:28] <Sarvatt> and it has the XKeysymDB removal in it even though its 1.3.4
[19:28] <Sarvatt> but they didn't remove xkeysymdb until 1.3.6 on the 1.3 branch
[19:35] <bryceh> ok reboot onto new -ati first
[19:35] <tjaalton> damh
[19:35] <tjaalton> damN
[19:36] <tjaalton> forgot to tell bryce about the build order
[19:36] <bryceh> so far so good
[19:37] <tjaalton> quick reboot?
[19:37] <Sarvatt> sandybridge system? :)
[19:37] <tjaalton> bryceh: RAOF said something about the build order, but you're installing the binaries so it doesn't matter really
[19:38] <tjaalton> the xserver does depend on the new mesa though
[19:38] <bryceh> -ati I rebuilt while other stuff was downloading; assumed that bit was safe to do independently, but maybe not?
[19:39] <tjaalton> yeah it should be independent
[19:39] <bryceh> ok the other stuff I'll just load the .debs then
[19:39] <bryceh> think there's an upload dependency?  Do I need to put mesa in and wait for it before sticking xserver in, or vice versa?
[19:40] <tjaalton> no the xserver build-deps on the new mesa, so it'll wait until mesa is ready
[19:40] <bryceh> hrm, wish you could just dpkg -i *.deb with mesa
[19:40] <tjaalton> hehe
[19:40] <tjaalton> there are only a few you need
[19:40] <bryceh> yeah
[19:41] <bryceh> dpkg -i libgl1-mesa-dri_7.10.1~git20110215.cc1636b6-0ubuntu2_i386.deb libgl1-mesa-glx_7.10.1~git20110215.cc1636b6-0ubuntu2_i386.deb libgles2-mesa_7.10.1~git20110215.cc1636b6-0ubuntu2_i386.deb
[19:42] <bryceh> did I miss anything?  that should be enough
[19:42] <bryceh> actually it looks like I could do everything except libgl1-mesa-swx11  - isn't that the only package that'd screw me up?
[19:42] <tjaalton> that can be installed as well
[19:43] <jcristau> that conflicts with -glx iirc
[19:43] <bryceh> libgl1-mesa-dri-experimental might be "fun" but it shouldn't cause conflicts for installation
[19:43] <jcristau> both provide libGL.so.1
[19:43] <tjaalton> oh
[19:43] <tjaalton> right I was looking at apt-cache search output, duh
[19:43] <bryceh> heck, I'm gonna give a try to install everything but that
[19:44] <bryceh> unhappy
[19:44] <bryceh> oh duh, gotta exclude amd64 pkgs
[19:44] <tjaalton> heh
[19:45] <bryceh> there we go
[19:45] <bryceh> yeah, just rm *swx11*deb ; dpkg -i *.deb
[19:46] <bryceh> reboot time
[19:47] <bryceh> metacity fine
[19:48] <bryceh> unity still crazy, but no crazier
[19:49] <bryceh> aaaa too crazy for me tho, brb
[19:52] <bryceh> aha, most of this craziness is compiz
[19:55] <tjaalton> hum, I wonder where the syncs went
[19:55] <tjaalton> oh, nowhere
[19:57] <Sarvatt> sync freeze was in december, i've done like 40 since then
[19:58] <tjaalton> i thought syncpackage would've uploaded them too, but it just signed them
[19:58] <tjaalton> probably because i didn't specify the release
[19:58] <Sarvatt> oh they might have removed that ability, i think archive admins want to do the syncs?
[19:59] <tjaalton> they can't prevent me from uploading packages signed by me :)
[19:59] <tjaalton> hm
[19:59] <tjaalton> of course they can
[19:59] <tjaalton> by revoking my upload rights :)
[19:59] <Sarvatt> not sure, the guy who used to upload them when I file just acks my sync requests instead of uploading them now so figured there was a policy change along the way
[20:00] <tjaalton> it could recognize packages without ubuntuN in the version
[20:04] <bryceh> ok, -ati, xserver, mesa all tested and uploaded
[20:06] <bryceh> [   175.611] (II) RADEON(0): [DRI2]   DRI driver: r600
[20:06] <bryceh> [   175.618] (II) AIGLX: Loaded and initialized /usr/lib/dri/r600_dri.so
[20:06] <bryceh> hm, shouldn't that be r600g?
[20:06] <bryceh> nope
[20:06] <bryceh> wonder how I tell whether I'm running g?
[20:06] <tjaalton> glxinfo should tell
[20:07] <bryceh> OpenGL renderer string: Gallium 0.4 on AMD RV770
[20:07] <bryceh> bingo, thanks
[20:07] <Sarvatt> r600g default now?
[20:07] <bryceh> hum, I just pulled glxinfo out of the apport hook yesterday... but it occurs to me that maybe useful info for debuggery
[20:08] <bryceh> Sarvatt, yep once the buildds are done
[20:08] <bryceh>  389 N + Feb 18 Ubuntu Installe ( 105) [ubuntu/natty] xserver-xorg-video-ati 1:6.14.0-0ubuntu1 (Accepted)
[20:08] <bryceh>  390 N + Feb 18 Ubuntu Installe ( 148) [ubuntu/natty] mesa 7.10.1~git20110215.cc1636b6-0ubuntu2 (Accepted)
[20:08] <bryceh>  391 N + Feb 18 Ubuntu Installe ( 119) [ubuntu/natty] xorg-server 2:<IP_ADDRESS>1+git20110131.be3be758-0ubuntu6 (Accepted)
[20:09] <tjaalton> mesa-utils isn't installed by default though
[20:09] <tjaalton> and in universe
[20:09] <tjaalton> because of that
[20:10] <bryceh> tjaalton, yeah that's why I took it out of the apport hook
[20:10] <bryceh> was causing the hook to error when glxinfo wasn't installed
[20:10] <Sarvatt> mesa-utils-extra? what the heck
[20:10] <Sarvatt> someone add more stuff to it and forget it's in debian now? :D
[20:11] <tjaalton> Sarvatt: syncs uploaded and accepted
[20:11] <Sarvatt> tjaalton: \o/ what'd ya get? libxcb?
[20:11] <tjaalton> that too
[20:12] <tjaalton> libxi, libxaw, libxext, libxcb, libxfont, xbacklight, xbitmaps
[20:12] <tjaalton> merged libx11, building it now
[20:12] <tjaalton> but won't upload it until monday
[20:13] <Sarvatt> tjaalton: I missed you man :)
[20:13] <tjaalton> hehe
[20:13] <tjaalton> I've missed these tools
[20:14] <Sarvatt> i had a bug for libxext but it was rejected, forgot to look into it
[20:14] <Sarvatt> think it was header removal, lets see
[20:15] <tjaalton> there was some changes yes.. could that break something?
[20:15] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/libxext/+bug/705010
[20:15] <ubot4> Launchpad bug 705010 in libxext (Ubuntu) "Sync libxext 2:1.2.0-1 (main) from Debian experimental (main) (affects: 1) (heat: 118)" [Wishlist,Incomplete]
[20:15] <Sarvatt> nothing we care about or ship
[20:15] <tjaalton> hah, sorry daniel..
[20:16] <tjaalton> "overruled"
[20:16] <Sarvatt> lbxproxy
[20:16] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/x11-xserver-utils/+bug/102018
[20:17] <tjaalton> yeah moved to liblbxutil
[20:17] <ubot4> Launchpad bug 102018 in x11-xserver-utils (Ubuntu) "[needs-packaging] lbxproxy (affects: 3) (heat: 17)" [Wishlist,Triaged]
[20:31] <tjaalton> bryceh: I've installed mesa here and will reboot in a minute
[20:31] <tjaalton> the new one
[20:31] <bryceh> ok
[20:43] <tjaalton> works
[20:47] <tjaalton> libx11 update didn't fix mumble
[21:11] <Amaranth> anyone seeing excessive wakeups on intel when running compiz?
[21:12] <Amaranth> it used to be 60 wakeups a second if you enabled vsync in compiz but now it's about that either way
[21:13] <Sarvatt> Amaranth: got second hands visible on your clock?
[21:13] <Sarvatt> was reading something about having the clock show seconds kept interrupts enabled all the time with compiz
[21:13] <Amaranth> Sarvatt: I don't even have a panel right now :)
[21:16] <Amaranth> I've got xchat-gnome and gnome-terminal as far as things drawing to the screen
[21:20] <bryceh> heya seb128
[21:20] <bryceh> seb128, you had questions about the retracer?
[21:20] <seb128> hey bryceh
[21:20] <seb128> bryceh, not really questions
[21:21] <seb128> rather I need some xorg crash reported and not retraced to run a retracing and see what is the issue
[21:21] <bryceh> seb128, ok, I'll keep an eye out for one
[21:21] <seb128> but it's getting late for this week now so let's see next week rather
[21:21] <bryceh> seb128, sounds good
[21:21] <Amaranth> Sarvatt: actually vsync on or off in compiz I get 57.2 wakeups
[21:21] <seb128> bryceh, thanks
[21:22] <Sarvatt> Amaranth: terminal cursor blink?
[21:22] <Amaranth> Sarvatt: It's blinking, yeah
[21:22] <bryceh> Sarvatt, ooh that'd be evil
[21:23] <Sarvatt> that did it years ago so i've always disabled it (they mention turning it off on their lesswatts page) :D
[21:23] <Amaranth> I just noticed it's on, could have sworn it was disabled by default
[21:24] <Sarvatt> Amaranth: i'm not sure though, let me see if i can dig up the discussion on the intel-gfx list because I think it had some debugging tips for it
[21:27] <Amaranth> Sarvatt: nope, wasn't the cursor blink :/
[21:28] <Amaranth> wow, actually it does it when running metacity too
[21:59] <bryceh> Sarvatt, hey I was just looking at bug #626967
[21:59] <ubot4> Launchpad bug 626967 in xserver-xorg-video-intel (Ubuntu Natty) (and 2 other projects) "MASTER: Hang in MI_WAIT_FOR_EVENT on framebuffer switch. (affects: 30) (dups: 42) (heat: 184)" [Medium,Fix released] https://launchpad.net/bugs/626967
[21:59] <bryceh> Sarvatt, looks like that is believed fixed for natty, but looks like the patch wasn't sru'd to maverick.  Do you think it'd make sense to do so?
[22:00] <bryceh> or is it too ambiguous what the fix was?
[22:07] <bryceh> bbiab


[00:41] <cmaloney> evening
[00:59] <brousch> cmaloney: Here you go, Mr. Emulator Guy http://9to5google.com/2015/05/08/macintosh-ii-system-6-android-wear/
[02:17] <cmaloney> Howdy
[02:30] <jrwren> hrm...
[02:31] <jrwren> don't know how to reply without invoking heehaw
[02:40] <cmaloney> heh


[09:40] <alkisg> Hi, I'm getting screen corruption with https://launchpad.net/ubuntu/+source/linux-raspi2, can I do something about it, e.g. change some configuration value?
[10:31] <ppisati> alkisg: kernel version? and how do you get that?
[10:31] <ppisati> alkisg: plain framebuffer? or X?
[10:31] <ppisati> alkisg: beucase i just connected my raspi2 to my lcd
[10:31] <alkisg> ppisati:  4.2.0-1014.21
[10:31] <ppisati> alkisg: and with the 13.19 kernel, i don't see any corruption
[10:31] <alkisg> I tried with fbdev and fbturbo
[10:31] <ppisati> alkisg: oh ok, let me try that
[10:31] <alkisg> Thanks!
[10:31] <ppisati> alkisg: ok, first le me test the new kernel
[10:32] <ppisati> alkisg: then i'll ask you about the rest
[10:32] <alkisg> Cool, thank you
[11:03] <ppisati> alkisg: are you using snappy? or another image?
[11:03] <ppisati> alkisg: cat /proc/cmdline
[11:03] <alkisg> ppisati: I'm using debootstrap in 14.04
[11:03] <alkisg> I manually installed the raspi2 kernel (actually I copied it to my ppa/trusty)
[11:04] <alkisg> $ cat /proc/cmdline
[11:04] <alkisg> dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=1080 bcm2709.boardrev=0xa01041 bcm2709.serial=0x32c4a54a smsc95xx.macaddr=B8:27:EB:C4:A5:4A bcm2708_fb.fbswap=1 bcm2709.disk_led_gpio=47
[11:04] <alkisg> bcm2709.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 init=/sbin/init-ltsp nbdroot=<IP_ADDRESS>:/opt/ltsp/armhf root=/dev/nbd0 elevator=deadline rootwait
[11:05] <alkisg> ppisati: did you try with the 4.2.0-1014.21      version, and it worked without corruption?
[11:06] <alkisg> By using the rpi2 kernel of fo0bar's ppa, I don't get screen corruption
[11:06] <ppisati> alkisg: yes, the framebuffer looks good here
[11:06] <alkisg> Do you think the version of the firmware would play a role?
[11:06] <alkisg> Which one are you using, the latest one from git?
[11:07] <ppisati> alkisg: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+packages
[11:07] <ppisati> alkisg: raspberrypi2-firmware - 4.1.10-ba7a8fb-1
[11:08] <alkisg> Ah cool, I'll try with those
[11:09] <alkisg> ppisati: I need to leave for now, but I'll work on it tomorrow + for some more days, and I'll ping you with the results. Do you have some blog etc somewhere with instructions about your ppa?
[11:09] <alkisg> (meaning, which of those packages I should install, and which ones aren't necessary....)
[11:09] <ppisati> alkisg: i have a script that creates ubuntu armhf images
[11:09] <ppisati> alkisg: or i can point you
[11:09] <ppisati> alkisg: to a premade image
[11:09] <alkisg> I'm trying to support rpi2 in LTSP (Linux Terminal Server Project)
[11:10] <alkisg> Sure, please point me to whatever script/info you have...
[11:10] <alkisg> Thanks!
[11:10] <ppisati> alkisg: prebuilt images - http://people.canonical.com/~ppisati/ubuntu_embedded/
[11:10] <ppisati> alkisg: for the script...
[11:10] <ppisati> alkisg: https://github.com/piso77/ubuntu-embedded
[11:10] <ppisati> alkisg: sudo ./make_img.sh -b raspi2 -d 15.10
[11:11] <alkisg> Thank you! :)
[11:15] <ogra_> ppisati, do you plan to push the firmware package to the archive ?
[11:15] <ppisati> ogra_: no plan ATM
[11:15] <ogra_> k
[11:15] <ppisati> ogra_: do you ned it?
[11:15] <ppisati> *need
[11:15] <ogra_> not urgently, no
[11:17] <ogra_> hmm, i just noticed their VideoCore "hardfp" build is armv6 only ...
[11:18] <ogra_> i wonder if that would actually work with our kernel (if the version matched)
[11:18] <alkisg> ppisati: what would be the proper path for ltsp users now? Currently to use your ppa, and in the future, e.g. in 16.04, those packages with the same names will be in the ubuntu archives?
[11:20] <ppisati> alkisg: except for the linux-firmware package, all the other packages are in the archive now
[11:20] <alkisg> The infrastructure in LTSP is already there, we just need the PPA, kernel variant, and extra package names for the rpi2. If we put those in ltsp-build-client.conf, the rpi2 will be supported by LTSP.
[11:21] <alkisg> ppisati: is the fbturbo driver needed?
[11:22] <ppisati> alkisg: never used, so i can't tell you
[11:22]  * alkisg tries to check if anything from https://launchpad.net/~fo0bar/+archive/ubuntu/rpi2/+packages is needed...
[11:22] <alkisg> I did some x11perf benchmarks with/without fbturbo, the difference was from small to non-existing...
[11:23] <alkisg> OK thanks a lot, I'll try with your firmware version to see if I still get corruption or not.
[11:23]  * alkisg waves
[11:23] <ppisati> alkisg: i'm going out for lunch soon, i'll do some X tests in the afternoon
[17:09] <caribou> ogasawara: apw: have you planned to take a cab upon your arrival in Austin ? I'll be there a bit before you
[17:09] <bjf> caribou, there's several of us arriving about that time
[17:09] <apw> caribou, i am planning on meeting up with whoever is still there
[17:09] <caribou> bjf: yeah, I was looking for your nic
[17:09] <ogasawara> caribou: yep, shall we try and find you?
[17:09] <caribou> ok, I'll wait for you then
[17:10] <apw> caribou, are you landing in the US for the first time in austin
[17:10] <caribou> ogasawara: apw bjf looks like there is 4 of 5 of us arriving arount 16:30
[17:10] <caribou> apw: nope, was there for the last sprint
[17:10] <bjf> caribou, i think there's enough that it should be easy to find someone to share a cab with
[17:11] <caribou> bjf: ok, I'll hang around until I see some of you
[17:11] <caribou> apw: I can hardly remember : the cab area is upstair or downstair ?
[17:11] <apw> caribou, sorry no i mean are you passing through imigration in austin
[17:12] <apw> caribou, i am so i will be no doubt slower than average
[17:12] <caribou> apw: no, in ATL
[17:12] <apw> ok
[17:12] <caribou> ok, I'll look around for any of you. Have a safe trim
[17:12] <caribou> s/trim/stip
[17:15] <arges> caribou: cabs are downstairs
[17:15] <bjf> cabs are at the end of the "cabs" signs
[17:15] <arges> : )
[17:15] <apw> heheh
[17:16] <caribou> arges: k. I remember meeting people there last time
[19:34] <noethics> hey, i'm wondering if there is some inotify-esque interface that instead of pooling resources can just match for any fs event with a certain dir prefix. or possibly every fs event and then i can filter myself


[11:52] <zer> Is there something like amarok (with lyrics and all these cool features) in GTK / Gnome?!
[11:52] <Seveas> benkong2, man update-rc.d
[11:52] <nalioth> benkong2: seveas is a bot
[11:52] <nalioth> lol
[11:52] <tiglionabbit> zer: dunno, but you can still get AmaroK
[11:52] <din> HaroldJohnson, we are telling you the commands to type...
[11:53] <benkong2> nalioth, a bot?
[11:53] <din> duh
[11:53] <martigan> anyone knows to enable intel mobile 4 scaling under hoary?
[11:53] <HaroldJohnson> din, I don't even know where to begin...
[11:53] <mumbles> bugger
[11:53] <nalioth> benkong2: ask him anything
[11:53] <zer> tiglionabbit: sure...but it doesn't work here..I can only choose aRts as Engine and i get not sound with it
[11:53] <Troy_McClure> http://paste.ubuntulinux.nl/540
[11:53] <Troy_McClure> there is my fstab
[11:53] <mumbles> last bit in the howto and i get a fatle error
[11:53] <HaroldJohnson> din, If I could tell you how many times I've typed iwconf, iwlist scan, iwconfig ath0 up, etc...
[11:53] <tiglionabbit> HaroldJohnson: actually, we're quite kind to newbies here, in comparison to other chats
[11:53] <benkong2> Seveas, what color is blue?
[11:53] <supernix> Hi everytime I start Kmid it gives an error about /dev/sequencer and then when I look there I don't see any /dev/sequencer how do I fix this
[11:54] <Troy_McClure> hdc1 is the one i can not get access to only through root
[11:54] <Seveas> benkong2, the 3rd of the primitive colors
[11:54] <Troy_McClure> i see that that is all set right... so i have no idea
[11:54] <HaroldJohnson> tiglionabbit: And I'm supposed to be thankful you're not unkind?
[11:54] <cmatheson> supernix: you don't have a real midi device.  may want to check out timidity
[11:54] <supernix> I have been trying desperately to get to where I can listen to Midi files
[11:54] <tiglionabbit> HaroldJohnson: yes
[11:54] <tiglionabbit> HaroldJohnson: now what was your question?
[11:54] <supernix> I have it installed how do I use it ?
[11:54] <HaroldJohnson> tiglionabbit, That's some attitude.
[11:54] <benkong2> nalioth, hmmmm... it take more than a bot to do that huh?
[11:54] <nalioth> benkong2: some people wonder
[11:54] <Seveas> Troy_McClure, can you paste the output of the command 'mount' ther too please
[11:54] <knoppix> hey
[11:54] <eliUbuntu> nalioth: just did it. yes it was well explained. I cannot access one partition (vfat). I suspect it is because it has already been mounted. should i reboot to see if the error is corrected?
[11:54] <tiglionabbit> HaroldJohnson: come on dude, it's free help, and a lot more responsive than some tech support line
[11:55] <nalioth> eliUbuntu: reboot is only necessary when you upgrade the kernel
[11:55] <eliUbuntu> nalioth: the ntfs drive did mount correctly though
[11:55] <knoppix> anyone useing ubuntu with vmware 4 or lower ?
[11:55] <nalioth> eliUbuntu: a "umount" command may be used
[11:55] <supernix> cmatheson: how do you fire up Timidiy or whatever that was I know I have it installed
[11:55] <eliUbuntu> let me try that
[11:55] <IcemanV9> ok, HaroldJohnson, let try this way .. 1) iwlist ath0 scan (get the list) 2) iwconfig ath0 essid <whichever has strong signal> 3) dhclient ath0
[11:55] <HaroldJohnson> tiglionabbit, I agree, and it's been wonderful, for the most part.  Absolutely incredible support, except for the wireless part.
[11:55] <Seveas> eliUbuntu, ig you type mount with no arguments, you can see what is mounted already
[11:55] <cmatheson> supernix: i reckon you probably don't have it installed... first do 'aptitude install timidity' and then launch it (run timidity from the command line)
[11:55] <jeanluc> hi
[11:56] <Seveas> hi
[11:56] <jeanluc> how come mp3 won't play in ubuntu?
[11:56] <knoppix> can anyone help me out with vmare
[11:56] <Seveas> jeanluc: Go to http://wiki.ubuntu.com/RestrictedFormats to find out all about mp3/dvd/flash/java/realplayer etc... support
[11:56] <tiglionabbit> HaroldJohnson: well, networking in hoary is kind of confuddled, so there are a lot of places that could be the problem.  Makes it hard for us to help with this topic
[11:56] <Troy_McClure> http://paste.ubuntulinux.nl/541
[11:56] <din> HaroldJohnson, it's not that hard to get wireless working... get the essid of whatever device you are using, be it a router or whatever, then iwconfig (interface) essid (essid name) and then use dhclient to get a dhcp address or ifconfig to set a static ip address (man ifconfig for more info)
[11:56] <Troy_McClure> thats my mount
[11:56] <HaroldJohnson> IcemanV9, How do I know which one has the strongest signal?
[11:56] <knoppix> i went on the wiki for vmware
[11:56] <carambol> is it advisable to install firefox-1.0.5?
[11:56] <supernix> oh cmatheson so it is a command line only program ?
[11:56] <Seveas> carambol, no
[11:56] <knoppix> but i am getting an error
[11:56] <carambol> thnx my guru
[11:56] <knoppix> Unable to open the installer database /etc/vmware/locations in read-mode.
[11:56] <knoppix> Execution aborted.
[11:56] <IcemanV9> HaroldJohnson: Link Quality=
[11:57] <mumbles> are the forums down ?
[11:57] <knoppix> what can i do about that ?
[11:57] <cmatheson> supernix: no, it's made w/ a tk interface, but i don't know if it will stick it in the menus for you or not
[11:57] <HaroldJohnson> tiglionabbit, I understand.  Ubuntu (and Linux in general) may be great for lots of things.  Perhaps it's not great for wireless users.
[11:57] <Seveas> Troy_McClure, odd, that output is perfectly fine, you should be able to read from the drive as any user
[11:57] <IcemanV9> HaroldJohnson: or Quality= even
[11:57] <Seveas> HaroldJohnson, indeed
[11:57] <eliUbuntu> nalioth: i had an error on hda 3 ext 3 - > (rw,errors=remount-ro)
[11:57] <moire> hi
[11:57] <Troy_McClure> yeah i know, i think i may try a restart and see what happens
[11:57] <Seveas> Troy_McClure, try umont /dev/hdc1
[11:58] <tiglionabbit> HaroldJohnson: my wireless is working.  It's not hard to get working once you know what you're doing
[11:58] <Troy_McClure> one more question, whats that program you all use to test how many frames you get?
[11:58] <Seveas> and then mount -a
[11:58] <nalioth> eliUbuntu: so ya fixed up now?
[11:58] <Seveas> Troy_McClure, glxgears
[11:58] <moire> has somebody a good apt-proxy.conf for the ubuntu repos? ;)
[11:58] <knoppix> any one know whats up with my proablm ?
[11:58] <eliUbuntu> still trying
[11:58] <knoppix> =\
[11:58] <Seveas> HaroldJohnson, can you maybe repeat the state of your wireless problem, I missed the beginning of your conversation
[11:58] <HaroldJohnson> tiglionabbit, Well, that's my problem, and why I'm asking for help: I have no idea what I'm doing.
[11:58] <Troy_McClure> is glxgears installed in ubuntu?
[11:59] <Seveas> HaroldJohnson, and I myself have an atheros card working fine so I might be able to help
[11:59] <cmatheson> Troy_McClure: yes
[11:59] <Seveas> Troy_McClure, yes
[11:59] <eliUbuntu> nalioth: what does this mean? -> errors=remount-ro
[11:59] <Troy_McClure> okay its running and i am getting like 115...
[11:59] <Troy_McClure> oh just got 723
[11:59] <HaroldJohnson> IcemanV9, I'm finding Quality=0/94 for all the listings.
[11:59] <Seveas> eliUbuntu, when linux encounters errors on that drive it will remount it read only
[11:59] <IcemanV9> Seveas: he's using madwifi, installed just fine and cannot connect to any open network
[11:59] <nalioth> eliUbuntu: i'd just umount cleanly