bug#29512: build of git-2.15.0.drv failed

[Ludovic Courtès]

Hi George,

George myglc2 Clemmer  skribis:

> g1@g1 ~/src/guix$ guix package -M 4 -c 4 -m ../g1.scm
> [...]
> *** t9153-git-svn-rewrite-uuid.sh ***
> not ok 4 - create new branches and tags
> #
> # ( cd git_project &&
> # git svn branch -m "New branch 1" -d b_one New1 ) &&
> # ( cd svn_project &&
> # svn_cmd up && test -e b_one/New1/a.file ) &&
> #
> # ( cd git_project &&
> # git svn branch -m "New branch 2" -d b_two New2 ) &&
> # ( cd svn_project &&
> # svn_cmd up && test -e b_two/New2/a.file ) &&
> #
> # ( cd git_project &&
> # git svn branch -t -m "New tag 1" -d tags_A Tag1 ) &&
> # ( cd svn_project &&
> # svn_cmd up && test -e tags_A/Tag1/a.file ) &&
> #
> # ( cd git_project &&
> # git svn tag -m "New tag 2" -d tags_B Tag2 ) &&
> # ( cd svn_project &&
> # svn_cmd up && test -e tags_B/Tag2/a.file )
> #
> # failed 1 among 4 test(s)
> 1..4
> make[2]: *** [Makefile:49: t9141-git-svn-multiple-branches.sh] Error 1

[...]

> Hmm... I have discovered that that works when I don't use the
> multi-job/multi-core options, e.g., as previously reported, this fails
> ...
>
> g1@g1 ~/src/guix$ guix package -M 4 -c 4 -m ../g1.scm
>
> But this ...
>
> g1@g1 ~/src/guix$ guix package  -m ../g1.scm
>
> works.

To me that sounds like an issue when running tests in parallel.  Commit
c03ba83c17c91e34e811a909fae0f63aab701ff9 ensures test run sequentially,
which hopefully solves the problem.

Thanks,
Ludo’.

bug#25035: scribus: No module named _sysconfigdata_nd

[Ludovic Courtès]

Hi,

Just a note that this was fix a couple of weeks ago in commit
aa6ae8d3243ce80d6c427e243c4fa961c3bf8388.

Thanks,
Ludo’.

bug#24279: Bug in xterm and/or fontconfig

[Ludovic Courtès]

Hello,

