gjs spamming the journal with stack traces

Another long time annoyance is the endless number of stack traces gjs inserts to the journal. As best as I can figure, based on reading, someone thought this was a good idea to find legacy js scripts or some such stuff. This is and example of the log entries that keep being inserted:

gnome-shell[1981]: Object St.BoxLayout (0x5603b05ffc50), has been already finalized. Impossible to get any property from it.
org.gnome.Shell.desktop[1981]: == Stack trace for context 0x5603ab329170 ==
org.gnome.Shell.desktop[1981]: #0 0x7ffd99df2850 b resource:///org/gnome/shell/ui/tweener.js:73 (0x7f0d5c1ddef0 @ 9)
org.gnome.Shell.desktop[1981]: #1 0x7ffd99df28f0 b resource:///org/gnome/shell/ui/tweener.js:105 (0x7f0d5c1df230 @ 36)
org.gnome.Shell.desktop[1981]: #2 0x7ffd99df2990 b resource:///org/gnome/shell/ui/tweener.js:92 (0x7f0d5c1df098 @ 52)
org.gnome.Shell.desktop[1981]: #3 0x7ffd99df3560 I resource:///org/gnome/gjs/modules/tweener/tweener.js:203 (0x7f0d5c1e9cd0 @ 54)
org.gnome.Shell.desktop[1981]: #4 0x7ffd99df36b0 b resource:///org/gnome/gjs/modules/tweener/tweener.js:332 (0x7f0d5c1e9d58 @ 1626)
org.gnome.Shell.desktop[1981]: #5 0x7ffd99df3760 b resource:///org/gnome/gjs/modules/tweener/tweener.js:345 (0x7f0d5c1e9de0 @ 100)
org.gnome.Shell.desktop[1981]: #6 0x7ffd99df37f0 b resource:///org/gnome/gjs/modules/tweener/tweener.js:360 (0x7f0d5c1e9e68 @ 10)
org.gnome.Shell.desktop[1981]: #7 0x7ffd99df3870 I resource:///org/gnome/gjs/modules/signals.js:126 (0x7f0d5c1e2b38 @ 386)
org.gnome.Shell.desktop[1981]: #8 0x7ffd99df3920 b resource:///org/gnome/shell/ui/tweener.js:208 (0x7f0d5c1df808 @ 159)
org.gnome.Shell.desktop[1981]: #9 0x7ffd99df3980 I resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f0d5c1c2bc0 @ 71)
org.gnome.Shell.desktop[1981]: #10 0x7ffd99df3980 I resource:///org/gnome/shell/ui/tweener.js:183 (0x7f0d5c1df780 @ 20)
org.gnome.Shell.desktop[1981]: #11 0x7ffd99df3a10 I self-hosted:917 (0x7f0d5c1ee5e8 @ 394)
org.gnome.Shell.desktop[1981]: == Stack trace for context 0x5603ab329170 ==
org.gnome.Shell.desktop[1981]: #0 0x7ffd99df2850 b resource:///org/gnome/shell/ui/tweener.js:80 (0x7f0d5c1ddef0 @ 82)
org.gnome.Shell.desktop[1981]: #1 0x7ffd99df28f0 b resource:///org/gnome/shell/ui/tweener.js:105 (0x7f0d5c1df230 @ 36)
org.gnome.Shell.desktop[1981]: #2 0x7ffd99df2990 b resource:///org/gnome/shell/ui/tweener.js:92 (0x7f0d5c1df098 @ 52)
org.gnome.Shell.desktop[1981]: #3 0x7ffd99df3560 I resource:///org/gnome/gjs/modules/tweener/tweener.js:203 (0x7f0d5c1e9cd0 @ 54)
org.gnome.Shell.desktop[1981]: #4 0x7ffd99df36b0 b resource:///org/gnome/gjs/modules/tweener/tweener.js:332 (0x7f0d5c1e9d58 @ 1626)
org.gnome.Shell.desktop[1981]: #5 0x7ffd99df3760 b resource:///org/gnome/gjs/modules/tweener/tweener.js:345 (0x7f0d5c1e9de0 @ 100)
org.gnome.Shell.desktop[1981]: #6 0x7ffd99df37f0 b resource:///org/gnome/gjs/modules/tweener/tweener.js:360 (0x7f0d5c1e9e68 @ 10)
org.gnome.Shell.desktop[1981]: #7 0x7ffd99df3870 I resource:///org/gnome/gjs/modules/signals.js:126 (0x7f0d5c1e2b38 @ 386)

I found a Redhat patch to address this mess: https://bugzilla.redhat.com/attachment.cgi?id=1433199

