[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#35350: Some compile output still leaks through with --verbosity=1

From: Mark H Weaver
Subject: bug#35350: Some compile output still leaks through with --verbosity=1
Date: Mon, 22 Apr 2019 19:52:28 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

Hi Ludovic,

Ludovic Courtès <address@hidden> writes:

> Mark H Weaver <address@hidden> skribis:
>> Sometimes when compiling a package with --verbosity=1, some parts of the
>> compile output leak through.  For example, see the transcript below.
> Weird.

FWIW, a few observations, possibly relevant:

(1) Each chunk of leaked output begins with 1 or 2 Unicode Replacement
    characters (U+FFFD).  In the transcript I provided, the first leak
    began with 1 replacement char, and all later leaks began with 2.

(2) The replacement characters are immediately followed by
    "@ build-log 30033 4096\n", and that string is also sprinkled
    throughout the leaked output, with approximately ~4060-4070
    characters of leaked output between each occurrence of
    "@ build-log 30033 4096\n".

> What’s the value of --max-jobs?

I'm not sure, how do I find out?  I don't specify it in my OS
configuration, and it's not on the command line of 'guix-daemon'.
Here's the relevant portion of my OS config:

       (modify-services %base-services
         (guix-service-type config =>
                              (inherit config)
                              (use-substitutes? #f)
                              (authorized-keys '())
                              (substitute-urls '())
                              (extra-options '("--gc-keep-derivations=yes"

I guess it's probably 2, because that's how many cores are in this
machine (Thinkpad X200), and 2 is also the number of GCC processes that
I typically see when building packages on this machine.

> Is offloading enabled?

No.  In addition to the above configuration, my /etc/guix/acl also
contains simply "(acl)".

> Presumably both the client and daemon are recent, right?

Yes, this machine is rarely more than a week out-of-date w.r.t. our
'master' branch.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]