<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 9:55 AM Karl Kleinpaste &lt;<a href="mailto:karl@kleinpaste.org">karl@kleinpaste.org</a>&gt; 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 10:40 AM, Karl Kleinpaste
      wrote:<br>
    </div>
    <blockquote type="cite"><font face="FreeSerif">What&#39;s where, now that tag/push is done?</font></blockquote>
    <br>
    <font face="FreeSerif">OK, to follow up to myself, I got the
      auto-build results email, which reports 6 successful builds and 1
      failed deployment.  From that email, I used the link to see the
      results, and have a packages.zip (174M) containing 2 Windows
      *.exe, 1 Fedora 31 rpm, a generic tarball (funny name, has double
      &#39;.&#39;), and a deb, which I presume is generic to Debian and Ubuntu
      both (editor-less?).  No Arch build?  I&#39;m guessing that I should
      create a new release using these as the assets to be uploaded.  Or
      is there a way to auto-import them?</font>  Should we bother
    including rpm and deb files, considering such systems should pick
    them up automatically from their overall update framework?<br></div></blockquote><div><br></div><div>Answering each thing separately:</div><div><br></div><div>* Distro files:<br></div><div>    * The deb file is specifically generated as part of the Ubuntu workflow, but it&#39;s going to require a bit of manual install of deps, because that&#39;s not packaged into the file. Also no - it&#39;s not editor-less, and it would require packaging up the GtkHTML we&#39;re building from source inside of the <br></div><div>    * RPM is specific to the version of Fedora it was built on, as well.</div><div>    * Conclusion: we can probably drop both of these as release artifacts. Let distros do their own packaging that way it&#39;s properly integrated. If we want to offer our own package repositories, we should do so by offering proper repos that can be added to apt/yum/zypper/pacman etc rather than one-off download files.<br></div><div>* double &#39;.&#39; is something we need to look into in the CMake sources. I&#39;ll open an issue for that. I thought I had seen it, but chalked it up to my eyes must be going bad</div><div>* I&#39;m not sure Arch builds are a thing? I&#39;m really hazy on how Arch works. It seems like the modern day Gentoo, but with a better wiki.</div><div>* All of those assets *should* have been uploaded automatically. However, the release script appears to have choked on itself in the place I least would have expected it to do so (&quot;cd packages&quot;), thus leading to the release not being created from the tag. I&#39;m looking into this as we type. For now, you can either choose to upload the assets you want, manually, or we can wait for me to figure out What Is Going On (TM) with the release. All that I&#39;m doing inside of that &quot;packages&quot; folder is making a .tar.xz out of the .tar.gz so that both formats are uploaded.</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>
  </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>