Your concerns are valid. May I suggest you take them to a new thread on
https://forum.snapcraft.io/ ? There will be many more eyes on it, and
I'm sure you will get more elaborate and constructive answers there,
than in this bug report.
Regarding the source code to build the snaps, in the case of c
The pinning is holding me back for moving from current version to 20.04.
So far the only option I see is to use the beta you pointed me to or switch
to google-chrome which looks like there still create debs.
Not being able to pin things and not being able to choose when the snap upgrade
is a prob
I'm glad that this update fixes the crash, thanks for the feedback.
I don't have a general solution to the problem you expose (pinning a
specific revision of a snap), but in the description you mention 16.04
and 18.04, and both offer deb packages for chromium (the chromium deb
was transitioned to
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
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 recomm
it need the no-sandbox to work.
On 6/11/20 10:57 AM, Olivier Tilloy wrote:
> Thanks for the upstream report Mike. I see it has been marked as a
> duplicate of
> https://bugs.chromium.org/p/chromium/issues/detail?id=1035803, and
> comment #19 there suggests the following:
>
> tldr; manually turn o
Thanks for the upstream report Mike. I see it has been marked as a
duplicate of
https://bugs.chromium.org/p/chromium/issues/detail?id=1035803, and
comment #19 there suggests the following:
tldr; manually turn off shared memory by using the "--no-xshm" flag,
setting the environment variable "QT_X11
I have reported the bug.
Here is the url.
https://bugs.chromium.org/p/chromium/issues/detail?id=1085136
On 5/20/20 8:24 AM, Olivier Tilloy wrote:
> Indeed, it appears to be the same problem. I think an actual bug report
> (as opposed to a support thread) would be useful if we want upstream
> deve
Indeed, it appears to be the same problem. I think an actual bug report
(as opposed to a support thread) would be useful if we want upstream
developers to look into the issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bug
It look like
https://support.google.com/chrome/thread/41722791?hl=en
On 5/19/20 8:48 AM, Olivier Tilloy wrote:
> Ack, thanks Mike. In light of this information, I have removed the
> duplicate status.
>
> Is there an upstream bug report for the crash? If not, would you mind
> filing one at crbug.
Ack, thanks Mike. In light of this information, I have removed the
duplicate status.
Is there an upstream bug report for the crash? If not, would you mind
filing one at crbug.com ?
** This bug is no longer a duplicate of bug 1857252
chromium 79 remote display broken
--
You received this bug
*** This bug is a duplicate of bug 1857252 ***
https://bugs.launchpad.net/bugs/1857252
Sorry about last comment. (ignore last comment)
The workaround in bug 18752 fixes the blank screen. (This is also my bug report)
export QT_X11_NO_MITSHM=1
export _X11_NO_MITSHM=1
export _MITSHM=0
This work
*** This bug is a duplicate of bug 1857252 ***
https://bugs.launchpad.net/bugs/1857252
Can no long test this bug as chromium has moved on to 81.0.4044.132 and
now has a different set of problems.
Thing crash on on gpu problems.
Look at Bug 1877173.
On 5/15/20 7:58 AM, Olivier Tilloy wrote:
*** This bug is a duplicate of bug 1857252 ***
https://bugs.launchpad.net/bugs/1857252
Ack. What about the suggestion in comment #12 in the upstream bug report
(https://bugs.chromium.org/p/chromium/issues/detail?id=1026950) ?
Does this work around the crash?
--
You received this bug notific
*** This bug is a duplicate of bug 1857252 ***
https://bugs.launchpad.net/bugs/1857252
This is not the same problem.
The --use-gl=swiftshader work for chrome before 81.0.4044.138. Without the
--use-gl option it only had a blank (gray) screen but did not crash.
On 81.0.4044.138 it crashes (e
*** This bug is a duplicate of bug 1857252 ***
https://bugs.launchpad.net/bugs/1857252
Disabling the sandbox is not recommended, you're loosing process
isolation.
Another suggested workaround in
https://bugzilla.redhat.com/show_bug.cgi?id=1786306 is to run chromium
with "--use-gl=swiftshader"
That did work for both 18.04 and 16.04
Any idea what i lose by not having the sandbox ?
On 5/7/20 4:38 AM, Sebastien Bacher wrote:
> Seems similar to https://support.google.com/chrome/thread/41722791?hl=en
> , does it work if you use --no-sandbox ?
>
--
You received this bug notification becaus
Seems similar to https://support.google.com/chrome/thread/41722791?hl=en
, does it work if you use --no-sandbox ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1877173
Title:
Chromium 81.0.4044.122
18 matches
Mail list logo
