[gentoo-project] [project] Re: Re: EAPI-2 and src_configure in eclasses

[gentoo-project] [project] Re: Re: EAPI-2 and src_configure in eclasses

[Steve Long]

Ciaran McCreesh wrote:

> On Tue, 07 Oct 2008 17:07:21 +0100
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> > It's illegal, according to PMS. It also won't work with Paludis,
>> > since phase function definitions aren't made available until just
>> > before that phase executes (there is a reason for this -- it
>> > provides us with a way of identifying whether a package has a
>> > particular phase or not).
>> > 
>> That seems a bit implementation-specific; how one alternative package
>> manager generates that metadata isn't important (though it does seem
>> odd that you think it has to be done at that point) nor should it get
>> in the way.
> 
> The whole point of PMS is that it provides a way to avoid relying upon
> implementation specific things. There are currently no packages that
> rely upon calling phase functions in the wrong place
It wasn't about calling it in the wrong place, it was about how you test for
whether the ebuild+eclasses provide a function, or use a phase.

> and there are 
> good reasons a package manager might want to avoid implementing things
> in a way such that doing so is legal, so we don't allow it.
>
Sure let's keep constraining what the bash side of things can do, as that's
nothing to do with the package manager implementation.
 
> Also, I don't think it has to be done at that point. I think it's
> convenient to do it at that point, and when combined with several other
> reasons doing it that way is the best option.
>
Yes, a mystery wrapped in an enigma wrapped in pure bullsh^W obfuscation is
always such fun.
 
> Strange how you repeatedly seem to pop up in favour of doing whatever
> you think will cause most inconvenience to Paludis, though...
> 
Strange how you think you can read my mind.. I actually think that not
providing functions an ebuild might call in a phase, during the actual
install, is not such a good way for the mangler to ascertain ahead of time
whether or not that phase will be needed, *irrespective* of how any extant
implementation does it. But as you always remind me, I don't know enough to
comment-- because you say so.

I actually hesitated to get into that discussion with you. I did so as I
wanted to query the design decision. You know, a technical _discussion_..
Thanks for reminding me again how incapable of that you are, unless you
think there is some political capital to be gained.

Re: [gentoo-project] [project] Re: Re: EAPI-2 and src_configure in eclasses

[Ciaran McCreesh]

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

On Wed, 08 Oct 2008 19:48:56 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > The whole point of PMS is that it provides a way to avoid relying
> > upon implementation specific things. There are currently no
> > packages that rely upon calling phase functions in the wrong place
>
> It wasn't about calling it in the wrong place, it was about how you
> test for whether the ebuild+eclasses provide a function, or use a
> phase.

The two issues are the same.

> > and there are 
> > good reasons a package manager might want to avoid implementing
> > things in a way such that doing so is legal, so we don't allow it.
>
> Sure let's keep constraining what the bash side of things can do, as
> that's nothing to do with the package manager implementation.

There are lots of constraints on what the bash side can do that are
for package manager implementation sanity reasons. The whole
constant cache requirement thing, for example, is purely a side effect
of how package managers work.

> > Also, I don't think it has to be done at that point. I think it's
> > convenient to do it at that point, and when combined with several
> > other reasons doing it that way is the best option.
> >
> Yes, a mystery wrapped in an enigma wrapped in pure bullsh^W
> obfuscation is always such fun.

We were discussing your trollish claim that I thought that things had to
be done a particular way. It is of course highly obvious that there are
several ways of achieving the desired result, and highly obvious that
there are a whole bunch of factors affecting which one works best.

As it happens, all three package managers picked different solutions,
all based upon extremely obscure internals issues. Which brings me back
to my original point -- mandating a particular behaviour to enable some
horrible ebuild hackery that doesn't even do what people want would be
a very silly decision.

> > Strange how you repeatedly seem to pop up in favour of doing
> > whatever you think will cause most inconvenience to Paludis,
> > though...
> > 
> Strange how you think you can read my mind.. I actually think that not
> providing functions an ebuild might call in a phase, during the actual
> install, is not such a good way for the mangler to ascertain ahead of
> time whether or not that phase will be needed, *irrespective* of how
> any extant implementation does it.

