RFC/RFS: src:wesnoth-1.18/1:1.17.25-1
Vincent and Rhonda,
src:wesnoth-1.18 is finally ready for review in my fork's devel[1]
branch, which merges additional changes from master[2]. If everything
looks OK, one of us can push the branches to the team repository, and
you can either tag and upload it or wait maybe a day. Upstream version
1.17.26 was scheduled for release yesterday, so if it's released before
src:wesnoth-1.18 is tagged and uploaded, I'll update debian/changelog
and debian/NEWS, drop the patches applied upstream (including mentions
thereof in debian/copyright.in), and re-run debian/branchcheck to add
copyrights.csv updates to debian/copyright. It looks like it's being
prepared for release today. Otherwise, updating to 1.17.26 would come
after src:wesnoth-1.18 clears NEW, as I originally planned.
Also after src:wesnoth-1.18 clears NEW, we can remove the unversioned
wesnoth and wesnoth-core metapackages in master and you can tag and
upload src:wesnoth-1.16/1:1.16.11-2. And I'll prepare src:wesnoth-1.18
backports in late March or so, after src:wesnoth-1.18/1:1.18.0-1 and the
final 1:1.16.12-1 version of src:wesnoth-1.16.
I'm still hoping all of this can happen before Ubuntu noble's Debian
Import Freeze on 2024-02-29. (This took longer than I expected, largely
because making Wesnoth use system Lua turned out to require a little
more than just build system changes[3] and Debian's src:lua5.4 recently
broke its C++ library by removing all symbols from the ABI[4].)
I know there are a lot of changes here. Of particular interest for
review are the "Fix software centers not installing campaigns or music"
commit (especially the package relationships, descriptions, and NEWS
text) and changes related to systemd and wesnoth-BRANCH-server (e.g.
"Run wesnothd as _wesnoth:_wesnoth" and "Allow running multiple wesnothd
versions under systemd"). I'm unable to test such systemd changes, as I
don't have a sufficiently capable Debian system with systemd. But the
adduser and sysvinit changes seem to work in testing.
I've had trouble running autopkgtest on this package; any ideas?
ERROR: testbed failure: sent `auxverb_debug_fail', got `timeout', expected `ok...'
(By the way, src:wesnoth-1.18/1:1.17.26-1 will be almost completely
lintian-clean all the way to the pedantic level!)
Two issues remain; first:
On 2024-01-05 at 01:24, Vincent Cheng wrote:
> I agree with replacing embedded code copies for things like Lua and
> other system libraries (generally well known libraries with stable
> APIs and ABIs), but I also think it's futile to do so specifically for
> embedded JS (as a side tangent, I've also mostly given up on packaging
> web applications for this reason). Wesnoth does not have a
> particularly large JS footprint, but even then I don't want to be on
> the hook for sanity checking whether the addon manager is still
> functional each time jquery gets updated in Debian/Ubuntu. I'm
> perfectly happy to ignore lintian's nagging here.
I still think the JS ECCs should be replaced with libjs-jquery and
libjs-jquery-tablesorter, now because there's actually a third one
(libjs-modernizr, below), but I left them alone and just updated the
missing sources.
Upstream commit 81c31c40c53 (2023-08-05) updated these two for the first
time since commit 72111578453 (2008-10-12) with no compatibility issues,
so it seems unlikely that further updates in Debian will break anything.
But I stumbled upon a complicated privacy breach that lintian missed.
data/tools/wesnoth_addon_manager uses data/tools/addon_manager/html.py
(all in wesnoth-BRANCH-tools) to generate a local HTML file that loads
remote resources, which should be replaced:
* https://fonts.googleapis.com/css?family=Montaga%7COpen+Sans:400,400i,700,700i
fonts-open-sans is in Debian but Montaga (licensed under SIL OFL)
isn't, so that could be packaged or put here in debian/. Then some
CSS needs to be written.
* https://www.wesnoth.org/wesmere/img/favicon-32.png
Can be put here in debian/.
* https://www.wesnoth.org/wesmere/img/favicon-16.png
Same.
* https://www.wesnoth.org/wesmere/css/wesmere-1.1.1.css
This is complicated. It's built from the wesmere Web site theme[5]
using Dart Sass (wesmere/Makefile can be ported to use sassc in
Debian) and zopfli (in Debian). wesmere/sass/nonfree/_assets.scss
may need to be removed for Debian.
* https://www.wesnoth.org/wesmere/js/modernizr.js
Can use libjs-modernizr.
data/tools/addon_manager/html.py hides these remote resources from
lintian's files/privacy-breach check, which should generate a
privacy-breach-generic warning but doesn't.
The semi-nuclear option to avoid this whole issue would be to just
remove data/tools/addon_manager/* (i.e. the HTML generation stuff)
from wesnoth-BRANCH-tools and patch out the --html option from the
data/tools/wesnoth_addon_manager script. This is easily doable and also
easily removes all the JS ECCs. Would this be acceptable? Do we know
whether many users rely on generating a local HTML page of add-ons?
If this is OK, I can do this quickly. Otherwise, solving this is
complicated, as noted above.
For now, I've just made a note in debian/TODO and patched
data/tools/wesnoth_addon_manager to warn users about the generated HTML
loading resources from Google and Wesnoth servers each time the file is
viewed locally.
The other issue is that, now that src:wesnoth-1.18 is able to provide
copyright information for images, music, and sounds, the copyright file
has grown a bit huge (nowhere near as large as that of src:boost1.83 at
least): 608 KiB. I realize that the campaign packages can't depend on a
strictly-versioned wesnoth-BRANCH-data like most other packages do for
/usr/share/doc/ symlinks, because the campaign packages are intended to
be able to fall out-of-sync with the other packages. But if we add a
wesnoth-BRANCH-campaigns-common package to provide a /usr/share/doc/
common to the campaigns, we can eliminate up to 15 installed copies of
the copyright file (saving almost 9 MiB). If we do this, now is a good
time; otherwise, src:wesnoth-1.18 would have to go through NEW again
later. There's no point in doing so for src:wesnoth-1.16 (sending a
near-EOL package through NEW).
Alternatively, I could write another Perl script to split the Files
stanzas into per-package copyright files, e.g. data/core/music/* Files
stanzas in wesnoth-BRANCH-music and data/campaigns/Two_Brothers/* Files
stanzas in wesnoth-BRANCH-ttb. This also has the advantage of making
each package's copyright file more relevant to the individual package.
But each campaign copyright file would need to carry GPL-2+, CC-BY-SA-4,
and/or CC0-1 License stanzas, up to almost 30 KiB (almost 470 KiB for
all 16 campaigns). (Too bad CC-BY-SA-4 isn't in debian-policy's common
licenses list, cf. BTS #795402.)
[1]: https://salsa.debian.org/pehjota/wesnoth/-/compare/6213521...devel
[2]: https://salsa.debian.org/pehjota/wesnoth/-/compare/b20e5d0...master
[3]: https://github.com/wesnoth/wesnoth/pull/8234
[4]: https://tracker.debian.org/news/1503999/accepted-lua54-546-3-source-into-unstable/
[5]: https://github.com/wesnoth/wesmere
--
Patrick "P. J." McDermott: http://www.pehjota.net/
Lead Developer, ProteanOS: http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/
Reply to: