Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Helmut Grohne]

On Thu, Feb 29, 2024 at 06:53:56AM +0100, Paul Gevers wrote:
> Well, officially downgrading isn't supported (although it typically works)
> *and* losing files is one of the problems of our merged-/usr solution (see
> [1]). I *suspect* this might be the cause. We're working hard (well, helmut
> is) to protect us and our users from loosing files on upgrades. We don't
> protect against downgrades.

As much as we like blaming all lost files on the /usr-move, this is not
one them. If you are downgrading from to a package that formerly has
been replaced, you always have lost files and you always had to
reinstall the package.

While t64 has quite some interactions with the /usr-move, I am closely
monitoring the situation have have been filing multiple bugs per day
recently about the relevant peculiarities. I don't think any of the
fallout we see here is reasonably attributable to /usr-move. The most
recent practical issues I've seen was related to image building tools
such as live-build and grml. When it comes to lost files, we're not
addressing them based on user reports (as there are practically none),
but on rigid analysis preventing users from experiencing them in the
first place.

Helmut

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Leandro Cunha]

Hi,

On Thu, Feb 29, 2024 at 9:32 AM Simon McVittie  wrote:
>
> On Thu, 29 Feb 2024 at 08:40:28 -0300, Leandro Cunha wrote:
> > Jeremy uploaded glib 2.0 to experimental which fixes such problems
>
> libglib2.0-0t64 in experimental does not contain any changes that would
> intentionally fix this.
>
> Upgrading to the experimental libglib2.0-0t64 probably fixes this as a
> side-effect, but if it does, then reinstalling the unstable libglib2.0-0t64
> would have the same effect as upgrading to experimental.
>
> smcv

The version with glib2.0 that is present in the experimental really
has nothing to solve this intentionally, and I saw what you mentioned
after sending this email and thank you for your response Simon, this
information was very important.

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Christoph Anton Mitterer]

On Thu, 2024-02-29 at 06:53 +0100, Paul Gevers wrote:
> Well, officially downgrading isn't supported (although it typically 
> works) *and* losing files is one of the problems of our merged-/usr 
> solution (see [1]). I *suspect* this might be the cause. We're
> working 
> hard (well, helmut is) to protect us and our users from loosing files
> on 
> upgrades. We don't protect against downgrades.
> 
> Obviously there might be issues, but you are running unstable
> *during* a 
> transition. You have to expect some troubles. Thanks for the 
> information, let's see if this is a real issue or not.

Well I didn't mean to complain :-)

As you said, usually downgrades (well rather: purge + install the old
package, here) work,... it's just this time, that it didn't because of
what Simon explained in #1065022 and it took me quite a while to
realise that re-installing solved the issue.

That plus the vanished lib files and that probably more people might be
affected by the issue, made me think that it wouldn't harm to CC d-d :)

Cheers,
Chris.

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Christoph Anton Mitterer]

On Wed, 2024-02-28 at 21:57 -0800, Steve Langasek wrote:
> Furthermore, this is a downgrade from a replacing package to a
> replaced
> package. Unless you also --reinstall the package at the end, missing
> files
> are quite to be expected.

Shouldn't that case be something that DPKG could detect and either warn
or automatically re-install... or do it in the right order (first
purge, that installed) and thus prevent the replaced files from being
deleted?

Thanks,
Chris.

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Simon McVittie]

On Thu, 29 Feb 2024 at 08:40:28 -0300, Leandro Cunha wrote:
> Jeremy uploaded glib 2.0 to experimental which fixes such problems

libglib2.0-0t64 in experimental does not contain any changes that would
intentionally fix this.

Upgrading to the experimental libglib2.0-0t64 probably fixes this as a
side-effect, but if it does, then reinstalling the unstable libglib2.0-0t64
would have the same effect as upgrading to experimental.

smcv

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Leandro Cunha]

Hi

On Thu, Feb 29, 2024 at 12:51 AM Christoph Anton Mitterer
 wrote:
