[PATCH] gnu: emacs-consult: Add ‘emacs-ve

OpenSubmitted by Xinglu Chen.
Details
5 participants
  • Arun Isaac
  • Leo Prikler
  • Liliana Marie Prikler
  • Maxim Cournoyer
  • Xinglu Chen
Owner
unassigned
Severity
normal
X
X
Xinglu Chen wrote on 5 May 2021 15:26
(address . guix-patches@gnu.org)
bee27d4455c579e5762f3d8df8474c8cd1f20820.1620221003.git.public@yoctocell.xyz
* gnu/packages/emacs-xyz.scm (emacs-consult)[propagated-inputs]: Add
emacs-vertico.
---
emacs-vertico is an optional dependency so maybe there is a better way
deal with this. Splitting the package into multiple outputs might be a
better idea, but I don’t know how we would do that.

gnu/packages/emacs-xyz.scm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

Toggle diff (18 lines)
diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 1a640a53f3..92b3e6ce37 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -7579,7 +7579,8 @@ style, or as multiple word prefixes.")
     (build-system emacs-build-system)
     (propagated-inputs
      `(("emacs-flycheck" ,emacs-flycheck)
-       ("emacs-selectrum" ,emacs-selectrum)))
+       ("emacs-selectrum" ,emacs-selectrum)
+       ("emacs-vertico" ,emacs-vertico)))
     (home-page "https://github.com/minad/consult")
     (synopsis "Consulting completing-read")
     (description "This package provides various handy commands based on the

base-commit: 56e4d7204b0d4f83ab8cf4aab24199a9f8dc082c
-- 
2.31.1
L
L
Leo Prikler wrote on 5 May 2021 19:39
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
ae577b203f68d766d7dc8b89c3dd2ac5067c192d.camel@student.tugraz.at
Am Mittwoch, den 05.05.2021, 15:26 +0200 schrieb Xinglu Chen:
Toggle quote (5 lines)
> emacs-vertico is an optional dependency so maybe there is a better
> way
> deal with this. Splitting the package into multiple outputs might be
> a
> better idea, but I don’t know how we would do that.
This is certainly an interesting question. With other Emacs packages,
there is sometimes a contrib version, that adds "more", see e.g. org-
mode or telega. But those are tied closely to what upstream considers
contrib, so I don't think that applies here.

IIUC selectrum is likewise optional. Perhaps we should consider not
propagating optional inputs, but rather adding them as normal inputs –
so that byte compilation succeeds, but users won't be forced to have a
rather large elisp library as part of their profiles if it's not
needed.

I've CC'd Maxim to get their input on the matter, the patch otherwise
LGTM.

Regards,
Leo
X
X
Xinglu Chen wrote on 7 May 2021 16:23
Re: [bug#48237] [PATCH] gnu: emacs-consult: Add ‘emacs-ve
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87k0oa4o7h.fsf@yoctocell.xyz
On Wed, May 05 2021, Leo Prikler wrote:

Toggle quote (11 lines)
> Am Mittwoch, den 05.05.2021, 15:26 +0200 schrieb Xinglu Chen:
>> emacs-vertico is an optional dependency so maybe there is a better
>> way
>> deal with this. Splitting the package into multiple outputs might be
>> a
>> better idea, but I don’t know how we would do that.
> This is certainly an interesting question. With other Emacs packages,
> there is sometimes a contrib version, that adds "more", see e.g. org-
> mode or telega. But those are tied closely to what upstream considers
> contrib, so I don't think that applies here.

Yeah, Org has a separate contrib/ directory.

Toggle quote (6 lines)
> IIUC selectrum is likewise optional. Perhaps we should consider not
> propagating optional inputs, but rather adding them as normal inputs –
> so that byte compilation succeeds, but users won't be forced to have a
> rather large elisp library as part of their profiles if it's not
> needed.

I think this might be the best option.
X
X
Xinglu Chen wrote on 2 Jun 2021 17:32
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
871r9kl1tr.fsf@yoctocell.xyz
Ping! Maxim, any opinions?
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmC3pIAVHHB1YmxpY0B5
b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x5x54P/0sMS7K2TxMch0ZtmptNC572qeVV
+8padMD2G/9mPCfmRASEQoNYWbyz9/nqIlp4EgV1VH6WoQhbFGpT06G0TlW8Yt6H
h04BpLGR/5RcwvDbbimUO1SDwloIzr83CK7VAGFcednWI4oyxkHDmLgiTrwu4Q1S
7h1XOXVAG5+i7+PMX3AtR83jc4lp5Gj2H6sa3mTDK9C374Yb8bmL/9KzlpdPDRno
RNONZ32lZR1Nfr8AxErvibli1KbDKt7ISON7AMuPRcwHpvWLIiuyhp3KN0+AoMYx
RmE67ckp568+oTejU+Ccf8CNIOAzFVMJxkVl+88ddNFMFYC3tVfcZTkvAipoipoV
B+m6AfoOS8Gtjfvl0N2SfuhzkAQWi43q44QjdPWahxW/m9K05lMZS4003HmRD5z2
laqf7SH+AXTEnURb28OoytVkXzzumoqhEs6rRvUd3zw6YCHEhRU6yutsVZWZNJ7h
tVrnX7F45mQ6XcXzq2mnwHiL4BFxtCpO72Znbqzaj8BpWAYT65n44b2kvqcYT0oM
TXzUePOR0QRAuUUM7ijZTxGEwcIaNdrVFdSw1o3ccKXrzYBxY209xz+JV/KH2mEo
7HE2qjeIqLNF7iUoJNwWEB4NOkBBOSCzedgJuh3bL9pyh+6S6Ru7mOeDwjwez7To
p2l7lMHAx8eMiNDp
=h/12
-----END PGP SIGNATURE-----

A
A
Arun Isaac wrote on 11 Aug 2021 17:23
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87pmukuhsf.fsf@systemreboot.net
Hi all,

I actually think we should not add emacs-vertico to the
propagated-inputs, and remove emacs-flycheck and emacs-selectrum as
well. All these are optional dependencies, and we should leave it to the
user to install the ones they want. At least in this specific case, the
three packages (flycheck, selectrum and vertico) are the kind the user
would want to explicitly install. They aren't backend libraries that
ought to remain invisible to the user.

In fact, this is the version of emacs-consult I have installed in my
profile.

Toggle snippet (5 lines)
(package
(inherit emacs-consult)
(propagated-inputs `()))

Also, byte compilation works for me without any propagated inputs. Am I
missing something?

Regards,
Arun
-----BEGIN PGP SIGNATURE-----

iQFPBAEBCAA5FiEEf3MDQ/Lwnzx3v3nTLiXui2GAK7MFAmET63AbHGFydW5pc2Fh
Y0BzeXN0ZW1yZWJvb3QubmV0AAoJEC4l7othgCuz/uAIAMt6rb5VCBEloF14WDFz
Vw+svKm7D6pDTSPZLNudC5da7mbwKz9H36uXMKIsSzfayzv8YY+W9J+rWBvlpuYz
oCPXHPrI3plFlAgnDYwQ1iXDKPP4JXYedvWpEhPjiMlASBtJFs9lxUle+NY/brbi
TGyr77Nn7udx16+iBbgQ2lhno+Nd1tv8Z/aNI+CF53Yf+EwtK/QqpJB8Cesha0K9
6Ic0pI4Sy1u9kEoCgc+SKNVaCJXVCSw4RJbc+JVGkSvUmrDCy7F0U4k5DpB3xu1T
aey/QwhmjupD+lFnFhgOVABxP1obf8NllQABKTCxWCGdwxCf5KP4gWXTWGsEwb+5
k+8=
=aU7a
-----END PGP SIGNATURE-----

X
X
Xinglu Chen wrote on 6 Sep 2021 15:47
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87v93d24tx.fsf@yoctocell.xyz
On Wed, Aug 11 2021, Arun Isaac wrote:

Toggle quote (22 lines)
> Hi all,
>
> I actually think we should not add emacs-vertico to the
> propagated-inputs, and remove emacs-flycheck and emacs-selectrum as
> well. All these are optional dependencies, and we should leave it to the
> user to install the ones they want. At least in this specific case, the
> three packages (flycheck, selectrum and vertico) are the kind the user
> would want to explicitly install. They aren't backend libraries that
> ought to remain invisible to the user.
>
> In fact, this is the version of emacs-consult I have installed in my
> profile.
>
> --8<---------------cut here---------------start------------->8---
> (package
> (inherit emacs-consult)
> (propagated-inputs `()))
> --8<---------------cut here---------------end--------------->8---
>
> Also, byte compilation works for me without any propagated inputs. Am I
> missing something?

Another option would be to define package variants of ‘emacs-consult’,
that way we would have four packages:

* emacs-consult;
* emacs-consult-flycheck;
* emacs-consult-vertico; and
* emacs-consult.

WDYT?
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmE2HAoVHHB1YmxpY0B5
b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x5a7EP/jJKHMjdr7YXL2VWkx82GjajqsW8
4K5pAUJGZQ8qpJOFGdS6N0/CbHv0pwLzwyKsODpbLs4Uqj4UhlhBQWmCOSrIQEQJ
lTQ3C1Cl9WEeJO2AkUBfFanX8aMsZowFXezV5JXWYt7gGs5oSUF79tOF1xi2LwUb
d2bGvWcFnffjS5sUvpSWoDq2vQadDRCU4vVuFZJJmvdMGw0yjLTe9tMOH4kQOir+
yS5i+PbRleumCLnj4+ovSzJCOOJJpNydvfadTUq7vtV9a3RMh9GLmZN44YC57nie
X9L0VHeHVniBs/HzwW0BqgO/gDN6W6pfJD/C7aYTmnDa2+Ar2u2EluaHaBl/DeI5
gp27EcgB/Yca7uG3up2ZcwBVDcVEDzK6gCcNcXcGNO8xEekC9uzAPiHREJHq+W3K
xgqB90lfogU9rQ+eTzZpcd4W28j7MjNXBKoBMez6Tru8cVaI+7G+quslwvmCn6sX
12oLw/mgwHwKTi34obn3bbSOaI0fOP6oATzGbXyXa/1Wy2j7jyru3ww0reLhLVZD
ah8HATZi45jfeV2xvo1Q8PqTH/P3U6idOv9T5J0haNCDLELvi0Qbe4Nt59IsFUk4
zfcnXheUDVO+ehbi2rndK4Je3p334oPGw0CfVsirk1GOWSR/SqmHVHtN0j/acES6
eHAp7BFjTsJVAYHn
=wNmP
-----END PGP SIGNATURE-----

M
M
Maxim Cournoyer wrote on 6 Sep 2021 19:51
(name . Xinglu Chen)(address . public@yoctocell.xyz)
8735qhbnj7.fsf@gmail.com
Hello Arun,

Xinglu Chen <public@yoctocell.xyz> writes:

Toggle quote (15 lines)
> On Wed, Aug 11 2021, Arun Isaac wrote:
>
>> Hi all,
>>
>> I actually think we should not add emacs-vertico to the
>> propagated-inputs, and remove emacs-flycheck and emacs-selectrum as
>> well. All these are optional dependencies, and we should leave it to the
>> user to install the ones they want. At least in this specific case, the
>> three packages (flycheck, selectrum and vertico) are the kind the user
>> would want to explicitly install. They aren't backend libraries that
>> ought to remain invisible to the user.
>>
>> In fact, this is the version of emacs-consult I have installed in my
>> profile.

Guix packages typically come as featureful as possible unless there are
good reasons not too (to minimize the closure size, for example). In
this case, the added optional dependencies seem to have negligible
effect on the closure size, according to `guix size`; I'd be in favor to
keep the optional dependencies specified for that reason, unless there
are other considerations that I'm missing.

Toggle quote (8 lines)
> Another option would be to define package variants of ‘emacs-consult’,
> that way we would have four packages:
>
> * emacs-consult;
> * emacs-consult-flycheck;
> * emacs-consult-vertico; and
> * emacs-consult.

I would prefer not go that route (variants multiplication), especially
when the user already has a way to customize.

My 2 cents,

Maxim
L
L
Liliana Marie Prikler wrote on 6 Sep 2021 20:05
fd28931b2c8a997621958bed77802cc9ef24822c.camel@gmail.com
Am Montag, den 06.09.2021, 13:51 -0400 schrieb Maxim Cournoyer:
Toggle quote (26 lines)
> Hello Arun,
>
> Xinglu Chen <public@yoctocell.xyz> writes:
>
> > On Wed, Aug 11 2021, Arun Isaac wrote:
> >
> > > Hi all,
> > >
> > > I actually think we should not add emacs-vertico to the
> > > propagated-inputs, and remove emacs-flycheck and emacs-selectrum
> > > as well. All these are optional dependencies, and we should leave
> > > it to the user to install the ones they want. At least in this
> > > specific case, the three packages (flycheck, selectrum and
> > > vertico) are the kind the user would want to explicitly install.
> > > They aren't backend libraries that ought to remain invisible to
> > > the user.
> > >
> > > In fact, this is the version of emacs-consult I have installed in
> > > my profile.
>
> Guix packages typically come as featureful as possible unless there
> are good reasons not too (to minimize the closure size, for
> example). In this case, the added optional dependencies seem to have
> negligible effect on the closure size, according to `guix size`; I'd
> be in favor to keep the optional dependencies specified for that
> reason, unless there are other considerations that I'm missing.
While closure size is normally a good metric, with interpreted
languages like Emacs Lisp you have the added baggage of *propagating*
inputs, thereby installing stuff at user (or system) level, that the
user did not actually ask for. My personal take on those is to provide
them as inputs where necessary to compile, but not actually propagate
them where not necessary to run.

For example, an Emacs package might require emacs-dash to function at
all and might install some autocompletion stuff with emacs-autocomplete
or emacs-company (perhaps even both). emacs-dash absolutely must be
propagated, but unless you're already using autocomplete or company and
thus have them in your manifest, you probably don't want them to be
installed by emacs-foo. Does this make sense?
A
A
Arun Isaac wrote on 6 Sep 2021 22:34
(address . 48237@debbugs.gnu.org)
87ilzdl9yp.fsf@systemreboot.net
Hi all,

Toggle quote (4 lines)
> unless you're already using autocomplete or company and
> thus have them in your manifest, you probably don't want them to be
> installed by emacs-foo. Does this make sense?

I agree. Closure size isn't the right metric for this
case. emacs-vertico and emacs-selectrum aren't really optional
dependencies in the normal sense. The user would only want one of them
in their profile, and never both. Propagating both would rather be a
nuisance to the user.

Toggle quote (3 lines)
> I would prefer not go that route (variants multiplication), especially
> when the user already has a way to customize.

I agree. Variant multiplication would result in a minor combinatorial
explosion. emacs-vertico and emacs-selectrum are anyway the kind of
package a user would explicitly install in their profile.

Cheers!
Arun
-----BEGIN PGP SIGNATURE-----

iQFPBAEBCAA5FiEEf3MDQ/Lwnzx3v3nTLiXui2GAK7MFAmE2e04bHGFydW5pc2Fh
Y0BzeXN0ZW1yZWJvb3QubmV0AAoJEC4l7othgCuzsCIH/21N9ni9U2CfyoqUzpbE
8PgOI9NmUDcwaAs2LAL7WNQ2y5JENKjK3KW3BMcSyFfaM5/V9lEbK9XWi1StUllT
nLwMryayTG6ZQNds3FvLLhbyWECGqzhTifGpzJciIr/xWlStkhv23fa5iF2U5R70
Pdsm+zLcDSj7BJBKu6UD4cFPFPVs+dX+WzyLmMgcSc9FndhUU2kEyBXmdQDioqXt
eaPxtb3bjrvJu0OdJJbFdt1Ji9kT7lUTLA06NXUeMyMb6+Vl8Gzu2BQURx57xOzT
UPwrzlwE8BhVy/isGD9mhEfOJzdsYKTp4x8Tj95wYDoHqKc4p/+w8wU9URTJqXsg
iB0=
=5ouO
-----END PGP SIGNATURE-----

M
M
Maxim Cournoyer wrote on 7 Sep 2021 01:17
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87v93d8fa0.fsf@gmail.com
Hello,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

Toggle quote (34 lines)
> Am Montag, den 06.09.2021, 13:51 -0400 schrieb Maxim Cournoyer:
>> Hello Arun,
>>
>> Xinglu Chen <public@yoctocell.xyz> writes:
>>
>> > On Wed, Aug 11 2021, Arun Isaac wrote:
>> >
>> > > Hi all,
>> > >
>> > > I actually think we should not add emacs-vertico to the
>> > > propagated-inputs, and remove emacs-flycheck and emacs-selectrum
>> > > as well. All these are optional dependencies, and we should leave
>> > > it to the user to install the ones they want. At least in this
>> > > specific case, the three packages (flycheck, selectrum and
>> > > vertico) are the kind the user would want to explicitly install.
>> > > They aren't backend libraries that ought to remain invisible to
>> > > the user.
>> > >
>> > > In fact, this is the version of emacs-consult I have installed in
>> > > my profile.
>>
>> Guix packages typically come as featureful as possible unless there
>> are good reasons not too (to minimize the closure size, for
>> example). In this case, the added optional dependencies seem to have
>> negligible effect on the closure size, according to `guix size`; I'd
>> be in favor to keep the optional dependencies specified for that
>> reason, unless there are other considerations that I'm missing.
> While closure size is normally a good metric, with interpreted
> languages like Emacs Lisp you have the added baggage of *propagating*
> inputs, thereby installing stuff at user (or system) level, that the
> user did not actually ask for. My personal take on those is to provide
> them as inputs where necessary to compile, but not actually propagate
> them where not necessary to run.

Thanks for explaining. It makes sense, although there would probably be
exceptions. I'm thinking for example about emacs-elpy, for which not
propagating optional dependencies would render the package nearly
useless out of the box.

Toggle quote (8 lines)
> For example, an Emacs package might require emacs-dash to function at
> all and might install some autocompletion stuff with
> emacs-autocomplete or emacs-company (perhaps even both). emacs-dash
> absolutely must be propagated, but unless you're already using
> autocomplete or company and thus have them in your manifest, you
> probably don't want them to be installed by emacs-foo. Does this make
> sense?

From a purity sense, yes, but propagating autocomplete or company
wouldn't cause any problems in practice, no?

As another possible option to explore to avoid propagation could be to
develop a runpath equivalent for the Emacs compiled format (.elc). More
work, but more definitive!

Thank you,

Maxim
M
M
Maxim Cournoyer wrote on 7 Sep 2021 01:18
(name . Arun Isaac)(address . arunisaac@systemreboot.net)
87r1e18f8o.fsf@gmail.com
Hello,

Arun Isaac <arunisaac@systemreboot.net> writes:

Toggle quote (12 lines)
> Hi all,
>
>> unless you're already using autocomplete or company and
>> thus have them in your manifest, you probably don't want them to be
>> installed by emacs-foo. Does this make sense?
>
> I agree. Closure size isn't the right metric for this
> case. emacs-vertico and emacs-selectrum aren't really optional
> dependencies in the normal sense. The user would only want one of them
> in their profile, and never both. Propagating both would rather be a
> nuisance to the user.

I see! Thank you for explaining!

Maxim
L
L
Liliana Marie Prikler wrote on 7 Sep 2021 09:05
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
73974dbbd116dd51a5c5a83f6dd37fde64a68035.camel@gmail.com
Hi,

Am Montag, den 06.09.2021, 19:17 -0400 schrieb Maxim Cournoyer:
Toggle quote (6 lines)
> [...]
>
> Thanks for explaining. It makes sense, although there would probably
> be exceptions. I'm thinking for example about emacs-elpy, for which
> not propagating optional dependencies would render the package nearly
> useless out of the box.
True, that's why those have to be evaluated on a case-by-case basis.
FWIW, I do think that not propagating auto-completion frameworks by
more or less unrelated packages is a good rule of thumb, however.

Toggle quote (10 lines)
> > For example, an Emacs package might require emacs-dash to function
> > at all and might install some autocompletion stuff with emacs-
> > autocomplete or emacs-company (perhaps even both). emacs-dash
> > absolutely must be propagated, but unless you're already using
> > autocomplete or company and thus have them in your manifest, you
> > probably don't want them to be installed by emacs-foo. Does this
> > make sense?
>
> From a purity sense, yes, but propagating autocomplete or company
> wouldn't cause any problems in practice, no?
Packages installed by Guix do contribute to startup times (guix-emacs
autoloads etc.) and if you don't care about a given feature you might
also want to update one package separately from the others (because the
spacebar heater got deactivated), which would lead to a conflict of
propagated inputs. I'm not sure how well the latter would work in
practice, but it's a thing to think about especially with libraries
that would otherwise propagate nothing.

Toggle quote (3 lines)
> As another possible option to explore to avoid propagation could be
> to develop a runpath equivalent for the Emacs compiled format
> (.elc). More work, but more definitive!
I think the bigger problem in Emacs is the lacking module system. Even
if you have runpaths, you're still polluting the same global namespace.

Thanks
X
X
Xinglu Chen wrote on 7 Sep 2021 19:49
87zgsoz370.fsf@yoctocell.xyz
On Mon, Sep 06 2021, Liliana Marie Prikler wrote:

Toggle quote (41 lines)
> Am Montag, den 06.09.2021, 13:51 -0400 schrieb Maxim Cournoyer:
>> Hello Arun,
>>
>> Xinglu Chen <public@yoctocell.xyz> writes:
>>
>> > On Wed, Aug 11 2021, Arun Isaac wrote:
>> >
>> > > Hi all,
>> > >
>> > > I actually think we should not add emacs-vertico to the
>> > > propagated-inputs, and remove emacs-flycheck and emacs-selectrum
>> > > as well. All these are optional dependencies, and we should leave
>> > > it to the user to install the ones they want. At least in this
>> > > specific case, the three packages (flycheck, selectrum and
>> > > vertico) are the kind the user would want to explicitly install.
>> > > They aren't backend libraries that ought to remain invisible to
>> > > the user.
>> > >
>> > > In fact, this is the version of emacs-consult I have installed in
>> > > my profile.
>>
>> Guix packages typically come as featureful as possible unless there
>> are good reasons not too (to minimize the closure size, for
>> example). In this case, the added optional dependencies seem to have
>> negligible effect on the closure size, according to `guix size`; I'd
>> be in favor to keep the optional dependencies specified for that
>> reason, unless there are other considerations that I'm missing.
> While closure size is normally a good metric, with interpreted
> languages like Emacs Lisp you have the added baggage of *propagating*
> inputs, thereby installing stuff at user (or system) level, that the
> user did not actually ask for. My personal take on those is to provide
> them as inputs where necessary to compile, but not actually propagate
> them where not necessary to run.
>
> For example, an Emacs package might require emacs-dash to function at
> all and might install some autocompletion stuff with emacs-autocomplete
> or emacs-company (perhaps even both). emacs-dash absolutely must be
> propagated, but unless you're already using autocomplete or company and
> thus have them in your manifest, you probably don't want them to be
> installed by emacs-foo. Does this make sense?

I just noticed that the “16.4.6 Emacs Packages” section of the manual
has the following paragraph.

The Elisp dependencies of Emacs packages are typically provided as
‘propagated-inputs’ when required at run time. As for other packages,
build or test dependencies should be specified as ‘native-inputs’.
Since these optional dependencies (‘emacs-autocomplete’ and
‘emacs-company’ in your case) are not needed at runtime, would it make
sense to make them ‘native-inputs’ instead of ‘inputs’?
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEAVhh4yyK5+SEykIzrPUJmaL7XHkFAmE3phMVHHB1YmxpY0B5
b2N0b2NlbGwueHl6AAoJEKz1CZmi+1x5wS4P/i4QywAz1KTYiJm6Ev2/re08c1Jc
6V0EcTlwWQR7uYk3+D+4LmmARrPykStEx1dXdZqU+y0LWpfvsuxyaKr4xArRGStS
gr5J1B4AI8uMlCT5k/xiiXI2W1qkd5M/ztNEf2U91+eOtpDfRTxV0dU7GtktAYv2
ZEG7P/EP44lPDtUzxTCTMQ1Tu6J9oHXzrwmFa04xuU53HZGs2G3ia6bkJKcFjAka
GZklmXTmDzrba2OUatDnuTiJkTudH226fhGhqPLxgeQNoZuGDe5c1ltjR+NRDals
5lVgvskway8DlPHnjH5VKIt8c3CI8ZdpsVWKMjf0/oHoBt2GmT8I3PjYUrLB3n1u
PFgr5BAYKWMFvP3Db/scVei+LHrG4qzmgZVTY32APzQiiiQrFx4njZrXZ8Df1V8p
sGRO5O1JBSZsnZoF6E2cjchei1gO+tPZlEjaz9PjVrNfP0Z6efT7YdaEYORWAyVj
2ph/awSGienrBNRN2BHC/tqLObHGjwnjMdtL+wXYHKpfVlVBjUf0pvfLY1fjWPy2
EijKBPtN617joK55ZvrQk710C/6YA9F9qMsxbngPDVK9wDLjUaEuRwXFYEssXH3I
bScEtGPFLT9tfQ3hDdVV/bTExHwJqE/ppSOU0ylfFaCPAoVTGmngF2Eik2YJDZ+K
RyrRpXv04o4cw2gh
=Hz1L
-----END PGP SIGNATURE-----

?