Unable to post the log as attachment, see $URL
simgear-2.8.0 in tree, which is supposedly unaffected.
I know it is not in tree since 30 days but it blocks boost stabilization. Please add arches if you agree
I'd not recommend 5 days as a timeframe for looking for issues, no matter what this blocks.
(In reply to comment #3) > I'd not recommend 5 days as a timeframe for looking for issues, no matter > what this blocks. This is a particular case, this is a library and we have only one package that uses it(games-simulation/flightgear)
(In reply to comment #4) > (In reply to comment #3) > > I'd not recommend 5 days as a timeframe for looking for issues, no matter > > what this blocks. > > This is a particular case, this is a library and we have only one package > that uses it(games-simulation/flightgear) I don't see how this makes it special, but I'm not the maintainer. I just disagree with rushing, just because some stuff is blocked by this. Let it be blocked then.
If we were to stabilize simgear, flightgear would need to go as well. Let's wait.
Is ok to do it now?
Still a mandatory week to go, but I don't expect anything new coming so let's go. =dev-games/simgear-2.8.0 =games-simulation/flightgear-2.8.0 @amd64, x86, ppc Fire at will.
(updated simgear) =dev-games/simgear-2.8.0-r1 =games-simulation/flightgear-2.8.0
amd64 stable
On x86 flightgear-2.8.0 has the problem that it only succeeds if uiuc is set together with laracsim, either enabled or disabled. It fails with USE="-uiuc laracsim" or USE="uiuc -laracsim".
Indeed, LARCsim uses uiuc (so won't work alone) while LARCsim provides symbols needed by uiuc as well.. I just groupped those two together under "oldfdm" USE flag. I suppose no revbump needed in this case (USE flags are of small relevance and since upack-wise flightgear is almost as big as OpenOffice, not worth rebuilding whole flightgear)
Cool, thanks! x86 stable.
ppc stable. Last arch, closing