| bryceh | "Enlightenment E17 Running On Wayland" ooh | 00:15 |
|---|---|---|
| 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:47 |
| 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:49 |
| RAOF | Sarvatt: Right. We just need to ensure that we *can* get quezacotl into the archive. | 02:50 |
| 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:53 |
| 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:54 |
| bryceh | Sarvatt, yeah anything that can be practiced in edgers would likely help | 02:57 |
| tjaalton | well i guess at least libxi, libxrandr will have to be updated too, whatever the server needs | 02:59 |
| tjaalton | i thought about the upgrade issues the other day.. | 03:00 |
| tjaalton | but now is not the time to remember what it was :) | 03:02 |
| tjaalton | +try to | 03:02 |
| Sarvatt | tjaalton: very much agreed about the time issue :) | 03:04 |
| 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:05 |
| 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:07 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:20 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| * 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:35 |
| 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:36 |
| broder | in fairness, that's always a risk on upgrade, regardless of whether you're going forwards or backwards | 03:37 |
| tjaalton | just declare it as a non-supported upgrade path.. you're on your own if you do that | 03:38 |
| 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:46 |
| 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:47 |
| 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:51 |
| tjaalton | :) | 03:52 |
| RAOF | xorg-q Provides: xorg | 03:52 |
| tjaalton | install ubuntu-desktop-q :) | 03:52 |
| 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:53 |
| Sarvatt | we're going to end up having deltas to debian on all of X doing this aren't we? | 03:56 |
| tjaalton | only on the next lts when it's cleaning up the mess :) | 03:57 |
| tjaalton | but don't see why the interim release packages should | 03:58 |
| 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? | 03:59 |
| 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:01 |
| RAOF | But, indeed, that's the sort of thing to check :) | 04:02 |
| tjaalton | updated the wiki | 04:02 |
| bryceh | wonder if stuff depending on xvfb will get confused | 04:03 |
| 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:04 |
| Sarvatt | probably my own fault with crappy packaging or not packaging absolutely everything though | 04:05 |
| 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:07 |
| Sarvatt | 1.9 was in 10.10 and 1.8 was only stopgap during the dev cycle though | 04:08 |
| bryceh | tjaalton, versions-current now updated | 04:12 |
| bryceh | http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/versions-current.html | 04:13 |
| Sarvatt | sucks about 6.14.3 ati :( | 04:14 |
| Sarvatt | new git snapshot? | 04:15 |
| tjaalton | bryceh: thanks! | 04:15 |
| bryceh | Sarvatt, yeah | 04:15 |
| tjaalton | oh, heh. as if they'll ever bump the minor release :) | 04:16 |
| 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:17 |
| 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:19 |
| 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:20 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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 | 04:58 |
| Milos_SD | Is there a bug in ppa-purge ? | 17:06 |
| 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:07 |
| ricotz | Milos_SD, i think ppa-purge has some problems handling multiarch and get confused by it | 17:13 |
| 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:14 |
| tseliot | I'm sorry | 17:15 |
| ricotz | tseliot, hmm, if there are only problem regarding jockey could upload it somewhere where I can grab it? | 17:16 |
| tseliot | ricotz: I've fixed jockey but something else's come up today and I had to delay my work on fglrx | 17:17 |
| ricotz | tseliot, i see, so you dont have a "kind of working" source package at all? | 17:18 |
| 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:19 |
| tseliot | ricotz: I know but can't we wait until Monday? | 17:20 |
| 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:21 |
| tseliot | ;) | 17:22 |
| ricotz | it would fit the cracky edgers ppa though :P | 17:23 |
| tseliot | heh | 17:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!