[d-kernel] [RFC] strict BuildRequires for kernel patches

[d-kernel] [RFC] strict BuildRequires for kernel patches

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 6023 bytes --]

Hello!

В текущей схеме сборки ядер имеются следующие проблемы:

1) В сборочных зависимостях пакетов kernel-image-* не указываются
конкретные версии пакетов с патчами (kernel-fix-*, kernel-feat-*).
Из-за этого возможна сборка пакета ядра с устаревшими версиями патчей.
Это, кстати, уже произошло как минимум один раз:

===========================================================================
$ diff <(rpm -qip /raid/ALT/archive/Sisyphus/2005/06/30/files/SRPMS/kernel-image-std26-up*) <(rpm -qip /raid/ALT/archive/Sisyphus/2005/06/30/files/i586/RPMS/kernel-image-std26-up*)
3,6c3,6
< Release     : alt11                         Build Date: Tue Jun 14 00:33:46 2005
< Install date: (not installed)               Build Host: vsu.hasher.altlinux.org
< Group       : System/Kernel and hardware    Source RPM: (none)
< Size        : 199090                           License: GPL
---
> Release     : alt11                         Build Date: Tue Jun 14 17:17:25 2005
> Install date: (not installed)               Build Host: bee5.hasher.altlinux.org
> Group       : System/Kernel and hardware    Source RPM: kernel-image-std26-up-2.6.11-alt11.src.rpm
> Size        : 36385402                         License: GPL
26c26
<       kernel-fix-core-2005.06.13-alt1
---
>       kernel-fix-core-2005.05.13-alt1
28,29c28,29
<       kernel-fix-fs-2005.06.13-alt1
<       kernel-fix-net-2005.06.13-alt1
---
>       kernel-fix-fs-2005.05.13-alt1
>       kernel-fix-net-2005.05.13-alt1
31c31
<       kernel-fix-drivers-char-2005.06.13-alt1
---
>       kernel-fix-drivers-char-2005.03.14-alt1
39c39
<       kernel-fix-drivers-media-2005.06.13-alt1
---
>       kernel-fix-drivers-media-2005.05.10-alt1
===========================================================================

Я вишу два варианта борьбы с этим безобразием:

- либо явно прописывать в spec-файлах ядер используемые версии пакетов
  с патчами (неудобно);

- либо брать текущие версии пакетов с патчами на момент сборки пакета
  с ядром (предполагая, что мантейнер соберёт ядро с правильными
  патчами, а после этого src.rpm не будет пересобираться).

Второй вариант может быть реализован, например, таким макросом:

===========================================================================
%get_patch_requires	%(for pkg in %get_patch_list; do \
	rpmquery --dbpath '%_dbpath' --qf ' %%{NAME} >= %%|SERIAL?{%%{SERIAL}:}|%%{VERSION}-%%{RELEASE} ' --whatprovides "$pkg" 2>/dev/null || \
		echo -n " $pkg "; \
done)
===========================================================================

При этом в spec-файле ядра будет указываться:

	BuildRequires: %get_patch_requires

(сейчас в этом месте используется %get_patch_list).  Зависимости
указываются с ">=", что вообще-то тоже не совсем правильно (если
какой-то вариант ядра обновляется редко, результат его пересборки в
текущем окружении может отличаться от изначальной сборки из-за
обновления патчей), но если там написать "=", ядра будут крайне редко
находиться в пересобираемом состоянии.


2) Использование при сборке ядра слишком новых пакетов с патчами также
может привести к возникновению неприятных проблем.  Патчи для новой
версии ядра довольно часто подходят и к старым версиям, но в новых
пакетах kernel-fix-* могут быть удалены патчи, которые были нужны для
старых версий ядра - в результате ядро, собранное по какой-то причине
с таким новым kernel-fix-*, не будет содержать нужных исправлений.

Для предотвращения таких ситуаций можно явно объявлять версии ядер, к
которым подходят патчи, например, добавив в пакеты с патчами Provides
вида kernel-fix-core(2.4.29), kernel-fix-core(2.6.12).  При переходе
на новую версию ядра необходимо будет обновить все необходимые для
этого ядра пакеты с патчами, даже если старый патч без изменений
подходит к новому ядру.  Естественно, всё это должно быть завёрнуто в
макросы:

