> 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.
