[01:48] <duflu> AlbertA: still around?
[02:21] <AlbertA> duflu: just for a bit
[02:21] <AlbertA> duflu: how is it going?
[02:22] <duflu> AlbertA: OK, I swear you fixed this already, or something like it? https://bugs.launchpad.net/mir/+bug/1406725
[02:22] <ubot5> Ubuntu bug 1406725 in xorg-server (Ubuntu) "Severe graphical corruption running software clients (including Xmir) on android" [High,Triaged]
[02:24] <AlbertA> duflu: I fixed one for "software" buffers... does flicker use software buffers?
[02:24] <duflu> AlbertA: Yep. And I found in a related bug it seriously breaks arale too :)
[02:24] <duflu> https://bugs.launchpad.net/mir/+bug/1498806
[02:24] <ubot5> Ubuntu bug 1498806 in Mir "[arale] Software clients can rapidly cause a Mir server to exhaust all fd handles" [High,New]
[02:25] <duflu> which may be related
[02:26] <AlbertA> duflu: interesting... I hope HWC is not leaking the fds
[02:27] <AlbertA> duflu: the fix for the graphical corruptions were the flags in AndroidAllocAdaptor::convert_to_android_usage
[02:28] <duflu> AlbertA: Although treat them as separate bugs. The primary issue is the corruption which happens on mako with Xmir too. And mako does not have the fd leak
[02:29] <AlbertA> duflu: the flags in lp:mir look correct.
[02:31] <duflu> AlbertA: The least buggy form of corruption is when you just get in-surface tearing. So that combined with the fd leak shows our android buffer fencing isn't working
[02:31] <duflu> I guess that could reveal apparent corruption too
[02:32] <AlbertA> duflu: right
[02:32] <duflu> AlbertA: Never mind, and good night. I have endless tangents if you linger too long
[02:32] <AlbertA> I wonder what changed....
[02:32] <AlbertA> is this a regression? or did you just notice it now?
[02:33] <duflu> AlbertA: AFAIK it's never works
[02:33] <duflu> worked
[02:33] <AlbertA> ok
[02:35] <RAOF> Can I plz haz jenkins & merge proposals on launchpad git? Grr.
[02:37] <duflu> RAOF: Merge proposals for LP git exist. I've done one!
[02:37] <RAOF> I can't propose a merge into lp:mir though!
[02:38] <duflu> That's true. Mir is not git yet though
[02:39] <duflu> BTW did wily break? https://bugs.launchpad.net/mir/+bug/1499134
[02:39] <ubot5> Ubuntu bug 1499134 in Mir "[wily] Mir suddenly no longer builds: /usr/include/EGL/eglplatform.h:100:35: fatal error: android/native_window.h: No such file or directory" [Critical,New]
[02:39] <duflu> Fully updated wily can't even build our stable branches any more
[02:40]  * RAOF updates to check!
[02:40] <RAOF> Plausibly; we've got mesa 11.0 now.
[02:40] <duflu> Woo, good news then
[02:40] <duflu> But we should build too
[02:53] <RAOF> Hm. I think it's actually mir that's broken...
[02:56] <RAOF> Heh, yes.
[02:57] <duflu> That's why I left Mir tasks open :)
[03:08] <robert_ancell> duflu, hmm, that merge commit seems to be confusing git rebase. I think we should just rebase on xmir-1.17 and you can keep your changes on another branch if you want them. Note that all this history will ultimately be lost when we go upstream.
[03:22] <duflu> robert_ancell: Do what you need to. Just don't lose yesterday's additional fix... Also I think next time we should aim to merge without clobbering history. It's OK to lose the history when upstreaming, but very annoying when you're mid-sprint and can't see what you've just done
[03:23] <robert_ancell> duflu, I think you should treat xmir-1.17 branch as upstream and just maintain a branch with your changes. git doesn't seem to handle keeping history around
[03:25] <duflu> robert_ancell: git does. And in fact it did by accident yesterday. I'm just saying that accident is what git should be doing and is meant to do anyway
[03:25] <robert_ancell> duflu, but git rebase is horribly confused after you made that change. So I can't effectively rebase anymore.
[03:26] <duflu> robert_ancell: Sorry, all I did was pull then push. Normal activities so I guess we need to find out where it went wrong
[03:29] <duflu> robert_ancell: I'll stay hands off for a while so if you want to forcefully overwrite things to fix it, go ahead.
[03:29] <robert_ancell> duflu, all fixed now
[03:29] <duflu> I'm still worried that git automagically created this situation....
[03:29] <duflu> "you're holding it wrong"
[03:30] <robert_ancell> Not surprised in the least with git :)
[03:31] <duflu> The whole point of non-numerical revision IDs is that they get to stay around and don't get confused by merges
[03:32] <robert_ancell> Oh, the changes will always remain. Just I don't think the tools can handle a branch being both rebased and merged at the same time.
[03:34] <duflu> robert_ancell: So is simply 'push, edit, commit, push' wrong?
[03:34] <duflu> 'pull, edit, commit, push'
[03:34] <robert_ancell> I *think* git pull -r might do it right.
[03:35] <robert_ancell> i.e. you should rebase on xmir-1.17 instead of merging.
[03:35] <robert_ancell> The other option is to keep on another branch and then rebase those changes into xmir-1.17 periodically (i.e. when we release packages)
[03:36] <robert_ancell> I'm open to better ideas but I found it very hard to generate the actual patches from a branch with full history.
[03:36] <duflu> robert_ancell: git diff <oldrev> HEAD ?
[03:37] <duflu> Something like that was working for me
[03:37] <duflu> We need some solution that doesn't require deleting commit history so often...
[03:37] <duflu> Or ever
[03:38] <robert_ancell> duflu, the history is never deleted - keep it on another branch if you want
[03:38] <robert_ancell> git diff doesn't handle having more than one change like we do
[03:38] <duflu> robert_ancell: The history should be visible on launchpad. If we need another branch on LP?....
[03:39] <duflu> It's not OK to lose history of what you've done
[03:39] <duflu> And not OK to say, you should keep it locally
[03:39] <robert_ancell> duflu, just put it on another branch.
[03:42] <duflu> robert_ancell: Essentially I want to know the URL of the "trunk" that shows everyone's workings
[03:43] <duflu> That used to be https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/ but not now
[03:43] <robert_ancell> duflu, The xmir-1.17 branch is a) the patches that go into the .debs and b) what we will propose upstream. It's never been anything else.
[03:44] <duflu> robert_ancell: Losing history is still not OK. I don't expect our history to be visible upstream, but it should always be visible on LP
[03:44] <robert_ancell> THEN PUT IT IN ANOTHER BRANCH
[03:46] <duflu> robert_ancell: I'm considering it, but the same problem will reoccur when that gets 'rebased'. So still needs fixing
[03:48] <duflu> robert_ancell: So we'd need one new branch for each "sprint" right? So that branch with the history never needs rebasing in itself
[03:48] <robert_ancell> duflu, you could just make a branch xmir-1.17-trunk and use that for development
[03:49] <robert_ancell> or we could rename xmir-1.17 to xmir-1.17-rebased
[03:50] <duflu> robert_ancell: AFAICT git merge -p solves it
[03:52] <robert_ancell> yay, git merge --help mentions -p in an example but doesn't define it...
[03:52] <duflu> robert_ancell: Oops, I mean git rebase -p
[03:54] <duflu> Although when you're ready to upstream, then you don't use -p  maybe
[03:54] <RAOF> Hm. We actually need the android NDK around to build Mir now.
[03:54] <duflu> RAOF: It appears that way. Why did it work up to yesterday?
[03:54] <RAOF> Because mesa was using a 4 year old version of Khronos' eglplatform.h
[03:55] <RAOF> Oh, sorry. 5 year old.\
[03:55] <duflu> RAOF: Oh didn't we have the missing bits in 3rd_party? Just got cleaned out recently by alan_g
[03:55] <duflu> He removed "unused" files
[03:57] <RAOF> Oh, good catch. Yes, native_window.h was one of those.
[03:57] <RAOF> It *was* unused ;)
[03:57] <duflu> robert_ancell: I think we need just one new branch in LP. One that keeps history (rebase -p) and one for upstreaming preparation (rebase)
[03:58] <robert_ancell> duflu, well, we have that second one and you're welcome to keep the first if you want it.
[03:58] <robert_ancell> s/keep/create/
[04:00] <duflu> robert_ancell: I'll look into it... are we tied to the existing branch name xmir-1.17 too?
[04:00] <robert_ancell> duflu, nope, the name is fairly arbitrary. It's just 1.17 because at some point we'll need to rebase on 1.18
[04:12] <robert_ancell> Is something weird going on in vivid with Mir? My silo is failing on amd64, armhf and i386 with a missing mir_toolkit/mesa/platform_operation.h. Builds fine on the other architectures
=== chihchun_afk is now known as chihchun
[04:43] <duflu> robert_ancell: OK, I've created the two newly named branches. Can we delete the old (duplicate) one now?
[04:44] <duflu> Or rename it
[04:44] <duflu> I might try
[04:45] <robert_ancell> duflu, is -development supposed to have all the history in it?
[04:45] <duflu> robert_ancell: Yep
[04:45] <RAOF> duflu: If you need it, https://code.launchpad.net/~raof/mir/fix-ftbfs-against-mesa-11/+merge/272203
[04:45] <robert_ancell> It doesn't appear to here
[04:45] <robert_ancell> oh, hang on
[04:45] <duflu> RAOF: Ta
[04:47] <robert_ancell> duflu, ok, now I see a single merge commit
[04:48] <duflu> robert_ancell: Yeah merge seems much more friendly than rebase. The latter is designed to clobber history
[04:49] <robert_ancell> was there a reason why you didn't set xmir-1.17-development to your old pre-rebased branch?
[04:51] <duflu> robert_ancell: If that's what I think you mean then it contained history of the breakage. So best to not confuse git with the brokenness in the history
[05:00] <robert_ancell> bye all
[05:03] <duflu> robert_ancell: Bye
[06:20] <anpok> RAOF: shouldnt that header be part of android-headers?
[06:22] <RAOF> anpok: I don't think so, no. android-headers is for bits of AOSP that we need, right?
[06:22] <RAOF> native_window.h is a part of the NDK.
[06:27] <anpok> RAOF: not sure if that is relevant but it defines the native window but not those functions..
[06:28] <RAOF> Not relevant at all; all we need of it is “struct ANativeWindow;”
[06:28] <RAOF> (That's all EGL needs of it, at least)
[06:46] <duflu> RAOF: I would have top approved but Jenkins has found all sorts of fail
[06:46] <duflu> Can't see how it's related
[06:47] <RAOF> I believe the answer is “it isn't”
[06:47] <RAOF> Do we need to build 0.15/0.16 on wily?
[06:48] <duflu> RAOF: Is that a trick question? What other Mir version do you intend to put in wily archive?
[06:48] <guest42315> 0.17 pls
[06:48] <RAOF> 0.17, of course!
[06:48] <duflu> Hah
[06:48] <guest42315> :P
[06:49] <duflu> Let's release 0.16.0 first.
[06:49] <duflu> To wily
[06:49] <RAOF> Spoil sport :P
[06:50]  * duflu is waiting for Mir 0.42 personally
[06:50] <duflu> Which oddly still happens before 1.0 is reached
[06:50]  * RAOF presses the Jenkins retry button.
[06:50] <duflu> RAOF: Works on my machine anyway
[06:51] <duflu> And presumably yours too
[06:51] <RAOF> Indeed.
[08:39]  * guest42315 they see me rollin' la la la
[09:09] <duflu> alf_: Didn't you kill the auth magic stuff? It's still used in Xmir
[09:11] <duflu> Or is that OK and it's wrapped as a platform message?
[09:11] <alf_> duflu: But through platform operations right?
[09:11] <duflu> alf_:  hw/xmir/xmir-dri2.c:        msg = mir_platform_message_create(auth_magic);
[09:11] <duflu> Is that current/safe?
[09:11] <alf_> duflu: yes, so only the direct drm stuff was removed from the API and we replaced them with platform ops
[09:12] <duflu> alf_: OK thanks
[10:05] <Saviq> hey guys, any idea why the new mir is in UNAPPROVED queue? sounds like wily feature freeze is starting to bite us?
[10:07] <alan_g> Saviq: first I've heard (camako has been working this release), I thought yesterday it just needed to re-sync qtmir.
[10:09] <Saviq> alan_g, oh yeah it's past QA and all, it's published, but says mir is in UNAPPROVED, I think that's because of FF in effect
=== chihchun is now known as chihchun_afk
=== alan_g is now known as alan_g|lunch
=== dandrader_ is now known as dandrader
=== alan_g|lunch is now known as alan_g|EOD
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader