[Bug 1081842] Re: [cinnamon] Cinnamon Menu not working properly
I can reproduce the following symptoms: - Windows (Super_L) key doesn't bring up the menu. - Right-clicking on the menu button does nothing. - Search works, but I can't press Enter to select the result. It does nothing. - Mouseover the categories does nothing. Disabling places and bookmarks fixes it. In my case, I have ~/Music as a symlink to /mounts/md0p1/Music (on an ext4 partition on an mdraid device), which doesn't automatically mount at boot time (and yes, I ought to fix that as well). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1081842 Title: [cinnamon] Cinnamon Menu not working properly To manage notifications about this bug go to: https://bugs.launchpad.net/linuxmint/+bug/1081842/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1314556] Re: Unable to mount Android MTP device
I'm having the same problem with both my 2012 Nexus 7 and my HTC One M8. If I connect the device, I get the error message "Unable to mount Android Phone: Unable to open MTP device '[usb:005,120]'" for my HTC One M8. The message changes to "Unable to mount Nexus 7" when I plug the Nexus 7 in. The '[usb:005,120]' identifier also changes. (All of the following was done with the HTC phone...) But here's the interesting part: if I run "lsusb" with the error message on the screen, the device is detected one ID higher. Right now, "lsusb" is showing "Bus 005 Device 121: ID 0bb4:061a HTC (High Tech Computer Corp.)" for the phone. Using "ls -l /dev/bus/usb/X/Y" gives: $ ls -l /dev/bus/usb/005/120 ls: cannot access /dev/bus/usb/005/120: No such file or directory $ ls -l /dev/bus/usb/005/121 crw-rw+ 1 root audio 189, 632 Jan 15 20:59 /dev/bus/usb/005/121 dmesg gives the following: $ dmesg [ 3202.628185] usb 5-2: new high-speed USB device number 122 using xhci_hcd [ 3202.650762] usb 5-2: New USB device found, idVendor=0bb4, idProduct=061a [ 3202.650769] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3202.650773] usb 5-2: Product: Android Phone [ 3202.650777] usb 5-2: Manufacturer: HTC [ 3202.653957] usb-storage 5-2:1.2: USB Mass Storage device detected [ 3202.654251] scsi11 : usb-storage 5-2:1.2 [ 3202.796549] usb 5-2: USB disconnect, device number 122 [ 3203.576177] usb 5-2: new high-speed USB device number 123 using xhci_hcd [ 3203.598656] usb 5-2: New USB device found, idVendor=0bb4, idProduct=061a [ 3203.598663] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3203.598667] usb 5-2: Product: Android Phone [ 3203.598670] usb 5-2: Manufacturer: HTC (I've deleted the 'SerialNumber' lines; I don't know if they're sensitive or not) Another time I tried to reproduce the dmesg output, I got: [ 3271.638047] xhci_hcd :08:00.0: xHCI xhci_drop_endpoint called with disabled ep 88056c19e040 [ 3271.638049] xhci_hcd :08:00.0: xHCI xhci_drop_endpoint called with disabled ep 88056c19e000 [ 3271.638051] xhci_hcd :08:00.0: xHCI xhci_drop_endpoint called with disabled ep 88057ad043c0 [ 3271.638052] xhci_hcd :08:00.0: xHCI xhci_drop_endpoint called with disabled ep 88056c19e080 [ 3271.638053] xhci_hcd :08:00.0: xHCI xhci_drop_endpoint called with disabled ep 88057ad041c0 [ 3271.638055] xhci_hcd :08:00.0: xHCI xhci_drop_endpoint called with disabled ep 88057ad04380 [ 3271.638056] xhci_hcd :08:00.0: xHCI xhci_drop_endpoint called with disabled ep 88057ad04180 I don't know if that's related. It doesn't always appear in dmesg. I'm actually using Linux Mint, as follows: $ uname -a Linux roger-pc 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: LinuxMint Description:Linux Mint 17 Qiana Release:17 Codename: qiana $ lsb_release -au No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 14.04 LTS Release:14.04 Codename: trusty -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1314556 Title: Unable to mount Android MTP device To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1314556/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1722411] Re: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com
"debdiff with memory leak fixed" appears to be identical to the original debdiff. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1722411 Title: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1722411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1722411] Re: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com
I'm pretty sure that it's the "compare_ca_name_and_key.patch", which introduces "raw_spki", but doesn't seem to do anything to free it. I'll do some more investigation today. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1722411 Title: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1722411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1722411] Re: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com
I'm trying it with the following extra patch: diff -ruN gnutls28-3.2.11-orig/lib/x509/x509.c gnutls28-3.2.11/lib/x509/x509.c --- gnutls28-3.2.11-orig/lib/x509/x509.c2014-01-01 17:14:59.0 + +++ gnutls28-3.2.11/lib/x509/x509.c 2018-01-18 14:52:52.617834001 + @@ -136,6 +136,7 @@ asn1_delete_structure(>cert); gnutls_free(cert->raw_dn.data); gnutls_free(cert->raw_issuer_dn.data); + gnutls_free(cert->raw_spki.data); gnutls_free(cert); } @@ -202,6 +203,7 @@ asn1_delete_structure(>cert); _gnutls_free_datum(>raw_dn); _gnutls_free_datum(>raw_issuer_dn); + _gnutls_free_datum(>raw_spki); result = asn1_create_element(_gnutls_get_pkix(), "PKIX1.Certificate", @@ -252,6 +262,7 @@ _gnutls_free_datum(&_data); _gnutls_free_datum(>raw_dn); _gnutls_free_datum(>raw_issuer_dn); + _gnutls_free_datum(>raw_spki); return result; } -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1722411 Title: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1722411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1722411] Re: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com
In my testing, that patch appears to fix the memory leak. I'm attaching it properly. I have no idea how to get it in a .debdiff. Also, does that require a version bump to "ubuntu1.3"? ** Patch added: "compare_ca_name_and_key_free.patch" https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1722411/+attachment/5039078/+files/compare_ca_name_and_key_free.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1722411 Title: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1722411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1722411] Re: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com
> I'm pretty sure that it's the "compare_ca_name_and_key.patch", which introduces "raw_spki", but doesn't seem to do anything to free it. Oh, now I see how https://gitlab.com/gnutls/gnutls/commit/cdd60f7013d5e64702f3b04e6fe93218e88a2213 fixes the leak -- by avoiding the allocation in the first place. I wasn't paying attention this morning :) I'll try with the updated debdiff. Thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1722411 Title: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1722411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1722411] Re: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com
> I'll try with the updated debdiff. Thanks. Looks good. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1722411 Title: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1722411/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1722411] Re: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com
The debdiff introduces a memory leak. With the simple program at https://gist.github.com/rlipscombe/78d6e3bbfc67e010f1e7a9ddd8c87099, the previous version is fine, but this one leaks. Valgrind reports the following: ==11134== ==11134== HEAP SUMMARY: ==11134== in use at exit: 1,014,363 bytes in 3,794 blocks ==11134== total heap usage: 978,656 allocs, 974,862 frees, 572,269,255 bytes allocated ==11134== ==11134== 53,462 bytes in 148 blocks are definitely lost in loss record 33 of 37 ==11134==at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11134==by 0x4E6DF61: _gnutls_set_datum (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4E98A4C: _gnutls_x509_get_raw_dn2 (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4EBBDB8: gnutls_x509_crt_import (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4EC0C9D: gnutls_x509_crt_list_import (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4EC0EF6: gnutls_x509_crt_list_import2 (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4E7DCF3: gnutls_certificate_set_x509_trust_mem (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4E7E037: gnutls_certificate_set_x509_trust_file (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x40107C: main (in /vagrant/gnutls-client) ==11134== ==11134== 294,000 bytes in 1,000 blocks are definitely lost in loss record 35 of 37 ==11134==at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11134==by 0x4E6DF61: _gnutls_set_datum (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4E98A4C: _gnutls_x509_get_raw_dn2 (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4EBBDB8: gnutls_x509_crt_import (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4E81246: gnutls_pcert_import_x509_raw (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4EE0FC6: _gnutls_proc_crt (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4E67836: _gnutls_recv_server_certificate (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4E64B0F: gnutls_handshake (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x401253: main (in /vagrant/gnutls-client) ==11134== ==11134== 294,000 bytes in 1,000 blocks are definitely lost in loss record 36 of 37 ==11134==at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11134==by 0x4E6DF61: _gnutls_set_datum (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4E98A4C: _gnutls_x509_get_raw_dn2 (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4EBBDB8: gnutls_x509_crt_import (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4E81246: gnutls_pcert_import_x509_raw (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4EE427A: _gnutls_proc_dhe_signature (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4EEBB2C: proc_ecdhe_server_kx (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4E674B3: _gnutls_recv_server_kx_message (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4E64AB7: gnutls_handshake (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x401253: main (in /vagrant/gnutls-client) ==11134== ==11134== 294,000 bytes in 1,000 blocks are definitely lost in loss record 37 of 37 ==11134==at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11134==by 0x4E6DF61: _gnutls_set_datum (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4E98A4C: _gnutls_x509_get_raw_dn2 (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4EBBDB8: gnutls_x509_crt_import (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4E7C05F: _gnutls_x509_cert_verify_peers (in /usr/lib/x86_64-linux-gnu/libgnutls.so.28.30.1) ==11134==by 0x4012AF: main (in /vagrant/gnutls-client) ==11134== ==11134== LEAK SUMMARY: ==11134==definitely lost: 935,462 bytes in 3,148 blocks ==11134==indirectly lost: 0 bytes in 0 blocks ==11134== possibly lost: 0 bytes in 0 blocks ==11134==still reachable: 78,901 bytes in 646 blocks ==11134== suppressed: 0 bytes in 0 blocks ==11134== Reachable blocks (those to which a pointer was found) are not shown. ==11134== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==11134== ==11134== For counts of detected and suppressed errors, rerun with: -v ==11134== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1722411 Title: gnutls28 in trusty no longer validates many valid certificate chains, such as google.com To manage
[Bug 1869568] Re: Unlock takes a long time
With ALL extensions, it doesn't get slower. When it was getting slower, I had the standard 'gnome-shell-extensions' package installed. I'm going to reinstall it and see if that reproduces the problem. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1869568 Title: Unlock takes a long time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1869568/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1869568] Re: Unlock takes a long time
That should say "With ALL extensions uninstalled..." -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1869568 Title: Unlock takes a long time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1869568/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1869568] Re: Unlock takes a long time
See https://github.com/home-sweet-gnome/dash-to-panel/issues/959, wherein I discover that dash-to-panel seems to be the worst offender in terms of leaking handlers, but there's a lower-grade steady leak anyway, which might bear looking at. ** Bug watch added: github.com/home-sweet-gnome/dash-to-panel/issues #959 https://github.com/home-sweet-gnome/dash-to-panel/issues/959 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1869568 Title: Unlock takes a long time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1869568/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1869568] Re: Unlock takes a long time
This is proving to be really difficult to reproduce -- it's getting slower (but really slowly) on my spare PC. The memory use for gnome- shell is, essentially, static. So: I sampled some perf data from the PC where it consistently happens and threw up a flame graph. It spends a bunch of time in 'clutter_actor_destroy' -> 'destroy_closure_array' -> 'handler_lookup'. This suggests to me that some extension or other is registering a handler for something multiple times, and not cleaning it up, which means it takes longer and longer to iterate through the list of handlers. I'm gonna have a rummage through the source code to see which function adds handlers, and then I'll attach a debugger to it to see if something's leaking registered handlers. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1869568 Title: Unlock takes a long time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1869568/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1869568] Re: Unlock takes a long time
> see if something's leaking registered handlers. It looks like clutter handlers are stored in two different hash tables: g_handlers and g_handler_list_bsa_ht. On the PC that's really slow, g_handlers.size = 8388608 (that's ~8M); on the PC that's not, g_handlers.size = 65536 (~65K). So, yeah, something's leaking, afaict. Gonna see if the hash table entries (signal_id, instance, closure) point to anything that gives me a clue. Given that the extensions are written mostly in JS, this is gonna be all kinds of interesting... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1869568 Title: Unlock takes a long time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1869568/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1869568] [NEW] Unlock takes a long time
Public bug reported: I searched and found related bugs #1774188 and #1847566, but one of those is against 19.04, which is end-of-support, and the other was abandoned with no feedback from the OP. So, let's try again. When unlocking my screen, it takes progressively longer to unlock. After a fresh restart, it's pretty quick. After about a day, it takes about a second. After a longer period, it takes up to 5 seconds. When I press Enter at the lock screen to get to the password entry, the "wipe" effect commonly stalls as it gets near the top of the screen; not sure if this is related. After correctly entering my password, it takes several seconds before my desktop is visible. It's _there_, because moving the mouse around changes the mouse pointer according to what's under it (e.g. it turns into an I-bar on the Firefox search/address box and a finger icon on a link). It just takes several seconds to actually draw the screen. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-shell 3.28.4-0ubuntu18.04.3 ProcVersionSignature: Ubuntu 5.3.0-42.34~18.04.1-generic 5.3.18 Uname: Linux 5.3.0-42-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.12 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Sun Mar 29 11:10:07 2020 DisplayManager: gdm3 EcryptfsInUse: Yes InstallationDate: Installed on 2020-01-10 (78 days ago) InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805) SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gnome-shell (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1869568 Title: Unlock takes a long time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1869568/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1869568] Re: Unlock takes a long time
I can't do that on my primary PC -- I'm *using* those extensions. I'll set up my spare PC the same way (with the extensions) and see if I can repro. Then I'll disable them and see if the problem goes away (or not). Gonna take me about a week, though, since this only happens after a bunch of locking and unlocking. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1869568 Title: Unlock takes a long time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1869568/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1869568] Re: Unlock takes a long time
Some investigation and notes (and apologies for the noise; I need somewhere to take notes): I have the following extensions in /usr/share/gnome-shell/extensions: alternate-...@gnome-shell-extensions.gcampax.github.com/ apps-m...@gnome-shell-extensions.gcampax.github.com/ auto-move-wind...@gnome-shell-extensions.gcampax.github.com/ dash-to-d...@micxgx.gmail.com/ dash-to-pa...@jderose9.github.com/ drive-m...@gnome-shell-extensions.gcampax.github.com/ hidetop...@mathieu.bidon.ca/ launch-new-insta...@gnome-shell-extensions.gcampax.github.com/ mediapla...@patapon.info/ move_cl...@jonathan.bluemosh.com/ multi-monitors-add-on@spin83/ native-window-placem...@gnome-shell-extensions.gcampax.github.com/ pixel-sa...@deadalnix.me/ places-m...@gnome-shell-extensions.gcampax.github.com/ screenshot-window-si...@gnome-shell-extensions.gcampax.github.com/ TaskBar@zpydr/ ubuntu-appindicat...@ubuntu.com/ ubuntu-d...@ubuntu.com/ user-th...@gnome-shell-extensions.gcampax.github.com/ window-l...@gnome-shell-extensions.gcampax.github.com/ windowsnaviga...@gnome-shell-extensions.gcampax.github.com/ workspace-indica...@gnome-shell-extensions.gcampax.github.com/ I have the following extensions installed via apt (reason, where known): gnome-shell-extension-appindicator (ubuntu-desktop) gnome-shell-extension-autohidetopbar (explicit) gnome-shell-extension-dashtodock (explicit) gnome-shell-extension-dash-to-panel (explicit) gnome-shell-extension-mediaplayer (explicit) gnome-shell-extension-move-clock (explicit) gnome-shell-extension-multi-monitors (explicit) gnome-shell-extension-pixelsaver (explicit) gnome-shell-extensions (explicit) gnome-shell-extension-taskbar (explicit) gnome-shell-extension-ubuntu-dock (ubuntu-desktop) ubuntu-session (ubuntu-desktop) I'm trying to figure out which directory maps to which .deb package, and then I'll remove the extensions that I'm not using. If that solves the problem: job done. I also have the following extensions installed in ~/.local/share/gnome- shell/extensions: alternate-...@gnome-shell-extensions.gcampax.github.com/ dash-to-pa...@jderose9.github.com/ multi-monitors-add-on@spin83/ audio-output-switcher@anduchs/ hidetop...@mathieu.bidon.ca/ I'm not sure what it means that I have an extension listed in both locations. I've removed the dashtodock and pixelsaver extensions; I wasn't using them. I'll remove some more unused extensions if that doesn't solve the problem. Concurrently, I'll leave my other PC nearly stock and I'll lock/unlock it a bunch of times over the next week or so and see if it gets slower. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1869568 Title: Unlock takes a long time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1869568/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1869568] Re: Unlock takes a long time
I've also removed gnome-shell-extension-move-clock, gnome-shell- extension-autohidetopbar and gnome-shell-extension-taskbar. > I'm not sure what it means that I have an extension listed in both locations. I suspect that either I've installed it explicitly, or extensions.gnome.org installed an update. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1869568 Title: Unlock takes a long time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1869568/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1869568] Re: Unlock takes a long time
Update: my spare PC is definitely getting slower at unlocking, but (possibly because I'm not using it as much) not as quickly. Are there any logs/debug steps you want me to run on it? I know enough gdb to be dangerous, if that helps. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1869568 Title: Unlock takes a long time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1869568/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
