[01:52] <bryceh> Sarvatt, re: arsenal script to transition nvidia-180 tasks to nvidia-gfx-drivers... sweetness
[01:59] <Sarvatt> pushed it here - https://code.edge.launchpad.net/~sarvatt/arsenal/working
[01:59] <Sarvatt> verified the first 10 it hit were all correct on the dry run, running it for real now :D
[02:00]  * bryceh currently working on script to make a report of lucid bugs with upstream tasks and the upstream status of the bug
[02:02] <Sarvatt> man, this makes thing a breeze
[02:03] <bryceh> yep
[02:03] <Sarvatt> do one of these grok the xorg logs for backtraces and put it in the description?
[02:04] <bryceh> no, but that could be done
[02:04] <bryceh> I've got some code about halfway done which identifies backtraces, and the pci-extract.py script is an example of pulling data from attachments and putting it into the description
[02:05] <bryceh> see starting at around line 321 of arsenal_lib.py, that has some routines for doing stuff with backtraces
[02:09] <bryceh> I've also got a script xparselog around somewhere which parses Xorg.0.log files.  Don't think it extracts backtraces but probably could.  It's perl though so needs reimplemented in python
[02:09] <bryceh> xlogparse
[02:10] <bryceh> there's a copy of it in xorg-pkg-tools
[02:10] <Sarvatt> sweet, I'll look into extending it for what I have in mind in the future then. i'd like to dump info on backtraces and assertions, put them in the description, and have a dupe-o-matic script that'll dupe based off of those strings if you pass it a target bug number
[02:11] <bryceh> great idea
[02:11] <Sarvatt> like there are probably 50 or more bugs right now against nvidia with the same backtrace and the symptoms arent easy to tell its a dupe from the description
[02:11] <bryceh> I think the apport crash bugs are structured well enough that the traces should be machine readable and should be straightforward to do
[02:11] <bryceh> yep
[02:12] <Sarvatt> segfault on resume ones with nvidia-current on lucid
[02:12] <Sarvatt> and karmic for people with PPA versions (which is probably the majority of karmic nvidia users)
[02:13] <Sarvatt> backtrace looks like this for everyone http://paste.ubuntu.com/392187/
[02:14] <RAOF> Is there a way to make apport report bugs against PPA packages?
[02:14] <Sarvatt> people describe it so many different ways, its way too much effort to manually dupe them all
[02:14] <bjsnider> i think it does
[02:14] <bryceh> Sarvatt, yeah
[02:14] <Sarvatt> black screen on resume, suspend doesn't work, X stuck on a black screen, my kittens hit the power button
[02:15] <bryceh> Sarvatt, yeah that looks quite familiar
[02:15] <RAOF> bjsnider: Really?  When did that happen?
[02:15] <bryceh> btw just pushed a script 'retest.py' - this is an example script I used to ask people to retest with the new drm
[02:15] <bjsnider> some guy managed to report a bug on a package in one of my ppas
[02:16] <bryceh> I have to recode it every time I use it for whatever I need, but that's a lot easier than manually going through all the bugs individually
[02:16] <bjsnider> no idea how he did it
[02:16]  * RAOF tests.
[02:18] <RAOF> bjsnider: Doesn't work for me.
[02:18] <bjsnider> i might be able to track the bug he reported down, so maybe you can figure out how he did it
[02:19] <Sarvatt> it rejects it if the bug is filed against a PPA version doesn't it?
[02:19] <RAOF> Right. “Not a genuine Ubuntu package”.
[02:19] <Sarvatt> ..which doesn't mean much with things going to the catchall xorg
[02:20] <RAOF> Sarvatt: Oooh, sneaky.
[02:21] <RAOF> Right.  That will work.
[02:21] <Sarvatt> dang bryceh, arsenal is going to suck my life away :)
[02:21] <bryceh> :-)
[02:22] <bryceh> Sarvatt, if you get to a point with a script where it'd be useful to run regularly, I can add it to my cron to run it hourly/daily/weekly with the other scripts
[02:22] <bryceh> that gets some life back :-)
[02:23] <bjsnider> RAOF, it won't show me bugs i subscribed to when they're closed
[02:23] <bjsnider> so i can't find it
[02:23]  * RAOF is going to have to set aside a day or two to work out exactly how arsenal works.
[02:23] <superm1> RAOF, i've got something set up for mythtv that files bugs for PPA packages
[02:24] <superm1> other MOTU's said it's better not to file them into ubuntu though, but rather use a different project
[02:24] <superm1> so that's what we do for mythtv
[02:24] <bryceh> not a bad idea
[02:25] <Sarvatt> yeah I noticed some random person invalidating bugs we actually requested to be filed against apw's ppa with the drm kernels
[02:25] <RAOF> Particularly since we've got a nouveau project just sitting around in launchpad...
[02:25] <superm1> http://pastebin.com/dHRhrdSR
[02:26] <superm1> basically if it's not a distro package, you set the crashdb accordingly
[02:26] <RAOF> Aaah, *that's* where I've seen it before :)
[02:26] <superm1> and here's the crashdb setup stuff http://pastebin.com/95fwzpkk
[02:27] <Sarvatt> with X stuff its getting filed straight to xorg which isn't a PPA version though
[02:27] <RAOF> That might be worth setting up at some point.  For now, both ubuntu-bug and apport-collect will work for nouveau packages in the xorg-edgers/nouveau PPA as long as it gets run as “ubuntu-bug xorg”.
[02:43] <Sarvatt> my wife is not a happy camper about not being able to come to brussels if I go to UDS :) airfare is ridiculous.
[02:44] <bjsnider> put her in a piece of luggage
[02:44] <bjsnider> that's my brilliant solution
[02:47] <RAOF> Ok.  Lunch time.
[02:47] <bjsnider> somebody needs to invent star trek-y transporters
[03:08] <bryceh> heh, the hotel costs might dwarf the airfare even still
[04:37] <DanaG> https://bugs.launchpad.net/bugs/534677
[04:37] <ubottu> Launchpad bug 534677 in xserver-xorg-video-ati "[lucid] Broken backlight control with Radeon open-source drivers" [Undecided,New]
[04:37] <DanaG> hmm, is xorg-edgers supposed to support "BACKLIGHT" property in xrandr?
[06:08] <tjaalton> RAOF: why not advice people to run 'ubuntu-bug xserver-xorg-video-nouveau' instead?
[06:08] <tjaalton> it'll collect the same information, and save developer time when there's less need to move bugs around
[06:09] <RAOF> tjaalton: Because (1) bryce has found that people get confused, and advises just xorg, (2) if they choose to do the extra work and install the upstream nouveau packages they can't run ubuntu-bug xserver-xorg-video-nouveau.
[06:10] <tjaalton> why (2)? it doesn't matter what the version is
[06:10] <tjaalton> the apport links are installed by x11-common
[06:11] <RAOF> tjaalton: But if they run ubuntu-bug x-x-v-nouveau, and x-x-v-nouveau is not an archive package, apport will bail.
[06:11] <tjaalton> oh boo
[06:11] <RAOF> Right.
[06:11] <RAOF> Otherwise I would have, yes.
[06:11] <tjaalton> ok
[06:33] <LLStarks> bryceh, does fglrx support kms?
[06:37] <tjaalton> LLStarks: no
[06:38] <tjaalton> it doesn't even support the xserver in lucid
[06:38] <LLStarks> what about that custom build we dry-humped amd for?
[06:39] <tjaalton> still, if it takes more than six months to support the server abi, they surely won't support kms
[06:41] <LLStarks> http://www.phoronix.com/scan.php?page=news_item&px=ODA1Mw
[06:41] <LLStarks> bryceh...
[06:41] <LLStarks> >__<
[06:41] <tjaalton> eh?
[06:41] <tjaalton> 2.10 doesn't support ums
[06:41] <LLStarks> usermode is old hat.
[06:41] <tjaalton> so 8xx users would be sad if we went to 2.10
[06:42] <tjaalton> so use kms and be happy
[06:42] <LLStarks> so, what happens for mystic?
[06:42] <LLStarks> drop i810?
[06:43] <tjaalton> if you mean the driver it's long gone
=== Amaranth_ is now known as Amaranth
[06:44] <LLStarks> really? i wouldn't be able to run lucid on an i810e?
[06:44] <tjaalton> no, -intel supports it, somewhat
[06:45] <LLStarks> so, by october, ums will be dropped entirely and the legacy quirks will be hammered out so they can support kms?
[06:45] <tjaalton> maybe
[06:46] <LLStarks> is edgers ready for tearless playback or is kernel work needed?
[06:46] <tjaalton> no idea
[06:47] <LLStarks> aside from that, i consider the i945 drivers perfect. you guys do amazing work.
[07:00] <LLStarks> jeez. nouveau and gallium are moving so fast.
[07:01] <LLStarks> i wouldn't be surprised if 3d performance makes exponential gains this year.
[07:04] <tjaalton> i heard it would need a rewrite of the memory manager, so probably not this year
[08:15] <bryceh> tjaalton, I've got code which can fairly reliably sort out moving bugs from xorg to the right video driver
[08:16] <tjaalton> bryceh: ok, good
[08:16] <bryceh> tjaalton, it's less reliable for bugs about input devices, but should be just fine for -nouveau
[08:17] <bryceh> I used to think we should educate everyone on what the right package to file against, but then I saw no one every got it right anyway.
[08:18] <bryceh> I figured I could write a crappy script which would do it better than the average bug reporter
[08:18] <bryceh> and so here we are ;-)
[08:19] <tjaalton> heh, alright
[09:12] <tseliot> hyperair: are you around?
[09:12] <hyperair> yes?
[09:12]  * hyperair makes some noise so tseliot notices him
[09:13] <bryceh> hi tseliot
[09:13] <tseliot> hi bryceh
[09:13] <tseliot> hyperair: so, about bug #248392
[09:13] <ubottu> Launchpad bug 248392 in ia32-libs "32bit libgl search for dri at wrong place on 64bit system" [Low,Confirmed] https://launchpad.net/bugs/248392
[09:14] <hyperair> yes?
[09:14] <hyperair> wait, you mean it's still not fixed?
[09:14] <tseliot> hyperair: wouldn't it be enough if I simply set --with-dri-searchpath=/usr/lib/dri:/usr/lib32/dri/ on 64bit?
[09:15] <hyperair> tseliot: that would work, i suppose.
[09:15] <tseliot> hyperair: what happens if one of those paths doesn't exist?
[09:15] <hyperair> tseliot: but you'd have to correctly detect 64-bit in debian/rules.
[09:15] <hyperair> tseliot: it falls back to the next path.
[09:16] <hyperair> tseliot: it's similar to PATH
[09:16] <hyperair> i think there was some environment variable that does the same thing
[09:16] <tseliot> hyperair: ok, I wanted to be sure
[09:16] <hyperair> LIBGL_SEARCH_PATH or something
[09:16] <hyperair> that is used if set, and if not, the value from --with-dri-searchpath is used.
[09:16] <hyperair> after that the code is the same.
[09:17] <tseliot> hyperair: as regards detecting 64 bit archs I would simply do: ifeq ($(DEB_BUILD_ARCH),amd64)
[09:17] <hyperair> tseliot: amd64 isn't our only 64-bit arch, is it?
[09:17] <hyperair> there's ia64..
[09:17] <tseliot> do we still support that?
[09:17] <hyperair> don't we?
[09:17] <hyperair> our buildds build that don't they?
[09:18] <tseliot> well, yes but that doesn't mean that it's supported
[09:18] <hyperair> so you're going to just leave it broken?
[09:18] <tseliot> see, ia32-libs for example didn't even build on ia64: https://launchpad.net/ubuntu/+source/ia32-libs
[09:19] <hyperair> meh
[09:19] <jcristau> err.
[09:19] <tseliot> it's not my call and I don't have the hardware anyway
[09:19] <jcristau> the search path you want to change is in the i386 packages anyway
[09:19] <jcristau> the native packages work fine
[09:20] <bryceh> ia64 is not supported, and not something we care about.
[09:20]  * hyperair sighs. okay then
[09:20] <hyperair> do what you wish. i don't mind, as long as amd64 works at the end of the day
[09:20] <tseliot> jcristau: right. Adding --with-dri-searchpath=/usr/lib/dri:/usr/lib32/dri/ should fix it
[09:21] <jcristau> tseliot: adding that to the i386 package.  not the amd64/ia64 ones.
[09:21] <tseliot> jcristau: would 64bit mesa really use 32bit binaries?
[09:21] <tseliot> if I added that?
[09:22] <jcristau> wtf
[09:22] <tseliot> hehe
[09:22] <jcristau> the point is to let 32bit mesa load 32bit drivers
[09:22] <jcristau> you're making me sad
[09:22] <tseliot> yes, I know
[09:22] <tseliot> I'll try to entertain you if you like :-P
[09:22] <hyperair> tseliot: so, which package do you intend to do --with-dri-searchpath for?
[09:23] <hyperair> tseliot: the 32-bit, or the 64-bit one?
[09:23] <hyperair> tseliot: it won't work with the 64-bit one, and with the 32-bit one, it'll fallback to looking in /usr/lib32 which is fine i suppose.
[09:23] <tseliot> hyperair: I was planning on updating mesa 32 bit and on refreshing ia32-libs so that the fix gets in
[09:24] <hyperair> tseliot: that sounds fine to me
[09:24] <tseliot> ok
[09:25] <hyperair> at least, i don't see any potential breakage from what you're doing (it's not so different from what i'm doing, from the mesa point of view)
[09:25] <hyperair> but really, when is our multiarch support going to improve?
[09:25] <tseliot> I'll test it here
[09:26] <hyperair> ia32-libs is a wild hack
[09:26] <tseliot> in lucid +1 I guess
[09:26] <jcristau> ha.
[09:26] <jcristau> in $something + 1
[09:26] <hyperair> ...
[09:26] <tseliot> I'm not the right person to ask
[09:26] <hyperair> i'm willing to bet lucid+1 will *not* get improved multiarch support
[09:26] <hyperair> nor will lucid+2
[09:27] <hyperair> anyway i've got to run
[09:27]  * hyperair brb in 15 minutes or so
[09:27] <bryceh> tseliot, heya, how's things going?
[09:28] <bryceh> tseliot, do you expect to be coming to UDS Brussels?
[09:29] <tseliot> bryceh: not so bad, last night upstream gave me some tips on plymouth (to add the support for 16 colours) :-)
[09:29] <tseliot> bryceh: sure, I'll be there
[09:29] <bryceh> excellent :-)
[09:29] <tseliot> bryceh: how are things going for you?
[09:29] <bryceh> tseliot, glad you're focused on plymouth.  Seems it needs much TLC.
[09:30]  * tseliot nods
[09:30] <bryceh> tseliot, busy as always, but going good.  Glad we have raof on board.
[09:30] <tseliot> :-)
[09:30] <bryceh> tseliot, at the moment I'm brainstorming ideas for topics to discuss at UDS
[09:30] <bryceh> any requests?
[09:31] <tseliot> bryceh: maybe support for touchscreens ;) ?
[09:31] <bryceh> so far got:  X.org general session; Wayland ; Rootless-X ; Multitouch ; X-freeze apport hooks ; X.org Hardware Workshop
[09:31] <tseliot> oh, it's there already
[09:32] <tseliot> I'll let you know if something else comes to my mind
[09:32] <bryceh> ok cool
[09:32] <bryceh> 6 sessions should be plenty
[09:33]  * tseliot nods
[09:33] <bryceh> feel like I'm missing something obvious though.  But guess there's plenty of time still to think of it.
[09:33] <tseliot> right, we have time
[09:46] <tjaalton> btw, evtouch could be synced from debian
[09:47] <tjaalton> builds against 1.7
[09:47] <tjaalton> tseliot: are you planning to move the mesa libGL back to /usr/lib?
[09:47] <tjaalton> for lucid
[09:52] <tseliot> tjaalton: hmm... I haven't decided yet. I think it would be safer not to do it at this point
[09:54] <tjaalton> I'm thinking that it would be worse to have a LTS with it, at least if it's known to be temporary
[10:00] <bryceh> tjaalton, feel free to file a sync request if you'd like; otherwise it's already on my todo list just haven't gotten to it
[10:00] <bryceh> tjaalton, it looked like maybe it needed merging, but I didn't look close
[10:01] <tjaalton> well, the changes were to the fdi file, dunno if they should be moved to the udev rule or not
[10:01] <bryceh> tjaalton, btw my merges page is going to be stuck on march 5th for a bit.  Gotta reincarnate a chroot before I can get that functioning again
[10:03] <tjaalton> bryceh: heh, so it seems
[10:05] <tjaalton> I guess ogra doesn't work on the touchscreens anymore, or evdev is enough for him?-)
[10:06] <bryceh> he does not work on them anymore
[10:06] <bryceh> I think it's more a case of frustration than of being satisfied with alternatives
[10:06] <tseliot> :-)
[10:06] <bryceh> but we did manage to get good braindumps from him into one of the blueprints last uds
[10:07] <bryceh> there is a ton beyond just X that needs worked to get touchscreen support up to snuff
[10:07] <bryceh> but plenty to do just within X even still
[10:08] <bryceh> tjaalton, fwiw shuttleworth has just recently developed a very strong interest in touchscreen support
[10:08] <bryceh> (I gather he's just purchased his first touchscreen hardware)
[10:12] <tjaalton> heh, ok
[10:12] <tjaalton> upstream is working on multitouch
[10:12] <tjaalton> wacom has some temporary hacks, but they won't live for long
[10:14] <bryceh> I've got one of the proposed -evdev patches in my queue to look into more
[10:15] <tjaalton> the kvm one?
[10:15] <bryceh> no the multitouch one
[10:15] <tjaalton> ah
[10:16] <bryceh> by benjamin
[10:16] <bryceh> got a lot of discussion on xorg-devel, sounds like it'll probably get reimplemented completely before its through, but sounds like it basically works
[10:17] <bryceh> I've got a meeting thursday with some of the oem folks to determine what we want to do for lucid
[10:17] <tjaalton> ok, so it's not the one on bug 379313 :)
[10:17] <ubottu> Launchpad bug 379313 in xserver-xorg-input-evdev "Handling NextWindow Touchscreen (multitouch)" [Medium,Incomplete] https://launchpad.net/bugs/379313
[10:19] <bryceh> no, but that one looks like something we could consider including
[10:20] <bryceh> tjaalton, I put my notes at https://wiki.ubuntu.com/X/Blueprints/Multitouch
[10:21] <bryceh> the particular hw we're looking at is N-Trig but really we'd want touchscreen support across a pretty broad range of hw
[10:24] <tseliot> Stantum or 3M should be more Linux friendly: http://www.lii-enac.fr/en/projects/shareit/multitouch-devices.html
[10:24] <tseliot> (no firmware issues)
[10:39] <tjaalton> bryceh: ok, interesting plans. wonder how risky this might be though :)
[10:41] <bryceh> tjaalton, aha! you've discovered my angle
[10:42] <tjaalton> :)
[12:35] <tseliot> tjaalton, hyperair: I've pushed the fix for bug #248392 in git
[12:35] <ubottu> Launchpad bug 248392 in mesa "32bit libgl search for dri at wrong place on 64bit system" [Medium,In progress] https://launchpad.net/bugs/248392
[12:35] <hyperair> tseliot: cool, thanks =)
[12:36] <tseliot> hyperair: of course ia32-libs will have to be updated too but I'll deal with it after I'm done with the rest
[12:52]  * hyperair nods
[13:27] <asac> hi
[13:27] <asac> ;)
[13:27] <asac> so how comes that on armel X falls back to fbdev
[13:27] <asac> is that hardcoded patch we have somewhere?
[13:27] <lool> asac: It's in the server code
[13:28] <asac> lool: so we have a hack?
[13:28] <lool> there's a function which has hardcoded logic depending on various information from the host
[13:28] <lool> asac: We have a patch to use PCI ids insteaed
[13:28] <asac> lool: for armel?
[13:28] <asac> ;)
[13:28] <asac> where is that? any idea?
[13:28] <lool> asac: Not for armel, that's the problem
[13:28] <asac> right ;)
[13:28] <lool> asac: NCommander was working on that a year or so ago, was supposed to extend with some arm logic IIRC
[13:29] <asac> so seems the imx driver is a full copy of fbdev + a patch for EXA
[13:29] <lool> asac: the dove one is a fork from fbdev too
[13:29] <asac> right
[13:29] <lool> But I think that's ok
[13:29] <asac> so easy way feels to extend the current hard coded logic to honour subarch or something
[13:30] <asac> and least try that first 
[13:31] <lool> asac: I think it's in listPossibleVideoDrivers() in hw/xfree86/common/xf86AutoConfig.c, but it could possibly be somewhere else
[13:31] <lool> It ressembles my memory of it
[13:31] <asac> cool i will check that out
[13:31] <asac> in what source is that ;)
[13:31] <asac> me tries the common thing
[13:31] <lool> asac: This is typically where we hookde the poulsbo pci ids at some point
[13:31] <asac> good thanks for that pointer
[13:31] <lool> asac: Actually, search for poulsbo in that file   ;-)
[13:32] <lool> asac: Careful, might be some patches which change this logic in debian/patches/
[13:32] <lool> In fact there are 5
[13:33] <asac> ok i have /* Fallback to platform default frame buffer driver */
[13:33] <asac> thats the place i am looking for ;)
[13:33] <asac> so adding imxdrv there if we are on imx (not sure how to detect that at runtime) might be a hacky but efficient way to accomplish a "prefer imxdrv if available"
[13:34] <asac> lool: any idea to do a proper testing?
[13:35] <jcristau> look in /proc/fb?
[13:35] <lool> That's an excellent idea
[13:35] <asac> i have
[13:35] <asac> 0 DISP3 BG
[13:35] <asac> 1 DISP3 BG - DI1
[13:35] <asac> 2 DISP3 FG
[13:35] <lool> we were considering crazy shit back a couple of cycles, /proc/fb sounds sane
[13:35] <asac> yeah cool
[13:35] <asac> but what do i parse to distinguish?
[13:35] <lool> Hmm it's not too nice on babbage
[13:36] <asac> i can check for cpuinfo ;)
[13:36] <asac> and if its Freescale BBG use imxdrv
[13:36] <asac> at least add to matches
[13:36] <lool> asac: I really think /proc/fb is a better place because it depends on the drivers people build in their kernel
[13:36]  * asac hopes it would then go to fbdev if that module isnt installed
[13:37] <asac> lool: but what do we get from there?
[13:37] <lool> Say, we could have multiple drivers in the kernel for a platform like OMAP and it would affect which xorg driver to use
[13:37] <asac> i dont see anything that tells me: "this is imx"
[13:37] <jcristau> it tells you the name of the kernel fb driver
[13:37] <asac> right. so you want to fix the kernel
[13:37] <asac> hmm
[13:37] <lool> asac: Alternatively, /sys might have more info
[13:37] <asac> yeah
[13:37] <jcristau> if you kernel fb driver doesn't tell you who it is, then fix that
[13:38] <lool> I'm +1 on that suggestion too, but there might be kernels in the wild already
[13:38] <asac> ok. are there convenience funcs for parsing /dev/fb already somewhere?
[13:38] <lool> Actually, there are
[13:38] <lool> asac: You mean /proc?
[13:38] <lool> asac: Don't think so
[13:39] <lool> asac: Just FTR, another (ugly) approach would be to prepend arch specific drivers to the list if you know they will fail and pass on to the default fbdev; but that's uglier than what's proposed here (might be less work, but we don't care, right? :-)
[13:40] <asac> lool: right. but i dont think we can assume they will fail
[13:40] <asac> thats why i think i could just check cpuinfo for now
[13:40] <asac> and prepend with arch specific drivers
[13:40] <asac> then long term we can fix /dev/fb info
[13:41] <asac> at least here in imx the driver doesnt really check if its supported ;)
[13:46] <lool> asac: Why not just recognize the crap you have in /proc/fb now, and also fix the contents and recognize the fixed output as an alternative?
[13:46] <lool> That's as much work as parsing cpuinfo since you have to check cpuinfo per board anyway
[13:46] <lool> but it's future proof
[13:48] <asac> lool: but is the current output in any way unique?
[13:49] <lool> asac: Not any more than cpuinfo
[13:49] <asac> hehe
[13:49] <asac> right. so ... yeah; sure
[13:49] <asac> will do that then ;)
[13:49] <lool> asac: I actually suspect cpuinfo is worse; because there were more boards than graphics drivers
[13:50] <lool> asac: Check the dove output, see if it's sane?
[13:50] <asac> thats the plan
[15:58] <Sarvatt> asac: can you point me at this xf86-video-imx driver?
[16:49] <asac> Sarvatt: havent published yet. will net you know when its avail
[16:49] <asac> let
[17:29] <Sarvatt> RAOF: did you see that they fixed a plymouth/ubuntu specific problem in nouveau git? http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=c642b9f7a13bdeecd0a83ddcbf6d6d4f2c287501
[17:33] <Sarvatt> just removes a harmless error message from the logs people are reporting bugs on -- [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
=== radoe_ is now known as radoe
[20:13] <bryceh> tjaalton, have you given thought to merging in xserver 1.7.6?
[20:30] <tjaalton> bryceh: yep, we should follow the stable branch
[20:33] <tjaalton> though maybe wait until it's released
[20:35] <tjaalton> there were a couple of issues with .901, one with selinux and a regression due to the fix for bug 25400 (apparently fixed now)
[20:35] <ubottu> Launchpad bug 25400 in mozilla-thunderbird-locale-fr "mozilla-thunderbird-locale-fr: new changes from Debian require merging" [Medium,Fix released] https://launchpad.net/bugs/25400
[20:35] <tjaalton> freedesktop bug 25400
[20:35] <ubottu> Freedesktop bug 25400 in Server/general "Fedora 12: Mouse cursor trapped inside menu button" [Blocker,Reopened] http://bugzilla.freedesktop.org/show_bug.cgi?id=25400
[20:49] <bryceh> tjaalton, ok great, it sounds fine to me so if you'd like to merge it in, go ahead whenever you feel it's ready
[20:49] <bryceh> otherwise I'll re-check again in a couple weeks
[20:50] <bryceh> tjaalton, jcristau, I'm looking at -evtouch currently.  We've unfortunately built up quite a bit on it in ubuntu, however looks like it's mainly fdi files which I gather are no longer relevant?
[20:50] <bryceh> or should those be ported to udev or xorg.conf.d rules?
[20:57] <tjaalton> bryceh: I'll merge once 1.7.6 or the next rc is released
[21:01] <tjaalton> bryceh: yeah the fdi files are useless as-is, and I'm not sure if they should be converted or not
[21:02] <tjaalton> leaning towards no, it has the calibrator anyway
[21:02] <bryceh> ok
[21:03] <bryceh> the only other bits besides the fdi stuff appears to be a couple tweaks to calibration stuff
[21:04] <bryceh> 21_more_calibration_fixups.patch and 20_fix_calibrate_submission_directions.patch
[21:16] <apachelogger> bryceh: ping
[21:20] <bryceh> the former patch debian took, the latter one doesn't sound that critical.  Time for a sync request
[21:20] <tjaalton> yeah
[21:21] <jcristau> \o/
[21:21]  * jcristau likes synced stuff :)
[21:22] <tjaalton> me too, there are plenty of candidates left :)
[21:22] <tjaalton> well, a handful at least
[21:22] <tjaalton> bryceh: lifeless should probably merge libx11 ;)
[21:22] <bryceh> tjaalton, heh
[21:24] <bryceh> I'd asked him to send his patches upstream when I saw him in portland, hmm
[21:24] <tjaalton> the klingon one was rejected
[21:24] <bryceh>   * Add klingon language definition.
[21:24] <bryceh> >_<
[21:25] <tjaalton> since the locale isn't known by libc
[21:25] <tjaalton> glibc
[21:25] <jcristau> and the glibc patch was rejected iirc
[21:25] <tjaalton> ah, ok :)
[21:26] <bryceh> +en_US.UTF-8/XLC_LOCALE:			la_AU.UTF-8
[21:26] <bryceh> what's la_AU?
[21:26] <apachelogger> bryceh: I am trying to debug bug 526919
[21:26] <ubottu> Launchpad bug 526919 in xorg-server "[Karmic] X crash due to xsetroot in startkde after recent update" [Undecided,Incomplete] https://launchpad.net/bugs/526919
[21:26] <bryceh> latin with an australian accent?
[21:27] <apachelogger> bryceh: but gdb doesnt like me and claims that any way I try to display/print privates it is at address 0x0
[21:27] <bryceh> Eu tu, mate?
[21:27] <jcristau> heh
[21:27] <tjaalton> :D
[21:27] <bryceh> apachelogger, heh, that doesn't sound good
[21:28] <tjaalton> fosters jacta est
[21:28] <bryceh> hehe
[21:28] <tjaalton> yeah I see the use case
[21:28] <apachelogger> bryceh: my thinking exactly :D espcially since both have an address according to the bt
[21:29] <bryceh> apachelogger, are you following my tips in comment #13?
[21:29] <apachelogger> yes
[21:29] <apachelogger> dpkg.log is just too massive to trace the issue
[21:30] <bryceh> apachelogger, it does sometimes happen that gdb doesn't produce useful results, so there are some alternate angles to doing debugging, like inserting print statements in the code
[21:30] <apachelogger> removing stuff from startkde lead to the conclusion that the crash can also be fixed by removing the ksplash from the startup sequence
[21:30] <bryceh> apachelogger, ok if you've made some progress at narrowing down what in startkde is triggering it, it would be good to update the bug report with a shorter use case
[21:30] <apachelogger> *nod*
[21:31] <bryceh> apachelogger, even if you can't pinpoint the exact issue, with a simple test case it may be possible to go upstream with the bug
[21:31] <apachelogger> bryceh: I'll poke some more into that, because I do not see me going after the issues with print statements unless the owner of the machine sends it to me :)
[21:32] <bryceh> ok
[21:32] <bryceh> yeah remote debugging is tough
[21:33]  * apachelogger is glad that the user granted him access to begin with :)
[22:04] <BUGabundo> evening