[pkg-fgfs-crew] flightgear 3.4 packaging
Rebecca N. Palmer
rebecca_palmer at zoho.com
Tue Feb 17 12:06:22 UTC 2015
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
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
More information about the pkg-fgfs-crew