[00:15] <bryceh> "Enlightenment E17 Running On Wayland" ooh
[02:47] <Sarvatt> bryceh, RAOF: hrm so theres not much use spending significant effort getting this lts backports stuff into the archive before got 12.04?
[02:47] <Sarvatt> since its going to be the crazy backporting 100 packages with suffixes deal
[02:49] <Sarvatt> we cant have xserver-xorg-video-quezacotl if we dont know what its actually called :P
[02:49] <Sarvatt> xserver-xorg-video-intel-quezacotl that is
[02:50] <RAOF> Sarvatt: Right.  We just need to ensure that we *can* get quezacotl into the archive.
[02:53] <Sarvatt> well the kernel does it and we were told this was how it has to be done so i guess thats how it's going to be? :P
[02:54] <Sarvatt> imagine we'll have some metapackage stuff to work out, would be good to get it working and tested before release at least
[02:54] <Sarvatt> i can probably integrate that into edgers, make a whole new stack an optional install
[02:54] <Sarvatt> xserver 1.12 for instance
[02:54] <Sarvatt> except yeah, libs..
[02:57] <bryceh> Sarvatt, yeah anything that can be practiced in edgers would likely help
[02:59] <tjaalton> well i guess at least libxi, libxrandr will have to be updated too, whatever the server needs
[03:00] <tjaalton> i thought about the upgrade issues the other day..
[03:02] <tjaalton> but now is not the time to remember what it was :)
[03:02] <tjaalton> +try to
[03:04] <Sarvatt> tjaalton: very much agreed about the time issue :)
[03:05] <Sarvatt> libs will have to be upgraded, thats a given
[03:05] <Sarvatt> its only the subtle releases like 1.9->1.10 where you dont, that wont happen for long
[03:05] <Sarvatt> 1.6->1.7, ugh
[03:07] <Sarvatt> i'm slightly worried about pixman because it has a history of affecting things like notify-osd without fixing it and is required quite often
[03:12] <tjaalton> ok so the issue is that you can't "upgrade" to Q from 12.04.3 without cleaning up the backports first
[03:12] <tjaalton> since it would be a downgrade X and kernel-wise
[03:12] <Sarvatt> is that an issue?
[03:12] <tjaalton> not to me
[03:12] <Sarvatt> packages could be versioned lower than Q i mean
[03:12] <tjaalton> just something that should be made clear
[03:13] <Sarvatt> ~Q
[03:13] <tjaalton> ah
[03:13] <tjaalton> well you lose functionality
[03:13] <broder> that's not a problem, because the package names will be different
[03:13] <tjaalton> so if you need the hw support you'll regress
[03:13] <tjaalton> and there's no way to detect that
[03:13] <Sarvatt> tjaalton: what are you doing up at 5am? :)
[03:14] <tjaalton> so, installations made with .3 should not offer the upgrade to other than the next lts imho
[03:14] <tjaalton> Sarvatt: youngest giving trouble for the past 2+h
[03:14] <Sarvatt> oh once P is out yeah that'll be an issue since it'd offer to upgrade to Q but versions would be higher, think i get what you mean
[03:15] <tjaalton> then it was my turn and it took 15min to get her back to sleep :)
[03:15] <tjaalton> yeah the upstream version part, doesn't matter what the package revision is
[03:20] <Sarvatt> err i meant R instead of P there, sheesh
[03:20] <tjaalton> anyway, if we can make our lives easier by adding policy, then lets do that :)
[03:22] <bryceh> hey yeah the 12.04.3 -> Q issue might be worth mentioning, can one of you add it to the blueprint?
[03:22] <tjaalton> on the subscription?
[03:23] <bryceh> also makes me wonder about problems relating to 12.04.3 -> P (skipping Q)
[03:23] <tjaalton> uh
[03:23] <tjaalton> description
[03:23] <tjaalton> s/P/R/
[03:23] <tjaalton> :)
[03:23] <bryceh> in the linked wiki page
[03:23] <tjaalton> oh
[03:24] <tjaalton> hadn't noticed that
[03:24] <broder> 12.04.3 -> P should be fine, right?
[03:24] <broder> because precise's kernel will be newer than any of the 12.04 backports
[03:24] <tjaalton> well it is P :)
[03:25] <broder> it's just, e.g., 12.04.3 -> M that have potential to be problematic
[03:25] <tjaalton> hmm
[03:25] <tjaalton> versions messed up there?
[03:26] <bryceh> yeah I meant 12.04.3 -> R :-)
[03:26] <broder> err...right :)
[03:26] <tjaalton> bryceh: should I add a "questions" headline for drive-by comments like this? :)
[03:26] <broder> 12.04.3 -> R isn't a valid upgrade path, though
[03:26] <Sarvatt> 12.04->Q is fine, thats the only one thats fine, 12.04.5->R will be the problem because it'll offer Q
[03:27] <broder> you can only upgrade 6 months at a time or 2 years at a time
[03:27]  * Sarvatt is totally slow at responding
[03:27]  * RAOF is confused.
[03:27] <Sarvatt> holy crap, me too
[03:27] <tjaalton> .4 is the latest there'll be
[03:27] <Sarvatt> 12.04.5 is R X stack
[03:27] <Sarvatt> newer than Q
[03:27] <bryceh> tjaalton, yeah
[03:27] <tjaalton> .2 (Q stack), .3 (R stack), .4 (S stack)
[03:28] <RAOF> And then we drop everyone on the T stack.
[03:28] <tjaalton> then the next one is another lts
[03:28] <Sarvatt> tjaalton: .3 should be Q still, .4 R?
[03:28] <tjaalton> Sarvatt: .2 is released after Q
[03:28] <tjaalton> .1 just before
[03:28] <tjaalton> https://wiki.ubuntu.com/X/Blueprints/LtsPointUpdatesForXorg
[03:28] <broder> Sarvatt: the point releases are offset from 6-month releases by 3 months
[03:28] <tjaalton> it's all there :)
[03:29] <bryceh> broder, right, so from 12.04.3 you could go to Q (downgrading your X stack), or to R (correct X stack, but not a valid upgrade path)
[03:29] <RAOF> Ahem.  Then after .4 we transition everyone to the T stack, because P is still supported for a long while after .4
[03:29] <tjaalton> RAOF: yep
[03:29] <RAOF> As the various stacks drop out of security support.
[03:29] <bryceh> I put a table with all these into the wiki blueprint page (and dates!)
[03:30] <tjaalton> so basically only vanilla P and maybe P.1 is upgradable to Q, the others -> T
[03:30] <bryceh> yeah it's just something we'll have to document
[03:31] <bryceh> I can't imagine someone who's already opted into 3 point releases is suddenly going to wake up one day and decide to go non-LTS ;-)  But users are crazy, anything could happen.
[03:31] <broder> bryceh: if it was possible to retain the backport-R stack when you upgraded from 12.04.3 -> Q, the user could reboot and upgrade to R immediately
[03:32] <broder> but i don't know if that's going to be possible. it depends on how the packaging magic plays out
[03:32] <tjaalton> bryceh: users can still do that, just that update-manager shouldn't offer it. no way to protect them from sed & apt-get :)
[03:32] <RAOF> That'd be different.
[03:32] <bryceh> broder, right, the only problem would be if they installed 12.04.3 because the Q stack was faulty on their hardware or something.  But we get into weird corner cases at this point.
[03:32] <RAOF> broder: Hm, but you raise a good point; there needs to be some update-manager trickery to ensure that things work correctly.
[03:33] <broder> bryceh: but if they kept using backport-R stack after they upgraded to Q, in the same way that you can have old kernel versions lying around...
[03:33] <tjaalton> yeah they just should reinstall at that point, it'll keep /home intact anyway
[03:34] <RAOF> There's a policy question here - on a 12.04.x → 12.10 upgrade, what stack should the user end up with?  I'd like to say they should just end up with the 12.10 stack, regardless of which 12.04.x they upgraded from.
[03:35]  * Sarvatt was seriously hoping we could just upgrade via -backports and include that on the livecd and not do package name mangling
[03:35]  * broder 's backporter head hurts from that idea
[03:35] <Sarvatt> RAOF: sounds like something update-manager could handle, removing the old stack before upgrading
[03:36] <RAOF> Sarvatt: Right, that's one way of doing it; we could also have the 12.10 stack declare breaks/replaces on the appropriate bits.  Either way, it needs deciding before the 12.10 release.
[03:36] <tjaalton> but then they risk losing hw support
[03:37] <broder> in fairness, that's always a risk on upgrade, regardless of whether you're going forwards or backwards
[03:38] <tjaalton> just declare it as a non-supported upgrade path.. you're on your own if you do that
[03:46] <RAOF> I think this is a huge corner case.  The use-case we're talking about is for people who installed 12.04.3 *in preference to* 13.04, and then want to upgrade to 12.10.
[03:46] <Sarvatt> very true, was about to say that too
[03:47] <RAOF> They probably don't want to do that at all :).  At worst, they *actually* want to upgrade to 13.04 or 13.10.  And we'll support upgrading to 14.04.
[03:47] <tjaalton> right
[03:51] <Sarvatt> so say, ubuntu-desktop depends on xorg
[03:51] <Sarvatt> how does that get fixed
[03:51] <Sarvatt> i'm not seeing it
[03:52] <tjaalton> :)
[03:52] <RAOF> xorg-q Provides: xorg
[03:52] <tjaalton> install ubuntu-desktop-q :)
[03:53] <RAOF> Which is one of the things we need to check pre-12.04: we need to ensure that nothing outside the stack has versioned dependencies on pieces of the stack.
[03:53] <tjaalton> if there are going to be other backports due to pixman changes or such
[03:56] <Sarvatt> we're going to end up having deltas to debian on all of X doing this aren't we?
[03:57] <tjaalton> only on the next lts when it's cleaning up the mess :)
[03:58] <tjaalton> but don't see why the interim release packages should
[03:59] <RAOF> The stack is reasonably self-contained; I don't think we'll need to touch *everything*.
[03:59] <Sarvatt> do you really think meta packages will handle this correctly?
[04:01] <Sarvatt> like right now, try to upgrade to a new X video abi version with a nvidia driver or virtualbox installed providing the old one, the dist-upgrade will remove a metapackage and a bunch of other crap, then things are screwed
[04:01] <RAOF> Those drivers shouldn't provide the old one.
[04:02] <RAOF> But, indeed, that's the sort of thing to check :)
[04:02] <tjaalton> updated the wiki
[04:03] <bryceh> wonder if stuff depending on xvfb will get confused
[04:04] <Sarvatt> yeah this is my xorg-edgers experience since xserver 1.5 bugging me, i've never seen an abi update handled correctly
[04:04] <Sarvatt> always some weird quirk in apt ordering screwing things up
[04:05] <Sarvatt> probably my own fault with crappy packaging or not packaging absolutely everything though
[04:07] <Sarvatt> by probably I mean guaranteed I guess, still worried about it :)
[04:07] <Sarvatt> the 1.8 transition in ubuntu didnt go well
[04:07] <Sarvatt> but was ok by 1.9
[04:08] <Sarvatt> 1.9 was in 10.10 and 1.8 was only stopgap during the dev cycle though
[04:12] <bryceh> tjaalton, versions-current now updated
[04:13] <bryceh> http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/versions-current.html
[04:14] <Sarvatt> sucks about 6.14.3 ati :(
[04:15] <Sarvatt> new git snapshot?
[04:15] <tjaalton> bryceh: thanks!
[04:15] <bryceh> Sarvatt, yeah
[04:16] <tjaalton> oh, heh. as if they'll ever bump the minor release :)
[04:17] <Sarvatt> they will, 6.14.4, bet ya a beer at budapest :)
[04:17] <bryceh> we could ask them to do 6.15 for the lts
[04:17] <Sarvatt> oh thats micro
[04:17] <tjaalton> Sarvatt: that's patch release, or micro yeah
[04:17] <tjaalton> :)
[04:19] <Sarvatt> any point to going through that list yet?
[04:19] <Sarvatt> i was waiting for xserver 1.11
[04:19] <Sarvatt> only did libdrm
[04:20] <tjaalton> nah, stuff will get synced from testing, and the rest can wait for the server push
[04:20] <tjaalton> though I did upload wacom already
[04:20] <tjaalton> merges can be staged in git though
[04:20] <Sarvatt> rebuilds are a lot faster than syncs though thinking about it
[04:23] <bjsnider> why is it necessary to have nvidia provide xorg video abi?
[04:23] <Sarvatt> bjsnider: i wish i knew, i debated that one with tseliot since the start
[04:24] <bjsnider> nvidia doesn't even care what else is installed
[04:24] <Sarvatt> it works on multiple abi's, it's only useful during the development release when it might be updated to a new abi it doesnt support
[04:24] <Sarvatt> artifical limitations dont make sense to me
[04:25] <tjaalton> well, if we are always going to update the stack via a ppa in the future, maybe it is unnecessary to have the blobs provide it
[04:25] <Sarvatt> nvidia especially, they have new abi support publically at most a week or so after its out, the real lag is the distro upgrading the driver
[04:26] <tjaalton> though fglrx is always behind
[04:26] <Sarvatt> fglrx on the other hand is guaranteed 3 months
[04:26] <bjsnider> even if nvidia doesn't officially support an abi, it almost always works fine with ignoreabi
[04:26] <Sarvatt> bjsnider: yea
[04:26] <bjsnider> 3 months behind?
[04:26] <bjsnider> does it work anyway?
[04:58] <broder> re: apt mangling upgrades, that's probably because the thing that's not getting upgraded is marked as manually installed
[04:58] <broder> while everything else is auto installed
[04:58] <broder> so apt (unfortunately) concludes that you *clearly* meant to keep the manually installed thing, even if it means you lose the auto installed thing
[17:06] <Milos_SD> Is there a bug in ppa-purge ?
[17:07] <Milos_SD> it says that there are a lot of packages with unmet dependencies...
[17:07] <Milos_SD> and it wants to delete a lot of packages not from xorg-edgers ppa
[17:13] <ricotz> Milos_SD, i think ppa-purge has some problems handling multiarch and get confused by it
[17:14] <ricotz> tseliot, please upload fglrx :)
[17:14] <tseliot> ricotz: I'm working right now on some changes for the upstream fglrx but I'm afraid I won't make it today for the one in Ubuntu
[17:15] <tseliot> I'm sorry
[17:16] <ricotz> tseliot, hmm, if there are only problem regarding jockey could upload it somewhere where I can grab it?
[17:17] <tseliot> ricotz: I've fixed jockey but something else's come up today and I had to delay my work on fglrx
[17:18] <ricotz> tseliot, i see, so you dont have a "kind of working" source package at all?
[17:19] <tseliot> ricotz: no, sorry
[17:19] <tseliot> I only have an untested local branch
[17:19] <ricotz> tseliot, i cant test it myself, but i really like to push something to the edgers ppa
[17:20] <tseliot> ricotz: I know but can't we wait until Monday?
[17:21] <ricotz> tseliot, sure, if you think it will break the world it might better
[17:21] <tseliot> ricotz: it should. Also, I have yet to fix an issue with hybrid graphics...
[17:21] <ricotz> tseliot, alright, it is ok then
[17:22] <tseliot> ;)
[17:23] <ricotz> it would fit the cracky edgers ppa though :P
[17:23] <tseliot> heh