| tjaalton | bryce: great! | 06:27 |
|---|---|---|
| bryce | heya | 06:27 |
| tjaalton | morning | 06:28 |
| RAOF | I presume the nv driver isn't always this corruption-prone? | 06:48 |
| tjaalton | RAOF: how so? | 07:11 |
| RAOF | Turning on metacity's compositor appears to make everything not work; I think this is just because it's stupendously slow at drawing fullscreen transparency. | 07:13 |
| RAOF | But gnome-terminal gets corrupted, too. | 07:13 |
| RAOF | In that everytime a new character is written, or a link is underlined, it's white on an all-white background. | 07:14 |
| RAOF | Also, there seemed to be some confusion between usplash and nv, but I'm pretty sure that bug's been filed. | 07:15 |
| RAOF | At least nouveau still loves me | 07:58 |
| tjaalton | that's nice | 08:15 |
| tjaalton | :) | 08:15 |
| RAOF | I'll hunt down the bugs/file new ones after housework. | 08:16 |
| RAOF | But nouveau is _so much_ better than nv, at least for me. | 08:16 |
| RAOF | We should be using it by default. If only they'd nail down their kernel interface and release something! | 08:17 |
| tjaalton | indeed... | 08:17 |
| RAOF | At least they've got a full-time paid dev now. That should speed things up! | 08:18 |
| tjaalton | yeah | 08:18 |
| tjaalton | I think fedora is pushing to have nouveau KMS ready asap | 08:18 |
| RAOF | Which, IIUC, means nailing down the TTM/GEM/whatever MM stuff. | 08:19 |
| RAOF | At least, that's what I gathered was blocking it from my idling in #nouveau. | 08:19 |
| tjaalton | probably so | 08:20 |
| * RAOF doesn't have a nv5x, so has never tested the existing KMS support. | 08:20 | |
| RAOF | I tried testing the -ng branches for DRI2/tfp/compiz support. That didn't go well :) | 08:22 |
| tjaalton | what marketing names match nv5x? | 08:22 |
| RAOF | geforce 8+ | 08:22 |
| tjaalton | great, I've got one | 08:23 |
| RAOF | Oh, and whatever quattro boards match it, too. | 08:23 |
| RAOF | But quatros seem to have arbitrary product strings associated with them, so I couldn't even guess which ones are nv5x ;) | 08:23 |
| tjaalton | right | 08:23 |
| RAOF | I'm not sure if the nv5x KMS is merged in the drm master we have as nouveau-kernel-source, though. It may still be in -modesetting-101, or something. | 08:25 |
| tjaalton | modesetting-gem probably | 08:29 |
| tjaalton | -101 is dead AIUI | 08:29 |
| RAOF | Isn't modeseting-gem dead, too? | 08:33 |
| RAOF | But it died later, certainly. | 08:33 |
| tjaalton | dave seems to use it for radeon | 08:35 |
| tjaalton | but darktama's branch seems to be the one for nouveau | 08:36 |
| tjaalton | repository, even | 08:36 |
| tjaalton | hum, no | 08:37 |
| RAOF | That's the MM work, right? I think the initial KMS support went elsewhere. | 08:37 |
| tjaalton | yep.. | 08:37 |
| RAOF | In some branch of some repository there is some KMS support. Who knows where! | 08:38 |
| tjaalton | yeah :) | 08:39 |
| RAOF | I suspect the person who knows is darktama :) | 08:39 |
| tjaalton | nice, the intel pageflipping patch has six hunks that fail to apply | 08:43 |
| tjaalton | no idea what version it's against | 08:44 |
| tseliot | tjaalton: where can I get this version of libxcb? https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/317746 | 08:45 |
| ubottu | Launchpad bug 317746 in libxcb "Error when building libxcb 1.1.92 on jaunty" [Undecided,Incomplete] | 08:45 |
| tjaalton | tseliot: experimental | 08:45 |
| tjaalton | .93 builds | 08:45 |
| tseliot | aah, ok so there's no need for me to fix it. | 08:46 |
| tjaalton | haha, the automated message is hilarious | 08:46 |
| tseliot | good | 08:46 |
| tjaalton | "Hi bryceharrington," | 08:46 |
| tseliot | hehe he's talking to himself | 08:46 |
| tjaalton | me, myself and LP | 08:46 |
| tseliot | a title for a new film :-P | 08:47 |
| bryce | rotfl | 08:49 |
| tjaalton | intel builds now, but really needs the new mesa until it can be uploaded, because starting gnome hangs the machine | 10:11 |
| tjaalton | er, starting compiz that is | 10:11 |
| bryce | well, progress at least | 10:30 |
| * Ng is entirely happy to throw jaunty live CDs at his 3 or 4 different Intel chipset machines, whenever the versions of driver/mesa/etc are a bit settled :) | 11:00 | |
| Ng | you might even say I was "actually rather keen" to do that, since I want them all to work :D | 11:00 |
| Ng | (which is a roundabout way of asking if, when the pieces have landed, you guys could post on the planet asking people to test) | 11:03 |
| pcjc2 | hi guys.. any more info on the Xrandr loop bug? | 11:23 |
| pcjc2 | I'm just prodding it with a stick now. | 11:23 |
| pcjc2 | Seems that whilst this perhaps isn't causing the loop, I'm getting a monitor change event from GDK each time I step brightness up and down | 11:24 |
| pcjc2 | changing using the hot-key, I get an xrandr event, monitor change event, then another xrandr, and another monitor-change event | 11:25 |
| pcjc2 | Changing using xrandr directly, I'm seeing an xrandr event (notifying the property change), and a monitor change event from GDK | 11:26 |
| pcjc2 | I suspect GDK is emitting that event when it shouldn't - looking at the code, it doesn't differentiate property change events from ones which actually effect the displays in a way suggested by the monitor change event | 11:27 |
| pcjc2 | "The ::monitors-changed signal is emitted when the number, size or position of the monitors attached to the screen change." | 11:27 |
| pcjc2 | *** infact, I'm not sure this is an infinite recursion loop at all... | 11:29 |
| pcjc2 | I wonder if it is gnome-power-manager incrementing the backlight in tiny little steps | 11:30 |
| pcjc2 | (which it does) | 11:30 |
| pcjc2 | the underlying bug is that each step is taking a very long time because its causing the hardware to be re-probed | 11:30 |
| pcjc2 | (Which may be due to buggy applications watching for Xrandr notify events, then querying the hardware for each it recieves) | 11:31 |
| Makdaam | hi, how do I get the current config out of Xorg? my xorg.conf is empty | 11:32 |
| pcjc2 | empty xorg.conf means everything is auto-detected | 11:32 |
| pcjc2 | I'm not sure if there is a way to extract an equivalent config | 11:32 |
| pcjc2 | you could look at /var/log/Xorg.0.log for clues though | 11:33 |
| Makdaam | so rewriting the xorg.conf by hand is the next best thing? | 11:33 |
| Makdaam | ok, thanks | 11:33 |
| pcjc2 | sure, but only if you need to specify some non-standard config | 11:37 |
| pcjc2 | it is supposed to work without a config file unless you have an unusual case | 11:37 |
| pcjc2 | jcristau? | 11:41 |
| tjaalton | hmm, monospace 7 looks even better now | 12:18 |
| pcjc2 | Did the font change, or has something else? | 12:21 |
| tjaalton | I'm not sure :) | 12:21 |
| tjaalton | it's looks a bit smaller, but still is crisp and easy to read | 12:22 |
| tjaalton | meaning that I can fit more in my 10x7 screen | 12:22 |
| pcjc2 | can't be bad | 12:22 |
| pcjc2 | I'm just debugging Xrandr stuff | 12:23 |
| pcjc2 | something nasty is going on | 12:23 |
| tjaalton | thanks for doing that :) | 12:23 |
| tjaalton | it doesn't affect my i965 | 12:23 |
| pcjc2 | I'm not sure if there are any cases where this is a good thing, but GDK is emitting a "monitors-changed" event for every RRNotify_OutputProperty event recieved | 12:24 |
| pcjc2 | Some apps are listening out for those - as far as I can tell, and retaliate by probing the hardware - which is very expensive | 12:24 |
| pcjc2 | what Intel driver are you running on the i965? | 12:25 |
| tjaalton | currently 2.6.0 | 12:25 |
| pcjc2 | ok, I've not updated yet.. was running git HEAD | 12:25 |
| pcjc2 | let me fetch 2.6.0 and see if that changes things | 12:25 |
| tjaalton | it doesn't build unless you apply the patch from freedesktop bug 19591 | 12:29 |
| ubottu | Error: Could not parse XML returned by Freedesktop: timed out (http://bugzilla.freedesktop.org/xml.cgi?id=19591) | 12:30 |
| pcjc2 | Just fetched the package from Xorg-edgers and am rebuilding it | 12:33 |
| pcjc2 | (Its marked as being for intrepid) | 12:33 |
| pcjc2 | hmm, the upstream ChangeLog for that package ends at Bump version 2.5.99.2 | 12:35 |
| tjaalton | it needs to be manually updated | 12:35 |
| pcjc2 | something they broken in the released tarball? | 12:35 |
| tjaalton | I'm not sure if the tarball ships it at all | 12:36 |
| tjaalton | the edgers package is probably built from git | 12:37 |
| pcjc2 | ok - fair enough | 12:37 |
| pcjc2 | A simple patch to GTK fixes the Xrandr issues | 12:59 |
| pcjc2 | Just tell it not to emit a monitors-changed signal for any Xrandr output property notifications | 13:00 |
| pcjc2 | I don't know if that is the "right thing" or not, but it seems vaguely sensible | 13:00 |
| pcjc2 | no monitors-changed signal -> gnome-power-manager doesn't perform an expensive probe for every brightness change | 13:00 |
| pcjc2 | turns out it probably wasn't an infinite loop.. just a lot of small steps to give a fading effect | 13:00 |
| tjaalton | great :) | 13:03 |
| tjaalton | do you have any idea why it was triggered by updating libxrandr? | 13:03 |
| pcjc2 | no, but if you know which libxrandr versions the update was between, I'll grab the git repository and look over the appropriate delta | 13:04 |
| tjaalton | between 1.2.3 and 1.2.99.2 | 13:09 |
| pcjc2 | only 14 commits.. shouldn't be too hard to track down | 13:10 |
| pcjc2 | I'm not convinced that there wasn't a problem before though | 13:10 |
| pcjc2 | My brightness changing problem existed before that librandr update | 13:10 |
| pcjc2 | hmm... | 13:11 |
| pcjc2 | there was an interesting bug fixed between those versions, regarding the event's "screen" property | 13:12 |
| pcjc2 | I noticed GDK tested if screen != NULL before processing the event | 13:12 |
| pcjc2 | I wonder if that disposed of some events in the old, buggy events case | 13:13 |
| pcjc2 | oo... cool | 13:16 |
| pcjc2 | new for Xrandr1.3, there is a new request which allows programs to retrieve the "current" resources without causing a hardware probe | 13:16 |
| pcjc2 | gah, it was the "window" property of the event which had a bug.. never mind | 13:18 |
| tjaalton | heh | 13:18 |
| pcjc2 | .... but the screen was determined from the window | 13:20 |
| pcjc2 | its really not obvious whether that could have caused the problem or not | 13:22 |
| tjaalton | I bet :) | 13:27 |
| * pcjc2 really wishes GTK was in a GIT repository so I could do some decent history diving | 13:39 | |
| tjaalton | it'll be.. | 13:47 |
| pcjc2 | right.. I think I'll just post findings so far to Xorg, and send some info to gtk-devel | 13:52 |
| pcjc2 | Now Xrandr 1.3 is available, those apps shouldn't be querying the config on notification... assuming the fact a notification occurred means that the Xserver knows the new state, you can just use the new API to retrieve the current config | 13:53 |
| tjaalton | xserver 1.6rc1 seems to work.. will release in a minute | 14:04 |
| tseliot | pcjc2: but gnome-desktop and gnome-control-settings are gtk apps which use xlib. Gnome-desktop is maintained in svn and we even have a bazaar branch which keeps track of the changes in the svn repo | 14:14 |
| tseliot | ah, I didn't read the "GIT" word | 14:15 |
| tseliot | never mind | 14:15 |
| tseliot | pcjc2: I think that the idea behind using notifications in the gnome randr applet was to have the cairo widget automatically updated (in theory) when the outputs change | 14:20 |
| pcjc2 | did you see the last I posted on xorg@... | 14:20 |
| tseliot | no, I didn't | 14:20 |
| * tseliot checks the mailing list | 14:20 | |
| pcjc2 | You can make the problems go away if you teach GDK not to emit a "monitors-changed" signal when receiving an Xrandr output property change notification. | 14:21 |
| pcjc2 | With Xrandr 1.3, there is a new API which should avoid the server re-probing hardware. You could use that in response to a notification, since presumably if the server is notifying _you_ of a change, you then just need to ask it what its current understanding of the hardware is.. not use the old API which instructs it to re-probe | 14:22 |
| tseliot | ok, so it was GDK. I wasn't aware of the change in the RandR API | 14:28 |
| tseliot | aah you're referring to RRGetScreenResourcesCurrent() | 14:31 |
| tseliot | yes, that should be cheaper | 14:31 |
| pcjc2 | I've not actually tested the various versions of libXrandr people bisected this problem to.. | 14:32 |
| pcjc2 | would have to un-patch / reinstall old GTK, then build both Xrandr versions to have a poke and see if GDK behaves differently | 14:32 |
| tseliot | I could try patching g-s-d and g-p-m to use RRGetScreenResourcesCurrent instead of RRGetScreenResources | 14:33 |
| pcjc2 | ordinarily I'd be curious, but part of me thinks we should just approach the necessary people to fix based on what we have now | 14:33 |
| pcjc2 | that would be cool | 14:33 |
| pcjc2 | I think g-s-d calls some other costly probe too, but I'm not sure | 14:33 |
| pcjc2 | with more than one client firing requests in response to the notifications, it became difficult to tell just what was expensive, and what wasn't | 14:34 |
| tseliot | heh | 14:34 |
| tjaalton | libxcb 1.1.93 uploaded, a fakesync of libx11 will follow | 14:36 |
| tseliot | great | 14:36 |
| tseliot | if it builds :-P | 14:36 |
| tjaalton | .92 didn't build, .93 should | 14:36 |
| tseliot | otherwise bryce will have another conversation with himself | 14:37 |
| tjaalton | yeah :) | 14:37 |
| tjaalton | bryce: for some reason dch doesn't add spaces to the author when you modify the changelog (you have "[name]", instead of "[ name ]"), maybe that's one source of your git griefs?-) | 14:43 |
| tjaalton | afk, floorball -> | 14:49 |
| tseliot | pcjc2: I can't reproduce the problem with my new patches | 14:54 |
| tseliot | seb128 will be happy :-) | 14:55 |
| * Alexia_Death grumbles... | 14:55 | |
| tseliot | Alexia_Death: what's the matter? | 14:55 |
| Alexia_Death | Theres an annoying bug in X that is not really debuggable. | 14:56 |
| Alexia_Death | my X dies in graphcs driver code if I use my tablet for some time. | 14:56 |
| Alexia_Death | and it happens the same wether i use nv or nvidia | 14:56 |
| tseliot | did you try vesa? | 14:56 |
| tseliot | just for testing | 14:57 |
| Alexia_Death | I cant use vesa sensibly on my laptop... | 14:57 |
| Alexia_Death | It is not an on demand crash | 14:57 |
| tseliot | ah, ok | 14:57 |
| Alexia_Death | It usually happens when I start drawing. | 14:57 |
| Alexia_Death | and have done it for a little bit. | 14:58 |
| Alexia_Death | and usually costs me my work. | 14:58 |
| Alexia_Death | I have two dumps for it but they are not really informative. | 14:58 |
| Alexia_Death | logs with stack traces that is | 14:59 |
| tseliot | did you try with gdb? https://wiki.ubuntu.com/X/Backtracing | 14:59 |
| pcjc2 | tseliot: What patches? | 15:01 |
| pcjc2 | Using the new Xrandr 1.3 APIs to avoid the costly probe? | 15:01 |
| Alexia_Death | tseliot: difficult... but I think I know why my trace is useless. | 15:01 |
| Alexia_Death | tseliot: I dont think I have nv debuging symbols | 15:02 |
| tseliot | pcjc2: the one which replace XRRGetScreenResources with XRRGetScreenResourcesCurrent | 15:02 |
| tseliot | s/one/ones/ | 15:02 |
| Alexia_Death | tseliot: isnt jaunty repros supposed to contain debugging symbols for nv? | 15:04 |
| tseliot | Alexia_Death: I don't know as I don't maintain it. Either tjaalton or bryce should know it though | 15:05 |
| pcjc2 | tseliot: ok - cool. Although if they were to go upstream, I guess they'd need to be conditional on detecting Xrandr 1.3 being available | 15:05 |
| Alexia_Death | tseliot: Ok. I will ask one of them... They dont seem to tho... | 15:05 |
| pcjc2 | I still think GDK is emitting more events than it should | 15:06 |
| pcjc2 | not sure who to bug about that | 15:06 |
| tseliot | pcjc2: yes, but g-s-d and g-p-m use xlib directly | 15:06 |
| pcjc2 | I was hoping someone might pick up the thread. Soren Sandmaan showed an interest already | 15:06 |
| pcjc2 | g-p-m also handles the GDK event | 15:06 |
| tseliot | where? | 15:07 |
| tseliot | maybe I missed it | 15:07 |
| pcjc2 | g-p-m is pretty impotent in responding to the notifications in fact, when I checked out the source | 15:07 |
| pcjc2 | the code was in an if (FALSE) {} | 15:07 |
| albert23 | Alexia_Death: you can use the dbgsym from here: http://ddebs.ubuntu.com/pool/main/x/xserver-xorg-video-nv/ | 15:07 |
| tseliot | ok, let me check | 15:08 |
| pcjc2 | but.. in when it first sets up the Xrandr stuff, it calls gpm_brightness_xrandr_update_cache | 15:08 |
| Alexia_Death | tjaalton: why there are no debugging symbols for nv in jaunty repros? | 15:08 |
| Alexia_Death | albert23: how do I use them? | 15:08 |
| pcjc2 | which connects to "monitors_changed" if it hasn't done so already | 15:09 |
| albert23 | Alexia_Death: download the deb and install with dpkg -i | 15:09 |
| Alexia_Death | they are ddeb-s not just debs.. why? | 15:09 |
| pcjc2 | <debug>deb | 15:10 |
| Alexia_Death | Ooh... | 15:10 |
| Alexia_Death | OK:) | 15:11 |
| Alexia_Death | Hopefully now I get some more informative dumps out of my crashes... | 15:11 |
| pcjc2 | might need to fetch a load of debug packages | 15:11 |
| pcjc2 | libc etc.. as well | 15:11 |
| pcjc2 | otherwise the back-traces can be incomplete | 15:12 |
| Alexia_Death | Its really annoying btw that I have to go to console to coppy out the log or my next log-in will overwrite it... | 15:12 |
| pcjc2 | some of them are in the repos as libfoo-dbg though | 15:12 |
| pcjc2 | so you don't necessarily need the -dbgsym version | 15:12 |
| Alexia_Death | I have most that are in repros already | 15:12 |
| pcjc2 | Xorg.0.log.old ? | 15:12 |
| Alexia_Death | pcjc2: yes. its overwritten the moment I log in. | 15:12 |
| pcjc2 | ok - didn't know it fired up a new X server _after_ GDM | 15:13 |
| Alexia_Death | Crash, grm starts, crash log becomes .old, I log in the trace is lost... | 15:13 |
| Alexia_Death | It would be really neat if gdm stuffed after crash logs somewhere itself... | 15:14 |
| tseliot | pcjc2: aah, you meant that it uses gdk to register the event type and add a filter. Yes, this is correct. | 15:14 |
| pcjc2 | no | 15:14 |
| pcjc2 | it uses g_signal_connect (G_OBJECT (gscreen), "monitors_changed", ... | 15:15 |
| pcjc2 | line 610, gpm-brightness-xrandr.c | 15:15 |
| pcjc2 | it is that callback which is / was causing the slow probe on | 15:15 |
| pcjc2 | brightness changes, since GDK is emitting "monitors_changed" for every brightness change | 15:15 |
| pcjc2 | (Which doesn't fit with its documented function) | 15:16 |
| tseliot | yes, that's a property change | 15:16 |
| pcjc2 | the documentation for "monitors_changed" doesn't say it will get called for property changes | 15:16 |
| pcjc2 | The ::monitors-changed signal is emitted when the number, size or position of the monitors attached to the screen change. | 15:17 |
| tseliot | in theory it should be correct if, for example, you change TV format (which is a property) | 15:18 |
| pcjc2 | not.. this event will fire for every property change.. including one time for each of the hundreds of steps used when fading the backlight brightness | 15:18 |
| pcjc2 | I had guessed there might be causes where that signal is needed | 15:18 |
| pcjc2 | but the description of the signal is still wrong | 15:19 |
| tseliot | that's easy to change ;) | 15:19 |
| pcjc2 | and the changes to use the "Current" version of the Xrandr getters makes the performance hit go away | 15:20 |
| pcjc2 | It still feels like it should be possible to filter those monitor-changed events to avoid getting swamped in backlight events | 15:20 |
| pcjc2 | no point waking up so many processes to do essentially nothing | 15:20 |
| tseliot | ok, so are you suggesting something like output-properties-changed? | 15:22 |
| tseliot | which should be separate from monitor-changed | 15:23 |
| tseliot | in GDK, I mean | 15:23 |
| pcjc2 | I'd leave that sort of design decision to those who know the realm better | 15:24 |
| pcjc2 | but its not a bad idea. | 15:24 |
| pcjc2 | Even if you added "output-properties-changed", you might need to add detail about _what_ property you cared about | 15:24 |
| tseliot | that would be nice to have | 15:25 |
| tseliot | I guess it will take some time for developers to decide and implement this thing | 15:25 |
| tseliot | in the meantime I'll write a patch for gnome-desktop and gnome-power-manager which checks the version of RandR and uses Current accordingly | 15:26 |
| tseliot | and of course I'll give credit to you for suggesting the use of the less expensive call | 15:26 |
| pcjc2 | I think most credit deserves to go to the implementer there... | 15:28 |
| tseliot | hehe that's right | 15:28 |
| jcristau | monitors-changed firing on property changes sounds like a bad idea | 15:53 |
| tseliot | jcristau: the only reason I can think of is that of tv format. But of course as pcjc2 said, it would be nice to be able to separate events | 15:56 |
| pcjc2 | tseliot: Are you Alberto Milone? | 16:32 |
| tseliot | pcjc2: yes, I am | 16:33 |
| pcjc2 | ok- no need to reply back to your email then ;) | 16:33 |
| tseliot | no, I guess not ;) | 16:33 |
| pcjc2 | Do you have an upload for the new g-s-d and g-p-m packages? | 16:34 |
| tseliot | I'm writing things as we speak (so that only if X supports RandR 1.3 we use Current) | 16:35 |
| pcjc2 | cool! | 16:35 |
| tseliot | maybe we should check the version at runtime instead of doing it at compilation timeù | 16:37 |
| tseliot | time | 16:37 |
| pcjc2 | since it is a dynnamic thing, yes | 16:44 |
| pcjc2 | although I doubt many users would be connecting to a remote X server using gnome-power-manager | 16:44 |
| pcjc2 | IIRC, GDK has some code to check the version - if a cheat-sheet would help | 16:44 |
| tseliot | I would like to call that function (e.g. XRRQueryVersion) only once though. I don't think we need to check the version every time an event is triggered | 16:49 |
| pcjc2 | no - that would be roundtrips - which would be bad | 16:49 |
| crevette | hey | 18:44 |
| crevette | it seems X crashed, but bug reporting with apport doesn't work apparently | 18:44 |
| crevette | hmm | 18:44 |
| crevette | anyway the stackstrace is useless | 18:44 |
| marijus | hello, i compiled 2.6.29-rc2 kernel with kms support and use latest xorg and intel on jaunty a.t.m. But i get a corrupted screen instead of GDM. KMS seems to work tho... anyone want to help? | 20:50 |
| tjaalton | marijus: I guess you'd get more help from #intel-gfx | 21:20 |
| tjaalton | doubt many have tested kms here | 21:21 |
| marijus | tjaalton, i just posted there... thanks | 21:21 |
| tjaalton | np | 21:21 |
| bryce | crevette: any ideas on why apport isn't reporting the crash? I've noticed that not as many crash reports have been coming in as I expected | 21:24 |
| crevette | bryce: I have no idea at all, all my bugs reported end with a warning message | 21:25 |
| bryce | was anything put into /var/crash? | 21:25 |
| tjaalton | bryce: I'll be able to fix the mesa build tomorrow, it turns out to be pretty simple | 21:26 |
| bryce | tjaalton: ah good to hear | 21:27 |
| tjaalton | bryce: also, I fakesynced libx11 to get it out at the same time with libxcb | 21:27 |
| tjaalton | we can sync both when there are new releases | 21:27 |
| bryce | I'm about to head down to see my dad and will be gone through Wednesday. Dunno how internet connectivity will be. Might try to get some more of the xorg.conf backup/recovery stuff coded if I have time. | 21:27 |
| bryce | tjaalton: good deal, yeah it'd be nice to get all these merges through | 21:28 |
| tjaalton | ok, take your time.. I'll deal with the fallout ;) | 21:28 |
| tjaalton | I noticed that I've had xkeyboard-config merge sitting idle for a looong time.. will check it out too | 21:29 |
| Alexia_Death | kmail is not installable because of akonadi btw... | 21:31 |
| Alexia_Death | oops | 21:31 |
| Alexia_Death | wrong chan | 21:31 |
| Alexia_Death | sory | 21:31 |
| bryce | yeah I started looking at the xkeyboard-config merge yesterday. Noticed there's a *bunch* of conflicts | 21:32 |
| bryce | what I was thinking was we should work on getting all those changes upstream and drop everything else so we can just sync | 21:32 |
| bryce | upstream is reasonably responsive when we forward bugs and changes, so no reason we can't get into a position where we can give them our changes and just sync | 21:33 |
| bryce | anyway, put that low on your priority list, and I can take care of it when I get back if you don't get to it | 21:34 |
| crevette | bryce: I didn't notice your reply | 21:49 |
| crevette | bryce: http://pastebin.ubuntu.com/106069/ | 21:51 |
| bryce | ok, taking off, cya | 22:19 |
| tseliot | take care bryce | 22:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!