| bryce | james_w: btw I've finished the gnome-desktop update, I just need to test it and then will upload it, perhaps tonight | 03:58 |
|---|---|---|
| bryce | tests ok; gnome-desktop uploaded | 05:58 |
| bryce | hmm, looks like seb128 already did gnome-settings-daemon | 06:16 |
| james_w | bryce: great, I'll test them in a little while. | 06:46 |
| ubotu | New bug: #214439 in xserver-xorg-video-tdfx (main) "Quake engine games freeze if video settings changed" [Undecided,New] https://launchpad.net/bugs/214439 | 07:11 |
| bryce | tdfx wtf? | 07:16 |
| bryce | 3dfx Banshee... interesting | 07:18 |
| ubotu | New bug: #214442 in xserver-xorg-video-ati (main) "Time out error with r128 and some games" [Undecided,New] https://launchpad.net/bugs/214442 | 07:20 |
| james_w | bryce: what would you like me to work on today? | 07:21 |
| james_w | I can test the uploads, and also seb uploaded g-c-c, so I think the patches need updating there again. | 07:22 |
| bryce | james_w: how far along are you with the gnome-control-center patches? Getting that uploaded is probably the next priority | 07:22 |
| james_w | they were pretty good I think, I'll update them and do some more testing, and then talk to seb about them. | 07:23 |
| bryce | presently, I'm working on a new patch to g-d to add a mess of null pointer checks. Seems like many of our bugs have been due to null pointers from g-d | 07:23 |
| bryce | so yeah, getting all the patches in g-c-c building properly, and getting that package would be the main goal today. | 07:25 |
| james_w | ok, sure | 07:25 |
| bryce | Looking over our bugs and that people are reporting problems still even after seb's last set of uploads (which I thought would fix those bugs), the new g-c-c changes unfortunately aren't going to solve that | 07:26 |
| bryce | so priority #2 after that is sorting out why 199960 and 210226 are still happening | 07:26 |
| bryce | the patch I'm doing may help with 210226 but it may just expose the null pointer at a higher level (which would be a good thing, but just one step) | 07:27 |
| bryce | in 199960, the reporters are getting pretty ornery and fussy, but I'm hopeful the g-s-d upload sorted it out - but not much word since the 3rd | 07:29 |
| james_w | 199960 is nice and easy to reproduce, which helps. | 07:30 |
| james_w | any idea how to reproduce 210226? | 07:30 |
| bryce | are you able to reproduce 199960? I've not been able to | 07:31 |
| bryce | I haven't reproduced 210226, but the backtraces are pretty clear | 07:31 |
| bryce | there were a bunch of unrelated issues lumped into 199960; I think the only remaining active was when running with Xgl, however I *think* the Apr 6th g-d/g-s-d uploads might have addressed that | 07:33 |
| james_w | I did "aptitude install xserver-xgl" and gnome-settings-daemon didn't start on the next login, so I assumed it was the bug, maybe it wasn't | 07:33 |
| bryce | if not, then maybe we need an explicit check for Xgl in g-s-d (and probably g-c-c) like the code I posted in comment 57 | 07:33 |
| james_w | I tested on Monday | 07:34 |
| james_w | I'll test again today. | 07:35 |
| james_w | bryce: have you sent any of the other patches that we are carrying upstream? | 07:53 |
| bryce | my plan has been to send them once we verified they built against the latest code | 07:56 |
| bryce | on my list so far are these three for gnome-desktop: | 07:56 |
| bryce | 102_gd-xrandr-null-pointer-check.patch | 07:56 |
| bryce | 103_gd-xrandr-xerror-check.patch | 07:56 |
| bryce | 104_gd-randr-revert-support.patch | 07:56 |
| bryce | I'm not sure if I should send in the g-s-d patch; I'm not sure checking for xrandr versions is really that necessary. ubuntu and fedora are both running xrandr 1.2 servers, so... might be useful in general, but I don't know | 07:58 |
| bryce | I want to go through the g-c-c patches once your work's uploaded, and send in a few of those. I think half or so will be relevant for them | 07:58 |
| james_w | yeah, that's what it looks like to me. | 07:59 |
| james_w | the revert dialog requires 104_gd-randr-revert-support.patch? | 08:00 |
| bryce | yes | 08:00 |
| james_w | ok, thanks. | 08:00 |
| bryce | I'd asked ssp previously about that but never got a response, and am guessing he won't be so interested, but who knows. | 08:01 |
| james_w | I'm going back to bed for a short nap, but I'll start with g-c-c after that. | 08:01 |
| bryce | ok cool | 08:01 |
| bryce | james_w: I'll be cc'ing the gnomecc list (it's pretty low traffic if you want to subscribe during this project) | 08:06 |
| seb128 | hello | 08:12 |
| bryce | hi | 08:12 |
| seb128 | bryce: hey | 08:12 |
| seb128 | bryce: they changed all that in gnome-desktop since my patch update on monday or did you list changes which we already had in your changelog? | 08:13 |
| bryce | I listed changes we already had | 08:14 |
| seb128 | ah ok, that was confusing | 08:14 |
| seb128 | I think you didn't see my update and redid the work or something | 08:14 |
| seb128 | s/think/though | 08:14 |
| bryce | actually that's the case :-/ | 08:15 |
| seb128 | :-( | 08:15 |
| seb128 | but we dicussed it on IRC some days ago? | 08:15 |
| bryce | but I noticed right after uploading and see that we had almost exactly the same patch | 08:15 |
| bryce | I thought you had said you didn't have time to work on it, so I had it on my todo list | 08:15 |
| seb128 | hum | 08:15 |
| seb128 | then I sent this mail to colin and you | 08:15 |
| seb128 | james_w joined the chan | 08:16 |
| seb128 | and we discussed the changes | 08:16 |
| seb128 | you even asked me when I did take the snapshot | 08:16 |
| seb128 | I copied the redhat viewcvs from saturday and you said that was newer than your snapshot | 08:16 |
| seb128 | no? | 08:16 |
| bryce | I assumed you took the snapshot and handed it over to james_w | 08:16 |
| bryce | so I asked james_w before I started if he'd had a chance to work on it, and he said no, so I said I had some time and would help by doing that bit | 08:17 |
| seb128 | ok, I though I had been clear when I asked you guys to test the new hardy versions | 08:17 |
| bryce | I thought you meant the gnome changes in general | 08:17 |
| seb128 | hum, k | 08:17 |
| seb128 | so to be clear I updated this one | 08:17 |
| seb128 | and the gnome-settings-daemon one too | 08:17 |
| seb128 | there was just the gnome-control-center one to update, that's what I explain on the chan to james_w | 08:18 |
| seb128 | I though you read that too, sorry about the confusion | 08:18 |
| bryce | no prob, actually the patches for gnome-desktop applied cleanly without issue, so the time was mostly just reviewing all the changes, which I planned to do regardless | 08:19 |
| seb128 | alright | 08:19 |
| seb128 | btw they broke the ABI, dunno if you noticed | 08:19 |
| seb128 | I had to add a breaks in the package on monday due to that | 08:20 |
| bryce | yeah I ran into that; confused me a bit | 08:20 |
| bryce | can you tell me more about it? | 08:20 |
| seb128 | ok, so the only change in your update is the unstable define renamed apparently | 08:20 |
| seb128 | so no breakage in this one | 08:21 |
| seb128 | good ;-) | 08:21 |
| bryce | right; in fact my change just adds another define test we can opt to start using if we wish | 08:22 |
| bryce | since "ONLY_IN_FEDORA" clearly is not 100% true ;-) | 08:22 |
| seb128 | right ;-) | 08:22 |
| bryce | but in general it probably doesn't matter to anyone, unless they're browsing code | 08:22 |
| seb128 | btw why did you change the configure.in? | 08:23 |
| bryce | I didn't change that, but I wonder if it's a difference between the fedora rpm patch, and what I took from ssp? | 08:23 |
| seb128 | -#GNOME_COMMON_INIT | 08:23 |
| seb128 | +GNOME_COMMON_INIT | 08:24 |
| seb128 | etc | 08:24 |
| seb128 | they likely have extra debug macros used in git | 08:24 |
| seb128 | that they don't use for the packaging | 08:24 |
| seb128 | you reenabled those | 08:24 |
| bryce | yeah, I noticed that too but don't know what it does. I can revert that part if you'd like | 08:24 |
| seb128 | if that builds that's alright | 08:24 |
| bryce | it builds and I tested it and seems to work properly | 08:24 |
| seb128 | alright, good | 08:25 |
| seb128 | let's wait for james_w gnome-control-center patch update now | 08:25 |
| seb128 | I'm wondering if somebody tried the current version using xgl | 08:25 |
| seb128 | users tend to complain loud when things are broken | 08:25 |
| bryce | yeah I'm wondering that too | 08:26 |
| seb128 | but they don't bother adding a comment when things are fixed usually | 08:26 |
| bryce | james_w said he can recreate the xgl issue fairly easy and will test it | 08:26 |
| bryce | you know I get that with most X bugs too ;-) | 08:26 |
| seb128 | :-) | 08:26 |
| ubotu | New bug: #214470 in xorg (main) "gdm screen uses virtual screen size instead of actual" [Undecided,New] https://launchpad.net/bugs/214470 | 08:40 |
| tjaalton | bryce: isn't bug 205979 a dupe of 184651? | 08:51 |
| ubotu | Launchpad bug 205979 in xorg-server "xserver crash on exit in CloseDownDevices and SrvXkbFreeGeomRows" [Unknown,Confirmed] https://launchpad.net/bugs/205979 | 08:51 |
| bryce | tjaalton: hmm let me look | 08:57 |
| bryce | darn, I nearly figured that one out myself. guess I'm duplicating a lot of work lately! ;-) | 08:59 |
| tjaalton | heh :) | 08:59 |
| tjaalton | I've now got six patches for xorg-server, mostly from upstream and one that defaults to intel instead of i810 | 09:00 |
| bryce | hmm, their patch doesn't match the direction I was going, but I bet it just solves it from a different (likely better) direction | 09:01 |
| bryce | hmm, and looking at the backtraces and steps to reproduce, they're *slightly* different | 09:03 |
| bryce | I'm not 100% sure that the patch for 184651 will also solve 205979, but I think it's possible and it wouldn't surprise me at all | 09:04 |
| tjaalton | maybe ask again after this has been uploaded and then mark as dupe if it's fixed (and close the upstream report) | 09:05 |
| ubotu | New bug: #214484 in xorg (main) "Standard NV driver doesn't work with G70 cards at 2560x1600" [Undecided,New] https://launchpad.net/bugs/214484 | 09:26 |
| tjaalton | hmmh, I had some mesa patches to add, but now I can't find any.. "assigned to" ftw | 09:29 |
| tjaalton | lunch -> | 09:30 |
| tjaalton | bryce: if you have anything you want me to look at, just ask | 09:30 |
| bryce | I don't have any patches for the xserver at the moment; I've been uploading other things directly as I run across them | 09:31 |
| bryce | bugwise, the top priorities right now are the 4 x-related bugs at https://bugs.launchpad.net/ubuntu/+bugs?field.milestone%3Alist=829 | 09:32 |
| seb128 | did you guys made some video driver changes which could have broken the dpi values detected on some cards? | 09:32 |
| bryce | I uploaded some patches for -intel the past few days, including one that updates a bunch of quirks, a few of which could correct some dpi issues | 09:34 |
| bryce | other than -intel, I've not updated any other drivers | 09:34 |
| seb128 | ok | 09:34 |
| seb128 | https://bugs.launchpad.net/ubuntu/+source/evince/+bug/213745 | 09:35 |
| ubotu | Launchpad bug 213745 in evince "PDF pages appear extremely small in evince" [Medium,Incomplete] | 09:35 |
| seb128 | upstream thinks it could be a dpi detection issue, I've asked for xdpyinfo logs and what card those users are using | 09:35 |
| * bryce nods | 09:36 | |
| bryce | for font dpi issues we also need to see their EDID, so it would be good to have their Xorg.0.log's | 09:37 |
| seb128 | ok | 09:37 |
| seb128 | asked that on the b ug | 09:38 |
| seb128 | bug | 09:38 |
| bryce | one thing to look for in EDID is the monitor's physical dimensions, which is the thing that messes up dpi calculations | 09:38 |
| bryce | anyway, off to bed for me. night | 09:38 |
| seb128 | 'night bryce | 09:38 |
| seb128 | bryce: ok, those guys seem to all have intel cards | 09:59 |
| seb128 | bryce: so I would say you broke the intel driver :-) | 09:59 |
| ubotu | New bug: #213745 in xserver-xorg-video-intel (main) "PDF pages appear extremely small in evince" [High,Confirmed] https://launchpad.net/bugs/213745 | 10:11 |
| ubotu | New bug: #214499 in linux-restricted-modules-2.6.24 (restricted) "Recompiled Ubuntu kernel - nvidia driver does not load (comm: modprobe Not tainted)" [Undecided,New] https://launchpad.net/bugs/214499 | 10:11 |
| ubotu | New bug: #214501 in xkeyboard-config (main) "no dead keys in hardy" [Undecided,New] https://launchpad.net/bugs/214501 | 10:16 |
| Q-FUNK | on bug #214119 I heard that before and this was already before the libpciaccess merge. | 10:19 |
| ubotu | Launchpad bug 214119 in xserver-xorg-video-amd "[HARDY] Koolu W.E. (ION A603) does not detect higher resolution than 800x600" [High,Triaged] https://launchpad.net/bugs/214119 | 10:19 |
| Q-FUNK | as far as I can tell, this is yet another case of a buggy BIOS that will require workarounds in x86emu. The same driver works fine if compiled against an older X and using an xorg.conf | 10:20 |
| ubotu | New bug: #209759 in firefox (universe) "firefox does not display scaled jpegs (dup-of: 182038)" [Undecided,Confirmed] https://launchpad.net/bugs/209759 | 10:32 |
| ubotu | New bug: #214513 in xserver-xorg-driver-i810 "mouse i810" [Undecided,New] https://launchpad.net/bugs/214513 | 10:56 |
| ubotu | New bug: #214517 in xserver-xorg-video-intel (main) "supend/resume broken with latest intel driver & kernel 2.6.24-15 " [Undecided,New] https://launchpad.net/bugs/214517 | 11:06 |
| ubotu | New bug: #214527 in evince (main) "Evince rendering very small text (dup-of: 213745)" [Low,Invalid] https://launchpad.net/bugs/214527 | 12:10 |
| ubotu | New bug: #208483 in ubiquity (main) "installer crashes in keyboard layout selection (dup-of: 184651)" [Undecided,New] https://launchpad.net/bugs/208483 | 12:16 |
| james_w | seb128: hi. I've updated the g-c-c patch: http://jameswestby.net/scratch/g-c-c.diff | 12:19 |
| seb128 | james_w: excellent! | 12:19 |
| james_w | it's now not showing any name for my monitor, I'll look in to why. | 12:20 |
| james_w | I also didn't change the #define to be the new one bryce added support for, so it still says FEDORA. | 12:21 |
| ubotu | New bug: #212373 in firefox-3.0 (main) "PNG error (dup-of: 182038)" [Undecided,Incomplete] https://launchpad.net/bugs/212373 | 12:22 |
| seb128 | james_w: ok, the applet runs, that broken the "cancel the changes" action though, and I've no monitor description written either | 12:42 |
| seb128 | s/broken/broke | 12:42 |
| james_w | the cancel button in the timer window? | 12:43 |
| seb128 | james_w: should I upload or do you want to give a try at fixing at least the cancellation thing before? | 12:43 |
| seb128 | yes | 12:43 |
| seb128 | or using esc | 12:43 |
| james_w | it worked here. | 12:43 |
| james_w | do you get any output on the terminal? | 12:43 |
| seb128 | james_w: that's working now, go figure | 12:46 |
| seb128 | xrand1.2 is still quite broken though | 12:46 |
| seb128 | I thought it would work alright on intel, but it doesn't :-( | 12:46 |
| seb128 | when switching to a lower resolution and back the screen has the small resolution area displayed correctly and the borders corrupted | 12:47 |
| seb128 | mvo: ^ compiz issue? | 12:48 |
| seb128 | compiz seems to thing the corrupted border is the limit of the workspace too | 12:49 |
| seb128 | I can move the xorg cursor there and use things under it correctly | 12:49 |
| seb128 | but when doing a dialog dnd for example it stops and switch workspaces | 12:49 |
| mvo | seb128: I have a look once I finished debugging this bug #213566 issue | 12:51 |
| ubotu | Launchpad bug 213566 in xkeyboard-config "dapper->hardy missing files on upgrade" [High,In progress] https://launchpad.net/bugs/213566 | 12:52 |
| seb128 | ok | 12:52 |
| mvo | its a nasty one | 12:52 |
| seb128 | james_w: ok, that seems already to me, thanks a lot for the work on it, I'll upload | 12:52 |
| seb128 | james_w: btw do you have an opinion on whether we should use "Refresh Rate" or "Refresh rate"? | 12:52 |
| james_w | if you want to hang on a minute I think I might have fixed the name thing. | 12:53 |
| seb128 | the upstream capplet is using "Refresh rate" | 12:53 |
| seb128 | james_w: sure | 12:53 |
| james_w | I though upstream was using "Rate", and we patched it to use "rate", which I just reverted | 12:53 |
| james_w | bryce said that the usability guy (is that mpt?) said that we should use capital letters for labels, and all of the rest do. | 12:54 |
| seb128 | james_w: if you do patch edition could ou remove the extra g_print? I don't think we make any use of those informations anyway and we should have only errors printing in .xsession-errors | 12:54 |
| james_w | sure, you want me to remove them all? | 12:54 |
| seb128 | just the non error ones | 12:54 |
| seb128 | we should still display failures | 12:54 |
| james_w | should I move them to something that would show up in .xsession-errors for debugging? | 12:54 |
| seb128 | they do show up there already | 12:55 |
| seb128 | that's why I want to clean those ;-) | 12:55 |
| seb128 | at the moment it prints thing like | 12:55 |
| seb128 | CRTC 49 Timestamp: 3792732 | 12:55 |
| seb128 | Output 4e Timestamp: 3792732 | 12:55 |
| seb128 | applying configuration. Clone: yes | 12:55 |
| seb128 | etc | 12:55 |
| seb128 | those should not be printed I think | 12:56 |
| seb128 | that's just a detail though | 12:56 |
| james_w | yeah, I agree. | 12:56 |
| seb128 | I want to clean .xsession-errors for hardy but too much to do | 12:56 |
| seb128 | I'll do a mini goal and try to get that for 8.04.1 | 12:56 |
| seb128 | do a mini goal = write a wiki page or something or tag bugs and try to get contributors helping to clean those | 12:57 |
| james_w | I've got it showing "Cloned Output" again, so it's wrong, but less wrong. | 12:57 |
| seb128 | did you had this label already using the hardy version? | 12:57 |
| james_w | there's something wrong with the clone checkbox, so I'll have a quick look to see if I can debug that. | 12:57 |
| seb128 | ok | 12:58 |
| james_w | yes, it was wrong in the previous versions as well. | 12:58 |
| seb128 | ok, so at least that's not a regression | 12:58 |
| seb128 | brb, need to restart xorg to get an usuable workspace again | 12:58 |
| james_w | I think it's a problem with gnome-desktop patch though, so it shouldn't stop us uploading this. | 12:58 |
| seb128 | re | 13:00 |
| james_w | Is there something better to use than g_print for real error messages? | 13:03 |
| james_w | aside from a popup of course? | 13:03 |
| seb128 | g_warning and g_error | 13:04 |
| seb128 | g_error call abort though so it's only to use on real errors | 13:05 |
| seb128 | and g_warning is for error worth reporting but which should stop the program | 13:05 |
| james_w | thanks | 13:06 |
| seb128 | and also g_messages for normal messages | 13:08 |
| seb128 | what is nice is that you can change the log handler so make those go in a debug log rather than on std* | 13:08 |
| seb128 | oh, that is not a cool bug | 13:29 |
| seb128 | using xrand1.2 breaks the dpi informations on intel | 13:30 |
| seb128 | which means once you have used the new capplet you will have broken dpis and the evince issue we got several bugs about | 13:30 |
| tjaalton | ouch | 13:30 |
| seb128 | that breaks the web browse fonts too | 13:35 |
| tjaalton | and that was due to the latest change? | 13:36 |
| seb128 | I've no idea, I didn't notice the issue before | 13:39 |
| tjaalton | no, seems to be an upstream issue | 13:39 |
| seb128 | I'm going to downgrade the intel driver now | 13:39 |
| tjaalton | ok, the changes seem to have added only some quirks | 13:40 |
| seb128 | and people started reporting that some days ago | 13:40 |
| seb128 | right | 13:40 |
| seb128 | https://launchpad.net/bugs/178558 suggests the issue is not new | 13:40 |
| ubotu | Launchpad bug 178558 in xulrunner-1.9 "Firefox 3.0 makes everything annoyingly huge" [High,Fix released] | 13:40 |
| seb128 | see https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/178558/comments/50 | 13:40 |
| tjaalton | yeah | 13:41 |
| seb128 | I think evince was not sensible to wrong dpi before or something | 13:41 |
| seb128 | so we didn't get lot of bugs about the issue | 13:41 |
| seb128 | or we got firefox font issues bugs which are not easy to track | 13:42 |
| jcristau | maybe with X log, output of xrandr and xdpyinfo it would be possible to do something. random screenshots, not so much | 13:43 |
| seb128 | jcristau: I can give you any information you need | 13:43 |
| seb128 | jcristau: starting xorg xpydinfo shows a correct 120 dpi number | 13:43 |
| seb128 | using xrand1.2 to set the same screen resolution I'm already using the xdpyinfo number goes to 1x1 | 13:44 |
| seb128 | that's a dell D630 laptop using a intel 965 video card | 13:44 |
| seb128 | using the current intel driver | 13:44 |
| tjaalton | heh, mine dropped from 106x105 to 87x85 | 13:45 |
| jcristau | do you X log, preferrably with the ModeDebug option turned on? | 13:45 |
| jcristau | meh | 13:45 |
| jcristau | s/do you/& have an/ | 13:46 |
| seb128 | jcristau: easy enough to get, where do I turn this option? | 13:46 |
| jcristau | in the Device section | 13:46 |
| seb128 | jcristau: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/213745 has several Xorg.0.log | 13:46 |
| ubotu | Launchpad bug 213745 in xserver-xorg-video-intel "PDF pages appear extremely small in evince" [High,Confirmed] | 13:46 |
| seb128 | jcristau: but I don't think they are using the debug mode | 13:46 |
| seb128 | I'll try in a bit, I've things open that I don't want to close right now ;-) | 13:47 |
| jcristau | (might be a good idea to set ModeDebug by default) | 13:47 |
| jcristau | ok | 13:47 |
| seb128 | let me know if those logs are useful already | 13:47 |
| jcristau | eww | 13:48 |
| jcristau | dimensions: 1280x800 pixels (40959x50175 millimeters) | 13:48 |
| jcristau | resolution: 1x0 dots per inch | 13:48 |
| seb128 | yeah, that's what you get after using xrandr1.2 | 13:49 |
| seb128 | dimensions: 1440x900 pixels (37887x31871 millimeters) | 13:49 |
| seb128 | resolution: 1x1 dots per inch | 13:49 |
| seb128 | that's the value on my laptop | 13:49 |
| jcristau | (II) intel(0): Printing DDC gathered Modelines: | 13:49 |
| jcristau | (II) intel(0): Modeline "1280x800"x0.0 65.31 1280 1296 1328 1344 800 801 804 810 -hsync -vsync (48.6 kHz) | 13:49 |
| seb128 | it was 120x120 before using xrandr | 13:50 |
| jcristau | that 0.0 is broken | 13:50 |
| seb128 | (II) intel(0): Printing DDC gathered Modelines: | 13:50 |
| seb128 | (II) intel(0): Modeline "1440x900"x0.0 108.50 1440 1520 1600 1952 900 903 909 926 -hsync -vsync (55.6 kHz) | 13:50 |
| seb128 | (II) intel(0): Modeline "1440x900"x0.0 108.50 1440 1520 1600 1952 900 903 909 926 -hsync -vsync (55.6 kHz) | 13:50 |
| seb128 | I've those | 13:50 |
| jcristau | seb128: what exact command? xrandr --output 'foo' --mode 1440x900? | 13:50 |
| seb128 | jcristau: I'm using this new xrandr1.2 capplet from redhat that bryce backported | 13:51 |
| seb128 | is the xrandr command line using 1.2 too? | 13:51 |
| jcristau | hrm, actually it's "1024x768"x0.0 here too | 13:51 |
| tjaalton | same here | 13:51 |
| jcristau | yes | 13:51 |
| jcristau | so that's not it | 13:51 |
| jcristau | modedebug would probably help | 13:51 |
| seb128 | ok, sec, editing xorg.conf and restarting | 13:53 |
| tjaalton | was it a boolean? | 13:54 |
| jcristau | do you have an url to the capplet source? | 13:54 |
| jcristau | tjaalton: yes | 13:54 |
| seb128 | jcristau: the patches are on http://people.ubuntu.com/~bryce/Testing/XrandrGui/ | 13:55 |
| seb128 | jcristau: http://www.gnome.org/~ssp/randr/ is the upstream thing, I think that's using git | 13:56 |
| seb128 | http://www.gnome.org/~ssp/randr/.git | 13:57 |
| ubotu | New bug: #214561 in evince (main) "Evince shows pdfs file with a very small size (dup-of: 213745)" [Low,Invalid] https://launchpad.net/bugs/214561 | 13:57 |
| ubotu | New bug: #214581 in nvidia-settings (universe) "[hardy] nvidia-settings window is displayed way too small" [Undecided,New] https://launchpad.net/bugs/214581 | 14:00 |
| seb128 | jcristau: http://people.ubuntu.com/~seb128/Xorg.0.log | 14:02 |
| jcristau | so at startup X sets your screen size to 304 x 190 | 14:06 |
| jcristau | (mm) | 14:06 |
| jcristau | as reported by your monitor | 14:06 |
| jcristau | and then something goes crazy | 14:07 |
| seb128 | as said if I don't use this capplet the xdpyinfo settings are correct | 14:07 |
| seb128 | so it goes wrong when using the xrandr calls | 14:07 |
| seb128 | the code which applies the settings seems to be in the gnome-desktop changes | 14:08 |
| seb128 | randrwrap.c | 14:08 |
| seb128 | it calls XRRSetScreenSize() | 14:08 |
| mvo | tjaalton: if you maintain xkeyboard-config in git for ubuntu you may want to sync with my latest uplaod | 14:09 |
| seb128 | mvo: so what was the bug? | 14:09 |
| tjaalton | mvo: I noticed your latest comment.. maybe this bug went "unnoticed" when people upgraded to edgy.. | 14:09 |
| mvo | seb128: multiple ones, but the killer was wrong order of unpack and replacing files in /etc with symlinks that confused dpkg | 14:10 |
| tjaalton | mvo: and it's not maintained in git, unfortunately | 14:10 |
| mvo | ok | 14:10 |
| tjaalton | it's not maintained by XSF in Debian :) | 14:10 |
| mvo | tjaalton: it pretty servere, if it went unoticed than our QA back then was pretty bad | 14:10 |
| mvo | tjaalton: it kills the keyboard for anyone using the gnome-keyboard preferences | 14:11 |
| tjaalton | ugh | 14:11 |
| mvo | it depends on the unpack ordering for it to trigger, maybe we were just luck on dapper->edgy | 14:11 |
| mvo | the issue that xkeyboard-config is in universe (and should be in main) is still open though | 14:12 |
| tjaalton | could be yes | 14:12 |
| * mvo goes to the seeds | 14:12 | |
| mvo | that was a bugger of a bug, happy to have nailed it down (works in my upgrade test environement, lts see if it works in the wild as well :) | 14:13 |
| jcristau | width_mm = (width * 96.0) * 25.4; | 14:15 |
| jcristau | height_mm = (height * 96.0) * 25.4; | 14:15 |
| jcristau | 14:15 | |
| jcristau | rw_screen_set_size (assign->screen, width, height, width_mm, height_mm); | 14:15 |
| jcristau | so it's supposed to set dpi to 96 | 14:15 |
| jcristau | except, maybe not | 14:15 |
| tjaalton | gotta run, bbl -> | 14:17 |
| jcristau | hmm, shouldn't that be (width / 96.0) * 25.4? | 14:17 |
| seb128 | hum, yeah | 14:18 |
| seb128 | trying | 14:19 |
| jcristau | seems likely to fuck things up, setting dpi to 1/96 instead of 96 :) | 14:21 |
| seb128 | brbr | 14:23 |
| seb128 | trying that change | 14:23 |
| seb128 | jcristau: ok, nice catch, much better now ;-) | 14:27 |
| seb128 | note for next time, don't blame xorg too quickly ;-) | 14:27 |
| jcristau | cool | 14:27 |
| jcristau | blaming red hat is a much better strategy! ;) | 14:28 |
| seb128 | yeah ;-) | 14:28 |
| ubotu | New bug: #214592 in xserver-xorg-video-intel (main) "[Hardy] OpenGL renders Wrong " [Undecided,New] https://launchpad.net/bugs/214592 | 14:31 |
| james_w | seb128: the clone checkbox isn't showing up as 'glade_xml_get_widget (xml, "clone_checkbox");' is returning NULL | 14:34 |
| james_w | there is '<widget class="GtkCheckButton" id="clone_checkbox">' in the glade file. | 14:34 |
| james_w | do you know enough about glade to offer any suggestions? | 14:34 |
| seb128 | james_w: hum, looking | 14:39 |
| mvo | james_w: was glade_xml_new run with a different root widget? | 14:40 |
| mvo | james_w: so that clone_checkbox is not a child of whatever root was set to? (that might be a possible explaination for this behavior) | 14:41 |
| james_w | glade_xml_new (GLADE_FILE, NULL, NULL); | 14:42 |
| seb128 | james_w: where is this clone widget? | 14:43 |
| seb128 | james_w: is that the Mirror Screen one? | 14:44 |
| james_w | I'm seeing it at line 100 of "capplets/display/display-capplet.glade" | 14:44 |
| james_w | seb128: yes | 14:44 |
| seb128 | it's displayed correctly for me | 14:44 |
| james_w | hmm, odd. | 14:45 |
| james_w | Do you have multiple screens? | 14:45 |
| seb128 | no | 14:46 |
| seb128 | I'm using a laptop right now | 14:46 |
| seb128 | and it's not pluged to any monitor or dock | 14:46 |
| james_w | and this is with the latest changes I made? | 14:46 |
| seb128 | using the debdiff you sent me some hours ago | 14:47 |
| james_w | odd. | 14:47 |
| seb128 | james_w: http://people.ubuntu.com/~seb128/xrandr.png | 14:47 |
| james_w | I'll fix up what I have currently and pass that to you. | 14:48 |
| seb128 | ok, thanks | 14:48 |
| james_w | I don't have the checkbox, or the "Detect displays" button. | 14:48 |
| seb128 | did you install the glade? | 14:50 |
| seb128 | or do you run from your source? | 14:50 |
| james_w | yeah, I'm just wondering whether it's not getting installed. | 14:50 |
| seb128 | try to strace -e open gnome-display-properties 2>&1 | grep glade | 14:50 |
| seb128 | then glade this one | 14:50 |
| seb128 | and see if it's correct | 14:50 |
| james_w | yeah, it's not in the .deb and the one on my system is old. | 14:52 |
| james_w | thanks! | 14:52 |
| seb128 | you are welcome | 14:52 |
| seb128 | weird though | 14:53 |
| seb128 | the debdiff you sent me works correctly and the glade is installed there | 14:53 |
| james_w | ah, it's in capplets-data | 14:55 |
| seb128 | yes | 14:57 |
| seb128 | I usually sudo dpkg -i *.deb ;-) | 14:57 |
| james_w | yeah, I'm using two machines, and I was too lazy to copy them all across. | 14:58 |
| james_w | It all seems to work nicely though. | 14:58 |
| seb128 | cool | 14:59 |
| james_w | seb128: http://jameswestby.net/scratch/g-c-c.diff updated if you want to grab it again and do your thing | 15:15 |
| seb128 | james_w: my thing being debuild? ;-) | 15:16 |
| james_w | oh, I thought you used sticky tape to make the .debs | 15:16 |
| seb128 | my debian applicant manager made me rewrite my a rules without using debhelper or cdbs | 15:18 |
| seb128 | I really appreciate the packaging tools since ;-) | 15:19 |
| seb128 | james_w: good work, thanks | 15:33 |
| seb128 | james_w: new revision uploaded to hardy | 15:34 |
| seb128 | james_w: I get the issue you described I think though, I've only one screen and the clone options is checked by default so the monitor label is wrong | 15:34 |
| james_w | yeah, I think that's a problem in the -desktop patch, I asked bryce about it as I am not sure what the correct logic should be. | 15:41 |
| seb128 | that's a minor point | 15:43 |
| seb128 | and it's likely that redhat will fix it | 15:43 |
| seb128 | next issue should be to look if it still bug under xgl | 15:43 |
| james_w | yep, I'm going to try that now. | 15:46 |
| james_w | xgl kills g-s-d, with a backtrace very similar to https://bugs.edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/210226 | 15:55 |
| ubotu | Launchpad bug 210226 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in rw_screen_list_outputs()" [Medium,Confirmed] | 15:55 |
| ubotu | New bug: #178274 in xulrunner-1.9 (main) "[hardy] firefox breaks on some pages with an X error (dup-of: 205599)" [Medium,Incomplete] https://launchpad.net/bugs/178274 | 16:31 |
| ubotu | New bug: #184076 in midbrowser "gecko received an X Window System error (dup-of: 205599)" [Undecided,New] https://launchpad.net/bugs/184076 | 16:31 |
| ubotu | New bug: #194782 in firefox-3.0 (main) "[hardy] firefox breaks on some pages with an X error (dup-of: 205599)" [Undecided,New] https://launchpad.net/bugs/194782 | 16:31 |
| ubotu | New bug: #214652 in xorg (main) "Xorg freezes on logout in hardy" [Undecided,New] https://launchpad.net/bugs/214652 | 17:01 |
| james_w | seb128: how would you feel about http://jameswestby.net/scratch/g-s-d.diff | 17:34 |
| james_w | is there a preferred way to add the linker options? | 17:34 |
| james_w | I wasn't sure whether autoconf would be appreciated. | 17:34 |
| james_w | It's taking bryce's code for detecting Xgl and just disabling the xrandr plugin if it is detected. | 17:35 |
| bryce | morning | 17:35 |
| james_w | hi bryce, sleep well? | 17:35 |
| seb128 | james_w: that seems the wrong approch to me, do you know why it breaks exactly? | 17:37 |
| james_w | nope, afraid not. | 17:37 |
| bryce | james_w: well enough | 17:38 |
| james_w | bryce: testing the new stuff on Xgl I didn't get a backtrace like those in the report, I got one like bug 210226 | 17:40 |
| ubotu | Launchpad bug 210226 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in rw_screen_list_outputs()" [Medium,Confirmed] https://launchpad.net/bugs/210226 | 17:40 |
| seb128 | james_w: I keep that as an option but I would prefer to find the call which is failing under xgl and fix that because it might cause similar cause under other situations | 17:40 |
| james_w | seb128: yes, that would be better, but I don't know where to look for that. I can look tomorrow if someone has a few pointers. | 17:40 |
| seb128 | james_w: we have bugs about similar crash when using nvidia and xinerama for example | 17:41 |
| seb128 | james_w: not really, that's just plain C crash debugging, not really hint to help there out of using gdb and valgrind | 17:41 |
| seb128 | james_w: let me have a look tomorrow and ping you back, ok? | 17:45 |
| james_w | seb128: sure, I'll take a quick look now as well. | 17:46 |
| seb128 | ok, thanks | 17:50 |
| seb128 | I'm away for diner, see you later | 17:50 |
| james_w | bye | 17:51 |
| james_w | XRRGetScreenSizeRange fails on Xgl | 18:06 |
| james_w | bryce: this is where I get stuck, I can't follow the X calls in libxrandr, is there a way I can debug this further? | 18:09 |
| james_w | or do we just need to add code for this situation to avoid a segfault? | 18:09 |
| bryce | james_w: what i've been doing is adding in some null pointer checks... | 18:18 |
| bryce | http://people.ubuntu.com/~bryce/Testing/XrandrGui/gd-randr-null-check.patch | 18:19 |
| bryce | warning - I've not compiled that patch yet, it may have typos | 18:19 |
| james_w | bryce: yeah, you've got the one causing this crash in there, want me to test it? | 18:21 |
| james_w | bryce: I've got to go now, sorry, I'll try and catch you later today to see if there is anything else to do. Feel free to drop me an email with anything instead. | 18:27 |
| james_w | Otherwise I'll test any uploads and work on other things. | 18:28 |
| * bryce finally catches up on backlog | 18:33 | |
| bryce | good work on getting the g-c-c patch uploaded, I'll pull it and test too | 18:33 |
| james_w | I'm pretty embarrased that I was trying to debug why the checkbox was missing when I just hadn't updated capplets-data :-) | 18:34 |
| bryce | heh | 18:34 |
| bryce | yeah I'll get this patch uploaded and you can test tomorrow or as you have time | 18:35 |
| bryce | my suspicion with that bug is that <root cause> is resulting in the xrandr gui code getting an invalid data structure, with some members being NULL | 18:37 |
| bryce | we can pepper the code with the null pointer checks, but it doesn't address the root cause that's causing the problem in the first place | 18:37 |
| bryce | I suspect using Xgl is one root cause. It's possible seb is right and that there are other similar causes | 18:38 |
| james_w | screen->info is null in my case | 18:41 |
| james_w | as XRRGetScreenSizeRange fails, and so it just sets it too NULL, and then this is never checked for. | 18:42 |
| james_w | null in rw_screen_list_outputs that is. | 18:46 |
| bryce | mmm | 18:54 |
| bryce | so the next question is why XRRGetScreenSizeRange fails | 18:54 |
| bryce | james_w: can you run sudo ddcprobe and see if you get edidfail? | 18:55 |
| james_w | sure | 18:56 |
| james_w | nope | 18:57 |
| james_w | want the output? | 18:57 |
| bryce | sure | 18:57 |
| james_w | (this is still nvidia by the way) | 18:57 |
| bryce | maybe -nvidia just doesn't work with that call? | 19:00 |
| bryce | perhaps we should simply include code to bail out once that call fails | 19:00 |
| james_w | http://paste.ubuntu.com/6673/ | 19:00 |
| bryce | hmmmm | 19:00 |
| bryce | something looks odd... can you pastebin your /var/log/Xorg.0.log? | 19:01 |
| bryce | ah, nope nevermind | 19:01 |
| bryce | (thought it was reporting cm when it should say mm, but it's actually doing the right thing) | 19:02 |
| james_w | http://paste.ubuntu.com/6674/ | 19:02 |
| bryce | the ddcprobe output looks ok. Also, am I remembering correctly that you tested with -nv and it worked ok? that would rule out an edid issue | 19:02 |
| james_w | um, no I haven't tested with nv yet. | 19:04 |
| james_w | let me do that. | 19:04 |
| james_w | still -xgl? | 19:04 |
| bryce | odd, no edid listed in your Xorg.0.log. | 19:04 |
| bryce | sure | 19:04 |
| bryce | actually wait | 19:04 |
| bryce | I don't think it's an edid issue, don't worry about testing the -nv driver | 19:05 |
| bryce | I'm fairly certain the issue is that -nvidia+-xgl is not supporting the necessary xrandr 1.2 calls, and we just need to check if that call failed | 19:07 |
| bryce | assuming that's right, running -nv without -xgl should work. I'm not sure what -nv + -xgl would do, actually. I suspect it'd probably fail | 19:08 |
| james_w | I can log in with nv and g-s-d runs fine, I've no idea whether I'm actually on Xgl though. | 19:12 |
| bryce | xpdyinfo | grep -i xgl I think | 19:12 |
| james_w | that doesn't report anything even when xgl is working. | 19:23 |
| bryce | sorry. xvinfo | grep -q Xgl | 19:27 |
| bryce | xvinfo | grep Xgl actually | 19:27 |
| james_w | yep nv works, but it's not Xgl | 19:56 |
| bryce | ok, that's what I expected | 19:57 |
| bryce | -nv + Xgl probably is a really uncommon config | 19:58 |
| bryce | (if it's even possible to config it that way) | 19:58 |
| joumetal | bug 214168 has good screenshot. What could cause it? | 20:09 |
| ubotu | Launchpad bug 214168 in xserver-xorg-video-intel "video acceleration broken with .810 driver in Hardy Beta" [Undecided,New] https://launchpad.net/bugs/214168 | 20:09 |
| bryce | heya joumetal | 20:16 |
| joumetal | hello bryce | 20:17 |
| bryce | joumetal: I don't know exactly what's causing it but I can give some general comments | 20:18 |
| joumetal | go ahead | 20:18 |
| bryce | first, issues that appear with 3D only, are sometimes/often due to issues in mesa. Not sure that's necessarily true in this case, but a possibility | 20:18 |
| bryce | also, I see the card in question is i815, which is a pretty old model of intel card | 20:19 |
| bryce | and in fact, many i8xx cards didn't work properly in -intel when we started Hardy, but we've forwarded bug reports upstream and the Xorg team has been fixing them | 20:19 |
| bryce | especially i855 got a lot of fixes. But each of the i8xx models has its own little quirks and bios-specific issues | 20:20 |
| bryce | I suspect i855 is more commonly found than i815, so it doesn't surprise me that there may be more bugs for i815 to do | 20:21 |
| bryce | anyway... | 20:21 |
| bryce | so what's needed here is to collect the /var/log/Xorg.0.log (this should always be included when people report X bugs), but otherwise I think it is ready for forwarding upstream | 20:22 |
| bryce | joumetal: do you want to collect that file and/or forward upstream, or shall I take it from here? | 20:23 |
| joumetal | I am happy if you take it. | 20:24 |
| bryce | ok will do | 20:25 |
| bryce | also, when you spot a bug that is driver specific and have added a task for that, you can also close the xorg task; not necessary to have them double filed | 20:26 |
| joumetal | ok maked xorg task invalid. | 20:30 |
| james_w | hey seb128. | 20:35 |
| james_w | bryce has a patch that should fix the -xgl issue I am seeing. | 20:35 |
| seb128 | re james_w | 20:36 |
| seb128 | ah, cool | 20:36 |
| seb128 | where is it? | 20:36 |
| james_w | http://people.ubuntu.com/~bryce/Testing/XrandrGui/gd-randr-null-check.patch | 20:36 |
| james_w | I haven't tested it, but it adds a NULL check where the segfault was, so it should at least prevent that. | 20:36 |
| bryce | james_w: did you test it? I'm finding one of the asserts is causing a crash on my dev box (which is good... but needs fixed first) | 20:37 |
| james_w | bryce: no, sorry, I didn't | 20:37 |
| bryce | also the null check may not *fix* the problem (it might), but at worst will shift the problem higher up in the stack where it can be better handled | 20:37 |
| seb128 | the patch looks alright, adding extra checks is a good thing | 20:38 |
| bryce | I noticed ssp had added similar checks in a few places, so followed his style and just made sure they were ubiquitous, but I may have been too liberal since now it's asserting | 20:40 |
| seb128 | let's get it uploaded soon and see what the user feedback is | 20:42 |
| seb128 | bryce: btw dunno if you noticed we fixed the evince issue | 20:42 |
| seb128 | bryce: thanks to jcristau who noticed that the dpi calculation was wrong | 20:43 |
| bryce | oh awesome, what was the cause? | 20:43 |
| bryce | yeah I saw the discussion | 20:43 |
| bryce | oh, *96 vs /96 | 20:43 |
| seb128 | the gnome-desktop call was using width_mm = (width * 96.0) * 25.4 | 20:43 |
| seb128 | and same for height | 20:43 |
| seb128 | where is should be / 96.0 | 20:43 |
| bryce | good catch | 20:45 |
| seb128 | indeed | 20:45 |
| bryce | I also wonder about using 96 there | 20:45 |
| seb128 | that's what GNOME used to code as a value | 20:45 |
| seb128 | I was thing about changing that to use the gconf dpig key rather | 20:45 |
| seb128 | s/thing/thinking | 20:46 |
| seb128 | that would allow users to change the value | 20:46 |
| bryce | I hope in intrepid we can finally get all the dpi fussiness sorted out | 20:46 |
| seb128 | which is not possible now | 20:46 |
| seb128 | would be nice if xorg would get that right ;-) | 20:47 |
| bryce | yeah... well looks like a lot of the remaining issues are quirkable | 20:47 |
| seb128 | quirk are nice | 20:47 |
| bryce | however I'm concerned about situations where edid is not available, since all the dpi calcs seem to depend on the monitor providing at least some info | 20:48 |
| seb128 | it make possible to fix things broken which it would not be possible to workaround easily in the code | 20:48 |
| * bryce nods | 20:48 | |
| seb128 | well, maybe xorg should just fallback to 96 dpis when there is no edid information? | 20:48 |
| bryce | I believe it does. That may be why we don't see more bug reports than we already do | 20:49 |
| seb128 | ah, ok | 20:49 |
| bryce | I wonder if there are apps that are using mechanisms other than Xorg for getting that value though | 20:49 |
| seb128 | let's try to drop the coded value again next cycle | 20:49 |
| bryce | agreed | 20:50 |
| seb128 | not in the standard desktop I think | 20:50 |
| bryce | I need to diagram out all the paths, like I did for the resolution stuff | 20:50 |
| seb128 | GNOME seems to not care about the xorg value | 20:50 |
| bryce | seems there are multiple techniques people have used for calculating dpi; maybe unifying them could eliminate many bugs and make quirking more universally effective | 20:51 |
| seb128 | bryce: btw xrandr is still quite broken, I though that resolution changes would work on intel | 20:51 |
| bryce | too many cases of "dpi is right in apps ABC, but bad in DEF" | 20:51 |
| seb128 | could be a compiz bug, when when switching between resolution the usuable screen portion stays to the small resolution and the other border are corrupted | 20:52 |
| bryce | could be | 20:52 |
| bryce | two of my -intel systems work great with the resolution switching. one system only works when switching resolution to *higher* rez's, and locks up if reducing | 20:53 |
| bryce | however that system I've hacked so much X stuff on I think it needs a complete reinstall (Xrandr used to work fine on it before I started work on xrandr gui stuff) | 20:53 |
| seb128 | is there any driver where xrandr is really working correctly? | 20:54 |
| bryce | there is no driver I've found that works 100% with xrandr with any arbitrary chipsets | 20:55 |
| bryce | but since these issues cause incorrect behavior rather than out and out crashes, I'm not certain how exactly to debug them | 20:56 |
| bryce | once the major xrandr gui bugs are closed, I want to build a table of xrandr test results for various drivers/chipsets, and approach the upstream devs. | 20:57 |
| bryce | seb128: a useful thing would be to try to reproduce the issue using just the cmdline xrandr tool; if this can be done, we can report the issue directly upstream. Otherwise we need to first identify if it is due to a bug in xrandr gui (like that dpi issue was) | 20:59 |
| seb128 | right | 21:00 |
| bryce | fwiw, this is the crash I'm working on... | 21:16 |
| bryce | Program received signal SIGSEGV, Segmentation fault. | 21:16 |
| bryce | [Switching to Thread 0xb6d2d720 (LWP 6683)] | 21:16 |
| bryce | 0x0804d911 in on_screen_changed (scr=0x8193880, data=0x8070e80) at xrandr-capplet.c:122 | 21:16 |
| bryce | 122in xrandr-capplet.c | 21:16 |
| seb128 | that's the common one I think | 21:17 |
| seb128 | one of those I listed in the mail I sent some days ago | 21:17 |
| seb128 | would be nice to get it fixed indeed ;-) | 21:17 |
| bryce | ah, so then if it's unrelated to my patch (which is as I suspect), should I upload this, so we can test it against the Xgl bug? Then I'll continue troubleshooting this one | 21:18 |
| bryce | this one is starting to feel like an uninitialized pointer error | 21:18 |
| seb128 | uninitialized pointer is easy to figure if you have the issue | 21:19 |
| seb128 | build using -O0 rather than -O2 | 21:19 |
| bryce | ok | 21:19 |
| seb128 | when using -O0 usually the variable are initialized | 21:20 |
| ubotu | New bug: #214787 in xserver-xorg-video-intel (main) "Intermittent monitor flicker after screen blanking in Hardy" [Undecided,New] https://launchpad.net/bugs/214787 | 21:45 |
| bryce | ok, whatever that bug is, it is unrelated to my changes; the dialog seems to work fine on other hardware, so I'll proceed with uploading. | 21:53 |
| seb128 | cool | 21:55 |
| bryce | hrm, got rejected | 22:42 |
| bryce | oh whoops, collided with your fix. | 22:45 |
| ubotu | New bug: #214813 in xorg (main) "Bad detection of card - Dell Optiplex 740 AMD64" [Undecided,New] https://launchpad.net/bugs/214813 | 22:45 |
| bryce | try again && lunch (bbiab) | 22:50 |
| bryce | ok went through that time | 23:12 |
| ubotu | New bug: #214836 in linux-restricted-modules-2.6.24 (restricted) "lrm incorrectly installs nvidia-glx-new" [Undecided,New] https://launchpad.net/bugs/214836 | 23:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
