4:05 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
Final RC1 images have been uploaded to EC2 and are available at
ami-3b361952 : us-east-1 image for i386
ami-1337187a : us-east-1 image for x86_64
additionally if your looking to the AMI's they have been added to files
in the release tree
http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/i386/Fedora-Image...
http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/x86_64/Fedora-Ima...
when we get to final and the images are uploaded to all regions
they will all be listed and the file will be gpg signed in the final
tree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJSqYqJAAoJEH7ltONmPFDRvh0QAKYbGMy2o4BW1BArGmqshU2U
YM609IteyjkaMNHJQbCoMUb1IEPXTEsIL+EFITN63NmigAjKXblB7aGyNEsNaPf9
92FCEx4+F9JBKkhd7AP4ZUtyXw9mLTNpKWdS6NY+/5YbH7/7SF3vYMCW0XBcGuZg
7+7pz2zjl/4919Sx7Y0jXnKmkc0mCulePkjjEy3yke7kYJtx+ph8ByqZUDyr4Qy0
6KNN83hIBBVmPCh+BBudiYkct747nh6g6rpXDSAz4K1Y2I9iV9Nd1BYZ+rxtl2Mv
J157JfJA+olTgHF07ZKqcdqOyNaGHH+J8b+k01kUrbOHfQxFul8JZulec0XLuTza
8UBlmyZ9D5NocU+QRZK0d9Fq5y9Ln/IUPAEXemRd0NjPjzA4YS6xj83MMSCx0aJr
7WEHXJ6b2PQBbLbxwASTbA9BBYNCCjrvocAB2xGbLwaKIqRiPdBLlE91QZMPmSM8
Ujw3/S94Ijp2mmlA/WXac6ksD5x1iBmVtNBozpzP8hxWVA0KAe3U+RNsmglgcz4d
tgA7KFy5jcKKbeIriPMerwo4jxfSqXEk3wIfl3iWwWWxyi6Jlnj1VvavJBrfJmsw
tGh858ZNGB7p3aDqf7esvvw5whOMQsfJ1W61xHF1Yc9sXuRI04DPbnbTNIRYzM6A
+6t3IW+zlkqLM68m7+5B
=q5Ww
-----END PGP SIGNATURE-----
8:18 a.m.
Dennis Gilmore <dennis(a)ausil.us> writes:
Hi all,
Final RC1 images have been uploaded to EC2 and are available at
ami-3b361952 : us-east-1 image for i386
ami-1337187a : us-east-1 image for x86_64
Compared to TC5 images:
1) iptables-services package is missing in RC1
2) SELinux contexts. It gets better :-)
In TC5 if you remember we had:
# restorecon -R -v -n -e /proc -e /sys -e /tmp -e /run -e /dev /
restorecon reset /boot/extlinux/ldlinux.sys context
system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0
restorecon reset /var/cache/yum context
system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0
restorecon reset /var/log/boot.log context
system_u:object_r:var_log_t:s0->system_u:object_r:plymouthd_var_log_t:s0
restorecon reset /var/log/cron context
system_u:object_r:var_log_t:s0->system_u:object_r:cron_log_t:s0
In RC1 we have only these:
# restorecon -R -v -n -e /proc -e /sys -e /tmp -e /run -e /dev /
restorecon reset /var/cache/yum context
system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0
restorecon reset /boot/extlinux/ldlinux.sys context
system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0
No other changes/issues noticed.
--
Vitaly Kuznetsov
10:44 a.m.
On Thu, Dec 12, 2013 at 03:18:31PM +0100, Vitaly Kuznetsov wrote:
> ami-3b361952 : us-east-1 image for i386
> ami-1337187a : us-east-1 image for x86_64
Compared to TC5 images:
1) iptables-services package is missing in RC1
This is intentional and by popular demand -- in an IaaS environment, the
cloud provider's security groups or equivalent concept provides the
firewall. If one wants defense-in-depth it's easy to install
iptables-services or firewalld with cloud-init.
2) SELinux contexts. It gets better :-)
In TC5 if you remember we had:
# restorecon -R -v -n -e /proc -e /sys -e /tmp -e /run -e /dev /
restorecon reset /boot/extlinux/ldlinux.sys context
system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0
restorecon reset /var/cache/yum context
system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0
restorecon reset /var/log/boot.log context
system_u:object_r:var_log_t:s0->system_u:object_r:plymouthd_var_log_t:s0
restorecon reset /var/log/cron context
system_u:object_r:var_log_t:s0->system_u:object_r:cron_log_t:s0
I'm pre-creating the two log files, so they end up right.
In RC1 we have only these:
# restorecon -R -v -n -e /proc -e /sys -e /tmp -e /run -e /dev /
restorecon reset /var/cache/yum context
system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0
restorecon reset /boot/extlinux/ldlinux.sys context
system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0
I tried to be clever with changing ldlinux.sys from immutable and back again
but apparently that doesn't do it. (Since this isn't ever actually run on
the system, only _before_ the system, and not on EC2 at all, the
side-effects of a wrong context should be small.)
I'm more concerned about /var/cache/yum, since that is already precreated
and should already be right.
--
Matthew Miller -- Fedora Project Architect -- <mattdm(a)fedoraproject.org>
1:18 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/12/2013 11:44 AM, Matthew Miller wrote:
On Thu, Dec 12, 2013 at 03:18:31PM +0100, Vitaly Kuznetsov wrote:
>> ami-3b361952 : us-east-1 image for i386 ami-1337187a : us-east-1 image
>> for x86_64
> Compared to TC5 images: 1) iptables-services package is missing in RC1
This is intentional and by popular demand -- in an IaaS environment, the
cloud provider's security groups or equivalent concept provides the
firewall. If one wants defense-in-depth it's easy to install
iptables-services or firewalld with cloud-init.
> 2) SELinux contexts. It gets better :-) In TC5 if you remember we had: #
> restorecon -R -v -n -e /proc -e /sys -e /tmp -e /run -e /dev / restorecon
> reset /boot/extlinux/ldlinux.sys context
> system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0 restorecon reset
> /var/cache/yum context
> system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0
> restorecon reset /var/log/boot.log context
> system_u:object_r:var_log_t:s0->system_u:object_r:plymouthd_var_log_t:s0
> restorecon reset /var/log/cron context
> system_u:object_r:var_log_t:s0->system_u:object_r:cron_log_t:s0
I'm pre-creating the two log files, so they end up right.
> In RC1 we have only these: # restorecon -R -v -n -e /proc -e /sys -e /tmp
> -e /run -e /dev / restorecon reset /var/cache/yum context
> system_u:object_r:file_t:s0->system_u:object_r:rpm_var_cache_t:s0
> restorecon reset /boot/extlinux/ldlinux.sys context
> system_u:object_r:file_t:s0->system_u:object_r:boot_t:s0
I tried to be clever with changing ldlinux.sys from immutable and back
again but apparently that doesn't do it. (Since this isn't ever actually
run on the system, only _before_ the system, and not on EC2 at all, the
side-effects of a wrong context should be small.)
I'm more concerned about /var/cache/yum, since that is already precreated
and should already be right.
Any chance this is something mounted on that directory? That the relabel is
not hitting the inode?
Another option would be to just remove this directory. Especially if there is
not content. yum would recreate it on the update.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKqDCAACgkQrlYvE4MpobNp+wCghhrcEdRESombmys7Pu73lbzH
7KQAnj+dM94shsnCtg9z+8ynyZ26RvaB
=wArP
-----END PGP SIGNATURE-----
1:29 p.m.
On Thu, Dec 12, 2013 at 02:18:56PM -0500, Daniel J Walsh wrote:
> I'm more concerned about /var/cache/yum, since that is
already precreated
> and should already be right.
>
Any chance this is something mounted on that directory? That the relabel is
not hitting the inode?
Another option would be to just remove this directory. Especially if there is
not content. yum would recreate it on the update.
Okay, I'll try that and see how it goes. But note that the fix for the other
files was to precreate them -- I'm not... actually sure why that works, but
it indicates that something isn't happening right when new files are created
at runtime. I've been meaning to talk to you about that. :)
--
Matthew Miller -- Fedora Project Architect -- <mattdm(a)fedoraproject.org>
2:46 p.m.
On 12/12/2013 02:29 PM, Matthew Miller wrote:
On Thu, Dec 12, 2013 at 02:18:56PM -0500, Daniel J Walsh wrote:
>> I'm more concerned about /var/cache/yum, since that is already precreated
>> and should already be right.
>>
> Any chance this is something mounted on that directory? That the relabel is
> not hitting the inode?
>
> Another option would be to just remove this directory. Especially if there is
> not content. yum would recreate it on the update.
fwiw that's what we did for rhel 7.
Okay, I'll try that and see how it goes. But note that the fix for the other
files was to precreate them -- I'm not... actually sure why that works, but
it indicates that something isn't happening right when new files are created
at runtime. I've been meaning to talk to you about that. :)
10:07 a.m.
Matthew Miller <mattdm(a)fedoraproject.org> writes:
On Thu, Dec 12, 2013 at 02:18:56PM -0500, Daniel J Walsh wrote:
> > I'm more concerned about /var/cache/yum, since that is already precreated
> > and should already be right.
> >
> Any chance this is something mounted on that directory? That the relabel is
> not hitting the inode?
>
> Another option would be to just remove this directory. Especially if there is
> not content. yum would recreate it on the update.
Okay, I'll try that and see how it goes. But note that the fix for the other
files was to precreate them -- I'm not... actually sure why that works, but
it indicates that something isn't happening right when new files are created
at runtime. I've been meaning to talk to you about that. :)
I tried installing F20 from ISO and '/var/cache/yum' has proper
'rpm_var_cache_t' context after install. It seems anaconda has hackaround for
that:
https://git.fedorahosted.org/cgit/anaconda.git/tree/data/post-scripts/80-...
I have an (crazy?) idea about how it happened: '/var/cache/yum' belongs
to yum and can be installed really early in the install queue before
selinux policy is installed. So it gets default 'file_t' instead of
'rpm_var_cache_t'.
--
Vitaly Kuznetsov
5:47 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Thu, 12 Dec 2013 04:05:55 -0600
Dennis Gilmore <dennis(a)ausil.us> escribió:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
Final RC1 images have been uploaded to EC2 and are available at
ami-3b361952 : us-east-1 image for i386
ami-1337187a : us-east-1 image for x86_64
additionally if your looking to the AMI's they have been added to
files in the release tree
http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/i386/Fedora-Image...
http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/x86_64/Fedora-Ima...
when we get to final and the images are uploaded to all regions
they will all be listed and the file will be gpg signed in the final
tree
Note, these are the GA images.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJSqvPfAAoJEH7ltONmPFDRMPMQANGbtuzCgRFIS40kyoxXVz3j
bObUUfAjpZMIKoP0KW5AHA4JInfkb1ZCTSrPDVX/AhHq5uKw2oTHPiHeDP6wvPMk
ZL+MFEhmq9Qku+Lf0aPqEsv/JhdI1TmCLxA5da+1Qm/8X+MMRGH97K1yIrb+D/rK
r1T97K1yw+6PlBPquBrtE6XRAp5hus1GmZltb1660Tq/QLpexxz3T45YbieDEaOD
zNndVoKyBTJiqqym34DFjomG02D3YzH2Mn790tFzrEUrKZYduYWwabY/MWcmYDXu
gehBTahOxdnykp3ZXDey8aksi0cgFseLoPX2fRpyc5ivhlvDlsO99enqPLqA5hZd
4eF3FoN8kvS8f+u8PcIMW6mdVMpDYQBGfxa0EB+NAQyiY6/5mPI6dFZDUlu84SUB
GOUDI7xOsBkoTyU9aQwH2KTtS0TkQNZ+fEZUI7xF7f46eKqSANxDSgewl8yehyZx
CCTrG3GRXU8qt7SK2hja2aO4L9KNlDAKGTNhejeoV1z8cL2xT6shrnsB8ohXLefA
By7J5Mv742x+/P48eaJtWvZmRGhEcEfu/0Iluu2VD+fcmAWjpLR8A9urG5mpj84l
Q4iqrcUIXhV8TSh79Nt5MGVZ5Wgh1k0nPw1j5AnSsZ8/F7DhmJrLojWDv5KdLqq+
OHWvu7mwiMbUzdCMSbTS
=D/B7
-----END PGP SIGNATURE-----
9:46 a.m.
On Fri, Dec 13, 2013 at 05:47:38AM -0600, Dennis Gilmore wrote:
> additionally if your looking to the AMI's they have been
added to
> files in the release tree
>
http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/i386/Fedora-Image...
>
http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/x86_64/Fedora-Ima...
> when we get to final and the images are uploaded to all regions
> they will all be listed and the file will be gpg signed in the final
> tree
Note, these are the GA images.
Hey Dennis, will the images going to mirrors be these or the ones with the
extra RC1.1 dot, like "Fedora-x86_64-20-20131211.1-sda.qcow2"?
--
Matthew Miller -- Fedora Project Architect -- <mattdm(a)fedoraproject.org>
10:05 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Fri, 13 Dec 2013 10:46:16 -0500
Matthew Miller <mattdm(a)fedoraproject.org> escribió:
On Fri, Dec 13, 2013 at 05:47:38AM -0600, Dennis Gilmore wrote:
> > additionally if your looking to the AMI's they have been added to
> > files in the release tree
> >
http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/i386/Fedora-Image...
> >
http://dl.fedoraproject.org/pub/alt/stage/20-RC1/Images/x86_64/Fedora-Ima...
> > when we get to final and the images are uploaded to all regions
> > they will all be listed and the file will be gpg signed in the
> > final tree
> Note, these are the GA images.
Hey Dennis, will the images going to mirrors be these or the ones
with the extra RC1.1 dot, like
"Fedora-x86_64-20-20131211.1-sda.qcow2"?
The Images in RC1 and RC1.1 are exactly the same. the changes in the
RC1.1 compose was just to respin the install tree making sure that none
of the older libreoffice packages were in the tree.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJSq9j6AAoJEH7ltONmPFDRBQgP/3TOfEMHOKFNegGA8KyOCDFa
kAeC8K8xx6xw7BLRjtoMK4N6/ol/GUUoLiC8stbs6r9M2oBfWYBcwEh01gki3mmx
yPW2NtKj5OWlbvh+t7MnO6vVUNybPV3lJnkCNAIWdTUM1SMct5nfRWFO15PYcCe7
SMHIwBkCMHF2x0d5tuySO7iNWyfraS/Ih+Eg2K2cjRrCMMmvCYxRcv2DWEMt3eb0
poC3kLgH3+z8fO/20Yb77Y0Sd+wPgWresUp/No0+sdMWN8wmUDoT/RV3WZsbfyE9
ESZnvER87DUokz7k0LctfRnwxl0Qt+V+Ib9vd5Thg+bMxFLgzm37dvd3f+cJoKR7
3B9BFteYpjk2JbCnxRY/bTiZ/2+uZ8pfNbYP0Yb6p+hBR4rxk8GSqd4Al9uCAlF9
EtkgzvYnM+f5YHvHQ60w1BovEpIwJNLvxFkhGJbGn78taUrHTC6cM1hLo2Zz0msV
N90ySYYdUS/gb16X35A7b5z0vFFq1PkZgBSHv++rPlZA98vtatFf1mFz1yx/wS7d
vGVnayERYKu7sn1pWXKEX0D/Us+gSqDmqXn9fqZa/oQFYyyItOytpkF+GMpnYwjZ
vp4H2plFm3Wz5sgP4Z8QaQ0a4s8DWkjF4p0yZFw/MSha3ydti7sLMo4brIbUShra
zryVtyd1AdaETEsrNk0I
=N+px
-----END PGP SIGNATURE-----
10:13 p.m.
On Fri, Dec 13, 2013 at 10:05:05PM -0600, Dennis Gilmore wrote:
> > Note, these are the GA images.
> Hey Dennis, will the images going to mirrors be these or the ones
> with the extra RC1.1 dot, like
> "Fedora-x86_64-20-20131211.1-sda.qcow2"?
The Images in RC1 and RC1.1 are exactly the same. the changes in the
RC1.1 compose was just to respin the install tree making sure that none
of the older libreoffice packages were in the tree.
Right, sorry, I wasn't clear. I know that part, but I'm wondering what the
actual filename going to the mirrors will be. This is important for the web
site and short links.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
2:50 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Fri, 13 Dec 2013 23:13:01 -0500
Matthew Miller <mattdm(a)mattdm.org> escribió:
On Fri, Dec 13, 2013 at 10:05:05PM -0600, Dennis Gilmore wrote:
> > > Note, these are the GA images.
> > Hey Dennis, will the images going to mirrors be these or the ones
> > with the extra RC1.1 dot, like
> > "Fedora-x86_64-20-20131211.1-sda.qcow2"?
> The Images in RC1 and RC1.1 are exactly the same. the changes in the
> RC1.1 compose was just to respin the install tree making sure that
> none of the older libreoffice packages were in the tree.
Right, sorry, I wasn't clear. I know that part, but I'm wondering
what the actual filename going to the mirrors will be. This is
important for the web site and short links.
We do not change file names when composed. what they are in the RC is
what they will be when shipped.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJSrBvwAAoJEH7ltONmPFDR1wgP/2zX6H9Tvp8WEuiHBo5n1rLp
N8sJSJ5VrtR26tqtCEI5DHaujOHjGTwEPMP/QZqXTomm6gQVg6/cgcalL8d8PV+r
/3Cx2epQxX28/ln4xVLI+3PdMXVErl01hEXVnXmAbuwdToUhi1jiDmbDVcpnAUv7
ibwqBn6V3nbk4ThCbfu1Wy2zRHR0qAFo689dsum/mlZPpU7ZelwqcQ7iOimpHvL7
ZwQ38rG1oLJZ0EfW7oe97w8pksn8mCOXdB+DIA17IEMlMWao4cxQ8SAXNsfyyx7l
jwFuPHKAlb0kmDLaqqVljpzx+J7Zibe0aIImbXQ5cDFyiC1ZmRwR9ed2P0SzIscJ
hIL9CPPi0I0nd+dxlIlTGbqu9sRddRVl3O6p4RVsizrrTJ9zF4Ft/MOWBrShlSsP
RnrqiFGR29hP9d/XGA+N0WRFeFfLdrxknrVtIfzV6e8kYgHvdeWh/yRt4WmZDJ8V
5kc84uBBxL/CFZWBrhNbnZmEkoH8qEyrzXkVp6q+ePsGBWROHSX3Gt4eu8TNFsoS
AZtXSfg8tSZnash6nCdTqcEuA0Avc6RA00SaUNHplQlpN8D42MyvCgNeWZNUyZta
+IwOll7skZUIcPvxgnnHpqyhEfJLP+UeYX0+2QPx9/YnupAyiMQDDTOErZCrZdzs
ClvuHNedf0dQLC2kVSHj
=UzA+
-----END PGP SIGNATURE-----
1:22 p.m.
On Sat, Dec 14, 2013 at 02:50:50AM -0600, Dennis Gilmore wrote:
> > > Hey Dennis, will the images going to mirrors be these
or the ones
> > > with the extra RC1.1 dot, like
> > > "Fedora-x86_64-20-20131211.1-sda.qcow2"?
> > The Images in RC1 and RC1.1 are exactly the same. the changes in the
> > RC1.1 compose was just to respin the install tree making sure that
> > none of the older libreoffice packages were in the tree.
> Right, sorry, I wasn't clear. I know that part, but I'm wondering
> what the actual filename going to the mirrors will be. This is
> important for the web site and short links.
We do not change file names when composed. what they are in the RC is
what they will be when shipped.
I see that the RC1 tree now alo contains
Fedora-x86_64-20-20131211.1-sda.qcow2 -- I am pretty sure that it was
previously Fedora-x86_64-20-20131211-sda.qcow2, without the .1. That is what
I was referring to.
--
Matthew Miller -- Fedora Project Architect -- <mattdm(a)fedoraproject.org>
4:20 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Sat, 14 Dec 2013 14:22:42 -0500
Matthew Miller <mattdm(a)fedoraproject.org> escribió:
On Sat, Dec 14, 2013 at 02:50:50AM -0600, Dennis Gilmore wrote:
> > > > Hey Dennis, will the images going to mirrors be these or the
> > > > ones with the extra RC1.1 dot, like
> > > > "Fedora-x86_64-20-20131211.1-sda.qcow2"?
> > > The Images in RC1 and RC1.1 are exactly the same. the changes
> > > in the RC1.1 compose was just to respin the install tree making
> > > sure that none of the older libreoffice packages were in the
> > > tree.
> > Right, sorry, I wasn't clear. I know that part, but I'm wondering
> > what the actual filename going to the mirrors will be. This is
> > important for the web site and short links.
> We do not change file names when composed. what they are in the RC
> is what they will be when shipped.
I see that the RC1 tree now alo contains
Fedora-x86_64-20-20131211.1-sda.qcow2 -- I am pretty sure that it was
previously Fedora-x86_64-20-20131211-sda.qcow2, without the .1. That
is what I was referring to.
the .1 is refering to the RC that it was. there is issues using just
the date, it clashes with the nightly images for one. if we had done a
rc2 there would have been a .2 at the end.
going forward Im going to name the images as we do for ARM and livecds
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJSrNmnAAoJEH7ltONmPFDRLc0P/RqkGeQ/svpoeTkDXIIfyegl
L5lVbuQOB//Tviwq/3uGSt9vaR06EqniKpP9phSdwMxiXO5de0JQe/CAejiQvpsu
Ko/ZwhMznDGCTar+okKs+FjtroC5ZYoHlU7afiAS/ZCo10QPYHsvsmnmccqKmvM9
ZYVUBha0fg++bWZzxXcblzh9kFzB/dny+s+dMpEVhi14kdcq9Fp26ncLmZ/4g1m8
vT/08vFLXA9hrUBDirDJXz3PNdLRZ6GWIoU8cSVdqPEu8bG6os00OxAtuCQyuvvs
/TLjFLQBXmCWwZfebDEQDZu3PFTCBcnHWM3IcHizj3Eauwh9dsa1R8iVAR9hbbMv
iFPHNRoLNxtiUkxNXVVBZJqaulOkyD5/eqBIdqhPMaDX5rIXWz84DMQPjL5FwDbT
//n3tHWIe5Vpco8czaAJJXxFIcKbuEhnxWesIgdXuuXmVdya3ceJdoj6QzR64k+/
xj0xGYXYwxM61rZdxibY3P5a32IGgg8OKkmq+57s8chUNp5xpkq1giDGbQON/C9z
8SKO3Yhmo1ckpfezVy1Mw7sbJ79oiHqVVkMfJVxcX3vPDnZ0TNsn1u5Rsc9btRHf
UF5dVGzDtusthxfzQjv2ToRru+8ebiF8oVp1BVCgSd8hobHuosOoxf0cNf7DaeKG
IA/QRfSEZ4zACly/inpf
=hXgD
-----END PGP SIGNATURE-----
3779
days inactive
3781
days old
13 comments
6 participants
participants (6)
-
Daniel J Walsh -
Dennis Gilmore -
Jay Greguske -
Matthew Miller -
Matthew Miller -
Vitaly Kuznetsov