;ve attached an updated patch, as well as a follow-up patch for the
> texmaker package.
Thanks!
Kind regards,
Roel Janssen
Theodoros Foradis writes:
> Roel Janssen writes:
>
>> Theodoros Foradis writes:
>>
>>> Roel Janssen writes:
>>>
>>> [...]
>>>
>>> Let me know if I need to post an updated patch.
>>
>> Please do. Have all comments been
ch:
>From a9b5305f8af51b88643986f99a8e94cad4d7a805 Mon Sep 17 00:00:00 2001
From: Roel Janssen
Date: Thu, 17 Nov 2016 09:46:15 +0100
Subject: [PATCH] guix: Add whitespacing to --list-generations output.
---
guix/ui.scm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/guix/ui.scm b/guix/ui.scm
index b9f
erences" graph type would only
include run-time
references, but I don't know what happens in this case.
What am I missing?
Thank you for your time.
Kind regards,
Roel Janssen
On Sun, 2022-07-24 at 23:01 +0200, Maxime Devos wrote:
>
> On 24-07-2022 22:25, Roel Janssen wrote:
> > I'm trying to understand the output of:
> > $ guix graph --type=references python-rdflib | dot -Tsvg -o rdflib.svg
> >
> > Particularly, I'm looking
low 1.15.2 still have the CMake build system files in place.
What has changed since 1.9.0 that makes the CMake build system no option
anymore?
Kind regards,
Roel Janssen
store/z9f8pcng2gsp7g9f93jd40c7g53wyc4s-tensorflow-
> 1.15.0.drv' failed with exit code 1
> build of /gnu/store/z9f8pcng2gsp7g9f93jd40c7g53wyc4s-tensorflow-1.15.0.drv
> failed
> View build log at '/var/log/guix/drvs/z9/f8pcng2gsp7g9f93jd40c7g53wyc4s-
> tensorflow-1.15.0.drv.bz2'.
> guix build: error: build of `/gnu/store/z9f8pcng2gsp7g9f93jd40c7g53wyc4s-
> tensorflow-1.15.0.drv' failed
> --8<---cut here---end--->8---
>
Alright! I've sent patches for abseil-cpp to the mailing list, but I haven't
been able to get the googletest test suite to work. Have you figured that out?
Perhaps we can share the work on Tensorflow 1.15.2. Would you mind sharing the
patch you've got so far?
Kind regards,
Roel Janssen
On Wed, 2020-03-04 at 16:10 +0100, Pierre Neidhardt wrote:
> Roel Janssen writes:
>
> > Alright! I've sent patches for abseil-cpp to the mailing list, but I
> > haven't
> > been able to get the googletest test suite to work. Have you figured that
> > ou
moved twice since printing and securely storing the revocation key,
this will take some time.
Is there perhaps a key-signing party for GNU Guix maintainers to build
a better trust in the future?
Kind regards,
Roel Janssen
On Thu, 2020-03-05 at 18:13 +0100, Ludovic Courtès wrote:
> Hello R
hould I attempt
to implement?
If there is interest in having this as a "load-profile" subcommand, I will post
an initial implementation to the mailing list ASAP.
Thanks all!
Kind regards,
Roel Janssen
[1]
https://github.com/UMCUGenetics/guix-additions/blob/master/umcu/packages/guix.scm#L191-L339
rther step should maybe combine "--load-profile" and
> "--ad-hoc" in order to create a temporary "augmented" profile.
I would strongly prefer to keep it backwards-compatible for our local HPC users.
Also, the "environment" command generates a new profile, whereas the proposed
"load-profile" merely applies the environment variables of an existing profile
to a newly spawned shell. I think the way they work differs enough to warrant a
separate subcommand.
Kind regards,
Roel Janssen
On Wed, 2020-04-29 at 15:48 +0200, zimoun wrote:
> Dear Roel,
>
> On Wed, 29 Apr 2020 at 14:46, Roel Janssen wrote:
>
> > > > If there is interest in having this as a "load-profile" subcommand, I
> > > > will
> > > > post
mmit(s) were added to refs/heads/master by this
> > push:
> > new 1f56ec0 gnu: Add r-loomr.
> > 1f56ec0 is described below
> >
> > commit 1f56ec08af704bdc7aa3e143bf5ce351c5306dea
> > Author: Roel Janssen
> > AuthorDate: Wed Sep 9 16:56:02 2020 +0200
mmit(s) were added to refs/heads/master by this
> > push:
> > new 0574446 gnu: Add r-bisquerna.
> > 0574446 is described below
> >
> > commit 0574446be82ef54b925441e4283bf754a86918a9
> > Author: Roel Janssen
> > AuthorDate: Wed Sep 9 17
On Thu, 2020-09-10 at 13:31 +0200, Ricardo Wurmus wrote:
> Roel Janssen writes:
>
> > > > +(define-public r-bisquerna
> > > > + (package
> > > > + (name "r-bisquerna")
> > > > + (version "1.0.4")
> > > >
dded to refs/heads/master by this
> > push:
> > new a9401b4 gnu: Add r-useful.
> > a9401b4 is described below
> >
> > commit a9401b4c948552d6a5a95bbd295e61871f4c6d74
> > Author: Roel Janssen
> > AuthorDate: Wed Sep 9 16:59:42 2020 +0200
> >
&g
aps my
opinion doesn't matter much in this, but I'd prefer #t and #f because
it's already widespread use in Scheme. (And with widespread I mean:
Pretty much all Scheme code I read).
I do remember being confused about the double parenthesis on "let" ;).
Kind regards,
Roel Janssen
"
> 8: Setting LC_MONETARY failed, using "C"
> 9: Setting LC_PAPER failed, using "C"
> 10: Setting LC_MEASUREMENT failed, using "C"
> >
> --8<---cut here---end--->8---
>
>
> The cluster machine is an old kernel:
>
> --8<---cut here---start->8---
> HEAD$ uname -a
> Linux HEAD 2.6.32-573.8.1.el6.x86_64 #1 SMP Tue Nov 10 18:01:38 UTC
> 2015 x86_64 x86_64 x86_64 GNU/Linux
> --8<---cut here---end--->8---
>
>
> What do I miss?
Perhaps completely misguided, but is this inside an SGE or SLURM job?
I've seen similar errors when starting R on a cluster node with too
little memory allocated to the compute job. In my experience you need
at least 2G of memory available.
Kind regards,
Roel Janssen
Dear Guix,
Is anyone working on updating Bioconductor to the latest (3.12)
release? If so, what's the status? :)
Kind regards,
Roel Janssen
Hi Simon,
On Mon, 2020-11-16 at 12:27 +0100, zimoun wrote:
> Hi Roel,
>
> On Mon, 16 Nov 2020 at 11:49, Roel Janssen wrote:
>
> > Is anyone working on updating Bioconductor to the latest (3.12)
> > release? If so, what's the status? :)
>
> Some work is alre
Hi Simon,
On Mon, 2020-11-16 at 13:29 +0100, zimoun wrote:
> Hi Roel,
>
> On Mon, 16 Nov 2020 at 13:10, Roel Janssen wrote:
>
> > Hehe. I'm building all R packages in the "wip-r" branch now to see
> > what's left for me to fix.
>
> Cool! I
re we can
consider merging to master.
Kind regards,
Roel Janssen
Hi Simon,
On Wed, 2020-11-18 at 12:50 +0100, zimoun wrote:
> Hi Roel,
>
> On Wed, 18 Nov 2020 at 10:31, Roel Janssen wrote:
>
> > I fixed the build issue with r-delayedarray and a couple of others
> > on
> > my local machine. I also updated the bioconductor ve
On Wed, 2020-11-18 at 17:23 +0100, zimoun wrote:
> Hi Roel,
>
> On Wed, 18 Nov 2020 at 17:13, Roel Janssen wrote:
>
> > I pushed updates and fixes for various packages. Now I'm at r-
> > rhdf5lib.
>
> Cool!
>
>
> > In 38881c9368595c5a894abe
On Wed, 2020-11-18 at 17:59 +0100, zimoun wrote:
> On Wed, 18 Nov 2020 at 17:33, Roel Janssen wrote:
>
> > Okay. Then I'll look into it. I currently have only these left as
> > changed in my tree:
> > - r-atacseqqc: Needs r-rhdf5lib.
> > - r-cytoml: Needs
On Thu, 2020-11-19 at 16:36 +0100, zimoun wrote:
> Hi,
>
> On Thu, 19 Nov 2020 at 16:31, Roel Janssen wrote:
>
> > I fixed the build of r-rhfd5lib.
>
> Cool!
>
> > It seems, however, that you removed all of my changes to the wip-r
> > branch. Why?
>
On Thu, 2020-11-19 at 17:18 +0100, zimoun wrote:
> On Thu, 19 Nov 2020 at 16:57, Roel Janssen wrote:
>
> > My bad, I jumped to a conclusion too quickly. :)
>
> No worries. :-)
>
>
> > So, *something* removed my commits to the wip-r branch. Is it some
> > k
Hi Simon,
On Thu, 2020-11-19 at 18:27 +0100, zimoun wrote:
> Hi Roel,
>
> Quick heads up of Ricardo from IRC.
>
> On Thu, 19 Nov 2020 at 17:25, Roel Janssen wrote:
>
> > Well, they got removed from Savannah. Now I get this when I try to
> > push:
>
> http
yance of
> > possible broken packages, I mean we could detect them.
>
> Same. I prefer having a branch so ci.guix.gnu.org can build things and
> we can keep an eye on the fall-out (if any).
On IRC you noted that the commit messages are wrong. I interpret that as "my
commit mes
-version (“import: cran: Update the
> Bioconductor version to 3.12.”) should also change “bioconductor-uri” in
> (guix build-system r). This is still at 3.11.
>
Can/may I rewrite the history of my own commits to fix these?
Kind regards,
Roel Janssen
dpkg
> guix environment --ad-hoc dpkg -- dpkg -i ./guix_1.2.0-3_amd64.deb
>
> It is almost like symmetry!
>
This is really awesome. I'm also grateful for fixing the guile-gnutls
packaging in Debian. Thank you!
Kind regards,
Roel Janssen
h a feature. And to point out
what else would be needed to include this option in guix-daemon.
Thank you for your time.
Kind regards,
Roel Janssen
>From d842f320f0ee911d7d219bba7baa45240edcbe6d Mon Sep 17 00:00:00 2001
From: Roel Janssen
Date: Tue, 3 Apr 2018 11:22:16 +0200
Subject: [PATCH]
s folders.
Kind regards,
Roel Janssen
Ludovic Courtès writes:
> Hi Roel,
>
> r...@gnu.org (Roel Janssen) skribis:
>
>> +(license (package-license perl
>
> Could you use (license perl-license) instead? It doesn’t make any
> difference in this case but it’s generally “safer” (see (guix
> license
Roel Janssen writes:
> Ludovic Courtès writes:
>
>> Hi Roel,
>>
>> r...@gnu.org (Roel Janssen) skribis:
>>
>>> +(license (package-license perl
>>
>> Could you use (license perl-license) instead? It doesn’t make any
>> diff
Ludovic Courtès writes:
> Hello Roel,
>
> Roel Janssen skribis:
>
>> The patch adds a “disableGarbageCollection” boolean variable to the
>> guix-daemon settings, and on each occasion where a store item may be
>> deleted, it checks this option.
>>
>>
Roel Janssen writes:
> Ludovic Courtès writes:
>
>> Hello Roel,
>>
>> Roel Janssen skribis:
>>
>>> The patch adds a “disableGarbageCollection” boolean variable to the
>>> guix-daemon settings, and on each occasion where a store item may be
k the introduction and the
> discussion/conclusion may be of general interest.
This looks really great! I also like how you leverage GNU Autotools.
Finally there is a paper that uses GNU Guix as deployment tool for
scientific purposes. :)
Kind regards,
Roel Janssen
Hello there,
I'm not sure this made it to the mailing list. Is the proposed patch
fine to disable the GC for remote connections?
Thanks!
Kind regards,
Roel Janssen
Roel Janssen writes:
> Roel Janssen writes:
>
>> Ludovic Courtès writes:
>>
>>> Hello Roe
Ludovic Courtès writes:
> Hello Roel,
>
> Roel Janssen skribis:
>
[...]
>
>> From 00f489d6303720c65571fdf0bc9ee810a20f70e0 Mon Sep 17 00:00:00 2001
>> From: Roel Janssen
>> Date: Wed, 11 Apr 2018 09:52:11 +0200
>> Subject: [PATCH] guix-daemon: Disa
Mark H Weaver writes:
> Hi Roel,
>
> r...@gnu.org (Roel Janssen) writes:
>
>> roelj pushed a commit to branch master
>> in repository guix.
>>
>> commit 5e3010a2ac651397e0cb69239a7d7aa3c0a5703e
>> Author: Roel Janssen
>> Date: Wed Apr 18 2
Ludovic Courtès writes:
> Roel Janssen skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>>> diff --git a/nix/nix-daemon/nix-daemon.cc b/nix/nix-daemon/nix-daemon.cc
>>>> index deb7003d7..65770ba95 100644
>>>> --- a/nix/nix-dae
Ludovic Courtès writes:
> Heya,
>
> Roel Janssen skribis:
>
>> From fcbe7ebb3d205cf7310700e62b78b9aafd94f76f Mon Sep 17 00:00:00 2001
>> From: Roel Janssen
>> Date: Thu, 19 Apr 2018 17:11:30 +0200
>> Subject: [PATCH] guix-daemon: Disable garbage c
Dear Guix,
What's the decision process for updating the ‘guix’ package revision,
like in commit b1fb247b?
The reason I ask this is because I'd like to bump the revision so that
the changes from 5cefb13d to ‘guix-daemon’ are available when I install
‘guix’ in a profile.
Kind reg
core-updates, but hopefully it would work
> on 'master' too.
Thanks a lot for working on this! I applied your patch to ‘master’ and
built VLC. It is missing the icons.
Then I manually built it inside a ‘guix environment vlc’.
Launching it shows the icons. Leaving the environment and running the
same executable misses the icons.
Could it be that we need to propagate an input?
I'll try to dissect it further.
Kind regards,
Roel Janssen
Roel Janssen writes:
> Mark H Weaver writes:
>
>> Hello Guix,
>>
>> Below I've attached a draft patch to update vlc to 3.0.1, and also to
>> add several more inputs based on reading the output of the 'configure'
>> script.
>>
>>
Roel Janssen writes:
> Roel Janssen writes:
>
>> Mark H Weaver writes:
>>
>>> Hello Guix,
>>>
>>> Below I've attached a draft patch to update vlc to 3.0.1, and also to
>>> add several more inputs based on reading the output of the
Ludovic Courtès writes:
> Hello,
>
> Roel Janssen skribis:
>
>> What's the decision process for updating the ‘guix’ package revision,
>> like in commit b1fb247b?
>
> There’s no real process, just do it when there’s a good reason to do it.
>
>> The r
4h-guile-ssh-0.11.2/bin/ssshd.scm
sssh.scm ->
/gnu/store/g2k7v2wv9w2ybs1glwh42w55jq25zd4h-guile-ssh-0.11.2/bin/sssh.scm
I suspect that the Scheme files don't belong in ‘bin’. What about the
others? Can we do better here than propagate ‘gnutls’ and ‘nettle’?
Kind regards,
Roel Janssen
Roel Janssen writes:
> Dear Guix,
>
> When installing ‘guix’ in a profile, the ‘bin’ directory of that profile
> contains:
>
> asn1Coding ->
> /gnu/store/2fg01r58vv9w41kw6drl1wnvqg7rkv9d-libtasn1-4.12/bin/asn1Coding
> asn1Decoding ->
> /gnu/store/2fg01r58vv9w4
Ludovic Courtès writes:
> Roel Janssen skribis:
>
>> Ludovic Courtès writes:
>>
>>> Hello,
>>>
>>> Roel Janssen skribis:
>>>
>>>> What's the decision process for updating the ‘guix’ package revision,
>>>>
Ludovic Courtès writes:
> Roel Janssen skribis:
>
>> From 9455c7b94e0010ff4038132affc7a5c796313894 Mon Sep 17 00:00:00 2001
>> From: Roel Janssen
>> Date: Tue, 24 Apr 2018 12:48:32 +0200
>> Subject: [PATCH] gnu: guile-ssh: Move files from bin to examples d
7;, do some basic testing on it, and then push it on my behalf if
> it works.
I've had the VLC 3.0.1 commit applied on the master branch and VLC works
fine. I only use ‘vlc’, and not ‘cvlc’. We may have to wrap ‘cvlc’ as
well. But we can do that at a later time if someone finds a problem.
Kind regards,
Roel Janssen
ix audio/video. What software could we use ?
>> I don't know.
>
> You may want to try simplescreenrecorder. I tried it before, it is
> reasonably easy to use.
Or, if you're using GNOME: Ctrl + Alt + Shift + R. A small red dot will
appear in the upper right corner. Press the key combination again to
stop the recording, and a webm video will appear in your ‘Videos’
folder.
Kind regards,
Roel Janssen
e this, or a similar solution so that creating
profiles in custom locations is a little more robust.
Kind regards,
Roel Janssen
>From 95178018beb8c5458c154771ac9d1ff4866cc507 Mon Sep 17 00:00:00 2001
From: Roel Janssen
Date: Tue, 3 Jul 2018 19:49:04 +0200
Subject: [PATCH] profiles: Let cano
Ludovic Courtès writes:
> Hi Roel,
>
> Roel Janssen skribis:
>
>> I'd like to change the way the symlinks to custom profiles are created.
>> Here's what currently happens:
>>
>> $ guixr package -i hello -p guix-profiles/test
>> $ ls -l guix-
ore points. We cannot have
both. The former can already be achieved with the shell pipe, and the
latter can be achieved by writing two processes.
Maybe we can come up with a convenient way to combine two processes
using a shell pipe. But this needs more thought!
If you have an idea to improve on this, please do share. :-)
> Thank you for all the work about the Guix ecosystem.
>
> All the best,
> simon
Thanks!
Kind regards,
Roel Janssen
; process that outputs fileA
> process that outputs fileB
> process that inputs fileA *and* fileB
> without write on disk fileA and fileB.
Given the ‘dd’ example, I don't see how that could work without
reinventing the way filesystems work.
> All the best,
> simon
Thanks!
Kind regards,
Roel Janssen
Ricardo Wurmus writes:
> Roel Janssen writes:
>
>> From 98ed1adae91aca2c118779f5333dc21446f1c720 Mon Sep 17 00:00:00 2001
>> From: Roel Janssen
>> Date: Tue, 26 Apr 2016 19:48:31 +0200
>> Subject: [PATCH] gnu: Add intervaltree.
>>
>> * gnu/packa
>From 8383c24c8a3c723535fe59f700a5fd18c50b4780 Mon Sep 17 00:00:00 2001
From: Roel Janssen
Date: Fri, 10 Feb 2017 12:23:22 +0100
Subject: [PATCH] gnu: icedtea-8: Build keystore without id-ecPublicKey
certificates.
* gnu/packages/java.scm (icedtea-8): Add 'install-keystore phase.
Carlo Zancanaro writes:
> On Fri, Feb 10 2017, Roel Janssen wrote
>> [ ... ]
>
> I was getting frustrated at not having certificates with java 8 (it's
> surprisingly annoying to have to use one environment with java 7 to
> download dependencies with maven, then a diffe
Carlo Zancanaro writes:
> On Sun, Feb 26 2017, Roel Janssen wrote
>> Great idea. This is also a more durable solution for when certificates
>> change in nss-certs.
>
> Yeah, that was my thinking. I had tried to do it earlier, but hadn't
> noticed the incorrect perm
Ricardo Wurmus writes:
> Carlo Zancanaro writes:
>
>> On Mon, Feb 27 2017, Roel Janssen wrote
>>> Unfortunately, I don't seem to be able to apply your patch. [ ... ]
>>
>> Hmm. That's strange. I generated a new patch which hopefully will work.
>>
Dear Guix,
To write a derivation builder that can turn a G-expression into a
derivation, it would be handy to expose two functions that are currently
not in the interface of (guix gexp).
Here's an example:
(define* (process->bash-engine-derivation proc #:key (guile (default-guile)))
"Return an
>From de9f486828827b1d024cad4918eed3ed96202cc0 Mon Sep 17 00:00:00 2001
From: Roel Janssen
Date: Wed, 26 Apr 2017 10:30:52 +0200
Subject: [PATCH] import: Update Bioconductor release to 3.5.
* guix/import/cran.scm: Change Bioconductor release to 3.5.
---
guix/import/cran.scm | 4 ++--
1 f
Ricardo Wurmus writes:
> Roel Janssen writes:
>
>> From de9f486828827b1d024cad4918eed3ed96202cc0 Mon Sep 17 00:00:00 2001
>> From: Roel Janssen
>> Date: Wed, 26 Apr 2017 10:30:52 +0200
>> Subject: [PATCH] import: Update Bioconductor release to 3.5.
>&g
Ricardo Wurmus writes:
> Roel Janssen writes:
>
>>> I’d be happy if you could take care of the mass update. I should note
>>> that sometimes new inputs are required. To find them I usually run the
>>> update in a separate branch where I’ve applied changes to
quot; data directory so that a downgrade will still work with the
data in your database at the time before the upgrade.
Hope this helps..
Kind regards,
Roel Janssen
Christopher Allan Webber writes:
> Roel Janssen writes:
>
>> Jan Nieuwenhuizen writes:
>>
>>> Hi!
>>>
>>> I reconfigured my system and pulled in the postgres 9.6.2 update. Now
>>> postgres does not start, /var/log/messages has
>>&g
Jan Nieuwenhuizen writes:
> Roel Janssen writes:
>
>> So, it would be something like:
>> postgres pg_upgrade \
>> ...
>
> It's great to have a recipe `that works', so thanks!
>
> However, whether or not we automate this, I cannot help to wonder if
this package,
and for future packages? [y/N]
We need to find the proper wording for this message. Using this, we can
still let the user decide, but we can make it a lot easier for the user
to make a decision -- a 'yes' or 'no' answer to a question is easier
than a paragraph in the manual with instructions to enable it.
Kind regards,
Roel Janssen
ix
pull'. I think this feature is very important because it makes the
generations traceable to the Guix source code, which is needed for
reproducing the same generation.
Is this something we could make? And can we live with the implicit
requirement to have the git repository information available when
building the source tarballs used by 'guix pull'?
Kind regards,
Roel Janssen
lot of information on 'guix package
--list-generations', because we only display the difference between two
generations. I think it looks much better in practice than it did
before.
> So, I'm wary of sacrificing a flexible and powerful CLI on behalf of
> users who really will never use a CLI. Now, I'm not saying there is
> nothing to improve. Rather, I'm saying that the existing Guix CLI is
> pretty good, and we should be careful about changing it.
I don't think we are making the CLI less powerful by not showing the
build output in the 'guix package' command. When the build fails, you
can review the build log. And a failure is something you don't expect
when you are installing packages. That's something we use 'guix build'
for.
Kind regards,
Roel Janssen
proves the
situation. Adding external repositories is not something the upstream
distribution can take care of. Maybe if we would add a different, more
formal way of allowing external repositories, that could be dealt with
more easily. (Is this what 'channels' could do?)
Kind regards,
Roel Janssen
Dear Guix,
Here's a patch for kaiju. A C++ program without any dependencies, plus
some additional scripts that need perl.
Kind regards,
Roel Janssen
>From ed45f47f7514faf10710b41a7d5e9cdaa8217c70 Mon Sep 17 00:00:00 2001
From: Roel Janssen
Date: Thu, 1 Jun 2017 15:01:51 +0200
Subject
s up (at least for us ;)).
Kind regards,
Roel Janssen
Roel Janssen writes:
> Dear Guix,
>
> Here's a patch for kaiju. A C++ program without any dependencies, plus
> some additional scripts that need perl.
>
> Kind regards,
> Roel Janssen
This was supposed to go to guix-patches instead. Sorry for the noise.
Ludovic Courtès writes:
> Roel Janssen skribis:
>
>> Ludovic Courtès writes:
>>
>>> I agree that we could do a lot more things with a faster ‘guix
>>> environment’. My guess is that it won’t be easy to go optimize, and
>>> very hard to go below 1
Ludovic Courtès writes:
> Hi Roel,
>
> Roel Janssen skribis:
>
>> Ludovic Courtès writes:
>
> [...]
>
>>>> FWIW, on our NFS-mounted /gnu, the 'guix environment' command takes at
>>>> least 20 seconds, but for any reasonably big
would be something like
>
> guix build --shell-on-failure mypackage
>
> Should I open a bug-report for this?
I would find this really useful as I usually do the manual steps:
guix build -K
cd
bash
. environment_variables
cd
Which is suboptimal because then you're not the build user in an
isolated environment.
Kind regards,
Roel Janssen
--pure --no-substitutes --no-grafts -- true
real0m23.357s
user0m2.802s
sys 0m0.340s
I suspect that the difference between the two commands is that one only
looks for one module, while the other looks in all modules. Looking at
the second run, I suppose the difference is quite small.
Kind regards,
Roel Janssen
Ludovic Courtès writes:
> Hi Roel,
>
> Roel Janssen skribis:
>
>> You should know that we have 'submit' nodes that use the guixr wrapper
>> script to connect to the guix-daemon that runs on the 'hpcguix' node.
>>
>> Both have a /gnu
tils --pure
--no-substitutes -- true
real0m30.993s
user0m5.049s
sys 0m0.458s
Why is grafting so slow, even if it doesn't have to graft anything?
So, because grafting is disk-intensive rather than CPU-intensive, it might
be a good idea to be able to globally disable grafting. (it would
reduce the after-we-build-it-time considerably for our cluster.)
Kind regards,
Roel Janssen
Ludovic Courtès writes:
> Hi!
>
> Roel Janssen skribis:
>
>> I applied the patch, and here are the results:
>>
>> [roel@hpcguix guix]$ time guixr environment --ad-hoc coreutils --pure -- true
>> The following derivations will be built:
>>/
some
way. This patch is probably too broad in effect. Can I change it so
that only the graphics card I have will be affected by this patch?
Kind regards,
Roel Janssen
>From 25b431d23071b325b50c584977fcd6c1f9d790af Mon Sep 17 00:00:00 2001
From: Roel Janssen
Date: Wed, 21 Jun 2017 09:44
Ricardo Wurmus writes:
> Hi Roel,
>
>> With the following patch to the Xorg configuration file, I have a
>> tear-free GuixSD experience. I wonder if this is upstreameable in some
>> way. This patch is probably too broad in effect. Can I change it so
>> that only the graphics card I have will b
Mark H Weaver writes:
> Hi Roel,
>
> Roel Janssen writes:
>
>> Ricardo Wurmus writes:
>>
>>> Hi Roel,
>>>
>>>> With the following patch to the Xorg configuration file, I have a
>>>> tear-free GuixSD experience. I wonder if t
Chris Marusich writes:
> Roel Janssen writes:
>
>> Ricardo Wurmus writes:
>>
>>> Hi Roel,
>>>
>>>> With the following patch to the Xorg configuration file, I have a
>>>> tear-free GuixSD experience. I wonder if this is upstreameable i
it changes Xorg in order to fix a bug in Emacs. A proper fix
would be in Emacs.
Unless every other piece of software (GTK+, GNOME, Qt) have worked
around the bug somehow.. Then it might be a Xorg thing after all. But
this seems to be unlikely.
Kind regards,
Roel Janssen
t; "quiet" "rhgb"
"thinkpad_acpi.fan_control=1" "i195.modeset=1"))
I can say that this does not solve the problem in my case.
Kind regards,
Roel Janssen
0m8.679s
user0m1.199s
sys 0m0.202s
But FWIW, I think the time between no output and the "substitute: ..."
output is dramatically shorter.
I'll report back when I have a better testing environment ready.
Kind regards,
Roel Janssen
Ludovic Courtès writes:
> Hel
Ludovic Courtès writes:
> Hi Roel,
>
> Roel Janssen skribis:
>
>> substitute: guix substitute: warning: ACL for archive imports seems to be
>> uninitialized, substitutes may be unavailable
>> substitute: ;;; Failed to autoload make-session in (gnutls):
>
Chris Marusich writes:
> Roel Janssen writes:
>
>> Chris Marusich writes:
>>
>>> Roel Janssen writes:
>>>
>>>> Ricardo Wurmus writes:
>>>>
>>>>> Hi Roel,
>>>>>
>>>>>> With the follo
lot longer to run the same command
as before? (this is probably disk-related, because that is a known
cause for trouble on network-mounted stores..)
Thanks for your time!
Kind regards,
Roel Janssen
o slow? It doesn't have
to check for conflicts because that's already done on profile creation
time. All it has to do is combine the search-path data and output
that..
Anyway, I worked around it by using the $PROFILE/etc/profile file and
unset the environment variables before setting them, which takes less
than a second.
Kind regards,
Roel Janssen
Ludovic Courtès writes:
> Hi,
>
> Roel Janssen skribis:
>
>> Ricardo Wurmus writes:
>>
>>> Hi Roel,
>>>
>>>> Looking into the manifests ($GENERATION_15/manifest and
>>>> $GENERATION_16/manifest), I noticed that generation 15 use
/bugreport.cgi?bug=812096
Regardless of whether older versions of libraries would be accepted
upstream, you can also keep them in a separate repository or directory
and use the environment variable GUIX_PACKAGE_PATH to include them in
your Guix.
Kind regards,
Roel Janssen
Ludovic Courtès writes:
> Hello Roel,
>
> I’m finally going back to this issue…
>
> Roel Janssen skribis:
>
>> Ludovic Courtès writes:
>>
>>> Hi,
>>>
>>> Roel Janssen skribis:
>>>
>>>> Ricardo Wurmus writes:
>&g
"8.1.9"
"out"
"/gnu/store/jw80iilm964q2y0krnc1r67fxi07fix2-grid-engine-core-8.1.9"
(propagated-inputs ())
(search-paths
(("DRMAA_LIBRARY_PATH"
("lib/libdrmaa.so")
":"
directory
#f)))
Why isn't DRMAA_LIBRARY_PATH set in this case?
Kind regards,
Roel Janssen
Ludovic Courtès writes:
> Hi Roel,
>
> Roel Janssen skribis:
>
>> I have a question about how search paths are handled in Guix.
>> So, I have a package that tries to set an environment variable:
>> DRMAA_LIBRARY_PATH.
>>
>> So, I tried:
>>
101 - 200 of 427 matches
Mail list logo