Maxim Cournoyer  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>> We can also fix this once and for all with this patch:
>>
>> diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
>> index 0da3397da..8f285b29a 100644
>> --- a/gnu/services/xorg.scm
>> +++ b/gnu/services/xorg.scm
>> @@ -113,6 +113,8 @@
>>  (file-append font-alias "/share/fonts/X11/100dpi")
>>  (file-append font-alias "/share/fonts/X11/misc")
>>  (file-append font-alias "/share/fonts/X11/cyrillic")
>> +(file-append font-misc-misc   ;default fonts for xterm
>> + "/share/fonts/X11/misc")
>>  (file-append font-adobe75dpi "/share/fonts/X11/75dpi")))
>>  
>>  (define* (xorg-configuration-file #:key
>>
>>
>> That adds 4.1 MiB, but it saves user headaches, so I think it’s worth it.
>>
>> I’ll go ahead and push that if there are no objections.
>
> And another bug down! :) Thanks for fixing it; LGTM!

Awesome, I went ahead and pushed as
4afc903a8c1b9cb19c0341b5cd2ea80a34974f25.

Thanks everyone!

Ludo’.

bug#29516: Maxima fails to build

[Diego Nicola Barbato]

Hello Guix,

`guix build maxima' fails during the `check' phase with the following
output:

starting phase `check'
Making check in admin
make[1]: Entering directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/admin'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/admin'
Making check in crosscompile-windows
make[1]: Entering directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/crosscompile-windows'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/crosscompile-windows'
Making check in src
make[1]: Entering directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/src'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/src'
Making check in lisp-utils
make[1]: Entering directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/lisp-utils'
make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/lisp-utils'
Making check in tests
make[1]: Entering directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests'
make  check-TESTS
make[2]: Entering directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests'
make[3]: Entering directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests'
sed <"test.sh.in" >"gcl-test.sh"  \
  -e 
's#!LOCAL_MAXIMA!#/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/sh
 ../maxima-local#'   \
  -e 's#!LISPNAME!#gcl#' \
  -e 's#!OUTPUT_LOG!#../tests/gcl.log#'
chmod a+x "gcl-test.sh"
FAIL: gcl-test.sh
make[4]: Entering directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests'

Testsuite summary for maxima 5.41.0

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log

make[3]: *** [Makefile:558: test-suite.log] Error 1
make[3]: Leaving directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests'
make[2]: *** [Makefile:666: check-TESTS] Error 2
make[2]: Leaving directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests'
make[1]: *** [Makefile:792: check-am] Error 2
make[1]: Leaving directory 
'/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests'
make: *** [Makefile:457: check-recursive] Error 1
phase `check' failed after 261.2 seconds
builder for `/gnu/store/cmz95fkz1mc7nb3yxch4x83iaxml6gzs-maxima-5.41.0.drv' 
failed with exit code 1
@ build-failed /gnu/store/cmz95fkz1mc7nb3yxch4x83iaxml6gzs-maxima-5.41.0.drv - 
1 builder for `/gnu/store/cmz95fkz1mc7nb3yxch4x83iaxml6gzs-maxima-5.41.0.drv' 
failed with exit code 1
guix build: error: build failed: build of 
`/gnu/store/cmz95fkz1mc7nb3yxch4x83iaxml6gzs-maxima-5.41.0.drv' failed

I am running GuixSD on a x86_64 machine (commit:
9ce07f2dbafe068aea81e79decc4cfc146a48259).
The x86_64 version also failed to build on hydra.gnu.org
(https://hydra.gnu.org/build/2361466).

Greetings

Diego

bug#29512: build of git-2.15.0.drv failed

[myglc2]

On 12/01/2017 at 11:33 Ludovic Courtès writes:
...
>
> To me that sounds like an issue when running tests in parallel.  Commit
> c03ba83c17c91e34e811a909fae0f63aab701ff9 ensures test run sequentially,
> which hopefully solves the problem.

That fixed it here. Thanks. - George

bug#29519: ./pre-inst-env: substitute: Failed to autoload make-session in (gnutls)

[Adonay Felipe Nogueira]

I'm experimenting developing directly to the Git checkout instead of
using GUIX_PACKAGE_PATH to develop and test package definitions.

Currently this is what I do:

--8<---cut here---start->8---
# If the local clone is somewhat dirty, clear it.
git reset --hard HEAD
git clean -fdx
# Uptdate the local clone.
git pull
# Use my already-installed Guix to prepare environment to hack on Guix.
guix environment guix
# Follow the info pages.
./bootstrap
# I checked contents of "/var" and it is indeed the localstatedir
# because "guix" (and gc lock, temproots and so on) is there.
./configure --localstatedir="/var"
# Do I need to do `make'? Since I'm used to do it I'll do it anyways.
make
# Back to following the info pages.
make check
--8<---cut here---end--->8---

Now I keep the first terminal open, and in a second terminal, I also go
to the local copy and do `guix environment guix', and keep that terminal
for now.

In a third terminal I stop the system's guix-daemon service, with
something similar to `sudo service guix-daemon stop'.

Then I go back to the first terminal, and do `sudo ./pre-inst-env
guix-daemon --debug --build-users-group=guixbuild', and that terminal is
now busy logging the daemon's activity.

In the second terminal I do `./pre-inst-env guix build --verbosity=4
hello' and I get this:

--8<---cut here---start->8---
acquiring global GC lock `/var/guix/gc.lock'
acquiring read lock on `/var/guix/temproots/26301'
acquiring write lock on `/var/guix/temproots/26301'
downgrading to read lock on `/var/guix/temproots/26301'
[... Repetitions of the same last two messages...]
starting substituter program 
`/home/adfeno/Projetos/Software/guix/nix/scripts/substitute'
substitute: guile: warning: failed to install locale
substitute: warning: failed to install locale: Invalid argument
substitute: guix substitute: warning: ACL for archive imports seems to be 
uninitialized, substitutes may be unavailable
substitute: ;;; Failed to autoload make-session in (gnutls):
substitute: ;;; ERROR: missing interface for module (gnutls)
substitute: Backtrace:
substitute:1 (primitive-load 
"/home/adfeno/Projetos/Software/guix/sc?")
substitute: In guix/ui.scm:
substitute:   1452:12  0 (run-guix-command _ . _)
substitute:
substitute: guix/ui.scm:1452:12: In procedure run-guix-command:
substitute: guix/ui.scm:1452:12: make-session: unbound variable
guix build: error: build failed: substituter `substitute' died unexpectedly
--8<---cut here---end--->8---

This also happens if I *don't* stop the already installed Guix daemon,
with the difference that in this case after stopping the ./pre-inst-env
guix-daemon, any further attempts to use the installed Guix daemon ---
even if no longer in the environment and even in a new terminal --- will
be denied, forcing me to restart this one.

In both cases (./pre-inst-env guix-daemon with installed guix-daemon
running or not), the ./pre-inst-env guix-daemon shows this:

--8<---cut here---start->8---
extra chroot directories: ''
automatic deduplication set to 1
listening on `/var/guix/daemon-socket/socket'
accepted connection from pid 26186, user adfeno
443 operations
--8<---cut here---end--->8---

I hope this helps finding out what the problem is.


Respectfully, Adonay.

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

bug#29522: rustc-1.16.0 broken after jemalloc updated to 5.0.1

[Adam Van Ymeren]

I haven't had time to dig in to this further, but in case anyone wants
to fix rustc-1.16.0, it's broken after the upgrade of jemalloc to 5.0.1.

Reverting commit 475b99fa5cf402430aa93a40e406e854ad2ff6e4 which reverts
jemalloc back to 4.5.0 causes rustc to build successfully again.  It has
been broken for some time.

https://hydra.gnu.org/job/gnu/master/rustc-1.16.0.x86_64-linux

bug#27943: tar complains about too-long names (guix release)

[Ludovic Courtès]

Leo Famulari  skribis:

>> On Thu, Nov 30, 2017 at 02:55:52PM +0100, Ludovic Courtès wrote:
>> > I thought about it, but since it’s an unsual case, what about adding a
>> > special property to packages instead?  You’d write:
>> > 
>> >   (package
>> > ;; …
>> > (properties '((fixed-vulnerabilities "CVE-123-4567" "CVE-123-4568"
>> > 
>> > ‘guix lint’ would honor this property, and that would address both cases
>> > like this and situations where a CVE is known to no longer apply, as is
>> > the case with unversioned CVEs¹.
>> > 
>> > Thoughts?
>
> I'd rather the property's name more clearly reflect that it doesn't
> actually fix the vulnerability, but just prevents the linter from
> complaining about it.
>
> Someone who sees this property used in a package could reasonably assume
> that it's required to list all fixed CVEs in a 'fixed-vulnerabilities'
> list, and that it is the "single source of truth" for which bugs apply
> to a package. But, it would not actually have anything to do with that,
> just being a way to silence the linter.

Yes, I see it as a last resort, and thus rarely used.  When used, it
should be accompanied by a comment clearly explaining what we’re doing.

I think people are unlikely to see it as a “single source of truth”
because it’ll be used in a handful of packages only, and because
comments there should make it clear that it’s really just to placate the
linter.

> However, I can't think of a good idea for another name...

Maybe ‘lint-hidden-vulnerabilities’ or ‘hidden-vulnerabilities’, or
‘ignored-vulnerabilities’, or…?  What’s you preference?  :-)

> On Thu, Nov 30, 2017 at 11:49:01PM +0200, Efraim Flashner wrote:
>> I like that idea. It also allows us to mitigate a CVE without needing to
>> specifically add a patch. I've attached my first attempt at implementing
>> it.
>
> I think of `guix lint -c cve` as one of many tools for discovering
> important problems in our packages, but I don't think that we must
> absolutely silence the linter. It's always going to be imprecise, with
> both false negative and positive results.

I agree.  Like patch file names, I view this new property as a way to
silence the reader when we have reliable info to do that.

Would you be OK with a more appropriate name and the understanding that
it’s there to address rare cases like this one?

Thanks for your feedback!

Ludo’.

bug#29516: Maxima fails to build

[Leo Famulari]

On Fri, Dec 01, 2017 at 11:53:01AM +0100, Diego Nicola Barbato wrote:
> `guix build maxima' fails during the `check' phase with the following
> output:

Thanks for your report!

> Testsuite summary for maxima 5.41.0
> 
> # TOTAL: 1
> # PASS:  0
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See tests/test-suite.log
> 

Can you retry the build with '--keep-failed' and send the
'tests/test-suite.log' file that will be in the directory of the failed
build?

And if that log's messages about the failing test refer to another log
file, please send that one too.


signature.asc
Description: PGP signature

bug#27943: tar complains about too-long names (guix release)

[Leo Famulari]

On Fri, Dec 01, 2017 at 05:50:01PM +0100, Ludovic Courtès wrote:
> Maybe ‘lint-hidden-vulnerabilities’ or ‘hidden-vulnerabilities’, or
> ‘ignored-vulnerabilities’, or…?  What’s you preference?  :-)

