[gentoo-dev] Re: [Last Rites] NVU
Jory A. Pratt anarchy at gentoo.org writes: As most are aware nvu has not had any activity in almost a year. Unless someone steps up or has any valid reason we should continue to patch nvu to keep it in the tree please speak up. If noone has any complaints I will p.mask Wed. March 21 and remove 30 days later. Because I am working on the next version and this product is not dead ? Daniel Glazman, Nvu engineering lead -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [Last Rites] NVU
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Glazman wrote: Jory A. Pratt anarchy at gentoo.org writes: As most are aware nvu has not had any activity in almost a year. Unless someone steps up or has any valid reason we should continue to patch nvu to keep it in the tree please speak up. If noone has any complaints I will p.mask Wed. March 21 and remove 30 days later. Because I am working on the next version and this product is not dead ? Daniel Glazman, Nvu engineering lead With that said I will go ahead and patch nvu in the tree for glibc-2.4. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEHtIJGDfjNg8unQIRAgCRAJ41KviwzgJjvcq5AX+z1ENw50hu8wCeNKBY pBxYCAe5ouR/hLuELT6H5pg= =rs+R -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] 2.6.16 and packages in conflict
Hi, Linux 2.6.16 will be in the tree very soon. Assuming there aren't any major problems, we'll hopefully be marking it stable in 2-3 weeks. As usual, please bring any conflicts (e.g. compilation failures of kernel module ebuilds against 2.6.16) to our attention by making them block bug 126972. Thanks! Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] package naming
Hi list. I've been working on getting a Gentoo version of Debians resolvconf package into portage. It's basically a re-write of the internals (which I don't like) but the command line, setup and plugin system are 100% compatible (except for the plugins which may need one line changing). As such, I've credited the original author (Thomas Hood) and basically said this is a Gentoo re-write. It's all good to go and all dhcp clients in portage and openvpn have patches ready for its optional support. dhcp (dhclient) and ppp have already been patched in portage. Now, if the commandline is the same, should the package name be the same? If so, what version number should I be using? It's currently just called resolvconf-0.1 Thoughts? BTW, baselayout-1.12 has always had a resolv.conf management system, but that was coded on a per package basis - resolvconf allows each package to inject dns setup without being reliant on baselayout. So baselayout-1.12.0_pre17 will be a fair bit lighter! Thanks -- Roy Marples [EMAIL PROTECTED] Gentoo Linux Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] package naming
On Monday 20 March 2006 18:42, Roy Marples wrote: Now, if the commandline is the same, should the package name be the same? If so, what version number should I be using? It's currently just called resolvconf-0.1 I would say gentoo-resolvconf as it's a rewrite/fork. -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpKMWA6s2z46.pgp Description: PGP signature
Re: [gentoo-dev] package naming
On Monday 20 March 2006 17:59, Luca Barbato wrote: why not having it implemented as eselect module? ^^; I am not familiar with eselect. Also, I fail to see the benefit of using the eselect framework when /sbin/functions.sh provides what I need as a base. Of course, feel free to talk me around. -- Roy Marples [EMAIL PROTECTED] Gentoo Linux Developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites for media-gfx/bootsplash-themes-livecd
Since we have switched to using splash-themes-livecd over a year ago, I'd like to whack this package. We have only 1 2.4-based kernel that I am aware of that has bootsplash support, so it is very likely that this is completely unused anymore. If there's no objections in the next few days, I'll mask it on Friday, March 24th pending removal. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] package naming
Roy Marples wrote: Now, if the commandline is the same, should the package name be the same? If so, what version number should I be using? It's currently just called resolvconf-0.1 Definately change the name of the package (if not the script itself) otherwise the Debian resolvconf author wouldn't be too happy. resolvconf-gentoo would be a good choice Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] package naming
Daniel Drake wrote: Roy Marples wrote: Now, if the commandline is the same, should the package name be the same? If so, what version number should I be using? It's currently just called resolvconf-0.1 Definately change the name of the package (if not the script itself) otherwise the Debian resolvconf author wouldn't be too happy. Or you could do something completely crazy like ask if the author's interested in incorporating your rewrite. Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: package naming
Chris Gianelloni posted [EMAIL PROTECTED], excerpted below, on Mon, 20 Mar 2006 14:00:15 -0500: I made a fork of hwdata for Gentoo's needs on the LiveCD and it is hwdata-gentoo (to match hwdata-knoppix and hwdata-morphix for their respective distributions). I think it makes more sense to keep the original package name first as it shows that it is a fork of that package. Agreed if keeping the old name with a gentoo prefix/suffix is chosen. However, nearly all Gentoo system tools are ewhatever (not only portage related either, as there's eselect), so I'd suggest eresolv. Even if resolvconf-gentoo is chosen, I'd definitely recommend an eresolv symlink, simply because doing so will allow it to be listed with etabtab, if one forgets the name. I recall back on Mandrake, reading the cooker discussion on their regret at the naming convention they had chosen, whateverdrake, for that very reason -- no simple prefixtabtab method for listing all the Mandrake system tools. Gentoo has it right with the e* precedent. I believe we should continue to follow it. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: package naming
On Mon, 2006-03-20 at 12:37 -0700, Duncan wrote: Agreed if keeping the old name with a gentoo prefix/suffix is chosen. However, nearly all Gentoo system tools are ewhatever (not only portage related either, as there's eselect), so I'd suggest eresolv. He was referring to the *package* name. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Making the developer community more open
more open? I can't think of a decent way to phrase the subject line which might make it sound it was coming from a native English speaker..ahem..anyway: I read a complimentary comment from a Gentoo user recently (can't remember exactly where, so this is from memory). It was something along the lines of Gentoo is great and will continue to be great for the foreseeable future. You have built the required structure to keep up with the rate of change in your environment (i.e. the increasingly rapid rate of development of open-source sofware). (if anyone can point me to where I read that, I'd appreciated it). I think there's a lot of truth in that, especially the way that he/she highlights the fact that simply keeping up with what goes on around us is key to our survival. I won't go as far to say that I *don't* think we can keep up with our current system, but I think there is plenty of room for improvement. One of the bigger problems is that we have a huge user community who are keen on contributing, but we have such a high barrier for entry to the developer community. Quite rightly so - we're dealing with a live tree, so we can't give out commit access on the street. At the same time, I feel that we're missing out. Comparing Gentoo with some other large open-source communities that I am personally involved in, I feel that we're too closed. A developer recently compared Gentoo dev-ship to a marriage. In an ideal world, sure, we'd love for every single person who makes any kind of contribution to the project to become a full-time contributor who never goes AWOL or sleeps with another project. But more realistically, I think we need to become more open and flexible - as volunteers, people's interests change, some people will stop contributing after they have fixed whatever problem motivated them to contribute, etc. How can we handle this better? We have a large expense on both sides when adding a developer to the project. I personally have lost developer candidates, undoubtedly more technically experienced than myself, who simply did not have the time to go through a month-long recruitment process which involved studying various documents not even relevant to the small area they would be contributing to. On the other side, it's a fair expense to add a developer to the project due to all of the quizzing/assessing/account-creating/access-elevation/... Additionally, a significant percentage of developers who have joined recently have gone AWOL after a few months. That hurts us, given the expense we went through recruiting and adding them, and the time needed to reverse that and retire them. I am not claiming this is an easy problem to solve - we do need to be especially careful that any changes made do not decrease the quality of commits to the live portage tree. This is why I am asking for help. I'm looking for ideas - preferably big, drastic, shiny ones. Ignore any issues relating to migration away from our current system. What would be the _ideal_ way for Gentoo to handle contributions from anyone? (note that I'm dropping the user/developer community separation in that question, as the boundary between those could change in these ideas) How would an ideal recruitment process work, if there would be one at all? Please try and keep replies on-topic - I'm not trying to start a discussion/flamewar on the current recruitment system or anything like that. To get you thinking, I suggest reading the section titled Open Development Team at http://www.samspublishing.com/articles/article.asp?p=23200seqNum=3 which is part of a (very good) larger article detailing why Linux kernel development works so well. Any ideas? Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
On Mon, 20 Mar 2006 23:07:37 + Daniel Drake [EMAIL PROTECTED] wrote: | One of the bigger problems is that we have a huge user community who | are keen on contributing, but we have such a high barrier for entry | to the developer community. Quite rightly so - we're dealing with a | live tree, so we can't give out commit access on the street. A relatively easy way of lowering that barrier would be to provide good, up to date, example-oriented ebuild writing documentation. There's too much stuff that people need to know to write ebuilds that's not written down anywhere -- this not only makes it harder for users to write good ebuilds, but also leads to some of them being dissuaded when they're told that the only way to know what's policy is by having paid attention on the mailing lists for the past five years. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] New Developer: Karol Pasternak (reb)
Danny van Dyk wrote: Karol joined Gentoo to help with the Gentoo/OpenBSD project. I guess Flameeyes will be happy with another slav^H^Hminio^H^H^Hhelping hand :-) Welcome aboard Karol! Watch this list closely for the day Danny's backspace key breaks and we all get to see what he's really thinking ;-) -- Jeff Walter [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
On 3/21/06, Bret Towe [EMAIL PROTECTED] wrote: perhaps having some proxys of a sort that accept patchs and such from trusted users that would commit fixes to portage would help. similiar to the kernel format that way users can 'commit'/help out quickly without having to go thru the long process of becoming a dev That is imo a key feature: Get contributions back to the users easily It doe snot need to be the portage-tree .. but an official user-overlay or contrib-overlay would definitely help to get a lot of people involved. Other projects are providing similar infrastructure with very good results, see the Arch User Repository for example: http://aur.archlinux.org It would be great to have something like that available for gentoo-users. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
I'm not a gentoo dev (just a satisfied user), but I lurk on this list. I was at PyCon last month. I would estimate that about 40% of the people there ran linux on their laptops. The most popular distros were gentoo and ubuntu. (Not this is not a scientific study, just my observations from talking to people there). While I was there the person next to me starting hacking the ebuild classes to handles eggs (so he could emerge turbogears). I talked to at least 3 others who were running gentoo. I asked all of them if they had worked on portage. Most said No, the code is a little scary. (I'll concur with that sentiment, as the code doesn't feel very pythonic). If you want to attract more developers (python people), a few things are needed: * Portage documentation. How the innards work. There is very little docs/comments in the portage code * Unittests - without this how do I know that my change to portage didn't break someone else's corner case * Refactoring into a more pythonic style. Note that this is pretty hard without unittests. Take this as a grain of salt, from an observer, who believes that there are a lot of potential users (who know python), and who could easily contribute, if the bar was lowered a bit. (Or steps were provided to reach a little higher ;)) -matt -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
On Tue, 21 Mar 2006 00:58:07 +0100 Stefan Schweizer [EMAIL PROTECTED] wrote: | It doe snot need to be the portage-tree .. but an official | user-overlay or contrib-overlay would definitely help to get a lot of | people involved. The problem is security. It's extremely easy to sneak some very devious code (e.g. that'd grant remote root access and post an IP somewhere) into an ebuild that'd be very hard to spot by anyone who doesn't realy know what they're doing. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Making the developer community more open
Monday, 20. March 2006 23:07, Daniel Drake Ви написали: I'm looking for ideas - preferably big, drastic, shiny ones. Ignore any issues relating to migration away from our current system. What would be the _ideal_ way for Gentoo to handle contributions from anyone? Any ideas? Heh, and that bug almost got closed for the 2nd time recently :). Please take a look at #1523 (note the number ;)), it addresses essentially this issue, or pretty similar. Half of the ideas from there we got done already, but another half is nowhere near. I'd even say they need some drastic redesign first, before they should go anywhere near glep or nearing implementation. For one infra will not be happy at all about more major stuff, but you said don't bother, just give me ideas, so here you go ;). Then some subprojects that are necessary to get that done in full were talked about and restarted a few times, but eventually died every time. I am talking about gentoo-stats and similar.. Frankly, I haven't thought much about this for the last two years or so, being busy with issues of the day mostly (and undergoing big real life transitions :)), but nonetheless kept the bug open, as from my experience this issue resurfaces every year or so. So, please take a look. Hopefully you will find something usefull.. George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
A quick update. Please use this link for the proposal instead of the one listed in original post in the bug: http://dev.gentoo.org/~george/epsp/proposal.html The files have been migrated to my gentoo space, as proper. I just added comment to the bug and I'll put up some remonder at the place the original link points to (but I am no longer at that place, so I cannot predict for how long that will work..) Please take a look at #1523 (note the number ;)), it addresses essentially George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
George- Not sure if you have seen this or not. Check out Conary [1] from rPath. Think of it as Rpm+Ebuild+Distributed. It's done by some people who used to be at Redhat and in one of the whitepapers, they specifically mention portage/ebuild. -matt 1 - http://wiki.conary.com/FrontPage On 3/20/06, George Shapovalov [EMAIL PROTECTED] wrote: A quick update. Please use this link for the proposal instead of the one listed in original post in the bug: http://dev.gentoo.org/~george/epsp/proposal.html The files have been migrated to my gentoo space, as proper. I just added comment to the bug and I'll put up some remonder at the place the original link points to (but I am no longer at that place, so I cannot predict for how long that will work..) Please take a look at #1523 (note the number ;)), it addresses essentially George -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
Well, I think a lot of what I've been thinking recently has already been said by Daniel. I'm actually in the middle of being inducted and I'm just concerned that I'm going to get extra responsibility without any real positive aspects for me. I don't really *want* access to check into portage, I don't know what I'm doing (yet) and I'm not certain I can invest the time to learn all the precise policy to ensure I don't make a mistake, or worse put up with the stress of worrying I'll do it wrong and affect the entire gentoo vmware-using userbase. What I tend to do is make ebuilds for things that I want to try out or things that are broken, and I'd really like to just keep on doing that, but have it more accessible to the rest of the userbase. I think the idea of a proxy is a good one. I don't know about a whole user repository though, because as Ciaran pointed out, one bad apple and everybody gets rooted. No one would trust it, so it wouldn't be worth it anyway. * It'd be a good idea to have a larger group of devs not dedicated to a particular project, but who can take user submitted ebuilds, vet them for nastiness, and submit them. They'll be officially contributed ebuilds, they won't get updated until either a dev offers to take them on, or the community offers to fix them. * I think also a larger number of bugzilla scouring devs could push through well tested (lots of positive feedback, no negative feedback) patches that the maintainers for whatever reason (aren't there, forgot about it, don't have the time) just aren't putting through. That would require bending the maintainer etiquette a bit though. * I guess a *quick* concise policy guide would help. Separate from the ebuild guide which is trying to teach you *how* to write ebuilds, this policy guide would tell you what MUST and MUST NOT happen in a good Quality Assured ebuild. For instance, if the various and sundry checks in repoman could be extracted for people to run over their own overlays without all the main portage cvs machinery in there, it would help them get *much* better trained in what makes a good ebuild and what doesn't. If it can already do that, then it needs better documentation. * Finally the mentoring scheme could perhaps be more streamlined. So rather than having an all-or-nothing gentoo developer membership. Those developers being mentored have a repoman-like interface that works almost exactly the same way, but instead of putting directly into0 the tree, it would submit to a holding area where an experienced ebuild writer can either send it back to them with comments, or put a tick next to it and pass it into the main overlay. This then would allow people to work up to becoming a full dev, and take their time over it. It would also offer a kind of buffer area for people who just want to help for a few months, their privilege levels don't have to rise too high. So these are some ideas. Sorry, I was trying to get these out concisely but tripped on my tongue somewhere along the way, hope they help generate some ideas... Mike 5:) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
m h wrote: I'm not a gentoo dev (just a satisfied user), but I lurk on this list. I was at PyCon last month. I would estimate that about 40% of the people there ran linux on their laptops. The most popular distros were gentoo and ubuntu. (Not this is not a scientific study, just my observations from talking to people there). While I was there the person next to me starting hacking the ebuild classes to handles eggs (so he could emerge turbogears). I talked to at least 3 others who were running gentoo. I asked all of them if they had worked on portage. Most said No, the code is a little scary. (I'll concur with that sentiment, as the code doesn't feel very pythonic). If you want to attract more developers (python people), a few things are needed: That depends on how they contribute, I personally don't want random python master bob contributing pieces to portage itself. Portage things are not necessarily as simple as people make them out to be. Even developers who know the code well make mistakes in adding and removing code. As solar once pointed out the only man I trust to touch the resolver is Jstubbs. I realize thats a bit elitest...but at the same time...I am overly cautious ;) However we always accept patches and I think we get most of them critiqued, sometimes it may take an extra prodding mail or two. We usually don't implement your features for you though ;) * Portage documentation. How the innards work. There is very little docs/comments in the portage code Someone has to write them; I have some of it done, it's been a longtime project that I've worked on off and on; I actually had more done last year and I know kutsuya did some as well. However these are not particularly interesting..and no one wants to document the 2.X branch. * Unittests - without this how do I know that my change to portage didn't break someone else's corner case No one is writing unittests for the 2.X branch * Refactoring into a more pythonic style. Note that this is pretty hard without unittests. See above :) Take this as a grain of salt, from an observer, who believes that there are a lot of potential users (who know python), and who could easily contribute, if the bar was lowered a bit. (Or steps were provided to reach a little higher ;)) -matt signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making the developer community more open
On Tuesday 21 March 2006 12:32, Alec Warner wrote: m h wrote: I'm not a gentoo dev (just a satisfied user), but I lurk on this list. I was at PyCon last month. I would estimate that about 40% of the people there ran linux on their laptops. The most popular distros were gentoo and ubuntu. (Not this is not a scientific study, just my observations from talking to people there). While I was there the person next to me starting hacking the ebuild classes to handles eggs (so he could emerge turbogears). I talked to at least 3 others who were running gentoo. I asked all of them if they had worked on portage. Most said No, the code is a little scary. (I'll concur with that sentiment, as the code doesn't feel very pythonic). If you want to attract more developers (python people), a few things are needed: That depends on how they contribute, I personally don't want random python master bob contributing pieces to portage itself. Portage things are not necessarily as simple as people make them out to be. Even developers who know the code well make mistakes in adding and removing code. As solar once pointed out the only man I trust to touch the resolver is Jstubbs. I realize thats a bit elitest...but at the same time...I am overly cautious ;) The resolver as it stands now is not overly difficult. One does really need to know it back to front though. I should really make splitting it out and documenting it my big project for 2.2. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
Daniel Drake wrote: We have a large expense on both sides when adding a developer to the project. I personally have lost developer candidates, undoubtedly more technically experienced than myself, who simply did not have the time to go through a month-long recruitment process which involved studying various documents not even relevant to the small area they would be contributing to. On the other side, it's a fair expense to add a developer to the project due to all of the quizzing/assessing/account-creating/access-elevation/... Technical ability isn't the only requirement for gentoo devs. They also must be motivated individuals and these high barriers you are talking about test this quality of the candidates. If they quit just because recruitment process is long, what makes you think they will stay active long enough to actually worth adding them to dev corpus? Additionally, a significant percentage of developers who have joined recently have gone AWOL after a few months. That hurts us, given the expense we went through recruiting and adding them, and the time needed to reverse that and retire them. Yes, it is hard to find the right people. Yes, a big percentage of recruiting team's time will be lost on useless additions/removals. But the only solution is scaling the recruiting team to gentoo needs. IMO recruiting team is too small to cope with the current size of the project. signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] DB and binary dependency
I'm replying to this one, but I've read the whole thread... On 3/16/06, Paul de Vrieze [EMAIL PROTECTED] wrote: On Wednesday 15 March 2006 16:13, Gustavo Sverzut Barbieri wrote: Hello, There is any provision for binary dependency on Gentoo/Portage? The way it works now is quite messy with things like revdep-rebuild. I have an idea to solve this problem: after software is build, you check which files it links (ldd binaries libraries) and check the used against installed packages. If a library is not provided by an installed package we could have a policy to inform user or just abort installation. Also, if we implement these dependencies in rpm-generator, we could just generate RPM packages and install it in the RPM-DB and let it handle these kind of things. With these in place emerge would handle the build stage (where it excels), but rpm would handle the binary installation and dependencies (where it excels). Solving this is not trivial. Basically suppose application X depends on sys-libs/db-4.* This can be resolved by differently slotted libraries. We need to record which one was actually used (not easy by itself, but more an issue of the ebuild itself, if more than 1 candidate is available). But suppose that we know that the application was compiled to use db-4.3.29. We must then know that it is ok to replace the db-4.3.29 package with 4.3.30, but that it isn't ok to replace it by 4.3.28 or 4.4.20. To make this things worse, the above example assumes that within a slot, the libraries are binary compatible. There are examples of libraries that are not. And what about a library whose interface is dependent on a third library: B uses A, C uses B, but B exports A. So B is dependent on A, and the binary package of C must record that B was compiled with A. In short, welcome to binary package hell. This is the reason that binary distributions must use versions. Even debian. It is just very very hard to fix these kinds of indirect dependencies. I do think you're overcomplicating things where you shouldn't. Declaring stuff manually will always break, and to ensure a safe system, it's better to use compiler information. So I wouldn't mind fixing it to one package instead of a slot. I mean, if user compiled software X-1.0 and it depends on library Y-2.0, provided at the moment of X-1.0 compilation by package Z-3.0, then make X-1.0 depend on Z-3.0. If you were to remove Z-3.0 or upgrade it or even add other option by means of USE, have X-1.0 to be recompiled too... you could be even more correct to make it check CFLAGS too. Of course this correctness could piss users, then you could have a --nodeps or something like that to avoid this and use the old behaviour. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 Phone: +1 (347) 624 6296; [EMAIL PROTECTED] GPG: 0xB640E1A2 @ wwwkeys.pgp.net -- gentoo-portage-dev@gentoo.org mailing list