===========================================================================
%_required_kernel_version	%nil
%require_patches_for_version()	%global _required_kernel_version (%1)

%supported_kernel_versions()	%(for ver in %*; do echo "Provides: %name($ver) = %version-%release"; done)

%get_patch_requires	%(for pkg in %get_patch_list; do \
	rpmquery --dbpath '%_dbpath' --qf ' %%{NAME}%_required_kernel_version >= %%|SERIAL?{%%{SERIAL}:}|%%{VERSION}-%%{RELEASE} ' --whatprovides "$pkg%_required_kernel_version" 2>/dev/null || \
		echo -n " $pkg%_required_kernel_version "; \
done)

%format_patch_list      %(for pkg in %get_patch_list; do \
	rpmquery --dbpath '%_dbpath' --qf '\\n\\t%%{NAME}-%%|SERIAL?{%%{SERIAL}:}|%%{VERSION}-%%{RELEASE}' --whatprovides "$pkg%_required_kernel_version" 2>/dev/null || \
		printf '\\n\\t%%s' "$pkg"; \
done)
===========================================================================

При этом в пакетах kernel-fix-*, kernel-feat-* добавляются строки вида:

	%supported_kernel_versions 2.4.29 2.6.12

В пакеты kernel-image-* добавляется строка:

	%require_patches_for_version %kversion

(эти зависимости нельзя включать по умолчанию, чтобы сохранилась
возможность пересобирать с новым kernel-build-tools ядра для старых
дистрибутивов).

Однако возникает неприятная ситуация с пакетами kernel-feat-evms,
kernel-feat-evms-nodm, kernel-feat-fs-squashfs - эти пакеты собираются
не из kernel CVS, поэтому с их обновлением для введения нового
Provides с очередной версией ядра будут проблемы.  Что делать с такими
пакетами, я пока не могу придумать (кроме ликвидации такого метода
сборки и помещения всех пакетов kernel-{feat,fix}-* в kernel CVS).


Какие будут мнения?  Проблему 1 надо исправлять в любом случае,
поскольку эти грабли один раз уже сработали.  Проблема 2 пока
теоретическая, но для редко обновляющихся вариантов ядер тоже может
всплыть (кроме того, при введении таких зависимостей заброшенные
kernel-image-* будут сразу становиться несобирающимися, если даже
патчи по каким-то причинам не отвалятся).

-- 
Sergey Vlasov

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: [RFC] strict BuildRequires for kernel patches

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

Hi Sergey!

Sunday 10, at 08:55:51 PM you wrote:

<skip>
> Однако возникает неприятная ситуация с пакетами kernel-feat-evms,
> kernel-feat-evms-nodm, kernel-feat-fs-squashfs - эти пакеты собираются
> не из kernel CVS, поэтому с их обновлением для введения нового
> Provides с очередной версией ядра будут проблемы.  Что делать с такими
> пакетами, я пока не могу придумать (кроме ликвидации такого метода
> сборки и помещения всех пакетов kernel-{feat,fix}-* в kernel CVS).
да, я именно за такой вариант (все -feat/fix должны жить в cvs).

> 
> Какие будут мнения?  Проблему 1 надо исправлять в любом случае,
> поскольку эти грабли один раз уже сработали.  Проблема 2 пока
> теоретическая, но для редко обновляющихся вариантов ядер тоже может
> всплыть (кроме того, при введении таких зависимостей заброшенные
> kernel-image-* будут сразу становиться несобирающимися, если даже
> патчи по каким-то причинам не отвалятся).
полностью поддерживаю предложеные решения.

-- 
WBR, Konstantin	      chat with ==>ICQ: 109916175
     Lepikhov,	      speak  to ==>JID: lakostis@jabber.org
aka L.A. Kostis       write  to ==>mailto:lakostis@pisem.net.nospam

...The information is like the bank... 			  (c) EC8OR

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] [RFC] strict BuildRequires for kernel patches