I like 'lint-hidden-vulnerabilities' because it communicates that we are
"hiding" a vulnerability somehow and that it's related to the linter.

Maybe even 'lint-hidden-cve', since it's really about the CVE system and
not so much about vulnerabilities as vulnerabilities.

> Would you be OK with a more appropriate name and the understanding that
> it’s there to address rare cases like this one?

Yes, definitely!


signature.asc
Description: PGP signature

bug#29516: Maxima fails to build

[Diego Nicola Barbato]

Leo Famulari  writes:

> On Fri, Dec 01, 2017 at 11:53:01AM +0100, Diego Nicola Barbato wrote:
>> `guix build maxima' fails during the `check' phase with the following
>> output:
>
> Thanks for your report!
>
>> Testsuite summary for maxima 5.41.0
>> 
>> # TOTAL: 1
>> # PASS:  0
>> # SKIP:  0
>> # XFAIL: 0
>> # FAIL:  1
>> # XPASS: 0
>> # ERROR: 0
>> 
>> See tests/test-suite.log
>> 
>
> Can you retry the build with '--keep-failed' and send the
> 'tests/test-suite.log' file that will be in the directory of the failed
> build?

As requested I ran `build' with `--keep-failed'.  This is the resulting
log file:

=
   maxima 5.41.0: tests/test-suite.log
