Re: Proposed changes to wesnoth-1.16

["P. J. McDermott" <pj@pehjota.net>]

Vincent (and Rhonda, if you read this, see below),

On 2023-12-31 at 01:09, Vincent Cheng wrote:
> On Sun, Dec 31, 2023 at 12:45 AM P. J. McDermott <pj@pehjota.net> wrote:
> > However, I guess none of my changes need to be reviewed now anyway.
> > Vincent, it looks like you ignored all of my proposed changes and
> > just uploaded a bare new upstream release?  Granted, it's nice to get
> > something uploaded quickly since the package will be autoremoved from
> > testing on Tuesday, and a couple of my proposed changes are incorrect/
> > inappropriate.  But I thought at least the upstream regression patch
> > backport, DEP-5 conversion and copyright update, removal of embedded JS
> > library code copies, deprecated debian/*.tmpfile update, and font
> > symlinks fix would be good to include.  
> 
> Ah, sorry, I didn't see this thread before uploading wesnoth; I'll be
> honest, I'm not keeping a close eye on my debian mail and I'm doing
> the bare minimum to keep my packages in shape due to overall lack of
> time recently. Indeed, I just wanted to close out the RC bug.

No problem, that's understandable.

> I took a quick glance at the diff. My personal threshold for repacking
> source tarballs is higher than that of most other maintainers. I'm
> inclined to not repack unless otherwise necessary (i.e. there's
> non-DFSG-compatible stuff that needs to be removed). When it comes to
> minified js, I'd rather just store a non-minified copy in
> debian/missing-sources, leave the source tarball untouched, suppress
> the lintian warning and move on.

That addresses the missing sources (assuming the source and minified
versions match) but doesn't actually solve the embedded code copies
issue (the reason lintian warns about "embedded-javascript-library").
The JS files that are installed should be replaced with symlinks to
system copies (and dependencies added), as my commit did.

And like I said, note that 1.18 will also have src/modules/lua/ without
local changes, so it can finally be replaced with the system copy of Lua
5.4.  Repacking is generally recommended to make sure the system copy is 
used and thus there's no chance the embedded copy is accidentally used,
hiding from efforts to fix a security vulnerability across all copies in
the Debian archive (or worse, in Ubuntu where it will more likely
never get fixed).  But I guess you prefer not to repack to remove ECCs
(whether jQuery+tablesorter or Lua)?

> Otherwise please feel free to push
> your changes to games-team/wesnoth on salsa. Thank you!

Thanks!

Upstream had to push back the 1.18.0 release date and will miss Ubuntu
Noble's Debian Import Freeze. [1][2]  They suggested getting 1.17.26
(1.18 RC1, which will essentially be 1.18.0) into noble, so I propose:

  * Merge the master branch into devel and update devel to 1.17
  * Call the new package "wesnoth-1.18" to avoid going through NEW twice
    and to give users an automatic upgrade from 1.18 Beta/RC to 1.18.0
  * Upload wesnoth-1.18 1:1.17.24-1 (out now) or 1:1.17.25-1 (due
    2024-01-21) soon to give wesnoth-1.18 time to pass through NEW
    review
  * Upload wesnoth-1.18 1:1.17.26-1 (1.18 RC1), due on 2024-02-18
  * Drop the unversioned metapackages from wesnoth-1.16 and upload
    wesnoth-1.16 1:1.16.11-2 sometime before the end of February
  * After Ubuntu's Debian Import Freeze, upload the final 1.18.0 and
    1.16.12, both [3] due 2024-03-17 [2]
  * Upload 1.16.12 to bookworm-backports and PPAs
  * Merge devel into master and then master into bookworm-backports and
    *-ppa, and upload 1.18.0 to bookworm-backports and PPAs

Does this sound agreeable/correct?  I can work on this, but I'm not a DD
or DM, so I'll need sponsorship from someone for uploads (three before
March, no rush on the rest).

Now that the RC bug deadline is gone, there are a few more changes I'd
like to get into 1:1.16.11-2 by the end of February, such as trying to
fix this [4] campaigns dependency/AppStream bug.

Rhonda, what what manual AppStream data adjustments were you suggesting?
Is there a reason we can't just make wesnoth-*-core recommend all the
campaign packages?

[1]: https://github.com/wesnoth/wesnoth/issues/8187
[2]: https://wiki.wesnoth.org/1.17_Roadmap
[3]: https://github.com/wesnoth/wesnoth/pull/8137#issuecomment-1869920802
[4]: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/2033222

-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/