Your premise is faulty. Ebuilds may not call phase functions, and
never do.

> I actually hesitated to get into that discussion with you. I did so
> as I wanted to query the design decision. You know, a technical
> _discussion_.. Thanks for reminding me again how incapable of that
> you are, unless you think there is some political capital to be
> gained.

If you want a technical discussion, post using your other account with
your real name on it, not your sockpuppet. It's a bit hard to take you
seriously when you maintain two personas, one for real development and
an alterego for Pkgcore fanboyism / Paludis bashing.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-project] [LONG] Re: EAPI-2 and src_configure in eclasses

[Steve Long]

*Sigh* Guess it's that time of year again..

Ciaran McCreesh wrote:
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> > The whole point of PMS is that it provides a way to avoid relying
>> > upon implementation specific things. There are currently no
>> > packages that rely upon calling phase functions in the wrong place
>>
>> It wasn't about calling it in the wrong place, it was about how you
>> test for whether the ebuild+eclasses provide a function, or use a
>> phase.
> 
> The two issues are the same.
>
You mean the three? They all boil down to whether a function is declared,
yes. Have a cookie: you'll need it.
 
>> > and there are
>> > good reasons a package manager might want to avoid implementing
>> > things in a way such that doing so is legal, so we don't allow it.
>>
>> Sure let's keep constraining what the bash side of things can do, as
>> that's nothing to do with the package manager implementation.
> 
> There are lots of constraints on what the bash side can do that are
> for package manager implementation sanity reasons. The whole
> constant cache requirement thing, for example, is purely a side effect
> of how package managers work.
>
Yes and it's well understood and has been discussed on the list. This
hasn't, to my knowledge, yet everytime something which has /not/ been
discussed is brought up, you rear up spouting on about vague hints of doom
to do with portage, irrespective of how many Gentoo systems it's built and
maintains. You obfuscate and spam the list with 15 mails instead of simply
explaining in one go. Finally when someone pleads for sanity, you might
turn around and explain wtf you're on about, and half the time it's
rubbish; only everyone who can argue the point has got too tired of the
thread, already has you in a killfile, or already gave up on the list or
Gentoo because of you, and the shitstorm you generate.
 
>> > Also, I don't think it has to be done at that point. I think it's
>> > convenient to do it at that point, and when combined with several
>> > other reasons doing it that way is the best option.
>> >
>> Yes, a mystery wrapped in an enigma wrapped in pure bullsh^W
>> obfuscation is always such fun.
> 
> We were discussing your trollish claim that I thought that things had to
> be done a particular way.

No you were; you keep making things much more personal than they need to be.
I was discussing how and when that metadata is generated. As Harring
pointed out, pkgcore does it at a  _different_ point in time.

IIRC weren't you the guy who deliberately took a troll as your avatar in
order to flagrantly ban-evade and troll the forums a while back? Since
we're discussing personality; at face sight it seems hypocritical, but then
you always have been quick to call others on behaviour you enjoy using,
even when it's not actually happening. Guess you must be a l337 uber-troll
or sth.. that's true trolling, to play the rules against everyone and cause
as much confusion as possible. Much better than simply being a dicq and
getting kicked out. Oh, wait..

> It is of course highly obvious that there are 
> several ways of achieving the desired result, and highly obvious that
> there are a whole bunch of factors affecting which one works best.
>
Yes, but it's not something we can discuss, I know, because I am 'obviously'
too stupid to understand.
 
> As it happens, all three package managers picked different solutions,
> all based upon extremely obscure internals issues.

I read that as "stuff I don't really understand." No doubt you'll elucidate
over the next 20 mails or so.. I'll get back to you then.

> Which brings me back 
> to my original point -- mandating a particular behaviour to enable some
> horrible ebuild hackery that doesn't even do what people want would be
> a very silly decision.
>
You mean the hackery one might use to detect whether a phase is needed?
 
>> > Strange how you repeatedly seem to pop up in favour of doing
>> > whatever you think will cause most inconvenience to Paludis,
>> > though...
>> > 
>> Strange how you think you can read my mind.. I actually think that not
>> providing functions an ebuild might call in a phase, during the actual
>> install, is not such a good way for the mangler to ascertain ahead of
>> time whether or not that phase will be needed, *irrespective* of how
>> any extant implementation does it.
> 
> Your premise is faulty. Ebuilds may not call phase functions, and
> never do.
>
Hehe. You're good at that trick: you know full well I don't mean the .ebuild

>> I actually hesitated to get into that discussion with you. I did so
>> as I wanted to query the design decision. You know, a technical
>> _discussion_.. Thanks for reminding me again how incapable of that
>> you are, unless you think there is some political capital to be
>> gained.
> 
> If you want a technical discussion, post using your other account with
> your real name on it, not your sockpuppet. It's a bit hard to take you
> seriously when you maintain two personas, one for real development and
> an alterego for Pkgcore fanboyism / Paludis bashing.
> 
Hmm how can I illustrate this wider point to you?

Ciaran: it's clear everytime the new academic year starts, your post count
ramps right up and pisses everyone off. I do hope that this year, what with
your leaving University and having to be taken under your Dad's wing due to
your mental illness, you don't go overboard and take out even more of your
frustration on the rest of us.

Is any of that true? Does it matter? What does any of it have to do with
software development? Would you like a full CV, passport and biometric data
from everyone who posts? Who are you to impose that condition?

You weaseled out of signing the copyright transfer and continue to wave it
in everyone's face at the slightest opportunity. Excuse me for not being
bowled-over.

BTW: stop telling me what to do: I'm mighty bored of it; your pronouncements
only sound dramatic in your own head: no-one else really cares that much.
*You* certainly don't get to impose /any/ conditions on me; you can only
_ask_ the moderators that I be held to a certain standard of behaviour,
taking into account the cultural norms, and the context.

I look forward to the userrel bug. Mind if I get on with software now?




Oh well, tough.

The bit that really gets me is you think I'm a pkgcore fanboi; portage all
the way, twat.

Steven James Long: nobody's puppet, least of all /that/ troll's.

Re: [gentoo-project] [LONG] Re: EAPI-2 and src_configure in eclasses

[Ciaran McCreesh]

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

On Thu, 09 Oct 2008 01:55:41 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> >> It wasn't about calling it in the wrong place, it was about how you
> >> test for whether the ebuild+eclasses provide a function, or use a
> >> phase.
> > 
> > The two issues are the same.
> >
> You mean the three? They all boil down to whether a function is
> declared, yes. Have a cookie: you'll need it.

So if you know they're the same, why did you say that it's about
something else?

> > There are lots of constraints on what the bash side can do that are
> > for package manager implementation sanity reasons. The whole
> > constant cache requirement thing, for example, is purely a side
> > effect of how package managers work.
> >
> Yes and it's well understood and has been discussed on the list. This
> hasn't, to my knowledge, yet everytime something which has /not/ been
> discussed is brought up, you rear up spouting on about vague hints of
> doom to do with portage, irrespective of how many Gentoo systems it's
> built and maintains. You obfuscate and spam the list with 15 mails
> instead of simply explaining in one go.

Uhm. No. My original post explained it all in a level of detail
suitable for the issue at hand. Unfortunately, you then had to jump in
and expect me to explain twenty other at best vaguely related issues
which weren't under discussion. As I've said every time you make that
absurd claim, this is not the place to post a two hundred page
explanation of how every last bit of the computer works, from electrons
upwards, in response to a simple question.

> IIRC weren't you the guy who deliberately took a troll as your avatar
> in order to flagrantly ban-evade and troll the forums a while back?

Uh. No.

> > It is of course highly obvious that there are 
> > several ways of achieving the desired result, and highly obvious
> > that there are a whole bunch of factors affecting which one works
> > best.
> >
> Yes, but it's not something we can discuss, I know, because I am
> 'obviously' too stupid to understand.

If you genuinely care about how Paludis deals with the bash side of
things, do a little background reading and then post a mail to the
Paludis mailing list asking about it. The answer you get will be long,
obscure and of interest to maybe three people, and only because they
have to know about it when changing things.

> > As it happens, all three package managers picked different
> > solutions, all based upon extremely obscure internals issues.
> 
> I read that as "stuff I don't really understand." No doubt you'll
> elucidate over the next 20 mails or so.. I'll get back to you then.

I realise trying to extend the scope of what you expect me to explain
to include life, the universe and everything so you can moan that at me
that I didn't include a demonstration of why the sky is blue in my
original email is your strategy here, but really... Do you genuinely
care?

> > Which brings me back 
> > to my original point -- mandating a particular behaviour to enable
> > some horrible ebuild hackery that doesn't even do what people want
> > would be a very silly decision.
> >
> You mean the hackery one might use to detect whether a phase is
> needed?

It won't, though, because the meaning of phases and phase functions
changes between EAPIs. Which is also something that's already been
covered.
 
> >> Strange how you think you can read my mind.. I actually think that
> >> not providing functions an ebuild might call in a phase, during
> >> the actual install, is not such a good way for the mangler to
> >> ascertain ahead of time whether or not that phase will be needed,
> >> *irrespective* of how any extant implementation does it.
> > 
> > Your premise is faulty. Ebuilds may not call phase functions, and
> > never do.
> >
> Hehe. You're good at that trick: you know full well I don't mean
> the .ebuild

So, uh, if by "an ebuild" you don't mean "the .ebuild", what do you
mean? Kindly explain.

> Is any of that true? Does it matter? What does any of it have to do
> with software development? Would you like a full CV, passport and
> biometric data from everyone who posts? Who are you to impose that
> condition?

No, I would like you to stop maintaining a "real work" persona and a
"paludis bashing" persona. Beyond that I don't care.

Incidentally, read up on luke-jr (google "gentoo-dev seems to be
hacked") if you want to see what Gentoo's view on using aliases and
contributions from non-existent people is.

> You weaseled out of signing the copyright transfer and continue to
> wave it in everyone's face at the slightest opportunity. Excuse me
> for not being bowled-over.

Uh. Huh.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-project] Re: [LONG] Re: EAPI-2 and src_configure in eclasses

[Steve Long]

Ciaran McCreesh wrote:
> On Thu, 09 Oct 2008 01:55:41 +0100
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> >> It wasn't about calling it in the wrong place, it was about how you
>> >> test for whether the ebuild+eclasses provide a function, or use a
>> >> phase.
>> > 
>> > The two issues are the same.
>> >
>> You mean the three? They all boil down to whether a function is
>> declared, yes. Have a cookie: you'll need it.
> 
> So if you know they're the same, why did you say that it's about
> something else?
>
*cough* user perception vs reality; in your case there's at least a third
level going on ofc.

