[08:04] <tjaalton> bryce: I've filed a bug to remove fonttosfnt from the archive, bug 235411. you could confirm that if you agree ;)
[08:04] <ubottu> Launchpad bug 235411 in fonttosfnt "Please remove from the archive" [Undecided,New] https://launchpad.net/bugs/235411
[08:06] <bryce> tjaalton: okies
[08:08] <tjaalton> hmm, a couple of pending sync requests.. guess they'll be processed soon
[08:10] <tjaalton> so, there'll be libdrm 2.3.1 without any memory-manager goodness
[08:29] <tseliot> tjaalton: I'm uploading the source code of my packages to my website. NOTE: I haven't touched the control files (as regards dependencies) and haven't carefully checked the diversions, however I would like you to review what I have done so far.
[08:32] <tjaalton> tseliot: ok, cool
[08:34] <tseliot> tjaalton: I haven't removed the dependency on linux-restricted-modules-common yet since we are not sure about its removal and I had to add a "-modaliases" package so that we don't screw up jockey
[09:21] <tjaalton> wow, Wolfram answered to bug 197163
[09:21] <ubottu> Launchpad bug 197163 in xorg "Mathematica renders fonts incorrectly in Hardy" [Undecided,Won't fix] https://launchpad.net/bugs/197163
[09:22] <tjaalton> so we are buggy at least in some respect, because there are no usable Courier and Times fonts (msttcorefonts not helping here)
[09:29] <tjaalton> hm, though it should help
[09:33] <tjaalton> fedora seems to have urw-fonts which is a free bundle of tt-fonts
[09:36] <bryce> tjaalton: true
[09:37] <tjaalton> I'll see what it takes to package that
[09:45] <tseliot> tjaalton: here is a txt file which contains all the links to the source code: http://www.albertomilone.com/ubuntu/newlrm/lrm-links.txt
[09:45] <tjaalton> apparently gsfonts should have the fonts..
[09:45] <tjaalton> tseliot: thanks
[09:46] <tjaalton> I'll just grab the directory
[09:46] <tseliot> in the meantime I'll work on the xorg parser for bryce 
[09:47] <tjaalton> uh, forbidden
[09:48] <tseliot> yes, I know
[09:49] <tseliot> you should wget the links in that txt file
[09:49] <tjaalton> works
[09:50] <tjaalton> ok, the version number is wrong :) -1 is reserved for debian, this should be -0ubuntu1
[09:51] <tseliot> yes, I (temporarily) used exactly the same version as the debian package
[09:52] <tjaalton> ok, that just makes no sense :)
[09:53] <unggnu> hi all
[09:53] <tjaalton> hi unggnu 
[09:53] <unggnu> According to mail [ubuntu-x] Xorg Triaging Projects it is not possible for non developers to set Wont' fix
[09:53] <unggnu> hi tjaalton
[09:54] <unggnu> Only solution is to set to invalid I guess or get the permission to use Wontfix.
[09:55] <tjaalton> or join ubuntu-bugcontrol
[09:56] <unggnu> Do you have a link?
[09:56] <tjaalton> https://edge.launchpad.net/~ubuntu-bugcontrol
[09:57] <unggnu> thx
[09:59] <unggnu> Btw. isn't it possible with a script to mark all displayconfig-gtk bug reports which have only one package association with Wontfix and add the description?
[10:01] <tjaalton> should be, but I'm not familiar with the mail-interface
[10:02] <unggnu> Ok
[10:06] <unggnu> Is something planned for people with hardware which send wrong data or something like that? Some can't even fixed with a quirk afaik. It is possible to change xorg.conf manually but it isn't so easy I guess for most people.
[10:06] <unggnu> e.g. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/191000
[10:06] <ubottu> Launchpad bug 191000 in xserver-xorg-video-intel "[Hardy] X Server fails to start [845g] (dup-of: 194760)" [Unknown,Fix released] 
[10:06] <ubottu> Launchpad bug 194760 in xorg-server "EDID fail" [High,Triaged] 
[10:17] <unggnu> I guess a tool with a "problem monitor" db would be great or the ability to import windows monitor drivers and change the xorg.conf settings with this information. Afaik displayconfig-gtk had the second ability. Maybe only the monitor part can be extracted.
[10:55] <unggnu> Another problem are CRT displays afaik. It is possible to change the user resolution with the screen resolution tool but not the login one and afaik X uses the highes possible one which doesn't look so well on CRTs.
[10:57] <unggnu> Are there any plans for this problems?
[11:05] <unggnu> bbl
[11:06] <tjaalton> CRT's are dying anyway ;)
[11:07] <jcristau> unggnu: X uses the mode that your monitor reports as preferred
[11:07] <jcristau> unggnu: if that doesn't work then it can be quirked
[11:08] <tjaalton> yeah the first problem seemed like it should be able to be quirked, since it tries to use a wrong mode
[11:21] <tjaalton> maybe the inted engineer meant that it's not possible to quirk the driver
[11:21] <tjaalton> *intel
[11:25] <jcristau> the initial mode selection code has changed a lot recently though
[11:25] <jcristau> so maybe the server from git does a better job
[11:25] <jcristau> in any case this looks like a bug in the server, not xf86-video-intel?
[11:27] <tjaalton> yeah
[11:59] <unggnu> re
[12:00] <unggnu> jcristau: so a CRT sends the data that he supports resolutions up to 1600x1200 but prefers 1280x1024?
[12:00] <unggnu> sorry, it supports :)
[12:00] <jcristau> yes
[12:01] <unggnu> But why are so many people with CRT complaining about it?
[12:04] <unggnu> Anyway, if xserver uses this preferred mode it is Ok I guess. I can't test it since I haven't any CRT anymore. Yes, they are dying :)
[12:07] <unggnu> I guess in future the biggest part of the driver are quirks ;)
[12:07] <jcristau> no
[13:11] <unggnu> bbl
[16:32] <bryce> tjaalton: do you know of any reasons we should put a newer fglrx into 8.04.1 (deadline's coming up)
[16:41] <tjaalton> tjaalton: I'll read the relnotes to see if there's anything
[16:42] <tjaalton> I didn't realize there was a deadline :/
[16:43] <bryce> yeah sunday is the cutoff for getting things into 8.04.1
[16:43] <tseliot> tjaalton: https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/catalyst_85_linux.html
[16:43] <tseliot> BTW they broke the API
[16:46] <bryce> tseliot: erf
[16:48] <tjaalton> tseliot: meaning?
[16:50] <tjaalton> eh, the list of known issues keeps getting longer..
[16:50] <tseliot> tjaalton: it means that you will have a lot of fun packaging it
[16:51] <tseliot> furthermore the ati installer doesn't include Mario's latest scripts
[16:51] <tseliot> therefore I suggest you to get such scripts from git and see what's changed
[16:52] <tseliot> I'm planning to make this driver available through EnvyNG too (sooner or later)
[16:52] <tseliot> bryce: have a look at my email when you have the time
[16:53] <bryce> tseliot: ok just replied
[16:53] <tseliot> bryce: thanks
[17:25] <bryce> heya unggnu
[17:25] <unggnu> hi bryce
[17:25] <bryce> tseliot, tjaalton: so sounds like the new fglrx is too sketchy to think about including for 8.04.1?
[17:26] <unggnu> Can't someone ask an Launchpad expert or maintainer if this is possible to close all displayconfig-gtk bugs since they don't seem to need user interaction.
[17:26] <unggnu> I thought updating fglrx or nvidia isn't possible or at least feasible? At least I have read it somewhere.
[17:26] <tseliot> bryce: yes, I guess so
[17:27] <bryce> unggnu: normally yes, but I got a dispensation for it for 8.04.1 -- but it makes sense to do it only if we know it will fix issues and we're confident it won't bring regressions
[17:28] <unggnu> ok
[17:32] <bryce> unggnu: I was going to just close the dcg bugs manually, so I could check that they're actually dcg bugs, and give additional answers where appropriate
[17:34] <unggnu> Ok, that's a point. I could be minimize through closing simply the displayconfig-gtk only bugs but the risk is still there.
[17:36] <unggnu> So kde-guidance should be closed too?
[17:36] <bryce> I believe so, but check with scottk
[17:39] <tjaalton> bryce: yep
[17:44] <johanbr> bryce: About the Radeon lockup bug (bug #234811), "xrandr -s 1440x900" works (in contrast to doing it with the GUI, which causes a hard lockup).
[17:44] <ubottu> Launchpad bug 234811 in xserver-xorg-video-ati "[Hardy] system freezes after setting resolution to 1440 x 900 with Radeon 7500 graphics card, when using DVI output, Acer AL1916W monitor" [Undecided,Incomplete] https://launchpad.net/bugs/234811
[17:45] <bryce> johanbr: *nod* that's too bad, since if it could be reproduced with xrandr we could forward the report upstream
[17:45] <bryce> johanbr: as it is, it may be some issue with gnome-display-properties' randrwrap code
[17:45] <unggnu> What happens with Bullet-Proof-X in Intrepid?
[17:46] <bryce> unggnu: timo and I discussed it and are thinking we'll drop it
[17:46] <johanbr> Even so, there's an X server or driver bug in there somewhere, right? I'd think the GUI shouldn't be able to bring everything down.
[17:46] <bryce> right
[17:47] <bryce> it's definitely a legit X bug, just not clear yet how to troubleshoot it
[17:47] <unggnu> I liked the idea very much but was never lucky with displayconfig-gtk.
[17:47] <johanbr> bryce: I haven't yet tried asking him to rebuild the Gutsy version of the driver. I'll do that.
[17:48] <unggnu> Theoretically it isn't needed if the Vesa fallback of Xorg works fine.
[17:48] <bryce> johanbr: basically what needs to happen is to dig through the code and identify which Xrandr protocol calls are generating the problem, make a test case that reproduces the issue, and forward that upstream
[17:48] <bryce> johanbr: but I think requesting a user code up a test case in C for us is probably asking much ;-)
[17:49] <bryce> possibly there is a way we could gather more detailed logs or something from g-d-p, but I don't recall offhand
[17:50] <johanbr> I guess running g-d-p under gdb and putting in some carefully chosen breakpoints would do the trick.
[17:55] <bryce> johanbr: possibly
[17:56] <bryce> johanbr: although I suspect it probably just happens during the protocol call
[17:56] <bryce> might be able to dig out some state info and such, although it would be difficult to talk a user through all that in gdb
[17:57] <bryce> but perhaps breaking on that call and getting a full backtrace would be doable
[17:57] <bryce> it would be good to have a documented procedure on this, as there's been a few other such reports and I daresay we may be getting more in the future
[18:00] <johanbr> He's new to linux, but interested in helping to resolve the bug and not afraid of reading man pages and such. I'll see what I can do.
[18:04] <unggnu> I guess it is Ok to drop bulletproof. X still is very picky about things in xorg.conf but it could be easily repaired through Recovery Mode. Maybe it would be great to start X without an xorg.conf instead of Bulletproof if X couldn't start.
[18:06] <unggnu> Maybe with a question after login for the admin users if the xorg.conf should be recreated like xfix does.
[18:08] <unggnu> Ok, could be a loop but a simple check could prevent it. I don't know. People like their GUIs :)
[19:13] <bdmurray> tjaalton: is bug 113679 specific to nvidia hardware?
[19:13] <ubottu> Launchpad bug 113679 in xorg-server "xorg freezes when running openoffice" [High,Fix committed] https://launchpad.net/bugs/113679
[19:19] <bryce> unggnu: yeah... ideally I'd like to replace displayconfig-gtk with something, but there's not really anything viable at the moment
[19:21] <unggnu> bryce: Xfix would do the job I guess if there is not a general Xorg/vesa problem.
[19:22] <bryce> unggnu: yeah that's what I'm thinking too
[19:23] <bryce> another option would be to strip down displayconfig to remove the multi-screen stuff and other bits that could cause confusion
[19:23] <bryce> we really don't have a good solution for the corner case of edid failures or where edid is not being provided by the monitor
[19:24] <bryce> i.e., http://bugs.launchpad.net/ubuntu/+bug/edidfail
[19:24] <unggnu> Would be great too for wrong edid data but afaik the conventions have changed. Modelines are ignored at lest for the intel driver. Mainly it would be a rewrite I guess.
[19:24]  * bryce nods
[19:25] <bryce> wow I didn't know they're ignoring modelines now
[19:25] <unggnu> Afaik of course :)
[19:27] <unggnu> something with PreferredMode
[19:27] <unggnu> http://www.intellinuxgraphics.org/dualhead.html
[19:29] <unggnu> also described here in the latest comment https://bugs.freedesktop.org/show_bug.cgi?id=14726
[19:29] <ubottu> Freedesktop bug 14726 in Driver/intel "[845G] X Server fails to start with "intel" driver, works with "i810"." [Major,Resolved: fixed] 
[19:30] <unggnu> bbl
[19:33] <tjaalton> bdmurray: shouldn't be AFAIK
[19:34] <bdmurray> tjaalton: Okay, I saw a couple of references to nvidia in it.  Is there a test case at all?
[19:37] <tjaalton> bdmurray: I don't think there is an easy way to reproduce it.. we have a couple of hundred desktops (all nvidia) and don't remember anyone reporting issues with OO.o :)
[19:37] <tjaalton> even with dapper
[19:37] <bdmurray> hrm, that'll be interesting then
[19:40] <tjaalton> apparently the fix works, since the google guys haven't seen the problem since upgrading to the version on my ppa
[19:51] <bryce> unggnu: hmm I read that as meaning that the order of the resolutions is ignored, but the resolutions themselves are accepted, and I read that as modelines are still accepted
[19:52] <bryce> unggnu: the issue seemed to be that the user added a mode, but couldn't get it to be taken as the default resolution in the new x server by simply listing it first in the list - he had to add it as the preferred mode
[19:52] <bryce> (I could be wrong though, but that was my interpretation)
[20:04] <bryce> good gem vs. ttm article:  http://lwn.net/Articles/283793/
[20:05] <bryce> copy of it here:  http://pastebin.com/m1a80b77b
[20:06] <tjaalton> wow, the topic suggested by Mirv :)
[20:22] <unggnu> bryce: I never got Modelines working with the -intel driver but I am not sure.
[20:24] <unggnu> Maybe it only accepts the modeline if preferredmode is used.
[20:25] <unggnu> It seems so http://lists.freedesktop.org/archives/xorg/2008-February/032791.html but I don't understand why they use a new option for an old feature?
[20:27] <tjaalton> it's randr-1.2, same thing with radeon AFAIK
[20:29] <tseliot> unggnu: something like this would work:
[20:29] <tseliot> Modeline "1280x1024_75.00"  138.54  1280 1368 1504 1728  1024 1025 1028 1069  -HSync +Vsync
[20:29] <tseliot> Option "PreferredMode" "1280x1024_75.00" 
[20:29] <unggnu> I think so. So the tool have to add a Modeline and PreferredMode.
[20:32] <bryce> unggnu: probably the xrandr changes altered how things worked internally
[20:32] <unggnu> Yeah, Xorg devs are very fast forward :)
[20:33] <tseliot> bryce: thinking of the special case which you suggested in the email, we can test such case with my program, which I will keep separate from the parser, and decide which approach we should adopt.
[20:33] <bryce> I think there didn't used to be the idea of a PreferredMode so adding that feature broke old behavior
[20:34] <bryce> tseliot: good to hear.  it could help prevent xorg.conf's from getting chugged up with extraneous cruft (which tends to exacerbate troubleshooting issues)
[20:35] <tseliot> bryce: I would like to make both parts maintainable and easy to use so that at least the parser can be shared between different applications. We'll see how it goes...
[20:36] <tseliot> tjaalton: quoting from Phoronix "NVIDIA this morning has released the 173.14.05 driver,  which marks the return to their old naming convention"
[20:37] <bryce> tseliot: heh
[20:37] <tseliot> tjaalton: this release supports kernel 2.6.25 therefore I will have to update the driver and drop the patch for 2.6.25 for driver 169.12
[20:42] <tjaalton> tseliot: cool, it only took them a couple of months..
[20:49] <unggnu> Btw. I have asked this some time ago. Is there any doc how to compile svn Intel driver for normal users without messing up their system?
[20:50] <bryce> there's a few such documents but from my experience users just whine when asked to build from git
[20:50] <bryce> (not that I blame them, I probably would too)
[20:50] <unggnu> But upstream often asks for it.
[20:51] <bryce> right
[20:51] <unggnu> This time the debian sid driver works but it is not often the case afaik.
[20:52] <unggnu> e.g. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/207881
[20:52] <ubottu> Launchpad bug 207881 in xserver-xorg-video-intel "[Gutsy, Hardy] Black screen with mouse pointer on i830, intel driver" [Unknown,Confirmed] 
[20:52] <unggnu> this one wanted a patched driver
[20:53] <unggnu> I have tried it but there is one hunk.
[20:57] <unggnu> +failed
[20:58] <bryce> often with patches from upstream I have to recode them a little to make them patch cleanly against the driver we carry
[21:00] <bryce> unggnu: tell you what, I'll take care of 207881
[21:01] <unggnu> thx :)
[21:02] <bryce> unggnu: btw, fyi we have the 8.04.1 cut off date coming up sunday, so what I'm working on now is looking for patches that are complete, verified, and ready for backporting to hardy
[21:02] <bryce> unggnu: so if you could search around for good looking patches that look like they could be put to hardy, please assign them to me
[21:04] <unggnu> Ok, what is the best way? Searching for bug reports with an upstream report and fix released?
[21:04] <unggnu> Or just patches which are already in Intrepid?
[21:05] <bryce> sure both
[21:05] <unggnu> ok
[21:05] <bryce> actually there are probably going to be exceptionally few in the latter category
[21:05] <bryce> so focus on the first
[21:08] <tjaalton> bryce: what was the firefox addon that allows you to open files in firefox instead of it proposing to save it first?
[21:12] <bryce> my notes say "Open In Browser"
[21:15] <bryce> howdy tormod
[21:16] <tormod> heya bryce
[21:16] <bryce> wow, don't think I've seen this many people on #ubuntu-x.  :-)
[21:17] <tjaalton> bryce: hm, either I'm blind or can't find it
[21:18] <bryce> maybe this?  http://www.spasche.net/mozilla/
[21:18] <bryce> looks like it's only for ff2
[21:18] <bryce> (I finally gave up on ff3 yesterday and reverted back to 2)
[21:19] <tjaalton> damn :)
[21:19] <tormod> bryce, due to the disk activity?
[21:19] <bryce> tormod: yeah the periodic freeze-ups that are reportedly due to sql-lite size limits
[21:20] <bryce> tormod: plus a scattering of crash issues (less common now than they used to be though)
[21:20] <tormod> they need a full RDBS in there I guess
[21:20] <unggnu> bryce: What should I do if there is already an assignee?
[21:21] <bryce> tjaalton: hrm, didn't install onto ff2 for me
[21:21] <bryce> unggnu: if it's already assigned to me, then I've already looked at it and it may already be in my queue
[21:21] <unggnu> bryce: no, not you :)
[21:21] <bryce> if it's assigned to the ubuntu-x swat team, you can consider those unassigned
[21:21] <unggnu> bryce: bryce: this one looks good https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/211759
[21:21] <ubottu> Launchpad bug 211759 in xserver-xorg-video-ati "Live-CD (7.10, 8.04) fails to start X server (ATI Xpress 1250)" [High,In progress] 
[21:22] <bryce> assigned to anyone else, just mention the bug id to me here and I'll review.
[21:22] <unggnu> cannonical-xorg
[21:22] <tormod> when is launchpad getting per-package bug filing instructions, like attach your Xorg.log...
[21:22] <bryce> ok, treat canonical-xorg to be unassigned as well; that's just a generic team assignment
[21:22] <unggnu> ok
[21:23] <bryce> I'm the only person in canonical-xorg anyway, so all those can just be re-assigned to me.  I don't know who added that team or why, but I don't use it
[21:23] <bryce> tormod: in fact I mentioned exactly that to kiko last week at UDS during one of the "improving launchpad to improve bug reporting" sessions
[21:24] <bryce> tormod: I didn't get a solid commitment to implement such a thing, but favorable noises were made, so we'll see
[21:24] <tormod> bryce: excellent. but it's not like a new idea... it has been requested before I think. hope it helps this time.
[21:25] <tormod> has it been decided that intrepid gets xserver 1.5 and mesa 7.1?
[21:25] <bryce> tormod: this was in particular related with how to improve being able to get bugs upstreamed, which kiko is very passionate about.  I said that if launchpad could be set to require attaching Xorg.0.log to every package managed by the xorg team, it'd probably double our triaging effectiveness
[21:25] <bryce> tormod: yes
[21:26] <tormod> yay for that 
[21:27] <tormod> can someone look at my workaround patch for bug 87661, before I ask upstream?
[21:27] <ubottu> Launchpad bug 87661 in mesa "[apport] polytopes crashed with SIGILL in _mesa_x86_64_transform_points4_perspective()" [Medium,Confirmed] https://launchpad.net/bugs/87661
[21:29] <bryce> tormod: looks roughly sane to me (although I didn't read the whole bug report)
[21:30] <tormod> bryce: I don't know so well how 64-bit processors work with different code and kernels etc
[21:51] <unggnu> bryce: I am not sure with this one. It only seems to be a dependency issue so easy fixable but I don't know ... https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/44115
[21:51] <ubottu> Launchpad bug 44115 in mesa "xserver-xorg-video-tdfx must depend of libglide3 to get 3d aceleration in 3dfx cards" [Wishlist,Confirmed] 
[21:53] <tjaalton> would mean installing libglide3 on every machine
[21:53] <tjaalton> not something to be done on a stable release
[21:53] <tjaalton> or ever
[21:53] <bryce> tjaalton: can it be closed as wontfix then
[21:53] <bryce> ?
[21:54] <tjaalton> imho yes
[21:54] <unggnu> Or put it to suggest like in Debian
[21:54] <tjaalton> it is?
[21:55] <tjaalton> yes
[21:56] <jibel> hi
[21:56] <tjaalton> so it's the same in ubuntu too -> closing the bug
[21:56] <unggnu> hi jibel
[21:57] <jibel> bryce: bug 229043 is fixed in v2.3 of the intel driver. Do you known if it will be fixed in 8.04.1 or earlier ?
[21:57] <ubottu> Launchpad bug 229043 in xserver-xorg-video-intel "System freezes when login out" [Undecided,Fix committed] https://launchpad.net/bugs/229043
[22:19] <bryce> jibel: I'll take a look
[22:27] <jibel> bryce: Thanks. I'll keep informed the reporter.
[22:55] <unggnu> bryce: I guess huge patches should be integrated?
[22:55] <unggnu> *shouldn't
[22:56] <bryce> right
[22:56] <bryce> (generally)
[22:56] <unggnu> so no need for assigning?
[22:59] <bryce> unggnu: right
[23:08] <unggnu> hm, haven't found so much
[23:08] <bryce> ok good.  I did a patrol for quirks and found only one
[23:08] <unggnu> four and one seems to be dirty but was confirmed several times https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/133060
[23:08] <ubottu> Launchpad bug 133060 in xserver-xorg-input-synaptics "Synaptic touchpad fails to register some of the taps for tap-to-click" [Undecided,Confirmed] 
[23:21] <tormod> actually update-manager uses more memory than firefox, lol
[23:22] <tormod> can I trust System Monitor - firefox only 43MB?
[23:22] <tormod> I wonder if I add up those numbers and compare with "free"
[23:36] <unggnu> bryce: another quirk possibility https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/201032 
[23:36] <ubottu> Launchpad bug 201032 in xorg-server "[hardy][regression]xorg gets wrong screen dpi" [Unknown,Confirmed] 
[23:39] <unggnu> and another one https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/200805
[23:39] <ubottu> Launchpad bug 200805 in xorg-server "xorg uses laptop video BIOS 'Panel Size' for external monitors, so apps end up confined to small space in top left of screen" [Undecided,Incomplete] 
[23:40] <tormod> oops that was wrong channel - time for bed QED
[23:42] <unggnu> :)
[23:43] <unggnu> I am not sure with them so I haven't assigned you.
[23:44] <unggnu> I am off too, ciao
[23:55] <bryce> excellent