Bug#1072157: gnome-shell: Log spam: g_closure_unref: assertion 'closure->ref_count > 0' failed
Package: gnome-shell Version: 43.9-0+deb12u2 Severity: important Dear Maintainer, when switching to the overview (pressing super key or using the active top left corner), a message is written to the syslog containing g_closure_unref: assertion 'closure->ref_count > 0' failed For every extension that is enabled this message seems to be logged too, but even without an extension it is logged at least once, so with 4 enabled extensions it's 5 messages with every switch to the overview. When being awakened from sleep/hibernation, this problem is worsening, with more and more such messages appearing, also leading to severe lag (multiple seconds). Re-login resets the problem, but it quickly accumulates again. There is an Ubuntu bug (2045632) without solution, pointing to enabled extensions, but my systems shows at least one message even with all of them disabled. I currently have no idea how to give you further information about this, if you have any clue, I'm happy to assist hunting that bugger down. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii gir1.2-accountsservice-1.0 22.08.8-6 ii gir1.2-adw-1 1.2.2-1 ii gir1.2-atk-1.0 2.46.0-5 ii gir1.2-atspi-2.0 2.46.0-5 ii gir1.2-freedesktop 1.74.0-3 ii gir1.2-gcr-3 3.41.1-1+b1 ii gir1.2-gdesktopenums-3.0 43.0-1 ii gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1 ii gir1.2-gdm-1.0 43.0-3 ii gir1.2-geoclue-2.0 2.6.0-2 ii gir1.2-glib-2.0 1.74.0-3 ii gir1.2-gnomebluetooth-3.042.5-3 ii gir1.2-gnomedesktop-3.0 43.2-2 ii gir1.2-graphene-1.0 1.10.8-1 ii gir1.2-gstreamer-1.0 1.22.0-2 ii gir1.2-gtk-3.0 3.24.38-2~deb12u1 ii gir1.2-gtk-4.0 4.8.3+ds-2+deb12u1 ii gir1.2-gweather-4.0 4.2.0-2 ii gir1.2-ibus-1.0 1.5.27-5 ii gir1.2-mutter-11 43.8-0+deb12u1 ii gir1.2-nm-1.01.42.4-1 ii gir1.2-nma-1.0 1.10.6-1 ii gir1.2-pango-1.0 1.50.12+ds-1 ii gir1.2-polkit-1.0122-3 ii gir1.2-rsvg-2.0 2.54.7+dfsg-1~deb12u1 ii gir1.2-soup-3.0 3.2.2-2 ii gir1.2-upowerglib-1.00.99.20-2 ii gir1.2-webkit2-4.1 2.44.2-1~deb12u1 ii gnome-backgrounds43.1-1 ii gnome-settings-daemon43.0-4 ii gnome-shell-common 43.9-0+deb12u2 ii gsettings-desktop-schemas43.0-1 ii gstreamer1.0-pipewire0.3.65-3+deb12u1 ii libatk-bridge2.0-0 2.46.0-5 ii libatk1.0-0 2.46.0-5 ii libc62.36-9+deb12u7 ii libcairo21.16.0-7 ii libecal-2.0-23.46.4-2 ii libedataserver-1.2-273.46.4-2 ii libgcr-base-3-1 3.41.1-1+b1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgirepository-1.0-11.74.0-3 ii libgjs0g 1.74.2-1+deb12u1 ii libgles2 1.6.0-1 ii libglib2.0-0 2.74.6-2+deb12u2 ii libglib2.0-bin 2.74.6-2+deb12u2 ii libgnome-autoar-0-0 0.4.3-1 ii libgnome-desktop-3-2043.2-2 ii libgraphene-1.0-01.10.8-1 ii libgtk-3-0 3.24.38-2~deb12u1 ii libgtk-4-1 4.8.3+ds-2+deb12u1 ii libical3 3.0.16-1+b1 ii libjson-glib-1.0-0 1.6.6-1 ii libmutter-11-0 43.8-0+deb12u1 ii libnm0 1.42.4-1 ii libpango-1.0-0 1.50.12+ds-1 ii libpangocairo-1.0-0
Bug#932752: apt-get dist-upgrade fails on missing locales
Package: apt Version: 1.4.9 Severity: important Dear Maintainer, when upgrading a fresh install of Stretch to Buster (German localization) and having a Gnome desktop environment, libpam0g:amd64 fails to configure due to missing locales: Preparing to unpack .../libpam0g_1.3.1-5_amd64.deb ... Unpacking libpam0g:amd64 (1.3.1-5) over (1.1.8-3.6) ... Setting up libpam0g:amd64 (1.3.1-5) ... locale: Kann LC_ALL nicht auf die Standard-Lokale einstellen: Datei oder Verzeichnis nicht gefunden Checking for services that may need to be restarted...awk: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory Checking init scripts... awk: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory dpkg: error processing package libpam0g:amd64 (--configure): subprocess installed post-installation script returned error exit status 127 Errors were encountered while processing: libpam0g:amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) This is resulting in a dependency loop with libtinfo6, that can't be resolved by running apt-get install -f, even after regenerating the locales by hand (which is possible). test@debian-test:~$ sudo locale-gen Generating locales (this might take a while)... de_DE.UTF-8... done Generation complete. test@debian-test:~$ sudo apt-get update && sudo apt-get dist-upgrade OK:1 http://debian.mirror.lrz.de/debian buster InRelease OK:2 http://debian.mirror.lrz.de/debian buster-updates InRelease OK:3 http://security.debian.org/debian-security buster/updates InRelease Paketlisten werden gelesen... Fertig Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen Fertig Probieren Sie »apt --fix-broken install«, um dies zu korrigieren. Die folgenden Pakete haben unerfüllte Abhängigkeiten: guile-2.2-libs : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert libedit2 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert libllvm7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert libncurses6 : Hängt ab von: libtinfo6 (= 6.1+20181013-2) ist aber nicht installiert libreadline7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt --fix-broken install« ohne Angabe eines Pakets (oder geben Sie eine Lösung an). test@debian-test:~$ sudo apt-get install -f Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen Fertig Abhängigkeiten werden korrigiert ... Fertig Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt: guile-2.2-libs libncurses6 libpython3.7-minimal libsasl2-modules libzstd1 mariadb-common python3.7-minimal Verwenden Sie »sudo apt autoremove«, um sie zu entfernen. The following additional packages will be installed: libtinfo6 Die folgenden NEUEN Pakete werden installiert: libtinfo6 0 aktualisiert, 1 neu installiert, 0 zu entfernen und 1323 nicht aktualisiert. 47 nicht vollständig installiert oder entfernt. Es müssen noch 0 B von 325 kB an Archiven heruntergeladen werden. Nach dieser Operation werden 534 kB Plattenplatz zusätzlich benutzt. Möchten Sie fortfahren? [J/n] libpam0g:amd64 (1.3.1-5) wird eingerichtet ... Checking for services that may need to be restarted...awk: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory Checking init scripts... awk: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory dpkg: Fehler beim Bearbeiten des Paketes libpam0g:amd64 (--configure): Unterprozess installiertes post-installation-Skript gab den Fehlerwert 127 zurück Fehler traten auf beim Bearbeiten von: libpam0g:amd64 E: Sub-process /usr/bin/dpkg returned an error code (1) Delaying configuration won't help either: test@debian-test:~$ sudo apt full-upgrade -o APT::Immediate-Configure=0 Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen Fertig Probieren Sie »apt --fix-broken install«, um dies zu korrigieren. Die folgenden Pakete haben unerfüllte Abhängigkeiten: guile-2.2-libs : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert libedit2 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert libllvm7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert libncurses6 : Hängt ab von: libtinfo6 (= 6.1+20181013-2) ist aber nicht installiert libreadline7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt --fix-broken install« ohne Angabe eines Pakets (oder geben Sie eine Lösung an). The issue can be resolved by combining apt --fix-broken install with configuration delay: test@debian-test:~$ sudo apt --fix-broken install -o
Bug#932747: apt-get: AppStream system cache updated, failing on APT::Update::Post-Invoke-Success
Package: apt Version: 1.4.9 Severity: normal Tags: patch Dear Maintainer, on running apt-get update, sometimes the AppStream subprocess returns an error: The AppStream system cache was updated, but some errors were detected, which might lead to missing metadata. Refer to the verbose log for more information. Paketlisten werden gelesen... Fertig E: Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null; fi' E: Sub-process returned an error code I've seen this error being persistent on some machines, while others were thrown off repeatedly. A popular suggestion on the internet is to comment out the test statement and proceed without a refreshed appstream cache, which seems to work, so I suggest this being rolled out at least to Debian Stretch. FYI: Writing this from a freshly installed Debian Stretch, which now undergoes another dist-upgrade test for me to report the bugs I've seen on other machines and am able to reproduce here. -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-9-amd64$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::Periodic ""; APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; APT::Update ""; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null; fi"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "xz";
Bug#752272: Last certificate not self-signed
Am Sonntag, den 22.06.2014, 19:54 +0200 schrieb Andreas Metzler: * certtool --verify --load-ca-certificate cacert.pem --infile \ BTW: The --verify parameter doesn't exist in the stable package. It was introduced afterwards. But cat-ing them into one testfile and verify the chain then works, you're right. BR Jo signature.asc Description: This is a digitally signed message part
Bug#752272: Last certificate not self-signed
Am Sonntag, den 22.06.2014, 08:22 +0200 schrieb Andreas Metzler: On 2014-06-22 Jo Drexl jo.dr...@poly-tick.de wrote: After installing the stable package and rerunning 'certtool -e --load-ca-certificate cacert.pem --infile servercert.pem', the outcome was: [...] It seems the self-sign for snakeoil CAs is broken. Good luck, I don't think I'm of much use here, still playing around and trying to find out what I'm doing here ;) Hell, You are trying to use -e but you are passing a single certificate instead of a certificate chain. | -e, --verify-chain | Verify a PEM encoded certificate chain. | | The last certificate in the chain must be a self signed one. If you used --verify instead the command would succeed. cu Andreas Sure I do only give him one ca-certificate - because it's the next and last one in the chain and is self-signed (certtool --generate-self-signed --load-privkey cakey.pem --template ca.info --outfile cacert.pem). I did follow the howto step by step. To clarify: cakey.pem is created (RSA 2432 bits), self signed with ca.info as template and thus yields cacert.pem as the certificate authority's public certificate to sign and verify all other keys with. serverkey.pem is created afterwards and signed with cacert.pem, cakey.pem and server.info as template, yielding servercert.pem. At this step the certificate chain should be a piece of cake (if I didn't get something totally wrong, which I doubt): servercert.pem --[verified against]-- cacert.pem [CA, self-signed] [CHAIN END] servercert.pem is verified by cacert.pem, which is self-signed and a trusted certificate authority. Nothing above it. So either the cacert.pem is not self-signed and therefore not trusted (which would be awkward and a bug all by itself, which I'd gladly file too), or - as the message indicates - servercert.pem can't be verified by cacert.pem, which either indicates a failure within the verification routine or within the signature routine. And even if this parameter doesn't work with my setup, libvirt should accept the keys. Well, it doesn't, telling me my own client certificate (which I generated the same way as the servercert.pem, with own key and own template) can't be verified by the certificate authority's cert. Of course I could have fucked up stuff, but I don't think so. I'm neither stupid nor did I just do this once. I tried it multiple times (with either rsa or ecc keys) on the server, and once (after being sure it's not me) verified the issue with my notebook. I've redone this chain at least 6 times, the last two by EXACTLY following the above mentioned tutorial (I didn't even change the proposed lines in the templates) on two different machines with both Debian Wheezy and the backports-package installed. With the stable package it works now again, and I changed quite a lot within the templates. All summed up: It worked with the stable package for the VM setup I'm working on, it didn't work multiple times with the testing-package and now it works again with the stable package. It's the package. Quod erat demonstrandum. BR Jo signature.asc Description: This is a digitally signed message part
Bug#752272: Last certificate not self-signed
Hi, OK, I'm not really understanding why this fails (since I give the CA-cert as well as the certificate to verify in both cases), but either way it doesn't matter. My point, all certificates based on a self-signed CA-certificate cease working with libvirt with the testing package still is valid, and I'd consider it a bug, whether I'd used the wrong command to try to give you guys clues or not. BR Jo Am Sonntag, den 22.06.2014, 19:54 +0200 schrieb Andreas Metzler: On 2014-06-22 Jo Drexl jo.dr...@poly-tick.de wrote: Am Sonntag, den 22.06.2014, 08:22 +0200 schrieb Andreas Metzler: On 2014-06-22 Jo Drexl jo.dr...@poly-tick.de wrote: After installing the stable package and rerunning 'certtool -e --load-ca-certificate cacert.pem --infile servercert.pem', the outcome was: [...] It seems the self-sign for snakeoil CAs is broken. Good luck, I don't think I'm of much use here, still playing around and trying to find out what I'm doing here ;) You are trying to use -e but you are passing a single certificate instead of a certificate chain. | -e, --verify-chain | Verify a PEM encoded certificate chain. | | The last certificate in the chain must be a self signed one. If you used --verify instead the command would succeed. Sure I do only give him one ca-certificate - because it's the next and last one in the chain and is self-signed (certtool --generate-self-signed --load-privkey cakey.pem --template ca.info --outfile cacert.pem). I did follow the howto step by step. Hello, I am not sure you are understanding me correctly. -e needs a chain as infile. You are passing a single non-self-signed certificate. i.e. while either of these succeed * certtool --verify --load-ca-certificate cacert.pem --infile \ servercert.pem * cat servercert.pem cacert.pem chain.pem \ certtool --verify-chain --infile chain.pem this one always fails: * certtool --verify-chain file-containing-only-a-single-non-self-signed-cert cu Andreas signature.asc Description: This is a digitally signed message part
Bug#752272: gnutls-bin: Self-signed ca can't create trusted client certs
Package: gnutls-bin Version: 3.2.15-1~bpo70+1 Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? Wishing for a stable and secure remote qemu/kvm-VM, managed by virt-manager and libvirt * What exactly did you do (or not do) that was effective (or ineffective)? Following this guide (http://libvirt.org/remote.html#Remote_certificates) with the wheezy standard gnutls-bin package, worked fine. Redid everything with the backports-package for ecc-dsa support (new CA) and ssl for webserver. Every certificate came out not trusted by certtool -e; this broke every tls connection to the server. Redid everything with the backports-package on my notebook (where I now write from), outcome was identical. No trusted certificate structure can be obtained. So it's definitively the package. Will downgrade again, hope that solves the problem for now. Will keep you posted. * What was the outcome of this action? Either the certificate generating algorithm broke during the update, or the verification routine prints out false-negatives. * What outcome did you expect instead? Working certificates ;) *** End of the template - remove these lines *** -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnutls-bin depends on: ii libc62.13-38+deb7u1 ii libgmp10 2:5.0.5+dfsg-2 ii libgnutls28 3.2.15-1~bpo70+1 ii libhogweed2 2.7.1-1~bpo70+1 ii libidn11 1.25-2 ii libnettle4 2.7.1-1~bpo70+1 ii libp11-kit0 0.20.2-1~bpo70+1 ii libtasn1-6 3.6-1~bpo70+1 ii zlib1g 1:1.2.7.dfsg-13 gnutls-bin recommends no packages. gnutls-bin suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752272: Last certificate not self-signed
After installing the stable package and rerunning 'certtool -e --load-ca-certificate cacert.pem --infile servercert.pem', the outcome was: Certificate[0]: CN=testserver,O=Server.inc Issued by: CN=testserver,O=Server.inc certtool: the last certificate is not self signed With the backports package the same command issued: Loaded 1 certificates, 1 CAs and 0 CRLs Subject: CN=testserver,O=Server.inc Issuer: CN=TestCA Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. Subject: CN=testserver,O=Server.inc Issuer: CN=TestCA Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. Chain verification output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. It seems the self-sign for snakeoil CAs is broken. Good luck, I don't think I'm of much use here, still playing around and trying to find out what I'm doing here ;) Jo signature.asc Description: This is a digitally signed message part
