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
  <here I started the upgrade or downgrade>
  Performing actions...
  <here it hang for several minutes... no real CPU/disk load>

  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.

Attached is the aptitude log.

Cheers,
Chris.

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.


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[7f4670970000+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.
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 ... 300005 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,

Hi,

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

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.

Ash Joubert wrote:

Yes, the workaround for this is to reinstall any package that carries
GSettings schemas. gsettings-desktop-schemas is a common one, but actually
any package that has files in /usr/share/glib-2.0/schemas/ should be
equally good here.

There is a related failure mode with a less dramatic impact that
can be worked around by reinstalling either dconf-gsettings-backend,
glib-networking or gvfs after the upgrade.

Please also check the apt logs, particularly /var/log/apt/term.log,
which will tell us what actually happened (not just what aptitude
planned to do, which is what the aptitude logs show). What I'm mainly
interested in in is the order of these events relative to each other,
during the upgrade transaction that added libglib2.0-0t64:

- De-configuring libglib2.0-0 (it's OK if this is not present)
- Preparing to unpack libglib2.0-0t64
- Processing triggers for libglib2.0-0t64
- Purging configuration files for libglib2.0-0
- Removing libglib2.0-0
- Setting up libglib2.0-0t64
- Unpacking libglib2.0-0t64

Ash, the same information from you would be useful.
...

I think what has happened here is that because you are *purging* (and not
just removing) the old libglib2.0-0, this code in the postrm is triggered:

if [ "$1" = purge ] && [ -d /usr/share/glib-2.0/schemas ] && [ "$DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT" = 1 ]; then
    # This is the last multiarch variant to be removed, so drop the
    # architecture-independent compiled schemas
    rm -f /usr/share/glib-2.0/schemas/gschemas.compiled
    rmdir -p --ignore-fail-on-non-empty /usr/share/glib-2.0/schemas
fi

... and then you have no GSettings schemas available any more, so anything
that uses GSettings will crash.

And then when you reverted the transition, you did the same thing in
reverse:
...

which would have the same problem.

Removing libglib2.0-0 will also remove the GIO modules cache, even though
it is (now) still being used by libglib2.0-0t64. That has a less dramatic
impact, but will break glib-networking and gvfs, which would explain some
bug reports we've seen recently where certificate validation in GLib apps
stops working with a message about there being no trusted CAs. Unlike
the code path for schemas, this *does* get triggered when libglib2.0-0
is removed-but-not-purged.

This is code that has existed for over a decade, written with the
assumption that the only time GLib would break ABI is if there was an
upstream transition to libglib3.0 with completely parallel-installable
paths. In the absence of a time machine, we can't go back and change it.

Unfortunately at the moment I'm not seeing a way to fix this without
a time machine: we can't go back and change the postrm of libglib2.0-0
in bookworm to have different behaviour. The only reliable solution I
can immediately see would be for libglib2.0-0t64 to delete the postrm
of libglib2.0-0 during its preinst (which is a Policy violation, and
relies on the filesystem layout of dpkg internals). Steve, are you aware
of any better options?

For future versions of glib2.0, I can see a few ways this could be made
more robust against in-place ABI transitions - but we can't retroactively
make any of those changes in bookworm, because bookworm was already
released, so I think we should defer discussion of those until after
the immediate problem has been solved.

    smcv

To clarify that, I mean "reinstall any single package in this category"
and not "reinstall every package in this category". Because of the way
this is set up, one is enough.

Similarly, reinstalling any one of these packages per architecture
should be enough, you don't have to reinstall all of them.

    smcv

Hi

Jeremy uploaded glib 2.0 to experimental which fixes such problems,
here it broke the entire GNOME interface after installation and
Chromium which is in unstable installs this package causing such
problems. I installed 2.79.3-2 from experimental which apparently
resolved the issues by even having GDM back and all GNOME interface.

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

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.

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.

Hey Simon.

So the advise for "end users" is to simply re-install one package of
both groups and everything should be cleaned up again?

See the attached files.
term.log.{1,2} are NOT rotated files.

.1 is the first try, where I've upgraded all packages at once in the
beginning and then did lots of subsequent "downgrades", trying to find
out where the problem is.

After that I restored the whole root-fs from a btrfs snapshot that I
had made by coincidence just before.

.2 is the whole upgrades but in several steps, with an number of re-
installs (from the *t64 packages, just to be sure that all files are
there), eventually also re-installing libglib.

Guess that should all be in the APT term logs? If not, don't hesitate
to poke me with a stick.

I see. But isn't one more or less supposed to purge?

I mean if there would e.g. ever be a libglib3, and libglib2.0-0 had
e.g. some conffiles (or manually created) files that where still neeed
in libglib3 but some that are obsolete... one would eventually need to
purge in order to clean those up.

Would that (cache) be re-created by reinstalling?

If not, what would be the end-user steps to clean up from all this? :)



Thanks,
Chris.

The advice for "end users" would be don't run unstable or experimental,
and wait for maintainers to fix release-critical bugs like this one as
they are detected. Unfortunately I have several other time-sensitive
responsibilities and cannot drop everything to investigate how to solve
this immediately. I'm sorry if this means I am not living up to your
expectations.

For advanced users who want to run unstable, yes, the advice would
be to reinstall one package from each of those groups. Or now that I
think about it, reinstalling libglib2.0-0t64 would probably also work,
and is simpler.

I'm not saying that purging old packages is necessarily wrong, I'm only
saying that it is the step that triggered this bug. In an ideal world,
all packages would be perfect and there would be no code path that would
cause problems, but sadly we do not live in that world.

Installing and then reinstalling libglib2.0-0t64 should recreate this
cache, yes.

If you have multiarch versions of libglib2.0-0t64 installed
(typically libglib2.0-0t64:amd64 and libglib2.0-0t64:i386) then you
will need to reinstall each of them.

    smcv

Well "end user" is a broad range :-)
I guess quite some people do run unstable on their regular systems like
I do, which gives them kind of a rolling release, while at the same
time being 99,xx% super stable (at least in my experience)... and on
the other hand helps Debian at a whole, as much more testing is done.