=

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: gcl-test.sh
=

Maxima 5.41.0 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) run_testsuite()
Running tests in rtest_rules: 103/103 tests passed
Running tests in rtestnset: 601/601 tests passed
Running tests in rtest1: 186/186 tests passed (not counting 3 expected errors)
Running tests in rtest1a: 34/34 tests passed (not counting 1 expected errors)
Running tests in rtest2: 268/268 tests passed (not counting 2 expected errors)
Running tests in rtest4: 93/93 tests passed
Running tests in rtest5: 83/83 tests passed
Running tests in rtest6: 39/39 tests passed
Running tests in rtest6a: 62/62 tests passed
Running tests in rtest6b: 27/27 tests passed
Running tests in rtest7: 85/85 tests passed
Running tests in rtest9: 89/89 tests passed
Running tests in rtest9a: 76/76 tests passed
Running tests in rtest10: 62/62 tests passed (not counting 2 expected errors)
Running tests in rtest11: 243/243 tests passed (not counting 3 expected errors)
Running tests in rtest13: 23/23 tests passed
Running tests in rtest13s: 17/17 tests passed
Running tests in rtest14: 418/418 tests passed
Running tests in rtest15: 
** Problem 55 ***
Input:
compile(f)


Result:
warning: encountered undefined variable qwerty in translation.
Compiling /tmp/gazonk_4051_0.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=2, Space=3, Speed=3
Finished compiling /tmp/gazonk_4051_0.o.
error-catch

This differed from the expected result:
[f]

** Problem 61 ***
Input:
compile(f)


