Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
Robin H. Johnson [EMAIL PROTECTED] said: Hi folks, I'm doing some research on our usages of the $Header$ keyword in our main CVS repo. The primary use-case that has been publicly stated before was for users to be able to identify to developers what version of a given ebuild they were using. Q: How much have you utilized the primary use case? Q: Are there any other use-cases you have and actively use? For evaluating existing uses of the primary case, I took a glance at Bugzilla. There are 624 bugs total that contain a $Header$ with an existing Gentoo path. At least 143 of those are for new packages or version bumps (they copied existing ebuilds). it appears we have decided to keep the $Header$ keyword in ebuilds for now. however, what about removing it from the ChangeLog? kind regards Thilo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Wed, Oct 01, 2008 at 05:31:21PM +0200, Thilo Bangert wrote: For evaluating existing uses of the primary case, I took a glance at Bugzilla. There are 624 bugs total that contain a $Header$ with an existing Gentoo path. At least 143 of those are for new packages or version bumps (they copied existing ebuilds). it appears we have decided to keep the $Header$ keyword in ebuilds for now. however, what about removing it from the ChangeLog? The Debian pkg generation was the only use-case that didn't have an immediate other solution. The Prefix guys need it while we are still on CVS, but said it could vanish on the other side of the Git migration. So probably just keep it everywhere until we switch VCS. Random plug: Interested in VCS migration? Subscribe to the gentoo-scm list. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpiy5wrC4jVd.pgp Description: PGP signature
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On 26-08-2008 15:41:07 -0500, Yuri Vasilevski wrote: On Tue, 26 Aug 2008 13:40:36 -0700 Robin H. Johnson [EMAIL PROTECTED] wrote: I'm doing some research on our usages of the $Header$ keyword in our main CVS repo. Q: Are there any other use-cases you have and actively use? I use the revision present in the header to identify changes in ebuild files that didn't needed a revision dump. I do exactly the same (or, eupdate is doing that) to keep the Prefix tree in sync with gentoo-x86. That is, I use the CVS Header to determine if a change has occurred, retrieve that diff, and apply the patch on my Prefix version of the same file (ebuild, ChangeLog, patch, eclass, ...). For that reason I'd pretty much prefer to keep the CVS Header in place, unless there is a very good reason to remove it. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Tue, 2008-08-26 at 13:40 -0700, Robin H. Johnson wrote: Q: How much have you utilized the primary use case? Not at all Q: Are there any other use-cases you have and actively use? No
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Wed, Aug 27, 2008 at 06:35:57PM +0200, Fabian Groffen wrote: For that reason I'd pretty much prefer to keep the CVS Header in place, unless there is a very good reason to remove it. As I wrote in the other thread, my reason for asking is that it's one of the things that doesn't have clear mapping in the Git world. As a side benefit, getting rid of it also makes the double-commit mess go away. For your use case, it should be possible to just ask Git for updates to the given directory, and apply those to your own tree. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp0p0m0ukuIx.pgp Description: PGP signature
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On 27-08-2008 10:28:57 -0700, Robin H. Johnson wrote: On Wed, Aug 27, 2008 at 06:35:57PM +0200, Fabian Groffen wrote: For that reason I'd pretty much prefer to keep the CVS Header in place, unless there is a very good reason to remove it. As I wrote in the other thread, my reason for asking is that it's one of the things that doesn't have clear mapping in the Git world. As a side benefit, getting rid of it also makes the double-commit mess go away. For who is it a mess? Not for repoman users, I suppose, and everyone should be using it, right? As the one who personally played with the code in repoman that determines whether or not the double commit is necessary, I think it's mostly a repoman internal problem. The commit script problems put aside. For your use case, it should be possible to just ask Git for updates to the given directory, and apply those to your own tree. Another VCS is another story. If we're switching, it would be nice if the notion of overlays shadowing the main tree would be taken into account. Especially since I don't think Prefix will merge any time soon, but we are plagued by the thing called growth. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Wed, Aug 27, 2008 at 10:38 AM, Fabian Groffen [EMAIL PROTECTED] wrote: On 27-08-2008 10:28:57 -0700, Robin H. Johnson wrote: On Wed, Aug 27, 2008 at 06:35:57PM +0200, Fabian Groffen wrote: For that reason I'd pretty much prefer to keep the CVS Header in place, unless there is a very good reason to remove it. As I wrote in the other thread, my reason for asking is that it's one of the things that doesn't have clear mapping in the Git world. As a side benefit, getting rid of it also makes the double-commit mess go away. For who is it a mess? Not for repoman users, I suppose, and everyone should be using it, right? As the one who personally played with the code in repoman that determines whether or not the double commit is necessary, I think it's mostly a repoman internal problem. The commit script problems put aside. So you are saying we should do what? precompute the CVS header and inject it into $header$ ourselves take the checksums generate the manifest revert the $header$ change then commit the ebuild and manifest at once ? The only reason we have double commits right now is that the $header$ replacement is done by cvs at commit time so if we don't do two commits the checksums all break due to the substitution..how is that repoman's fault? For your use case, it should be possible to just ask Git for updates to the given directory, and apply those to your own tree. Another VCS is another story. If we're switching, it would be nice if the notion of overlays shadowing the main tree would be taken into account. Especially since I don't think Prefix will merge any time soon, but we are plagued by the thing called growth. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Wed, Aug 27, 2008 at 11:57:30AM -0700, Alec Warner wrote: So you are saying we should do what? precompute the CVS header and inject it into $header$ ourselves take the checksums generate the manifest revert the $header$ change then commit the ebuild and manifest at once The only reason we have double commits right now is that the $header$ replacement is done by cvs at commit time so if we don't do two commits the checksums all break due to the substitution..how is that repoman's fault? For those not using SSH ControlMaster, one of the side-effects of having to do two separate commits is the SSH setup latency hitting twice. I wouldn't call it repoman's fault like Fabian did, but the double-commit is why I called it a mess. If we drop the $Header$ in any file covered by a developer-generated Manifest, it becomes a single commit with contents+Manifest :-). -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpn4fdW8Vfv9.pgp Description: PGP signature
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On 27-08-2008 11:57:30 -0700, Alec Warner wrote: For who is it a mess? Not for repoman users, I suppose, and everyone should be using it, right? As the one who personally played with the code in repoman that determines whether or not the double commit is necessary, I think it's mostly a repoman internal problem. The commit script problems put aside. So you are saying we should do what? precompute the CVS header and inject it into $header$ ourselves take the checksums generate the manifest revert the $header$ change then commit the ebuild and manifest at once ? The only reason we have double commits right now is that the $header$ replacement is done by cvs at commit time so if we don't do two commits the checksums all break due to the substitution..how is that repoman's fault? It's not. But I don't see the problem (apart from a race condition with rsync generation) with the two commits either. Incidently the $Header: $ feature just helps me a lot at the moment to keep the Prefix tree up-to-date. Hence, I'm against switching them off or removing them as long as we use CVS for gentoo-x86. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On 27-08-2008 12:15:35 -0700, Robin H. Johnson wrote: For those not using SSH ControlMaster, one of the side-effects of having to do two separate commits is the SSH setup latency hitting twice. I wouldn't call it repoman's fault like Fabian did, but the Right. I thought I suggested that it (the double-commit) is a mess for repoman. Not that it is repoman's fault. double-commit is why I called it a mess. If we drop the $Header$ in any file covered by a developer-generated Manifest, it becomes a single commit with contents+Manifest :-). It seems that what you call mess means needing a double commit for a single repoman commit. That to me isn't a mess, but a performance issue, and as I indicated a possible point of corruption. But we've dealt long enough with the situation without problems to ignore that point. But to repeat: - no I'm not against removing the $Header: $ stuff - yes I'd even like to use another VCS which can make my life easer - but, as long as we're on CVS, I'd prefer it when you'd keep my life sort of bearable - so, keep the $Header: $ stuff for Prefix' sake (me) as long as we're using CVS -- Fabian Groffen Gentoo on a different level
[gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
Hi folks, I'm doing some research on our usages of the $Header$ keyword in our main CVS repo. The primary use-case that has been publicly stated before was for users to be able to identify to developers what version of a given ebuild they were using. Q: How much have you utilized the primary use case? Q: Are there any other use-cases you have and actively use? For evaluating existing uses of the primary case, I took a glance at Bugzilla. There are 624 bugs total that contain a $Header$ with an existing Gentoo path. At least 143 of those are for new packages or version bumps (they copied existing ebuilds). -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpmjeA4IEyQM.pgp Description: PGP signature
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
Hi, On Tue, 26 Aug 2008 13:40:36 -0700 Robin H. Johnson [EMAIL PROTECTED] wrote: I'm doing some research on our usages of the $Header$ keyword in our main CVS repo. Q: Are there any other use-cases you have and actively use? I use the revision present in the header to identify changes in ebuild files that didn't needed a revision dump. Kindest regards, Yuri.
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On T, 2008-08-26 at 13:40 -0700, Robin H. Johnson wrote: The primary use-case that has been publicly stated before was for users to be able to identify to developers what version of a given ebuild they were using. Q: How much have you utilized the primary use case? Never. There has never been a reason to ask this from the user for me. If the ebuild in question has changed without changing name, it has always been obvious if it matters, and if the user has an old version if it does (as then what the bug is about is what was just recently fixed without revbump, typically build fixes). Q: Are there any other use-cases you have and actively use? No. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Tue, Aug 26, 2008 at 03:41:07PM -0500, Yuri Vasilevski wrote: I'm doing some research on our usages of the $Header$ keyword in our main CVS repo. Q: Are there any other use-cases you have and actively use? I use the revision present in the header to identify changes in ebuild files that didn't needed a revision dump. Err, what do you mean by revision dump? -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp0q7G3TIQhD.pgp Description: PGP signature
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Tue, 26 Aug 2008 13:54:21 -0700 Robin H. Johnson [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 03:41:07PM -0500, Yuri Vasilevski wrote: I'm doing some research on our usages of the $Header$ keyword in our main CVS repo. Q: Are there any other use-cases you have and actively use? I use the revision present in the header to identify changes in ebuild files that didn't needed a revision dump. Err, what do you mean by revision dump? revision dump is when foo-1.0-r4 becomes foo-1.0-r5. But when foo-1.0-r4 is updated in-place, I use CVS revisions (ej: 1.12 - 1.13 in 2nd word in $ Header: ) Yuri.
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Tue, Aug 26, 2008 at 03:59:09PM -0500, Yuri Vasilevski wrote: Err, what do you mean by revision dump? revision dump is when foo-1.0-r4 becomes foo-1.0-r5. That's revision 'B'ump, not 'D'ump. But when foo-1.0-r4 is updated in-place, I use CVS revisions (ej: 1.12 - 1.13 in 2nd word in $ Header: ) The $Header$ is filled out automatically by CVS, what are you using the $Header$ string for? Why do you need to identify the changes? Considering that the checksum changes as well, is detecting change not sufficient? (or asking the VCS for what files have changed since your last check time). -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpPq30jIkMcZ.pgp Description: PGP signature
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Tue, 26 Aug 2008 14:45:25 -0700 Robin H. Johnson [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 03:59:09PM -0500, Yuri Vasilevski wrote: Err, what do you mean by revision dump? revision dump is when foo-1.0-r4 becomes foo-1.0-r5. That's revision 'B'ump, not 'D'ump. Sorry, not native English speaker :$ But when foo-1.0-r4 is updated in-place, I use CVS revisions (ej: 1.12 - 1.13 in 2nd word in $ Header: ) The $Header$ is filled out automatically by CVS, what are you using the $Header$ string for? Why do you need to identify the changes? Considering that the checksum changes as well, is detecting change not sufficient? (or asking the VCS for what files have changed since your last check time). I am writing a tool that creates deb (as in Debian package format) based distributions from gentoo packages and that tool encodes the CVS revision as part of debian revision of the packages. So I need this part to be chronologically ordered, as opposed to have only the knowledge of whenever the file has changed or not.
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote: Why do you need to identify the changes? Considering that the checksum changes as well, is detecting change not sufficient? (or asking the VCS for what files have changed since your last check time). I am writing a tool that creates deb (as in Debian package format) based distributions from gentoo packages and that tool encodes the CVS revision as part of debian revision of the packages. So I need this part to be chronologically ordered, as opposed to have only the knowledge of whenever the file has changed or not. I'd call that critically dangerous in missing some changes. If I have a file in $FILESDIR, and change it, but it has the same name, there is no commit to the ebuild, and your .debs won't pick up changes at all. This is usually for cases with compile fixes that don't need revision bumps at all, but sometimes there are also changes to scripts. If you're making binary package .debs, I gather that you are grabbing the (pre|post)(inst|rm) and setup blocks for inclusion? That is an interesting use case, and would that would present a problem with any VCS migration. - Under SVN, you'd only have the global revision, which might not uniquely identify the file. - Bzr doesn't support keyword expansion in any released version. There are/were plans for it in 1.7, but I haven't seen anything since the first prototype. - Hg supports it with an extension: http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension But has warnings about why it sucks http://www.selenic.com/mercurial/wiki/index.cgi/KeywordPlan See the 'keyword update intervals' item (mainly having to touch every file in the repo sometimes). - Git supports only the $Id$ keyword, and expands it to the SHA1 of the file, which ends up being a duplicate of the information we have in the Manifest. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp8kuyAJCBo9.pgp Description: PGP signature
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson schrieb: On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote: I am writing a tool that creates deb (as in Debian package format) based distributions from gentoo packages and that tool encodes the CVS revision as part of debian revision of the packages. So I need this part to be chronologically ordered, as opposed to have only the knowledge of whenever the file has changed or not. snip That is an interesting use case, and would that would present a problem with any VCS migration. I don't see this problem ... I guess it is possible in all VCS to get the information, which global revision touched a specific file last. For example in bzr (these examples are conceived by me - so probably there is an easier way): bzr log -l1 --line $FILE | cut -f1 -d: - --or: to have the unique rev-id instead of the branch-local rev-number-- bzr log -l1 --show-ids $FILE | grep revision-id | cut -f2 -d' ' And hg,svn,git sure have similar abilities. - - Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki0hZQACgkQ4UOg/zhYFuBTrgCeJ/2gfygwUvWCB5QOibsYz0mN sGMAnRmqz/ChCg6zSAVrS4JljP1+DYRV =g5fE -END PGP SIGNATURE-
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
Robin H. Johnson wrote: On Tue, Aug 26, 2008 at 03:59:09PM -0500, Yuri Vasilevski wrote: Err, what do you mean by revision dump? revision dump is when foo-1.0-r4 becomes foo-1.0-r5. That's revision 'B'ump, not 'D'ump. bumb!!
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Tue, 26 Aug 2008 15:25:16 -0700
Robin H. Johnson [EMAIL PROTECTED] wrote:
On Tue, Aug 26, 2008 at 04:57:50PM -0500, Yuri Vasilevski wrote:
Why do you need to identify the changes? Considering that the
checksum changes as well, is detecting change not sufficient? (or
asking the VCS for what files have changed since your last check
time).
I am writing a tool that creates deb (as in Debian package format)
based distributions from gentoo packages and that tool encodes the
CVS revision as part of debian revision of the packages. So I
need this part to be chronologically ordered, as opposed to have
only the knowledge of whenever the file has changed or not.
I'd call that critically dangerous in missing some changes.
If I have a file in $FILESDIR, and change it, but it has the same
name, there is no commit to the ebuild, and your .debs won't pick up
changes at all. This is usually for cases with compile fixes that
don't need revision bumps at all, but sometimes there are also
changes to scripts.
Yes, I know that this will not protect me against changes in a file from
${FILESDIR} nor a change in a file in ${A}, but that was the best way I
could think of to make debian source packages (I create as well) as
reproducible as possible.
For the source packages I create a debian/rules[1] file that basically
calls ebuild foo.ebuild with the right options and to compile and then
install to a temporary directory and then call some debhelper scripts
to turn that directory into a proper .deb package. So from my
perspective the .ebuild file can be considered part of the debian/rules
files and because of that I really need to keep track of changes in it.
And for the rest of files, I bump ( :-D ) another revision counter with
each rebuild of the same debian source package version, so until I find
some better way to catch changes in any bit of the source (be it the
ebuild, files from ${A} or files from ${FILESDIR)/) I still don't have
conflicts.
If you're making binary package .debs, I gather that you are grabbing
the (pre|post)(inst|rm) and setup blocks for inclusion?
Yes, I certainly do.
That is an interesting use case, and would that would present a
problem with any VCS migration.
- Under SVN, you'd only have the global revision, which might not
uniquely identify the file.
- Bzr doesn't support keyword expansion in any released version. There
are/were plans for it in 1.7, but I haven't seen anything since the
first prototype.
- Hg supports it with an extension:
http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension
But has warnings about why it sucks
http://www.selenic.com/mercurial/wiki/index.cgi/KeywordPlan
See the 'keyword update intervals' item (mainly having to touch
every file in the repo sometimes).
- Git supports only the $Id$ keyword, and expands it to the SHA1 of
the file, which ends up being a duplicate of the information we have
in the Manifest.
I am aware about this problem, and unless this is explicitly taken into
consideration on migration, I guess I'll have to keep a local database
of order of ebuilds as part of the metadata associated with each
distribution my tool creates.
[1] debian/rules files is a make file that provides the right targets
for debian tools call it and generate deb binary packages. So it
is kind of the equivalent of .ebuild scripts for debian.
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
On Wed, Aug 27, 2008 at 12:37:09AM +0200, Ren?? 'Necoro' Neumann wrote: - --or: to have the unique rev-id instead of the branch-local rev-number-- bzr log -l1 --show-ids $FILE | grep revision-id | cut -f2 -d' ' IIRC, the revision-id is just like the Git $Id$, it's a hex string, not an incremented counter like the revision number in CVS. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpbbzrUE2Qbx.pgp Description: PGP signature
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson schrieb: On Wed, Aug 27, 2008 at 12:37:09AM +0200, Ren?? 'Necoro' Neumann wrote: - --or: to have the unique rev-id instead of the branch-local rev-number-- bzr log -l1 --show-ids $FILE | grep revision-id | cut -f2 -d' ' IIRC, the revision-id is just like the Git $Id$, it's a hex string, not an incremented counter like the revision number in CVS. True ... it usually looks like [EMAIL PROTECTED] Though, if one enforces certain policies using the main branch located on the server like disallowing pushing and only allowing merges, one can safely use the branch-revno (which is incremental). Only oddity are revnos of merged branches (e.g. 193.1.10) Another approach would be to use the unix-timestamp of the last change. Though it is not a unique identifier per se, it should be sufficient here. It should be queriable in all VCS. Though it might be, that it is not possible using standard CLI and requires a plugin in some way (but I bet, an easy one ;)) - - Necoro -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki0j3UACgkQ4UOg/zhYFuDZ+QCdGm7Sjew2+27KCUB06lWf8aLr XBsAoIbJSke4xHyPiucYEmkuNVd9GPJ3 =jTaO -END PGP SIGNATURE-
Re: [gentoo-dev] Usages of CVS $Header$ keyword in ebuilds - use cases wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 René 'Necoro' Neumann schrieb: Only oddity are revnos of merged branches (e.g. 193.1.10) Gnah - forget this issue.. from the main branch' viewpoint, the last change is always in the merge revision, and not in a revision being merged. So it is guaranteed to be an integer and not a combined thingy as above ;) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki0kZMACgkQ4UOg/zhYFuDftQCfWHv+AvkqNJgZ/VwyIc1AV9WS kJcAoIMmvsPv48GO4ixM4KE25TQtBHkm =F3DM -END PGP SIGNATURE-
