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:
>>
>> open("/gnu/store/b484nvn9nnr3ddclpz2fma9yxmimg2jj-fontconfig-2.11.94/lib/libXdmcp.
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 procedur
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 to install a package?
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" |
> > GZIP=--best gzip -c >guix-0
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 didn't like
> trying to appl
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 ~/
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 adding that to
> > satis
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.
>
> Than
> 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
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
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 @@
>
11 matches
Mail list logo
