[07:19] <tjaalton> jcristau: oh, nice.. didn't spot that one
[07:21] <bryce> heya
[07:21] <tjaalton> howdy
[07:22] <tjaalton> no archive-admin action yet, it seems :)
[07:22] <bryce> yeah :-/
[07:22] <bryce> I did mention the sync req's to rick
[07:22] <bryce> if they don't get done in the next day I can ping some people
[07:23] <tjaalton> most of the protos should be autosynced anyway, since they entered testing yesterday
[07:23] <tjaalton> but I need to merge xutils-dev so they build
[07:27] <tjaalton> maybe I should upgrade my laptop as well..
[07:28] <tjaalton> before the madness
[08:14] <tjaalton> mvo: hey, could the "failed to install" bugs attach the output of df to the bug. I suspect most of them are due to full root partition..
[08:18] <tjaalton> 'df -l' would do
[08:56] <mvo> hey tjaalton
[08:56] <mvo> tjaalton: sure
[08:56] <mvo> tjaalton: good idea
[08:56] <mvo> hm, update-manager should check (well, approximate) that now, however apt itself does not
[09:00] <tjaalton> mvo: great, thanks
[09:09] <tjaalton> mvo: is it generally ok to drop Breaks/Depends/.. on packages from a past devel version (so that the version was not in the final release)?
[09:10] <tjaalton> since I don't think we support upgrades from a past alpha
[09:13] <mvo> yeah, that should be fine
[09:14] <tjaalton> good
[09:41] <mvo> tjaalton: df -l commited to my bzr branch, thanks
[09:41] <tjaalton> mvo: excellent :)
[10:01] <Unggnu> hi all
[10:02] <Unggnu> I have read that the big X/Kernel changes are scheduled before Alpha 1. So it doesn't make sense/is dangerous before that to upgrade a Lucid Testing environment?
[10:03] <Unggnu> Btw. which gain do we have through noveaou. I mean it has no 3D support yet afaik and KMS is good but most people would switch to the proprietary driver anyway.
[10:04] <Unggnu> I mean nv is quite stable and has an alternative or are there many bugs for nv?
[10:04] <tjaalton> bah, I upgraded an hour ago
[10:04] <Unggnu> tjaalton, So the big changes hasn't happened yet or already? :)
[10:04] <tjaalton> nv is pretty much dead
[10:04] <tjaalton> Unggnu: not yet
[10:04] <Unggnu> tjaalton, But they still make it work for new cards, 2d and xv or not anymore?
[10:04] <tjaalton> waiting on syncs from debian, and xorg & xorg-server merges to be uploaded
[10:05] <tjaalton> Unggnu: it has modesetting bugs that wont be fixed
[10:05] <Unggnu> Ok, noveau would be great for old Nvidia cards that has no proprietary driver anymore but I doubt that it is already fast or so stable
[10:05] <tjaalton> it's fast for 2D
[10:05] <Unggnu> ok, I just thought it is a tough decision for LTS
[10:05] <tjaalton> and some people can't get nv up at all
[10:06] <Unggnu> I mean radeon driver is in development since a long time and still has no Powerplay
[10:06] <Unggnu> which makes the computer pretty loud and uses much energy
[10:07] <Unggnu> I don't know if the nv has the pendant.
[10:07] <jcristau> it doesn't
[10:07] <Unggnu> But with the edgers package KMS already works and textured video (still with tearing though).
[10:08] <Unggnu> Ok, we will see how it works out. I haven't any Vvidia card anymore, at least not in use.
[10:10] <Unggnu> Through ChromeOS and developments like this Nvidia will probably change their decison, at least I hope so
[10:10] <Unggnu> The pressure through Dell has already worked in some areas afaik
[10:11] <Ng> chromeos would be more likely to be used on a tegra type platform I would have thought?
[10:12] <Unggnu> Ng, on Netbooks and in future it should be combine with Android afaik. Anyway Nvidia also produces chips for this devices afaik.
[10:12] <Unggnu> If they only use open source drivers they have to change
[10:13] <Ng> sure, the tegra, but I'm assuming wildly that it's very different to their desktop offerings
[10:14] <Unggnu> synergy ;)
[10:22] <Unggnu> KMS seems to work with nouveau even for nvidia TNT, that's cool.
[10:22] <Unggnu> So Debian plans to use Nouveau in SID too?
[10:23] <tjaalton> probably not as default. that would mean kernel changes
[10:23] <tjaalton> which is the painful part
[10:25] <Unggnu> yes, I have heard
[10:26] <Unggnu> Radeon is also pretty fast without KMS
[10:26] <Unggnu> but I think this was fixed lately
[10:29] <Unggnu> Got to go, thanks for the information, bye.
[13:48] <diverse_izzue> hi all, using kernel 2.6.32 from the mainline kernel ppa and the xorg-edgers ppa on karmic, i get no dri. xorg.log says:(EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch. [dri] radeon kernel module version is 2.0.0 but version 1.17.0 or newer is needed. [dri] Disabling DRI.
[13:48] <diverse_izzue> any ideas?
[13:56] <diverse_izzue> i should say that i also enable kms
[13:56] <tjaalton> does .31 work?
[13:57] <diverse_izzue> tjaalton, i'll check that, just a minute
[14:03] <diverse_izzue> tjaalton, same thing with 2.6.31-15 from karmic repos
[14:04] <tjaalton> don't use kms, it seems
[14:05] <diverse_izzue> it does use KMS i believe
[14:05] <tjaalton> but if you use modeset=1, DRI works
[14:05] <tjaalton> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/394263
[14:05] <tjaalton> erm, =0
[14:06] <diverse_izzue> i'm quite sure it's someting in the updated  X stack, because i get dri with the X stack from karmic + KMS
[14:06] <tjaalton> mesa then
[14:07] <tjaalton> google for the error, there are tons of hits
[14:07] <jcristau> diverse_izzue: your issue is either your ddx driver doesn't support kms, or there's a race when loading the radeon kernel module which makes this fail.
[14:07] <diverse_izzue> jcristau, my ddx driver is the most recent one from the xorg-edgers ppa
[14:07] <diverse_izzue> so probably number 2
[14:07] <diverse_izzue> what to do about that?
[14:08] <jcristau> modeset=0, or load radeon earlier
[14:08] <diverse_izzue> how to load radeon earlier?
[14:13] <diverse_izzue> have to go to the lab, back in a little while...
[14:22] <tormod> bryce, can you join our radeon kms discussion on #ubuntu-kernel please?
[14:24] <tjaalton> doubt he's awake yet
[14:25] <diverse_izzue> the xorg wiki talks about the error: http://www.x.org/wiki/radeonBuildHowTo.
[14:25] <tormod> hmm doesn't his son keep him awake all the time?
[14:25] <tjaalton> hehe
[14:26] <jcristau> tjaalton: i'd forgotten xft.. damn lib not starting with lib.  fixed now, on its way to sid.
[14:27] <tjaalton> jcristau: hehe, time to rename it? :)
[14:27] <tjaalton> it's libXft upstream
[14:27] <tjaalton> so it would be even consistent :)
[14:27] <tormod> diverse_izzue, it's not what they say on the x wiki
[14:28] <diverse_izzue> tormod, but what...?
[14:38] <tormod> diverse_izzue, the reason for that error message can be what the x wiki says, and it can be what my page says
[14:38] <tormod> on Ubuntu, the x wiki explanation is not applicable since we build with the kms api
[14:41] <apw> bryce, yo ... we are discussing the change to enable radeon kms on #u-k
[14:41] <tormod> apw, I tried to wake him too :)
[14:44] <apw> heheh
[14:45] <tjaalton> so how does intel initialize early enough, but not radeon?
[14:45] <tjaalton> is the module in initramfs?
[14:45] <tjaalton> AIUI it isn't
[14:48] <tormod> tjaalton, is the i915 force loaded somewhere, not by the X server?
[14:48] <tjaalton> tormod: maybe, I don't know
[14:49] <tormod> I just remember there was this i915 and fbcon(?) issues in karmic before release
[14:50] <tormod> wasn't there some kind of race that got sorted out?
[14:50] <tjaalton> apw: ^
[14:50] <tjaalton> or should Keybuk know?
[14:50] <tjaalton> things progress too fast for me :)
[14:50] <tormod> I asked Keybuk about all this some days ago
[14:51] <tormod> he did not know
[14:51] <tjaalton> heh ok
[14:51] <tormod> I thought I had more time to sort it out anyway :)
[14:51] <apw> its odd, we load the drivers which do that very early, in responce to udev events for them
[14:51] <apw> we then boot ... slowly for several seconds, then start X
[14:52] <apw> how it could not be ready in time i do not know
[14:52] <tormod> radeon does not load by itself
[14:52] <tormod> I tried, see my gdm.conf on the wiki page
[14:52] <apw> the radeon driver does not have module aliases ?
[14:52] <tormod> if I remove "modprobe radeon" X does not start
[14:53] <tjaalton> tormod: but kms worked?
[14:53] <tormod> if I then manually modprobe radeon, boom X starts
[14:53] <tjaalton> I mean, how can it work without radeon?
[14:53] <tormod> no kms does not activate before
[14:53] <apw> it can't work without radeon, but radeon should load automatically by itself
[14:53] <tjaalton> right
[14:53] <apw> if its done right
[14:53] <tjaalton> it takes 2.5s for i915 to load here
[14:54] <apw> but that is sychonous
[14:54] <apw> so its done by the time X starts
[14:54] <tormod> historically only the X server would make radeon load
[14:54] <tormod> and only if the X server uses "radeon" DDX I guess
[14:54] <tormod> and not if it uses fglrx
[14:55] <tormod> so it's a chicken and hen element to this
[14:55] <tormod> *egg
[14:55] <apw> #if defined(CONFIG_DRM_RADEON_KMS)
[14:55] <apw> MODULE_DEVICE_TABLE(pci, pciidlist);
[14:55] <apw> #endif
[14:55] <apw> if KMS is turned on in the build (which it is) then we should load the driver if the id's are listed
[14:55] <tjaalton> ha
[14:56] <tjaalton> maybe that would do it?
[14:56] <apw> that is the current settings
[14:56] <tormod> that is the current settings since a long time right?
[14:56] <apw> so if you disabe the gdm upstart job, we'd expect to see it loaded by udev
[14:56] <tjaalton> tormod: has anyone tried with a kernel where it's enabled?-)
[14:56] <apw> all of karmic yes
[14:56] <apw> thats enabled, with or without modesetting selected
[14:56] <tormod> tjaalton, CONFIG_DRM_RADEON_KMS means support for KMS
[14:57] <tormod> not that it is on by default
[14:57] <tjaalton> ah right
[14:57] <apw> yep we have the code ON but disabled by option
[14:57] <tormod> well, it does not load by itself here
[14:57] <apw> then the module aliases are wrong i would guess
[14:57] <tormod> what can I check?
[14:58] <tormod> wait I know
[14:58] <apw> if you don't load it by default
[14:58] <apw> then you can see what udev sees in its logs /var/log/udev
[14:59] <tormod> my card is 1002:5653 and I see pci:v00001002d00005653sv*sd*bc*sc*i* in modinfo
[14:59] <apw> tormod, there are a lot of id's listed
[14:59] <apw> nope not listed
[14:59] <tormod> is /var/log/udev kept logged to?
[15:00] <apw> its a live file i believe
[15:00] <apw>    This file is auto-generated from the drm_pciids.txt in the DRM CVS
[15:00] <apw>    Please contact dri-devel@lists.sf.net to add new cards to this list
[15:00] <apw> ok the list of supported id's has that comment in it
[15:01] <tormod> apw, not listed where? I see it in modinfo
[15:01] <apw> yeah ... hrm
[15:01] <apw> it is in there
[15:03] <apw> tormod, i see the ids in the source but not in the modules.alias file
[15:04] <tormod> anyway, it can still be racy since kms init takes ~0.6s and X starts earlier and earlier
[15:04] <apw> tormod, wa
[15:04] <apw> tormod, what is the solution to that ... 
[15:05] <tormod> apw, you saw my gdm.conf hack?
[15:05] <tormod> there must be a real solution though
[15:06] <tormod> drmCheckModesettingSupported in libdrm should not return before init is finished maybe
[15:08] <tormod> if there's a way from userspace to see if drm init has finished regardless of kms support
[15:08] <apw> we have an issue that we want X to start earlier to get things working qucker, but that makes people do init async, and we have no way to work out if its meant to be coming
[15:08] <apw> the issue is that there is no way to know if the device will find an output and modeset it or not
[15:11] <tormod> we could make drm emit an event and let gdm wait for it, but then if you boot something where there is no drm hw...
[15:12] <apw> you need to know its done whether it did anything or not
[15:13] <tormod> I am tending towards fixing radeon DDX, it knows it has a drm device, just have to wait for it to finish init before probing it
[15:16] <tormod> I wonder if /dev/dri/card0 shows up before it is fully initialised?
[15:17] <tormod> in other words, if /dev/dri/card0 shows up before /sys/class/.../drm/controlD* which is the KMS marker it probes for
[15:19] <tormod> I mean /sys/bus/pci/devices/.../drm/controlD*
[15:26] <tormod> yes it does, that is obvious from Xorg.0.log
[16:25] <tormod> (more loud thinking in #radeon)
[17:05]  * tormod notices libdrm 2.4.16 is out!
[18:01] <apw> bryce, yo!
[18:02] <apw> i reenabled ati kms, tormod seems to think that userspace is not ready, what do you want the Alpha-1 kernel to have  as the default, on or off?
[18:10] <tormod> apw, I have some ideas to avoid potential races if the module already has been loaded and is under initialisation, but what about the fact that radeon is not loaded by itself?
[18:15] <apw> its sounding like you guys just need to do more before this is ready
[18:15] <apw> so i'll just turn it off again
[18:16] <tormod> apw, yes I agree. we could add some quick workarounds now, but we need to find a better solution
[18:17] <apw> we 
[18:17] <bryce> heya apw
[18:17] <apw> i'll put together an email tomorrow saying that we're turning it off
[18:17] <tormod> would be good if more of you devs would run lucid and latest bits and KMS though
[18:17] <apw> and you guys can argue about how to fx it for alpha2
[18:18] <apw> we all sensibly have intel
[18:18] <tormod> if I am the only one who have tested KMS, I would not enable it for everybody ATM
[18:18] <apw> then we'll never enable it, which seems like no progress
[18:18] <apw> bryce, talking about radeon
[18:18] <tormod> yes that's bad that you all use the same hardware
[18:18] <apw> i enabled it in the -6 kernel and its seeeming its not working
[18:19] <apw> userspace issues, so i wanted to confirm whether i should switch it off for a1 or not
[18:20] <bryce> if it is completely broken, there's not much time remaining pre-a1 for us to fix it
[18:20] <apw> bryce, i thought from our disucssions at uds it was ok, but tormod says userspace isn't ready
[18:21] <apw> perhaps you could disucss with him and let me know what you wnat the default to be for a1
[18:21] <apw> i'll be uploading tommorrow am my time for the release
[18:21] <apw> i have to run now, so drop me an email.... 
[18:21] <bryce> leave it off
[18:22] <apw> ack
[18:22] <bryce> I tend to prefer switching things on right after a release, to give maximal time to test
[18:22] <bryce> if we already know radeon kms doesn't work reliably, I'd rather not have the deluge of bug reports ;-)
[18:23] <apw> ok so lpan of off for a1 and on in the first upload after thant
[18:23] <bryce> yep
[18:23] <bryce> I'll work out the plan with tormod for what we have to do on the userspace side and hopefully get that squared away in the mean time
[18:23] <tormod> bryce, to summarize: radeon is not loaded before X loads it, but when X probes for KMS the module has not finished initializing so it thinks KMS is off
[18:24] <tormod> and you get UMS and KMS at the same time!
[18:24] <bryce> tormod, ah
[18:24] <tormod> bryce, please read the backlog here, #ubuntu-kernel and #radeon
[18:24] <bryce> tormod, could we just force it to expect KMS and sleep if it is missing?
[18:24] <jcristau> tormod: afaict with CONFIG_DRM_RADEON_KMS=y, the radeon module exports a device table that should get it loaded automatically by whatever at boot
[18:24] <bryce> hmm, I'm not on #radeon
[18:25] <tormod> jcristau, I was discussing this with apw above, but it seems it is not loading
[18:26] <bryce> hmm and looks like I caught only the tail end of the #ubuntu-kernel discussion...  mind re-summarizing the main bits for me?
[18:26] <jcristau> hmm the MODULE_DEVICE_TABLE isn't enough?
[18:26] <tormod> so maybe it is a kernel issue although apw blames userspace :)
[18:27] <jcristau> well there's still another bug if 'modprobe radeon; drmCheckModesettingSupported()' fails
[18:27] <tormod> bryce, I have a patch for what you suggested there :)
[18:27] <tormod> jcristau, yes it is still racy
[18:28] <jcristau> tormod: but that should only matter in the case where radeon doesn't get loaded by udev earlier
[18:28] <tormod> jcristau, or everything starts up really quick :)
[18:28] <jcristau> which is aiui the whole point of the device table
[18:29] <tormod> note also that radeon will need firmware available, currently missing from initrd
[18:29] <jcristau> it doesn't need to be in initrd
[18:29] <tormod> depends on when you load radeon...
[18:30] <jcristau> udev should load it after / is available, i think
[18:36] <tormod> bryce, this is patch http://ubuntu.pastebin.com/d3b3afb7c
[18:38] <bryce> tormod, firmware?
[18:39] <tormod> bryce: platform radeon_cp.0: firmware: requesting radeon/R420_cp.bin
[18:39] <bryce> tormod, yeah that's what I was thinking
[18:40] <tormod> on my own laptop, I have a kms-ready.conf that waits for "filesystem" to load radeon
[18:41] <tormod> then I let gdm.conf wait for kms-ready (which is NOP without KMS)
[18:41] <jcristau> tormod: that patch seems wrong.  drmCheckModesettingSupported returns 0 if modesetting *is* supported
[18:41] <tormod> jcristau, quite possibly, not tested yet :)
[18:41] <bryce> tormod, oh right the command processor
[18:42] <jcristau> also a 2s penalty for ums users seems a lot...
[18:42] <tormod> not if KMS is default
[18:42] <bryce> right ideally we don't care about UMS
[18:43] <bryce> like with -intel people need UMS only to work around bugs
[18:43] <bryce> (in theory, ideally)
[18:43] <tormod> ideally drmCheckModesettingSupported should be fixed to wait if stuff is initialising
[18:43] <jcristau> yes
[18:44] <tormod> jcristau, this is not a upstream patch :) just a Ubuntu hack
[18:44] <tormod> drmCheckModesettingSupported is kind of mickeymouse also IMO
[18:51] <tormod> how difficult would it be to fix the radeon module to create a /sys file that tells if KMS is enabled or disabled (and not just one of them)
[18:53] <bryce> jcristau, do you envision in debian testing wanting to support both UMS and KMS on radeon?
[18:54] <jcristau> i don't think we'll turn radeon kms on by default if that was the question
[18:54] <bryce> jcristau, since I know with -intel the plan is to eliminate UMS entirely, I'm sort of figuring supporting both to be just a transitional thing
[18:54] <bryce> jcristau, ok gotcha
[18:55] <jcristau> (if we do, we'd have to track whatever's in f12, since apparently dave didn't get all fixes in .32 final, and considering the manpower issues we have i don't think that's feasible
[18:56] <jcristau> )
[18:57] <tormod> since many users does kernel-hopping it would be good if user-space can deal with both active-by-default and not
[18:57] <bryce> email from alex deucher:
[18:57] <bryce> Any chance you can pull radeon drm bits from 2.6.33 during
[18:57] <bryce> development?  We are planning to move radeon kms out of staging during
[18:57] <bryce> 2.6.33 and there are a number of important patches already queued for
[18:57] <bryce> 2.6.33: a number of bug fixes, tmds support on pre-avivo igp chips,
[18:57] <bryce> interrupt support on r6xx/r7xx, and displayport support to name a few.
[18:57] <bryce>  
[18:57] <bryce> Displayport is supported now in xf86-video-ati master for UMS, and for
[18:57] <bryce> KMS the patches are in drm-radeon-testing.  I hope to have the
[18:57] <bryce> interrupt bits for KMS DP/HPD merged soon too.  This will give us
[18:57] <bryce> interrupt driven monitor detection which will trigger a uevent (e.g.,
[18:57] <bryce> box pops up saying: "You've attached/disconnected a monitor", etc.).
[18:58] <bryce>  
[18:58] <bryce> monitor uevents... sweetness
[18:59] <tormod> anyone here on radeon UMS ATM?
[18:59] <bryce> yes
[19:00] <tormod> can you pastebin your "find /sys/devices/pci-blahblahvideocard" ?
[19:01] <bryce> http://pastebin.ubuntu.com/334037/
[19:01] <tormod> thanks
[19:08] <tormod> my KMS one: http://ubuntu.pastebin.com/d43af9bdf drmCheckModesettingSupported looks for drm/controlD* in there
[21:10] <bryce> tjaalton, how are we looking for the 1.7 merge?  would it help if I work on some of the misc. outstanding merges?
[21:11] <tjaalton> bryce: 44 packages are waiting to be synced
[21:12] <tjaalton> xorg & xorg-server are merged, but the latter has some patches that need a review & refresh
[21:12] <bryce> tjaalton, right, beyond the syncs anything else needed that I should work on?
[21:12] <tjaalton> well, maybe have a look at the patches and see if they are needed?
[21:13] <tjaalton> I've updated the versions page with some new syncs and comments
[21:14] <bryce> ok
[21:14] <bryce> I've pinged pitti to do the syncs
[21:14] <tjaalton> great
[21:15] <bryce> are the patches to review flagged somehow in git?
[21:15] <bryce> ah yes they are
[21:15] <bryce> ok on it
[21:15] <tjaalton> uncommented from series, and marked in the changelog
[21:40] <tormod> are you gonna use udev in the xserver for A1?
[21:42] <tjaalton> yes
[21:43] <tormod> cool
[21:46] <bryce> hrmph, everyone complains "canonical doesn't contribute to X.org upstream", yet here are all these patches I made and sent upstream and they never got taken (or got a reply as to why not)
[21:47] <bryce> and I continue to wait for my fdo git account  :-P  https://bugs.freedesktop.org/show_bug.cgi?id=20373
[21:50] <tjaalton> maybe ping someone on #xorg-devel?
[21:51] <tjaalton> and the workflow has changed, so direct commits to master are a no-go, so posting patches for a review doesn't require the login (not that it would harm either..)
[21:52] <tjaalton> but maybe it's just the xserver that follows this, dunno
[21:52] <bryce> oh interesting
[21:52] <bryce> yeah mainly I wanted access to do work on -ati
[21:52] <tjaalton> it's been discussed on the list several times the past few months :)
[21:53] <bryce> yeah read those, and also discussed at XDC which I attended.
[21:53] <bryce> you'd think I'd remember these things
[21:53] <tjaalton> oh right
[21:53] <tjaalton> hehe
[21:53] <jcristau> it's mostly for the server, where keith is the one to push to master
[21:53] <bryce> yeah I guess I can try pushing the patches in again
[21:54] <bryce> iirc some of them whot said were just papering over issues and he'd prefer to crash in those situations
[21:54] <jcristau> i need to resend the udev stuff
[21:54] <bryce> I tend to prefer issuing a warning in Xorg.0.log and not crash... seems more friendly to the user
[21:54] <Sarvatt> patch 169 obsoleted by http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.7-branch&id=3d30789a05a730a03faa6058c73a5eda36ef3779 ?
[21:55] <bryce> Sarvatt, unfortunately that's not the only place where MIPOINTER() is dereferenced without checking for NULL
[21:57] <tormod> tjaalton, I don't see the touchpad rule in git yet
[21:57] <bryce> Sarvatt, grepping launchpad, patch 169's error string does show up in a couple bug reports (for proprietary drivers).
[21:57] <bryce> maybe those are outdated, I didn't check
[21:57] <jcristau> tormod: i think i pushed it to -synaptics...
[21:58] <tormod> jcristau, oh that would make sense 
[22:00] <bryce> tjaalton, looks like the syncs are coming in
[22:00] <bryce> libs at least so far
[22:00] <tjaalton> bryce: yep :)
[22:01] <bryce> looks like lp is about to go down so rest are going to wait for tomorrow
[22:03] <tjaalton> it's only 90min or so
[22:03] <bryce> I think pitti wants to go to bed
[22:03] <tjaalton> ah, right :)
[22:06] <Sarvatt> at least most of that wont build without the missing protos so things wont be broken until then :D
[22:06] <tjaalton> yep
[22:08] <bryce> ok, down to two patches
[22:08] <bryce> but oy, saved the hardest for last
[22:09] <Sarvatt> nothing can be worse than libx11's 03 patch lol
[22:10] <Sarvatt> which one is left?
[22:10] <bryce> 003_recognize_glibc_2.3.2_locale_names.diff ?
[22:10] <bryce>     - 135_rethrow_signals.patch - TODO: Refresh
[22:10] <bryce>     - 190_cache-xkbcomp_output_for_fast_start_up.patch
 bryce: ok, it's still alive, synced all bug bug 491051
[22:10] <Sarvatt> ugh yeah thats the nightmare one I spent 8 hours refreshing
[22:11] <bryce> oop he did that one too
[22:11] <tjaalton> bryce: 003? where's that from?
[22:11] <bryce> tjaalton, ok all in
[22:11] <bryce> tjaalton libx11
[22:11] <tjaalton> hehe
[22:11] <Sarvatt> libx11, sorry was talking about nightmare patches
[22:11] <tjaalton> the infamous la_AU patch
[22:12] <bryce> Sarvatt, 006 looks bad too (at least, it's huge)
[22:12] <Sarvatt> wait, you need x11proto-input 2.0 from experimental not the one from unstable dont you?
[22:12] <tjaalton> indeed
[22:12] <bryce> $ diffstat 006_tailor_pt_BR.UTF-8_Compose.diff 
[22:12] <bryce>  Compose.pre | 5619 ------------------------------------------------------------
[22:12] <bryce>  1 file changed, 1 insertion(+), 5618 deletions(-)
[22:12] <bryce> ok maybe not so bad, just deletes a lot of stuff :-)
[22:12] <tjaalton> huh
[22:13] <bryce> Sarvatt, yes, the bug was just misfiled, my bad
[22:13] <jcristau> Sarvatt: want to help getting it upstream?
[22:13] <jcristau> :)
[22:13] <tjaalton> bryce: only patch 16 is ours
[22:14] <tjaalton> 016 I mean
[22:14] <tjaalton> so it's a simple merge
[22:19] <bryce> hey, speaking of XI2, does this finally get rid of the 256 limitation on key codes?
[22:19] <bryce> or is that a more fundamental X11 protocol issue?
[22:23] <jcristau> the core protocol still only has 8bit for keycodes
[22:23] <jcristau> but i think apps can listen to xi2 events and get 32bit keycodes
[22:24] <jcristau> so we probably still need xkb2 and then fix clients
[22:28] <bryce> jcristau, so will only apply for xi2 compliant apps?
[22:28] <bryce> do apps need changed to use this or is it something that can be taken care of by the toolkits?
[22:28] <jcristau> bryce: may be enough to migrate toolkits
[22:29] <jcristau> that's probably all that's needed
[22:29]  * bryce nods
[22:29] <jcristau> but then it's possible even fewer people understand gtk's input code than X's
[22:29] <jcristau> ;)
[22:29] <bryce> lol
[22:30] <Sarvatt> refreshing the udev patch for master and i'll upload it in a bit tormod
[22:31] <Sarvatt> oh darn he just left, nevermind
[22:37] <bryce> ok patch 135 done, one patch left
[22:54] <bryce> done
[22:55] <bryce> and refreshed/re-enabled the timing patch 160 for good measure
[22:55] <Sarvatt> that one fails nastily on master :D
[22:56] <bryce> Sarvatt, the timing patch?
[22:56] <Sarvatt> 190_cache-xkbcomp_output_for_fast_start_up.patch
[22:56] <bryce> oh
[22:56] <bryce> it required only minor tweaking to get it to apply (just one chunk was off)
[22:57] <tjaalton> bryce: so 156 is no longer needed?
[22:58] <tjaalton> the commits were a bit messy ;)
[22:58] <bryce> tjaalton, where might I best snag xorg-server_1.7.2.orig.tar.gz ?  I'll do a build test
[22:58] <tjaalton> packages.debian.org?
[22:58] <jcristau> ftp.debian.org works
[22:58] <tjaalton> that too
[22:58] <bryce> tjaalton, my commits were messy?  sorry about that, tried to keep one commit per patch
[22:59] <tjaalton> well, some changelog edits etc. and patch 156 is still in git and enabled, also referenced in the changelog :)
[22:59] <Sarvatt> sweet, changelog is down to 4 hooks for xorg-server master now from about 40 :D
[23:00] <bryce> oh whoops
[23:00]  * bryce fixifies
[23:01] <bryce> pushed
[23:01] <tjaalton> thanks
[23:04] <Sarvatt> 02_Add-libgcrypt-as-an-option-for-sha1.diff is upstream 164_trap-aspect-ratios.patch fails 190_cache-xkbcomp_output_for_fast_start_up.patch fails and 12-Add-libudev-input-hotplug-backend.diff just needed 2 words changed. ah yeah and --disable-werror needed to be changed to --disable-strict-compilation in rules on master
[23:05] <bryce> what's the error on 190?
[23:05] <bryce> ftp.debian.org is slooow
[23:10] <Sarvatt> wait, you're patching the patch in the patch?
[23:10] <Sarvatt> in 190
[23:10] <Sarvatt> --- a/debian/patches/190_cache-xkbcomp_output_for_fast_start_up.patch
[23:10] <Sarvatt> +++ b/debian/patches/190_cache-xkbcomp_output_for_fast_start_up.patch
[23:12] <bryce> oh hell
[23:12] <bryce> hang on
[23:13] <tjaalton> :)
[23:17] <bryce> wow I made a mess
[23:18] <bryce> er, wait maybe not
[23:20] <Sarvatt> all of configure.ac and 2 hunks out of ddxLoad.c failed on master though before the patch patched itself and tried to delete all the other hunks :D
[23:21] <Sarvatt> that patch just speeds up startup times after the first one?
[23:25] <bryce> ok I think I see what happened
[23:27] <Sarvatt> lucid's got a pretty nasty bug right now, all the standard preferences and administration items are gone from the menus
[23:28] <RAOF> I guess now's not the time to restart, then.
[23:31] <Sarvatt> not till ya get a gnome-menus update for sure
[23:54] <bryce> fixed (I think) 190 pushed
[23:55] <bryce> my pbuilder env is not getting the new protos for some reason
[23:55] <bryce> and                                 Depends: libxi-dev (>= 2:1.2.99.1) but 2:1.2.1-2ubuntu1 is to be installed.
[23:58] <Sarvatt> thats a good sign --
[23:58] <Sarvatt> robert@ubuntu-9{/opt/source/xorg-pkg-tools}:aptitude show x11proto-xext-dev
[23:58] <Sarvatt> Segmentation fault
[23:58] <Sarvatt> :D
[23:58] <bryce> maybe not everything got sync'd after all?
[23:59] <Sarvatt> think it's even moved past the libs that were synced before the protos that wont build yet?