<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style=""><span style="display: inline !important; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"></span></div>
<p style="margin: 0in 0in 0.0001pt; line-height: normal;"><span style="border: 1pt none windowtext; padding: 0in; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Christian,</span></p>
<p style="margin: 0in 0in 0.0001pt;"><span style="border-width: 1pt; border-style: none; border-color: windowtext; padding: 0in;"><br>
</span></p>
<p style="margin: 0in 0in 0.0001pt;"><span style="border-width: 1pt; border-style: none; border-color: windowtext; padding: 0in; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">The decision was to demote release builds, but
NOT to remove x86 compatibility. If you take this as an excuse to also end x86 CI testing bots, you are effectively killing x86 through bit rot. This is not a hypothetical. As you know, @87 just recently caught a regression introduced by an easyHack to convert
use of sal_uLong to better integer types. Without CI testing, these bugs will pile up </span><span style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">effectively</span><span style="border-width: 1pt; border-style: none; border-color: windowtext; padding: 0in; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> removing
x86 compatibility.</span></p>
<p style="margin: 0in 0in 0.0001pt;"></p>
<p style="margin: 0in 0in 0.0001pt;"><span style="border: 1pt none windowtext; padding: 0in;"></span></p>
<p style="margin: 0in 0in 0.0001pt;"><span style="border: 1pt none windowtext; padding: 0in;"><br>
</span></p>
<p style="margin: 0in 0in 0.0001pt;"><span style="border: 1pt none windowtext; padding: 0in; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">In a past job, I have seen how b</span><span style="border: 1pt none windowtext; padding: 0in;"><span style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">uilding
code against multiple architectures uncovers latent bugs and code portability. T</span></span><span style="border: 1pt none windowtext; padding: 0in; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">his philosophy made ARM
and RISC ports much easier along with higher quality software.</span></p>
<p style="margin: 0in 0in 0.0001pt;"><span style="border: 1pt none windowtext; padding: 0in; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></p>
<p style="margin: 0in 0in 0.0001pt;"><span style="border: 1pt none windowtext; padding: 0in; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">If we chose to go down the path of killing x86, we should discuss it. While I agree
that overhead of x86 release build may not be worth it, the advantages of maintaining a working x86 build are clear. My suggestion would be to upgrade @87 to CentOS 7 or Debian 9.0 before bit rot makes this a difficult task. Currently master has no problem
building on 32-bit Fedora 30.</span></p>
<p style="margin: 0in 0in 0.0001pt;"><span style="border: 1pt none windowtext; padding: 0in;"><br>
</span></p>
<p style="margin: 0in 0in 0.0001pt; line-height: normal;"><span style="border: 1pt none windowtext; padding: 0in; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">-Luke</span><span style="font-size: 12pt; font-family: "Segoe UI", sans-serif; color: rgb(50, 49, 48); font-size: 12pt;"></span></p>
<p style="margin: 0in 0in 8pt;"><span style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"></span></p>
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Christian Lohmaier <lohmaier+libreoffice@googlemail.com><br>
<b>Sent:</b> Tuesday, June 4, 2019 6:17 AM<br>
<b>To:</b> Luke Benes<br>
<b>Subject:</b> Re: @87 reboot?</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">Hi Luke,<br>
<br>
On Sun, Apr 14, 2019 at 6:40 PM Luke Benes <lukebenes@hotmail.com> wrote:<br>
><br>
> Christian,<br>
> No rush, just a polite ping. Looks like @87 is stuck.<br>
<br>
It's not really stuck per se, it is just that the old baseline is no<br>
longer suitable for master/libreoffice-6-3 (glib2 requirement not<br>
fullfilled) - with 6.2 we demoted 32bit linux builds provided by TDF<br>
(they for example already don't include all vclplugins, most notably<br>
gtk3) and stated that 6.2 will be last line with 32bit builds provided<br>
by TDF (of course distros continue to provide buidls, and 32bit<br>
support in sourcecode is not removed).<br>
<br>
So unless there's an outcry of users there won't be master buidls by<br>
that box anymore - (well even if there is there won't be, but rather<br>
32bit version then would be cross-compiled from a 64bit host)<br>
<br>
ciao<br>
Christian<br>
</div>
</span></font></div>
</div>
</body>
</html>