[Alex Yustasov]

On Sun, Jul 10, 2005 at 08:55:51PM +0400, Sergey Vlasov wrote:

Здравствуйте.
skip
> Я вишу два варианта борьбы с этим безобразием:
> 
> - либо явно прописывать в spec-файлах ядер используемые версии пакетов
>   с патчами (неудобно);
> 
> - либо брать текущие версии пакетов с патчами на момент сборки пакета
>   с ядром (предполагая, что мантейнер соберёт ядро с правильными
>   патчами, а после этого src.rpm не будет пересобираться).
Может еще для ядра, которое пошло в сизиф,  где-нибудь сохранять набор
патчей, с которыми оно было собрано? Или собирать пакет, в котором будет
содержимое
hasher/chroot/usr/src/kernel/patches/. Можно будет собрать такое же ядро.

skip
> 
> 
> 2) Использование при сборке ядра слишком новых пакетов с патчами также
> может привести к возникновению неприятных проблем.  Патчи для новой
> версии ядра довольно часто подходят и к старым версиям, но в новых
> пакетах kernel-fix-* могут быть удалены патчи, которые были нужны для
> старых версий ядра - в результате ядро, собранное по какой-то причине
> с таким новым kernel-fix-*, не будет содержать нужных исправлений.
> 
> Для предотвращения таких ситуаций можно явно объявлять версии ядер, к
> которым подходят патчи, например, добавив в пакеты с патчами Provides
> вида kernel-fix-core(2.4.29), kernel-fix-core(2.6.12).  При переходе

Может kernel-fix-core(2.6.12-altN)?

skip

Re: [d-kernel] [RFC] strict BuildRequires for kernel patches

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 3055 bytes --]

On Sun, Jul 10, 2005 at 09:10:43PM +0300, Alex Yustasov wrote:
> On Sun, Jul 10, 2005 at 08:55:51PM +0400, Sergey Vlasov wrote:
> > Я вишу два варианта борьбы с этим безобразием:
> > 
> > - либо явно прописывать в spec-файлах ядер используемые версии пакетов
> >   с патчами (неудобно);
> > 
> > - либо брать текущие версии пакетов с патчами на момент сборки пакета
> >   с ядром (предполагая, что мантейнер соберёт ядро с правильными
> >   патчами, а после этого src.rpm не будет пересобираться).
> Может еще для ядра, которое пошло в сизиф,  где-нибудь сохранять набор
> патчей, с которыми оно было собрано?

Версии патчей, использованные при сборке, сейчас пишутся в
%description; старые версии патчей можно вытащить из kernel CVS (за
исключением нескольких пакетов, собирающихся "левым" образом).
Естественно, чтобы собрать в hasher именно старое ядро, нужно
использовать соответствующий старый репозиторий (в частности, не
содержащий более новых пакетов kernel-{fix,feat}-* - иначе при сборке
будут использованы новые версии).

> Или собирать пакет, в котором будет содержимое
> hasher/chroot/usr/src/kernel/patches/. Можно будет собрать такое же
> ядро.

Каким образом - руками?

> > 2) Использование при сборке ядра слишком новых пакетов с патчами также
> > может привести к возникновению неприятных проблем.  Патчи для новой
> > версии ядра довольно часто подходят и к старым версиям, но в новых
> > пакетах kernel-fix-* могут быть удалены патчи, которые были нужны для
> > старых версий ядра - в результате ядро, собранное по какой-то причине
> > с таким новым kernel-fix-*, не будет содержать нужных исправлений.
> > 
> > Для предотвращения таких ситуаций можно явно объявлять версии ядер, к
> > которым подходят патчи, например, добавив в пакеты с патчами Provides
> > вида kernel-fix-core(2.4.29), kernel-fix-core(2.6.12).  При переходе
> Может kernel-fix-core(2.6.12-altN)?

Тогда уж kernel-fix-core(2.6.12-std26-altN).  Но это получится
опять-таки явное прописывание версий всех патчей, только не в
spec-файле kernel-image-*, а по всем использованным пакетам с патчами.
Кроме того, пропадает возможность собрать свой вариант ядра на базе
имеющихся kernel-{fix,feat}-*, не трогая эти пакеты.

Кстати, устаревшие пакеты kernel-image-* можно обнаружить при
автоматической пересборке, даже если до действительной несобираемости
дело ещё не дошло - по несовпадению исходного и пересобранного src.rpm
(сейчас отличается только %description, в случае автоматического
проставления зависимостей на пакеты с патчами будут ещё и различия в
BuildRequires).  Хотя будет множество ложных срабатываний (например,
все пакеты с ядрами 2.4.x будут объявлены устаревшими после обновления
ядер 2.6.x, поскольку многие пакеты с патчами для этих ядер общие).
Так что такую проверку ввести не получится (ну разве что где-нибудь
выкладывать результаты для информации, но без рассылки спама).  Или же
придётся распилить пакеты с патчами на отдельные для 2.4 и 2.6 (но
сколько же тогда будет этих пакетов...).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] [RFC] strict BuildRequires for kernel patches

[Evgeny Sinelnikov]

[-- Attachment #1: Type: text/plain, Size: 5497 bytes --]

В сообщении от Воскресенье 10 Июль 2005 23:01 Sergey Vlasov написал(a):
> On Sun, Jul 10, 2005 at 09:10:43PM +0300, Alex Yustasov wrote:
> > On Sun, Jul 10, 2005 at 08:55:51PM +0400, Sergey Vlasov wrote:
> > > Я вишу два варианта борьбы с этим безобразием:
> > >
> > > - либо явно прописывать в spec-файлах ядер используемые версии пакетов
> > >   с патчами (неудобно);
> > >
> > > - либо брать текущие версии пакетов с патчами на момент сборки пакета
> > >   с ядром (предполагая, что мантейнер соберёт ядро с правильными
> > >   патчами, а после этого src.rpm не будет пересобираться).

- либо действительно сохранять набор патчей для всех поддерживаемых ядер, 
а не только веток. Насколько я понимаю механизм указывающий на принадлежность 
патчей в {feat,fix}-пакетах веткам:
%source 01      2.4.x.patch                      2.4
%source 51      2.6.x.patch                      2.6
несложно расширить до указания принадлежности ядру:
%source 01      2.4.x.patch                      2.4
%source 21      2.4.27.patch                    2.4.27
%source 31      2.4.29.patch                    2.4.29
%source 51      2.6.x.patch                      2.6
%source 61      2.6.10.patch                    2.6.10
Это решение даёт возможность сборки некоторого набора текущих поддерживаемых 
версий ядер на одних и тех же {feat,fix}-пакетах. При этом не отменяется 
текущая схема ведения патчей по веткам. В этом случае вместо выбрасывания  
патча ветки (2.6, например), устаревшего для последней версии ядра, он будет 
перенесён список прямо указывающий на ядра с которыми он можем быть собран 
(2.6.9, 2.6.10). Кроме того такой подход позволит обеспечить возможность 
введения патчей "с четвёртой цифрой", которые сразу должны указывать на 
версию ядра, а не ветки и не будут смешаны в общую кучу исправлений.

> > Может еще для ядра, которое пошло в сизиф,  где-нибудь сохранять набор
> > патчей, с которыми оно было собрано?
>
> Версии патчей, использованные при сборке, сейчас пишутся в
> %description; старые версии патчей можно вытащить из kernel CVS (за
> исключением нескольких пакетов, собирающихся "левым" образом).
> Естественно, чтобы собрать в hasher именно старое ядро, нужно
> использовать соответствующий старый репозиторий (в частности, не
> содержащий более новых пакетов kernel-{fix,feat}-* - иначе при сборке
> будут использованы новые версии).

По моему, этот способ не удобен, тем более не представляю себе возможным вести 
на таком репозитории реальной работы, требующей не только старого набора 
патчей. Например, текущая стабильная (тестовая) версия RTAI (aka vesuvio - 
3.1r2) не собирается на ядрах выше 2.6.10. При этом достаточно не удобно 
брать (а самое главное следить за актуальностью)  старых версий fix-патчей из 
kernel CVS с текущими.

> > Или собирать пакет, в котором будет содержимое
> > hasher/chroot/usr/src/kernel/patches/. Можно будет собрать такое же
> > ядро.
>
> Каким образом - руками?
>
> > > 2) Использование при сборке ядра слишком новых пакетов с патчами также
> > > может привести к возникновению неприятных проблем.  Патчи для новой
> > > версии ядра довольно часто подходят и к старым версиям, но в новых
> > > пакетах kernel-fix-* могут быть удалены патчи, которые были нужны для
> > > старых версий ядра - в результате ядро, собранное по какой-то причине
> > > с таким новым kernel-fix-*, не будет содержать нужных исправлений.
> > >
> > > Для предотвращения таких ситуаций можно явно объявлять версии ядер, к
> > > которым подходят патчи, например, добавив в пакеты с патчами Provides
> > > вида kernel-fix-core(2.4.29), kernel-fix-core(2.6.12).  При переходе
[skip]

