[xiphos-devel] 4.2.0 tagged and pushed

[Greg Hellings]

On Sat, May 2, 2020 at 3:50 PM Karl Kleinpaste <karl at kleinpaste.org> wrote:

> On 5/2/20 4:10 PM, Caleb Maclennan wrote:
>
> If you are deleting the tag, DO IT NOW.
>
>
> At this point, we'll just let 4.2.0 go, and tag 4.2.1 for a real release
> once Greg does his patch.
>

Just want to update on this:

1) I fell off the bandwagon this weekend and got sucked into a video game.
Totally forgot to come up for air and take care of my commitments. My
apologies.

2) The problem with the release arose because I didn't pin the version of
the release actions we were using in Github Actions. I specified to use
@master instead of @v1 for the upload/download artifact steps. Between when
I pushed my version and when Karl made the release v2 of it was released,
and it changed the directory structure of how the artifacts are downloaded.
That's what caused the break in 4.2.0 release. I've resolved this portion
now.

Additional things I'm cleaning up in the release process, since I'm in
there with my monkey wrench:
3) Not generating RPM and DEB files any longer. This is just going to be
fraught with trouble, as downstream distros contain lots of conditionals
and building criteria. Also, because on the Deb architectures we're
building against libraries that aren't packed by upstream any longer. So
there's no reason to release a deb file that simply can't be installed any
longer.

4) The mingw-biblesync packages are now in stable form in the Fedora
repositories, and they squeaked in just under the wire for inclusion in
Fedora 30 (that goes EOL this month, so we cut it pretty close on that). So
I've updated the Windows build process to no longer build that from source,
but rather to install the pre-built binaries. It's such a small library
that this isn't really any, or much, of a time saver in the builds, but
it's unnecessary steps, so we can now skip that step.

5) I've moved the dnf install steps of the Windows build into a Dockerfile.
For the purposes of release and CI, this doesn't really change anything,
because we want to make sure that Dockerfile is up to date. However, from a
developer's perspective it can change a whole lot. Instructions are
included, but now you can run the "docker/podman build -t xiphos_win"
command one time and it will create a container image with all the
dependency packages already installed and it already will know where to
look for the cross-compile shell script to run it. From then on, to create
a Windows build, all you need to do is execute "docker/podman run -it -v
path/to/xiphos:/source xiphos_win" and pass it the arguments for the shell
script. It will no longer need to download repository metadata or packages
every time you want to test a build. It will still do a clean configure and
build from scratch, but unless you're editing the Dockerfile itself (e.g.
changing the dependency packages), there will be no need to re-run the
container build on subsequent steps. For those of us on limited or slow
bandwidth this is a huge gain, and it's probably a significant gain for
most everyone.

6) I've discovered the source of the spurious "." in the source files. It
comes when you do a "cpack -G TGZ" instead of "make package_source". CPack
should not be used to generate the source directly, as it turns out.

A few last bits and pieces to clean up in the release and I'll have that PR
up. Hopefully tonight.

--Greg

>
> _______________________________________________
> xiphos-devel mailing list
> xiphos-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/xiphos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/xiphos-devel/attachments/20200506/c0a1569a/attachment.html>