>> > There are lots of constraints on what the bash side can do that are
>> > for package manager implementation sanity reasons. The whole
>> > constant cache requirement thing, for example, is purely a side
>> > effect of how package managers work.
>> >
>> Yes and it's well understood and has been discussed on the list. This
>> hasn't, to my knowledge, yet everytime something which has /not/ been
>> discussed is brought up, you rear up spouting on about vague hints of
>> doom to do with portage, irrespective of how many Gentoo systems it's
>> built and maintains. You obfuscate and spam the list with 15 mails
>> instead of simply explaining in one go.
> 
> Uhm. No. My original post explained it all in a level of detail
> suitable for the issue at hand.
`Level of detail for issue at hand' is similar to a user thinking it's two
or three issues when it's one.
 
> Unfortunately, you then had to jump in 
> and expect me to explain twenty other at best vaguely related issues
> which weren't under discussion.
Nope; just if you don't want to discuss, kindly stay away from any of my
posts in future. Just ignore me and perhaps someone more able to carry on a
discussion will respond instead (and yes, that does preclude your fanbois.)

> As I've said every time you make that 
> absurd claim, this is not the place to post a two hundred page
> explanation of how every last bit of the computer works, from electrons
> upwards, in response to a simple question.
>
Yes because we really need to discuss transistor logic for this. (And yes, I
really do know more about it than you.)

>> you keep making things much more personal than they need to be.
>> I was discussing how and when that metadata is generated. As Harring
>> pointed out, pkgcore does it at a _different_ point in time.

Funny how that slipped by, isn't it?

>> IIRC weren't you the guy who deliberately took a troll as your avatar
>> in order to flagrantly ban-evade and troll the forums a while back?
> 
> Uh. No.
>
Yes, dear.. http://img263.imageshack.us/img263/3440/1183976821967ju4.jpg

>> > It is of course highly obvious that there are
>> > several ways of achieving the desired result, and highly obvious
>> > that there are a whole bunch of factors affecting which one works
>> > best.
>> >
>> Yes, but it's not something we can discuss, I know, because I am
>> 'obviously' too stupid to understand.
> 
> If you genuinely care about how Paludis deals with the bash side of
> things,

No I don't you moron; I want to discuss package managers and the
technicalities of using them with people who work with portage, pkgcore and
Gentoo. You just keep getting in the way, acting somehow as if you're
elucidating, when all you're doing is quite pathetic attention-seeking.

> do a little background reading and then post a mail to the 
> Paludis mailing list asking about it.

No thanks, my first and only real-time conversation with you two years ago
convinced me that all the Gentoo people who couldn't stand to even talk
about you had good reason. Up until that point, based on the mailing-list,
I assumed that when you didn't get an answer it was because you were right.
Not that everyone was just sick to death of you after 3 or 4 years.

Their embarrasment wasn't technical iow, it was purely about your
personality, which is poisoned, perhaps by your Aspergers or w/e you're
calling it this year. I doubt it though: I think you're just a nasty piece
of work who hides his craven cowardice behind his technical ability, and
uses that to get a kick out of beating up on newbs. We see them all the
time in #bash, ##c and so on; put bluntly you and your cohorts are the
reason I never got involved with KDE on Gentoo, despite having used it for
over a decade.

>> > As it happens, all three package managers picked different
>> > solutions, all based upon extremely obscure internals issues.
>> 
>> I read that as "stuff I don't really understand." No doubt you'll
>> elucidate over the next 20 mails or so.. I'll get back to you then.
> 
> I realise trying to extend the scope of what you expect me to explain
> to include life, the universe and everything so you can moan that at me
> that I didn't include a demonstration of why the sky is blue in my
> original email is your strategy here

No it's not; see above. Honestly, you really think I waste time strategising
about how to deal with *you*? Most I ever do is joke with mates about how
obnoxious you are, though these days it's more your cronies (and no doubt
your sekrit personality on the forums.) Honestly, I don't need to waste
time thinking how to deal with you, little boy: you always turn up being
nasty[1] and proving the point. That's why you were eventually kicked out
on your arse after so much time.

> , but really... Do you genuinely 
> care?
> 
Not about the over-engineered, bloated crap you come out with. I do hope
exherbo is taking all your ideas without review, or at very least all the
ones you've presented to the dev m-l. If only christel and kloeri weren't
involved, I'd be able to cackle with delight.

I mean that crap you came out with about subshell die over a year ago, and
the nonsense you spouted about trap on the dev m-l recently. I can't take
you seriously as you're simply unable to grasp that other people might know
more than you; hence you're a liability to any project, and it's no wonder
you couldn't get a job outta Uni, despite all those legions of people who
think you're so hawt.

>> > Which brings me back
>> > to my original point -- mandating a particular behaviour to enable
>> > some horrible ebuild hackery that doesn't even do what people want
>> > would be a very silly decision.
>> >
>> You mean the hackery one might use to detect whether a phase is
>> needed?
> 
> It won't, though, because the meaning of phases and phase functions
> changes between EAPIs. Which is also something that's already been
> covered.
>
IOW we need to consider the EAPI, which is what was being discussed on the
technical list.
  
>> >> Strange how you think you can read my mind.. I actually think that
>> >> not providing functions an ebuild might call in a phase, during
>> >> the actual install, is not such a good way for the mangler to
>> >> ascertain ahead of time whether or not that phase will be needed,
>> >> *irrespective* of how any extant implementation does it.
>> > 
>> > Your premise is faulty. Ebuilds may not call phase functions, and
>> > never do.
>> >
>> Hehe. You're good at that trick: you know full well I don't mean
>> the .ebuild
> 
> So, uh, if by "an ebuild" you don't mean "the .ebuild", what do you
> mean? Kindly explain.
>
Work it out, genius.

Feel free to keep spouting; I won't be answering this thread for at least 10
more of your emails, if it's still going.

[1] http://thread.gmane.org/gmane.linux.gentoo.devel/56682/focus=56997 sums
it up. 

Re: [gentoo-project] Re: [LONG] Re: EAPI-2 and src_configure in eclasses

[Ciaran McCreesh]

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

On Sat, 11 Oct 2008 04:45:16 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > As I've said every time you make that 
> > absurd claim, this is not the place to post a two hundred page
> > explanation of how every last bit of the computer works, from
> > electrons upwards, in response to a simple question.
> >
> Yes because we really need to discuss transistor logic for this.

Right, in the same way we need to discuss package manager loading
internals for this.

> >> you keep making things much more personal than they need to be.
> >> I was discussing how and when that metadata is generated. As
> >> Harring pointed out, pkgcore does it at a _different_ point in
> >> time.
> 
> Funny how that slipped by, isn't it?

What? I already mentioned how there were other obscure internals
factors related to the decision. There are all kinds of ways one could
do it. As it happens, I don't like the Pkgcore way primarily because it
directly encourages the kind of screwups that happened with the first
Pkgcore EAPI 2 attempt.

> (and no doubt your sekrit personality on the forums.)

Unlike you, I don't post from multiple accounts or pretending to be
several people. (As an aside: if you feel you must carry on calling me
a terrorist baby-munching communist or whatever it is this week, please
humour me and do it from the account with your real name on it.)

> I mean that crap you came out with about subshell die over a year
> ago, and the nonsense you spouted about trap on the dev m-l recently.

You mean the results of having several people try every solution in
depth, evaluate them against the way ebuilds are coded and come up
with the one that works?

> >> You mean the hackery one might use to detect whether a phase is
> >> needed?
> > 
> > It won't, though, because the meaning of phases and phase functions
> > changes between EAPIs. Which is also something that's already been
> > covered.
> >
> IOW we need to consider the EAPI, which is what was being discussed
> on the technical list.

Yes, which is what my original reply (the one that got you so upset)
said in the first place.

> >> Hehe. You're good at that trick: you know full well I don't mean
> >> the .ebuild
> > 
> > So, uh, if by "an ebuild" you don't mean "the .ebuild", what do you
> > mean? Kindly explain.
> >
> Work it out, genius.

I'm sorry, I can't work that out on my own. Please elucidate. Help me
to understand why you think PMS is wrong with its restrictions on phase
functions.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-project] Re: [LONG] Re: EAPI-2 and src_configure in eclasses

[Dawid Węgliński]

On Saturday 11 of October 2008 17:38:54 Ciaran McCreesh wrote:

> > >> Hehe. You're good at that trick: you know full well I don't mean
> > >> the .ebuild
> > >
> > > So, uh, if by "an ebuild" you don't mean "the .ebuild", what do you
> > > mean? Kindly explain.
> >
> > Work it out, genius.
>
> I'm sorry, I can't work that out on my own. Please elucidate. Help me
> to understand why you think PMS is wrong with its restrictions on phase
> functions.


ebuild.sh, methinks.

Re: [gentoo-project] Re: [LONG] Re: EAPI-2 and src_configure in eclasses

[Ciaran McCreesh]

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

On Sat, 11 Oct 2008 17:45:15 +0200
Dawid Węgliński <cla@gentoo.org> wrote:
> > I'm sorry, I can't work that out on my own. Please elucidate. Help
> > me to understand why you think PMS is wrong with its restrictions
> > on phase functions.
> 
> ebuild.sh, methinks.

If that's what he means, it's extremely bizarre, because none of the
package managers implement phase function execution as a simple direct
call. There's too much other stuff that needs doing before and after.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]