Re: [gentoo-dev] [PATCH] ruby-ng.eclass: drop support for jruby
On Thu, 2019-07-18 at 08:43 -0400, Brian Evans wrote: > > While I get it is no longer needed, java-utils-2 has had EAPI 7 > enabled > since December 2018. Just saying. I guess that tells you when I started working on this patchset. :-( I've updated the commit message. Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] CPU_FLAGS_X86: Introduce 'sha' flag
On Thu, 2019-07-18 at 17:53 +0100, Dirkjan Ochtman wrote: > On Thu, Jul 18, 2019, 15:53 Michał Górny wrote: > > > Introduce 'sha' flag that corresponds to SHA-NI instruction set. > > This has two potential users, and is present in git version > > of cpuid2cpuflags (pending release once the flag is added). > > > > A bit of bikeshedding: as I understand it, SHA-NI covers SHA-1 and SHA-256, > but not SHA-3 or some of the other SHA-2 variants. Maybe name it sha-ni or > sha_ni to be more accurate? > We already name AES-NI 'aes', so naming SHA-NI 'sha' follows suit. Besides, unless I'm mistaken NI stands for 'new instructions', so I don't see how that would be relevant to SHA algorithms supported. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] CPU_FLAGS_X86: Introduce 'sha' flag
On Thu, Jul 18, 2019, 15:53 Michał Górny wrote: > Introduce 'sha' flag that corresponds to SHA-NI instruction set. > This has two potential users, and is present in git version > of cpuid2cpuflags (pending release once the flag is added). > A bit of bikeshedding: as I understand it, SHA-NI covers SHA-1 and SHA-256, but not SHA-3 or some of the other SHA-2 variants. Maybe name it sha-ni or sha_ni to be more accurate? >
Re: [gentoo-dev] [PATCH] CPU_FLAGS_X86: Introduce 'sha' flag
On Thu, Jul 18, 2019 at 7:53 AM Michał Górny wrote: > > Introduce 'sha' flag that corresponds to SHA-NI instruction set. > This has two potential users, and is present in git version > of cpuid2cpuflags (pending release once the flag is added). Ack
[gentoo-dev] [PATCH] CPU_FLAGS_X86: Introduce 'sha' flag
Introduce 'sha' flag that corresponds to SHA-NI instruction set. This has two potential users, and is present in git version of cpuid2cpuflags (pending release once the flag is added). Signed-off-by: Michał Górny --- profiles/desc/cpu_flags_x86.desc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/profiles/desc/cpu_flags_x86.desc b/profiles/desc/cpu_flags_x86.desc index 35ca08b18700..d891398e7a60 100644 --- a/profiles/desc/cpu_flags_x86.desc +++ b/profiles/desc/cpu_flags_x86.desc @@ -1,4 +1,4 @@ -# Copyright 1999-2015 Gentoo Foundation. +# Copyright 1999-2019 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # Whenever the flag name does not correspond to /proc/cpuinfo flags, @@ -19,6 +19,7 @@ mmxext - Use the Extended MMX instruction set (a subset of SSE) ([mmxext] or [ss padlock - Use VIA padlock instructions ([phe] in cpuinfo) pclmul - Use Carry-less Multiplication instructions ([pclmulqdq] in cpuinfo) popcnt - Enable popcnt instruction support ([abm] or [popcnt] in cpuinfo) +sha - Use the SHA-NI instruction set sse - Use the SSE instruction set sse2 - Use the SSE2 instruction set sse3 - Use the SSE3 instruction set ([pni] in cpuinfo, NOT ssse3) -- 2.22.0
Re: [gentoo-dev] [PATCH] ruby-ng.eclass: drop support for jruby
On 7/18/2019 3:41 AM, gra...@gentoo.org wrote: > From: Hans de Graaff > > jruby has been removed from the tree for quite some time and is not > used at all anymore in ebuilds. This also drops an inherit of > java-utils-2 which blocks updating to EAPI 7. While I get it is no longer needed, java-utils-2 has had EAPI 7 enabled since December 2018. Just saying. Brian
[gentoo-dev] Re: News item about interoperability restrictions of >=net-p2p/syncthing-1.2.0
On 2019-07-18 11:12, Kristian Fiskerstrand wrote: > Should we be more specific as to how not to enable it here? is it a > USE-flag? does it require a package mask for newer versions if it is > always used for the newer ones? Good point, this should explicitly say "do not emerge new versions". My own thoughts on the matter have been that since we are now in the process of stabilising syncthing-1.1.4 (i.e. the latest version which does not force the use of large blocks) and that I do not intend to push the 1.2.0 ebuild until stabilisation has been concluded, it would be up to individual users to mask newer versions should they insist on using ~arch ebuilds. > Also cluster immediately made me think of server<>client relationship > and this only affecting server side, which probably doesn't fit well > with syncthing, but admittedly I don't use it so not familiar with the > nomenclature. I guess it is a bit subjective and/or based on one's experience, in my case "cluster" brings to mind a cluster of peers. Anyway, this is the wording from the official upstream statement so I would rather not change it unless there is a good reason for it - like the Gentoo-specific clarification you have suggested above. PS. For the record, I have already published this news item (a couple of hours ahead of schedule I am afraid, I didn't remember the exact time I submitted the RFC) so I'll include your comments in the second revision. -- MS
[gentoo-dev] [PATCH 3/3] cvs.eclass: Add proper EAPI conditional, drop EAPIs 0 to 3.
---
eclass/cvs.eclass | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/eclass/cvs.eclass b/eclass/cvs.eclass
index 8c9b41f586f3..ff23bd9df496 100644
--- a/eclass/cvs.eclass
+++ b/eclass/cvs.eclass
@@ -4,6 +4,7 @@
# @ECLASS: cvs.eclass
# @MAINTAINER:
# vap...@gentoo.org (and anyone who wants to help)
+# @SUPPORTED_EAPIS: 4 5 6 7
# @BLURB: This eclass provides generic cvs fetching functions
# @DESCRIPTION:
# This eclass provides the generic cvs fetching functions. To use this from an
@@ -185,10 +186,14 @@ if [[ ${ECVS_AUTH} == "ext" ]] ; then
DEPEND+=" net-misc/openssh"
fi
+case ${EAPI:-0} in
+ 4|5|6) ;;
+ 7) BDEPEND="${DEPEND}"; DEPEND="" ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} is not supported" ;;
+esac
+
# called from cvs_src_unpack
cvs_fetch() {
- has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
-
# Make these options local variables so that the global values are
# not affected by modifications in this function.
--
2.22.0
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH 1/3] cvs.eclass: Remove support for running under sudo.
This neither works, nor is it used in the tree.
Signed-off-by: Ulrich Müller
---
eclass/cvs.eclass | 53 +++
1 file changed, 8 insertions(+), 45 deletions(-)
diff --git a/eclass/cvs.eclass b/eclass/cvs.eclass
index e2121f4724f2..128c065ebe78 100644
--- a/eclass/cvs.eclass
+++ b/eclass/cvs.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: cvs.eclass
@@ -174,22 +174,10 @@ inherit eutils
# Set this to get a clean copy when updating (passes the
# -C option to cvs update)
-# @ECLASS-VARIABLE: ECVS_RUNAS
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# Specifies an alternate (non-root) user to use to run cvs. Currently
-# b0rked and wouldn't work with portage userpriv anyway without
-# special magic.
-
-# : ${ECVS_RUNAS:=$(whoami)}
-
# add cvs to deps
# ssh is used for ext auth
-# sudo is used to run as a specified user
DEPEND="dev-vcs/cvs"
-[[ -n ${ECVS_RUNAS} ]] && DEPEND+=" app-admin/sudo"
-
if [[ ${ECVS_AUTH} == "ext" ]] ; then
#default to ssh
[[ -z ${CVS_RSH} ]] && export CVS_RSH="ssh"
@@ -250,15 +238,6 @@ cvs_fetch() {
ECVS_UP_OPTS+=" -D ${ECVS_DATE}"
fi
- # It would be easiest to always be in "run-as mode", logic-wise,
- # if sudo didn't ask for a password even when sudo'ing to `whoami`.
-
- if [[ -z ${ECVS_RUNAS} ]] ; then
- run=""
- else
- run="sudo -u ${ECVS_RUNAS}"
- fi
-
# Create the top dir if needed
if [[ ! -d ${ECVS_TOP_DIR} ]] ; then
@@ -274,7 +253,7 @@ cvs_fetch() {
debug-print "${FUNCNAME}: checkout mode. creating cvs directory"
addwrite /foobar
addwrite /
- ${run} mkdir -p "/${ECVS_TOP_DIR}"
+ mkdir -p "/${ECVS_TOP_DIR}"
export SANDBOX_WRITE="${SANDBOX_WRITE//:\/foobar:\/}"
fi
@@ -287,11 +266,6 @@ cvs_fetch() {
# Disable the sandbox for this dir
addwrite "${ECVS_TOP_DIR}"
- # Chown the directory and all of its contents
- if [[ -n ${ECVS_RUNAS} ]] ; then
- ${run} chown -R "${ECVS_RUNAS}" "/${ECVS_TOP_DIR}"
- fi
-
# Determine the CVS command mode (checkout or update)
if [[ ! -d ${ECVS_TOP_DIR}/${ECVS_LOCALNAME}/CVS ]] ; then
mode=checkout
@@ -313,13 +287,13 @@ cvs_fetch() {
# Switch servers automagically if needed
if [[ ${mode} == "update" ]] ; then
cd "/${ECVS_TOP_DIR}/${ECVS_LOCALNAME}"
- local oldserver=$(${run} cat CVS/Root)
+ local oldserver=$(cat CVS/Root)
if [[ ${server} != "${oldserver}" ]] ; then
einfo "Changing the CVS server from ${oldserver} to
${server}:"
debug-print "${FUNCNAME}: Changing the CVS server from
${oldserver} to ${server}:"
einfo "Searching for CVS directories ..."
- local cvsdirs=$(${run} find . -iname CVS -print)
+ local cvsdirs=$(find . -iname CVS -print)
debug-print "${FUNCNAME}: CVS directories found:"
debug-print "${cvsdirs}"
@@ -327,7 +301,7 @@ cvs_fetch() {
local x
for x in ${cvsdirs} ; do
debug-print "In ${x}"
- ${run} echo "${server}" > "${x}/Root"
+ echo "${server}" > "${x}/Root"
done
fi
fi
@@ -336,9 +310,6 @@ cvs_fetch() {
# mess with ~/.cvspass
touch "${T}/cvspass"
export CVS_PASSFILE="${T}/cvspass"
- if [[ -n ${ECVS_RUNAS} ]] ; then
- chown "${ECVS_RUNAS}" "${T}/cvspass"
- fi
# The server string with the password in it, for login (only used for
pserver)
cvsroot_pass=":${connection}:${ECVS_USER}:${ECVS_PASS}@${ECVS_SERVER}"
@@ -352,9 +323,9 @@ cvs_fetch() {
fi
# Commands to run
- cmdlogin=( ${run} ${ECVS_CVS_COMMAND} -d "${cvsroot_pass}" login )
- cmdupdate=( ${run} ${ECVS_CVS_COMMAND} -d "${cvsroot_nopass}" update
${ECVS_UP_OPTS} ${ECVS_LOCALNAME} )
- cmdcheckout=( ${run} ${ECVS_CVS_COMMAND} -d "${cvsroot_nopass}"
checkout ${ECVS_CO_OPTS} ${ECVS_MODULE} )
+ cmdlogin=( ${ECVS_CVS_COMMAND} -d "${cvsroot_pass}" login )
+ cmdupdate=( ${ECVS_CVS_COMMAND} -d "${cvsroot_nopass}" update
${ECVS_UP_OPTS} ${ECVS_LOCALNAME} )
+ cmdcheckout=( ${ECVS_CVS_COMMAND} -d "${cvsroot_nopass}" checkout
${ECVS_CO_OPTS} ${ECVS_MODULE} )
# Execute commands
@@ -482,13 +453,6 @@ EOF
unset DISPLAY
fi
fi
-
- # Restore ownership. Not sure why this is needed, but someone
- # added it in
[gentoo-dev] [PATCH 2/3] cvs.eclass: Remove support for PATCHES.
Not used in the tree, and broken in EAPI 7.
Signed-off-by: Ulrich Müller
---
eclass/cvs.eclass | 15 ---
1 file changed, 15 deletions(-)
diff --git a/eclass/cvs.eclass b/eclass/cvs.eclass
index 128c065ebe78..8c9b41f586f3 100644
--- a/eclass/cvs.eclass
+++ b/eclass/cvs.eclass
@@ -15,8 +15,6 @@
if [[ -z ${_CVS_ECLASS} ]]; then
_CVS_ECLASS=1
-inherit eutils
-
# TODO:
# Implement more auth types (gserver?, kserver?)
@@ -524,19 +522,6 @@ cvs_src_unpack() {
debug-print "${FUNCNAME}: removing empty CVS directory
${ECVS_LOCALNAME}"
rm -rf "${ECVS_TOP_DIR}/${ECVS_LOCALNAME}"
fi
-
- # Implement some of base_src_unpack's functionality; note however
- # that base.eclass may not have been inherited!
- if [[ -n ${PATCHES} ]] ; then
- debug-print "${FUNCNAME}: PATCHES=${PATCHES}, S=${S},
autopatching"
- cd "${S}"
- epatch ${PATCHES}
- # Make sure we don't try to apply patches more than once,
- # since cvs_src_unpack is usually called several times from
- # e.g. kde-source_src_unpack
- export PATCHES=""
- fi
-
einfo "CVS module ${ECVS_MODULE} is now in ${WORKDIR}"
}
--
2.22.0
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH 0/3] cvs.eclass update
This removes some broken and unused code, and adds proper EAPI support. Ulrich Müller (3): cvs.eclass: Remove support for running under sudo. cvs.eclass: Remove support for PATCHES. cvs.eclass: Add proper EAPI conditional, drop EAPIs 0 to 3. eclass/cvs.eclass | 77 +-- 1 file changed, 15 insertions(+), 62 deletions(-) -- 2.22.0 signature.asc Description: PGP signature
[gentoo-dev] Re: News item about interoperability restrictions of >=net-p2p/syncthing-1.2.0
On 7/15/19 1:39 PM, Marek Szuba wrote: > 2019-07-18-syncthing-update-incompatibility.en.txt > > Title: Syncthing 1.2.0 and newer do not interoperate with 0.14.45 and older > Author: Marek Szuba > Posted: 2019-07-18 > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: net-p2p/syncthing > > Starting with version 1.2.0, Syncthing always uses large, variable-sized, > blocks to index and transfer files larger than 256 MiB [1]. Syncthing > version 0.14.45 and older will initially appear to accept files scanned > with large blocks, but will later panic during some internal file > operations. Do NOT enable large blocks in clusters with devices still > on v0.14.45 or older, Should we be more specific as to how not to enable it here? is it a USE-flag? does it require a package mask for newer versions if it is always used for the newer ones? Also cluster immediately made me think of server<>client relationship and this only affecting server side, which probably doesn't fit well with syncthing, but admittedly I don't use it so not familiar with the nomenclature. > e.g. Debian Stretch servers using official packages. > > [1] https://docs.syncthing.net/advanced/folder-uselargeblocks.html -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH 2/2] ruby-ng.eclass: future proof EAPI checks
From: Hans de Graaff
Explicitly list old EAPIs but use a wildcard for the latest EAPI, so
that these changes will also be used by default in newer EAPIs.
Signed-off-by: Hans de Graaff
---
eclass/ruby-ng.eclass | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index facb0bea95d7..edf17fb94746 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -416,7 +416,7 @@ _ruby_apply_patches() {
fi
done
;;
- 6)
+ *)
if [[ -n ${RUBY_PATCHES[@]} ]]; then
eqawarn "RUBY_PATCHES is no longer supported, use
PATCHES instead"
fi
@@ -448,7 +448,9 @@ ruby-ng_src_prepare() {
# Handle PATCHES and user supplied patches via the default phase
case ${EAPI} in
- 6)
+ 4|5)
+ ;;
+ *)
_ruby_invoke_environment all default
;;
esac
--
2.21.0
[gentoo-dev] [PATCH 1/2] ruby-ng.eclass: drop support for EAPI 2 and EAPI 3
From: Hans de Graaff
Signed-off-by: Hans de Graaff
---
eclass/ruby-ng.eclass | 43 ++-
1 file changed, 10 insertions(+), 33 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index 90c36cd86e40..facb0bea95d7 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -8,7 +8,7 @@
# Author: Diego E. Pettenò
# Author: Alex Legler
# Author: Hans de Graaff
-# @SUPPORTED_EAPIS: 2 3 4 5 6
+# @SUPPORTED_EAPIS: 4 5 6
# @BLURB: An eclass for installing Ruby packages with proper support for
multiple Ruby slots.
# @DESCRIPTION:
# The Ruby eclass is designed to allow an easier installation of Ruby packages
@@ -68,7 +68,7 @@
local inherits=""
case ${EAPI} in
- 2|3|4|5)
+ 4|5)
inherits="eutils"
;;
esac
@@ -78,9 +78,8 @@ inherit ${inherits} java-utils-2 multilib toolchain-funcs
ruby-utils
EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_test
src_install pkg_setup
case ${EAPI} in
- 0|1)
+ 0|1|2|3)
die "Unsupported EAPI=${EAPI} (too old) for ruby-ng.eclass" ;;
- 2|3) ;;
4|5|6)
# S is no longer automatically assigned when it doesn't exist.
S="${WORKDIR}"
@@ -302,40 +301,21 @@ IUSE+=" $(ruby_get_use_targets)"
if [[ ${RUBY_OPTIONAL} != yes ]]; then
DEPEND="${DEPEND} $(ruby_implementations_depend)"
RDEPEND="${RDEPEND} $(ruby_implementations_depend)"
-
- case ${EAPI:-0} in
- 4|5|6)
- REQUIRED_USE+=" || ( $(ruby_get_use_targets) )"
- ;;
- esac
+ REQUIRED_USE+=" || ( $(ruby_get_use_targets) )"
fi
_ruby_invoke_environment() {
old_S=${S}
- case ${EAPI} in
- 4|5|6)
- if [ -z "${RUBY_S}" ]; then
- sub_S=${P}
- else
- sub_S=${RUBY_S}
- fi
- ;;
- *)
- sub_S=${S#${WORKDIR}/}
- ;;
- esac
+ if [ -z "${RUBY_S}" ]; then
+ sub_S=${P}
+ else
+ sub_S=${RUBY_S}
+ fi
# Special case, for the always-lovely GitHub fetches. With this,
# we allow the star glob to just expand to whatever directory it's
# called.
if [[ "${sub_S}" = *"*"* ]]; then
- case ${EAPI} in
- 2|3)
- #The old method of setting S depends on
undefined package
- # manager behaviour, so encourage upgrading to
EAPI=4.
- eqawarn "Using * expansion of S is deprecated.
Use EAPI and RUBY_S instead."
- ;;
- esac
pushd "${WORKDIR}"/all &>/dev/null || die
# use an array to trigger filename expansion
# fun fact: this expansion fails in src_unpack() but the
original
@@ -425,7 +405,7 @@ ruby-ng_src_unpack() {
_ruby_apply_patches() {
case ${EAPI} in
- 2|3|4|5)
+ 4|5)
for patch in "${RUBY_PATCHES[@]}"; do
if [ -f "${patch}" ]; then
epatch "${patch}"
@@ -524,8 +504,6 @@ _each_ruby_check_install() {
# we have a Mach-O object here
[[ ${CHOST} == *-darwin ]] && scancmd=scanmacho
- has "${EAPI}" 2 && ! use prefix && EPREFIX=
-
local libruby_basename=$(${RUBY} -rrbconfig -e 'puts
RbConfig::CONFIG["LIBRUBY_SO"]')
local libruby_soname=$(basename $(${scancmd} -F "%S#F" -qS
"${EPREFIX}/usr/$(get_libdir)/${libruby_basename}") 2>/dev/null)
local sitedir=$(${RUBY} -rrbconfig -e 'puts
RbConfig::CONFIG["sitedir"]')
@@ -578,7 +556,6 @@ ruby_rbconfig_value() {
# Installs the specified file(s) into the sitelibdir of the Ruby interpreter
in ${RUBY}.
doruby() {
[[ -z ${RUBY} ]] && die "\$RUBY is not set"
- has "${EAPI}" 2 && ! use prefix && EPREFIX=
( # don't want to pollute calling env
sitelibdir=$(ruby_rbconfig_value 'sitelibdir')
insinto ${sitelibdir#${EPREFIX}}
--
2.21.0
[gentoo-dev] [PATCH] ruby-ng.eclass: drop support for jruby
From: Hans de Graaff
jruby has been removed from the tree for quite some time and is not
used at all anymore in ebuilds. This also drops an inherit of
java-utils-2 which blocks updating to EAPI 7.
---
eclass/ruby-ng.eclass | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index 21cbc5d99595..d3264743c89a 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -73,7 +73,7 @@ case ${EAPI} in
;;
esac
-inherit ${inherits} java-utils-2 multilib toolchain-funcs ruby-utils
+inherit ${inherits} multilib toolchain-funcs ruby-utils
EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_test
src_install pkg_setup
@@ -402,8 +402,6 @@ ruby-ng_pkg_setup() {
# before doing anything; by leaving the parameters empty we know
# it's a special case.
_ruby_each_implementation
-
- has ruby_targets_jruby ${IUSE} && use ruby_targets_jruby &&
java-pkg_setup-vm
}
# @FUNCTION: ruby-ng_src_unpack
@@ -629,9 +627,6 @@ ruby_get_implementation() {
local ruby=${RUBY:-$(type -p ruby 2>/dev/null)}
case $(${ruby} --version) in
- *jruby*)
- echo "jruby"
- ;;
*rubinius*)
echo "rbx"
;;
@@ -713,11 +708,6 @@ ruby-ng_cucumber() {
;;
esac
- if [[ ${RUBY} == *jruby ]]; then
- ewarn "Skipping cucumber tests on JRuby (unsupported)."
- return 0
- fi
-
${RUBY} -S cucumber ${cucumber_params} "$@" || die "cucumber failed"
}
--
2.21.0
Re: [gentoo-dev] Last rites: mask ruby24-only slots of ruby packages for removal
On Wed, 2019-07-17 at 10:41 +0200, Hans de Graaff wrote: > # Hans de Graaff (2019-07-17) > # Mask ruby24-only slots for removal in 30 days. These slots do not > # have any reverse dependencies. Please migrate to or use a newer > slot. > > dev-ruby/webmock:2 webmock is still a dependency for dev-ruby/github_api so it has been removed from the removal mask. Thanks to ulm for fixing this. Hans signature.asc Description: This is a digitally signed message part
