[00:03] <bryce> tseliot: mind if I blog about this?  :-)
[00:04] <tseliot>  bryce: sure, have fun ;)
[00:06] <tseliot> bryce: as regards blocking the interface, I guess there's no way to solve it unless we mess with threads.
[00:06] <bryce> yep
[00:07]  * tormod says goodnight
[00:07] <tseliot> and we don't want to mess with threads with GTK... trust me
[00:07] <bryce> oh believe me, I know
[00:07] <tseliot> heh
[00:11] <tseliot> oh, I've found the line which makes it output "Error". It's in policyui.py. I won't touch the code now since I'm 100% sure that I would screw it up (1:11AM)
[00:27] <tseliot> I've found another thing I'll have to correct. I'll fix it all tomorrow
[00:30] <bryce> ok cool
[00:31] <tseliot> good night
[00:57] <bryce> http://bryceharrington.org/drupal/node/61
[08:43] <bryce> tseliot: so commenters on the blog feel that the wording would be better "please log out and log in again" instead of "please restart the Xserver"
[08:44] <tseliot> bryce: ok, it can be changed
[08:44] <bryce> (http://bryceharrington.org/drupal/node/61)
[08:47] <tseliot> bryce: would this be ok? "Operation Complete. Please log out, log in again and use Monitor Resolution Settings again in order to apply your settings." 
[08:48] <james_w> tseliot: hi, is "use Monitor Resolution Settings again in order to apply your settings." what they are already trying to do?
[08:49] <tseliot> james_w: if you set a screen to the left of the other but the framebuffer is not enough
[08:49] <tseliot> you will have to set the virtual resolution and restart the xserver
[08:49] <tseliot> however, in so doing the settings will be lost
[08:50] <tseliot> and you will get cloned screens unless you use the GUI again
[08:50] <tseliot> and this time the settings will be applied immediately
[08:50] <james_w> tseliot: yes, so I think the message should indicate they should try again
[08:51] <james_w> in order to be clear that they don't need to hunt for another tool and try something else.
[08:51] <james_w> perhaps my point isn't clear?
[08:51] <tseliot> james_w: good point. can you suggest a better message then?
[08:52] <tseliot> better than what we have in the app now, I mean
[08:52] <james_w> "Operation Complete. Please log out, log in again and retry the current operation"?
[08:52] <james_w> if they get it when clicking "Apply"
[08:53] <james_w> you probably want to ask a few more people though, as that may not be clear enough
[08:53] <tseliot> yes, that's when they get it
[08:53] <james_w> perhaps it needs two sentences.
[08:53] <tseliot> ok
[08:53] <tseliot> let's use yours and wait for more feedback
[08:55] <bryce> hmm
[08:56] <bryce> hard to express that without it sounding funky for the user
[08:56] <bryce> it shouldn't say Operation Complete because then it sounds like the whole operation might be complete (which clearly it will not)
[08:58] <bryce> hmm "Please log out and log back in again.  You will then be able to use Monitor Screen Resolution to setup your monitors"
[08:58] <tseliot> bryce: right
[08:58] <bryce> yeah I think more feedback would be nice
[08:58] <bryce> maybe ask mpt, he usually has well thought out input to give
[08:59] <tseliot> ok
[08:59] <james_w> yeah, he'll be around soon
[09:00] <james_w> what would be ideal would be if it could add a one-run item to the user's session that started the capplet in the configuration they have chosen,
[09:01] <james_w> could it write a monitors.xml.desired, and then behave differently if one existed?
[09:01] <bryce> I was wondering about that
[09:02] <bryce> james_w: btw do you know why the revert dialog patch got dropped?
[09:03] <james_w> bryce: I think it got dropped when the capplet was merged upstream
[09:04] <james_w> I don't think it was because seb didn't like it though, so we could resurrect it.
[09:05] <bryce> well I'm surprised because seb128 had been adamant about having that implemented.
[09:05] <james_w> maybe I'm wrong then
[09:05] <james_w> you should ask him when he returns
[09:06] <bryce> I guess it doesn't matter.  I see he did the merge so if he still wanted it I guess he'd have ported it forward or talked to you or I about it.
[09:07] <bryce> you know, I never got an answer why upstream didn't like that
[09:09]  * bryce shrugs
[09:09] <bryce> anyway, time for bed.  cya.
[09:11] <tseliot> night bryce
[09:11] <james_w> night bryce 
[09:12] <tseliot> james_w: what we can do (and what I used to do in URandr, a program of mine) is write a script and add it to the gnome-session or kde-session so that it applies the settings without having to use that program again
[09:12] <tseliot> a shell script
[09:12] <james_w> tseliot: yeah, that would be good
[09:13] <james_w> I think it would be better modifying the capplet itself to do it, but using the session would be good
[09:13] <tseliot> james_w: this would make settings permanent though
[09:14] <tseliot> james_w: maybe something can be done with gconf
=== federico1 is now known as f_shower
[17:01] <bryce> is composite still limited to a max virtual of 2048x2048?
[17:02] <jcristau> what?
[17:03] <bryce> http://lists.freedesktop.org/archives/xorg/2007-August/027634.html - i915 is limited to 2048x2048 w/ 3d still I assume, but are newer chipsets at 4kx4k?
[17:05] <jcristau> that limit is way higher for 965+ afaik
[17:08] <bryce> hmm, I thought so but on my 965 the default virtual is still limited to 2048x2048.
[17:09] <bryce> I'm digging through the -intel source code to figure out if there's a reason why it's still limited to that
=== f_shower is now known as federico1
[17:20] <bryce> ah http://lists.freedesktop.org/archives/xorg/2008-April/035007.html
[17:21] <shenki> can i get someone to take a look at https://bugs.launchpad.net/bugs/259129
[17:22] <ubottu> Launchpad bug 259129 in xserver-xorg-input-synaptics "synaptics (almost) crashes in recent kernels" [Undecided,New] 
[17:22] <shenki> with the switch to .27 kernels, more people will be seeing the error in their logs
[17:22] <tseliot> bryce: can you upload envyng-qt, please? The links to the source are in this file: http://albertomilone.com/ubuntu/envyng-intrepid/list.txt
[17:22] <tseliot> to intrepid, I mean
[17:23] <jcristau> shenki: will be fixed in the next version
[17:23] <bryce> jcristau: I'm gathering we simply need a patched mesa (or mesa 7.1) - LP #146859
[17:23] <ubottu> Launchpad bug 146859 in xserver-xorg-video-intel "No dri for virtual screen greater than 2048x2048" [High,In progress] https://launchpad.net/bugs/146859
[17:24] <shenki> jcristau: yes, that's what i said in the bug report. any idea when the next version will be uploaded?
[17:24] <tjaalton> shenki: tomorrow
[17:24] <bryce> tseliot: sure; do you have the fixed screen-resolution-extra ready to go?
[17:24] <jcristau> shenki: it doesn't matter...
[17:24] <jcristau> the kernel fixes things up anyway
[17:24] <shenki> jcristau: it doesn't matter?
[17:25] <tseliot> bryce: yes, but I would like to test what I did
[17:25] <bryce> tseliot: ok cool
[17:25] <shenki> well, yes and no. it doesn't crash, but the touchpad driver sits there complaining about loosing sync every now and then
[17:25] <shenki> tjaalton: thanks
[17:25] <jcristau> shenki: that's unrelated
[17:25] <tjaalton> bryce: looks like it's not that simple to fix
[17:25] <shenki> jcristau: ok. where does that come from?
[17:25] <jcristau> bryce: #146859 is about i915..
[17:26] <jcristau> shenki: dunno. kernel or hardware bug.
[17:26] <jcristau> bryce: oh, unless there's some other unrelated discussion in it
[17:27] <tjaalton> bryce: sorry, didn't know there _was_ a patch for that (and the hard bit would be to go beyond 4kx4k)
[17:29] <bryce> jcristau: I gather the mesa patch discussed there is for all drivers; I could be wrong though (only one cup of coffee so far)
[17:29] <bryce> morning tjaalton
[17:29] <jcristau> the mesa patch there only touches i965
[17:30] <bryce> right
[17:31] <bryce> bah I need more coffee
[17:31] <bryce> jcristau: do you know when debian will be packaging mesa 7.1?
[17:31] <tjaalton> g'morning bryce
[17:32] <tjaalton> I could update the mesa git
[17:32] <jcristau> bryce: whenever i find time for it
[17:32] <bryce> tjaalton: btw I notice some patch posting activity on the Xcb list, but not seeing if the rearchitecting work we need for fixing those locking problems is coming in yet.  I've emailed bart to check, but if it doesn't come through, I'm wondering if we should disable libxcb
[17:33] <bryce> tjaalton: that'd be great
[17:33] <jcristau> (kinda working on it now, but dunno when it'll be ready)
[17:35] <tjaalton> bryce: hum, sounds drastic.. what locking bugs are there now that java is fixed?
[17:36] <jcristau> meh. forgot to set DEB_BUILD_OPTIONS :/
[17:40] <bryce> tjaalton: #185311 has a lot of assertions from users that $random_app doesn't work unless my libx11-noxcb package is used
[17:40] <jcristau> the only one i know about is some vmware shit
[17:41] <tjaalton> checking..
[17:42] <bryce> there's fewer recent comments though.  Maybe the latest java version isn't as badly afflicted
[17:43] <tjaalton> java 6-07 at least should be fixed
[17:43] <bryce> ok
[17:43] <bryce> well guess I won't worry about it then
[17:44] <tjaalton> :)
[17:44] <bryce> I think the bulk of the apps have been java based
[17:44] <tjaalton> yeah..
[17:46] <tjaalton> I've packages a lot of math apps locally (matlab, mathematica..), and they all tend to ship a java runtime of their own, but work just fine if the dir is linked under /usr/lib/jvm :)
[17:46] <tjaalton> so they all get the latest java that is installed
[17:49] <bryce> the last comment in that bug mentions cinelerra which I guess is C
[17:50] <bryce> but user didn't indicate how they got it.  cinelerra appears to roll their own .deb packages outside ubuntu
[17:50] <tjaalton> bah, got to put the tux on and get ready for the stage.. ->>
[17:50] <tjaalton> bbl
[17:50] <bryce> cya
[17:54] <bryce> tseliot: uploaded
[17:54] <tseliot> bryce: thanks a lot.
[17:54] <tseliot> I'll have to ask an admin, right?
[17:55] <bryce> tseliot: probably
[17:55] <bryce> tseliot: try asking slangasek
[17:55] <tseliot> bryce: ok
[17:56] <tseliot> I'm updating my laptop so as to try screen-resolution-extra. Testing shouldn't take long
[18:00] <tseliot> bryce: I talked with james_w about making screen resolution-extra apply the settings automatically after the login
[18:00] <bryce> tseliot: ah?
[18:00] <tseliot> bryce: I did something similar in URandR
[18:01] <bryce> it'd be great if we could do that; it'd simplify the workflow
[18:01] <tseliot> bryce: by adding either a shell script to the GNOME session or something with gconf (if possible)
[18:03] <tseliot> what do you think?
[18:03] <bryce> I'd need to see the implementation, but in principle it sounds good
[18:03] <tseliot> bryce:
[18:04] <tseliot> I can make Python create the script
[18:04] <tseliot> as I used to do
[18:04] <tseliot> or I can do it in C
[18:04] <tseliot> since the C part has access to all the details
[18:05] <bryce> yeah best to do it in C probably
[18:05] <tseliot> e.g. which display is on the left of which, etc.
[18:06] <tseliot> ok, one more task to do in C. I'll experiment a bit then and show you something soon. But of course we should focus on what currently works (or should work) ;)
[18:08] <bryce> great, and agreed
[18:08] <james_w> I agree
[18:08] <bryce> the sooner we can get the current stuff in front of testers, the sooner we'll be able to get this in main and switched on for everyone
[18:09] <tseliot> right
[18:09] <james_w> Making the capplet itself do it would be good I think, as I think it would work better in failure situations, and makes it easier for the user to tweak.
[18:11]  * tseliot nods
[18:41] <tseliot> bryce: ok, I have fixed every problem I'm aware of, however the C program still outputs Error:  Failure running /usr/share/.../policyui.py
[18:41] <tseliot> Close
[18:42] <tseliot> I guess it's because I make the python script exit with an error status so that the C part can understand that it doesn't have to apply the settings
[18:43] <tseliot> other than this, the other output and the bugs are gone
[18:46] <tseliot> bryce: I think that the only way to get rid of that error output is calculate the framebuffer size in C and execute the Python script only if necessary
[18:46] <tseliot> the C code is already there and I'm sure that we can reuse it
[18:46] <tseliot> what do you think?
[18:51] <bryce> sure
[18:51] <bryce> ok, well that Error stuff isn't visible to users so I guess it's just a minor irritant
[18:57] <tormod> tedg: ping
[18:58] <tseliot> bryce: would it be ok if I changed Section: contrib/x11 into Section: utils/x11 in the control file?
[18:59] <tseliot> Riddel asked me to change contrib yesterday
[18:59] <tedg> tormod: pong
[19:00] <tedg> tormod: Let's not both update xscreensaver this time :)
[19:00] <tormod> tedg: right :) be my guest 
[19:01] <tormod> I am running a little out of time, so if you can...
[19:01] <tedg> tormod: Okay, I will do it.
[19:01] <tormod> thanks
[19:02] <tormod> as you see, 5.07-1 is not released yet, because Jose Luis is travelling etc, but it's good as done.
[19:02] <tormod> if you see something that should be fixed in Debian, please tell me.
[19:03] <tedg> tormod: Okay, thanks.
[19:06] <tseliot> bryce: BTW the fixes are all in my bzr branch: /~albertomilone/screen-resolution-extra/main
[19:11]  * tseliot > dinner. Bbl
[19:45] <tormod> how does the X server actually choose the driver nowadays?
[20:27] <tormod> re bug #261977
[20:27] <ubottu> Launchpad bug 261977 in xorg-server "nv is chosen even if it doesn't support the card" [Undecided,Confirmed] https://launchpad.net/bugs/261977
[20:34] <jcristau> tormod: it's all there in hw/xfree86/common/xf86AutoConfig.c 
[20:34] <tjaalton> are the *.ids used anymore?
[20:35] <jcristau> yes
[20:35] <jcristau> but if that fails, it goes to videoPtrToDriverName()
[20:35] <tjaalton> ah
[20:35] <jcristau> and, case 0x10de: case 0x12d2:   return "nv";
[20:38] <jcristau> i think it's saner on master
[20:38] <jcristau> and it'll fall back to vesa
[20:39] <tjaalton> there should be a similar bug about nv (ie. dupe)
[20:58] <bryce> tjaalton: btw I filed the outstanding sync requests.  having some troubles updating the versions page due to fdo timeouts
[21:40] <tjaalton> bryce: oh, that's why it looks so funny?-)
[21:40] <bryce> yeah
[21:41] <bryce> tjaalton: btw, do you have any thoughts on what to do about 207409?
[21:42] <bryce> tjaalton: personally I suspect most of the cases they're having an X problem, and they remember that once long ago (pre-autoconfigure) running dpkg-reconfigure fixed something, and they want their current issue to be fixed that way again, only it's not clear that dpkg-reconfigure would work any better
[21:43] <bryce> also the whining is not winning any points with me
[21:43] <tjaalton> bug 207409
[21:43] <ubottu> Launchpad bug 207409 in xorg "There is no user interactive menu method to configure xorg.conf from a shell" [Wishlist,Incomplete] https://launchpad.net/bugs/207409
[21:44] <tjaalton> sigh..
[21:44] <bryce> yeah
[21:44] <tjaalton> wontfi
[21:44] <tjaalton> x
[21:45] <bryce> would the idea in comment #46 even be doable?
[21:45] <bryce> I imagine the postinst script is too wedded to debconf to be used separately like that
[21:47] <tjaalton> it doesn't have to use debconf.. they are free to write an app of their own
[21:47] <tjaalton> which would generate the xorg.conf
[21:48] <tjaalton> curses based or whatever !gnome
[21:49] <bryce> so "You're welcome to try putting the postfix script into a new package separate from xorg that uses curses or whatever to generate an xorg.conf for you.  I think you overestimate the likelihood that it'd actually be able to fix these problems, but I could be wrong.  In any case, since it'll be a new package, it's no longer an xorg issue.  Closing." --> WONTFIX ?
[21:50] <jcristau> bryce: sounds good
[21:51] <tjaalton> yeah \o/
[21:51] <tjaalton> case closeed
[21:51] <tjaalton> -e
[21:51] <bryce> alrighty.
[21:51] <bryce> deed is done.
[21:52] <bryce> next dirty deed on the todo list... killing displayconfig-gtk...
[21:55] <tjaalton> dirty deeds done dirt cheap ;)
[22:48] <tormod> thanks all for the info above
[22:50] <tormod> I remember vaguely some discussion on xorg ML about a commit that was reversed because(?) it would "help" third-party drivers like nvidia. It was speculated that whore distributions would cherry-pick it anyway. Is that done?
[22:51] <jcristau> tormod: it's not about helping nvidia
[22:51] <tormod> jcristau: ok I probably remember wrong then
[22:52] <jcristau> it's about whether x.org supports the nvidia driver. which they don't.
[22:52] <tjaalton> yep..
[22:53] <tormod> I understand Debian and Ubuntu do then. But this was maybe in 1.6?
[22:53] <tormod> anyway back to that bug, what should be done?
[22:54] <jcristau> i'm pretty sure debian doesn't support the nvidia driver
[22:54] <jcristau> at least i'm not going to ship that patch
[22:54] <tjaalton> ubuntu tries to..
[22:54] <tjaalton> which, looking at the bug count, isn't doing that great
[22:54] <jcristau> tjaalton: i think they're wrong, but it's none of my business, so.. :)
[22:55] <tormod> should nvidia ship .ids files then?
[22:55] <tjaalton> tormod: no
[22:57]  * tormod tries to look at that file referenced above, but freedesktop.org seems broken
[22:57] <tjaalton> jcristau: yeah, I'm thinking that applying that patch could generate some bad press
[22:57] <jcristau> tjaalton: less than reverting to 1.4 for intrepid because of no fglrx ;)
[22:58] <tjaalton> jcristau: hehe, true
[22:59] <tjaalton> mesa merge done
[22:59] <tjaalton> and pushed
[23:00] <bryce> yay!  you rock
[23:01] <tjaalton> pitti made a couple of uploads a while back, and I added those changes too (mesa now in git, since changes keep piling up)
[23:01] <tjaalton> clearly faster to merge with a VCS
[23:24] <tjaalton> jcristau: dpkg-source complains about the mesa tarball.. files that are symlinks in the git tree and nonexistent in the tarball
[23:25] <tjaalton> {r200,r300}/radeon_screen.c mainly
[23:25] <jcristau> tjaalton: hmm?
[23:26] <jcristau> no such files here
[23:26] <tjaalton> jcristau: in git?
[23:26] <jcristau> sounds like your git tree isn't clean
[23:27] <jcristau> git clean -dnx?
[23:27] <tjaalton> right, that would remove those
[23:27] <jcristau> git clean -dfx to actually do it
[23:29] <tjaalton> yep, works
[23:34] <tjaalton> maybe I'll be able to upload the new synaptics tomorrow.. and start fixing the evdev s/model/rules/ mess
[23:35] <tjaalton> though that means touching many packages
[23:35] <bryce> btw, FF is in 1.5 hrs
[23:36] <tjaalton> oh, I thought there were plenty of hours left :)
[23:38] <bryce> apparently slangasek is selecting 00:00 UTC instead of 23:59 UTC as "Aug 28th"
[23:38] <tjaalton> well, that just means I have to upload synaptics now :)
[23:39] <tjaalton> the rest are just patches
[23:39] <bryce> tjaalton: lemme know if we need FFe's for any particulars, I can ask at the meeting
[23:39] <bryce> (or feel free to ask yourself on #ubuntu-x when they get to me)
[23:39] <bryce> er
[23:39] <tjaalton> -meeting
[23:39] <bryce> s/-x/-meeting/ :-P
[23:39] <tjaalton> oh it's underway
[23:40] <bryce> yeah they're going in reverse-alpha by screenname so I should be after calc
[23:49] <tormod> for syncs, is it enough to have archive-admins subscribed before FF?
[23:50] <bryce> tormod: I *think* so
[23:50] <tormod> bryce, can you do something for bug #192772, it's assigned to rtg but he doesn't seem to be reliable
[23:50] <ubottu> Launchpad bug 192772 in linux-wlan-ng "please merge linux-wlan-ng 0.2.9+dfsg-1 from Debian main unstable" [Low,Fix committed] https://launchpad.net/bugs/192772
[23:51] <tormod> if you can subscribe archive-admins it should be fine. if he ever gets to my patch later that's fine.
[23:54] <bryce> tormod: hm, I'd be more comfortable if you talked to slangasek directly.  Or if you're certain you just want a sync, file a new bug requesting a sync and sub ubuntu-archive to that
[23:54] <tormod> bryce: I don't think I can sub ubuntu-archive, a dev must do it
[23:55] <tormod> ok I'll give slangasek a try
[23:57] <bryce> if you file a new bug for the sync request, or add a comment at the end of the bug that clearly states a sync request, I'd be happy to sub them
[23:57] <tormod> thanks, I'll do that if I don't hear from slangasek on #ubuntu-devel