duflurobert_ancell: Sorry to trouble you but I'm not sure anyone else knows how and is also blessed to do so: Can we update the Xmir patch for xenial?01:22
dufluRAOF: Did linking get faster recently? Did we switch to gold or did gcc just get fixed?01:24
RAOFgcc may have been fixed?01:25
RAOFWe're on 5.3 now.01:25
robert_ancellduflu, do you need it sponsored?01:25
dufluYeah 5.3 caused the slowdown actually01:25
duflurobert_ancell: Maybe... I don't remember that process01:25
robert_ancellduflu, or do you want me to generate a patch from the branch and upload that?01:26
* robert_ancell tries to remember about xmir01:26
duflurobert_ancell: Yes please01:26
dufluFortunately xorg hasn't changed otherwise since November01:27
robert_ancellduflu, is bregma aware of these changes?01:29
duflurobert_ancell: Yes, it was work requested by him and kgunn01:30
dufluOtherwise I would not have touched it01:30
duflurobert_ancell: The two "Fix Committed": https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bugs?field.tag=xmir01:30
robert_ancellduflu, do you fix configure.ac to check for a more recent version of Mir?01:36
robert_ancellone of your commits suggests that is the case01:36
duflurobert_ancell: Where is that comment?01:36
robert_ancellduflu, https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/commit/?id=3f1e0ab7e5a8af5578cd10492c1f93e9bf97e25201:36
robert_ancellit's a runtime dependency I guess, but probably worth checking on build01:37
duflurobert_ancell: No, it's a runtime requirement. Also probably safe to assume any updated Ubuntu Touch system has Mir new enough01:37
dufluEspecially if it also has /future/ Xmir01:37
robert_ancellduflu, yeah, but anyone building X would probably want to fail if they have an old version01:38
duflurobert_ancell: It's not a build-time check. Xmir links to libmirclient.so.9 which may be from "any" Mir version01:38
robert_ancellduflu, yes, but configure is not necessaraily just for checking API compatibility01:39
duflurobert_ancell: It would have to be a runtime check (on Android only) that the Mir client library version is new enough. But that's actually less severe than the QtMir fix, which we can't detect from Xmir01:40
robert_ancellduflu, my point is by putting in configure.ac you stop someone with Mir 0.15 installed from building, because they are almost certainly going to hit the issue when they run the X they built01:41
* duflu checks distro01:41
duflurobert_ancell: Ubuntu 15.10 and later already ships with a new enough Mir. And the QtMir bug can't be detected (we don't even know where it got fixed)01:42
dufluSo I'm happy to skip any detection attempts01:42
robert_ancellduflu, but this is a patch to xorg, which is not necessarily built on Ubuntu01:42
* robert_ancell gives up01:42
duflurobert_ancell: I see your point, but it would be a hack of probably no real-world value and would still not protect the user entirely if they are using an old Unity801:43
RAOFconfigure.ac is a nice place to document such a dependency.01:44
dufluIt's not a dependency. We could switch it to a compatibility mode at run time. But it's impossible to reliably detect if that is required01:44
dufluI will personally worry about our phone images having the right bits. But non-Ubuntu users I'm happy to say: You need a Mir v0.16 or later for it to work properly.01:46
RAOF(Which is what a mir-client >= 0.16 in configure.ac documents ☺)01:59
dufluRAOF: It can and should build with older Mir... libmirclient9 is the requirement. When did that happen?02:01
RAOFBut it won't work at runtime with mir-client < 0.16?02:01
RAOFWhich is why you document that in the configure.ac check!02:01
dufluRAOF: It could if we detected it and switched to slow mode. But we can't also detect the broken QtMir02:02
RAOFBut we don't, so it doesn't.02:02
RAOFBasically: it's harmless to bump that version requirement, and it's courteous to anyone trying to get it to work.02:02
dufluRAOF: It's not a "bump". We don't check the Mir version at runtime yet do we? That's a code change02:03
dufluAlso not a reliable or useful one, probably02:03
RAOFWe have a check in configure.ac, yes? Because we link with libmirclient9.02:03
RAOF*That* check is a simple bump.02:04
dufluRAOF: That's a build time check. We still want it to be buildable with old Mir. Building on old Mir is not broken02:04
RAOFIt's useless to build against old Mir, though.02:05
RAOFI mean, you can build it, but you'll run into this bug and it won't work.02:05
RAOFSo in order to use it you'll need to have a newer build of Mir.02:05
RAOFSo there's no benefit gained in letting people build something they won't be able to run.02:05
RAOFBut this isn't really interesting enough to argue about, either :)02:06
dufluRAOF: It's a silly feature to check and then throttle. If someone is advanced enough to build their own Xmir and they're not using Ubuntu, we should just remind them we'll only support recent versions02:07
RAOFWhich is why we should bump the configure.ac check!02:08
dufluRAOF: Also, this only applies to Android. And never desktop02:08
RAOFI'm not arguing for runtime detection!02:08
dufluDesktop users can use old Mir fine02:08
dufluOnly touch users can't02:08
dufluAlthough the QtMir bug does affect desktop... we have no knowledge of exactly what version that got fixed in. Just "it seems to be fixed this year"02:10
dufluHmm, now I look at it again, the only relevant Mir bug was only on Android and only relevant to non-nested servers. That's what got fixed in 0.16.002:20
robert_ancellduflu, is anyone looking at updating xmir for the X 1.18 API (i.e. you)02:21
duflurobert_ancell: No I wasn't yet. Still focusing on xenial (1.17)02:22
dufluSounds like branches will happen02:22
robert_ancelltjaalton, was asking, but I haven't had time to have a look02:22
duflurobert_ancell: Best not to mess with what we've got (which seems like the right branch for xenial) right now02:23
duflurobert_ancell: Oh I see new Xmir in xenial proposed already. You rock.02:23
robert_ancellduflu, it was for testing purposes and to be ready when fglrx updates to the new API we can shift over.02:24
robert_ancellI guess 1.18 will land into 16.1002:24
robert_ancellduflu, please test xmir from -proposed :)02:24
duflurobert_ancell: OK, ta02:24
duflurobert_ancell: I won't have an answer till at least your Wednesday though02:25
robert_ancellduflu, for xmir?02:25
duflurobert_ancell: Yeah I'm still ploughing through morning tasks and have two time consuming meetings today02:26
dufluBut should be able to do all the manual testing required before tomorrow02:26
* duflu wonders if his words are knocking robert_ancell over02:27
robert_ancellhmm, any reason why I can't VT switch away from mir_demo_server anymore?02:27
robert_ancellI had to reboot, was stuck on VT102:27
duflurobert_ancell: There is a known bug. Lemme find it02:28
duflurobert_ancell: Non-root?02:29
robert_ancellduflu, as root02:29
dufluOh, I found https://bugs.launchpad.net/mir/+bug/128625202:29
ubot5`Launchpad bug 1286252 in Mir "mir_demo_server* successfully start as non-root (without input support), meaning it can't be quit/switched away from" [Medium,Confirmed]02:29
robert_ancellyeah, I've fallen for the non-root base before02:29
duflurobert_ancell: Or generally it might mean you have no input platform :)02:29
robert_ancellduflu, which package name02:30
duflurobert_ancell: mir-platform-input-evdev502:30
=== chihchun is now known as chihchun_afk
tjaaltonduflu: 1.18 is in ppa:canonical-x/x-staging05:33
tjaaltoni've ported xmir to it05:33
tjaaltonsent a CFT to ubuntu-devel some time ago05:34
tjaaltonplan was to move it to main before FF, but nvidia hybrids regress with the blob, unity-greeter crashes05:36
tjaaltonso we're looking into that first05:37
anpok_hm i thought 1286252 has been fixed already, by accident06:13
anpok_oh ok only partially06:16
anpok_there is still a way to get stuck06:16
duflutjaalton: Thanks. So long as you have the Xmir changes from the past few days too (https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/)06:20
tjaaltonduflu: yeah I've now merged it in the branch, will upload to ppa later06:24
duflutjaalton: Cool, thanks. Ignore the email then06:24
tjaaltonthis is what was needed to port it btw http://sprunge.us/JfHW06:25
duflutjaalton: No risk on the GL stuff because Touch uses software rendering for now. Only the keyboard changes I guess06:27
tjaaltonI should probably test that :)06:29
duflutjaalton: If you test it on desktop it will default to DRI2 (not what the phone uses), so add: -sw06:30
duflutjaalton: Do you have permission to create a git branch for your changes? https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/06:41
dufluThat's ~xmir-team I guess06:41
duflutjaalton: Today's package just vanished from proposed and only the old release is visible. Is that right? https://launchpad.net/ubuntu/+source/xorg-server06:46
dufluMaybe it's just a transitional period. I vaguely recall that happens06:47
tjaaltonduflu: i might be able to create a branch, after joining the team at least06:49
dufluAh I see it was "Deleted 16 minutes ago by Ubuntu Archive Robot - moved to release"06:49
duflutjaalton: That's OK. Just we'll need to remember to do it and incorporate your changes before any new major Xmir work06:49
dufluAnd make that new branch the default one06:50
dufluI forget how06:50
zzarrokey RAOF, thanks, I  hope for the first option ("jumping" to internal, and back to external when the cable is pluged in again)07:01
RAOFzzarr: Just bear in mind, essentially no application currently written will support that.07:01
=== chihchun_afk is now known as chihchun
zzarrRAOF, I know, but if the Vulkan framework for a sample will be then that would be splendid :-)07:02
zzarrI don't know if though07:03
dufluOoh progress. The new xmir is released in xenial before I've finished testing it :)07:03
zzarrduflu, is that good or bad?07:04
dufluNot sure yet07:04
dufluCan't hurt. If anything is wrong we'll fix it quickly07:04
zzarrwell it happened in any way07:05
zzarrawesome my internet is faster then I pay for I pay for 100/100 and get 120/115 :-)07:10
zzarrmy grammar is poor though (realized that when I read my line)07:12
zzarrin any way I'm happy to see that so many are enthusiastic about Ubuntu :-) (I'm one of the enthustiast)07:15
zzarrdoes anyone know the status of Miracast (Aethercast)?07:51
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
=== dandrader is now known as dandrader|afk
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
alan_ggreyback: I don't really know my way around the unity8 code, and this is something you might know: is there anything that relies on MIR setting $MIR_SERVER? ("anything" would be forking a client process that relies on that environment variable to find the server - which isn't something I expect/can find.)14:56
greybackalan_g: MIR_SERVER env var? No, I've never even seen that env var before, let alone seeing code depending on it14:58
alan_ggreyback: the Mir client API can use it to find the server socket. (if the client code doesn't specify a socket)15:00
alan_gBut I *think* setting it in the server process is a legacy mess that isn't useful and is confusing.15:01
greybackalan_g: ok. I've only seen MIR_SOCKET being used to specify that, and upstart is responsible for that15:01
alan_gThe legacy thinking was that Mir servers would set it and launch clients. But it hasn't turned out that way - U8 doesn't launch clients directly does it?15:02
greybackalan_g: nope15:03
* alan_g is going to delete the mess15:03
=== dandrader|afk is now known as dandrader
=== dandrader is now known as dandrader|afk
=== alan_g is now known as alan_g|EOD
=== chihchun is now known as chihchun_afk
=== dandrader|afk is now known as dandrader
=== mapreri_ is now known as mapreri
=== tedg_ is now known as tedg
=== Trevinho_ is now known as Trevinho

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!