- Package:
- python3-debian
- Source:
- python3-debian
- Submitter:
- Christoph Berg
- Date:
- 2026-06-07 12:43:01 UTC
- Severity:
- normal
- Tags:
Hi,
I've just had autopkgtest die on unstable/ppc64el and forky/ppc64el.
I'm not sure which package changed here, but I think autopkgtest (or
python3-debian?) shouldn't die if a previously-supported architecture
is listed in a source package stanza.
tl;dr:
apt-cache showsrc postgresql-hll
postgresql-18-hll deb database optional arch=alpha,amd64,arm64,ia64,kfreebsd-amd64,loong64,mips64el,ppc64el,riscv64
-> autopkgtest dies:
File "/usr/lib/python3/dist-packages/debian/_arch_table.py", line 152, in _dpkg_arch_to_tuple
return self._arch2table[dpkg_arch]
~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'kfreebsd-amd64'
11:42:38 + apt-cache showsrc postgresql-hll
11:42:38 Package: postgresql-hll
11:42:38 Format: 3.0 (quilt)
11:42:38 Binary: postgresql-10-hll, postgresql-11-hll, postgresql-12-hll, postgresql-13-hll, postgresql-14-hll, postgresql-15-hll, postgresql-16-hll, postgresql-17-hll, postgresql-18-hll
11:42:38 Architecture: alpha amd64 arm64 ia64 kfreebsd-amd64 loong64 mips64el ppc64el riscv64
11:42:38 Version: 2.19-1.pgdg+1
11:42:38 Maintainer: Debian PostgreSQL Maintainers <team+postgresql@tracker.debian.org>
11:42:38 Uploaders: Christoph Berg <myon@debian.org>,
11:42:38 Homepage: https://github.com/citusdata/postgresql-hll
11:42:38 Standards-Version: 4.7.2
11:42:38 Vcs-Browser: https://salsa.debian.org/postgresql/postgresql-hll
11:42:38 Vcs-Git: https://salsa.debian.org/postgresql/postgresql-hll.git
11:42:38 Testsuite: autopkgtest
11:42:38 Testsuite-Triggers: postgresql-common-dev
11:42:38 Build-Depends: debhelper-compat (= 13), postgresql-all <!nocheck>, postgresql-server-dev-all
11:42:38 Package-List:
11:42:38 postgresql-10-hll deb database optional arch=alpha,amd64,arm64,ia64,kfreebsd-amd64,loong64,mips64el,ppc64el,riscv64
11:42:38 postgresql-11-hll deb database optional arch=alpha,amd64,arm64,ia64,kfreebsd-amd64,loong64,mips64el,ppc64el,riscv64
11:42:38 postgresql-12-hll deb database optional arch=alpha,amd64,arm64,ia64,kfreebsd-amd64,loong64,mips64el,ppc64el,riscv64
11:42:38 postgresql-13-hll deb database optional arch=alpha,amd64,arm64,ia64,kfreebsd-amd64,loong64,mips64el,ppc64el,riscv64
11:42:38 postgresql-14-hll deb database optional arch=alpha,amd64,arm64,ia64,kfreebsd-amd64,loong64,mips64el,ppc64el,riscv64
11:42:38 postgresql-15-hll deb database optional arch=alpha,amd64,arm64,ia64,kfreebsd-amd64,loong64,mips64el,ppc64el,riscv64
11:42:38 postgresql-16-hll deb database optional arch=alpha,amd64,arm64,ia64,kfreebsd-amd64,loong64,mips64el,ppc64el,riscv64
11:42:38 postgresql-17-hll deb database optional arch=alpha,amd64,arm64,ia64,kfreebsd-amd64,loong64,mips64el,ppc64el,riscv64
11:42:38 postgresql-18-hll deb database optional arch=alpha,amd64,arm64,ia64,kfreebsd-amd64,loong64,mips64el,ppc64el,riscv64
11:42:38 Priority: optional
11:42:38 Section: database
11:42:38 Directory: pool/main/p/postgresql-hll
11:42:38 Files:
11:42:38 eacf4b3847de3a185d6e2ae79dd59678 2475 postgresql-hll_2.19-1.pgdg+1.dsc
11:42:38 f6bc5624bab1c3b9c9f8c2f8aa2fcdf0 2756222 postgresql-hll_2.19.orig.tar.gz
11:42:38 a8a6204e4e4fd60682895fe481ef832b 3696 postgresql-hll_2.19-1.pgdg+1.debian.tar.xz
11:42:38 Checksums-Sha1:
11:42:38 dc682335d9d60ac57b5dd87ef908b3d6eb84ea7c 2475 postgresql-hll_2.19-1.pgdg+1.dsc
11:42:38 ce3ec8a76996cb02cf19fd3faf0f3e2843f00ad1 2756222 postgresql-hll_2.19.orig.tar.gz
11:42:38 15fe407beb4a100bd149c9a2c8f6cac15dcdb45e 3696 postgresql-hll_2.19-1.pgdg+1.debian.tar.xz
11:42:38 Checksums-Sha256:
11:42:38 2ace26c6382efe811abb7d005aa8b2779fdcb02e1d9e9ae394cc76c3da1e4a9d 2475 postgresql-hll_2.19-1.pgdg+1.dsc
11:42:38 d63d56522145f2d737e0d056c9cfdfe3e8b61008c12ca4c45bde7d9b942f9c46 2756222 postgresql-hll_2.19.orig.tar.gz
11:42:38 d6183d59ead33b69c2212e1633483b2511e9c835694db09455121208839059ee 3696 postgresql-hll_2.19-1.pgdg+1.debian.tar.xz
11:42:38
11:42:38 + autopkgtest --user buildd --timeout-copy=900 postgresql-hll -- null
11:42:38 autopkgtest [10:42:35]: starting date and time: 2026-01-08 10:42:35+0000
11:42:38 autopkgtest [10:42:35]: version 5.53
11:42:38 autopkgtest [10:42:35]: host postgresql-debian-12-p10-xxlarge; command line: /usr/bin/autopkgtest --user buildd --timeout-copy=900 postgresql-hll -- null
11:42:38 autopkgtest [10:42:35]: testbed dpkg architecture: ppc64el
11:42:38 autopkgtest [10:42:35]: testbed apt version: 3.1.13
11:42:38 autopkgtest [10:42:35]: @@@@@@@@@@@@@@@@@@@@ test bed setup
11:42:38 autopkgtest [10:42:35]: testbed release detected to be: sid
11:42:38 autopkgtest [10:42:36]: testbed running kernel: Linux 6.12.57+deb13-powerpc64le #1 SMP Debian 6.12.57-1 (2025-11-05)
11:42:38 autopkgtest [10:42:36]: @@@@@@@@@@@@@@@@@@@@ apt-source postgresql-hll
11:42:38 Get:1 https://apt.postgresql.org/pub/repos/apt sid-pgdg-testing/main postgresql-hll 2.19-1.pgdg+1 (dsc) [2,475 B]
11:42:38 Get:2 https://apt.postgresql.org/pub/repos/apt sid-pgdg-testing/main postgresql-hll 2.19-1.pgdg+1 (tar) [2,756 kB]
11:42:39 Get:3 https://apt.postgresql.org/pub/repos/apt sid-pgdg-testing/main postgresql-hll 2.19-1.pgdg+1 (diff) [3,696 B]
11:42:39 dpkg-source: warning: extracting unsigned source package (postgresql-hll_2.19-1.pgdg+1.dsc)
autopkgtest [10:42:38]: testing package postgresql-hll version 2.19-1.pgdg+1
autopkgtest [10:42:38]: ERROR: unexpected error:
Traceback (most recent call last):
File "/usr/bin/autopkgtest", line 993, in main
process_actions()
~~~~~~~~~~~~~~~^^
File "/usr/bin/autopkgtest", line 904, in process_actions
tests_tree = build_source(kind, arg, built_binaries)
File "/usr/bin/autopkgtest", line 705, in build_source
(tests, _) = testdesc.parse_debian_source(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
srcdir=pkg_root,
^^^^^^^^^^^^^^^^
...<5 lines>...
ignore_restrictions=opts.ignore_restrictions,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/share/autopkgtest/lib/testdesc.py", line 735, in parse_debian_source
(depends, package_under_test_depends) = _expand_test_depends(
~~~~~~~~~~~~~~~~~~~~^
test_names[0],
^^^^^^^^^^^^^^
...<3 lines>...
test_arch_is_foreign,
^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/share/autopkgtest/lib/testdesc.py", line 480, in _expand_test_depends
(my_packages, my_packages_for_test_arch) = _debian_packages_from_source(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
srcdir,
^^^^^^^
test_arch,
^^^^^^^^^^
test_arch_is_foreign,
^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/share/autopkgtest/lib/testdesc.py", line 376, in _debian_packages_from_source
if _architecture_is_concerned(test_arch, arch_list):
~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
File "/usr/share/autopkgtest/lib/testdesc.py", line 332, in _architecture_is_concerned
return dpkg_arch_table.architecture_is_concerned(
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
architecture,
^^^^^^^^^^^^^
architecture_restrictions,
^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/lib/python3/dist-packages/debian/_arch_table.py", line 349, in architecture_is_concerned
dpkg_wildcard = self._dpkg_wildcard_to_tuple(arch_restriction_positive)
File "/usr/lib/python3/dist-packages/debian/_arch_table.py", line 143, in _dpkg_wildcard_to_tuple
result = self._dpkg_arch_to_tuple(arch)
File "/usr/lib/python3/dist-packages/debian/_arch_table.py", line 152, in _dpkg_arch_to_tuple
return self._arch2table[dpkg_arch]
~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'kfreebsd-amd64'
autopkgtest exit status is 20
(I fixed it by replacing the explicit architecture list in postgresql-hll with
"B-D: architecture-is-little-endian", so this isn't a pressing problem.)
Christoph
Hi, Agree. Looking at the stack trace, it's indeed python3-debian that's crashing here. (leaving the rest of the message for the maintainers of python3-debian). However, I'm not seeing the failures in the history of ci.d.n, is this on your own infra? Which version of python3-debian are you running there? I'm also surprised you report it on ppc64el, there's no arch specific code involved here, or am I wrong? Paul
Re: Paul Gevers It's from the apt.postgresql.org infrastructure: https://jengus.postgresql.org/view/Testsuite/job/postgresql-hll-autopkgtest/96/architecture=ppc64el,distribution=sid/console Other archs (amd64, arm64) were not expected. I would attribute that to version skew between the architectures, but that doesn't explain why forky is also affected which should pretty much in sync all the time. This is autopkgtest running inside a schroot of the target distribution/arch (using the null virt). Christoph
Hello! (Guillem - this is about architecture tuple names; see bugs.debian.org/1125014 for additional context if needed) The data source that python3-debian uses for valid architectures is dpkg, and kfreebsd seems to have been dropped from /usr/share/dpkg/ostable and /usr/share/dpkg/tupletable between trixie and forky: trixie: $ grep freebsd /usr/share/dpkg/*table /usr/share/dpkg/ostable:eabihf-gnu-kfreebsd kfreebsd-gnueabihf kfreebsd[^-]*-gnueabihf /usr/share/dpkg/ostable:base-gnu-kfreebsd kfreebsd-gnu kfreebsd[^-]*(-gnu.*)? /usr/share/dpkg/ostable:base-bsd-freebsd freebsd freebsd[^-]* /usr/share/dpkg/tupletable:base-gnu-kfreebsd-amd64 kfreebsd-amd64 /usr/share/dpkg/tupletable:base-gnu-kfreebsd-i386 kfreebsd-i386 /usr/share/dpkg/tupletable:base-bsd-freebsd-amd64 freebsd-amd64 /usr/share/dpkg/tupletable:base-bsd-freebsd-arm freebsd-arm /usr/share/dpkg/tupletable:base-bsd-freebsd-arm64 freebsd-arm64 /usr/share/dpkg/tupletable:base-bsd-freebsd-i386 freebsd-i386 /usr/share/dpkg/tupletable:base-bsd-freebsd-powerpc freebsd-powerpc /usr/share/dpkg/tupletable:base-bsd-freebsd-ppc64 freebsd-ppc64 /usr/share/dpkg/tupletable:base-bsd-freebsd-riscv freebsd-riscv sid $ grep freebsd /usr/share/dpkg/*table /usr/share/dpkg/ostable:base-bsd-freebsd freebsd freebsd[^-]* /usr/share/dpkg/tupletable:base-bsd-freebsd-amd64 freebsd-amd64 /usr/share/dpkg/tupletable:base-bsd-freebsd-arm freebsd-arm /usr/share/dpkg/tupletable:base-bsd-freebsd-arm64 freebsd-arm64 /usr/share/dpkg/tupletable:base-bsd-freebsd-i386 freebsd-i386 /usr/share/dpkg/tupletable:base-bsd-freebsd-powerpc freebsd-powerpc /usr/share/dpkg/tupletable:base-bsd-freebsd-ppc64 freebsd-ppc64 /usr/share/dpkg/tupletable:base-bsd-freebsd-riscv freebsd-riscv The data source was changed in dpkg 5d17f447257a7ea5fa60e3496e365c29a2b63cc5 where all kfreebsd references were dropped. I see some old Debian architectures (official and unofficial) are still present in these files while others are missing, and there's also some architectures from d-ports there, so I'm not sure of the intention of these data; my feeling is that historical names probably should be retained in these tables. I'm including Guillem in thi I'm not sure whether the problematic behaviour should *also* be changed in python-debian to not raise exceptions on unknown architectures - I doubt that python-debian should blindly ignore invalid architectures in this code either. Christoph, I'm not sure how to actually provoke the failure you're seeing - my attempts to make a very minimal reproducer have failed. What versions of dpkg and python3-debian are involved? Perhaps Paul can add some autopkgtest knowledge to this to help too, to know how architecture_is_concerned is being called in this situation. thanks Stuart
Hi, I just realized that the use of python3-debian for this is a recent change [1] (we used Perl, but now only on systems where python3-debian is too old). We use it to figure out which binaries we should expect from a source on the architecture we're running the test for [2]. Instead of giving the full list to dpkg_arch_table.architecture_is_concerned(), we could ask it one architectures at a time and handle the exception ourselves (and assume the answer is False for that arch), but that feels clumsy. Given that we aim to be backwards compatible for a long time [3], I think we still should do that. I'd still like python3-debian to do that for us, such that eventually we can drop such backwards-compatibility code. Paul [1] https://salsa.debian.org/ci-team/autopkgtest/-/commit/dd84a47ebaf68b64c8e6a46b67946418c6e6a0e8 [2] https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/lib/testdesc.py?ref_type=heads#L376 [3] https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/debian/README.source
Re: Stuart Prescott It was up-to-date sid and forky chroots at that point. To trigger, I would think you'd need a source package that lists kfreebsd-amd64 in the Package-List. But there are plenty of these at the moment in forky and I can't trigger it now. :( Since my original problem with postgresql-hll is fixed (I removed the explicit architecture list), feel free to close the bug if you think there is nothing to fix. Thanks, Christoph
Hi! [ Paul Tagliamonte CCed, related to our earlier dak vs dpkg arch data discussion. ] (Thanks for looping me in!) (Sentence seems to be cut off.) So the intention with the architecture cleanups that I've been doing in the past (now recently when removing kopensolaris-any, kfreebsd-any and powerpcspe; and previously by restricting valid subsets of wildcards for hurd, freebsd, dragonflybsd, darwin, solaris, aix, and removal of knetbsd-any, uclinux, arm64ilp32, avr32, m32r and tilegx; and even earlier the removal of lpia, which I think was the first removal), has been to make it visible that these are long dead architectures (for example a kernel or libc does not support them at all anymore or ever, they cannot be bootstrapped, etc) that do not need to be supported anymore in packaging, and so that tooling that pulls arch data from dpkg (such as lintian), can then start emitting tags that those can be removed from packaging. This has been prompted by seeing maintainers (in many cases) try to cover all architectures supported by dpkg, when listing them in package metadata or programmatically in code for example, which seems counter productive (and a waste of their time). In the past I've tried to file reports for obsolete arch usage, but I think for the latest batch, I'd like to let lintian sip in, and then do a bug filing once most maintainers have had a go at removing those dead arches. While discussing the removal of this last batch, concerns were brought up about dak potentially refusing uploads (even for older releases) when it starts using the dpkg arch tables [C]. Where I talked with Paul Tagliamonte about improving dak to use the dpkg arch table for the target release, so that we could do these cleanups safely (I should perhaps file a report to make this more visible though!). Although as I mentioned in the dpkg list discussion, if this is going to cause unintended fallout for the next stable release, I'm prepared to revert those removals before the Debian release. [C] <https://lists.debian.org/debian-dpkg/2025/09/msg00009.html> I guess autopkgtest might perhaps need something similar? During the above linked conversations, I also wondered whether the arch definitions should instead be kept longer (or forever) and marked somehow as obsolete, so that dpkg tooling (and other tooling using the data files) could emit warnings, and then could error out for unknown ones. But I'm not sure whether the added complexity is worth it (and tooling would need to be adapted to then handle the «obsolete» markings and act on them), and so whether always emitting warnings for unknown ones is enough, given that this might as well trigger errors (for example when output on stderr anyway). And in principle I've been leaning into it not being worth it. It might be that if the autopkgtest infra is running on an older Debian release, then it still has the old arch definitions from dpkg, and that's why you are not seeing this? (Although if you tested everything locally, then I don't know. :) In any case, I'm open to discussing alternatives here, if people think other paths forward might make more sense. Thanks, Guillem
A bit OT from why I'm on CC, but FWIW, I agree here. I often see
long-dead arches listed in B-D or D lines, and I tend to believe it's
copy-paste, not actually done with the intention of dealing with a real
problem for a real port (official or otherwise).
Ditto, back when I helped with NEW, I would often see this same thing. I
would rarely REJECT or even PROD over it.
Yeah, this is on my TODO. I fully intend to give this a whirl, but i've
been set back by a few $LIFE things. I think it's a great idea, and I've
recently dealt with dpkg arch tuples, so some of it is even still
swapped into cache.
Hopefully dak isn't a factor here. If it becomes one, definitely hit me
up directly.
here.
I did look at the source (since I am technically a parseltongue), and we
can do a bad thing with the internals to dupe:
```
import debian._arch_table
table = debian._arch_table.DpkgArchTable.load_arch_table()
table._dpkg_wildcard_to_tuple("kfreebsd-amd64")
```
On sid this gives me:
```
Traceback (most recent call last):
File "<python-input-14>", line 1, in <module>
table._dpkg_wildcard_to_tuple("kfreebsd-amd64")
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/debian/_arch_table.py", line 143, in _dpkg_wildcard_to_tuple
result = self._dpkg_arch_to_tuple(arch)
File "/usr/lib/python3/dist-packages/debian/_arch_table.py", line 152, in _dpkg_arch_to_tuple
return self._arch2table[dpkg_arch]
~~~~~~~~~~~~~~~~^^^^^^^^^^^
KeyError: 'kfreebsd-amd64'
```
Which looks the same.
fondly,
paultag
Hi, And today I'm seeing that on ci.d.n for loong64 (because our hosts are running sid on that architecture for obvious reasons). https://ci.debian.net/packages/libr/libreoffice/unstable/loong64/68179872/ Paul
Hello, Bug #1125014 in python-debian 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/python-debian-team/python-debian/-/commit/05a6c09a329d86c3e7fb2c28f3b57578a2cada14 ------------------------------------------------------------------------ Don't raise exceptions on invalid arch specifications Accept invalid architecture specifications rather than raise exceptions. Closes: #1125014 ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1125014
Hi, I ran into this today again, as we enabled loong64 testing for migration now and this now can be a blocker. Could python-debian with the fix be uploaded please? https://ci.debian.net/packages/b/boost1.83/testing/loong64/71778870/ Paul
I've uploaded 1.1.1 with the fix. Cheers, Jelmer
Hi, Thank you. Paul
We believe that the bug you reported is fixed in the latest version of python-debian, 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 1125014@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Jelmer Vernooij <jelmer@debian.org> (supplier of updated python-debian 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, 07 Jun 2026 11:14:32 +0100 Source: python-debian Architecture: source Version: 1.1.1 Distribution: unstable Urgency: medium Maintainer: Debian python-debian Maintainers <pkg-python-debian-maint@lists.alioth.debian.org> Changed-By: Jelmer Vernooij <jelmer@debian.org> Closes: 1109030 1125014 Changes: python-debian (1.1.1) unstable; urgency=medium . [ Stuart Prescott ] * Move charset-normaliser to an optional dep group * Annotate additional deps with nocheck * Have dh_python3 add optional deps to Suggests * Update licence metadata format in pyproject.toml * Tweak tag_regex for tag2upload vs setuptools_scm compatibility * Don't raise exceptions on invalid arch specifications (Closes: #1125014) * Fix crash in copying multivalued Deb822 objects (Closes: #1109030) * Minor whitespace fixes . [ Jelmer Vernooij ] * Always build distribution tarball in CI . [ Christoph Steiger ] * Add Static-Built-Using to relations Checksums-Sha1: 11227acaec0f859e8fbe580f1e7c8a8bfef7ecee 2119 python-debian_1.1.1.dsc 86378e173fa2be056d1fe2be0e90719f5dc064ca 199876 python-debian_1.1.1.tar.xz 65ecdf96ee9cd9783d35401936b581f26c6fb924 7092 python-debian_1.1.1_source.buildinfo Checksums-Sha256: 1f1804ab59b8054c63ae701ca9951f60b702600d13d75957886a2373f2f25024 2119 python-debian_1.1.1.dsc 59cc8a9a6236f6386ae622564e7d13c846e65cfa63948c9a75e02358dfeaac20 199876 python-debian_1.1.1.tar.xz 37cddcd0a83b3dd80886c9ac24cc543f0802be35b8db2dbaa86d2074f46905e6 7092 python-debian_1.1.1_source.buildinfo Files: f58dbe002b77be7401fcc03b81af33eb 2119 python optional python-debian_1.1.1.dsc 6ed47b93514f0b86b21fa19a40fae76c 199876 python optional python-debian_1.1.1.tar.xz b25214144ded7ab2715c2ec35a064f82 7092 python optional python-debian_1.1.1_source.buildinfo -----BEGIN PGP SIGNATURE----- iQFGBAEBCgAwFiEE45ORIHAv6kHRgdNzhp0ktO57TaYFAmolRNISHGplbG1lckBk ZWJpYW4ub3JnAAoJEIadJLTue02mctkH/3OBo9BBvXtS418M8phCpXSjMVH96+j5 8MAKG+Vzemi9dLQjYz4eoT8IIROc+wnv3ynbX55l2WA3356mvQLA8yWFVDoOggkE vZrSAXSAKNt9tbK0RuiJhtQbvQV2ponX0hYW8Ehho/mSDROTUGAtRAS4SS/AjclK Njy9HO9fG04SsLzqlDWjSmk20EP5iDB46/AAg2CuzKMc7exfNQCVfAtEEIaAmAjC 89GKc63fzVO1rdgfLBrltMHW2NbA6PmG7RBuzFmGxBoOWWPLZeH6gLH6IkWN4NVX cYClJejajQS2MhCiFkjdVezYTQl8lz+//Q6PYwQuTGxet+1GnqprOG0= =UFu2 -----END PGP SIGNATURE-----
Thank you!