Re: Proposed changes to wesnoth-1.16
On Thu, Jan 4, 2024 at 7:36 AM P. J. McDermott <pj@pehjota.net> wrote:
>
> 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.
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.
> 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)?
If you don't trust the build system used by the package and want to
ensure system build-deps are used, you can simply rm -rf the embedded
code copies in the package's clean target (dpkg-source ignores removed
files so that's generally safe to do). I think this is a lesser evil
vs repacking the upstream source tarball, and I'm not convinced it's
appropriate or necessary to do so for wesnoth, sorry.
> > 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
We could also just drop src:wesnoth-1.16 entirely at this point (we
can just file an RM request to have it be removed from sid, and if
it's done before Debian Import Freeze then it'll automatically get
removed from Ubuntu Noble as well).
> * 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).
The plan sounds fine to me, thanks for volunteering to tackle this!
I'm happy to sponsor/upload wesnoth when it's ready, feel free to ping
me and I'll try to get back ASAP.
Thanks,
Vincent
Reply to: