Re: Proposed changes to wesnoth-1.16
Hi Rhonda,
On 2024-01-16 at 15:31, Rhonda D'Vine wrote:
> * P. J. McDermott <pj@pehjota.net> [2024-01-12 17:12:29 CET]:
> > On 2024-01-12 at 01:19, Vincent Cheng wrote:
> > > > So since Lua compiled as C++ isn't (yet) universal among distributions
> > > > or Lua itself, and Wesnoth still wants some compile-time changes,
> > > > upstream might not be willing to support using system Lua (even though
> > > > they did before 1.9.0), especially this late in their development cycle
> > > > while they're understandably focused on getting a release ready. But
> > > > I've developed and submitted [9] a patch series to add support to both
> > > > build systems for using system Lua 5.4 C++ on non-Windows platforms.
> > [...]
> > > > [9]: https://github.com/wesnoth/wesnoth/pull/8234
> > >
> > > I'm happy to defer to what you think is best here - whichever approach
> > > you think is more maintainable, whether it's to hack around the build
> > > system with d/rules or add the patch series that you linked above (I
> > > guess that kind of depends on how likely you think the patch series
> > > would be accepted upstream - I wouldn't really want to carry it around
> > > indefinitely).
> >
> > My pessimism was perhaps premature; I'm getting a more positive response
> > upstream to my potentially controversial and close-to-RC-version patch
> > series than I expected, so we'll see how that goes.
>
> Yeah - don't be so pessimistic about wesnoth upstream. They are pretty
> awesome on many levels and where a charm to work with over the years, even
> decades now. :)
So it seems. :) I guess I'm used to upstreams who are hostile to
somewhat large patch series that add more build configurations that need
tested just to satisfy a distribution (7kaa for example rejected most of
a patch series to support system libuuid).
> > If I add a series of related patches, for example this series of eight,
> > I think they should go in a subdirectory of debian/patches/ to keep
> > things better organized, unless you disagree.
>
> if you want to organize them better, sure. If they are not meant to stay
> around because they were taken from upstream and will vanish with next stable
> release I guess it's not worth the effort, but it doesn't hurt there neither.
Not much effort to add a "/" to patch names: "quilt new 05foo/01bar" or
"quilt import -P 05foo/01bar foo-bar.patch".
> > > > Thanks for sanity checking the plan and for the sponsorship offer! When
> > > > I have things ready to upload, should I send mail To: you and Cc: the
> > > > list or just send To: the list? I'm asking what's more convenient for
> > > > you, in case you filter and don't always read list mail but do read mail
> > > > sent To: you.
> > >
> > > Mail sent directly to me will get my attention faster, but I'll try to
> > > be better about responding to mail both on and off list.
> >
> > OK, I just thought I'd ask in case you don't have time to read the
> > list or prefer to not get duplicate messages. (Too bad SmartList
> > isn't as "smart" as GNU Mailman's "Avoid duplicate copies of messages"
> > option.)
>
> For me also the Cc was extremely helpful to notice it. I am slowly trying to
> get back into things, but digging in mailinglists often enough is costing too
> much energy for too little benefit.
OK, good to know. I've seen some people ask not to be Cc:ed.
> > > > [11]: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/2033222
> > >
> > > I don't really have any context into how appstream or Ubuntu software
> > > center works, again happy to defer to what you or Rhonda think is best
> > > here.
> >
> > Yeah, I also am inexperienced with AppStream and "software center"
> > things. Fortunately I have a Debian system lying around that came with
> > gnome-software installed, so I confirmed that GNOME Software (which uses
> > PackageKit which uses APT) would indeed install Recommends packages as
> > APT itself does by default. (I also learned that Ubuntu Software Center
> > was discontinued and replaced with GNOME Software in 2015.)
>
> I'm inexperienced too, but there must be a way for gnome-software to select
> which packages to offer. My first thought went to listing packages with a
> .desktop file. And I'd try moving that to the main package.
>
> There is a reason the -core package does not depend on the campaigns, and I
> really would love to avoid to suddenly dropping all the campaigns on users of
> the package. Newly added recommends would get pulled in on upgrade from what I
> know, by default in apt & co, so I really really would love to have such a move
> avoided.
Ah...
I did first consider moving the .desktop and .appdata.xml files to the
wesnoth-BRANCH metapackage, because that's a much cleaner solution.
But I thought those files were supposed to be in the same package as the
executable? Otherwise a user could end up with the executable not going
in their menu. And the only way to get it in their menu would be to
install the metapackage and all of the campaigns, which defeats the
purpose of the packaging split.
So unless we think of something else, users get all of the campaigns
pulled in, either if they want a menu entry or if they upgrade.
> I am scanning over the other changes you proposed, and I want to especially
> thank you a ton for the copyright file one. I tried to tame that beast
> multiple times and pushed it back from every upload I contributed to since a
> looong while now because I never managed to wrap my head around completing it.
> So that is extremely appreciated!
I'm also working on a Perl script to automatically inject into the DEP5
copyright file all of the image copyright information upstream now
conveniently provides[1][2] in 1.17/1.18!
This however adds a Perl package dependency that maintainers will need
when running debian/branchcheck, so I'll add a note to branchcheck
and/or debian/README.source.
[1]: https://github.com/wesnoth/wesnoth/raw/master/copyrights.csv
[2]: https://github.com/wesnoth/wesnoth/pull/7903#issuecomment-1716480463
> About debian/embed.c, this is about a lintian warning that will get fixed in
> future upstream versions from what I read in your comment, isn't that a bit
> over the top? :) Don't want to cut your enthusiasm short, just wondering.
Upstream turned out to be a little more reluctant[3] to merge this fix,
and understandably so especially since I later realized there's a
possible legal issue[4] with it. I'd like to fix it up-upstream,
but that involves figuring out how to report a bug against Android
(requiring a Google account).
I also realized after Vincent merged the change that I broke cross
builds. It needs to use CC_FOR_BUILD from /usr/share/dpkg/buildtools.mk
instead of CC. And debian/embed.c computes the checksum incorrectly.
If the change stays (pending above), I'll fix these issues.
[3]: https://github.com/wesnoth/wesnoth/pull/8171
[4]: https://lists.debian.org/debian-legal/2024/01/msg00007.html
> The rest about the games:games user/group was addressed by Vincent already
> from what I see.
>
> Thanks for your effort, was a charm! The more the merrier.
> Rhonda
Thanks!
--
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: