Re: [gentoo-dev] Flags to punt (including: kerberos USE flag)
On Saturday 01 November 2008 02:44:50 Josh Saddler wrote: emboss - Seriously. Who needs the European Biology Open Software Suite on a *desktop* oriented system? That flag is only used by a few sci-biology packages, so if you don't have any of those installed, it doesn't matter whether the flag is on or off. IIRC the argument for having it on was that the majority of people who /do/ use those packages will want it. I suppose one could say that it should be set in IUSE or profile package.use instead, but IMHO, if there are enough packages using it to justify making it a global flag in the first place, and all of them need the same default, it makes sense to set the default globally (*cough*ocamlopt*cough*).
[gentoo-dev] RFC: Adding lxde-base category
Hi, I would like to add a new category to the tree: lxde-base, to be used for the LXDE desktop [1,2] packages, in correspondence to the categories for the other desktop environments we have (gnome, kde, xfce). With the help of a few users I have been developing ebuilds for these packages in the lxde overlay [3], and I would like to move the ebuilds for the release versions into the official tree now. (The overlay also contains live svn ebuilds.) LXDE currently has 14 packages that would go into this new category, which is comparable to what xfce-base has. It also uses x11-wm/openbox as default WM, and x11-misc/pcmanfm as default filemanager, although these can be easily swapped for others. Comments are welcome! 1: http://lxde.org/ 2: https://bugs.gentoo.org/157989 3: http://www.bitbucket.org/yngwin/lxde-overlay/src/ -- Ben de Groot Gentoo Linux developer (lxde, media, desktop-misc) Gentoo Linux Release Engineering PR liaison __ [EMAIL PROTECTED] http://ben.liveforge.org/ irc://chat.freenode.net/#gentoo-media irc://irc.oftc.net/#lxde __ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Adding lxde-base category
On Sat, 01 Nov 2008 12:05:54 +0100 Ben de Groot [EMAIL PROTECTED] wrote: Hi, I would like to add a new category to the tree: lxde-base, to be used for the LXDE desktop [1,2] packages, in correspondence to the categories for the other desktop environments we have (gnome, kde, xfce). With the help of a few users I have been developing ebuilds for these packages in the lxde overlay [3], and I would like to move the ebuilds for the release versions into the official tree now. (The overlay also contains live svn ebuilds.) LXDE currently has 14 packages that would go into this new category, which is comparable to what xfce-base has. It also uses x11-wm/openbox as default WM, and x11-misc/pcmanfm as default filemanager, although these can be easily swapped for others. Comments are welcome! As a use who looked at LXDE for older machines, but decided that not to mess around with overlays on otherwise stable x86 boxes, can I vote for this? 1: http://lxde.org/ 2: https://bugs.gentoo.org/157989 3: http://www.bitbucket.org/yngwin/lxde-overlay/src/ signature.asc Description: PGP signature
[gentoo-dev] Re: GCC 4.3 pre-stabilization
Hi, Ryan Hill [EMAIL PROTECTED]: In anticipation of getting GCC 4.3 stabilized sometime, I'd like to ask maintainers check if their current stable packages build with 4.3, and if not please stabilize a version that does in the near future if at all possible. Stabilizing this version is going to be a huge job due to the number of packages that don't compile due to implicit C++ standard library header dependencies that got cleaned up in 4.3.[i], so anything you could do ahead of time to save our sanity would be greatly appreciated. Is there a bug that is blocked by such stabilisation requests? We had such a thing on the GCC 4 transition (apart from the normal porting tracker) and was really handy. I will rebuild three x86 systems (one totally stable, two mostly) to check. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: Adding lxde-base category
Hi, Robert Bridge [EMAIL PROTECTED]: As a use who looked at LXDE for older machines, but decided that not to mess around with overlays on otherwise stable x86 boxes, can I vote for this? You can, and I am sure you can also rely on that overlay to be in good shape, so test it. +1 by the way for inclusion. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Adding lxde-base category
On Sat, 2008-11-01 at 12:05 +0100, Ben de Groot wrote: Hi, I would like to add a new category to the tree: lxde-base, to be used for the LXDE desktop [1,2] packages, in correspondence to the categories for the other desktop environments we have (gnome, kde, xfce). With the help of a few users I have been developing ebuilds for these packages in the lxde overlay [3], and I would like to move the ebuilds for the release versions into the official tree now. (The overlay also contains live svn ebuilds.) ++ Note that I will propose to the GNOME team to reorganize the GNOME categories to gnome-platform/, gnome-desktop/, gnome-dev/, gnome-bindings/ or similar setup once we have atomic commits to the portage tree (a la git) to not disrupt anything from all the moves. But I think with just 14 packages an lxde-base makes the most sense indeed, with upstream probably not having them categorized themselves like GNOME has. -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: GCC 4.3 pre-stabilization
On Sat, 1 Nov 2008 14:30:09 +0100 Christian Faulhammer [EMAIL PROTECTED] wrote: Hi, Ryan Hill [EMAIL PROTECTED]: In anticipation of getting GCC 4.3 stabilized sometime, I'd like to ask maintainers check if their current stable packages build with 4.3, and if not please stabilize a version that does in the near future if at all possible. Stabilizing this version is going to be a huge job due to the number of packages that don't compile due to implicit C++ standard library header dependencies that got cleaned up in 4.3.[i], so anything you could do ahead of time to save our sanity would be greatly appreciated. Is there a bug that is blocked by such stabilisation requests? We had such a thing on the GCC 4 transition (apart from the normal porting tracker) and was really handy. I will rebuild three x86 systems (one totally stable, two mostly) to check. There is now: https://bugs.gentoo.org/show_bug.cgi?id=245160 Thanks for the help. :) -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] GCC 4.3 pre-stabilization
Ryan Hill wrote: In anticipation of getting GCC 4.3 stabilized sometime, I'd like to ask maintainers check if their current stable packages build with 4.3, and if not please stabilize a version that does in the near future if at all possible. Stabilizing this version is going to be a huge job due to the number of packages that don't compile due to implicit C++ standard library header dependencies that got cleaned up in 4.3.[i], so anything you could do ahead of time to save our sanity would be greatly appreciated. What version is the candidate to reach stable? 4.3.2? Thanks. -- Jose Luis Rivero [EMAIL PROTECTED] Gentoo/Doc Gentoo/Alpha
Re: [gentoo-dev] packages up for grabs
On Fri, 31 Oct 2008 20:42:27 + Daniel Drake [EMAIL PROTECTED] wrote: dev-util/rej Taken. Unavoidable really. :) Kind regards, jer
Re: [gentoo-dev] packages up for grabs
On Fri, 31 Oct 2008 20:42:27 + Daniel Drake [EMAIL PROTECTED] wrote: sys-block/viaideinfo And that one. rej
[gentoo-dev] [PMS] Add RESTRICT=distcc capability
I'd like to get distcc added as one of the FEATURES we are able to RESTRICT. It is true that RESTRICT=distcc is usually not the proper solution to problems. But in the case of out-of-tree kernel modules the idea of distributing compile jobs to other machines is fundamentally flawed IMO. Additionally, there are a few packages in the tree already that will never get fixed (or be fixable) and just have some check for FEATURES=distcc die disable distcc type stuff. Thanks, Gordon Malm (gengor)
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
On Sat, 1 Nov 2008 13:57:17 -0700 Gordon Malm [EMAIL PROTECTED] wrote: But in the case of out-of-tree kernel modules the idea of distributing compile jobs to other machines is fundamentally flawed IMO. Why? And how are out of tree kernel modules in any way special when it comes to distcc? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
If you're compiling an out-of-tree module that requires the kernel be compiled with support for a particular item and the distccd host's kernel does not have that support compiles fail. Reference bug #120001 (though I know that it was properly diagnosed there). Then there's also this doozie. - #167844. Thanks, Gordon Malm (gengor) On Saturday, November 1, 2008 14:00:17 Ciaran McCreesh wrote: On Sat, 1 Nov 2008 13:57:17 -0700 Gordon Malm [EMAIL PROTECTED] wrote: But in the case of out-of-tree kernel modules the idea of distributing compile jobs to other machines is fundamentally flawed IMO. Why? And how are out of tree kernel modules in any way special when it comes to distcc?
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
On Sat, 1 Nov 2008 14:21:43 -0700 Gordon Malm [EMAIL PROTECTED] wrote: If you're compiling an out-of-tree module that requires the kernel be compiled with support for a particular item and the distccd host's kernel does not have that support compiles fail. Reference bug #120001 (though I know that it was properly diagnosed there). Then there's also this doozie. - #167844. So far as I can see, when the correct options are passed to a build system, the only issue is hardened being broken. There doesn't seem to be any fundamental reason why distcc with a sane compiler can't be used with kernel modules. If this is the case, wouldn't it be better to get the hardened compiler fixed? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
On Saturday, November 1, 2008 14:28:06 Ciaran McCreesh wrote:
On Sat, 1 Nov 2008 14:21:43 -0700
Gordon Malm [EMAIL PROTECTED] wrote:
If you're compiling an out-of-tree module that requires the kernel be
compiled with support for a particular item and the distccd host's
kernel does not have that support compiles fail. Reference bug
#120001 (though I know that it was properly diagnosed there).
Then there's also this doozie. - #167844.
So far as I can see, when the correct options are passed to a build
system, the only issue is hardened being broken. There doesn't seem to
be any fundamental reason why distcc with a sane compiler can't be used
with kernel modules. If this is the case, wouldn't it be better to get
the hardened compiler fixed?
I use madwifi-ng extensively and have experienced the same issue with
madwifi-ng as stated in that bug. For bug #167844, please read comment #13
and http://code.google.com/p/distcc/issues/detail?id=25. There's nothing to
fix, hardened is doing the right thing as is distcc. The proper approach is
to not distribute compiles of kernel modules.
To not get too stuck on a single scenario, I think this would be a useful
feature and desireable vs. the alternative of FEATURES=${FEATURES/distcc/}.
This is not the first time its been requested, a simple search reveals bugs
#28300, #80894.
A quick grep shows these packages at minimum have to do some FEATURES checking
and either pass a config option (if provided) or die disable distcc and try
again.
dev-python/pyqwt
media-gfx/sam2p
media-tv/mythtv
media-video/avidemux
Gordon Malm (gengor)
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
On Sat, 1 Nov 2008 14:58:39 -0700
Gordon Malm [EMAIL PROTECTED] wrote:
I use madwifi-ng extensively and have experienced the same issue with
madwifi-ng as stated in that bug. For bug #167844, please read
comment #13 and http://code.google.com/p/distcc/issues/detail?id=25.
There's nothing to fix, hardened is doing the right thing as is
distcc. The proper approach is to not distribute compiles of kernel
modules.
It looks to me like hardened is doing entirely the wrong thing. Thus,
the proper fix is to make hardened behave itself.
To not get too stuck on a single scenario, I think this would be a
useful feature and desireable vs. the alternative of
FEATURES=${FEATURES/distcc/}.
This is not the first time its been requested, a simple search
reveals bugs #28300, #80894.
It looks a lot like people are blaming distcc for parallelisation bugs
that aren't distcc related but that happen to be easier to reproduce
when distcc is enabled. Do you have any examples of problems that are
definitely caused by distcc, rather than general parallelisation bugs
or user misconfigurations? RESTRICTing distcc doesn't seem to be an
actual fix for anything...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
[gentoo-dev] Re: GCC 4.3 pre-stabilization
On Sat, 01 Nov 2008 18:30:41 +0100 Jose Luis Rivero [EMAIL PROTECTED] wrote: Ryan Hill wrote: In anticipation of getting GCC 4.3 stabilized sometime, I'd like to ask maintainers check if their current stable packages build with 4.3, and if not please stabilize a version that does in the near future if at all possible. Stabilizing this version is going to be a huge job due to the number of packages that don't compile due to implicit C++ standard library header dependencies that got cleaned up in 4.3.[i], so anything you could do ahead of time to save our sanity would be greatly appreciated. What version is the candidate to reach stable? 4.3.2? I don't know, that's up to the toolchain guys. Probably the latest version available when the tree is ready, which I'm expecting will take quite some time. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
On Saturday, November 1, 2008 15:11:16 Ciaran McCreesh wrote:
On Sat, 1 Nov 2008 14:58:39 -0700
Gordon Malm [EMAIL PROTECTED] wrote:
I use madwifi-ng extensively and have experienced the same issue with
madwifi-ng as stated in that bug. For bug #167844, please read
comment #13 and http://code.google.com/p/distcc/issues/detail?id=25.
There's nothing to fix, hardened is doing the right thing as is
distcc. The proper approach is to not distribute compiles of kernel
modules.
It looks to me like hardened is doing entirely the wrong thing. Thus,
the proper fix is to make hardened behave itself.
It looks to me like you've already made up your mind. How is hardened doing
the entirely wrong thing? What do you propose can be done to fix the
hardened compiler? What about madwifi-ng? You are getting increasingly
narrow in your points of objection.
To not get too stuck on a single scenario, I think this would be a
useful feature and desireable vs. the alternative of
FEATURES=${FEATURES/distcc/}.
This is not the first time its been requested, a simple search
reveals bugs #28300, #80894.
It looks a lot like people are blaming distcc for parallelisation bugs
that aren't distcc related but that happen to be easier to reproduce
when distcc is enabled. Do you have any examples of problems that are
definitely caused by distcc, rather than general parallelisation bugs
or user misconfigurations? RESTRICTing distcc doesn't seem to be an
actual fix for anything...
As I said in my first post:
'It is true that RESTRICT=distcc is usually not the proper solution to
problems.'
Parallel building problems can often and should be addressed properly. I
don't want the answer to every one that comes along to be to add
RESTRICT=distcc. This is something to be addressed through developer
documentation that using RESTRICT=distcc should be a last resort.
However, in practice making a package parallel-make safe isn't always trivial.
So what happens in these cases is FEATURES=distcc die check is put in
place killing the emerge chain and requiring user intervention. Either that
or the bug just lingers and the compile fails somewhere in the middle...
I don't know about palaudis but this is like a one line patch to portage. But
silly me, I thought the package manager was there to support the
distribution.
Gordon Malm (gengor)
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
On Sat, 1 Nov 2008 15:47:09 -0700 Gordon Malm [EMAIL PROTECTED] wrote: It looks to me like hardened is doing entirely the wrong thing. Thus, the proper fix is to make hardened behave itself. It looks to me like you've already made up your mind. How is hardened doing the entirely wrong thing? What do you propose can be done to fix the hardened compiler? What about madwifi-ng? You are getting increasingly narrow in your points of objection. I suggest you get the hardened upstream people to stop abusing the -D switch to gcc. The distcc people suggest the same. Parallel building problems can often and should be addressed properly. I don't want the answer to every one that comes along to be to add RESTRICT=distcc. This is something to be addressed through developer documentation that using RESTRICT=distcc should be a last resort. Uh, RESTRICT=distcc won't even fix parallel make problems. It'll just make them harder to reproduce on some systems. However, in practice making a package parallel-make safe isn't always trivial. So what happens in these cases is FEATURES=distcc die check is put in place killing the emerge chain and requiring user intervention. Either that or the bug just lingers and the compile fails somewhere in the middle... ...or you could use -j1, which whilst being horrible will at least work. I don't know about palaudis but this is like a one line patch to portage. But silly me, I thought the package manager was there to support the distribution. You have yet to demonstrate how RESTRICT=distcc will help. In fact, you seem to be demonstrating that all it'll do is make a few people apply a 'fix' that won't reliably fix anything. *If* there's a legitimate use for RESTRICT=distcc then I am entirely in favour of it. But it looks like there isn't, with every issue being either a parallelism issue (which RESTRICT=distcc won't fix), a user configuration issue (which RESTRICT=distcc won't fix) or a hardened toolchain bug (for which RESTRICT=distcc is massive overkill, and thus the wrong solution). You've decided upon a solution before you've worked out what the problem is. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
Gordon Malm wrote: It looks to me like you've already made up your mind. How is hardened doing the entirely wrong thing? From the page [1] you mentioned: If so, that seems to me like an abuse of the -D option. The abuse is in changing the compiler behavior based on -D options. What do you propose can be done to fix the hardened compiler? From the same page: It would be better for you to remove the patch from gcc where it makes -D__KERNEL__ imply -nossp -nopie, and to instead patch the Linux kernel build system (Makefiles, etc.) so that it passes -D__KERNEL__ -nossp -nopie rather than -D__KERNEL__. [1] http://code.google.com/p/distcc/issues/detail?id=25 Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Adding lxde-base category
Ben de Groot wrote: Hi, I would like to add a new category to the tree: lxde-base, to be used for the LXDE desktop [1,2] packages, in correspondence to the categories for the other desktop environments we have (gnome, kde, xfce). With the help of a few users I have been developing ebuilds for these packages in the lxde overlay [3], and I would like to move the ebuilds for the release versions into the official tree now. (The overlay also contains live svn ebuilds.) LXDE currently has 14 packages that would go into this new category, which is comparable to what xfce-base has. It also uses x11-wm/openbox as default WM, and x11-misc/pcmanfm as default filemanager, although these can be easily swapped for others. Comments are welcome! 1: http://lxde.org/ 2: https://bugs.gentoo.org/157989 3: http://www.bitbucket.org/yngwin/lxde-overlay/src/ I dunno . . . given the Xfce (the OTHER lightweight DE) team's decision to start getting rid of the xfce-* categories, near as I can tell, is this really consistent with what the rest of the desktop teams are doin'? Or is it just Xfce that seems to be less consistent with other categories. Aside from these recent actions, lxde categories seem like a good idea, same as for all our other desktops. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
On Saturday 01 November 2008 20:57:17 Gordon Malm wrote: I'd like to get distcc added as one of the FEATURES we are able to RESTRICT. Regardless of whether it's a good idea or not, does it fix all the known issues if the ebuild sets DISTCC_HOSTS=localhost in the environment?
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
On Saturday, November 1, 2008 15:57:52 Ciaran McCreesh wrote: Parallel building problems can often and should be addressed properly. I don't want the answer to every one that comes along to be to add RESTRICT=distcc. This is something to be addressed through developer documentation that using RESTRICT=distcc should be a last resort. Uh, RESTRICT=distcc won't even fix parallel make problems. It'll just make them harder to reproduce on some systems. Why don't you post the whole context? Here, I'll do it for you: On Saturday, November 1, 2008 15:11:16 Ciaran McCreesh wrote: It looks a lot like people are blaming distcc for parallelisation bugs that aren't distcc related but that happen to be easier to reproduce when distcc is enabled. Do you have any examples of problems that are definitely caused by distcc, rather than general parallelisation bugs or user misconfigurations? RESTRICTing distcc doesn't seem to be an actual fix for anything... And my full response... As I said in my first post: 'It is true that RESTRICT=distcc is usually not the proper solution to problems.' Parallel building problems can often and should be addressed properly. I don't want the answer to every one that comes along to be to add RESTRICT=distcc. This is something to be addressed through developer documentation that using RESTRICT=distcc should be a last resort. You're the one assuming the only purpose would be to mask parallel make problems. Apparently it does have a purpose though since avidemux builds fine in parallel but NOT via distcc. Back to your most recent post *If* there's a legitimate use for RESTRICT=distcc then I am entirely in favour of it. But it looks like there isn't, with every issue being either a parallelism issue (which RESTRICT=distcc won't fix), a user configuration issue (which RESTRICT=distcc won't fix) or a hardened toolchain bug (for which RESTRICT=distcc is massive overkill, and thus the wrong solution). You've decided upon a solution before you've worked out what the problem is. You assumed it is a parallelism issue that people are trying to solve. I haven't pointed to any user configuration issues. Using RESTRICT=distcc on kernel modules is hardly overkill. This isn't openoffice. I know exactly what the problem is, but since you have such a better grasp on it On Saturday, November 1, 2008 15:57:52 Ciaran McCreesh wrote: On Sat, 1 Nov 2008 15:47:09 -0700 Gordon Malm [EMAIL PROTECTED] wrote: It looks to me like hardened is doing entirely the wrong thing. Thus, the proper fix is to make hardened behave itself. It looks to me like you've already made up your mind. How is hardened doing the entirely wrong thing? What do you propose can be done to fix the hardened compiler? What about madwifi-ng? You are getting increasingly narrow in your points of objection. I suggest you get the hardened upstream people to stop abusing the -D switch to gcc. The distcc people suggest the same. On Saturday, November 1, 2008 16:28:17 Jan Kundrát wrote: Gordon Malm wrote: It looks to me like you've already made up your mind. How is hardened doing the entirely wrong thing? From the page [1] you mentioned: If so, that seems to me like an abuse of the -D option. The abuse is in changing the compiler behavior based on -D options. What do you propose can be done to fix the hardened compiler? From the same page: It would be better for you to remove the patch from gcc where it makes -D__KERNEL__ imply -nossp -nopie, and to instead patch the Linux kernel build system (Makefiles, etc.) so that it passes -D__KERNEL__ -nossp -nopie rather than -D__KERNEL__. We have to build using different specs sets for kernel code than userland. If we can't depend on the __KERNEL__ macro for detection, how else do you propose one detect if gcc is building kernel code or not? Patching an out-of-tree module's build system to pass -fno-PIE works on x86, I don't know how this will affect other ARCHes, do either of you? This could potentially get really tricky. If it can't be done nicely in the eclass for every possible kernel release and out-of-tree module, then we get into patching *everything* and having to maintain it forward. So this is just a different workaround, a rather heavy-handed and high-maintenance one at that. What makes it any better than a simple option to RESTRICT distcc? I guess the larger question in all this is why does a third party who has demonstrated his anti-Hardened (and anti-Gentoo) slant on multiple occasions define what goes in our PMS? Gordon Malm (gengor)
Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gordon Malm wrote: snip a lot of exchanges All the technical discussion on the above is perfectly fine, but the way the arguments are being presented and the tone used by both sides is getting arguments into a thin line from becoming flames. Please step back before turning this into another flame festival. I guess the larger question in all this is why does a third party who has demonstrated his anti-Hardened (and anti-Gentoo) slant on multiple occasions define what goes in our PMS? It's not up to a 3rd party to define what will be or not in PMS. Any 3rd party is free to contribute to the discussion (within boundaries), but it's up to the PMs folks to reach agreements about PMS and, or if they can't, up to the Gentoo Council. Gordon Malm (gengor) - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkNG6IACgkQcAWygvVEyAKOrgCghGO8W2839jXMaMq9DN3DpWbM JJMAn0PhLDiKoBayr1juI48tzwa8j8Wc =EXnX -END PGP SIGNATURE-