Возможно вариант, предложенный выше, даст более гибкое решение, чем макросы: 
%supported_kernel_versions и %require_patches_for_version. Хотя такие макросы 
могли бы дать формализацию, упомянутого выше списка поддерживаемых ядер, на 
уровне зависимостей. В любом случае такого рода жесткие зависимости будут 
полезны.

> >
> > Может kernel-fix-core(2.6.12-altN)?
>
> Тогда уж kernel-fix-core(2.6.12-std26-altN).  Но это получится
> опять-таки явное прописывание версий всех патчей, только не в
> spec-файле kernel-image-*, а по всем использованным пакетам с патчами.
> Кроме того, пропадает возможность собрать свой вариант ядра на базе
> имеющихся kernel-{fix,feat}-*, не трогая эти пакеты.
>
> Кстати, устаревшие пакеты kernel-image-* можно обнаружить при
> автоматической пересборке, даже если до действительной несобираемости
> дело ещё не дошло - по несовпадению исходного и пересобранного src.rpm
> (сейчас отличается только %description, в случае автоматического
> проставления зависимостей на пакеты с патчами будут ещё и различия в
> BuildRequires).  Хотя будет множество ложных срабатываний (например,
> все пакеты с ядрами 2.4.x будут объявлены устаревшими после обновления
> ядер 2.6.x, поскольку многие пакеты с патчами для этих ядер общие).
> Так что такую проверку ввести не получится (ну разве что где-нибудь
> выкладывать результаты для информации, но без рассылки спама).  Или же
> придётся распилить пакеты с патчами на отдельные для 2.4 и 2.6 (но
> сколько же тогда будет этих пакетов...).

Они сейчас уже распилены внутри соответствующих пакетов (см. выше). Или это 
другое? Уже сейчас, насколько я понимаю, по kversion из kernel-image на этапе 
сборки можно вычленить нужный набор 2.4 и 2.6 патчей из kernel-{fix,feat}. 
Повторюсь. Если расширить этот выбор по возможности указания конкретной 
версии ядра, то это не будет ли решением проблемы?

-- 
Sin

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [d-kernel] [RFC] strict BuildRequires for kernel patches

[Alex Yustasov]

