Re-add rkward build to binary factory

[Ben Cooksley]

On Tue, Jun 18, 2019 at 10:19 PM Thomas Friedrichsmeier
<thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:
>
> Hi,

Hi Thomas,

>
> On Sat, 15 Jun 2019 12:22:39 +0200
> Hannah von Reth <vonreth at kde.org> wrote:
> > currently we are unable to build QtWebkit with mingw.
> >
> > It should be possible to fix QtWebkit,
> > https://github.com/msys2/MINGW-packages/blob/2cfdf054df2c826d7c61237ee5ac2453b0f3964d/mingw-w64-qtwebkit/PKGBUILD
> > the patches here might help.
>
> could you give me some details? After re-enabling the build for MinGW,
> qtwebkit just compiled out of the box. It took forever, but did not
> require any patching. Admittedly, I have cheated a tiny bit by building
> with --buildtype Release, as RelWithDebInfo exceeded my (virtual) disk
> space.
>
> I'd like to point of the perhaps the entire reason for the continued
> existence of QtWebKit *is* MinGW, or more precisely the fact that
> QtWebEngine cannot be built with MinGW, and thus is not available as an
> alternative.
>
> > The mingw builds where recently removed after several month of
> > failing.
>
> And just now our MacOS build has been removed, as well. I know it has
> been failing. *Again* without any change on *our* end.
>
> I'm not directing the following sigh at anyone in particular, as I know
> there isn't the right address for it. It still wants out though:
>
> I'd love to have more time for the project. But I don't. It totally
> sucks to come back from a hiatus after a few months, only to find out
> that there's not just a lack of progress, but the project has been
> broken by external changes, left broken, *and* removed without notice.
> Instead of going anywhere, I'm spending hours just trying to get back
> to the baseline. No fun.

Sorry about the MacOS removal. That was unintentional and an oversight
on my part when I was enabled the MSVC Windows builds.
Turns out the Python YAML parser is very tolerant of invalid YAML.

It's fixed now and the job should be restored shortly.

With regards to why the RKWard job regressed, this is a limitation of
R.framework on MacOS it would seem. In the past few months we've
switched to using a Binary Cache, meaning builds on the Binary Factory
are now faster and can be more reliably reproduced outside of the
single Binary Factory system. It also supports us having a second
machine in the future should we so wish to do so.

Unfortuantely it does mean that path rewriting must now work fully,
otherwise stale paths will be referenced (and cause failures). I'm not
sure why R.framework is mentioning a system wide location directly
like that though.

Chances are the correct solution for this will be to rewrite paths
within R.framework as part of it's unpacking process - once that is
sorted.

>
> Regards
> Thomas
>
>

Thanks,
Ben