[manjaro-dev] urgent mate panel update needed

[kendell clark]

hi
Yup, git bisect seems to be the most sensible rout. I'm working with the
mate people and joanmeri diggs, the lead orca developer to find and fix
the issue. I've downgraded to mate panel 1.12 in the meantime. Do you
still want me to run this git bisect and post it hear? The mate people
have said that once they fix all the accessibility issues they will
release a new mate panel 1.14 version which we can update to. If you
look at the issue I filed they had me run a git bisect, but I might've
identified the wrong commit because the panel is still broken. There are
two issues I've filed, one for the panel being broken and one for
inaccessible applets. I'll give links for both. The one for the broken
panel is at: https://github.com/mate-desktop/mate-panel/issues/440.
The one for the inaccessible applets is at:
https://github.com/mate-desktop/mate-panel/issues/441. Since you guys
can see, would one of you mind installing orca and running it while
navigating the panel? Joanmeri thinks part of the problem with the panel
is that keyboard focus is getting stuck, meaning once you tab to one of
the applets you can't move past it. I can't see well enough to know if
that's the issue or not, but someone who can see can. If orca stops
speaking but you continue to move around the panel then it's not a
keyboard focus issue, but something with the panel's accessibility code.

Thanks
Kendell Clark


Philip Müller wrote:
> Hi Kendell,
>
> simply put we need you to know how git-bisect is working and how you can
> use it with PKGBUILD to get a result. Lets say v1.12.2 was the last good
> working version for you. Compile it with PKGBUILD by changing the
> version number but keep the dependencies as given. If that is good then
> we can test the next given tarball which is v1.13.0. If that is bad, we
> know commits between v1.12.2 and v1.13.0 created your regression.
>
> Is however v1.13.0 also good you can go for v1.13.1 or v1.13.2. For sure
> we know that v1.14.0 has the regression.
>
> So knowing now in which range we have to look we can use git-bisect now.
> First you have to get the latest git source and checkout the v1.14
> branch. This can you do in three steps:
>
> git clone https://github.com/mate-desktop/mate-panel.git
> cd mate-panel
> git checkout 1.14
>
> Now we have to kickoff the bisect procedure by initiating 'git bisect
> start'. Then we define the last good commit which is working for you.
> Lets say it was v1.12.2:
>
> git bisect good v1.12.2
>
> Then you have to tell git bisect a known bad commit. Lets say it was
> v1.14.0:
>
> git bisect bad v1.14.0
>
> The bisect routine will calculate now a random git hash. This is now the
> version you have to use and test it on your machine.
>
> Go to the attached PKGBUILD and change the version number to that hash.
> So '_commit' becomes something like
> '_commit=51edda9fc670c38c57fa3739280086dc310c6df7'. You build then the
> package and test it. If the outcome is good or bad you tell your running
> bisect routine until you find the culeprint. Also paste the full bisect
> log to your next issue report.
>
> Now you find an example log I just did to showcase that for you what
> will happen in the console:
>
> [phil at manjaro bisect]$ git clone
> https://github.com/mate-desktop/mate-panel.git
> Cloning into 'mate-panel'...
> remote: Counting objects: 4939, done.
> remote: Compressing objects: 100% (10/10), done.
> remote: Total 4939 (delta 5), reused 0 (delta 0), pack-reused 4929
> Receiving objects: 100% (4939/4939), 11.43 MiB | 5.93 MiB/s, done.
> Resolving deltas: 100% (3348/3348), done.
> Checking connectivity... done.
> [phil at manjaro bisect]$ cd mate-panel
> [phil at manjaro mate-panel]$ git checkout 1.14
> Branch 1.14 set up to track remote branch 1.14 from origin.
> Switched to a new branch '1.14'
> [phil at manjaro mate-panel]$ git log -1
> commit c383cf09d716681f0cca795283d7ef3702814f9e
> Author: monsta <monsta at inbox.ru>
> Date:   Thu May 5 17:16:16 2016 +0300
>
>     added missing variable initialization
> [phil at manjaro mate-panel]$ git bisect start
> [phil at manjaro mate-panel]$ git bisect good v1.12.2
> [phil at manjaro mate-panel]$ git bisect bad v1.14.0
> Bisecting: a merge base must be tested
> [22f1787182a46bc7583be4bb07eb7e0f91c60b65] fix indent a bit
>
> So you add the hash '22f1787182' and so on as '_commit' falue in your
> PKGBUILD and compile the package, test it and decide if it is either bad
> or good.
>
> Lets say it was good:
>
> [phil at manjaro mate-panel]$ git bisect good
> Bisecting: 76 revisions left to test after this (roughly 6 steps)
> [a14d2b7ddde3bc2713b31e692331f74f0b5ceb68] GTK+3: do not use deprecated
> n_screens
>
> Now we have to test hash 'a14d2b7ddd' by changing the '_commit' value
> again in our PKGBUILD and test this package. This goes on and on until
> you have the cuelprint found. Roughly 7 steps.
>
> I hope this helps you to figure out what the regression here is. Then
> you can try to revert this change and see if that is fixing it.
>
> However you can trigger me by then.
>
>
>
>
>
>
> _______________________________________________
> manjaro-dev mailing list
> manjaro-dev at manjaro.org
> http://lists.manjaro.org/mailman/listinfo/manjaro-dev