>
> Package: libglib2.0-0t64
> Version: 2.78.4-2
> Severity: critical
> Justification: breaks unrelated software
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> Hey.
>
>
> CCing d-d since there seems some further deeper problem with the t64
> transition (namely lib files getting lost, when "downgrading" i.e.
> reverting).
>
>
> Earlier tonight I've upgraded this day’s packages which included
> numerous that made the t64 transition (see the attached aptitude log
> for the whole process, first the upgrade, and then "bi-secting" to
> find the culprit).
>
> Immediately afterwards, starting GUI programs from the still running
> desktop environment caused failures like:
> $ evince
>
> (evince:17537): GLib-GIO-CRITICAL **: 04:18:22.610: 
> g_settings_schema_source_lookup: assertion 'source != NULL' failed
>
> (evince:17537): GLib-GIO-CRITICAL **: 04:18:22.610: 
> g_settings_schema_source_lookup: assertion 'source != NULL' failed
>
> (evince:17537): GLib-GIO-ERROR **: 04:18:22.658: No GSettings schemas are 
> installed on the system
> Trace/breakpoint trap
> $ gedit
>
> (gedit:17585): GLib-GIO-ERROR **: 04:18:35.012: No GSettings schemas are 
> installed on the system
> Trace/breakpoint trap
> $
>
> I suspected a reboot might be needed but after that even the display
> manager didn't start anymore.
> I saw errors like:
> Feb 29 02:51:14 heisenberg kernel: traps: at-spi-bus-laun[17935] trap int3 
> ip:7fdceec49587 sp:7ffd0acdade0 error:0 in 
> libglib-2.0.so.0.7800.4[7fdceec05000+99000]
> Feb 29 02:51:52 heisenberg kernel: traps: at-spi-bus-laun[17941] trap int3 
> ip:7f52e53ee587 sp:7ffcc69b0fc0 error:0 in 
> libglib-2.0.so.0.7800.4[7f52e53aa000+99000]
>
>
> My first guess was glib, so I downgraded that (everything from the source
> package), but that didn't help.
>
> As you can see from the aptitude log, I then moved on downgrade further
> of the previously upgraded packages, several times I've rebooted in-
> between (e.g. after downgrading things like *pam* and *systemd*).
>
> Along the way I saw the most weirdest effects:
> - logind was apprently in some bogus state, which I think might
>   have been the reason, why X/the display manager remained black/hung for
>   several minutes:
>   Feb 29 03:37:21 heisenberg lightdm[139886]: Failed to get list of logind 
> seats: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate 
> service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
>
> - At some point, when installing packages via aptitude
>   # aptitude
>   
>   Performing actions...
>   
>
>   And it also hung at the end shortly after finishing the
>   upgrade/downgrade.
>
> - When downgrading packages that had a t64 transition, sometimes
>   the lib file was gone.
>   I.e. I removed the *t64 package and re-installed the old one
>   and then the .so file for libapt-pkg6.0 and libpam0g was missing.
>   How can that happen?
>
>
> Eventually I downgraded the gcr/gck stuff, and then it worked again.
>
> From that I went forward and upgrade all the various packages again, to
> see where the problem actuall is.
>
> Turns out, it's probably actually libglib.
>
> When I install the first time libglib2.0-0t64 (and purge libglib2.0-0),
> things start to break apart.
> When I re-install libglib2.0-0t64, things work again (it seems regardless
> of the gcr/gck stuff).
>
>
> Long story short:
> @glib maintainers:
> - there's something wrong with the transition (unless even that need for
>   the re-install is already a sign for some deeper issues)
>
> @d-d:
> - How can it happen that purge *t64 packages and at the same time install
>   the previous package, and then the so file is missing?
>   I mean it's clear that they use the same name, but shouldn't DPKG handle
>   the cleanly?
>
> Thanks,
> Chris
>
> PS: I'll attach the aptitude log only to the bug and not to d-d, in
> order not to spam so many people with it.
> It's probably anyway uselesss, but might help to find out why
> downgrading gck/gcr stuff helped first, without re-installing the
> glib package.
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
> 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
> Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libglib2.0-0t64 depends on:
> ii  libc6 2.37-15
> ii  libffi8   3.4.6-1
> ii  libmount1 2.39.3-6
> ii  libpcre2-8-0  10.42-4+b1
> ii  libselinux1   3.5-2
> ii  zlib1g1:1.3.dfsg-3+b1
>
> Versions of packages libglib2.0-0t64 recommends:
> ii  libglib2.0-data   2.78.4-2
> ii  shared-mime-info  2.4-1
> ii  xdg-user-dirs 0.18-1
>
> Versions of packages 

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Steve Langasek]

On Thu, Feb 29, 2024 at 06:53:56AM +0100, Paul Gevers wrote:
> On 29-02-2024 4:47 a.m., Christoph Anton Mitterer wrote:
> > @d-d:
> > - How can it happen that purge *t64 packages and at the same time install
> >the previous package, and then the so file is missing?
> >I mean it's clear that they use the same name, but shouldn't DPKG handle
> >the cleanly?

> Well, officially downgrading isn't supported (although it typically works)
> *and* losing files is one of the problems of our merged-/usr solution (see
> [1]). I *suspect* this might be the cause. We're working hard (well, helmut
> is) to protect us and our users from loosing files on upgrades. We don't
> protect against downgrades.

> Obviously there might be issues, but you are running unstable *during* a
> transition. You have to expect some troubles. Thanks for the information,
> let's see if this is a real issue or not.

Furthermore, this is a downgrade from a replacing package to a replaced
package. Unless you also --reinstall the package at the end, missing files
are quite to be expected.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Paul Gevers]

Hi,

On 29-02-2024 4:47 a.m., Christoph Anton Mitterer wrote:

@d-d:
- How can it happen that purge *t64 packages and at the same time install
   the previous package, and then the so file is missing?
   I mean it's clear that they use the same name, but shouldn't DPKG handle
   the cleanly?


Well, officially downgrading isn't supported (although it typically 
works) *and* losing files is one of the problems of our merged-/usr 
solution (see [1]). I *suspect* this might be the cause. We're working 
hard (well, helmut is) to protect us and our users from loosing files on 
upgrades. We don't protect against downgrades.


Obviously there might be issues, but you are running unstable *during* a 
transition. You have to expect some troubles. Thanks for the 
information, let's see if this is a real issue or not.


Paul

[1] https://subdivi.de/~helmut/dep17.html


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Ash Joubert]

Workaround for me was to reinstall gsettings-desktop-schemas:

# apt-get reinstall gsettings-desktop-schemas

I have circulated this rescue information to debian-devel and debian-users.

Cheers,
Ash.


 Forwarded Message 
Subject: Fwd: Fix for missing gsettings desktop schemas on unstable
Date: Thu, 29 Feb 2024 12:03:11 +1300
From: Ash Joubert 
To: debian-de...@lists.debian.org

I know the time_t transition is in progress but there could have been a 
nicer experience for users on unstable:


Feb 29 10:31:30 ripley systemd[914]: Starting at-spi-dbus-bus.service - 
Accessibility services bus...
Feb 29 10:31:30 ripley at-spi-bus-laun[984]: Cannot get the default 
GSettingsSchemaSource - is the gsettings-desktop-schemas package installed?
Feb 29 10:31:30 ripley systemd[914]: at-spi-dbus-bus.service: Main 
process exited, code=killed, status=5/TRAP
Feb 29 10:31:30 ripley systemd[914]: at-spi-dbus-bus.service: Failed 
with result 'signal'.
Feb 29 10:31:30 ripley kernel: traps: at-spi-bus-laun[984] trap int3 
ip:7f46709b4587 sp:7ffea37840b0 error:0 in 
libglib-2.0.so.0.7800.4[7f467097+99000]
Feb 29 10:31:30 ripley systemd[914]: Failed to start 
at-spi-dbus-bus.service - Accessibility services bus.


rednotebook just refused to start!

Cheers,
Ash.


 Forwarded Message 
Subject: Fix for missing gsettings desktop schemas on unstable
Date: Thu, 29 Feb 2024 11:56:48 +1300
From: Ash Joubert 
To: debian-u...@lists.debian.org

There is a huge transition underway on unstable to migrate to 64-bit 
time_t. After upgrading to the new libglib2.0-0t64, nothing could find 
gsettings desktop schemas, breaking applications like rednotebook and 
reportbug (lol), and after a reboot, stopping services like at-spi from 
starting, causing huge timeouts at system and application start.


A workaround that worked for me was to reinstall gsettings-desktop-schemas:

# apt-get reinstall gsettings-desktop-schemas
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not 
upgraded.

Need to get 660 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://ftp.debian.org/debian sid/main amd64 
gsettings-desktop-schemas all 46~beta-3 [660 kB]

Fetched 660 kB in 2s (431 kB/s)
(Reading database ... 35 files and directories currently installed.)
Preparing to unpack .../gsettings-desktop-schemas_46~beta-3_all.deb ...
Unpacking gsettings-desktop-schemas (46~beta-3) over (46~beta-3) ...
Setting up gsettings-desktop-schemas (46~beta-3) ...
Processing triggers for libglib2.0-0t64:amd64 (2.78.4-2) ...

Cheers,

--
Ash Joubert (they/them) 
Director / Game Developer
Transient Software Limited 
New Zealand

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Christoph Anton Mitterer]

Attached is the aptitude log.

Cheers,
Chris.
Aptitude 0.8.13: log report
Thu, Feb 29 2024 02:17:21 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 83 packages, and remove 21 packages.
471 kB of disk space will be used

[INSTALL, DEPENDENCIES] gcr4:amd64 4.2.0-3
[INSTALL, DEPENDENCIES] libapt-pkg6.0t64:amd64 2.7.12+nmu1
[INSTALL, DEPENDENCIES] libatk-bridge2.0-0t64:amd64 2.50.0-1.1
[INSTALL, DEPENDENCIES] libatk1.0-0t64:amd64 2.50.0-1.1
[INSTALL, DEPENDENCIES] libatspi2.0-0t64:amd64 2.50.0-1.1
[INSTALL, DEPENDENCIES] libcamel-1.2-64t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libcupsfilters1t64:amd64 1.28.17-3.1
[INSTALL, DEPENDENCIES] libdb5.3t64:amd64 5.3.28+dfsg2-4.1
[INSTALL, DEPENDENCIES] libdirectfb-1.7-7t64:amd64 1.7.7-11.1
[INSTALL, DEPENDENCIES] libebackend-1.2-11t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libebook-1.2-21t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libebook-contacts-1.2-4t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libecal-2.0-2t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libedata-book-1.2-27t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libedata-cal-2.0-2t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libedataserver-1.2-27t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libedataserverui-1.2-4t64:amd64 3.50.3-2
[INSTALL, DEPENDENCIES] libevdocument3-4t64:amd64 45.0-2
[INSTALL, DEPENDENCIES] libevview3-3t64:amd64 45.0-2
[INSTALL, DEPENDENCIES] libfontembed1t64:amd64 1.28.17-3.1
[INSTALL, DEPENDENCIES] libglib2.0-0t64:amd64 2.78.4-2
[INSTALL, DEPENDENCIES] libpam0t64:amd64 1.5.3-4
[HOLD] eject:amd64 2.38.1-5+b1
[REMOVE (PURGE)] libapt-pkg6.0:amd64 2.7.12
[REMOVE (PURGE)] libatk-bridge2.0-0:amd64 2.50.0-1+b1
[REMOVE (PURGE)] libatk1.0-0:amd64 2.50.0-1+b1
[REMOVE (PURGE)] libatspi2.0-0:amd64 2.50.0-1+b1
[REMOVE (PURGE)] libcamel-1.2-64:amd64 3.50.3-1
[REMOVE (PURGE)] libcupsfilters1:amd64 1.28.17-3+b1
[REMOVE (PURGE)] libdb5.3:amd64 5.3.28+dfsg2-4+b1
[REMOVE (PURGE)] libdirectfb-1.7-7:amd64 1.7.7-11+b1
[REMOVE (PURGE)] libebackend-1.2-11:amd64 3.50.3-1
[REMOVE (PURGE)] libebook-1.2-21:amd64 3.50.3-1
[REMOVE (PURGE)] libebook-contacts-1.2-4:amd64 3.50.3-1
[REMOVE (PURGE)] libecal-2.0-2:amd64 3.50.3-1
[REMOVE (PURGE)] libedata-book-1.2-27:amd64 3.50.3-1
[REMOVE (PURGE)] libedata-cal-2.0-2:amd64 3.50.3-1
[REMOVE (PURGE)] libedataserver-1.2-27:amd64 3.50.3-1
[REMOVE (PURGE)] libedataserverui-1.2-4:amd64 3.50.3-1
[REMOVE (PURGE)] libevdocument3-4:amd64 45.0-1+b1
[REMOVE (PURGE)] libevview3-3:amd64 45.0-1+b1
[REMOVE (PURGE)] libfontembed1:amd64 1.28.17-3+b1
[REMOVE (PURGE)] libglib2.0-0:amd64 2.78.4-1
[REMOVE (PURGE)] libpam0g:amd64 1.5.2-9.1+b1
[UPGRADE] apt:amd64 2.7.12 -> 2.7.12+nmu1
[UPGRADE] apt-doc:amd64 2.7.12 -> 2.7.12+nmu1
[UPGRADE] apt-utils:amd64 2.7.12 -> 2.7.12+nmu1
[UPGRADE] apt-xapian-index:amd64 0.54 -> 0.55
[UPGRADE] at-spi2-common:amd64 2.50.0-1 -> 2.50.0-1.1
[UPGRADE] at-spi2-core:amd64 2.50.0-1+b1 -> 2.50.0-1.1
[UPGRADE] btrfs-progs:amd64 6.6.3-1 -> 6.6.3-1.1
[UPGRADE] cups-browsed:amd64 1.28.17-3+b1 -> 1.28.17-3.1
[UPGRADE] cups-filters:amd64 1.28.17-3+b1 -> 1.28.17-3.1
[UPGRADE] cups-filters-core-drivers:amd64 1.28.17-3+b1 -> 1.28.17-3.1
[UPGRADE] evince:amd64 45.0-1+b1 -> 45.0-2
[UPGRADE] evince-common:amd64 45.0-1 -> 45.0-2
[UPGRADE] evolution-data-server:amd64 3.50.3-1 -> 3.50.3-2
[UPGRADE] evolution-data-server-common:amd64 3.50.3-1 -> 3.50.3-2
[UPGRADE] gcr:amd64 3.41.1-4 -> 3.41.2-1
[UPGRADE] gir1.2-atk-1.0:amd64 2.50.0-1+b1 -> 2.50.0-1.1
[UPGRADE] gir1.2-atspi-2.0:amd64 2.50.0-1+b1 -> 2.50.0-1.1
[UPGRADE] gir1.2-camel-1.2:amd64 3.50.3-1 -> 3.50.3-2
[UPGRADE] gir1.2-ecal-2.0:amd64 3.50.3-1 -> 3.50.3-2
[UPGRADE] gir1.2-edataserver-1.2:amd64 3.50.3-1 -> 3.50.3-2
[UPGRADE] gir1.2-pango-1.0:amd64 1.51.0+ds-4 -> 1.52.0+ds-1
[UPGRADE] libasound2-data:amd64 1.2.10-3 -> 1.2.10-3.1
[UPGRADE] libatk-adaptor:amd64 2.50.0-1+b1 -> 2.50.0-1.1
[UPGRADE] libaudit-common:amd64 1:3.1.2-2 -> 1:3.1.2-2.1
[UPGRADE] libaudit1:amd64 1:3.1.2-2 -> 1:3.1.2-2.1
[UPGRADE] libboost-filesystem1.83.0:amd64 1.83.0-2+b2 -> 1.83.0-2.1
[UPGRADE] libboost-iostreams1.83.0:amd64 1.83.0-2+b2 -> 1.83.0-2.1
[UPGRADE] libboost-locale1.83.0:amd64 1.83.0-2+b2 -> 1.83.0-2.1
[UPGRADE] libboost-program-options1.83.0:amd64 1.83.0-2+b2 -> 1.83.0-2.1
[UPGRADE] libboost-python1.83.0:amd64 1.83.0-2+b2 -> 1.83.0-2.1
[UPGRADE] libboost-thread1.83.0:amd64 1.83.0-2+b2 -> 1.83.0-2.1
[UPGRADE] libbsd0:amd64 0.12.0-1 -> 0.12.1-1
[UPGRADE] libdirectfb-extra:amd64 1.7.7-11+b1 -> 1.7.7-11.1
[UPGRADE] libgck-1-0:amd64 3.41.1-4 -> 3.41.2-1
[UPGRADE] libgck-2-2:amd64 4.2.0-2 -> 4.2.0-3
[UPGRADE] libgcr-4-4:amd64 4.2.0-2 -> 4.2.0-3
[UPGRADE] libgcr-base-3-1:amd64 3.41.1-4 -> 3.41.2-1
[UPGRADE] libgcr-ui-3-1:amd64 3.41.1-4 -> 3.41.2-1
[UPGRADE] libgegl-common:amd64 1:0.4.48-1 -> 1:0.4.48-2
[UPGRADE] libglib2.0-bin:amd64 2.78.4-1 -> 2.78.4-2
[UPGRADE] libglib2.0-data:amd64 2.78.4-1 -> 2.78.4-2
[UPGRADE] libnss-mymachines:amd64 

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Christoph Anton Mitterer]

Package: libglib2.0-0t64
Version: 2.78.4-2
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: debian-de...@lists.debian.org

Hey.


CCing d-d since there seems some further deeper problem with the t64
transition (namely lib files getting lost, when "downgrading" i.e.
reverting).


Earlier tonight I've upgraded this day’s packages which included
numerous that made the t64 transition (see the attached aptitude log
for the whole process, first the upgrade, and then "bi-secting" to
find the culprit).

Immediately afterwards, starting GUI programs from the still running
desktop environment caused failures like:
$ evince

(evince:17537): GLib-GIO-CRITICAL **: 04:18:22.610: 
g_settings_schema_source_lookup: assertion 'source != NULL' failed

(evince:17537): GLib-GIO-CRITICAL **: 04:18:22.610: 
g_settings_schema_source_lookup: assertion 'source != NULL' failed

(evince:17537): GLib-GIO-ERROR **: 04:18:22.658: No GSettings schemas are 
installed on the system
Trace/breakpoint trap
$ gedit

(gedit:17585): GLib-GIO-ERROR **: 04:18:35.012: No GSettings schemas are 
installed on the system
Trace/breakpoint trap
$

I suspected a reboot might be needed but after that even the display
manager didn't start anymore.
I saw errors like:
Feb 29 02:51:14 heisenberg kernel: traps: at-spi-bus-laun[17935] trap int3 
ip:7fdceec49587 sp:7ffd0acdade0 error:0 in 
libglib-2.0.so.0.7800.4[7fdceec05000+99000]
Feb 29 02:51:52 heisenberg kernel: traps: at-spi-bus-laun[17941] trap int3 
ip:7f52e53ee587 sp:7ffcc69b0fc0 error:0 in 
libglib-2.0.so.0.7800.4[7f52e53aa000+99000]


My first guess was glib, so I downgraded that (everything from the source
package), but that didn't help.

As you can see from the aptitude log, I then moved on downgrade further
of the previously upgraded packages, several times I've rebooted in-
between (e.g. after downgrading things like *pam* and *systemd*).

Along the way I saw the most weirdest effects:
- logind was apprently in some bogus state, which I think might
  have been the reason, why X/the display manager remained black/hung for
  several minutes:
  Feb 29 03:37:21 heisenberg lightdm[139886]: Failed to get list of logind 
seats: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate 
service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)

- At some point, when installing packages via aptitude
  # aptitude
  
  Performing actions...
  
  
  And it also hung at the end shortly after finishing the
  upgrade/downgrade.

- When downgrading packages that had a t64 transition, sometimes
  the lib file was gone.
  I.e. I removed the *t64 package and re-installed the old one
  and then the .so file for libapt-pkg6.0 and libpam0g was missing.
  How can that happen?


Eventually I downgraded the gcr/gck stuff, and then it worked again.

From that I went forward and upgrade all the various packages again, to
see where the problem actuall is.

Turns out, it's probably actually libglib.

When I install the first time libglib2.0-0t64 (and purge libglib2.0-0),
things start to break apart.
When I re-install libglib2.0-0t64, things work again (it seems regardless
of the gcr/gck stuff).


Long story short:
@glib maintainers:
- there's something wrong with the transition (unless even that need for
  the re-install is already a sign for some deeper issues)

@d-d:
- How can it happen that purge *t64 packages and at the same time install
  the previous package, and then the so file is missing?
  I mean it's clear that they use the same name, but shouldn't DPKG handle
  the cleanly?

Thanks,
Chris

PS: I'll attach the aptitude log only to the bug and not to d-d, in
order not to spam so many people with it.
It's probably anyway uselesss, but might help to find out why
downgrading gck/gcr stuff helped first, without re-installing the
glib package.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libglib2.0-0t64 depends on:
ii  libc6 2.37-15
ii  libffi8   3.4.6-1
ii  libmount1 2.39.3-6
ii  libpcre2-8-0  10.42-4+b1
ii  libselinux1   3.5-2
ii  zlib1g1:1.3.dfsg-3+b1

Versions of packages libglib2.0-0t64 recommends:
ii  libglib2.0-data   2.78.4-2
ii  shared-mime-info  2.4-1
ii  xdg-user-dirs 0.18-1

Versions of packages libglib2.0-0t64 suggests:
pn  low-memory-monitor  

-- no debconf information