On Sun, Jul 10, 2005 at 11:01:17PM +0400, Sergey Vlasov wrote:
> On Sun, Jul 10, 2005 at 09:10:43PM +0300, Alex Yustasov wrote:
> > On Sun, Jul 10, 2005 at 08:55:51PM +0400, Sergey Vlasov wrote:
> > > Я вишу два варианта борьбы с этим безобразием:
> > > 
> > > - либо явно прописывать в spec-файлах ядер используемые версии пакетов
> > >   с патчами (неудобно);
> > > 
> > > - либо брать текущие версии пакетов с патчами на момент сборки пакета
> > >   с ядром (предполагая, что мантейнер соберёт ядро с правильными
> > >   патчами, а после этого src.rpm не будет пересобираться).
Может скрипт, типа add_changelog, который будет в корне cvs и добавляет в
spec-файл ядра список с нужными версиями пакетов feat/fix, запускается
мантейнером ядра, полученный spec выкладывается в cvs и сизиф, в
sisyphus_check проверка на обязательность этой записи в spec ядра.
Различные типы сборок должны проверять соответствие установленных патчей с
этой записью, если она есть; если записи нет, то собирать из того что
доступно.
> > Может еще для ядра, которое пошло в сизиф,  где-нибудь сохранять набор
> > патчей, с которыми оно было собрано?
> 
> Версии патчей, использованные при сборке, сейчас пишутся в
> %description; старые версии патчей можно вытащить из kernel CVS (за
> исключением нескольких пакетов, собирающихся "левым" образом).
> Естественно, чтобы собрать в hasher именно старое ядро, нужно
> использовать соответствующий старый репозиторий (в частности, не
> содержащий более новых пакетов kernel-{fix,feat}-* - иначе при сборке
> будут использованы новые версии).
> 
> > Или собирать пакет, в котором будет содержимое
> > hasher/chroot/usr/src/kernel/patches/. Можно будет собрать такое же
> > ядро.
> 
> Каким образом - руками?
Вместо BuildRequires: %get_patch_list
BuildRequires: kernel-patches
А какие есть причины пересобирать src.rpm, кроме проверки заброшенности
ядра и чего-то типа
http://lists.altlinux.ru/pipermail/sisyphus/2005-March/055405.html

Re: [d-kernel] [RFC] strict BuildRequires for kernel patches

[Michael Shigorin]

On Sun, Jul 10, 2005 at 09:10:43PM +0300, Alex Yustasov wrote:
> Может еще для ядра, которое пошло в сизиф,  где-нибудь
> сохранять набор патчей, с которыми оно было собрано?

Кому надо -- и так держат sisyphus snapshots.  Решает эту
(не совсем... когда ежедневные недоступны) и ещё вагон проблем.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[d-kernel] А давайте ещё...

[Anton D. Kachalov]

...ещё добавим макросы по сборке ядер под разные рахитектуры. Сейчас это
немного затормаживает появление x86_64 ядра как оно должно быть "по инструкции".
А ещё нужно расширять спеки на тему ExclusiveArch. 
Вопрос с многоарчностью я уже поднимал несколько раз, даже что-то
предлагал, но особого оживления не возникло. В пятницу Сизиф потолстел на
добрых пол гига, вместив в себя небольшой набор пакетов под x86_64.

--
mouse

Re: [d-kernel] А давайте ещё...

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

On Sun, Jul 10, 2005 at 10:19:05PM +0400, Anton D. Kachalov wrote:
> ...ещё добавим макросы по сборке ядер под разные рахитектуры. Сейчас это
> немного затормаживает появление x86_64 ядра как оно должно быть "по инструкции".
> А ещё нужно расширять спеки на тему ExclusiveArch. 

Причём в ядре нужно писать в ExclusiveArch только те варианты
архитектур, для которых есть файлы конфигурации.  Сейчас можно
пересобрать kernel-image-* с --target pentium4 или ещё каким-то другим
вариантом, но ожидаемого результата это не даст - лучше уж явно это
запретить.

В kernel-modules-* независимо от того, что указано в --target,
оптимизация и набор команд получатся те, которые были использованы при
сборке соответствующего ядра.  Можно ли тут сделать жёсткую привязку,
чтобы не создавать пакетов с "неправильной" архитектурой - надо
подумать.  Хотя любителей такой оптимизации можно и проигнорировать...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] kernel arch

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

On Sun, Jul 10, 2005 at 11:12:41PM +0400, Sergey Vlasov wrote:
> Причём в ядре нужно писать в ExclusiveArch только те варианты
> архитектур, для которых есть файлы конфигурации.  Сейчас можно
> пересобрать kernel-image-* с --target pentium4 или ещё каким-то
> другим вариантом, но ожидаемого результата это не даст - лучше
> уж явно это запретить.

Заодно будет напоминанием, что когда-то (к 3.1?) хорошо бы это
пофиксить?

> Хотя любителей такой оптимизации можно и проигнорировать...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]