Re: RFC/RFS: src:wesnoth-1.18/1:1.17.26-1 (was: src:wesnoth-1.18/1:1.17.25-1)
On Mon, Feb 19, 2024 at 11:18 PM P. J. McDermott <pj@pehjota.net> wrote:
>
> 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).
Thank you! I merged in all of the commits on your devel branch, made a
few minor changes, tagged it and am currently uploading as we speak.
Thanks in particular for getting all the lua stuff upstreamed, for all
the work you put into d/copyright, and for dealing with all the
existing lintian issues!
> > 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.
If src:wesnoth-1.18 doesn't clear NEW in time for Debian Import Freeze
(4 days from now unfortunately - sorry I couldn't get around to
reviewing this earlier in the week), any objections if I go ahead and
file a RM bug for src:wesnoth-1.16 after the freeze date passes (since
the only reason we're keeping 1.16 around is to let both 1.16 and 1.18
get synced into Ubuntu noble)? There's not really any reason to keep
maintaining 1.16 in Debian proper once src:wesnoth-1.18 lands in sid
(I expect most folks have the metapackages installed and will get
upgraded to 1.18), and it saves us time from having to package and
upload 1.16 in addition to 1.18.
> > 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.
The extent of my testing was to do a cursory wesnoth-1.16 ->
wesnoth-1.18 upgrade attempt in a container before uploading to NEW.
I'll let piuparts report on any other install/upgrade/removal errors
(if they exist) later, and I guess we'll wait for user bug reports for
anyone that's running the -server package.
> > I've had trouble running autopkgtest on this package; any ideas?
> >
> > ERROR: testbed failure: sent `auxverb_debug_fail', got `timeout', expected `ok...'
How are you running autopkgtest / do you have additional layers of
containerization/virtualization that might be interfering somehow? I'm
running autopkgtests with the pbuilder hook that's shipped with the
package (/usr/share/doc/pbuilder/examples/B20autopkgtest) and that
works fine for me for wesnoth.
> > (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.
At this point I think I'd be in favour of just not shipping
data/tools/addon_manager/* in wesnoth-tools at all; I imagine most end
users are using the built in addon client, and upstream devs or addon
developers are probably not using the version we ship in wesnoth-tools
(tbh I'm not really sure who our target audience is for the -tools
package).
> > 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.)
I'd be in favour of keeping things simple here and just accepting
duplicated copyright data, as is the case for most other packages.
It's still a small percentage overall relative to the total size of
wesnoth and all of its campaigns installed. Having a -common package
and symlinking the copyright file in all the other campaign packages
is a violation of Policy 12.5 [1] (and it'll get flagged by lintian).
Trying to produce different copyright files for each campaign is
frankly too much work and not something I'd like to have to maintain.
[1] https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information
Thanks,
Vincent
Reply to: