[00:00] tormod, alpha-1 is dec 10th [00:00] I've seen a number of opinions that graphics got worse from Jaunty->Karmic, I don't want to set up any sort of trend. And also, there are people irate over Fedora because 3d support is not good, but no one really tested 3d until after the release, and I think we'll see the same thing happen. [00:00] bryce, which means freeze on 8th [00:00] tormod, right [00:01] sconklin, fwiw, every single release we have heard "graphics is worse!" [00:01] And if people think it's broken, none of the arguments we've made for going to nouveau will make any sense to them if it 'worked' before. [00:01] bryce: ok, I feel better :) maybe [00:01] sconklin, what I think happens is we hear from people when things get worse, but not when they get better [00:02] most of the things that got worse in Karmic were introduced around/after FF [00:02] bryce: agreed. It's the same with most kernel drivers. No news is really good news. [00:02] tormod: what was that, btw? [00:03] key here is to get things in early and get everybody to test lucid continuously not wait for (late) alphas [00:03] yes. [00:03] tormod: (stuff that "got worse" in karmic) [00:05] some intel drivers got worse, although I think that's mostly resolved now - we froze in the middle of a bunch of changes that came from upstream. [00:05] jcristau, there were a few radeon mesa regressions, well I don't know if there was much, u pstart issues got sorted out mostly [00:05] ok [00:05] jcristau, gdm rewrite + upstart post-FF caused failsafe to break horribly; boot speed improvements exposed design flaws in dkms that can result in nvidia.ko not getting built [00:05] so other than the mesa stuff that's not really X stuff [00:06] also, there were things like EDID quirke that didn't get migrated from X to the kernel KMS code, which caused apparent regressions (Bryce explained this to me) [00:06] sconklin, the intel issues - were those the ones just for ironlake / new hardware? [00:06] sconklin, oh right... still need to get that fixed up [00:06] jcristau, right X just got caught in the crossfire for the most part [00:07] bryce: no, I think there were some suspend/resume issues that came up with old hardware. That patch is already out for an SRU. [00:07] anyway, I think graphics in general got a lot better from Jaunty to Karmic, my "opinion" [00:07] sconklin, ok [00:08] oh also there have been some regressions on older ATI hardware where it falls back to XAA instead of EXA (as a workaround to still other problems) [00:09] we should switch to Wayland [00:09] it has *so* fewer bugs [00:09] it has *so* fewer users :) [00:09] jcristau, perfect! [00:10] bbiab (babysitting time) [00:12] fun times [00:20] RAOF: did you see that I had put up the Fedora kernel patch set for people to browse? There are some additional nouveau patches in there, which may very well now be in the upstream nouveau - I haven't had time to look [00:21] sconklin: I don't think I did see that; is it on ubuntu-x@? [00:22] no, I sent it to the kernel list, hang on for a link. [00:22] Oh, whoops. Yeah, found it. [00:22] http://www.ai4qr.com/fedora12kernel/rpmbuild/ [00:22] yeah [00:22] are you familiar with rpm's layout? [00:23] not that you have to go browse patches - I just thought you may be interested [00:23] No, but it's easy enough to find the patches. [00:23] in SOURCES :) [00:23] So, they've taken the route of dumping a huge "nouveau" patch on the kernel rather than pulling from the nouveau tree. [00:24] but there are patches in there that aren't actually used, so be wary [00:24] ha, yeah [00:24] and a 2.9M drm-next patch [00:25] it gives me the willies [00:26] Owch, yeah. [00:34] RAOF: I'm guessing the "nouveau" patch is generated from git for packaging purposes [00:34] pwnguin: as in: git diff nouveau/master? I'd guess, yes. [00:34] so the individual patches might still be around [00:40] yeah. If we pull it in, it'll be probably done as a pull to a branch and a rebase, but that's andy's call - he's the git wizard. I know we won't do huge patches like that. [00:40] it's unmaintainable [00:42] As I say, if we pull from nouveau's kernel tree we pull in (a recent snapshot of) drm-next, too, due to frequent merges. I don't know how you'd (the kernel team) want to deal with that. [00:43] I already handed that to Andy to think about. [00:44] but for the moment and for the purposes of the plan, I'm assuming that there's a magic step for making that happen in a sustainable way. It would be a first - we have [00:44] Heh. [00:44] always taken Linus's tree plus minimal patches [00:45] we do drop in drivers, but there's never been a situation like there is with drm [00:45] Interrelated drivers, what fun! [00:45] So, I guess my next action here would be a nouveau DDX package update, so we've got a shiny new snapshot for when the kernel does whatever it's going to do. [05:27] hmm, where are these patches at? [05:28] * Apply Julien Cristau's udev patches. from https://edge.launchpad.net/~pitti/+archive/halsectomy/+packages [05:29] grabbed the source for the xorg-server package there but i dont see any new patches in the series, guessing he applied them by hand? i was going to add them to the server in edgers [05:40] Sarvatt: check the version in experimental [05:40] it's there too [05:44] thanks tjaalton, found it there === seb128_ is now known as seb128 === sconklin1 is now known as sconklin [18:15] tjaalton, how goes 1.7? need help merging stuff in? [19:57] bryce: pretty well I think. xserver 1.7.2 broke the ABI, so we need to wait for 1.7.3 (which should happen RSN). we could start by syncing the protos from unstable/experimental [19:57] and libs too [19:57] ok [19:57] some of them haven't been uploaded yet, though, but most are [19:57] can't most of those just be sync'd? do we need sync requests? [19:58] oh duh, we're syncing from testing, that's why they're not already sync'd [19:58] I've updated all the driver repo's, so those are just waiting for the 1.7.3, which should be uploaded to unstable once it's released AIUI [19:58] right [19:58] so they need manual syncs from unstable/experimental [19:58] very few of them need merging [19:59] ok, I'll work on those today [19:59] but the most important one is probably xutil-dev which is a pre-req for many of the new versions :) [19:59] the new version of xutil-dev, that is [20:01] the only change we have on it probably makes sense for debian too, but since there's a rush to get all of this in a merge is probably worth it for now [20:03] hmm looks like libxxf86{dga,vm} need some fixing until they can be uploaded (moved headers) [20:04] I'll fix them shortly, but first something to eat.. -> [21:09] well thats no good, 2.6.32 still doesnt suspend/resume right but now I cant use a web browser on the 2.6.31-14 kernel without crashing x and getting this - [drm:i915_gem_object_bind_to_gtt] *ERROR* Invalid object alignment requested 4096 [21:11] hello. i've just upgraded to karmic and i've had a few issues with my graphics driver for my ati radeon 2400. [21:12] i waas using fglrx but i couldn't boot the kernal except in safe mode, so i switched to the ati drivers. i still couldn't boot except in safe mode [21:13] i turned off the splash screen to get some error messages and the kernal then booted and x has started fine [21:13] although i don't have 3D rendering in my current state [21:13] all in all a bit confused [21:17] marqy, did you remove all the fglrx trash? [21:17] i think so, it took a couple of attempts; [21:18] but it'd be nice to know how to be sure [21:20] there is a wiki page https://wiki.ubuntu.com/X/Troubleshooting/FglrxInteferesWithRadeonDriver [21:24] tormod: cheers, i had a look. i took the manual steps to purge: removed xorg-driver-fglrx and reinstalled libgl1-* [21:24] $ dpkg -l fglrx [21:24] No packages found matching fglrx [21:25] but locate fglrx returns a load of stuff in /usr/src/fglrx-8.561, usr/share/ati, lib/modules, /var/lib/dkms/fglrx and /var/lib/dpkg/info [21:27] uploading a new libdrm now incase you were in the middle of packaging one tormod lol [21:27] was just building it to check on new symbols [21:27] Sarvatt, cool I am taking a break right now :) [21:27] many intel's yesterday, many mesa's today [21:28] Sarvatt, are you gonna add the udev patch to xserver? [21:28] I forgot to reinstall pitti's after doing a dist-upgrade, and I got pretty screwed :) [21:28] more like 10 patches and a bunch of rules changes, haven't had a chance to look it over yet [21:29] * bryce is syncreq'ing [21:29] i dont see the patches in his xserver though [21:29] think he applied them by hand [21:29] not even the power button would react :) [21:29] you can debdiff against yours [21:30] they're in the debian-experimental git [21:30] but not all the rules are there yet [21:30] oh? darn gotta dig out the 20091111 server build then [21:31] I had to add one for my SynPS protocol touchpad, pitti said jcristau would add it to git [21:31] yeah will be there soonish [21:32] it only adds udev support and does not take hal support away, right? [21:32] tormod: you can still choose hal at build time [21:32] jcristau, but you have to choose one of them? [21:32] yes [21:33] otherwise i don't see how you avoid duplicated events [21:33] yeah [21:33] tjaalton, all protos have sync req's filed [21:33] (also there probably wouldn't be much point. all linux will use udev, !linux can stay with hal) [21:34] tjaalton, I also syncreq's x11proto-input which had the XInput.h change - I assume we don't need that change any more, sounds like it got taken into debian at 1.9.99.902-1; let me know if otherwise [21:34] jcristau, sure. I just wondered about this transition period with one version in xorg-edgers and another in lucid [21:35] isn't Xinput.h in libxi-dev now? [21:36] Sarvatt, that's what 1.9.99.902-1 says, however I'm not sure we have the right version of libxi in ubuntu yet... [21:36] * bryce moves on to syncing lib's [21:36] Sarvatt, I remember that transition upstream in hardy time, a PITA for xorg-edgers... [21:39] think we should keep the old versions in edgers or delete them to clean it up tormod? [21:39] Sarvatt, which old versions? [21:39] i dont really like the idea of telling people to use lucid sources on karmic like we were doing for jaunty-karmic because it was a nightmare explaining things to people who wanted to build packages [21:40] the protos and stuff that are already in lucid [21:40] can wittle it down to just the server eventually [21:40] oh yes if it obsoleted by main it should be deleted [21:42] like we were doing for jaunty-karmic? I don't understand or remember exactly? [21:45] oh yeah cross-release mixing, yeah that can be a mess [21:45] bryce: true about x11proto-input, can be synced now [21:49] we had libdrm-radeon1 on karmic but not on jaunty and people were mixing and matching packages [21:49] tjaalton, ok [21:49] * x11proto-input: sync req# 491051 [21:51] Sarvatt, your intel issues are on your netbook? === seb128_ is now known as seb128 [21:52] tjaalton, all libs without ubuntu versions sync'd [22:00] bryce: libdmx and libxext can be synced too [22:01] tjaalton, rationale? [22:02] libdmx runs autoreconf now [22:02] on build [22:02] libxext was pulled for moblin, and runs autoreconf now like the rest [22:02] libxi should be syncable as well [22:03] libxrender too [22:03] (yet-another autoreconf) [22:04] ok, I'm working through these, just need to specify the rationale ("all changes upstream", "was just a fakesync", "was rebuild with no source change", etc.) [22:05] yeah, most of them are simple [22:06] * bryce nods [22:06] thank god I have a script for this now [22:06] libxvmc syncable [22:07] epoch is bumped in debian, the rest aren't that important I guess ;) [22:07] +of the changes [22:07] what's your diff in libxfont? [22:08] checking [22:08] debian/rules: unset LDFLAGS to not be hit by -Bsymbolic-functions, as libxfont contains weak symbols which are meant to be overriden (cf. LP #226156). [22:08] Launchpad bug 226156 in libxfont "After update in intrepid branch Xorg " [High,Fix released] https://launchpad.net/bugs/226156 [22:09] * libxvmc: sync req# 491086 [22:10] tjaalton: hmm i've seen one of those in a debian/rules a few days ago [22:10] libxfontcache? [22:10] libxt has it [22:10] bryce: i've gotten libxfontcache removed from debian [22:11] * libxrender: sync req# 491088 [22:11] * libxext: sync req# 491085 [22:11] i got, even [22:12] tjaalton: if the diff is the same as in libxt, care to put it in libxfont debian-unstable before i prepare an upload? [22:12] tjaalton, "libxi should be syncable as well" - mind doublechecking, seems quite a few changes, just want to be absolutely sure it's syncable [22:12] https://edge.launchpad.net/ubuntu/+source/libxi/2:1.2.1-2ubuntu1 [22:13] bryce: it's the same as with inputproto [22:13] jcristau, ok [22:13] I'll check the status of patch 101 [22:14] jcristau: yes, I'll check the diff [22:14] * libxi: sync req# 491094 [22:14] tjaalton: thanks. i pushed an update of libxfont to 1.4.1 to git a few minutes ago, so i'll wait [22:15] * bryce ignores libxfontcache for now [22:16] (but noting that it's dropped in debian) [22:16] i think libxfontcache had no reverse deps in lenny [22:16] jcristau: it's done by just appending LDFLAGS="" for configure [22:16] tjaalton: ah, ok [22:16] libxkbfile has one patch - https://edge.launchpad.net/ubuntu/+source/libxkbfile/1:1.0.5-1ubuntu2 [22:17] libxt specifically filters out -Bsymbolic-functions [22:17] bryce: pretty sure that's upstream [22:17] ok, we'll do a merge on that to be sure [22:18] tjaalton, libdrm ? [22:18] changelog entry is a bit terse ;-) [22:18] https://edge.launchpad.net/ubuntu/+source/libdrm/2.4.14-1ubuntu1 [22:19] your libdrm builds -radeon iirc? [22:19] yes, it's not syncable [22:19] ah right [22:19] at least not yet ;) [22:19] libx11 probably needs merger attention too [22:19] the full log is in git of course :) [22:20] bryce: http://git.debian.org/?p=pkg-xorg/lib/libxkbfile.git;a=commit;h=e695be2ab7eb1361b204f98c3da872eff58ad6b5 [22:20] alrighty, so except for libxfont I think all the libs and protos that can be sync'd are sync'd [22:20] jcristau, aha awesome thanks [22:20] or just check an older entry, if it's the same I usually don't bother [22:21] oh wait, there is also kees' fortify-crash.diff patch in libxkbfile [22:22] upstream as well [22:22] http://git.debian.org/?p=pkg-xorg/lib/libxkbfile.git;a=commit;h=dd9514fe714d81b881a1bd6bd88d4287adc5fc7e [22:23] aha excellent [22:24] * libxkbfile: sync req# 491103 [22:25] the libxi patch 101 was pulled from upstream, so it should be safe to sync [22:25] but you already filed that, so it's good [22:26] yep [22:26] jcristau: libxinerama should be good? [22:27] long sync list this cycle... https://wiki.ubuntu.com/X/PackageNotes [22:27] (and haven't even gotten to the good stuff yet) [22:28] updated notes @ http://www2.bryceharrington.org:8080/X/PkgList/versions_current.html [22:28] jcristau: also libxxf86dga and libxxf86vm have the Replaces, so whenever you have time.. :) [22:30] checking libx11 [22:31] bah, not upstream [22:32] bad robert [22:32] "Fix 'locale not supported by XLib' errors for la locales" that is [22:36] what's that locale? [22:37] la_AU.UTF-8 [22:39] that isn't even in libc afaict.. [22:44] hehe [22:53] apparently he created it [22:54] and was turned down by upstream [22:55] http://sourceware.org/bugzilla/show_bug.cgi?id=6583 [22:55] sourceware.org bug 6583 in localedata "Please add a locale for Latin" [Enhancement,Resolved: wontfix] [22:56] yeah so i'm not going to carry that as a debian-specific patch [22:56] 003_recognize_glibc_2.3.2_locale_names.diff is enough of a nightmare as it is [23:04] wow [23:31] http://alec.mooo.com/mpx.php looks intresting.