Re: [gentoo-dev] GLEP59 - Manifest2 hashes
On Sun, Jan 31, 2010 at 3:57 AM, Robin H. Johnson wrote: > > The SHA512 algorithm is available in Python 2.5, which has been a > dependency of Portage since approximately Python 2.1.6.13. I hate to nitpick, but I believe you meant Portage in that line. However, great work on this GLEP, you've put forth some good solid research into it. I do hope that we don't intend on settling on SHA512 as the end all solution as well. We should retain a method for bumping the hashing algorithm used when the SHA-3 family becomes available. -- Doug Goldstein
Re: [gentoo-dev] openssl 1.0.0 quick test
В Сбт, 30/01/2010 в 13:19 +0100, Hanno Böck пишет: > - php fails, fix is trivial. I've sent it upstream and it got already applied > to upstream svn: > http://bugs.php.net/bug.php?id=50859 > - wvstreams fails, fix also trivial and sent upstream, no reply yet: > http://code.google.com/p/wvstreams/issues/detail?id=27 > - ruby fails (both the 1.8/1.9 versions from the tree and the latest from the > ruby-overlay), fix seems to be non-trivial. There is some upstream work on it > I haven't tested: > http://redmine.ruby-lang.org/issues/show/2022 > > So all in all it's not that much. I'll leave it up to the maintainers of php > and wvstreams if they want to patch their packages or wait till upstream > fixes > arrive. Please report this issues in our bugzilla. And it's good idea to start openssl-1.x tracker. -- Peter.
[gentoo-dev] [RFC] Font eclass EAPI update and design
Hi guys,
As I was reworking the x-modular-r2 eclass I found out that most of the
slowdowns for fonts were produced in fonts eclass.
Since we were the guys who are supposed to update it, I redesign it to
be bit faster and also to support all known eapis.
I would like to ask you to review the changes and spot anything that
might slipped my sight.
(Diff and full eclass attached)
Expected addition to main tree: if nothing huge is found after fosdem,
otherwise in 3 weeks
Cheers
Tomas
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: font.eclass
# @MAINTAINER:
# fo...@gentoo.org
# Author: Tomáš Chvátal
# Author: foser
# @BLURB: Eclass to make font installation uniform
inherit eutils
EXPORT_FUNCTIONS pkg_setup src_install pkg_postinst pkg_postrm
# @ECLASS-VARIABLE: FONT_SUFFIX
# @DESCRIPTION:
# Space delimited list of font suffixes to install
: ${FONT_SUFFIX:=}
# @ECLASS-VARIABLE: FONT_S
# @DESCRIPTION:
# Dir containing the fonts
: ${FONT_S:=${S}}
# @ECLASS-VARIABLE: FONT_PN
# @DESCRIPTION:
# Last part of $FONTDIR
: ${FONT_PN:=${PN}}
# @ECLASS-VARIABLE: FONTDIR
# @DESCRIPTION:
# This is where the fonts are installed
: ${FONTDIR:-/usr/share/fonts/${FONT_PN}}
# @ECLASS-VARIABLE: FONT_CONF
# @DESCRIPTION:
# Array, which element(s) is(are) path(s) of fontconfig-2.4 file(s) to install
FONT_CONF=( "" )
# @ECLASS-VARIABLE: DOCS
# @DESCRIPTION:
# Docs to install
: ${DOCS:-}
IUSE="X"
DEPEND="X? (
x11-apps/mkfontdir
media-fonts/encodings
)
media-libs/fontconfig"
# @FUNCTION: font_xfont_config
# @DESCRIPTION:
# Creates the Xfont files.
font_xfont_config() {
# create Xfont files
if has X ${IUSE//+} && use X ; then
ebegin "Creating fonts.scale & fonts.dir"
rm -f "${ED}${FONTDIR}"/fonts.{dir,scale}
mkfontscale "${ED}${FONTDIR}"
mkfontdir \
-e ${EPREFIX}/usr/share/fonts/encodings \
-e ${EPREFIX}/usr/share/fonts/encodings/large \
"${ED}${FONTDIR}"
eend $?
if [ -e "${FONT_S}/fonts.alias" ] ; then
doins "${FONT_S}/fonts.alias"
fi
fi
}
# @FUNCTION: font_xft_config
# @DESCRIPTION:
# Creates the fontconfig cache if necessary.
font_xft_config() {
# create fontconfig cache
ebegin "Creating fontconfig cache"
fc-cache -sf "${ED}${FONTDIR}"
eend $?
}
# @FUNCTION: font_fontconfig
# @DESCRIPTION:
# Installs the fontconfig config files of FONT_CONF.
font_fontconfig() {
local conffile
if [[ -n ${font_co...@]} ]]; then
insinto /etc/fonts/conf.avail/
for conffile in "${font_co...@]}"; do
[[ -e ${conffile} ]] && doins ${conffile}
done
fi
}
# @FUNCTION: font_src_install
# @DESCRIPTION:
# The font src_install function.
font_src_install() {
local suffix commondoc
pushd "${FONT_S}" > /dev/null
insinto "${FONTDIR}"
for suffix in ${FONT_SUFFIX}; do
doins *.${suffix}
done
rm -f fonts.{dir,scale} encodings.dir
font_xfont_config
font_xft_config
font_fontconfig
popd > /dev/null
[[ -n ${DOCS} ]] && { dodoc ${DOCS} || die "docs installation failed" ;
}
# install common docs
for commondoc in COPYRIGHT README{,.txt} NEWS AUTHORS BUGS ChangeLog
FONTLOG.txt; do
[[ -s ${commondoc} ]] && dodoc ${commondoc}
done
}
# @FUNCTION: font_pkg_setup
# @DESCRIPTION:
# The font pkg_setup function.
# Collision portection and Prefix compat for eapi < 3.
font_pkg_setup() {
# make sure we get no collisions
# setup is not the nicest place, but preinst doesn't cut it
[[ -e "${FONTDIR}/fonts.cache-1" ]] && rm -f "${FONTDIR}/fonts.cache-1"
# Prefix compat
case ${EAPI:-0} in
0|1|2)
if ! use prefix; then
EPREFIX=
ED=${D}
EROOT=${ROOT}
[[ ${EROOT} = */ ]] || EROOT+="/"
fi
;;
esac
}
# @FUNCTION: font_pkg_postinst
# @DESCRIPTION:
# The font pkg_postinst function.
# Update global font cache and fix permissions.
font_pkg_postinst() {
# unreadable font files = fontconfig segfaults
find "${EROOT}"usr/share/fonts/ -type f '!' -perm 0644 -print0 \
| xargs -0 chmod -v 0644 2>/dev/null
if [[ -n ${font_co...@]} ]]; then
local conffile
echo
elog "The following fontconfig configuration files have been
installed:"
elog
for conffile in "${font_co...@]}"; do
[gentoo-dev] Re: [RFC] Font eclass EAPI update and design
В Пнд, 01/02/2010 в 11:35 +0100, Tomáš Chvátal пишет:
> As I was reworking the x-modular-r2 eclass I found out that most of the
> slowdowns for fonts were produced in fonts eclass.
Exactly what slowdowns are you talking about? I've reviewed all changes
and I don't see any noticeable performance improvements anywhere. Or
what do you mean?
> I would like to ask you to review the changes and spot anything that
> might slipped my sight.
1.
-FONT_SUFFIX=${FONT_SUFFIX:-}
+: ${FONT_SUFFIX:=}
What are the benefits of this change? Personally I prefer first syntax
more since it's more evident and does not need to run empty command :
2.
if has X ${IUSE//+} && use X ; then
I'm not sure. With this change should we update all packages depending
on font.eclass to have X in IUSE?
3.
If you dropped
if has_version '>=media-libs/fontconfig-2.4'; then
then >=media-libs/fontconfig-2.4 should be in DEPEND.
4.
+ [[ -n ${DOCS} ]] && { dodoc ${DOCS} || die "docs installation
failed" ; }
This should be non fatal, until somebody installs all packages that
inherit font.eclass and assures us that nothing broke with this change.
--
Peter.
h
[gentoo-dev] Re: [RFC] Font eclass EAPI update and design
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dne 1.2.2010 14:14, Peter Volkov napsal(a):
> В Пнд, 01/02/2010 в 11:35 +0100, Tomáš Chvátal пишет:
>> As I was reworking the x-modular-r2 eclass I found out that most of the
>> slowdowns for fonts were produced in fonts eclass.
>
> Exactly what slowdowns are you talking about? I've reviewed all changes
> and I don't see any noticeable performance improvements anywhere. Or
> what do you mean?
Well it might be visible if you use some font from overlay and from main
tree (overlay use also the x-modular-r2) not sure which changes helped
it more :P
>
>> I would like to ask you to review the changes and spot anything that
>> might slipped my sight.
>
> 1.
> -FONT_SUFFIX=${FONT_SUFFIX:-}
> +: ${FONT_SUFFIX:=}
>
> What are the benefits of this change? Personally I prefer first syntax
> more since it's more evident and does not need to run empty command :
I am just used to this syntax. I dont think it is so huge issue that it
would need revert.
>
> 2.
> if has X ${IUSE//+} && use X ; then
>
> I'm not sure. With this change should we update all packages depending
> on font.eclass to have X in IUSE?
Nak this specialy allows that you dont have to keep X in iuse.
But it does not matter anyway because it is and was always defined by
eclass. But with this syntax it allows us to remove that IUSE="X" from
eclass global scope at some point.
>
> 3.
> If you dropped
>
> if has_version '>=media-libs/fontconfig-2.4'; then
>
> then >=media-libs/fontconfig-2.4 should be in DEPEND.
Probably yes, but think when was the 2.3 removed from portage :] (Jul 2007).
Dep added.
>
> 4.
> + [[ -n ${DOCS} ]] && { dodoc ${DOCS} || die "docs installation
> failed" ; }
>
> This should be non fatal, until somebody installs all packages that
> inherit font.eclass and assures us that nothing broke with this change.
>
Actualy former behaviour was violating QA rules for dodoc, so it should
be fixed anyway.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAktm1y8ACgkQHB6c3gNBRYe7GACfclA2J/2eMSw/wZJnfT9E2/4G
uB0AnRhnJ9RoiaoMwTkPASFMSlEx4XkY
=f/72
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: [RFC] Font eclass EAPI update and design
В Пнд, 01/02/2010 в 14:29 +0100, Tomáš Chvátal пишет:
> > 2.
> > if has X ${IUSE//+} && use X ; then
> >
> > I'm not sure. With this change should we update all packages depending
> > on font.eclass to have X in IUSE?
> Nak this specialy allows that you dont have to keep X in iuse.
> But it does not matter anyway because it is and was always defined by
> eclass. But with this syntax it allows us to remove that IUSE="X" from
> eclass global scope at some point.
Do we have such goal? Where this is useful?
> > 4.
> > + [[ -n ${DOCS} ]] && { dodoc ${DOCS} || die "docs installation
> > failed" ; }
> >
> > This should be non fatal, until somebody installs all packages that
> > inherit font.eclass and assures us that nothing broke with this change.
> Actualy former behaviour was violating QA rules for dodoc, so it should
> be fixed anyway.
And yet we have more strong policy that states "not to break the tree".
Since previous version of eclass issued no warning about missed
documentation, it's highly probable that lot's of font packages will
fail to emerge after this change (we already had one report, while
eclass is in x11 overlay only)... So this is no go, until somebody
checks that no package (at least in stable tree) became broken by this
change.
--
Peter.
[gentoo-dev] Recent lists mail loss
As the listadmin, I'd like to apologize for some recent lists mail loss. A spammer managed to get a subscription confirmation email send to a spamtrap address, that promptly caused the lists server to be listed on a blacklist for 12-14 hours. During that time, approximately 2000 list deliveries were rejected due to the RBL. First recorded rejection was around Feb 1 00:20 UTC, last recorded was Feb 1 13:35 UTC. I've included full log details in a blogpost: http://robbat2.livejournal.com/236942.html If you know anybody that runs similar spamtraps, please ask them to ensure list confirmation requests are NOT treated as spam. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpr3thPAg5pi.pgp Description: PGP signature
[gentoo-dev] Re: [RFC] Font eclass EAPI update and design
On Mon, 01 Feb 2010 14:29:19 +0100
Tomáš Chvátal wrote:
> Dne 1.2.2010 14:14, Peter Volkov napsal(a):
> > 1.
> > -FONT_SUFFIX=${FONT_SUFFIX:-}
> > +: ${FONT_SUFFIX:=}
> >
> > What are the benefits of this change? Personally I prefer first syntax
> > more since it's more evident and does not need to run empty command :
> I am just used to this syntax. I dont think it is so huge issue that it
> would need revert.
No thanks. The second form is unreadable.
> > 4.
> > + [[ -n ${DOCS} ]] && { dodoc ${DOCS} || die "docs installation
> > failed" ; }
> >
> > This should be non fatal, until somebody installs all packages that
> > inherit font.eclass and assures us that nothing broke with this change.
> >
> Actualy former behaviour was violating QA rules for dodoc, so it should
> be fixed anyway.
Well then the QA rules for dodoc are dumb. :P There is no reason for an
ebuild to die when a generic doc file doesn't get installed.
The prefix changes are welcome assuming they've been tested.
--
fonts,by design, by neglect
gcc-porting, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
[gentoo-dev] Monthly Gentoo Council Reminder for February
This is your monthly friendly reminder ! Same bat time (typically the 3rd Thursday at 1800 UTC / 2000 CET / 1400 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every GLEP *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/
Re: [gentoo-dev] Monthly Gentoo Council Reminder for February
On Mon, Feb 1, 2010 at 4:30 PM, Mike Frysinger wrote: > This is your monthly friendly reminder ! Same bat time (typically > the 3rd Thursday at 1800 UTC / 2000 CET / 1400 EST), same bat channel > (#gentoo-council @ irc.freenode.net) ! Uh... no. The meeting is actually next Monday (January 8th) at 2000UTC / 2100CET / 1500 EST. We now adapt the date and time to suit our schedules and maximize everybody's chance to be available. Mike, could you please stop your cron job? It's now useless as I have to send the reminder email manually, which I do more or less two weeks in advance. Thanks, Denis.
Re: [gentoo-dev] GLEP59 - Manifest2 hashes
On Mon, Feb 1, 2010 at 1:23 AM, Doug Goldstein wrote: > However, great work on this GLEP, you've put forth some good solid > research into it. Agreed. I would suggest to use this series of GLEPs as examples of what to do for future GLEP writers. > I do hope that we don't intend on settling on SHA512 as the end all > solution as well. We should retain a method for bumping the hashing > algorithm used when the SHA-3 family becomes available. >From the way I understand it the GLEP implies that we can add hashes at will. But that's a good point, and a one-liner somewhere making it explicit would be useful. Thus, in "What should be done" I would I would for example replace "We should be prepared to add stronger checksums wherever possible, and to remove those that have been defeated." with: "Stronger checksums shall be added as soon as an implementation is available in Portage. Weak checksums may be removed as long as the depreciation process is followed (see below)." And then, in "Checksum depreciation timing" I would prefer that the description of what needs to be done in the present situation was used as an example after a more general rule is stated. Something like: "At least one older algorithm must remain until the new one(s) has (have) been in stable Portage for minimum one year." The one year period is debatable, what matters is we have well defined rules in order to avoid future flamewars. Denis.
Re: [gentoo-dev] GLEP59 - Manifest2 hashes
On Mon, Feb 01, 2010 at 02:23:42AM -0600, Doug Goldstein wrote: > On Sun, Jan 31, 2010 at 3:57 AM, Robin H. Johnson wrote: > > > > > The SHA512 algorithm is available in Python 2.5, which has been a > > dependency of Portage since approximately Python 2.1.6.13. > > I hate to nitpick, but I believe you meant Portage in that line. Thanks :-) Fixed. > However, great work on this GLEP, you've put forth some good solid > research into it. > > I do hope that we don't intend on settling on SHA512 as the end all > solution as well. We should retain a method for bumping the hashing > algorithm used when the SHA-3 family becomes available. The present Portage logic I believe requires SHA1 still be present (so I'm not sure how good the second patch I gave would be), and I'd like that to change to rather be the strongest supported & available algorithm. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp6HykmYofid.pgp Description: PGP signature
[gentoo-dev] dev-db/mysql-community security masking, users must move to dev-db/mysql
# Robin H. Johnson (01 Feb 2010) # Upstream discontinued the split of -community and -enterprise specific # tarballs of source. You must move to dev-db/mysql as the -community split has # security vulnerabilities only fixed in the main package. # To be removed 2010/07/01. dev-db/mysql-community -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpIs9ed8IT4t.pgp Description: PGP signature
Re: [gentoo-dev] GLEP58 - MetaManifest
You'll find below an email from solar to Robin about MetaManifest. I'm adding it to this thread (with solar's authorization) as it seems pertinent. Denis. On Thu, Jan 21, 2010 at 6:51 PM, Ned Ludd wrote: > Robin, > > I recall you wanted me to mail you what we talked about last nite in > #gentoo-portage and I'll CC: the council so they have an idea what to > maybe expect. > > So in our talking last night we discussed the fact that if the Manifest > format has to change why not just get rid of it all together, and save > some serious in tree space with the new MetaManifest's taking over all > together. This would include MetaManifest's at the 2-level. > You said the MetaManifest would need about 4 fields in them to describe > the distfiles etc. Devs would still push normal Manifest's to the cvs > tree so DIST can be obtained by the backend infra scripts. But those > Manifest's could be dropped from the mirroring. if [ -e CVS ] then > portage would need to use the existing Manifest's > > This method would hands down win my vote. As you know I'm not a fan of > format changes in general as they can make the Gentoo experience suck, > but if we are going to change formats. Lets do it right. > > The only downside I can see in this method is for people like drobbins > who mirror our tree but overlay right on top of it then provide it back > out. In such cases we should provide our backend scripts to the public > so they can re MetaManifest. > > I'm probably forgetting all sorts of details from the chat. But > hopefully this is enough to remind you, as well as giving the other > council ppl an idea of what to maybe expect.
Re: [gentoo-dev] Recent lists mail loss
On Mon, Feb 1, 2010 at 11:40 AM, Robin H. Johnson wrote: > As the listadmin, I'd like to apologize for some recent lists mail loss. > > A spammer managed to get a subscription confirmation email send to a > spamtrap address, that promptly caused the lists server to be listed on > a blacklist for 12-14 hours. > > During that time, approximately 2000 list deliveries were rejected due > to the RBL. First recorded rejection was around Feb 1 00:20 UTC, last > recorded was Feb 1 13:35 UTC. > > I've included full log details in a blogpost: > http://robbat2.livejournal.com/236942.html > > If you know anybody that runs similar spamtraps, please ask them to > ensure list confirmation requests are NOT treated as spam. > > -- > Robin Hugh Johnson > Gentoo Linux: Developer, Trustee & Infrastructure Lead > E-Mail : robb...@gentoo.org > GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 > Woah so thats why I had to move the subscribe messages to the Inbox in gmail. THey may be CONNECTED TO THAT SPAM LIST!!
Re: [gentoo-dev] GLEP58 - MetaManifest
On Mon, Feb 01, 2010 at 11:27:01PM -0700, Denis Dupeyron wrote:
> You'll find below an email from solar to Robin about MetaManifest. I'm
> adding it to this thread (with solar's authorization) as it seems
> pertinent.
>
> Denis.
>
> On Thu, Jan 21, 2010 at 6:51 PM, Ned Ludd wrote:
> > Robin,
> >
> > I recall you wanted me to mail you what we talked about last nite in
> > #gentoo-portage and I'll CC: the council so they have an idea what to
> > maybe expect.
> >
> > So in our talking last night we discussed the fact that if the Manifest
> > format has to change why not just get rid of it all together, and save
> > some serious in tree space with the new MetaManifest's taking over all
> > together. This would include MetaManifest's at the 2-level.
> > You said the MetaManifest would need about 4 fields in them to describe
> > the distfiles etc. Devs would still push normal Manifest's to the cvs
> > tree so DIST can be obtained by the backend infra scripts. But those
> > Manifest's could be dropped from the mirroring. if [ -e CVS ] then
> > portage would need to use the existing Manifest's
First, I'd like to clarify one things for all other readers, as it isn't
clear for anybody else just reading this email.
Solar's proposal does the following:
1. Tree in CVS/VCS:
- drop ALL Manifest2 lines _EXCEPT_ DIST.
2. Tree available via rsync:
- Manifests at the following locations ONLY:
- /MetaManifest
- /${CAT}/Manifest
- /profiles/Manifest
- /eclasses/Manifest
- /metadata/cache/${CAT}/Manifest
- /metadata/glsa/Manifest
- Data from ALL Manifests get moved to one of the above.
- MISC/EBUILD etc (non-DIST) lines generated at the same time that the
rsync tree is prepared.
3. Net savings of approximately 13000 inodes, as the per package
Manifest data is now one level up, saving the inode from the package.
Now, I believe that this above should be possible WITHIN the framework
of my proposed MetaManifest changes.
I specifically stated in GLEP58:
===
The objective of creating the MetaManifest file(s) is to ensure that
every single file in the tree occurs in at least one Manifest.
===
My proposals did not cover removing other Manifest files per solar's
suggestion, as I perceived that to be a much larger objective than my
goal of actually securing the existing tree distribution.
I am entirely open to solar's suggestions, in an additional GLEP, as
they will require that Portage support IS fully in place, because old
versions WILL fail on a tree without per-package Manifest.
> > This method would hands down win my vote. As you know I'm not a fan of
> > format changes in general as they can make the Gentoo experience suck,
> > but if we are going to change formats. Lets do it right.
A potential plan for GLEP58 and solar's changes would be:
1. Council approves GLEP58.
2. Portage support is added, we add MetaManifests everywhere needed
(top-level, categories, metadata, eclass etc) in the tree.
3. Old Portage versions still work at this point, because they ignore
the other Manifest files.
4. Wait 6-12 months for Portage upgrade cycle.
5. Change the content of the MetaManifests to be per solar's proposal.
6. Drop per-package Manifests from the tree.
Thus there is ZERO breakage.
A similar timeline is required for ALL of the other GLEPs I have proposed.
GLEP59 - Hashes:
- Can add new hashes right now.
- Some of the old hashes we can remove right now.
- Have to keep just one old hash for old Portage to still work.
GLEP60 - Filetypes:
- Can add new types right now.
- Cannot remove ANY types for a full upgrade cycle.
GLEP61 - Compression:
- (uncofirmed) Cannot add the compressed files in per-package locations until
the upgrade cycle is done, as old Portage will complain about their
existence.
> The only downside I can see in this method is for people like drobbins
> who mirror our tree but overlay right on top of it then provide it back
> out. In such cases we should provide our backend scripts to the public
> so they can re MetaManifest.
My MetaManifest generation script is already public. I do agree that we could
do better in documenting and publishing our older rsync generation scripts.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpOOCktCmelC.pgp
Description: PGP signature
