<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 2, 2020 at 3:50 PM Karl Kleinpaste <<a href="mailto:karl@kleinpaste.org" target="_blank">karl@kleinpaste.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>On 5/2/20 4:10 PM, Caleb Maclennan
wrote:<br>
</div>
<blockquote type="cite">
<pre>If you are deleting the tag, DO IT NOW.</pre>
</blockquote>
<font face="FreeSerif"><br>
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.</font></div></blockquote><div><br></div><div>Just want to update on this:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Additional things I'm cleaning up in the release process, since I'm in there with my monkey wrench:</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>A few last bits and pieces to clean up in the release and I'll have that PR up. Hopefully tonight.</div><div><br></div><div>--Greg<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br>
</div>
_______________________________________________<br>
xiphos-devel mailing list<br>
<a href="mailto:xiphos-devel@crosswire.org" target="_blank">xiphos-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/xiphos-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/xiphos-devel</a><br>
</blockquote></div></div>