Preliminary IceCat 68.2 package

Preliminary IceCat 68.2 package

[Mark H Weaver]

Hello fellow Guix,

I was finally able to successfully build a working IceCat-68.2 package.
The 'wip-icecat-68' branch on Savannah contains this preliminary work.

A few caveats:

* IceCat 68 has not yet been released upstream.  This is very much a
  work-in-progress, and does not currently meet the privacy-respecting
  standards of the IceCat project.  There are still several issues to be
  resolved.  In particular, it might be that some information is being
  sent to Google or Mozilla without your knowledge.

* Many earlier attempts to build it have failed due to non-deterministic
  failures in the build system, possibly due to a bug in the Cargo tool.
  I'm not sure how much luck was involved in my successful build.  Your
  mileage may vary.

I'd be curious to hear whether others are able to build it successfully,
and whether it works for them.  I'd be grateful if others would try
building it and report back on their experiences.

      Thanks,
        Mark

PS: Many thanks to Efraim Flashner <efraim@flashner.co.il> for
    contributing the package definition for 'rust-cbindgen', and to
    Amin Bandali <bandali@gnu.org> for producing the first preliminary
    working version of IceCat 68.

Re: Preliminary IceCat 68.2 package

[Mark H Weaver]

I wrote:
> * Many earlier attempts to build it have failed due to non-deterministic
>   failures in the build system, possibly due to a bug in the Cargo tool.
>   I'm not sure how much luck was involved in my successful build.  Your
>   mileage may vary.

Having now done a few more test builds, I'm sorry to say that the build
seems to often fail non-deterministically.  Most of my attempts have
failed so far.

The most common failure mode is described in these bug reports for
Gentoo and BLFS:

  https://bugs.gentoo.org/show_bug.cgi?id=680934
  http://wiki.linuxfromscratch.org/blfs/ticket/11975#comment:6

Those errors, where a backtrace is printed by cargo, happen at a
different place in the build every time.  If you're lucky, you might get
through the entire build without hitting that bug.

I'd be very grateful for help debugging these failures or finding a
workaround.

Note that the 'wip-icecat-68' branch is at the precise commit where I
had my successful build.  In case anyone is interested, I've made
available the NAR of my successful, ungrafted build here:
<https://www.netris.org/~mhw/guix/icecat-68-preview/>.  Note that the
NAR doesn't include any dependencies, so you'll need to build those
locally before importing the NAR, and then apply grafts locally
afterwards.  Also note that I cannot guarantee the integrity of the
machine that I built it on, which includes a web server and mail server,
among other things, so I cannot guarantee the integrity of the NAR
itself.  I prefer to avoid distributing binaries for that reason, but if
you want to try it, there it is.

      Mark

Re: Preliminary IceCat 68.2 package

[Andy Wingo]

Heya Mark :)

On Wed 23 Oct 2019 12:32, Mark H Weaver <mhw@netris.org> writes:

> I wrote:
>> * Many earlier attempts to build it have failed due to non-deterministic
>>   failures in the build system, possibly due to a bug in the Cargo tool.
>>   I'm not sure how much luck was involved in my successful build.  Your
>>   mileage may vary.
>
> Having now done a few more test builds, I'm sorry to say that the build
> seems to often fail non-deterministically.  Most of my attempts have
> failed so far.
>
> The most common failure mode is described in these bug reports for
> Gentoo and BLFS:
>
>   https://bugs.gentoo.org/show_bug.cgi?id=680934
>   http://wiki.linuxfromscratch.org/blfs/ticket/11975#comment:6
>
> Those errors, where a backtrace is printed by cargo, happen at a
> different place in the build every time.  If you're lucky, you might get
> through the entire build without hitting that bug.
>
> I'd be very grateful for help debugging these failures or finding a
> workaround.

I don't know what this is, but at work I have to build Firefox a lot,
and sometimes the rust bits die in the middle of compilation.  Is it a
resource exhaustion issue?  I am not sure.  In any case, continuing to
"make" always solves it for me.  I know that's not very reassuring, but
if you're looking for a quick workaround, running your "make -jN" in a
loop 5 times or something may be good enough.

Cheers,

Andy

Re: Preliminary IceCat 68.2 package

[Mark H Weaver]

Hi Andy,

Andy Wingo <wingo@igalia.com> wrote:
>> I'd be very grateful for help debugging these failures or finding a
>> workaround.
>
> I don't know what this is, but at work I have to build Firefox a lot,
> and sometimes the rust bits die in the middle of compilation.  Is it a
> resource exhaustion issue?  I am not sure.  In any case, continuing to
> "make" always solves it for me.  I know that's not very reassuring, but
> if you're looking for a quick workaround, running your "make -jN" in a
> loop 5 times or something may be good enough.

Thank you, this is a good idea.  It's highly unfortunate that we must
resort to such an awful hack, but given the time constraints, we don't
have much of a choice here, and it's clearly what needs to be done.

Thanks for helping me to see that!

     Regards,
       Mark

Re: Preliminary IceCat 68.2 package

[Mark H Weaver]

Hi Andy,

Andy Wingo <wingo@igalia.com> writes:
> I know that's not very reassuring, but if you're looking for a quick
> workaround, running your "make -jN" in a loop 5 times or something may
> be good enough.

Thanks again for suggesting this.  I was stuck, and you got me unstuck,
and for that I'm very grateful.

I've pushed a new 'wip-icecat-68' branch with a preliminary IceCat 68.2
package that should now build *far* more reliably.

      Mark