Suggesting such people to use the testing suite is only a partial
replacement, as that generally lacks some packages (like firefox).

Uhm? No I'm absolutely fine... an do no in any way think that you (or
anyone else) should have "performed any better" - nor would I have any
such demands/expectations. :-)

I see. Well I guess that's then already enough of instructions for any
end user (in the sense of "is not a glib expert" user).


Thanks,
Chris.

Hi,

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.

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

Hello,

Bug #1065022 in glib2.0 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/gnome-team/glib/-/commit/451ed4fd133f4cac0b1530cbba2a63a18c6543e1
------------------------------------------------------------------------
d/libglib2.0-0t64.preinst: Remove libglib2.0-0 postrm to avoid file loss

During the migration from libglib2.0-0 to libglib2.0-0t64, the package
that is responsible for "owning" /usr/lib/*/gio/modules/giomodule.cache
and /usr/share/glib-2.0/schemas/gschemas.compiled changed from
libglib2.0-0 to libglib2.0-0t64. Because dpkg does not have an equivalent
of RPM's %ghost files, the ownership of these files is managed by social
convention rather than by the package management system.

Unfortunately, libglib2.0-0's postrm as shipped in Debian releases from
2010 to the present is not aware of the possibility that another binary
package might need to take over responsibility for those files, and so
will remove both files during purge (and giomodules.cache also during
remove) in accordance with the requirement that installing and then
removing and purging a package must not leave unowned files behind.
This causes most applications that depend on GSettings schemas to crash
with an assertion failure, until the next time the glib-compile-schemas
trigger happens to be run; it will also cause functionality loss for
applications that depend on GIO modules.

To disarm the problematic maintainer script, delete it during the new
package's preinst. This is (probably) a Policy violation, but seems like
the least-bad exit strategy from the unacceptable situation we have
found ourselves in.

A subsequent commit will improve the postrm so that if we find that we
need to migrate from libglib2.0-0t64 to libglib2.0-0xyz or libglib-2.0-0
at some point in the future, similar efforts will not be needed.

Closes: #1065022
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1065022

We believe that the bug you reported is fixed in the latest version of
glib2.0, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1065022@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated glib2.0 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 02 Mar 2024 23:07:12 +0000
Source: glib2.0
Architecture: source
Version: 2.79.3-3
Distribution: experimental
Urgency: medium
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Closes: 1065022
Changes:
 glib2.0 (2.79.3-3) experimental; urgency=medium
 .
   * Merge pending packaging from unstable
     - Mention #1065280 in 2.79.3-1 changelog entry
   * d/libglib2.0-0t64.preinst: Remove libglib2.0-0 postrm to avoid file loss
     during the time64 transition (Closes: #1065022)
   * d/tests/manual/1065022.sh: Add a manual reproducer for #1065022
   * d/libglib2.0-0t64.postrm: Only clean up giomodule.cache during purge.
     This matches the behaviour that we have had for gschemas.compiled
     since 2012, with similar reasoning: if we remove this file during
     remove, then during upgrades there is a window between old-postrm
     and new-postinst during which giomodule.cache is missing.
   * d/libglib2.0-0t64.postrm: Avoid recurrence of #1065022 in the future.
     If at some point in the future we have another transition as extensive
     as time64, then libglib2.0-0t64 could conceivably be replaced by
     some other package, for example libglib2.0-0xyz. If that happens,
     we need to avoid deletion of gschemas.compiled and giomodule.cache,
     otherwise we will have another bug similar to #1065022.
   * d/tests/1065022-futureproofing: Add a test for recurrence of #1065022.
     This test-case depends on several implementation details which
     might cause it to regress for reasons that are not genuinely
     release-critical, so it is marked as flaky.
Checksums-Sha1:
 17f2acfcde8a3543c35ce6d15016c4e1b6736189 4507 glib2.0_2.79.3-3.dsc
 ba077097f00cad603e8f9f4c3ab0d39b600b83ba 129052 glib2.0_2.79.3-3.debian.tar.xz
 32de4fbbc445d4b0edfbe069de227b9e2c2017cb 7593 glib2.0_2.79.3-3_source.buildinfo
Checksums-Sha256:
 f19a118c5808231a5c36a8bdea82a99f52db9b49bcec124c1d4bc98519ca9faa 4507 glib2.0_2.79.3-3.dsc
 be37dffdd661326eeeb53d9011b818303138ab373b826d341a7a40ce29c67e37 129052 glib2.0_2.79.3-3.debian.tar.xz
 77a63d939b56b831ebb07393766fef755d636bb7f5998c193e958283cd41cb87 7593 glib2.0_2.79.3-3_source.buildinfo
Files:
 1b160670305eeed23cde7a7634e9402b 4507 libs optional glib2.0_2.79.3-3.dsc
 b468bde94524600e7a07e1222ead8242 129052 libs optional glib2.0_2.79.3-3.debian.tar.xz
 d7437f59ef2643765e3360526ed676bd 7593 libs optional glib2.0_2.79.3-3_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENuxaZEik9e95vv6Y4FrhR4+BTE8FAmXj00kACgkQ4FrhR4+B
TE9wQA/+IBqjGj8cr2sBzO64aNAm3n3oHxqYZPVw/IVjhqpTexx3TrOdaVcIncN4
Wge8v26cLj+ouh2Jf1nF6OJIAKM8RehuKRNt0tc8n1hrc29wnH9HGvfSL2+URrCP
6oC5rjjRQXMFGCRjcaCJFgkjRrn7EM49d2Tb72wx6MJcuJ38igCicC5H75n7jvT5
G86HzP6y9eKhkVQbvAruT6iHnHnXCibujHuk6HAWZnt9TUm909ke4Zy9nH4MNOEQ
8lS6CYfV776vBhbhyXfR0K6REHwdx7WWkQFdzAm/O+g8tPJq5Xfa0Exf2WlH2cd6
1Dl/UxBlB1Xr3bOH7ULxd7lREpZ90YCVu1saEyf2z3FpTGjZQJSI+x5LaxxKMT+m
+RAINntq4JSWMSozioNLk+nL+ZsfI/JkZRfvC0ec2mPWnZ9v8YHYPQT1xOgzAIbx
Sqo1yoQAPwwUEr/6HAq9bSBwVMnVsmsj/fMKs1CBsSd+M6ZwIAHTh32ijSxTR1LF
aPr4LGFgoIxDfHtOyPOznQ2F6a9IwfsXNCAOTSiaMniT3uzuc0sopflYSHQpfR94
cbbEuj5+bpsAGk5fw8CU6IEO/5USKISMcQwa0WOJE+gcmC+6qDgmbCnv2Yxan0KC
UOOrap4EoYiWeAWZLS54DmPtA7sb/iQCGkUHFXNjo/De9q2FcvY=
=jpJH
-----END PGP SIGNATURE-----

We believe that the bug you reported is fixed in the latest version of
glib2.0, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1065022@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated glib2.0 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 03 Mar 2024 13:30:12 +0000
Source: glib2.0
Architecture: source
Version: 2.78.4-3
Distribution: unstable
Urgency: medium
Maintainer: Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Closes: 1065022 1065280
Changes:
 glib2.0 (2.78.4-3) unstable; urgency=medium
 .
   * Build-depend on dpkg-dev (>= 1.22.5), to ensure that we are on the
     64-bit time_t side of the transition (Closes: #1065280).
     If this version gets backported, then the whole t64 package rename
     (including this change) will need to be reverted in the backport.
   * d/libglib2.0-0t64.preinst: Remove libglib2.0-0 postrm to avoid file loss
     (Closes: #1065022)
   * d/tests: Add a manual reproducer for #1065022
   * d/libglib2.0-0t64.post*: Stop generating from a template.
     dh_installdeb will substitute #DEB_HOST_MULTIARCH# for us since
     debhelper 12.2 (2019).
   * d/libglib2.0-0t64.postrm: Only clean up giomodule.cache during purge.
     This matches the behaviour that we have had for gschemas.compiled
     since 2012.
   * d/libglib2.0-0t64.postrm: Avoid recurrence of #1065022 in the future.
     If at some point in the future we have another transition as extensive
     as time64, then libglib2.0-0t64 could conceivably be replaced by some
     other package, for example libglib2.0-0xyz. If that happens,
     we need to avoid deletion of gschemas.compiled and giomodule.cache,
     otherwise we will have another bug similar to #1065022.
   * d/tests/1065022-futureproofing: Add a test for recurrence of #1065022.
     This test-case depends on several implementation details which
     might cause it to regress for reasons that are not genuinely
     release-critical, so it is marked as flaky.
   * d/libglib2.0-0t64.postinst: Remove workarounds that are no longer needed.
     As noted in their comments, now that Debian 12 and Ubuntu 22.04 were
     both released with these workarounds included, the workarounds can safely
     be removed from newer distro branches.
   * d/control: libglib2.0-dev Suggests gir1.2-glib-2.0-dev in preference
     to libgirepository1.0-dev, for multi-arch co-installability.
   * Fix filename of README.Debian for libglib2.0-0t64.
     This regressed during the t64 transition, presumably renamed with the
     help of a script that didn't take multiple extensions into account.
Checksums-Sha1:
 95ff673e0e875d5e6e19cd0937c491021d75835c 3765 glib2.0_2.78.4-3.dsc
 81121d5a8a8d5bc74ded000ab034a41caad1c1d3 123424 glib2.0_2.78.4-3.debian.tar.xz
 6869bb3c70ded6ee994ce23b1c398f9d2c9794fd 7494 glib2.0_2.78.4-3_source.buildinfo
Checksums-Sha256:
 6c6dd2ba30deefd46c8b5a28beb1f4fc41ab8b68690c5e161705d042bbf4f156 3765 glib2.0_2.78.4-3.dsc
 72361967d752796fec3a6f1d56298e250198b1d08fc446eb309d527df8e6ef00 123424 glib2.0_2.78.4-3.debian.tar.xz
 96c6883a196381948121e8fd3e6e8b2684b412d2d83154c323c6bc640d7bd060 7494 glib2.0_2.78.4-3_source.buildinfo
Files:
 acba48a04d14018102d1e3debc80faec 3765 libs optional glib2.0_2.78.4-3.dsc
 bde1d7669b3492f0759125b8a4e056ae 123424 libs optional glib2.0_2.78.4-3.debian.tar.xz
 5511421b20f7ebf540ddf8384a4f53df 7494 libs optional glib2.0_2.78.4-3_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENuxaZEik9e95vv6Y4FrhR4+BTE8FAmXkupYACgkQ4FrhR4+B
TE+XFQ/+PCDeLeppmd+Q1mx54MrMqqpgxjHcSrJc+V7hF88R0aJZpPiecwAGzijV
DQf+AX+iy8XJwbxE+0xgYQPpwvCZNzt+GYc14oNcxDgMx7TEpUW5JTwuN+QGp4L1
Tk0SveO8MZRI0HcOWC6JTsUfJ38Us7ocoznlxDk9EpLKJ48B/38iFYCo73xafewq
QLj5psdnXpzF+gl3TSXj1ny4xljWR4q67ljaM7jpV2Y//LGaleEyPwlpG6UheNa0
MD8+zJMaRFRGkQLsHhSSNATuJwaZfO/DX3QKzPjFayb8irb1kLhNzJJR+1dtuAWn
BIanJXmCTuCngbZ1fwfhjqv6J/ICZo75MBBsPvt+TmioCutgFDL8H4ynUdenHwMZ
VGQLfwYnCjAzizWFlkBmqorNOeg1s/SsPOAs/MCmcAhzW+4vhSxE6JNSS1saVHD0
3q1QjElMXNpCFZ9GgfnXk7crg4j4DfUq3v8oR/ZH5eInVKkWGOkgZtLk9FP8iCc/
56Cv8k7CYAr+EB8QsdNNGeB6LEvmjWC/luQl3eqtYyFraDHBIsBJUFf7JKjKNLF0
gWkfm6oQm+/bRkd5ENvdt1rwly6xANxNzNGCgK8WQkYRPoN3lyQq2xHsr4wuoDDL
fnLse73Tqn5oldFeTz8xaLhThCepdoKj6Y7Jmjr/pFRlnOSvq/4=
=vnqd
-----END PGP SIGNATURE-----