On 09/06/13 23:13, Theo de Raadt wrote:
On Fri, Sep 6, 2013 at 7:14 AM, Lars Engblom
<lars.engb...@kimitotelefon.fi>wrote:
Quite often the snapshot of the packages and the base system are out of
sync, because naturally, the base has to be built before packages.
For example in this moment, as I write this, Firefox can not be installed
in a new system installed from snapshots, as the packages are compiled
against an older snapshot (amd64)
If there are just space on the ftp servers, I would suggest keeping two
snapshots: one complete with both base and packages (always in sync) and
one with just the newest base. This would make life easier for people
following snapshots.
Regards,
Lasse
The problem with ports is that even with a build farm, the ports guy has to
make sure dpb runs to the end. In the best case, a dpb run WITHOUT problems
to the end takes atleast a day with a fast quad core machine. gcc4, JDK 1.6
+ 1.7, GTK+2, GTK+3, Qt4, Webkit, Firefox are some of the worst ports in
terms of build time and the largest offender Libreoffice which alone takes
4-6 hrs of all quad cores (Xeon E3-1230v2 3.3GHz). I might have missed some
offenders, I just built a subset, experienced porters who handle the whole
tree know better than me which ones are also worthy candidates.
Finding and fixing port problems takes a minimum of 2 and I am guessing
typically 4 days to pump out a wholly built ports tree, on a extremely fast
arch like amd64. By which time the userland, kernel and xenocara have
changed a lot underneath. Hence, you get these mismatches from time to
time. It is not catastrophic, solution is to wait for the next snap. Even
if the ports build machine untars userland, kernel, xenocara, running dpb
again may force rebuilds or sometimes not.
Anyone want to pay for a faster network link?
Step up -- then we can solve this problem easily.
OK. How much would it cost per month for faster access? Do you have
several options for increased speeds?
I smell a fundraiser here--paying for a year's costs in advance. Perhaps
then others would come up with larger chunks for future costs. It
would certainly be bad to not be able to come up with the funds for
the future net costs. I think it should be thought of as another cost,
just like new hardware.
--STeve Andre'
