Re: RFC/RFS: src:wesnoth-1.18/1:1.17.26-1 (was: src:wesnoth-1.18/1:1.17.25-1)

On 2024-02-19 at 10:52, P. J. McDermott wrote:
> 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.

1.17.26 was tagged in upstream Git, but we're awaiting a tar archive.
I've already updated debian/changelog, debian/NEWS, debian/patches/,
and debian/copyright* for this new upstream 1.18 RC1 version.  (All
still in my fork for now until I decide I'm definitely done amending old
commits and force pushing, which by now I probably am.)

So once `uscan --download-current-version` finds a tar archive, I (or
anyone) can run one more test build (which in the new upstream version
now should be lintian-clean to pedantic level except for some fonts
tags) and debian/changelog and debian/NEWS can be finalized for upload,
unless we first address the below issue(s).

> 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