Re: [gentoo-dev] Virtualization Herd
On Mon, 2006-07-03 at 20:15 -0600, Nick Devito wrote: > Generating root filesystems for UML and Xen are basically the same > process. I've heard of domi, but, bleh, I never could get it to work. I > usually just make my images in chroot, and that usually works well. But, > since the images are *basically* the same, that means it would be > possible to use the jailtime images, unless you are running on a 64-bit > arch. Then, in that case, least with gentoo, running a 64-bit kernel and > 32-bit userland doesn't work for long (first glibc (re)compile, and the > whole thing borks out). I'm on amd64, as my primary arch. I generally use a chroot, as well, and have knocked up some scripts to help me, but a well-designed package to do it would be very helpful. Maybe I'll write one... Several patches just went into -mm to make UML work well as a 32-bit process on 64-bit arches, which would make the root image a pure 32-bit image. Daniel signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI
On Mon, Jul 03, 2006 at 07:13:35PM -0700, Donnie Berkholz wrote:
> Robin H. Johnson wrote:
> > If you have an ebuild with a non-standard pkg_nofetch, please ensure
> > that you use $SRC_URI instead of $A!
> >
> > This is because if you have FEATURES=mirror or FEATURES=cvs, attempts to
> > download all of the source files for digesting or verification will hit
> > pkg_nofetch and $A is only the subset of $SRC_URI, causing misleading
> > messages to be displayed about what needs to be downloaded still.
> >
> > Plasmaroo: could you perhaps change this in the devmanual?
> >
> > I'll be looking through the tree to fix any existing occurrences of this.
> Displaying $SRC_URI is worse for the user, because it displays this
> weird dependency tree containing USE flags that they should not need to
> decipher.
>
> I don't consider this something that should be "fixed."
In that case, neither behavior is correct.
Additionally, you should talk to the portage team and get the master
ebuild.sh changed, because the stock pkg_nofetch there uses SRC_URI.
This is the existing default pkg_nofetch from ebuild.sh:
pkg_nofetch() {
[ -z "${SRC_URI}" ] && return
echo "!!! The following are listed in SRC_URI for ${PN}:"
local x
for x in $(echo ${SRC_URI}); do
echo "!!! ${x}"
done
}
When FEATURES=mirror, and you try to fetch, it does indeed contain unevaluated
USE flags. However for FEATURES=-mirror, the content of it is correct - no USE
flags at all.
Maybe a two-part solution is in order here then:
1. Change portage behavior regarding the value of SRC_URI during fetch with
FEATURES=mirror to not contain any conditionals.
2. Change all ebuilds to use SRC_URI in pkg_nofetch
--
Robin Hugh Johnson
E-Mail : [EMAIL PROTECTED]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpLeZd4D2Zqv.pgp
Description: PGP signature
Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI
Robin H. Johnson wrote: > If you have an ebuild with a non-standard pkg_nofetch, please ensure > that you use $SRC_URI instead of $A! > > This is because if you have FEATURES=mirror or FEATURES=cvs, attempts to > download all of the source files for digesting or verification will hit > pkg_nofetch and $A is only the subset of $SRC_URI, causing misleading > messages to be displayed about what needs to be downloaded still. > > Plasmaroo: could you perhaps change this in the devmanual? > > I'll be looking through the tree to fix any existing occurrences of this. Displaying $SRC_URI is worse for the user, because it displays this weird dependency tree containing USE flags that they should not need to decipher. I don't consider this something that should be "fixed." Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Virtualization Herd
Generating root filesystems for UML and Xen are basically the same process. I've heard of domi, but, bleh, I never could get it to work. I usually just make my images in chroot, and that usually works well. But, since the images are *basically* the same, that means it would be possible to use the jailtime images, unless you are running on a 64-bit arch. Then, in that case, least with gentoo, running a 64-bit kernel and 32-bit userland doesn't work for long (first glibc (re)compile, and the whole thing borks out). On Mon, 2006-07-03 at 21:09 -0400, Daniel Gryniewicz wrote: > On Mon, 2006-07-03 at 22:28 +0200, Benedikt Böhm wrote: > > On Monday 03 July 2006 21:56, Nick Devito wrote: > > > Okay, in that case, extend the vserver herd to include a larger range of > > > virtualization stuff, including Xen, Bochs, and so on. It just seems > > > more fitting to group those packages together. > > > > not really, bochs, qemu and vmware is emulation, merely used in > > virtualization > > environments > > > > uml and xen do run with VMMs and don't share anything with > > OpenVZ/Linux-VServer > > > > uml and xen could be integrated into the VPS project (with a different > > herd) > > but i don't know what their maintainers are thinking about this > > UML is not complicated or hard to maintain. I'm fairly happy > maintaining it with the help of the kernel herd, and (being a linux > kernel port) I think it really belongs in kernel, not in virtualization > or vmm or vserver, or whatever. > > Maybe if there were some projects for full virtual server setups that > could use xen or uml or vmware or ... as it's underlying hosting > service, that could be useful, but just for maintenance, I don't think > it's really necessary. > > I'm open to arguments in favor of such a project, tho, if people have > real plans. Certainly, an easier way to generate and maintain root > filesystems for UML would be nice. > > Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Virtualization Herd
On Mon, 2006-07-03 at 22:28 +0200, Benedikt Böhm wrote: > On Monday 03 July 2006 21:56, Nick Devito wrote: > > Okay, in that case, extend the vserver herd to include a larger range of > > virtualization stuff, including Xen, Bochs, and so on. It just seems > > more fitting to group those packages together. > > not really, bochs, qemu and vmware is emulation, merely used in > virtualization > environments > > uml and xen do run with VMMs and don't share anything with > OpenVZ/Linux-VServer > > uml and xen could be integrated into the VPS project (with a different herd) > but i don't know what their maintainers are thinking about this UML is not complicated or hard to maintain. I'm fairly happy maintaining it with the help of the kernel herd, and (being a linux kernel port) I think it really belongs in kernel, not in virtualization or vmm or vserver, or whatever. Maybe if there were some projects for full virtual server setups that could use xen or uml or vmware or ... as it's underlying hosting service, that could be useful, but just for maintenance, I don't think it's really necessary. I'm open to arguments in favor of such a project, tho, if people have real plans. Certainly, an easier way to generate and maintain root filesystems for UML would be nice. Daniel signature.asc Description: This is a digitally signed message part
[gentoo-dev] pkg_nofetch: $A vs. $SRC_URI
If you have an ebuild with a non-standard pkg_nofetch, please ensure that you use $SRC_URI instead of $A! This is because if you have FEATURES=mirror or FEATURES=cvs, attempts to download all of the source files for digesting or verification will hit pkg_nofetch and $A is only the subset of $SRC_URI, causing misleading messages to be displayed about what needs to be downloaded still. Plasmaroo: could you perhaps change this in the devmanual? I'll be looking through the tree to fix any existing occurrences of this. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpNEPQYKqLDo.pgp Description: PGP signature
[gentoo-dev] New sub-project Gentoo Science Physics
Hi I'm glad to announce a new sub project from Gentoo Science. The Physics sub project! You may noticed i created a new category on the tree and moved a few packages from another categories to the new one. Now the future is to maintain and add new applications to provide the best platform for science development on the opensource world. We encourage the participation of all scientists(or future scientists :)) like us to help with this job, you can submit and research new packages, help us fixing bugs and creating documentation. Greetings -- Gentoo Linux Developer http://dev.gentoo.org/~metalgod -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New sub-project Gentoo Science Physics
Hi I'm glad to announce a new sub project from Gentoo Science. The Physics sub project! You may noticed i created a new category on the tree and moved a few packages from another categories to the new one. Now the future is to maintain and add new applications to provide the best platform for science development on the opensource world. We encourage the participation of all scientists(or future scientists :)) like us to help with this job, you can submit and research new packages, help us fixing bugs and creating documentation. Greetings -- Gentoo Linux Developer http://dev.gentoo.org/~metalgod -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for July
Mike Frysinger wrote: > On Monday 03 July 2006 15:41, Henrik Brix Andersen wrote: >> On Mon, Jul 03, 2006 at 03:04:55PM -0400, Mike Frysinger wrote: >> > the entire point of these threads is to address developer concerns >> > to that sunrise can be folded back into Gentoo >> >> Really? According to who? > > presumably the Sunrise guys considering they started the thread > Yeah, this is right. Sunrise is meant to be Gentoo. >> We only just had the userrel + sunrise meeting where the people behind >> Project Sunrise said they would continue the project as an unofficial >> project. > > Stefan would have to comment on this then > Yeah, we got frequent problems with offical/unofficial/suspended or not so much suspended. Consequently to sort out this issue we came to the conclusion to make it fully unofficial in the meeting. It works this way but it is not how I wish Sunrise to operate. It needs to have approval and that is why we discuss Sunrise and improve it constantly. >> Even if they have changed their minds about this, I think it is too >> early to re-evaluate the project for inclusion. > > maybe, but ignoring constant requests for feedback isnt helping anyone > -mike Agreed, and waiting does not help Sunrise either. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Virtualization Herd
That's what I was trying to say is that bochs/qemu/vmware are emulation since they emulate x86 hardware, though I would see some good by including Xen and User-mode Linux with the VPS Project, since that seems fitting. Oh yeah, don't forget vmware-server, that's supposely supposed to be used in virtualization enviroments (I personally haven't tried it, but, it's on my todo list to play around with most virtualization technology least once :) On Mon, 2006-07-03 at 22:38 +0200, Benedikt Böhm wrote: > On Monday 03 July 2006 22:28, Benedikt Böhm wrote: > > On Monday 03 July 2006 21:56, Nick Devito wrote: > > > Okay, in that case, extend the vserver herd to include a larger range of > > > virtualization stuff, including Xen, Bochs, and so on. It just seems > > > more fitting to group those packages together. > > > > not really, bochs, qemu and vmware is emulation, merely used in > > virtualization environments > > s/merely/barely/ > > > > > uml and xen do run with VMMs and don't share anything with > > OpenVZ/Linux-VServer > > > > uml and xen could be integrated into the VPS project (with a different > > herd) but i don't know what their maintainers are thinking about this > > > > > On Mon, 2006-07-03 at 21:48 +0200, Benedikt Böhm wrote: > > > > On Monday 03 July 2006 19:49, Nick Devito wrote: > > > > > Looking at the number of virtualization-related packages (xen, > > > > > openvz, and related packages) that are in portage, and the increasing > > > > > complexity of these packages (which means more problems, as usual), > > > > > I'm suggesting that a Virtualization herd be formed to handle these > > > > > packages. I was also going to suggest moving virtualization-related > > > > > things out of app-emulation, since they don't quite fit the bill of > > > > > "emulation". Maybe QEMU, Bochs, and VMWare would fit, but, not quite. > > > > > These are the packages that would be affected: > > > > > > > > > > * Xen/Xen-tools > > > > > * QEMU > > > > > * OpenVZ > > > > > * Bochs > > > > > * VMWare (workstation, server, etc) > > > > > * User-mode Linux > > > > > > > > > > ..and the list goes on... > > > > > > > > the packages related to OS-level virtualization (OpenVZ, Linux-VServer) > > > > are already in the vserver herd > > > > > > > > > Just a suggestion :) > > > > > > > > > > ~ Nick > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Virtualization Herd
On Monday 03 July 2006 22:28, Benedikt Böhm wrote: > On Monday 03 July 2006 21:56, Nick Devito wrote: > > Okay, in that case, extend the vserver herd to include a larger range of > > virtualization stuff, including Xen, Bochs, and so on. It just seems > > more fitting to group those packages together. > > not really, bochs, qemu and vmware is emulation, merely used in > virtualization environments s/merely/barely/ > > uml and xen do run with VMMs and don't share anything with > OpenVZ/Linux-VServer > > uml and xen could be integrated into the VPS project (with a different > herd) but i don't know what their maintainers are thinking about this > > > On Mon, 2006-07-03 at 21:48 +0200, Benedikt Böhm wrote: > > > On Monday 03 July 2006 19:49, Nick Devito wrote: > > > > Looking at the number of virtualization-related packages (xen, > > > > openvz, and related packages) that are in portage, and the increasing > > > > complexity of these packages (which means more problems, as usual), > > > > I'm suggesting that a Virtualization herd be formed to handle these > > > > packages. I was also going to suggest moving virtualization-related > > > > things out of app-emulation, since they don't quite fit the bill of > > > > "emulation". Maybe QEMU, Bochs, and VMWare would fit, but, not quite. > > > > These are the packages that would be affected: > > > > > > > > * Xen/Xen-tools > > > > * QEMU > > > > * OpenVZ > > > > * Bochs > > > > * VMWare (workstation, server, etc) > > > > * User-mode Linux > > > > > > > > ..and the list goes on... > > > > > > the packages related to OS-level virtualization (OpenVZ, Linux-VServer) > > > are already in the vserver herd > > > > > > > Just a suggestion :) > > > > > > > > ~ Nick -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Virtualization Herd
On Monday 03 July 2006 21:56, Nick Devito wrote: > Okay, in that case, extend the vserver herd to include a larger range of > virtualization stuff, including Xen, Bochs, and so on. It just seems > more fitting to group those packages together. not really, bochs, qemu and vmware is emulation, merely used in virtualization environments uml and xen do run with VMMs and don't share anything with OpenVZ/Linux-VServer uml and xen could be integrated into the VPS project (with a different herd) but i don't know what their maintainers are thinking about this > > On Mon, 2006-07-03 at 21:48 +0200, Benedikt Böhm wrote: > > On Monday 03 July 2006 19:49, Nick Devito wrote: > > > Looking at the number of virtualization-related packages (xen, openvz, > > > and related packages) that are in portage, and the increasing > > > complexity of these packages (which means more problems, as usual), I'm > > > suggesting that a Virtualization herd be formed to handle these > > > packages. I was also going to suggest moving virtualization-related > > > things out of app-emulation, since they don't quite fit the bill of > > > "emulation". Maybe QEMU, Bochs, and VMWare would fit, but, not quite. > > > These are the packages that would be affected: > > > > > > * Xen/Xen-tools > > > * QEMU > > > * OpenVZ > > > * Bochs > > > * VMWare (workstation, server, etc) > > > * User-mode Linux > > > > > > ..and the list goes on... > > > > the packages related to OS-level virtualization (OpenVZ, Linux-VServer) > > are already in the vserver herd > > > > > Just a suggestion :) > > > > > > ~ Nick -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Virtualization Herd
Okay, in that case, extend the vserver herd to include a larger range of virtualization stuff, including Xen, Bochs, and so on. It just seems more fitting to group those packages together. On Mon, 2006-07-03 at 21:48 +0200, Benedikt Böhm wrote: > On Monday 03 July 2006 19:49, Nick Devito wrote: > > Looking at the number of virtualization-related packages (xen, openvz, > > and related packages) that are in portage, and the increasing complexity > > of these packages (which means more problems, as usual), I'm suggesting > > that a Virtualization herd be formed to handle these packages. I was > > also going to suggest moving virtualization-related things out of > > app-emulation, since they don't quite fit the bill of "emulation". Maybe > > QEMU, Bochs, and VMWare would fit, but, not quite. These are the > > packages that would be affected: > > > > * Xen/Xen-tools > > * QEMU > > * OpenVZ > > * Bochs > > * VMWare (workstation, server, etc) > > * User-mode Linux > > > > ..and the list goes on... > > the packages related to OS-level virtualization (OpenVZ, Linux-VServer) are > already in the vserver herd > > > > > Just a suggestion :) > > > > ~ Nick -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for July
On Monday 03 July 2006 15:41, Henrik Brix Andersen wrote: > On Mon, Jul 03, 2006 at 03:04:55PM -0400, Mike Frysinger wrote: > > the entire point of these threads is to address developer concerns > > to that sunrise can be folded back into Gentoo > > Really? According to who? presumably the Sunrise guys considering they started the thread > We only just had the userrel + sunrise meeting where the people behind > Project Sunrise said they would continue the project as an unofficial > project. Stefan would have to comment on this then > Even if they have changed their minds about this, I think it is too > early to re-evaluate the project for inclusion. maybe, but ignoring constant requests for feedback isnt helping anyone -mike pgpYPrPohmJFl.pgp Description: PGP signature
Re: [gentoo-dev] Virtualization Herd
On Monday 03 July 2006 19:49, Nick Devito wrote: > Looking at the number of virtualization-related packages (xen, openvz, > and related packages) that are in portage, and the increasing complexity > of these packages (which means more problems, as usual), I'm suggesting > that a Virtualization herd be formed to handle these packages. I was > also going to suggest moving virtualization-related things out of > app-emulation, since they don't quite fit the bill of "emulation". Maybe > QEMU, Bochs, and VMWare would fit, but, not quite. These are the > packages that would be affected: > > * Xen/Xen-tools > * QEMU > * OpenVZ > * Bochs > * VMWare (workstation, server, etc) > * User-mode Linux > > ..and the list goes on... the packages related to OS-level virtualization (OpenVZ, Linux-VServer) are already in the vserver herd > > Just a suggestion :) > > ~ Nick -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for July
On Mon, Jul 03, 2006 at 03:04:55PM -0400, Mike Frysinger wrote: > the entire point of these threads is to address developer concerns > to that sunrise can be folded back into Gentoo Really? According to who? We only just had the userrel + sunrise meeting where the people behind Project Sunrise said they would continue the project as an unofficial project. Even if they have changed their minds about this, I think it is too early to re-evaluate the project for inclusion. Regards, Brix PS: There is no need to CC: me on replies. Please use reply-to-list. -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpPBhFAF5VW7.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for July
On Monday 03 July 2006 14:47, Henrik Brix Andersen wrote: > I have no problem with Project Sunrise being an unofficial project, > which is why I haven't responded to those mails. the entire point of these threads is to address developer concerns to that sunrise can be folded back into Gentoo -mike pgpmdyUzJbf6M.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for July
On Mon, Jul 03, 2006 at 02:43:32PM -0400, Mike Frysinger wrote: > On Monday 03 July 2006 09:50, Bryan Ãstergaard wrote: > > No, brix is certainly not happy with a overlay like sunrise in any > > official capacity. > > then he needs to voice his concerns > > we've had a few threads calling for people to list their problems so they can > be addressed and i dont recall anyone piping up that hasnt been addressed I have no problem with Project Sunrise being an unofficial project, which is why I haven't responded to those mails. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpFEkvganiQ8.pgp Description: PGP signature
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for July
On Monday 03 July 2006 09:50, Bryan Ãstergaard wrote: > No, brix is certainly not happy with a overlay like sunrise in any > official capacity. then he needs to voice his concerns we've had a few threads calling for people to list their problems so they can be addressed and i dont recall anyone piping up that hasnt been addressed -mike pgpUsCwGkzD7V.pgp Description: PGP signature
[gentoo-dev] Virtualization Herd
Looking at the number of virtualization-related packages (xen, openvz, and related packages) that are in portage, and the increasing complexity of these packages (which means more problems, as usual), I'm suggesting that a Virtualization herd be formed to handle these packages. I was also going to suggest moving virtualization-related things out of app-emulation, since they don't quite fit the bill of "emulation". Maybe QEMU, Bochs, and VMWare would fit, but, not quite. These are the packages that would be affected: * Xen/Xen-tools * QEMU * OpenVZ * Bochs * VMWare (workstation, server, etc) * User-mode Linux ..and the list goes on... Just a suggestion :) ~ Nick -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for July
On Mon, Jul 03, 2006 at 08:30:42AM -0400, Mike Frysinger wrote: > On Monday 03 July 2006 08:06, Chris Gianelloni wrote: > > On Sun, 2006-07-02 at 15:26 -0400, Mike Frysinger wrote: > > > > What has the existence of Sunrise done for Gentoo? What new packages > > > > are now in the tree because of it? What new developers have been > > > > recruited because of it? What packages that were previously without > > > > maintainers in the tree have found maintainers due to Sunrise? > > > > > > why do any of these matter at this point of time ? you cant kill a > > > project for failing to accomplish any of its goals when it hasnt been > > > given real time yet to actually accomplish them > > > > Nor was I trying to in any way. Instead, I don't see any point in > > discussing something that still needs time to mature. The project > > hasn't been around long enough to accomplish anything, so again, what is > > there to discuss? > > the project was suspended because developers were severely unhappy with it > > the issues are whether said developers feel all of their grievances have been > addressed ... so far it would appear so > > debating whether the project has/is will accomplish things is out of > scope/off > topic > -mike No, brix is certainly not happy with a overlay like sunrise in any official capacity. This should be clear from the meeting [1] that was held between sunrise (jokey and genstef), userrel (represented by christel), brix and myself. Instead brix suggested a different solution to the problem, namely a "proxy maintainer" project that everybody seemed to be happy about at the meeting. However, while brix sees the proxy maintainer project as a replacement for the current sunrise project jokey and genstef sees it as a welcome addition. In any case it's not true that everybody is happy with sunrise yet. Regards, Bryan Østergaard 1. http://article.gmane.org/gmane.linux.gentoo.devel/39764 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for July
On Monday 03 July 2006 08:06, Chris Gianelloni wrote: > On Sun, 2006-07-02 at 15:26 -0400, Mike Frysinger wrote: > > > What has the existence of Sunrise done for Gentoo? What new packages > > > are now in the tree because of it? What new developers have been > > > recruited because of it? What packages that were previously without > > > maintainers in the tree have found maintainers due to Sunrise? > > > > why do any of these matter at this point of time ? you cant kill a > > project for failing to accomplish any of its goals when it hasnt been > > given real time yet to actually accomplish them > > Nor was I trying to in any way. Instead, I don't see any point in > discussing something that still needs time to mature. The project > hasn't been around long enough to accomplish anything, so again, what is > there to discuss? the project was suspended because developers were severely unhappy with it the issues are whether said developers feel all of their grievances have been addressed ... so far it would appear so debating whether the project has/is will accomplish things is out of scope/off topic -mike pgpLOmnJOZGQc.pgp Description: PGP signature
[gentoo-dev] adding graphviz use flag
I was going to add graphviz as a local use flag to kdevelop, when I found these: use.local.desc:media-gfx/imagemagick:graphviz - enable graphviz support use.local.desc:media-gfx/k3d:graphviz - Add graphviz support use.local.desc:net-analyzer/scapy:graphviz - Enable graphviz support use.local.desc:www-apps/bugzilla:graphviz - enable graphviz support use.local.desc:www-apps/tikiwiki:graphviz - enable graphviz support I plan on moving all of them to a new global graphviz flag unless someone screams loudly in my direction. Thanks, Caleb -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for July
On Sun, 2006-07-02 at 15:26 -0400, Mike Frysinger wrote: > > What has the existence of Sunrise done for Gentoo? What new packages > > are now in the tree because of it? What new developers have been > > recruited because of it? What packages that were previously without > > maintainers in the tree have found maintainers due to Sunrise? > > why do any of these matter at this point of time ? you cant kill a project > for failing to accomplish any of its goals when it hasnt been given real time > yet to actually accomplish them Nor was I trying to in any way. Instead, I don't see any point in discussing something that still needs time to mature. The project hasn't been around long enough to accomplish anything, so again, what is there to discuss? -- 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] Future developer
Well, I've been reading the dev mailing-list for a while now, and... I think there could not be a better first message : congratulations Paul ! He really is a very nice baby. Hope The mother feels good too. I wish you a lot of happiness (x3) ! Best regards, 2006/6/30, Paul de Vrieze <[EMAIL PROTECTED]>: I'm proud to announce the arival of a future developer. His name is "Tom". He arived last monday on 10:22 am (UTC+02). I and my wife will take care of mentoring him to full developership ;-). In the meantime, he's got his own album on http://www.cs.ru.nl/~pauldv/tom/ Paul ps. If I'm a bit away these days, it is due to me being preoccupied with my mentoring task. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net -- gentoo-dev@gentoo.org mailing list
