that fixes the --no-sandbox but still needs the
QT_X11_NO_MITSHM=1
also the --no-xshm works now.
This whole bug report shows my big problem with snaps.
In production I have a pin a version of chromium that works so that I can use
webdriver to access a number of site that I need to submit data to.
Once snap become in place I do not see any way to lock/pin a version of chromium that
works while the bug get fix.
How can problems like this be dealt with ?
On 6/12/20 10:52 AM, Olivier Tilloy wrote:
> https://bugs.chromium.org/p/chromium/issues/detail?id=1039560#c14
> suggests that this should be fixed in the latest 83 stable update.
>
> Would you mind testing that update from https://launchpad.net
> /~canonical-chromium-builds/+archive/ubuntu/stage and reporting whether
> the issue persists?
>
> I'd recommend disabling that PPA after the test, the updates will
> eventually be available in the Ubuntu archive.
>
that fixes the --no-sandbox but still needs the
QT_X11_NO_MITSHM=1
also the --no-xshm works now.
This whole bug report shows my big problem with snaps.
In production I have a pin a version of chromium that works so that I can use
webdriver to access a number of site that I need to submit data to.
Once snap become in place I do not see any way to lock/pin a version of chromium that
works while the bug get fix.
How can problems like this be dealt with ?
On 6/12/20 10:52 AM, Olivier Tilloy wrote: /bugs.chromium. org/p/chromium/ issues/ detail? id=1039560# c14 /launchpad. net chromium- builds/ +archive/ ubuntu/ stage and reporting whether
> https:/
> suggests that this should be fixed in the latest 83 stable update.
>
> Would you mind testing that update from https:/
> /~canonical-
> the issue persists?
>
> I'd recommend disabling that PPA after the test, the updates will
> eventually be available in the Ubuntu archive.
>