Personally, I just want a clean log. I just comment out g_critical( … up to and including gjs_dumpstack(); and six in all for the 1.50.4 version.

So:
1. ebuild gjs-1.50.4.ebuild configure
2. Comment out the blocks of code.
3. ebuild gjs-1.50.4.ebuild compile — look for errors
4. ebuild gjs-1.50.4.ebuild install
5. ebuild gjs-1.50.4.ebuild qmerge

I do save the tree under image to a safe spot so I do not have to go through this again. If you need to see the errors just do a regular emerge of gjs. After you are done copy back the lib files to quiet everything down again.

*** As a note, when I do “emerge @changed-deps”, portage wants to replace gjs. I do “emerge -v –exclude gjs @changed-deps” to keep this from happening ***

evolution-calendar login errors

Finally decided to shut this up:


e_cal_recur_generate_instances_sync: assertion 'icaltime_compare (interval_start, interval_end) < 0' failed

I found this patch:
diff -up gnome-shell-3.26.2/src/calendar-server/gnome-shell-calendar-server.c.xxxx gnome-shell-3.26.2/src/calendar-server/gnome-shell-calendar-server.c
--- gnome-shell-3.26.2/src/calendar-server/gnome-shell-calendar-server.c.xxxx 2017-11-02 17:05:55.000000000 +0100
+++ gnome-shell-3.26.2/src/calendar-server/gnome-shell-calendar-server.c 2018-04-30 14:07:17.611055378 +0200
@@ -590,6 +590,11 @@ app_load_events (App *app)
g_list_free (app->live_views);
app->live_views = NULL;

+ if (!app->since || !app->until)
+ {
+ print_debug ("Skipping load of events, no time interval set yet");
+ return;
+ }
/* timezone could have changed */
app_update_timezone (app);

So:
1. ebuild gnome-shell-3.26.2-r4.ebuild configure
2. Install the patch
3. ebuild gnome-shell-3.26.2-r4.ebuild compile — look for errors
4. ebuild gnome-shell-3.26.2-r4.ebuild install
5. ebuild gnome-shell-3.26.2-r4.ebuild qmerge

Polkit and USB Mount Authentication

Suddenly popping in a USB or CD/DVD was asking for authentication!  Short story, polkit issue.  Edit org.freedesktop.udisks2.policy in /usr/share/polkit-1/actions and change:

org.freedesktop.udisks2.filesystem-mount-other-seat
org.freedesktop.udisks2.eject-media-other-seat

to read:

“<allow_active> yes</allow_active>”

polkit — Authorization Manager

OS/2: Blue Lion – Arca Noae

According to the Arca Noae site:

Blue Lion is Go!

Arca Noae has become an IBM business partner and has an agreement in place that enables us to produce our own OS/2 distribution. We have given this project the code name “Blue Lion” (which probably won’t be the final release name!).

Other sites:

TechRepublic: OS/2: Blue Lion to be the next distro of the 28-year-old OS

Arca Noae is developing a new full distribution of OS/2 that should ease the pain of upgrading or deploying the OS on modern hardware.

OSNews: Blue Lion: new OS/2 distribution due 2016

The Register: Is the world ready for a bare-metal OS/2 rebirth?

 

 

Virtual Box VERR_VM_DRIVER_NOT_ACCESSIBLE error.

I saw this in the logs of both VB 4.3.30 and 5+:

Failed to open “/dev/vboxdrvu”, errno=13, rc=VERR_VM_DRIVER_NOT_ACCESSIBLE

Which based on this post (Ref) is caused by having the wrong permissions, resulting in:

ls -l /dev
 
crw------- 1 root root 10, 57 Oct 2 05:58 vboxdrv
crw------- 1 root root 10, 56 Oct 2 05:58 vboxdrvu
crw------- 1 root root 10, 55 Oct 2 05:58 vboxnetctl
drwxr-x--- 4 root vboxusers 80 Oct 2 05:58 vboxusb

The fix is to create /lib/udev/rules.d/20-virtualbox2.rules and add:

KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="vboxusers", MODE="0660"
KERNEL=="vboxdrvu", NAME="vboxdrvu", OWNER="root", GROUP="vboxusers", MODE="0660"
KERNEL=="vboxnetctl", NAME="vboxnetctl", OWNER="root",GROUP="vboxusers", MODE="0660"

Then restart the system and the permissions are now:

ls -l /dev
 
crw-rw---- 1 root vboxusers 10, 57 Oct 5 06:00 vboxdrv
crw-rw---- 1 root vboxusers 10, 56 Oct 5 06:00 vboxdrvu
crw-rw---- 1 root vboxusers 10, 55 Oct 5 06:00 vboxnetctl
drwxr-x--- 4 root vboxusers 80 Oct 5 06:00 vboxusb

I am not sure how correct this is by including vboxdrv, but it does prevent the errors in VB logs.