[01:16] <ubotu> New bug: #196823 in mesa (main) "libgl1-mesa-glx" [Undecided,New] https://launchpad.net/bugs/196823
[04:27] <ubotu> New bug: #196711 in xserver-xorg-input-mouse (main) "single click is considered as double click" [Undecided,Confirmed] https://launchpad.net/bugs/196711
[06:56] <tjaalton> hmm, should we just drop -unichrome..
[07:37] <bryce> have we converted over to openchrome as the default?  or are we still using via?
[07:38] <bryce> I think -unichrome could be dropped to universe for Intrepid
[07:43] <tjaalton> it is already in universe, and openchrome is the default
[07:44] <tjaalton> it's just that there are no unichrome releases, the current one is a git checkout from a year ago
[07:45] <bryce> hmm
[07:45] <bryce> well I would leave it for hardy and drop it starting with intrepid
[07:45] <tjaalton> why wait?
[07:46] <tjaalton> it's just collecting bugs, albeit not that many users apparently, given that it's not even installable currently :)
[07:47] <bryce> oh, if it's not even installable, I guess there'd be limited value in keeping it
[07:47] <tjaalton> it's simple to fix though, just change the Provides
[07:48] <bryce> I'm just thinking that if people have been using it in the past, dropping it entirely for hardy might be a bit too drastic since hardy is supposed to be an lts
[07:48] <bryce> however if it's not installable, and hasn't that many users, it probably won't matter
[07:51] <tjaalton> the driver uses "via" name anyway, so on upgrade the users will end up using openchrome
[07:51] <tjaalton> umm
[07:52] <tjaalton> or maybe not
[07:58] <tjaalton> openchrome sucks in modesetting though
[07:59] <tjaalton> poor via users, nobody cares :)
[07:59] <bryce> hehe
[08:05] <tjaalton> bdmurray: nvidia-xconfig is still there, but maybe it should be dropped
[08:06] <tjaalton> but not before jockey has a cmdline option
[08:15] <ubotu> New bug: #196900 in linux-restricted-modules-2.6.24 (restricted) "Ati x1600Pro White screen on active desktop fx" [Undecided,New] https://launchpad.net/bugs/196900
[09:31] <bryce> night
[09:31] <tjaalton> night
[09:57] <Ng> is bryce's xrandr stuff going to replace the Screens and Graphics tool?
[09:57] <tjaalton> I think so
[09:57] <tjaalton> although they server different purpose
[09:57] <tjaalton> -r
[09:57] <Ng> I was playing with the latter last night at home and it does some strange stuff. I tell it my monitor is an LCD Panel that can do 1920x1080 and the highest resolution it offers is 1680x1050
[09:57] <Ng> tjaalton: yeah, that's what I wondered
[09:58] <Ng> the strange and wonderful thing is that X actually figures everything out itself if I remove the xorg.conf. pops straight into 1920 :)
[10:03] <tjaalton> guidance trying to be clever or something
[10:14] <pwnguin> man, that tool really kicked my ass when i set up our mythbox
[11:26] <ubotu> New bug: #196789 in xorg (main) "while playing different games the screen field either shrinks to 1/8  screen size or is sucked into the desktop and vanishes" [Undecided,New] https://launchpad.net/bugs/196789
[11:31] <ubotu> New bug: #117480 in openoffice.org (main) "OpenOffice 2.2 crashes the machine with File->Open (dup-of: 113679)" [Undecided,Confirmed] https://launchpad.net/bugs/117480
[12:51] <ubotu> New bug: #189380 in sun-java5 (multiverse) "[Hardy] Can't make any java package work (dup-of: 87947)" [Undecided,New] https://launchpad.net/bugs/189380
[13:11] <ubotu> New bug: #196979 in xorg (main) "laptop crashes when closing the lid" [Undecided,New] https://launchpad.net/bugs/196979
[13:16] <ubotu> New bug: #98594 in xubuntu-meta (universe) "Xubuntu - Bad fonts size: Firefox, OpenOffice, interfaz user, etc (dup-of: 112514)" [Undecided,Invalid] https://launchpad.net/bugs/98594
=== asac_ is now known as asac
[15:08] <seb128> bryce: I officially don't like those gnome-desktop changes
[15:22] <Q-FUNK> :)
[15:22] <Q-FUNK> seb128: which ones?
[15:22] <seb128> Q-FUNK: the xrand changes
[15:24] <Q-FUNK> hmm... such as?
[15:39] <Q-FUNK> here, I'm mostly worried that Hardy will be released withthe absolute piece of crap known as Firefox 3.
[16:21] <tjaalton> ff3 rocks
[16:23] <Q-FUNK> it's as slow as molasses and polutes the notification tray with crap.
[16:24] <Q-FUNK> "upgrading" to ff3b3 that is currently in hardy made me fele like someone had removed all the RAM out of my workstation. the difference of speed was that drastic.
[16:24] <tjaalton> hmm? fast as hell and my notification tray is empty :)
[16:25] <Q-FUNK> tjaalton: i really wonder how you do that.  here, access speed is down to half what it was and the UI has become extremely unresponsive.
[16:26] <tjaalton> uses less memory too
[16:27] <Q-FUNK> not here
[16:27] <tjaalton> try a new profile
[16:28] <Q-FUNK> you mean they still haven't gotten rid of profiles either?
[16:29] <tjaalton> eh
[16:38] <Q-FUNK> hard to tell with a new profile.  it fails to import my bookmarks or my session form the other profile
[16:48] <bryce> seb128: what do you not like?
[16:49] <seb128> bryce: it add a lot of functions to the public api
[16:50] <seb128> bryce: I think I would like better to ship copy of the code in gnome-settings-daemon and gnome-control-center if possible
[16:51] <seb128> bryce: another issue is that those functions don't use a gnome_ namespace and they should
[16:51] <seb128> those symbols could conflict with other libs, etc
[16:52] <seb128> soren said he would accept a patch to use a correct namespace
[16:53] <bryce> by 'ship copy of the code' what do you mean?
[16:54] <seb128> the functions which are added to gnome-desktop
[16:54] <seb128> have this code in gnome-control-center
[16:54] <seb128> and gnome-settings-daemon
[16:54] <seb128> so they would not be in any public library
[16:54] <seb128> just code in the binaries
[16:55] <bryce> ah, ok anything else?
[16:55] <seb128> no
[16:56] <seb128> sorry about that, but I think it's a better solution
[16:56] <seb128> this way we don't provide a non stable api
[16:56] <seb128> and we will not break the lib compatibility when upstream does something similar
[16:57] <seb128> I mean some function names might change etc when that's upstreamed next cycle
[16:57] <bryce> ok, shall I make these changes or are you planning to?
[16:57] <seb128> which means the ubuntu libgnome-desktop abi would break compatibility
[16:58] <seb128> I'll not do those today most likely
[16:58] <seb128> you are welcome to look at those
[16:58] <seb128> I'm sorry I had a very busy week
[16:58] <seb128> what we can do if you want to get the things some testing is to upload the changes now as you did them
[16:58] <seb128> and switch to the copies later
[16:59] <bryce> yes, that would be great
[16:59] <seb128> ok, I'll do that then
[16:59] <bryce> I'll work on the changes today
[16:59] <seb128> thanks
[17:03] <soren> seb128: I said that I'd accept a patch to use a correct namespace for what?
[17:04] <seb128> soren: not you, the soren from redhat who is writting the code we are speaking about
[17:04] <soren> seb128: Oh, sorry. :)
[17:04] <seb128> soren: sorry about the confusing with your nickname ;-)
[17:05] <soren> seb128: No worries :)
[17:35] <seb128> bryce: gnome-desktop changes uploaded
[17:50] <bryce> seb128: thanks
[17:51] <bryce> seb128: you'll be uploading g-c-c and g-s-d as well?
[17:51] <seb128> bryce: looking at the gnome-settings-daemon changes
[17:51] <seb128> there is no setting migration, right?
[17:52] <seb128> which means user will be back to whatever xorg uses rather than what he had configured, right?
[17:53] <bryce> no, it detects and starts from the current settings
[17:53] <bryce> so if they achieved that via xorg.conf, it uses that; if they did it through the current screen resolution tool, it uses that.
[17:56] <ubotu> New bug: #197049 in xorg (main) "[hardy] shift and caps lock keys not working" [Undecided,New] https://launchpad.net/bugs/197049
[17:59] <seb128> bryce: how does that work? the user settings are written to gconf and applied on startup right now, the code applying those gconf key is replaced to use the libgnomedesktop one apparently
[18:01] <ubotu> New bug: #197053 in linux-restricted-modules-2.6.24 (restricted) "package nvidia-glx None failed to install/upgrade: el subproceso post-removal script devolvió el código de salida de error 2" [Undecided,New] https://launchpad.net/bugs/197053
[18:01] <seb128> bryce: gsd uploaded now
[18:15] <bryce> what gnomedesktop does is store the configuration layout in an xml file in the user's home dir
[18:15] <bryce> so (if I understand correctly) the first time it's run, it will store whatever the user has set up
[18:16] <bryce> I tested on a system with dual monitors set up via a .xprofile setting, and it picked up and handled that.  If it handles that ok, it should handle most anything
[18:17] <bryce> I also tested with laptops in a few different configurations and it picked up the existing settings correctly
[18:19] <seb128> bryce: well, the question was whether it'll pick the setting written by the old capplet on gutsy and stored in gconf when you first log in hardy
[18:20] <seb128> bryce: because I've seen no code reading those gconf keys and written a new .xprofile with the values
[18:20] <seb128> bryce: which is not really an issue but could be nice to fix
[18:22] <bryce> right, it does not read those gconf keys directly, just indirectly by taking them from what has been booted up (which in some ways is better)
[18:23] <seb128> I fail to see how that can work
[18:23] <seb128> let me take an example
[18:23] <seb128> xorg default is 1024x768, user is on gutsy, he picks 800x600, the value is written to gconf
[18:24] <seb128> he logs in on gutsy, gnome-settings-daemon read the gconf key, apply it and he gets 800x600
[18:24] <seb128> he update the hardy, reboot
[18:24] <seb128> he logs in, nothing read the key, nothing apply those, he gets 1024x768 which is the xorg config
[18:24] <seb128> no?
[18:24] <seb128> since gnome-settings-daemon in hardy doesn't read those keys
[18:24] <bryce> hmm
[18:25] <bryce> yeah I guess that's true
[18:26] <seb128> ok, not a big issue but might be worth considering migration code before hardy
[18:26] <seb128> should be easy to have something reading the gconf keys and writting those to xprofile on first hardy login
[18:26] <seb128> bryce: looking to the capplet changes now, the patches are mostly redhat work, right?
[18:27] <seb128> bryce: just wanting to give some credit where it's due in the changelog if that's the case ;-)
[18:28] <bryce> the first (main) patch is from redhat, the auto* changes I did, and there's a patch I did to clean up the ui a little
[18:28] <seb128> ok
[18:29] <bryce> the hard part was getting the changes into the gnomedesktop lib such that everything linked to it properly
[18:45] <seb128> bryce: your new capplet seems to be working but I just broke my session using it :-p
[18:46] <seb128> I did rotate the screen
[18:46] <bryce> I've found it certainly offers a good way to test for xrandr bugs ;-)
[18:46] <seb128> but now it doesn't take any click or keyboard event
[18:47] <bryce> sounds like a known xrandr bug
[18:47] <bryce> fwiw, rotation worked 100% on all of the systems I tested on.
[18:47] <seb128> lucky you :-p
[18:47] <bryce> one system has problems when scaling up or down
[18:47] <bryce> maybe we should include a note on the dialog, "Um, maybe save your work first?"
[18:48] <seb128> rather "backup your disk"
[18:48] <seb128> because restarting xorg doesn't fix the issue
[18:48] <seb128> I've no a broken session and no way out of the command line to fix it
[18:48] <bryce> the issue I ran into required a reboot
[18:49] <seb128> that's not good
[18:49] <seb128> well, it's applying the rotation on login
[18:49] <seb128> which seems to be an issue
[18:49] <bryce> hrm yeah
[18:49] <seb128> where is the config file?
[18:49] <bryce> ~/.gnome2/monitors.xml
[18:50] <seb128> thanks
[18:50] <seb128> fixed
[18:50] <bryce> there should be a confirmation dialog like displayconfig-gtk has
[18:50] <seb128> I've to go for diner but I've g-c-c ready for upload
[18:50] <seb128> will upload later
[18:50] <bryce> ok
[18:50] <seb128> having what the previous capplet had would be nice
[18:51] <bryce> I'll look into that next week
[18:51] <seb128> a counter which reverts if you don't ack
[18:51] <seb128> cool
[18:51] <bryce> yeah displayconfig-gtk had that as well
[18:51] <seb128> otherwise good work, it looks cool ;-)
[18:51] <bryce> great
[18:51] <bryce> did it get your monitor name correct?
[18:55] <ubotu> New bug: #197069 in xserver-xorg-video-amd (main) "xserver-xorg-video-amd: wide resolutions don't work" [Undecided,New] https://launchpad.net/bugs/197069
[21:04] <seb128_> re
[21:04] <seb128_> bryce: still around?
[21:05] <bryce> yup
[21:05] <seb128_> I uploaded gnome-control-center
[21:05] <bryce> yay!
[21:05] <seb128_> xrand is really buggy on my dell laptop though
[21:05] <seb128_> rotation breaks xorg in a way I've to switch to a vt and edit the xml by hand to get xorg working again
[21:05] <bryce> aside from the rotation, are you seeing other issues?
[21:05] <seb128_> and changing resolution corrupts part of the screen
[21:06] <bryce> seb128I will put a note in the dialog on how to restore
[21:06] <seb128_> yes, changing to 800x600 worked correctly, switching back to 1440x900 doesn't
[21:06] <seb128_> I get what looks like a working 800x600 area
[21:06] <bryce> right, that is one of the bugs I ran into on one of my systems that I mentioned
[21:06] <seb128_> and a corrupted border on right and bottom which is not usuable
[21:07] <seb128_> I expect intel to be not too buggy ;-)
[21:07] <bryce> and you can move the mouse into those areas, and interact with buttons located there
[21:07] <seb128_> expect intel not too by too buggy rather
[21:07] <seb128_> yes
[21:07] <seb128_> but I can't move things there
[21:07] <bryce> yup, that's the same bug I found - jdub also reported it earlier, but identified it as a metacity bug
[21:08] <bryce> he tried running a different window manager and it worked correctly
[21:08] <seb128_> compiz consider the corruption border as the viewport limit and will switch to next one
[21:08] <seb128_> I'm using compiz
[21:08] <bryce> yeah mine was with compiz as well. 
[21:08] <seb128_> ok
[21:08] <seb128_> I think I've done my part for this week now that those packages are uploaded
[21:09] <seb128_> I'll let you figure the xrandr issues ;-)
[21:09] <bryce> so maybe check if the same thing happens with metacity - if not, then it may be a compiz bug
[21:09] <bryce> yup
[21:09] <seb128_> let me know if you need debug informations
[21:09] <seb128_> well, you said jdub had the issue using it
[21:09] <bryce> sure, thanks, yep I'm working on the xrandr issues
[21:09] <seb128_> cool, thanks
[21:09] <seb128_> and again, nice work ;-)
[21:09] <seb128_> out of the xrandr bugs the capplet looks great
[21:09] <bryce> the rotation one is well known; this other one I've not seen reported but I can reproduce it easily, so...
[21:10] <bryce> good to hear
[21:10] <bryce> still needs a few more features, but good enough for hardy.  Much better than what we've had
[21:10] <seb128_> right
[21:25] <bryce> tjaalton: btw I have a new patch to extend the "greedy" fix to all intel chipsets here - http://people.ubuntu.com/~bryce/Uploads/
[21:25] <seb128_> bryce: btw you come you don't use a ppa for your uploads?
[21:25] <bryce> tjaalton: but I'm not certain yet if it's appropriate to do that, or if it would cause more issues
[21:26] <bryce> seb128_: I should start using that, I just have my workflow set up for doing local builds mostly
[21:26] <seb128_> well,; you copy those on rookery apparently though
[21:26] <seb128_> so you could as easily dput them on launchpad ;-)
[21:27] <bryce> yep
[21:28] <bryce> can you delete things from a ppa?
[21:29] <mvo> tjaalton: hm, what happend to the nvidia-settings that used to be part of nvidia-glx (-new) ? is that now all folded into the nvidia-settings package?
[21:29] <keescook> bryce: yeah, it's on the left side, 2nd action down, IIRC.
[21:30] <tjaalton> mvo: yep
[21:30] <mario_limonciell> tjaalton, why did that happen?
[21:30] <tjaalton> bryce: ok, maybe after the weekend?
[21:30] <tjaalton> mario_limonciell: because it has source
[21:30] <mario_limonciell> oh fair enough :)
[21:31] <bryce> tjaalton: sure
[21:31] <bryce> tjaalton: I may have more user reports on it by then
[21:31] <tjaalton> mario_limonciell: but now that the default xorg.conf has a ServerLayout section again, it's not a problem anymore.. without that it would just crash
[21:31] <bryce> heya keescook
[21:32] <tjaalton> man, I'd love to see fglrx banished from the archive when r5/6xx has 3D support
[21:32] <mario_limonciell> tjaalton, there are similar problems with aticonfig not liking the default xorg.conf (when trying aticonfig --initial)
[21:33] <mario_limonciell> i've reported them to the beta team
[21:33] <tjaalton> mario_limonciell: yep
[21:34] <tjaalton> well, jockey should have a cmdline interface, then every doc should mention that aticonfig/nvidia-xconfig are Evil
[21:34] <mvo> tjaalton: hm, I use it in compiz to detect the available video ram, any chance to get it back ?
[21:34] <mario_limonciell> well there features of the AMD driver that are not exposed via any other public interface
[21:34] <tjaalton> mvo: maybe by depending on it
[21:35] <mvo> tjaalton: its universe currently, but that shouldn't be too much of an issue - but let me dig a bit into it, maybe there is a different way to get the video ram
[21:36] <keescook> heya bryce :) I just happened to catch your question :)
[21:37] <tjaalton> mvo: btw, jockey still disables composite for fglrx, but apparently composite still has some issues..
[21:37] <mvo> tjaalton: I can give it a try early next week - I can't wait to see fglrx go
[21:37] <bryce> tjaalton: do you seriously think we may be able to drop fglrx?  that'd be rather stunning.  I hadn't realized things had progressed that far already
[21:38] <tjaalton> mvo, bryce: no, we are not there yet :)
[21:38] <tjaalton> unfortunately
[21:38] <mvo> tjaalton: the "ati" driver works quite well with the r500 now in 2d, randr, suspsend all of this is good for me
[21:38] <mvo> (well, radeon)
[21:38] <tjaalton> 3D support is still very much a work in progress..
[21:39] <tjaalton> maybe intrepid+1..
[21:39] <tjaalton> r5xx docs are out, so maybe intrepid will have a mesa which supports it
[22:00] <tjaalton> bryce: the archive has 2.2.1-1ubuntu2 ;)
[22:26] <bryce> ah, hmm
[22:26] <bryce> tjaalton: I'll rework the patches then.  I also have another quirk to add
[22:26] <tjaalton> bryce: yep, saw that one
[23:23] <bryce> http://bryceharrington.org/drupal/display-config-1
[23:36] <tjaalton> looks nice