Re: HEADS UP multi processor compilations and packages
Pav Lucistnik p...@freebsd.org wrote: Brian Whalen p??e v ?t 24. 03. 2009 v 12:08 -0700: On a related topic, I wonder what the cost would be of acquiring enough hardware so that the probability of actually getting a package with portupgrade -aP would go up substantially ... It's more a question of creating a new delivery platform, because the currently used ftp mirrorring is useless for packages. The whole process of synchronizing from upstream server introduces _days_ of delay into the process, presumably addressable by adding bandwidth, which would need to be included in the cost ... of acquiring enough hardware ... and there is no guarantee that you don't catch an upload in progress, which renders whole mirror useless for a time period. I would have thought that judicious use of snapshots could avoid problems with in-progress updates. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: HEADS UP multi processor compilations and packages
per...@pluto.rain.com píše v st 25. 03. 2009 v 00:23 -0700: Pav Lucistnik p...@freebsd.org wrote: Brian Whalen p??e v ?t 24. 03. 2009 v 12:08 -0700: On a related topic, I wonder what the cost would be of acquiring enough hardware so that the probability of actually getting a package with portupgrade -aP would go up substantially ... It's more a question of creating a new delivery platform, because the currently used ftp mirrorring is useless for packages. The whole process of synchronizing from upstream server introduces _days_ of delay into the process, presumably addressable by adding bandwidth, which would need to be included in the cost ... of acquiring enough hardware ... Bandwidth is okay, but rsync is just too slow. Serial synchronization on this amount of data does not work feasibly. and there is no guarantee that you don't catch an upload in progress, which renders whole mirror useless for a time period. I would have thought that judicious use of snapshots could avoid problems with in-progress updates. Yes, but current ftp mirrors does not have enough space to hold several snapshots of same package set. Thus, the need for new platform. -- Pav Lucistnik p...@oook.cz p...@freebsd.org See file. Click file. Get file. signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: HEADS UP multi processor compilations and packages
Pav Lucistnik wrote: Two days ago, I have checked in probably most requested feature of last few years. Ports framework now systematically supports building ports on multiple processing cores. It is achieved by passing -jX flag to make(1) running on vendor code. Of course not all ports handle this well, experimental run on pointyhat with this flag globally enabled turned up shy of 400 failures. Because of that, the feature was designed as a whitelist. Individual ports need to be enabled, and indeed, fellow developers took on and already started adding required declarations to popular ports like Firefox and others. On a related topic, I wonder what the cost would be of acquiring enough hardware so that the probability of actually getting a package with portupgrade -aP would go up substantially. I imagine the time required for the build servers to build packages with the above mod would go down substantially. Brian ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: HEADS UP multi processor compilations and packages
Brian Whalen píše v út 24. 03. 2009 v 12:08 -0700: Pav Lucistnik wrote: Two days ago, I have checked in probably most requested feature of last few years. Ports framework now systematically supports building ports on multiple processing cores. It is achieved by passing -jX flag to make(1) running on vendor code. Of course not all ports handle this well, experimental run on pointyhat with this flag globally enabled turned up shy of 400 failures. Because of that, the feature was designed as a whitelist. Individual ports need to be enabled, and indeed, fellow developers took on and already started adding required declarations to popular ports like Firefox and others. On a related topic, I wonder what the cost would be of acquiring enough hardware so that the probability of actually getting a package with portupgrade -aP would go up substantially. I imagine the time required for the build servers to build packages with the above mod would go down substantially. It's more a question of creating a new delivery platform, because the currently used ftp mirrorring is useless for packages. The whole process of synchronizing from upstream server introduces _days_ of delay into the process, and there is no guarantee that you don't catch an upload in progress, which renders whole mirror useless for a time period. -- Pav Lucistnik p...@oook.cz p...@freebsd.org Do not meddle in the fashions of wizards, for they are seasonal and quick to fall out of style! signature.asc Description: Toto je digitálně podepsaná část zprávy
