GNU bug report logs - #48273
Icedove 78.10.0 build stuck at 'unpack' phase

Previous Next

Full log

Message #44 received at 48273 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>, 48273 <at> debbugs.gnu.org
Subject: Re: Icedove 78.10.0 build stuck at 'unpack' phase
Date: Fri, 04 Jun 2021 20:42:32 -0400

Hi Jonathan,

I wrote:
> Unfortunately, not all of our package definitions respect the --cores
> option.  Our 'icecat' package does, but I can see now that our
> 'icedove' package does _not_ respect it.  It would be good to fix that.

Jonathan Brielmaier <jonathan.brielmaier <at> web.de> replied:
> @Mark: Yes, it would by nice to fix that. Do we make something special
> in Icecat to achieve that? I couldn't find anything obvious on a first
> view...

There's nothing special in the IceCat package to achieve it.  The
relevant code is in the default 'build' phase from 'gnu-build-system',
here:

<https://git.sv.gnu.org/cgit/guix.git/tree/guix/build/gnu-build-system.scm?id=7382aa00b82860762bc326dec6b45f8cd2161327#n338>

_ (define* (build #:key (make-flags '()) (parallel-build? #t)
_________________ #:allow-other-keys)
___ (apply invoke "make"
__________ `(,@(if parallel-build?
__________________ `("-j" ,(number->string (parallel-job-count)))
__________________ '())
____________ ,@make-flags)))

The problem is that the 'icedove' package has a custom 'build' phase
that does not honor (parallel-job-count).

Ultimately, the relevant difference between the two packages is that the
'icecat' package uses the 'gnu-build-system' approach of running
"./configure", "make" and "make install", whereas the 'icedove' package
uses the (Mozilla-preferred) approach of creating a ".mozconfig" file
and running "./mach configure", "./mach build" and "./mach install".

If I remember correctly (from when I looked at the process listings
provided in this bug report), "./mach build" seems to be passing a
"-j<N>" argument to "make", but at present we have no control over the
<N> is.

The best solution would be to find a way to tell "./mach build" to pass
a specific value of <N>.  Ideally, <N> should be (parallel-job-count) if
'parallel-build?' is #t, otherwise it should be 1.

What do you think?

     Thanks,
       Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.