Avainsanana Ubuntu

Release 16 doesn’t work in Gnome Shell 3.28 (Ubuntu 18.04): GObject.registerClass() used with invalid base class (is PanelMenuButton)

4. toukokuuta 2019 klo 21.02
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Gnome, Ubuntu

I’m using Ubuntu 18.04, which has Gnome Shell 3.28 (3.28.3+git20190124-0ubuntu18.04.1).

After I updated the extension to latest release (16), it fails to start. Gnome Shell reports this error:

Extension "System_Monitor@bghome.gmail.com" had error: TypeError: GObject.registerClass() used with invalid base class (is PanelMenuButton)

Downgrading to release 14 makes it work again.

Ubuntu’s appindicator extension has a similar issue from a while back, with pointers to an issue with the extensions website, but I’m unsure if this is related.

In any case, I decided to open this issue to at least document it. Feel free to close it if it’s intentional (Gnome Shell 3.28 no longer supported), or otherwise not a bug with System Monitor.

Vastaa viestiin sen kontekstissa (Github)

Tested this again and it seems to have been fixed at some point

21. helmikuuta 2019 klo 17.13
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Gnome, Ubuntu

Tested this again and it seems to have been fixed at some point by some Ubuntu (18.04) updates: my test user still had version 8 of the extension, and I could no longer reproduce the issue, neither before nor after updating the extension to release v9. My main user’s desktop now also appears unaffected.

(I was going to try the workaround reported by @ChrisLancs, but ended up not having to. My ”List type” is set to ”Disabled”.)

Vastaa viestiin sen kontekstissa (Github)

After adding the PPA, replace ’cosmic’ with ’bionic’ in the sources list

15. joulukuuta 2018 klo 16.01
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Ubuntu

Alternatively, after adding the PPA, replace ’cosmic’ with ’bionic’ in the sources list, as the package for Bionic currently appears to install and work in Cosmic just fine (from my brief testing).

Vastaa viestiin sen kontekstissa (Github)

So I did a little more digging, and found that this first cropped up in Ubuntu 17.10

25. marraskuuta 2018 klo 17.54
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Ubuntu

So I did a little more digging, and found that this actually first cropped up in Ubuntu 17.10.

I then ran mozregression (back on 18.04, my main desktop) and here’s what it found:

7:12.48 INFO: Last good revision: 64bab5cbb9b63808d04babfbcfba3175fd99f69d (2017-10-25)
7:12.48 INFO: First bad revision: aa958b29c149a67fce772f8473e9586e71fbdb46 (2017-10-26)
7:12.48 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=64bab5cbb9b63808d04babfbcfba3175fd99f69d&tochange=aa958b29c149a67fce772f8473e9586e71fbdb46

After that ”There are no build artifacts on inbound for these changesets (they are probably too old).”

As this was my first time ever using mozregression, I have no idea how useful that was, but if there’s some way I can narrow this down further, I’d be happy to.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

I’m using Ubuntu 18.04, and that appears to be crucial here

21. marraskuuta 2018 klo 18.27
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Ubuntu

Adrian: Thanks for taking a look! I’m using Ubuntu 18.04, and that appears to be crucial here: I created a 16.04 VM, installed all in-release updates (including Firefox 63), and just as you, was unable to reproduce the issue. I then upgraded the VM to 18.04 and the bug immediately manifested again.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

I first reported this against 62 in Launchpad

17. marraskuuta 2018 klo 15.13
Sijainti: Vianhallintajärjestelmät: Mozilla Bugzilla
Avainsanat: Firefox, Launchpad, Ubuntu

I first reported this against 62 in Launchpad: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1798103

Firefox was since updated to 63 in Ubuntu and the issue remains.

Vastaa viestiin sen kontekstissa (Mozilla Bugzilla)

Debian derivatives installation example uses `ln -s` instead of `a2ensite`

30. syyskuuta 2018 klo 13.43
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Apache, Debian, Nextcloud, Ubuntu

Under Apache Web server configuration, there’s a prompt to create a symlink to enable the newly created site:

ln -s /etc/apache2/sites-available/nextcloud.conf /etc/apache2/sites-enabled/nextcloud.conf

As the instructions in this section are written for Debian, Ubuntu, and their derivatives, a2ensite should be used instead:

a2ensite nextcloud.conf

The commands are currently functionally equivalent (AFAIK), but should this change sometime, the latter would be more future proof, besides being much shorter and easier to type.

Additionally, immediately following the ln -s there is a section about Additional Apache configurations, which correctly instructs the use of a2enmod to create the symlinks. Replacing ln -s with a2ensitewould thus harmonize the two sections.

Vastaa viestiin sen kontekstissa (Github)

All right. Thanks, Jeremy!

8. syyskuuta 2018 klo 16.02
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Gnome, Ubuntu

All right. Thanks, Jeremy!

Vastaa viestiin sen kontekstissa (Launchpad)

Okay, did it!

7. syyskuuta 2018 klo 18.19
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Gnome, Ubuntu

Okay, did it! https://gitlab.gnome.org/GNOME/gnome-terminal/issues/30

Vastaa viestiin sen kontekstissa (Launchpad)

No way to disunify/unify ’New Terminal’ during runtime

7. syyskuuta 2018 klo 18.18
Sijainti: Vianhallintajärjestelmät: Gnome GitLab
Avainsanat: Fedora, Gnome, saavutettavuus, Ubuntu

Some years back (2013/2014 maybe?) the ’New Window’ and ’New Tab’ menu items were combined into a single ’New Terminal’ item.

This apparently met with resistance from users, so Fedora and recently also Ubuntu have chosen to build Gnome terminal with DISUNIFY_NEW_TERMINAL_SECTION to restore the old behavior.

This unfortunately leaves users of those distros, like myself, who actually prefer the simplicity of ’New Terminal’, with no practical way to restore that functionality (beyond rebuilding the package with the compile-time switch reverted).

After hearing me out, the Ubuntu maintainer suggested I file a bug here, asking to turn the compile-time option into a Gsetting so that the behavior could be more easily adjusted per user preferences.

So that is what I’m asking here.

Vastaa viestiin sen kontekstissa (Gnome GitLab)

Vanhempia »