[pkg-fgfs-crew] flightgear 3.4 packaging

[Rebecca N. Palmer]

Upstream release is due today, but nothing is tagged yet.  Ubuntu freeze 
is Thursday; it *is* possible for Ubuntu to accept packages that are 
still stuck in Debian's NEW queue (see 
https://bugs.launchpad.net/ubuntu/+source/simbody/+bug/1417830 ), so if 
simgear is still waiting when release happens, please upload 
flightgear/flightgear-data (and fgrun if possible) and push simgear 
final to Alioth (I'm not sure what happens if you make another upload 
while in the NEW queue), and I'll request a sync.

>> flightgear-data needs at least the two references to the
>> no-longer-existing Textures.high removing from d/rules.
>
> Yeah, I had those changes pending, but didn't want to commit quite yet.
> What's the story behind? Do you know why that directory doesn't exist
> anymore?

It was merged with Textures, on the grounds that hardware had moved on 
far enough that the split no longer made sense.  (There had been no 
user-facing mechanism to actually select the lower-resolution version 
for some time before this.)

> Also note that all of this webgui directory is new and flightgear-data
> wouldn't ship it at all, as it stands. I don't even know what it is, yet.

I've vaguely heard of various moving-map-etc.-in-a-browser experiments, 
but haven't tried them myself.  The policy violation (and lintian error) 
exists even if you don't ship it in the binary; repacking the .orig 
tarball to delete them from the source is also a permitted solution, but 
using debian/missing-sources has the advantage that you don't have to 
re-upload the (huge) .orig if you later do decide to ship them.

>> fgrun can stay at 3.2 if you're pressed for time, as almost nothing has
>> actually been done to it since, but it would be better to at least fix
>> the minimum simgear version in the dependency.
>
> I guess it would block the auto-simgear transition, so I plan to update
> it as well.

"auto-simgear transition" = "rebuild against new simgear": as fgrun 3.2 
does build against simgear 3.4, that isn't a blocker.  (The dependency 
issue is that fgrun 3.2 doesn't build against simgear 3.*0*, which is 
currently accepted by its d/control.)  I agree that going to 3.4 is the 
better option if you have time to do so, but wouldn't let it delay the 
others.