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

2017-11-30 Thread George myglc2 Clemmer
Running guix from clean make check on ... 6e385b76e (HEAD -> master, origin/master, origin/HEAD) gnu: mongodb: Use scons-build-system. ... guix package failed ... guix package: error: build failed: build of `/gnu/store/r3rijd3pmkfdmg3h4spyb24az3xiylc4-git-2.15.0.drv' failed Details: g1@g1

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

2017-11-30 Thread Ludovic Courtès
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: > > ``` >

bug#24279: Bug in xterm and/or fontconfig

2017-11-30 Thread Ludovic Courtès
Hi Oleg, Oleg Pykhalov skribis: > John Darrington writes: > >> In GuixSD: >> >> guix package -i xterm strace >> strace xterm >> >> xterm starts as it should, however observe many failed calls similar to: >> >>

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

2017-11-30 Thread Efraim Flashner
On Thu, Nov 30, 2017 at 02:55:52PM +0100, Ludovic Courtès wrote: > Hi Efraim, > > Efraim Flashner skribis: > > > It gets worse than that, our t1lib-CVE-2010-2462 is also CVE-2011-0433 > > and CVE-2011-5244.¹ > > > > I tried creating a blank patch (touch t1lib-CVE...) and

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

2017-11-30 Thread George myglc2 Clemmer
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. So maybe it's a git bug as opposed to

bug#29426: guix: "make check" test "utmpx-entries" fails

2017-11-30 Thread Adonay Felipe Nogueira
Thank you very much. It works nicely now. ;) 2017-11-25T18:14:36+0100 Ludovic Courtès wrote: > Hi, > > > This is the culprit: its ‘pid’ is 0, but its type is not BOOT_TIME as > the test expects. Instead, it’s DEAD_PROCESS (8). > > Fixed in commit 4aac8d059a2bec9f075ceea2a089ca029a71912c. > >

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

2017-11-30 Thread Leo Famulari
> 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"

bug#24279: Bug in xterm and/or fontconfig

2017-11-30 Thread Maxim Cournoyer
Hello, 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 @@ >

bug#29255: "Profile contains conflicting entries" could be more helpful

2017-11-30 Thread Ludovic Courtès
Hi, Ricardo Wurmus skribis: > In this case it is not entirely clear that the existing python-requests > package in the profile is “old”. The version looks the same and the > hash is opaque. > > Would it be possible to record something about the Guix version that was > used

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

2017-11-30 Thread Ludovic Courtès
Hi Efraim, Efraim Flashner skribis: > It gets worse than that, our t1lib-CVE-2010-2462 is also CVE-2011-0433 > and CVE-2011-5244.¹ > > I tried creating a blank patch (touch t1lib-CVE...) and adding that to > satisfy the linter (and bookeeping) but unsuprisingly patch

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

2017-11-30 Thread Efraim Flashner
On Tue, Nov 28, 2017 at 03:26:03PM +0100, Ludovic Courtès wrote: > Hi Danny, > > Danny Milosavljevic skribis: > > > guix $ make release > > ... || chmod -R a+r "guix-0.13.0.1849-cf189-dirty" > > tardir=guix-0.13.0.1849-cf189-dirty && ${TAR-tar} chof - "$tardir" | > >