Result:
Compiling /tmp/gazonk_4051_1.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=2, Space=3, Speed=3
Finished compiling /tmp/gazonk_4051_1.o.
error-catch

This differed from the expected result:
[f]

** Problem 67 ***
Input:
compile(f)


Result:
Compiling /tmp/gazonk_4051_2.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=2, Space=3, Speed=3
Finished compiling /tmp/gazonk_4051_2.o.
error-catch

This differed from the expected result:
[f]

** Problem 73 ***
Input:
compile(f)


Result:
warning: encountered undefined variable qwerty in translation.
Compiling /tmp/gazonk_4051_3.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=2, Space=3, Speed=3
Finished compiling /tmp/gazonk_4051_3.o.
error-catch

This differed from the expected result:
[f]

** Problem 79 ***
Input:
compile(f)


Result:
warning: encountered undefined variable qwerty in translation.
Compiling /tmp/gazonk_4051_4.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=2, Space=3, Speed=3
Finished compiling /tmp/gazonk_4051_4.o.
error-catch

This differed from the expected result:
[f]

** Problem 85 ***
Input:
compile(f)


Result:
Compiling /tmp/gazonk_4051_5.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=2, Space=3, Speed=3
Finished compiling /tmp/gazonk_4051_5.o.
error-catch

This differed from the expected result:
[f]

** Problem 91 ***
Input:
compile(f)


Result:
Compiling /tmp/gazonk_4051_6.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=2, Space=3, Speed=3
Finished compiling /tmp/gazonk_4051_6.o.
error-catch

This differed from the expected result:
[f]

** Problem 164 ***
Input:
compile(aref)


Result:
Compiling /tmp/gazonk_4051_7.lsp.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=2, Space=3, Speed=3
Finished compiling /tmp/gazonk_4051_7.o.
error-catch

This differed from the expected result:
[aref]

** Problem 173 ***
Input:
compile(foo)


Result:
Compilin

bug#29492: tests/guix-system.sh failure on unbound variable check

[Eric Bavier]

> -Original Message-
> From: Ludovic Courtès [mailto:l...@gnu.org]
> Sent: Thursday, November 30, 2017 4:04 AM
> To: Eric Bavier
> Cc: 29...@debbugs.gnu.org
> Subject: Re: bug#29492: tests/guix-system.sh failure on unbound variable
> check
> 
> Hi Eric,
> 
> Eric Bavier  skribis:
> 
> > Latest guix master (2cdf78df2d3d5d88c7e6908754233cf37cce1e61) fails
> tests/guix-system.sh for me, on line 128.  This seems to be caused by the
> fact that the error output contains a multi-character column number:
> >
> > ```
> > /tmp/bavier/tmpfile:9:14: In procedure #:
> > /tmp/bavier/tmpfile:9:14: GRUB-config: unbound variable
> > hint: Did you forget a `use-modules' form?
> 
> I suppose that’s with Guile 2.0, right?

Right, 2.0.14.

> So the patch would become:

diff --git a/tests/guix-system.sh b/tests/guix-system.sh
index 4bb866adf..eaa0c4332 100644
--- a/tests/guix-system.sh
+++ b/tests/guix-system.sh
@@ -125,7 +125,8 @@ else
# See .
grep "$tmpfile:[49]:[0-9]: GRUB-config.*[Uu]nbound variable" 
"$errorfile"
 else
-   grep "$tmpfile:9:[0-9]: GRUB-config.*[Uu]nbound variable" "$errorfile"
+   # With Guile 2.0.14 the error is reported on line 14 (the last line).
+   grep "$tmpfile:9:[0-9]\+: GRUB-config.*[Uu]nbound variable" "$errorfile"
 fi
 fi

No, at *column* 14.  Which I believe is the desired result, right?  Character 
14 is the '(', the 'GRUB-config symbol itself starts at character 15.   But now 
I wonder whether we should be using a regex for that anyhow.  Do we expect the 
column number to change ever?

I think it would be fine to fix the regex for Guile 2.0 only, but once the bug 
affecting 2.2 is fixed, it'll need to be applied there too.  Maybe it would 
make sense to fix both at the same time.

WDYT?

`~Eric