Re: [gentoo-dev] Re: [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: Nirbheek Chauhan [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 03 Aug 2008 05:37:10 +0530: How about we just skip the reversed-boolean-usage/it's-a-long-name confusion/argument and just call it RESTRICT=tarballs ? I know not all distfiles are tarballs, but it gets the message across far better than constant-sources IMO :o) +1 The simplicity of live with the negative connotation of restrict, seems to kill both those issues with a single stone. =8^) RESTRICT=tarballs works for me! I don't like RESTRICT=tarballs because I don't think it's clear enough. I think we should go with RESTRICT=live-sources. Maybe it doesn't fit your convention, I'm pretty sure we already have other RESTRICT flags that don't fit your convention. How about primaryuri, for example? Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiVcw8ACgkQ/ejvha5XGaOLFwCfU/tvAxDpYl/3urruB9B5ba+U 6qwAn1bJ47ZCY0ZjW/vjR9qEc4KyDc8C =GcXp -END PGP SIGNATURE-
[gentoo-dev] Re: [RFC] New RESTRICT=live value for identification of live ebuilds?
Nirbheek Chauhan [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 03 Aug 2008 05:37:10 +0530: How about we just skip the reversed-boolean-usage/it's-a-long-name confusion/argument and just call it RESTRICT=tarballs ? I know not all distfiles are tarballs, but it gets the message across far better than constant-sources IMO :o) +1 The simplicity of live with the negative connotation of restrict, seems to kill both those issues with a single stone. =8^) RESTRICT=tarballs works for me! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: [RFC] New RESTRICT=live value for identification of live ebuilds?
Zac Medico [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 03 Aug 2008 01:57:52 -0700: I don't like RESTRICT=tarballs because I don't think it's clear enough. I think we should go with RESTRICT=live-sources. Maybe it doesn't fit your convention, I'm pretty sure we already have other RESTRICT flags that don't fit your convention. How about primaryuri, for example? Well, it's obviously the sore thumb sticking out, but that doesn't mean we otta make it two sore thumbs! =8^) In any case, just because I'm supporting what may be a compromise doesn't necessarily mean I support the convention one side was arguing, as the second-person your (whether singular or plural) would indicate. I'm more or less neutral on that, personally, only supporting it here as a way to work with the people for whom it seems to be an issue. Personally, if it comes down to the It's a list of flags, called 'RESTRICT' only due to historical reasons argument, so be it. (Said as a user who contributed one live ebuild now in the tree, and uses a few others.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
Sorry that this is slightly OT, but maybe one should think about this point in this discussion: It seems like USE would be an unconventional location to store that information and I'm not sure that it really belongs in the ebuild. USE=live could perfectly make sense, if it is equipped with the obvious meaning: I suggest that if it is set, then it is attempted before building to download the newest source from cvs/svn/git/monotone/bzr/..., otherwise only the previously downloaded source is recompiled. Currently, this functionality, which is extremely useful for systems without permanent internet connection, is only implemented inconsistently by using environment variables, differently for each vcs: cvs: CVS_OFFLINE or CVS_OFFLINE_package_name git: EGIT_OFFLINE or ESCM_OFFLINE svn: ESVN_OFFLINE or ESCM_OFFLINE ???: Perhaps not implemented at all? Then it would also make sense that @live-ebuilds consists only of those packages for which the live USE-flag is actually set (because the user does not want to treat them as live).
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vaeth wrote: Sorry that this is slightly OT, but maybe one should think about this point in this discussion: It seems like USE would be an unconventional location to store that information and I'm not sure that it really belongs in the ebuild. USE=live could perfectly make sense, if it is equipped with the obvious meaning: I suggest that if it is set, then it is attempted before building to download the newest source from cvs/svn/git/monotone/bzr/..., otherwise only the previously downloaded source is recompiled. Currently, this functionality, which is extremely useful for systems without permanent internet connection, is only implemented inconsistently by using environment variables, differently for each vcs: cvs: CVS_OFFLINE or CVS_OFFLINE_package_name git: EGIT_OFFLINE or ESCM_OFFLINE svn: ESVN_OFFLINE or ESCM_OFFLINE ???: Perhaps not implemented at all? Then it would also make sense that @live-ebuilds consists only of those packages for which the live USE-flag is actually set (because the user does not want to treat them as live). Well, it seems to me that you're trying to shoehorn a USE flag into a role that's intended to be filled by package sets. The idea is that instead of settings USE flags in package.use, you'd define a package set containing the specific packages that you want rebuilt. Trying to define your set inside package.use would be an abuse of package.use and we've already got package sets designed for that purpose. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiVumgACgkQ/ejvha5XGaMhRACeNiJD30ggs/plNGuhX78B63Yv fX4An2faHig4ZreJD/3I1uGOEa/UTaDb =p9G+ -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
Vaeth wrote: The main point in introducing the live USE flag should be IMHO to let the user decide whether the sources should be fetched. The fact that IUSE then marks live ebuilds in the way which you wanted is an additional side effect. A tend to agree with Zac that USE flags should not dictate package manager behavior (e.g. whether a package gets included in a specific package set or defining a package as live), and the idea of the IUSE side-effect seems a bit unclean (i.e., behaviors that the dev did not intend might end up being a surprize; I think we need to be careful about side-effects). However, I do see the point about the RESTRICT variable. Throwing random flags into it does not seem ideal, and I think convenience should take a back seat to correctness when designing, e.g., ebuild syntax/rules. But why would using a new variable require an EAPI change any more than adding new flags to RESTRICT? I.e., if people start using OPTIONS= or FLAGS=, it would simply be ignored by older package manager versions, just like new RESTRICT values would be ignored. Or am I missing something fundamental? -Joe
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
On Sun, Aug 3, 2008 at 12:25 AM, Zac Medico [EMAIL PROTECTED] wrote: Santiago M. Mola wrote: I don't think we're in a hurry for this feature, so I don't see the need of using suboptimal hacks in order to avoid an EAPI bump. Furthermore, EAPI 2 is supposed to be done in the near future, right? Regards, I don't view the RESTRICT=live idea as suboptimal or a hack in any way. I see it as a legitimate use of an existing ebuild variable that's already used for lots of other legitimate purposes. Let me rephrase the point as that this method should not be favoured over others just because it doesn't require an EAPI bump. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Peterson wrote: However, I do see the point about the RESTRICT variable. Throwing random flags into it does not seem ideal, and I think convenience should take a back seat to correctness when designing, e.g., ebuild syntax/rules. But why would using a new variable require an EAPI change any more than adding new flags to RESTRICT? I.e., if people start using OPTIONS= or FLAGS=, it would simply be ignored by older package manager versions, just like new RESTRICT values would be ignored. Or am I missing something fundamental? What you're missing is that only a specific subset of variables is cached in /usr/portage/metadata/cache. Now that you mention it, we could introduce a new variable called EBUILD_FLAGS and start caching it in new versions of portage. It wouldn't necessarily require an EAPI bump as long as it can safely be ignored by older versions of portage. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiWD04ACgkQ/ejvha5XGaO8JgCgv3dIDZtq/7qnmCadq7cpfUQs CNUAn334taZBgjWwM9UAxW97mEO9WCE6 =vbtT -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: Joe Peterson wrote: However, I do see the point about the RESTRICT variable. Throwing random flags into it does not seem ideal, and I think convenience should take a back seat to correctness when designing, e.g., ebuild syntax/rules. But why would using a new variable require an EAPI change any more than adding new flags to RESTRICT? I.e., if people start using OPTIONS= or FLAGS=, it would simply be ignored by older package manager versions, just like new RESTRICT values would be ignored. Or am I missing something fundamental? What you're missing is that only a specific subset of variables is cached in /usr/portage/metadata/cache. Now that you mention it, we could introduce a new variable called EBUILD_FLAGS and start caching it in new versions of portage. It wouldn't necessarily require an EAPI bump as long as it can safely be ignored by older versions of portage. Zac Oh and by the way, I should mention that it might not be worth it to add a whole new variable. I think RESTRICT=live-sources is a perfectly fine, especially considering the the existing RESTRICT=primaryuri value is similar in some ways, including perceived polarity. If we do decide to add a new variable then perhaps we should move primaryuri to the new variable as well, for consistency. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiWGY0ACgkQ/ejvha5XGaPGlQCgiDvulaAgLqdHXyoFVPPXdF6t 22gAnAiUNyY4fbmCl2WeapH3n7g1Y/8A =l90F -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
Zac Medico wrote: What you're missing is that only a specific subset of variables is cached in /usr/portage/metadata/cache. Now that you mention it, we could introduce a new variable called EBUILD_FLAGS and start caching it in new versions of portage. It wouldn't necessarily require an EAPI bump as long as it can safely be ignored by older versions of portage. Yes, that was my thinking. Oh and by the way, I should mention that it might not be worth it to add a whole new variable. I think RESTRICT=live-sources is a perfectly fine, especially considering the the existing RESTRICT=primaryuri value is similar in some ways, including perceived polarity. If we do decide to add a new variable then perhaps we should move primaryuri to the new variable as well, for consistency. Yes, that's sort of what I am thinking. Migrate options that really do not belong in RESTRICT to another variable (and keep them in RESTRICT, of course, for backward compat for now). Then introduce new ones into whichever variable makes sense. I'm not sure the EBUILD_ in EBUILD_FLAGS would be necessary (redundant?). Maybe even OPTIONS or PROPERTIES makes more sense. In fact, FLAGS might be a little too generic, even? Worth a short discussion. -Joe
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Peterson wrote: Yes, that's sort of what I am thinking. Migrate options that really do not belong in RESTRICT to another variable (and keep them in RESTRICT, of course, for backward compat for now). Then introduce new ones into whichever variable makes sense. Personally I think people are far too concerned about the name of the variable. I only see a what I consider to be a trivial or negligible benefit in separating these things into two different variables. However, it it makes more people happy then I guess I'm for it. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiWKJMACgkQ/ejvha5XGaOtxwCdHWWJ9sFaVsSiQF36j1WDmJOY Vf8AmgP9MlJGdQC5jzgGkjdUqmv+Y+F8 =WWt3 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
Zac Medico wrote: Personally I think people are far too concerned about the name of the variable. I only see a what I consider to be a trivial or negligible benefit in separating these things into two different variables. However, it it makes more people happy then I guess I'm for it. Different people have differing sensitivity to things like this (aesthetics, consistency, etc.). IMHO, this particular one is not a *huge* deal (picking my battles, I personally would not choose to be too vehement on this one), but it's always nice to pick the most elegant/logical way to do things, especially for things that are exposed to the dev/ebuild interface and are hard to change later. -Joe
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Peterson wrote: I'm not sure the EBUILD_ in EBUILD_FLAGS would be necessary (redundant?). Maybe even OPTIONS or PROPERTIES makes more sense. In fact, FLAGS might be a little too generic, even? Worth a short discussion. One potential issue with using a short generic name is the potential for variable name collisions. It's mainly an issue if we want to mark the variable readonly during normal ebuild phases. If the variable is marked readonly then bash will not allow that variable name to be used as either a global or a _local_ variable. Maybe it doesn't really matter though. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiWKuYACgkQ/ejvha5XGaPdgQCfXyDdAPN22+Jn/szjD0zG99eH xqgAn28jCCmEOLoKfKSspbJbGskUwjtI =rDmY -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Peterson wrote: I'm not sure the EBUILD_ in EBUILD_FLAGS would be necessary (redundant?). Maybe even OPTIONS or PROPERTIES makes more sense. In fact, FLAGS might be a little too generic, even? Worth a short discussion. I think something like PROPERTIES or ATTRIBUTES would be nice. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiWNvgACgkQ/ejvha5XGaML/QCgj7Aof1UEVGrtBNcloDjFMhDJ izEAn2FTGTnnDa23XEF3ZENc9UaQU0P4 =JrMC -END PGP SIGNATURE-
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-08-03 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2008-08-03 23h59 UTC. Removals: dev-util/livecd-specs 2008-07-31 00:51:09 wolf31o2 dev-util/livecd-kconfigs2008-07-31 00:57:47 wolf31o2 dev-db/freecdb 2008-08-01 15:02:04 hattya mail-client/claws-mail-pdf-viewer 2008-08-03 16:19:05 opfer Additions: sci-geosciences/osmosis 2008-07-28 00:59:23 hanno sci-geosciences/mkgmap 2008-07-28 01:01:28 hanno media-libs/sublib 2008-07-29 01:16:38 beandog dev-python/pygene 2008-07-30 04:55:49 neurogeek dev-perl/Text-Markdown 2008-07-30 08:09:19 tove dev-perl/CGI-FormBuilder2008-07-30 08:21:09 tove app-emacs/tempo-snippets2008-07-30 13:42:20 ulm app-misc/tmux 2008-07-30 18:01:53 swegener dev-java/lucene-analyzers 2008-07-30 18:23:30 elvanor x11-libs/xpyb 2008-07-30 22:21:17 dberkholz dev-util/radare 2008-07-31 17:54:59 deathwing00 net-misc/wicd 2008-07-31 18:08:54 darkside dev-perl/LWP-Authen-Wsse2008-08-01 14:22:48 tove dev-perl/XML-Atom 2008-08-01 14:28:29 tove dev-perl/Feed-Find 2008-08-01 14:41:09 tove dev-perl/URI-Fetch 2008-08-01 14:54:25 tove dev-perl/XML-Feed 2008-08-01 15:07:55 tove dev-perl/LWPx-ParanoidAgent 2008-08-01 15:26:31 tove dev-perl/Net-OpenID-Consumer2008-08-02 11:35:05 tove net-misc/switzerland2008-08-03 12:45:01 cedk net-analyzer/nagvis 2008-08-03 15:12:28 dertobi123 dev-java/glassfish-transaction-api 2008-08-03 22:21:25 betelgeuse java-virtuals/transaction-api 2008-08-03 22:27:58 betelgeuse sci-chemistry/xds-bin 2008-08-03 22:29:53 dberkholz -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-util/livecd-specs,removed,wolf31o2,2008-07-31 00:51:09 dev-util/livecd-kconfigs,removed,wolf31o2,2008-07-31 00:57:47 dev-db/freecdb,removed,hattya,2008-08-01 15:02:04 mail-client/claws-mail-pdf-viewer,removed,opfer,2008-08-03 16:19:05 Added Packages: sci-geosciences/osmosis,added,hanno,2008-07-28 00:59:23 sci-geosciences/mkgmap,added,hanno,2008-07-28 01:01:28 media-libs/sublib,added,beandog,2008-07-29 01:16:38 dev-python/pygene,added,neurogeek,2008-07-30 04:55:49 dev-perl/Text-Markdown,added,tove,2008-07-30 08:09:19 dev-perl/CGI-FormBuilder,added,tove,2008-07-30 08:21:09 app-emacs/tempo-snippets,added,ulm,2008-07-30 13:42:20 app-misc/tmux,added,swegener,2008-07-30 18:01:53 dev-java/lucene-analyzers,added,elvanor,2008-07-30 18:23:30 x11-libs/xpyb,added,dberkholz,2008-07-30 22:21:17 dev-util/radare,added,deathwing00,2008-07-31 17:54:59 net-misc/wicd,added,darkside,2008-07-31 18:08:54 dev-perl/LWP-Authen-Wsse,added,tove,2008-08-01 14:22:48 dev-perl/XML-Atom,added,tove,2008-08-01 14:28:29 dev-perl/Feed-Find,added,tove,2008-08-01 14:41:09 dev-perl/URI-Fetch,added,tove,2008-08-01 14:54:25 dev-perl/XML-Feed,added,tove,2008-08-01 15:07:55 dev-perl/LWPx-ParanoidAgent,added,tove,2008-08-01 15:26:31 dev-perl/Net-OpenID-Consumer,added,tove,2008-08-02 11:35:05 net-misc/switzerland,added,cedk,2008-08-03 12:45:01 net-analyzer/nagvis,added,dertobi123,2008-08-03 15:12:28 dev-java/glassfish-transaction-api,added,betelgeuse,2008-08-03 22:21:25 java-virtuals/transaction-api,added,betelgeuse,2008-08-03 22:27:58 sci-chemistry/xds-bin,added,dberkholz,2008-08-03 22:29:53 Done.
Re: [gentoo-dev] Gentoo Council Reminder for August 7
Hi, For clarity, I am tomaw, a member of freenode staff. For even more clarity, I am a member of OFTC staff, although that's not relevant to this posting. I have spent many hours discussing this issue with Chrissy and others and feel some points require clarification. On Fri, 1 Aug 2008 08:39:41 -0700 Chrissy Fullam [EMAIL PROTECTED] wrote: Fair enough. Let me wrap up the IRC part. 1. I'd like to ask Council to discuss possible reactions to our developer being banned from Freenode without providing us with a reason. The situation looks like one of Freenode staffers overreacted over something Chris said during previous Council meeting and banned him to prevent him from attending next meetings when he was supposed to provide more information on the CoC topic. The ban was removed after an hour, The ban was put in place on Sunday; the ban was lifted on Tuesday evening = way longer than one hour. Chris tried to speak to Freenode staff on Freenode but was told he was evading the ban and they would not speak to him there. He had to find out from me what the email I have previously indicated on IRC that the omission of the email address to respond to with questions about klines in this kline message was a mistake. He did not have to find out which email address to use from you. I told him myself. I am quite upset that you did not feel it prudent to indicate that we admit this mistake in your email. address was (as it's not documented on Freenode's site) and email them to ask why he was banned. Christel responded later that day and simply apologized and removed the ban. Chris again emailed to ask *why* he was banned but Freenode staff has ignored his second email requesting information about his own ban. I responded personally to this request. I did consider writing another response earlier today asking for more time due to staff availability but decided doing so was overly verbose. If your personal knowledge of the person in question indicates that he prefers more verbose interaction please have him convey this to us and I will be happy to help. To me it looks like they not only will not tell us, they will not tell the individual who was actually banned and that is in poor professional taste and only further serves to drive a wedge between our ability to work with Freenode. freenode can currently only discuss this with the person banned due to legal issues. I am not a lawyer, but I suspect much of what fmccor said to be true. 2. I want Council to consider moving their meetings somewhere where third parties can't control who in Gentoo can attend and who can't. This is an interesting idea. Perhaps a good trial for a transition? 3. I want Council to consider creating and using irc.gentoo.org alias instead of irc.freenode.net in our docs, news items and so on. Seems pretty logical so I just want to say that I like this whoever came up with this. :) This seems sensible. Thanks, -- Tom Wesley [EMAIL PROTECTED] signature.asc Description: PGP signature
[gentoo-dev] [RFC] New PROPERTIES=live-sources setting for ebuilds?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
As a substitute for the previously discussed RESTRICT=live value[1],
I'd now like you to consider an equivalent PROPERTIES=live-sources
setting. By specifying PROPERTIES=live-sources, an ebuild will be
able to indicate that it uses src_unpack() to download sources from
some type of live repository such as cvs, darcs, git, mercurial, or svn.
The only difference between the previously suggested RESTRICT=live
value and the new PROPERTIES=live-sources value is that we'll be
using a new variable name and therefore we'll have to add that
variable to the metadata cache in order for it to be accessible
during dependency calculations. This will require the introduction
of a new PROPERTIES variable to the ebuild metadata cache that's
distributed via the rsync mirrors and resides locally in the
${PORTDIR}/metadata/cache/ directory.
By using a new PROPERTIES variable instead of the existing RESTRICT
variable, we will have two separate categories of boolean
attributes. This is useful since some boolean attributes, such as
primaruri and live-sources, have an inverted nomenclature when
compared to the other boolean attributes that currently exist within
the RESTRICT set, show here:
binchecks - Disable all QA checks for binaries.
bindist - Distribution of binary packages is restricted.
fetch - Files will not be fetched via SRC_URI.
installsources - Disable FEATURES=installsources.
mirror - Disable mirroring.
primaryuri - Fetch from URLs in SRC_URI before GENTOO_MIRRORS.
strip - Final binaries/libraries will not be stripped.
test - Do not run src_test even if user has FEATURES=test.
userpriv - Disables FEATURES=userpriv.
We can add the new PROPERTIES variable to the metadata cache and it
will be fully backward compatible as long as PROPERTIES only
contains information that can be safely ignored by older versions of
portage. Newer versions of portage that are aware of the new
variable will simply have a superset of the information that's
available to older versions of portage.
The addition of the PROPERTIES variable isn't entirely necessary
since the live-sources attribute could be expressed in RESTRICT
just as well. However, numerous people has expressed a desire to
have a new variable to represent a different category of boolean
attributes, so as not to pollute the RESTRICT variable with values
that don't fit well into existing RESTRICT nomenclature conventions.
Shall we move forward with this approach or are there any remaining
issues that people would like to discuss?
Zac
[1]
http://archives.gentoo.org/gentoo-dev/msg_164fd8d5d513121ab772509d06a7b27a.xml
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkiWYOoACgkQ/ejvha5XGaPMuACfQ+9TlGN4gG18HTWvKKncIXzE
Hl8An1FIrlZIq1GV5UnfE5j6gTnVdyBY
=Kc2m
-END PGP SIGNATURE-
