[05:42] <mlankhorst> morning
[05:54] <Sarvatt> mlankhorst: morning!
[05:55] <Sarvatt> amazing work on the lts backports renaming btw, cant believe you got it working
[05:55] <mlankhorst> all the stuff was already in place, I just refined it a little :)
[05:57] <mlankhorst> but thanks :)
[06:00] <Sarvatt> i cant believe you got nouveau working outside for cairo 1.12 too outside of the libdrm-nouveau2 change too, really awesome :)
[06:00] <Sarvatt> and that wasnt english but yeah
[06:00] <mlankhorst> debian needs some more fixes to kernel drm, i have them but untested
[10:55] <mlankhorst> tiling's fun
[17:21] <mlankhorst> bryceh: awake yet?
[17:53] <bryceh> mlankhorst, what's up?
[17:57] <mlankhorst> oh the renamed stack thing. We can't support it because it's impossible to remove properly atm afterwards.
[17:59] <mlankhorst> And the binary drivers will be uninstallable although that would be trivial to fix
[17:59] <tjaalton> wasn't the plan to offer a script a'la ppa-purge to allow downgrades
[18:00] <tjaalton> or what do you mean by "impossible to remove afterwards"?
[18:00] <mlankhorst> tjaalton: Because of the Replaces: unrenamed if you install the older version it won't install right.
[18:01] <tjaalton> use the force
[18:02] <mlankhorst> I'm going to try another version with Conflicts instead of Breaks
[18:02] <bryceh> where there's a will there's a way :-)
[18:02] <tjaalton> or just don't support downgrades
[18:02] <tjaalton> no, conflicts is wrong
[18:03] <bryceh> anyone know if we formally support downgrading from a .2 lts back to the .0?
[18:03] <tjaalton> no
[18:03] <mlankhorst> also fun will be if you try to upgrade from renamed stack to quantal
[18:03] <tjaalton> nothing new :
[18:03] <tjaalton> :)
[18:04] <tjaalton> wasn't it decided as "unsupported"?
[18:04] <mlankhorst> yeah but if we want to do an announcement we might want to emphasise those things..
[18:06] <tjaalton> it's not coming before january..
[18:07] <tjaalton> but yeah, of course
[18:12] <tjaalton> it wouldn't be that hard to allow upgrades though, if the version number would be less than in quantal (-XubuntuX~lbq) and the package replaced the renamed one
[18:13] <tjaalton> uh
[18:14] <tjaalton> the version of the renamed package was lower, and the proper quantal package had provides/replaces: renamed.. but it would be fun to script the build of the renamed package from that :)
[18:14] <tjaalton> so, just don't allow upgrades to non-lts releases..
[18:15] <tjaalton> the stack on T will have butt-ugly control files..
[18:16] <tjaalton> and then that stack will be the last backported one, so you get to do the above at least once
[18:17] <mlankhorst> tjaalton: I think I'm just going to create a real metapackage by then that defines every possible renamed package from quantal onward..
[18:18] <tjaalton> that won't help
[18:18] <Sarvatt> it's using replaces? yeah that totally wont downgrade right, you would have to purge then reinstall the unrenamed packages :(
[18:18] <mlankhorst> Yeah..
[18:19] <mlankhorst> tjaalton: Why not?
[18:19] <tjaalton> mlankhorst: the new real packages need to replace the old renamed ones
[18:19] <tjaalton> new unrenamed packages
[18:20] <tjaalton> let me stop my head spinning..
[18:20] <mlankhorst> tjaalton: I know, but I mean if it upgrades to that fake package first I could make those depend on the unrenamed package.
[18:21] <tjaalton> mlankhorst: it will update the metapackage but leave the old renamed packages installed
[18:22] <tjaalton> uh, maybe this is too abstract to handle
[18:22] <tjaalton> in my little brain anyway
[18:23] <mlankhorst> tjaalton: Could we at least add a Conflicts: package >> currentversion to renamed stack?
[18:23] <mlankhorst> or would that break too
[18:24] <tjaalton> what would that solve?
[18:25] <mlankhorst> so upgrading to unrenamed will remove those renamed packages first..
[18:25] <mlankhorst> between lts releases
[18:26] <tjaalton> that's not how dpkg works
[18:27] <tjaalton> if you need details you can read the policy, the way the pre/postinst scripts are run etc, it's a nice diagram :)
[18:27] <tjaalton> debian policy that is
[18:28] <mlankhorst> can you add a version to replaces: ?
[18:29] <tjaalton> yes
[18:31] <mlankhorst> We definitely should add a version to our control files for replaces then, so in future upgrades we could bump version and do a replaces for all the possible renamed versions to upgrade back to next lts. :)
[18:34] <mlankhorst> Fortunately it's automated enough now to simply add it, bump version number, upload it to launchpad and check next day.
[18:41] <tjaalton> added to which control file, the renamed or unrenamed package?
[18:42] <mlankhorst> renamed
[18:43] <tjaalton> so 'renamed; Replaces: unrenamed (<< version)
[18:43] <tjaalton> '?
[18:43] <mlankhorst> yes
[18:44] <tjaalton> ok, I don't understand the rest of the sentence then :)
[18:44] <mlankhorst> and for r Replaces: unrenamed (<< lts), renamed1
[18:44] <mlankhorst> and for next lts the package will have: Replaces: all renamed versions
[18:49] <tjaalton> well, the releases can have real updates too, so versioned replaces need manual thinking
[18:50] <tjaalton> would be great if you could write these cases in a wiki or so, a lot easier to review than trying to read between the lines here :)
[18:51] <mlankhorst> I'm still not entirely sure yet and experimenting
[18:53] <tjaalton> doesn't matter, wiki can be edited :)
[19:07] <bryceh> fwiw I directed them not to mention X stack in the announce they're prepping.  Don't think widespread usage right now is going to buy us anything (except support questions)
[19:09] <bryceh> tjaalton, mlankhorst if someone adds the ppa and does just a regular dist-upgrade, it won't actually upgrade the X stack will it?  they have to specifically install the metapackage right?
[19:11] <mlankhorst> indeed
[19:12] <mlankhorst> but it might be better to remove anyhow
[19:19] <bryceh> no, I think leave it in the ppa.  Removing it would sort of be defeating the purpose...