Il giorno gio 9 set 2021 alle ore 23:14 Davide Prina <davide.pr...@gmail.com> ha scritto:
> > ma non hai guardato cosa c'era che occupava CPU o RAM? > ad esempio con htop > Ciao Davide e a tutta la lista con htop non ho notato particolari processi che occupavano la ram/cpu. la versione di libglib è la stessa in testing e unstable, per questo per cercare di risolvere ho installato stable. - bullseye (stable) <https://packages.debian.org/bullseye/libglib2.0-0> (libs): libreria GLib di routine in C 2.66.8-1: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x - bookworm (testing) <https://packages.debian.org/bookworm/libglib2.0-0> (libs): libreria GLib di routine in C 2.68.4-1: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x - sid (unstable) <https://packages.debian.org/sid/libglib2.0-0> (libs): libreria GLib di routine in C 2.68.4-1: amd64 arm64 armel armhf hppa i386 ia64 m68k mips64el mipsel ppc64 ppc64el riscv64 s390x sh4 sparc64 x32 > qui sembra che ci siano dei breakpoint[¹] > in pratica sembra che era in esecuzione qualcosa in debug con dei > breakpoint impostati... e vedendo dai messaggi sembra che fosse sulle > libreria libglib, per questo c'erano dei rallentamenti. > Resta da capire come è stato possibile... > > da che fonti prendi i repository? > Usi https? > dal mio etc/apt/source.list deb http://http.debian.net/debian/ testing main contrib non-free deb http://deb.debian.org/debian-security testing-security contrib non-free main queste le uniche 2 righe per debian. saluti Gianluca
