53233 2025-02-26 19:31:43 +0300 Ошибка lib.req: WARNING: <lib> is not yet set-versioned 2025-03-13 11:20:50 +0300 1 1 1 Unclassified Branch p11 rpm-build unspecified x86_64 Linux CLOSED NOTABUG P5 normal --- 0 pfe placeholder amakeenk antohami iv vt zerg qa-p11 oldest_to_newest 259985 0 pfe 2025-02-26 19:31:43 +0300 Собираю RPM-пакеты C++ - проекта, на этапе Executing(%install) получаю ошибки вида: error: file /usr/lib64/ld-linux-x86-64.so.2()(64bit): No such file or directory lib.req: WARNING: /usr/lib64/ld-linux-x86-64.so.2()(64bit) is not yet set-versioned error: file /usr/lib64/libc.so.6()(64bit): No such file or directory lib.req: WARNING: /usr/lib64/libc.so.6()(64bit) is not yet set-versioned error: file /usr/lib64/libcrypto.so.3()(64bit): No such file or directory lib.req: WARNING: /usr/lib64/libcrypto.so.3()(64bit) is not yet set-versioned error: file /usr/lib64/libcurl.so.4()(64bit): No such file or directory lib.req: WARNING: /usr/lib64/libcurl.so.4()(64bit) is not yet set-versioned error: file /usr/lib64/libgcc_s.so.1()(64bit): No such file or directory lib.req: WARNING: /usr/lib64/libgcc_s.so.1()(64bit) is not yet set-versioned error: file /usr/lib64/libm.so.6()(64bit): No such file or directory lib.req: WARNING: /usr/lib64/libm.so.6()(64bit) is not yet set-versioned error: file /usr/lib64/libssh.so.4()(64bit): No such file or directory lib.req: WARNING: /usr/lib64/libssh.so.4()(64bit) is not yet set-versioned error: file /usr/lib64/libstdc++.so.6()(64bit): No such file or directory lib.req: WARNING: /usr/lib64/libstdc++.so.6()(64bit) is not yet set-versioned error: file /usr/lib64/libz.so.1()(64bit): No such file or directory lib.req: WARNING: /usr/lib64/libz.so.1()(64bit) is not yet set-versioned Сама сборка пакета несмотря на это завершается успешно, но потом при установке появляются ошибки вида: Depends: /usr/lib64/libc.so.6(GLIBC_2.14)(64bit) but it is not installable как раз для этих библиотек. При сборке все эти библиотеки есть по указанным путям. Нашёл такой пост на похожую тему: https://lists.altlinux.org/pipermail/devel/2010-December/187234.html Окружение: ALT Linux p11 (официальный докер-образ) $ gcc --version x86_64-alt-linux-gcc (GCC) 13.2.1 20240128 (ALT Sisyphus 13.2.1-alt3) 260006 1 iv 2025-02-27 09:49:30 +0300 Сообщения о том, что какая-то библиотека is not set-versioned, не мешают сборке. Нужно понять, откуда взялась зависимость на /usr/lib64/libc.so.6(GLIBC_2.14)(64bit), именно такие зависимости приводят к сообщениям, которые Вы видите. К сожалению, понять это, не имея возможности воспроизвести проблему локально, непросто. Вы собираете Ваш проект? Из исходников? Можете поделиться? Вы не делаете что-нибудь странное с компоновщиком? > ALT Linux p11 (официальный докер-образ) Можете уточнить, какой именно? Хеш, теги? 260070 2 pfe 2025-02-28 08:21:07 +0300 Спасибо за пояснения, попробую разобраться, откуда берётся проблемная зависимость, я думал, что это последствия set-versioned. Сборочный докер-образ у меня основан на свежем текущем alt:p11 RepoDigests: alt@sha256:301f3053b315587a1584d32f0d46dd9ab3f41120b5b0506e991fb43f1747fd98 в котором обычным образом установлены пакеты для сборки: apt-get install -y glibc-devel meson zlib-devel и т.д. Исходниками поделиться не могу, так как это закрытый код. Попробую пока сам. 260813 3 pfe 2025-03-11 14:24:13 +0300 У меня есть подозрение, что причина проблемных библиотек - в пакетах этих библиотек. Например, такая тестовая программа для проверки liblz4 (liblz4 - это одна из проблемных библиотек): #include <stdio.h> #include "lz4.h" int main(int argc, char** argv) { (void)argc; (void)argv; printf("Hello World ! LZ4 Library version = %d\n", LZ4_versionNumber()); return 0; } на CentOS Stream 9 собирается успешно: [root@14186f489e04 ~]# gcc -llz4 -o prog test.c [root@14186f489e04 ~]# chmod +x prog [root@14186f489e04 ~]# ./prog Hello World ! LZ4 Library version = 10903 а на ALT Linux сборка выдаёт ошибку [root@347e45b1a3f4 ~]# gcc -llz4 -o prog test.c ld: /tmp/cc2muNOw.o: in function `main': test.c:(.text+0x10): undefined reference to `LZ4_versionNumber' collect2: error: ld returned 1 exit status Библиотека и символ в действительности присутствуют: [root@347e45b1a3f4 ~]# objdump -T /usr/lib64/liblz4.so.1 | grep LZ4_versionNumber 0000000000004c80 g DF .text 0000000000000006 Base LZ4_versionNumber Также я заметил, что на CentOS Stream 9 (где нет ошибки установки) в зависимостях моего пакета эти библиотеки указаны в виде чистого soname: [root@69acd03fbbc6 packages]# rpm --requires -qp ./mypackage-1.2.3-1.el9.x86_64.rpm | grep liblz4 liblz4.so.1()(64bit) а на ALT Linux они указаны в виде soname с полным путём [root@113afa5094e4 packages]# rpm --requires -qp ./mypackage-1.2.3-1.x86_64.rpm | grep liblz4 /usr/lib64/liblz4.so.1 и именно на зависимостях с полным путём возникает ошибка "not installable". Не складывается ли это в какую-то единую картину? Что ещё можно сделать для локализации ошибки? В качестве ALT Linux я использую текущий докер-образ alt:p11. 260814 4 pfe 2025-03-11 14:32:49 +0300 Для сравнения вот ещё выводы команд на CentOS Stream 9, где установка успешна: [root@2a5dbdc177ee /]# rpm -q --provides lz4-libs liblz4.so.1()(64bit) lz4-libs = 1.9.3-5.el9 lz4-libs(x86-64) = 1.9.3-5.el9 на ALT Linux p11 [root@347e45b1a3f4 ~]# rpm -qa | grep lz4 liblz4-1.9.4-alt1.x86_64 liblz4-devel-1.9.4-alt1.x86_64 [root@347e45b1a3f4 ~]# rpm -q --provides liblz4 liblz4.so.1()(64bit) = set:kdM5gNUbF3KIMt3ooTZHOp2fldcuDMknnKl5orJK759Af8VRAc7Z0Kn1SgSvsiLihMW1acRgjOHNzPqQPpQMfKoPdjoe4pZjCvX4sYK1ROZ4XJiap0NcuzRgiLh0iELAxziAxIvOiFM9MwOHBqNte1OYb2F19YqrnabgGpHW6FhdJZdu5413fH8r5 liblz4 = 1:1.9.4-alt1:sisyphus+309416.100.1.1 На CentOS provides сщвпадает с requires пакета, на ALT Linux - нет. 260832 5 arseny 2025-03-11 15:54:04 +0300 (In reply to pfe from comment #3) > У меня есть подозрение, что причина проблемных библиотек - в пакетах этих > библиотек. Например, такая тестовая программа для проверки liblz4 (liblz4 - > это одна из проблемных библиотек): > > #include <stdio.h> > #include "lz4.h" > > int main(int argc, char** argv) > { > (void)argc; (void)argv; > printf("Hello World ! LZ4 Library version = %d\n", LZ4_versionNumber()); > return 0; > } > > на CentOS Stream 9 собирается успешно: > > [root@14186f489e04 ~]# gcc -llz4 -o prog test.c > [root@14186f489e04 ~]# chmod +x prog > [root@14186f489e04 ~]# ./prog > Hello World ! LZ4 Library version = 10903 > > а на ALT Linux сборка выдаёт ошибку > > [root@347e45b1a3f4 ~]# gcc -llz4 -o prog test.c > ld: /tmp/cc2muNOw.o: in function `main': > test.c:(.text+0x10): undefined reference to `LZ4_versionNumber' > collect2: error: ld returned 1 exit status > > Библиотека и символ в действительности присутствуют: > > [root@347e45b1a3f4 ~]# objdump -T /usr/lib64/liblz4.so.1 | grep > LZ4_versionNumber > 0000000000004c80 g DF .text 0000000000000006 Base > LZ4_versionNumber А пакет liblz4-devel с симлинком /usr/lib64/liblz4.so, скорее всего, отсутствует. # apt-get install 'pkgconfig(liblz4)' Вы ссылаетесь на CentOS; разве там не выделяют файлы для разработки в пакет "-devel"? 260836 6 zerg 2025-03-11 16:03:56 +0300 (Ответ для Arseny Maslennikov на комментарий #5) > Вы ссылаетесь на CentOS; разве там не выделяют файлы для разработки в пакет > "-devel"? Да. Это было бы слишком, т.к. для 2-х soname уже не сделать 2-х devel-пакетов. https://src.fedoraproject.org/rpms/lz4/blob/rawhide/f/lz4.spec 260838 7 arseny 2025-03-11 16:06:29 +0300 (In reply to pfe from comment #3) > Также я заметил, что на CentOS Stream 9 (где нет ошибки установки) в > зависимостях моего пакета эти библиотеки указаны в виде чистого soname: > > [root@69acd03fbbc6 packages]# rpm --requires -qp > ./mypackage-1.2.3-1.el9.x86_64.rpm | grep liblz4 > liblz4.so.1()(64bit) > > а на ALT Linux они указаны в виде soname с полным путём > > [root@113afa5094e4 packages]# rpm --requires -qp > ./mypackage-1.2.3-1.x86_64.rpm | grep liblz4 > /usr/lib64/liblz4.so.1 > > и именно на зависимостях с полным путём возникает ошибка "not installable". > > Не складывается ли это в какую-то единую картину? Что ещё можно сделать для > локализации ошибки? Предоставьте, пожалуйста, команды, которыми вы собираете пакет, а лучше — ещё и спек. Ещё на всякий случай замечу, что далеко не все привычки упаковки под rh можно перенести на альт, и чем дальше, тем сильнее эти два мира расходятся. В частности, на сегодняшний день программа rpm и программа rpmbuild собираются из разных исходников и сопровождаются достаточно независимо, и первой из них собирать пакеты _не стоит_; `rpm -ba` даст не тот результат, что вы ожидаете, в отличие от rpmbuild -ba. 260840 8 iv 2025-03-11 16:09:22 +0300 > gcc -llz4 -o prog test.c Во-первых, обратите внимание: $ sudo apt-get update [...] $ sudo apt-get install liblz4-devel [...] $ gcc -llz4 -o prog test.c ld: /tmp/.private/iv/ccLyrIwq.o: in function `main': test.c:(.text+0x10): undefined reference to `LZ4_versionNumber' collect2: error: ld returned 1 exit status $ gcc -o prog test.c -llz4 && ./prog Hello World ! LZ4 Library version = 10904 Наш gcc, как и многие другие, по умолчаню включает -Wl,--as-needed, поэтому библиотеки надо указывать после файлов, которые ими пользуются. Сборочный инструментарий (cmake, meson и т.п.) обычно так и делает. Далее, $ readelf -d prog | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [liblz4.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] Покажите пожалуйста аналогичный вывод для бинарников из Вашего пакета, и командную строку компоновщика. 260876 9 pfe 2025-03-12 05:08:27 +0300 Вот строка компоновщика одной из shared-библиотек: [25/185] cc -o subprojects/pb3-format-c/libpb3_encoder.so.1 subprojects/pb3-format-c/libpb3_encoder.so.1.p/pb3_cbor.c.o subprojects/pb3-format-c/libpb3_encoder.so.1.p/encoder.c.o subprojects/pb3-format-c/libpb3_encoder.so.1.p/decoder.c.o subprojects/pb3-format-c/libpb3_encoder.so.1.p/ft_hash.c.o subprojects/pb3-format-c/libpb3_encoder.so.1.p/compression.c.o subprojects/pb3-format-c/libpb3_encoder.so.1.p/shared.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,-soname,libpb3_encoder.so.1 -pipe -frecord-gcc-switches -Wall -g -O2 -Wl,--start-group subprojects/tinycbor/libtinycbor.a subprojects/spookyhash/libspookyhash.a -lpq /usr/lib64/libz.so -lzstd -llz4 -Wl,--end-group Вот получившиеся зависимости этой библиотеки в заголовке: [root@7563664ad248 ~]# readelf -d libpb3_encoder.so | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libz.so.1] 0x0000000000000001 (NEEDED) Shared library: [libzstd.so.1] 0x0000000000000001 (NEEDED) Shared library: [liblz4.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] [root@7563664ad248 ~]# Но на этапе find-requires зависимые библиотеки, похоже, попадают в метаданные пакета с полными путями: Processing files: libpb3-encoder-3.0.7~beta3~20250312g0a15594-1 Finding Provides (using /usr/lib/rpm/find-provides) Executing: /bin/sh -e /tmp/rpm-tmp.iK8cKq Finding Requires (using /usr/lib/rpm/find-requires) Executing: /bin/sh -e /tmp/rpm-tmp.2SzQ4M Provides: libpb3_encoder.so.1()(64bit) = set:kdqkmZjNkXms1fiYqLU92s0ZtKLdBmL5ud3jmUttcwtGqidw54YiZk1locpLZhxwpAaqopaQ516ZuvFzG8wvKGWTPqVXFfero7qeshcqK0CNfMQts32r6LF4AxCGiv8ZFNlZvf1da5GHANHlB2qZpNlZuEANGUzdbzL4MROd4 Requires: /usr/lib64/libc.so.6(GLIBC_2.14)(64bit), /usr/lib64/libc.so.6(GLIBC_2.2.5)(64bit), /usr/lib64/libc.so.6(GLIBC_2.3)(64bit), /usr/lib64/libc.so.6(GLIBC_2.3.4)(64bit), /usr/lib64/libc.so.6(GLIBC_2.33)(64bit), /usr/lib64/libc.so.6(GLIBC_2.38)(64bit), /usr/lib64/libc.so.6(GLIBC_2.4)(64bit), /usr/lib64/liblz4.so.1, /usr/lib64/libz.so.1(ZLIB_1.2.0)(64bit), /usr/lib64/libzstd.so.1, rtld(GNU_HASH) Вот части спек-файла, относящиеся к сборке пакета этой библиотеки: %build %meson %meson_build %install # ALT Linux has its own meson install macro. %distribution can be used to detect # ALT Linux %{?distribution: %__meson_install}%{!?distribution: %meson_install} %clean rm -rf $RPM_BUILD_ROOT %files -n libpb3-encoder %_libdir/libpb3_encoder*.so* 260877 10 pfe 2025-03-12 07:26:33 +0300 Пакеты собираются командой: rpmbuild -bb --define="_lto_cflags %{nil}" --define="optflags_lto %{nil} спек-файл 260880 11 iv 2025-03-12 09:02:31 +0300 Спасибо. Пока ничего особенного не видно, так что давайте попробуем копнуть глубже. Могу предложить два пути. I. Вы можете добавить к rpmbuild ключ -vvv и приложить полученый лог сборки сюда? Что-то типа такого rpmbuild -vvv -bb [...] 2>&1 | tee rpmbuild.log Возможно, для понимания проблемы будет достаточно только того, что идёт после строки Finding Requires (using /usr/lib/rpm/find-requires) если что-то до этого Вы хотели бы скрыть. Может и сами почитать и это Вас на что-нибудь вдохновит, но там наверное будет очень много букв. II. Нужно попробовать воспроизвести проблему на каком-то свободном пакете, которым Вы сможете нормально поделиться. Например, пересобрать пакет banner (https://packages.altlinux.org/en/sisyphus/srpms/banner/rpms/), и посмотреть, будут ли у него неправильные зависимости на /usr/lib64/libc.so.6. Или поискать что-нибудь маленькое собираемое meson'ом (сейчас мне ничего в голову не приходит). 260954 12 pfe 2025-03-13 06:32:38 +0300 Я понял, в чём непосредственная причина ошибки. Наши пакеты устанавливаются в /opt, поэтому в спек-файле я в самом начале переопределяю макросы: %define _prefix /opt/mypackage/prog %define _libdir %_prefix/lib До этого я это не указывал, потому что считал, что это не влияет на сборку пакетов. Но причина точно в этом - с этими строчками ошибка возникает, без них - нет, всё собирается и устанавливается без ошибок. Прилагаю минималистический пример для воспроизведения (example.tgz), команды для воспроизведения в readme.txt. 260955 13 17964 pfe 2025-03-13 06:33:44 +0300 Created attachment 17964 Код для воспроизведения ошибки 260956 14 antohami 2025-03-13 06:38:07 +0300 (In reply to pfe from comment #12) > Я понял, в чём непосредственная причина ошибки. Наши пакеты устанавливаются > в /opt, поэтому в спек-файле я в самом начале переопределяю макросы: > > %define _prefix /opt/mypackage/prog > %define _libdir %_prefix/lib > > До этого я это не указывал, потому что считал, что это не влияет на сборку > пакетов. Но причина точно в этом - с этими строчками ошибка возникает, без > них - нет, всё собирается и устанавливается без ошибок. > > Прилагаю минималистический пример для воспроизведения (example.tgz), команды > для воспроизведения в readme.txt. Вот вы сами накосячили, и почему-то вешаете багу на rpm-build. Нельзя так делать. 260957 15 pfe 2025-03-13 06:55:07 +0300 Во-первых, я, действительно, сначала хотел посоветоваться и послал свой вопрос в рассылку community@lists.altlinux.org, но мне так никто и не ответил. Во-вторых, поясните, в чём мой косяк? Макросы типа _libdir описывают пути для сборки и установки пакета и мне нужно, чтобы они были такими, какими я их задаю. На CentOS Stream, который является для меня эталоном RPM-based систем, никаких ошибок в этом случае не возникает. 260958 16 antohami 2025-03-13 07:00:16 +0300 (In reply to pfe from comment #15) > Во-первых, я, действительно, сначала хотел посоветоваться и послал свой > вопрос в рассылку community@lists.altlinux.org, но мне так никто и не > ответил. > community@ для таких вопросов не подходит. Есть рассылка https://lists.altlinux.org/mailman/listinfo/devel-newbies > Во-вторых, поясните, в чём мой косяк? Макросы типа _libdir описывают пути > для сборки и установки пакета и мне нужно, чтобы они были такими, какими я > их задаю. На CentOS Stream, который является для меня эталоном RPM-based > систем, никаких ошибок в этом случае не возникает. Это базовые макросы, их переопределять не надо. Переопределите DESTDIR, если это Makefile. 260963 17 zerg 2025-03-13 10:29:32 +0300 (Ответ для pfe на комментарий #15) > Во-вторых, поясните, в чём мой косяк? Макросы типа _libdir Эти макросы используются всеми компонентами, участвующими в сборке, а не только вашим конечным пакетом. Переопределяя любые(не ваши) макросы будьте готовы, что что-то сломаете. 260965 18 iv 2025-03-13 11:20:50 +0300 > Я понял, в чём непосредственная причина ошибки. Ура) (In reply to pfe from comment #15) > Во-первых, я, действительно, сначала хотел посоветоваться и послал свой > вопрос в рассылку community@lists.altlinux.org, но мне так никто и не > ответил. Не знаю, подходит ли для этого community@ (мне казалось что почему бы и нет?) но я не вижу Вашего письма ни у себя, ни в архивах. Возможно, Вы пропустили письмо от mailman, или не придали ему значения. Не вижу никаких проблем в том, чтобы задавать вопросы в багзилле, но письмо в devel-newbies безусловно привлекло бы больше людей к поиску решения. (In reply to Антон Мидюков from comment #16) > Это базовые макросы, их переопределять не надо. > Переопределите DESTDIR, если это Makefile. Вы так ругаетесь на человека как будто это где-то документированно)) Но действительно, макросы %_prefix, %_libdir, %_bindir и подобные -- это не точки конфигурирования макросов. Они описывают систему, и именно в таком качестве используются как в пользовательских макросах (%configure, %makeinstall_std, %meson...) так и во внутренних частях rpm-build. Например, после переопределения макроса %_libdir /usr/lib64, с точки зрения rpm, перестаёт быть стандартным путём поиска динамических библиотек. Отсюда и зависимости с полным путём. Если сборочной системе необходимо передать какие-то особые параметры, не нужно менять такие макросы, нужно просто передать нужные параметры. Возможно, при этом не получится воспользоваться стандартными макросами. Это нормально: стандартные макросы предназначены для стандартных задач, а ваша -- нестандартная. 17964 2025-03-13 06:33:44 +0300 2025-03-13 06:33:44 +0300 Код для воспроизведения ошибки example.tgz application/x-compressed-tar 1383 pfe H4sIAAAAAAAAA+0YXY/bRPBQX9BK8A8QQ0rkpL049sVJqhyHem1RQQrt6a5QiXKyNvYm2dZem7U3 vWtViXf+AU/9K/BD+Ac888rsOs6lB+1RKcm1wqPIXs/M7mx2dj7ZCY3TiLW31ggOQr/b1W+33+0s v0vYcr1+z/O8Xqfb33Jcp4dk6K5zUyWoLKcSYCudsDfyXUR/T4HN9Z/JYG134C303+l3PNS/63V6 lf43Acv6jykXdpCmq5ahFYzKfa3+O2f633H1PXE7jrZ/Z9Ub+Tf4n+v/KhdBpEIGX2R5yBN7+iVZ oGrRM8+e1gjhIgd9ORp6QOUk2IZgSuW1a/pj1iTPCSA0ZgkPm5q8ezae7RpaKnHquFH7mkVRAg8T GYXwGQx/8GDIR5LKU5gxmfFEwB7Uwx9FbVsT/TnynopHTDaazWIxyXIlBTi75AW57PN73+EV+2dZ IuyR4lG4UhkX2n+3d+b/HVfbf7ffq+x/E0DD0E9l8pgFuY/mqmIm8qzxCO3Maj0sDK2Vn6bMQszx NuAzomKi6IQNwMJYYZEmIYSmqZ8lSgYsQwMe84hlDb1EGVEMV6pGEQ/8kKWaSYvAIRMhE8Fpw4r4 CN2N1STHhLAThhz4DFRORxFrWLjFibWNU5YkbS+vwFHyAJZEaCoXqNwoGkAuFdNbuOzTfvegtP/5 284nz1Yu4yL7dzDmz+2/6/T7Jv53dir73wR8+suHxeDKn7998BG+f3/51/344/7LBcfP/Su//vGJ tdW4lP1VsF4o7V+msQn86ygC36L+6zo7O2j/Ox6yV/XfBuAf+j86+Or20WpvwX/Xf9dxeyb/62j/ X+l//fAa/et8y85SFqxCxkXxv+d2zum/q9sAVfzfANRDNuaCARYBODiBdpLm7fg0pcETzPHNPSAL HszRQy6hPmdu4zch92iMtYBh/L4o1wfg2o7tkEMWMZoh0SVHKo6xyh/AIUPOUAUMKIzUhNyViUoH sJ+mmLjTHGdnZMgDJvS8A5mkkjNU0Cm5pW/nIftJccmyARTlQitkMxaBKVz1NrNA8lQvQs7LIXXc c0pkDC05Brt9jQQpDsG22/hbqnznGKyHwcZZBkfqcwnm5Rc4Up+XF6Tu+wWhRJB6gP9clNI+Pzz4 1r/13TfDO/7h/fsPkGwqJJw34gIPtDjlyylOFvbPaBhj+n+Sr16GsfHeG+p/73z/f6fXdSr73wTs Z0AFKIF2NsNLOWEhqIzJASHmSkPGcpWCufF4U4ng4jGF1u0FBjBwEPJgygTQDGSS5DhVRTzmObQE uM6OB3AVBGMhLs3HIJXARSa6Nuch08L3hw/gThI8YRJ4jE6H0DRvTVgOKg1pfvY5ty5YhCo0q6P2 yY2e3/OMCbWM28FngbP11i77fN91KO1/Xb0/DRfEf9f13NL+vU6R/6FTqOx/EzDv/ZUdtqKnV3TW xlRFuZ+YeKqba49M810z+Fke7gXXr7uuYUXkUyq1VfuRjsd7nRKtJ8f8mYnre47BHutH2ewfgGVs 1lCiIuxr5P7dg6HpGWZKZxwNC8OxpT9N58/Xbgb2irBvB0pKJvJ5V9DX7MhZOglks1qtIoHZq/l5 kmqnddO5uch4a5Y9TmRM88bS6s2zBa7jCrC0RJQnfjCO6CSD+nPBoxe1JSr+YUPSXCXZOr/WaASv S7eRVwkfbyQ6vIaFXOZkrhofOeRCnUCQiJyiLAlTdLhcoFyeMzhzuU+nPJgCHY9RrRlkScy0NBgr ERTpFeAamI2JEFVqtVUm25iGtJmYafW3buNz6SAQlU0NIdDPVz377uJ/6BNdnGOJbB5XLdcKKqig ggoqeBfhb6tZ8e4AKAAA