[14:52] <wahbwahb1> Hi! I'm trying to build emacs using snapcraft and I'm running into this issue: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1611505 - where 'loaders.cache' doesn't get copied into the snapcraft container. I was wondering if anyone can help. Here's my snapcraft.yaml: https://gist.github.com/benwah/7f027dbb50ec2279ba3d603145040546
[14:52] <ubot5> Ubuntu bug 1611505 in snapcraft (Ubuntu) "gdk-pixbuf cache is missing from snap" [Undecided,Confirmed]
[14:53] <wahbwahb1> After I build the snap, I seem to find this `loaders.cache` file in the expected location, under ./prime ./stage ./parts/emacs/install
[14:53] <wahbwahb1> First time trying to build a snap FYI
[21:00] <brain_> Just a heads up.  I believe I found the solution to a pretty critical bug that causes gnome-shell in Ubuntu 17.04 to crash a lot.
[21:00] <brain_> https://bugs.launchpad.net/ubuntu/+source/mozjs38/+bug/1682631
[21:00] <ubot5> Ubuntu bug 1682631 in mozjs38 (Ubuntu) "gnome-shell crashes in libmozjs on x86_64" [Undecided,Confirmed]
[21:02] <bdmurray> brain_: Do you end up with a .crash file in /var/crash?
[21:06] <brain_> Yes, but I believe it's fairly worthless.  For one, the dbg package doesn't exist, so I don't have debug symbols.  But more than that, I've pretty much confirmed that the package's own tests segfault all over the place because it's not being compiled with the right arguments.  So I believe it would be fruitless to look at the crash file because you'd be chasing an improper compiler optimization which would be a nightmare to diag
[21:06] <brain_> nose
[21:07] <bdmurray> brain_: If the crash file were submitted to the Ubuntu Error Tracker it would be automatically retraced with the dbg symbols and then a crash signature would be generated. That is used to then aggregate the crashes so we have an idea of the scope of impact.
[21:09] <bdmurray> brain_: So if you were to file it, if it hasn't been already, then I could do a bit more research into the matter and prioritize the bug appropriately.
[21:11] <brain_> How do I file one from the past using my .crash file I have saved?
[21:12] <bdmurray> Is there a .uploaded file corresponding to the .crash file? If so run 'sudo service whoopsie status'. If not run 'ubuntu-bug /var/crash/$file.crash'. Then check the whoopsie log for an OOPS ID.
[21:13] <bdmurray> e.g. Reported OOPS ID 0d3ef9fc-2154-11e7-bc49-fa163eba73df
[21:22] <brain_> Here's one:  Reported OOPS ID 3f8b3c3c-2158-11e7-9ffd-fa163e839e11
[21:24] <brain_> I don't know what your classification system looks like, but I would think this bug is hard to classify.  It doesn't look like it always crashes in the same place.  I've seen crashes occur in libmozjs-38-0, other times in libgjs, other times in gnome-shell.  The time and place and frequency of the crash also probably depends on the javascript gnome extensions that people have installed.
[21:25] <bdmurray> but rebuilding mozjs38 not gnome-shell helped?
[21:26] <brain_> Using the -fno-strict-aliasing flag, yes.  My friend with the same setup was experiencing crashes much more frequently with me, and he's gone a long time now without a crash.  But I think the fact that the package's own tests no longer segfault is the best piece of evidence that it works
[21:27] <brain_> Here are some others:  d3ba2dc8-2158-11e7-8d8f-fa163ef911dc  d889b8aa-2158-11e7-b7fe-fa163e192766
[21:29] <bdmurray> brain_: Okay, I've subscribed somebody more familiar with the package. Thanks for the information.
[21:29] <brain_> Cool, thanks.
[21:33] <bdmurray> If you don't hear anything early next week, feel free to track me down.