[07:36] tjaalton: ping? [07:38] oh nm I'll just send you a pull request, always wanted to do one of those [07:52] RAOF: if you merge something please do it properly ;) [07:52] try git diff c44dd5f11702cfc07f828d7f4716dc9cb7d257d0...ubuntu in libdrm [08:28] tjaalton: I updated xf86-input-wacom in your tree [09:41] bryceh/RAOF: evdev done, wacom done, synaptics done, xserver-xorg-video-all (minus geode) done. Xorg server ready, let her rip? [09:42] I'll give the geode thing a shot first [10:02] mlankhorst: Yeah, that was actually deliberate. [10:02] RAOF: why? [10:03] Because 2.4.37-0ubuntu1 was a pre-sync from debian-experimental; it wasn't actually a merge, so it doesn't need the previous changelog entries. [10:04] ok [10:04] When we sync we drop all the previous Ubuntu changelogs, partially because they no longer accurately describe the lineage of the package, partially because it's easier. :) [10:05] shrug git-merge handles changelog entries for me automatically, but yeah [10:05] Oh, yeah. It does for me, too. [10:08] ok I'm just setting up my quantal-i386 changeroot again, I automated most of it now though [10:25] RAOF: you could start uploading xorg-server to -proposed though with a note to keep it there for a bit, then prepare xserver-xorg-input-* [10:28] for the video drivers, openchrome was updated to 0.3.0 but I couldn't find a binary package, and the real 0.3.0 name will conflict with openchrome from hardy so you need to change version probably [10:28] ati and cirrus are git snapshots since they didn't post a release that worked in time [10:29] and the rest of the *.orig.tar.gz I'll sell to you for a small price [10:29] :P [10:29] openchrome 0.3.0? [10:30] ah. [10:30] i was remembering the version wrong [10:30] apm ark ati chips cirrus dummy fbdev glide glint i128 i740 intel mach64 mga modesetting neomagic nouveau openchrome qxl r128 rendition s3 savage siliconmotion sis sisusb tdfx trident vesa [10:31] all the xorg video drivers that I had updated [10:32] geode is going to need another fix but doesn't seem to use version control [10:34] working on it though as soon as this apt-get dist-upgrade finishes [11:00] ok early eod for me, still working on fixing up geode source [11:00] will complete tomorrow :) [12:25] mlankhorst: You know tomorrow's Saturday, right? :) [12:26] mlankhorst: I'm trying my hand at robustifying the ‘get apport to catch Xserver crashes’ patch; I think I can do that before uploading 1.13 (ie: it'll be done Monday or Tuesday) [12:26] Now, sleep [12:27] RAOF: yeah just moving up this afternoon to play wtih a friend, and maybe visit him next week in afternoon :) [19:10] tjaalton (and mlankhorst), I've moved the question you added at the end of https://wiki.ubuntu.com/X/Blueprints/LtsPointUpdatesForXorg up into the body proper. What you listed as upgrade paths looks proper to me (and leann says it fits with foundation's recollection of the upgrade plan). [19:11] apparently there's been some confusion about how we're going to handle the upgrades so hopefully this will help us nail things down. Please take a look and make sure it's covering things correctly. [19:20] bryceh: I would really want to sru libdrm if possible [19:20] so that only packages pulled in by xorg would get updated [19:23] this would make it possible to nuke the entire X stack and move back to the old one if needed :) [19:23] mlankhorst, well good luck getting that by the sru admins... [19:23] bryceh: I know, but it would make Xorg so much easier [19:24] if there's specific patches in particular that would help, that might be doable. but I don't know [19:24] bryceh: it's specifically that having the new version shouldn't break existing functionality, and would make switching between new Xorg and old easier by a multitude [19:26] same for libXrender, if things would mess up, apt-get remove .*lts-quantal could be made to work [19:26] without leaving a severely broken system [19:29] although maybe xrandr needs a different solution [19:30] I think it makes sense to define the backported X stack as xorg package + xorg-server-core + all drivers + mesa [19:31] and x11proto probably :) [19:32] but if we would do that, there's no creepy magic going on any more, it would just be a different set of xorg packages [19:34] just mesa+xorg+xorg-server-core+drivers under a different name [19:36] if things mess up, we could create a script that uninstalls all the renamed xorg packages, the original xorg package names, and reinstall the original packages without leaving the system in a creepy halfbroken state because of libdrm [19:37] that would also mean sru'ing the fix for plymouth on arm, but we should really aim for it :) [19:38] mlankhorst, have you talked with RAOF about this? what's his take? [19:38] not sure yet [19:39] I'm gonna pester him, and after x1.13 is uploaded do another renamed x stack for testing, but this time only including the packages I want to update unrenamed, and the x stack itself renamed [19:39] to show you can switch between them without scary brokenness [19:43] or at least, when it does break but it would leave your system in a state where it can still boot :) [19:52] booting is overrated [19:53] I already had a problem where I uninstalled libdrm-renamed, but the old libdrm was overwritten by it [19:55] at which point no plymouth, and things get unhappy? [19:56] erm plymouth package is fine, it was just libdrm*.so.* missing [19:56] which plymouth didn't like very much [19:57] yeah that's what i meant by no plymouth [19:57] sorry [19:59] :) === yofel_ is now known as yofel [20:59] mlankhorst: oh you managed to update it, cool. the shared repo sometimes doesn't really work that well.. [21:00] should probably push it to kernel.u.c or such.. [21:00] bryceh: ok, thanks. I'll read it once it's nice and calm ;) [21:00] it's fine though [21:02] great then, remember there were some issues with it earlier [21:03] ooh new upstream [21:03] 0.15 wasn't interesting [21:49] bryceh: yeah it looks fine [21:49] * bryceh nods [21:50] did update the 12.04.0 x stack column to 'no update' though (instead of 'none' :) [21:51] https://wiki.ubuntu.com/Kernel/Release/Rolling looks scary, for 14.04