Hello all,
Am Sun, Apr 13, 2025 at 02:56:28PM +0200 schrieb Andreas Enge:
> I have rebased the r-team branch on master without any problems and
> pushed. So if you think r-team is ready now, please feel free to push
> it to master.
Ricardo has just pushed the branch to master, thanks t
Am Sat, Apr 12, 2025 at 03:01:43PM +0200 schrieb Ludovic Courtès:
> I believe ‘r-team’ is already being built:
> https://ci.guix.gnu.org/jobset/r-team
I must admit having trouble reading the result... In the "build changes"
column it mentions 2089 red builds. But when clicking o
Andreas Enge skribis:
> How about profiting from our duplicate build farms by building in
> parallel r-team on berlin/CI and qt-team and tex-team on bordeaux/QA?
I believe ‘r-team’ is already being built:
https://ci.guix.gnu.org/jobset/r-team
Ludo’.
Hello again,
I understand the frustration at our progress in branch merging being so
slow that systems like R, for instance, are already outdated when they
are finally merged.
Am Fri, Apr 11, 2025 at 05:27:05PM +0200 schrieb Andreas Enge:
> Well, there *is* flexibility. If the r-team branch
Hi Andreas,
On Fri, Apr 11 2025, Andreas Enge wrote:
> Well, why should r-team go before qt-team or tex-team?
> (I have no particular opinion and am fine with any decision on that
> matter, but one should search agreement by qt-team and tex-team
Some "one" has to do it.
Hey,
Greg Hogan skribis:
> I'd rather have some team make progress than no one, and the only way
> to dig ourselves out of this hole is to be more assertive as Ricardo
> has been here. Let everyone else follow his lead soon after.
Yes. I think it’s good that qa.guix.gnu.org and the correspondi
h person/group responsible for a branch can right away
> mark it as blocked by ‘r-team’ <https://issues.guix.gnu.org/76303>, and
> then ‘r-team’ will be at the top of the list and QA will pick it up.
>
> Did I get that right?
Yep, pretty much, but I think anyone can do this, the gu
Am Fri, Apr 11, 2025 at 05:22:57PM +0200 schrieb Ludovic Courtès:
> Oh, my bad; so each person/group responsible for a branch can right away
> mark it as blocked by ‘r-team’ <https://issues.guix.gnu.org/76303>, and
> then ‘r-team’ will be at the top of the list and QA will pick it
this is mentioned on [1], but this probably
> needs to be mentioned on the qa-frontpage as well.
>
> 1:
> https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html
Oh, my bad; so each person/group responsible for a branch can right away
mark it as blocked by ‘
Am Fri, Apr 11, 2025 at 04:55:27PM +0200 schrieb Ludovic Courtès:
> But we also need more flexibility, in particular the ability to say
> “this branch is ready so it should be merged now”.
Well, there *is* flexibility. If the r-team branch is ready and built
out on CI, say, you can merge
Ludovic Courtès writes:
> Greg Hogan skribis:
>
>> I'd rather have some team make progress than no one, and the only way
>> to dig ourselves out of this hole is to be more assertive as Ricardo
>> has been here. Let everyone else follow his lead soon after.
>
> Yes. I think it’s good that qa.gui
Am Fri, Apr 11, 2025 at 06:35:35AM -0700 schrieb Felix Lechner:
> Your branch should be merged now (and before you update R) after our new
> branch merge coordinator, Andreas Enge, signs off.
No, no, I have never signed on that role.
In particular, I am here only to push my own branches.
Hi Ricardo,
On Fri, Apr 11 2025, Ricardo Wurmus wrote:
> There has now been a new R release while the branch has been waiting
Upstream will always do as they please. To us, it's more important
what's in Guix.
Your branch should be merged now (and before you update R) after o
Hi Andreas,
On Tue, Apr 01 2025, Andreas Enge wrote:
> Probably we also need some human scheduler. In the past it has happened
> that branches have clogged the queue although for a week or two nobody
> was available to work on it. Having a person following the branches and
> interacting with the
Hello,
Am Tue, Apr 01, 2025 at 09:39:51AM -0400 schrieb Greg Hogan:
> QA shows no status ("Yet to process target revision") for python-team
> and core-packages-team (resurrected and now again the head of the
> queue).
I have just closed the core-packages-team issue, as it turns out that we
need t
Hi Guix,
the r-team branch has been ready for weeks. It has only
accumulated more changes (like the upgrade of R itself) as it has
been sitting in the queue. What do you think about letting this
branch jump the queue ahead of python-team?
--
Ricardo
Hi there,
after a few months offline I'm now back to work on Guix for a little
bit. I see that not much happened to our vast collection of R packages
in my absence, so here is my plan:
- apply all patches relating to R packages (done)
- upgrade to R 4.4.2 (released on Oct 31)
- upgrade all
Hi Marco,
Marco Fortina skribis:
> Yes, only changes in the environment.scm files are required for fixing the
> issue.
>
> Why did you make the patch so complex?
[...]
>> +(when (file-exists? gcc-path)
>> + (catch 'system-error
>> +(lambda ()
>> + (symlink gcc-path "
Hello!
Yes, only changes in the environment.scm files are required for fixing the
issue.
Why did you make the patch so complex?
> --- a/guix/scripts/environment.scm
> +++ b/guix/scripts/environment.scm
> @@ -464,8 +464,15 @@ (define (setup-fhs profile)
>;; /bin since that already has the sh
Marco Fortina writes:
> Is there any plan to add rustup to the package as well? This is useful for
> adding targets for cross-compilation.
>
I don't have plans to add that in my channel (I don't use it), but if
someone packages it and gets it to work, I'd be happy to take a PR.
I doubt it will
Is there any plan to add rustup to the package as well? This is useful for
adding targets for cross-compilation.
Cheers,
Marco
Da: guix-devel-bounces+marco_fortina=hotmail...@gnu.org
per conto di Brennan
Vincent
Inviato: lunedì 21 ottobre 2024 22:34
A: di...@s
Divya writes:
> I installed R packages using `guix install`, `guix shell` or by adding them
> to my home configuration, but in none of those ways can I get
> my R system (which is also installed through guix using system configuration)
> can recognize those packages.
>
> W
On Mon, Sep 16, 2024 at 02:02:30PM +, Divya wrote:
> I installed R packages using `guix install`, `guix shell` or by adding them
> to my home configuration, but in none of those ways can I get my R system
> (which is also installed through guix using system configuration) can
&g
I installed R packages using `guix install`, `guix shell` or by adding them to
my home configuration, but in none of those ways can I get my R system (which
is also installed through guix using system configuration) can recognize those
packages.
What is going wrong?
Zheng Junjie writes:
> Ricardo Wurmus writes:
>
>> Hi Guix,
>>
>> the r-team branch has been built successfully. It contains updates to
>> R
>> and both CRAN and Bioconductor packages.
>>
>> It is the last in the queue of branches to be merge
On Sun, Jul 07, 2024 at 09:24:23AM +0200, Ricardo Wurmus wrote:
> Hi Guix,
>
> the r-team branch has been built successfully. It contains updates to R
> and both CRAN and Bioconductor packages.
>
> It is the last in the queue of branches to be merged:
>
> core-updat
Hello,
Am Sun, Jul 07, 2024 at 09:24:23AM +0200 schrieb Ricardo Wurmus:
> the r-team branch has been built successfully. It contains updates to R
> and both CRAN and Bioconductor packages.
> It touches very few packages that are not related to R. The exception
> is apache-arrow.
a
Hello,
Ricardo Wurmus writes:
> the r-team branch has been built successfully. It contains updates to R
> and both CRAN and Bioconductor packages.
>
> It is the last in the queue of branches to be merged:
>
> core-updates #70456
> tex-team #70915
> pytho
Ricardo Wurmus writes:
> Hi Guix,
>
> the r-team branch has been built successfully. It contains updates to
> R
> and both CRAN and Bioconductor packages.
>
> It is the last in the queue of branches to be merged:
>
> core-updates #70456
> tex-team #7
Hi Guix,
the r-team branch has been built successfully. It contains updates to R
and both CRAN and Bioconductor packages.
It is the last in the queue of branches to be merged:
core-updates #70456
tex-team #70915
python-team #71408
kde-team #71614
rust-team
Hi Guix,
“guix system container” produces a launcher script. I would really like
to have a nicer name for it, so I use “-r” to link it to a well-known
location. But I can only do this once as the link name will be in use
the second time I run this.
I’d much rather like to have a proper profile
Hi Ludo,
On mar., 17 janv. 2023 at 17:09, Ludovic Courtès wrote:
>> For other cases, such issue is avoided by appending the suffix -next to
>> package name; as with ghc-next, python-numpy-next, emacs-next, etc.
>>
>> Personally, I find the -next trick useful because the package name
>> reflects
Hi,
Ludovic Courtès writes:
> Thoughts?
What if package variables in Guix were functions that accepted an
optional argument?
Each function could deliver any available version or a default, possibly
accompanied by a warning when the wanted version was not available.
Kind regards
Felix Lechne
Hello,
Simon Tournier skribis:
> Other said, build systems use some version for compiler and tools but
> Guix can also offer more recent versions for these very same compilers
> and tools. It leads to the issue when selecting the name of a compiler
> or tool (command line or manifest). The use
Simon Tournier writes:
> $ guix shell ocaml ocaml-ppxlib -- ocaml --version
> The OCaml toplevel, version 5.0.0
I also encountered this and was surprised.
> Personally, I find the -next trick useful because the package name
> reflects that it is not the default. However, it can be annoying t
Simon Tournier writes:
> Hi,
>
> As bug#60200 [1], the issue is one that many of us often hit: packages
> with several versions and when the highest one is not the default.
>
> Other said, build systems use some version for compiler and tools but
> Guix can also offer more recent versions for t
Hi,
As bug#60200 [1], the issue is one that many of us often hit: packages
with several versions and when the highest one is not the default.
Other said, build systems use some version for compiler and tools but
Guix can also offer more recent versions for these very same compilers
and tools. It
Ricardo Wurmus skribis:
> Ricardo Wurmus writes:
>
>> unfortunately I had to revert commits
>> 9078c651e8d50e08b46e3b2da1c532c15af5ddb6 (Add r-mathjaxr) and
>> 00056eafaefed0af8535f219760fbbe01dd6f240 (updating r-metafor).
> […]
>> The good news is that we can
Ricardo Wurmus writes:
> unfortunately I had to revert commits
> 9078c651e8d50e08b46e3b2da1c532c15af5ddb6 (Add r-mathjaxr) and
> 00056eafaefed0af8535f219760fbbe01dd6f240 (updating r-metafor).
[…]
> The good news is that we can soon build a
> slightly degraded version of math
Hi,
unfortunately I had to revert commits
9078c651e8d50e08b46e3b2da1c532c15af5ddb6 (Add r-mathjaxr) and
00056eafaefed0af8535f219760fbbe01dd6f240 (updating r-metafor).
mathjaxr contains vast amounts of minified JavaScript that cannot be
built from source. The Guix R team has been working on
On Thu, 06 Jan 2022 09:44:27 -0600 Katherine Cox-Buday
wrote:
Hi Katherine,
> I hope we can take the reasons people make these channels and bring
> them back to Guix proper to make contributing here just as easy.
Contributing to Guix upstream is definitely high priority for the guixrus
channel
jgart writes:
> On Wed, 29 Dec 2021 00:27:04 +0100 raingloom wrote:
>> TLDR how much of the effort spent on this channel is really justified
>> compared to making the underserved use-cases easier in upstream Guix?
I also have my own personal "upstream staging" channel so that I can continue
co
On Wed, 29 Dec 2021 00:27:04 +0100 raingloom wrote:
> TLDR how much of the effort spent on this channel is really justified
> compared to making the underserved use-cases easier in upstream Guix?
If there's any particular packages that should be sent upstream feel
free to take them from GuixRUs a
On Tue, 28 Dec 2021 08:40:20 -0500
jgart wrote:
> On Tue, 28 Dec 2021 13:14:45 +0100 Ricardo Wurmus
> wrote:
> >
> > jgart writes:
> >
> > > * Yet to be merged upstream.
> >
> > Are these going to be submitted and merged upstream eventually?
>
> Hi Ricardo,
>
> From our README:
>
On Tue, 28 Dec 2021 13:14:45 +0100 Ricardo Wurmus wrote:
>
> jgart writes:
>
> > * Yet to be merged upstream.
>
> Are these going to be submitted and merged upstream eventually?
Hi Ricardo,
>From our README:
```
The goal of this guix channel is to provide packages and services that are:
jgart writes:
> * Yet to be merged upstream.
Are these going to be submitted and merged upstream eventually? I think
it would be regrettable to establish a channel where ready-to-merge
packages accumulate that never make it into Guix proper because people
don’t want to make the little bit of
Hi Guixers,
Santa's calendar app seg-faulted, so they couldn't deliver the toys on the
correct date. As a bonus, instead of delivering toys they decided to offer
a toy store where you can build your own toys.
Welcome to GuixRUs[1], a Guix Channel, maintained by the whereiseveryone[2]
community.
ote:
> Hi,
>
> Recently, the switch from uglify-js to uglifyjs raises a question if
>
> this minification should be part of the r-build-system; as suggested
>
> by Ricardo:
>
> http://logs.guix.gnu.org/guix-hpc/2021-09-22.log#160424
>
> What people think to this
Hi,
Recently, the switch from uglify-js to uglifyjs raises a question if
this minification should be part of the r-build-system; as suggested
by Ricardo:
<http://logs.guix.gnu.org/guix-hpc/2021-09-22.log#160424>
What people think to this move? Because, currently the replacement of
the mi
Hi,
On Tue, 29 Dec 2020 at 20:04, Ricardo Wurmus wrote:
>> I fixed it with 0c8bb20b7cbd39537999fce29979a6acaf64e601, which is maybe
>> not the better solution.
>
> Oh, that’s unfortunate. I’m sorry for the breakage. I did run “make”
> to build the changed modules, so I’m surprised I didn’t see
t; (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value
> (r-snpstats)) (value #f))
> builder for
> `/gnu/store/g546w6qi19001rcx7si7imrb1z7yzf3g-guix-package-cache.drv' failed
> to produce output path
> `/gnu/store/sjy574qw76kdr
Hello,
This commit caused the following evaluation issue:
--8<---cut here---start->8---
Generating package cache for
'/gnu/store/dylz1h2sxgaqd6jhzq01b6y26797zjm5-profile'...
(exception unbound-variable (value #f) (value "Unbound vari
You do not need these packages: the tarball includes a copy of
> libfakechroot.so (see
> <https://hpc.guix.info/blog/2020/05/faster-relocatable-packs-with-fakechroot/>).
>
>> $ export GUIX_EXECUTION_ENGINE=fakechroot
>> $ strace -f -s 500 -o logg ./bin/R
>> fakechroot:
Hi,
zimoun skribis:
> On Sun, 8 Nov 2020 at 18:34, Ludovic Courtès wrote:
>
>> Oh right, you’d need to pick a different execution engine, most likely
>> ‘fakechroot’ is the only one that works on this machine:
>>
>> export GUIX_EXECUTION_ENGINE=fakechroot
>&g
Hi,
On Sun, 8 Nov 2020 at 18:34, Ludovic Courtès wrote:
> Oh right, you’d need to pick a different execution engine, most likely
> ‘fakechroot’ is the only one that works on this machine:
>
> export GUIX_EXECUTION_ENGINE=fakechroot
> strace -f -s 500 -o log ./bin/R
Hum? I d
Hi,
zimoun skribis:
> $ strace -f -s 500 -o log ./bin/R
> proot error: ptrace(TRACEME): Operation not permitted
> proot error:
> execve("/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/bin/R"):
> Operation not permitted
> proot info: possible causes:
&
Hi Roel,
On Thu, 05 Nov 2020 at 13:38, Roel Janssen wrote:
>> 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
Hi,
Thank you for the help.
On Fri, 06 Nov 2020 at 11:05, Ludovic Courtès wrote:
>> $ ./bin/R
>> : unsupported Guix execution engine; ignoring
>
> ‘GUIX_EXECUTION_ENGINE’ is set to the empty string.
Yes, sorry. I have tried another one than the default and have been
lazy
Hi,
zimoun skribis:
> The usual ‘./bin/R’ fails with:
>
> $ ./bin/R
> : unsupported Guix execution engine; ignoring
‘GUIX_EXECUTION_ENGINE’ is set to the empty string.
> ./bin/R
> R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
>
> [...]
>
-S /site-library=site-library \
> r) \
> cluster:/path/to/my/stuff
> --8<---cut here---end--->8---
>
> then log via SSH to cluster and untar the pack.
>
> --8<---
tc=etc \
-S /include=include \
-S /lib=lib \
-S /share=share \
-S /site-library=site-library \
r)\
cluster:/path/to/my/stu
Dear,
On Thu, 10 Sep 2020 at 16:44, Roel Janssen wrote:
> > If you have time to do that, yes please. Some time ago I started a
> > half-hearted migration of R packages from (gnu packages
> > bioinformatics)
> > to (gnu packages cran) and (gnu packages bioconductor).
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
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")
> > > >
time to do that, yes please. Some time ago I started a
>> half-hearted migration of R packages from (gnu packages bioinformatics)
>> to (gnu packages cran) and (gnu packages bioconductor). It’s not
>> supremely important, but I think in the long term we’d like to have CRAN
zimoun writes:
> Last, should CRAN packages in statistics.scm go in cran..scm or not?
Yes, I want statistics.scm to no longer have CRAN packages.
--
Ricardo
any good place for those packages. It would be good to
> have a dumping ground for packages like that, and for those that are on
> CRAN but unusually depend on Bioconductor packages.
IMHO, for non-CRAN and non-Bioconductor R packages, they should go to
thematic files: bioinformatics.sc
On Thu, 10 Sep 2020 at 13:30, Ricardo Wurmus wrote:
> > It seemed so "bioinformatics"-specific. But you're right, it's a CRAN
> > package, so that may be a better fit. Shall I move it to CRAN?
>
> If you have time to do that, yes please. Some time ago I s
Roel Janssen writes:
>> > +(define-public r-bisquerna
>> > + (package
>> > + (name "r-bisquerna")
>> > + (version "1.0.4")
>> > + (source (origin
>> > +(method url-fetch)
>&g
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
Roel Janssen writes:
>> > commit 1f56ec08af704bdc7aa3e143bf5ce351c5306dea
>> > Author: Roel Janssen
>> > AuthorDate: Wed Sep 9 16:56:02 2020 +0200
>> >
>> > gnu: Add r-loomr.
>> >
>> > * gnu/packages/bioinformatic
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
Hi Roel,
> This is an automated email from the git hooks/post-receive script.
>
> roelj pushed a commit to branch master
> in repository guix.
>
> The following commit(s) were added to refs/heads/master by this push:
> new a9401b4 gnu: Add r-useful.
> a9401b4 is de
Hi Roel,
> This is an automated email from the git hooks/post-receive script.
>
> roelj pushed a commit to branch master
> in repository guix.
>
> The following commit(s) were added to refs/heads/master by this push:
> new 0574446 gnu: Add r-bisquerna.
> 05
Hi Roel,
> This is an automated email from the git hooks/post-receive script.
>
> roelj pushed a commit to branch master
> in repository guix.
>
> The following commit(s) were added to refs/heads/master by this push:
> new 1f56ec0 gnu: Add r-loomr.
> 1f56ec0 is de
On Tue, 24 Mar 2020 22:13:00 -0500 sirgazil wrote
> On Tue, 24 Mar 2020 21:44:58 -0500 sirgazil wrote
>
> > Hi, Daniela
> >
> > On Tue, 24 Mar 2020 07:34:37 -0500 Daniela Lura
> wrote
> > > Yes I have and the same thing happens.
> > > When I use
On Tue, 24 Mar 2020 21:44:58 -0500 sirgazil wrote
> Hi, Daniela
>
> On Tue, 24 Mar 2020 07:34:37 -0500 Daniela Lura
> wrote
> > Yes I have and the same thing happens.
> > When I use: `guix environment --pure guix --ad-hoc coreutils findutils
> which`I am sent to
Hi, Daniela
On Tue, 24 Mar 2020 07:34:37 -0500 Daniela Lura
wrote
> Yes I have and the same thing happens.
> When I use: `guix environment --pure guix --ad-hoc coreutils findutils
> which`I am sent to another shell and it can't recognize pre-inst-env.
Did you run the recommended
Yes I have and the same thing happens.
When I use: `guix environment --pure guix --ad-hoc coreutils findutils
which`
I am sent to another shell and it can't recognize pre-inst-env.
On Wed, 25 Mar 2020 at 01:27, Paul Garlick <
pgarl...@tourbillion-technology.com> wrote:
> Hi Daniela,
>
> Have yo
Hi Daniela,
Have you tried './pre-inst-env guix build ...' instead of 'guix build
...'?
The difference is that the former command will look for package
definitions in your checked out, and modified, version of Guix.
The latter command looks for package definitions in your installed
version of
Hello,
I hope you are well!
I've been trying to build an r package for two days now.
When I initially ran `guix build` I got an error message indicating that
there was no code for a specific guile module, which I managed to work
around by using %load-path.
After adding GUILE_LOAD_PAT
Hello,
R Veera Kumar ezt írta (időpont: 2020. márc. 11., Sze
17:51):
> On Wed, Mar 11, 2020 at 11:03:00AM +0100, Gábor Boskovits wrote:
> > Hello,
> >
> > Veera ezt írta (időpont: 2020. márc. 11., Sze 1:31):
> >
> > > On Tue, Mar 10, 2020 at 08:
contribute would be to build an unmodified guix
> from source.
>
> Try to find out how to do that, the manual has great instructions. Should
> you have any questions feel free to reach out to us.
>
Yes. Would that require huge internet bandwidth? I mean downloading all
the package so
great instructions. Should
you have any questions feel free to reach out to us.
>
> > > The usual first time contribution we recommend is to package an R
> > package
> > > from cran that has all its dependencies in guix using the
> > importer.
y around.
> > The usual first time contribution we recommend is to package an R
> package
> > from cran that has all its dependencies in guix using the
> importer.
> >
>
>Best regards,
>G_bor
>
> References
>
>1. mailto:v...@vkten.in
>3. http://issues.guix.gnu.org/easy
Regards,
Veera
Hello,
Veera ezt írta (időpont: 2020. márc. 8., Vas 8:41):
> On Sat, Mar 07, 2020 at 09:31:32PM +0100, Gábor Boskovits wrote:
> > Hello Veera,
> >
> > Veera ezt írta (időpont: 2020. márc. 7., Szo 16:05):
> >
> > > Hi,
> > >
> > > I am R Vee
On Sat, Mar 07, 2020 at 09:31:32PM +0100, Gábor Boskovits wrote:
> Hello Veera,
>
> Veera ezt írta (időpont: 2020. márc. 7., Szo 16:05):
>
> > Hi,
> >
> > I am R Veera Kumar from India. I have been selected as Outreachy applicant
> > for May 2020 round.
>
Hello Veera,
Veera ezt írta (időpont: 2020. márc. 7., Szo 16:05):
> Hi,
>
> I am R Veera Kumar from India. I have been selected as Outreachy applicant
> for May 2020 round.
>
Nice to see you around.
>
> I like to work with Danny Milosavljevic, the mentor of the project:
&
On Sat, Mar 07, 2020 at 04:19:09PM +0100, Pierre Neidhardt wrote:
> Hi Veera!
>
> Welcome!
>
> Veera writes:
>
> > I like to work with Danny Milosavljevic, the mentor of the project:
> > Guix Integration of desktop environments into GNU Guix
>
> Cool, sounds like this is very much needed!
> D
Hi,
I am R Veera Kumar from India. I have been selected as Outreachy applicant
for May 2020 round.
I like to work with Danny Milosavljevic, the mentor of the project:
Guix Integration of desktop environments into GNU Guix
I am a self taught computer and software user. I am a Linux user for 15
Hi,
I am R Veera Kumar from India. I have been selected as Outreachy applicant
for May 2020 round.
I like to work with Danny Milosavljevic, the mentor of the project:
Guix Integration of desktop environments into GNU Guix
I am a self taught computer and software user. I am a Linux user for 15
Hi,
I am R Veera Kumar from India. I have been selected as Outreachy applicant
for May 2020 round.
I like to work with Danny Milosavljevic, the mentor of the project:
Guix Integration of desktop environments into GNU Guix
I am a self taught computer and software user. I am a Linux user for 15
or example the packages r-shiny or r-sankeyd3
> do not come from CRAN but directly from Github.
> Maybe, we could group all the 6 non-CRAN packages and the 4 CRAN
> packages depending on Bioconductor to a unique file.
>
> What do you think?
Yes, the should probably be moved. It’s als
int to (gnu packages
> bioconductor). A more correct way to deal with this would be put these
> outliers in a separate module, or even to ignore this all together until
> it becomes a problem.
If I understand well, the policy is: the packages in the file cran.scm
cannot import '(gnu
zimoun writes:
> 1.
> Currently, the file bioconductor.scm contains 4 packages with
> 'cran-uri' and git blames you. :-)
>
> Well, the 4 commits are:
>
> : a207bca2ad gnu: r-codedepends: Move from cran to bioconductor.
> : 3a0babacdc gnu: Add r-htscluster
Hi Ricarco
On Fri, 22 Nov 2019 at 15:47, Ricardo Wurmus wrote:
> PS: I also think that CRAN things in bioinformatics.scm should be moved
> to cran.scm, and even some or all of the R stuff in statistics.scm.
> (Same applies to Bioconductor packages, which should end up in
> bioc
Hi Ricardo,
Thank you for your inputs.
On Fri, 22 Nov 2019 at 15:47, Ricardo Wurmus wrote:
> > The packages r-desolve, r-quadprog, r-subplex and r-pracma are defined
> > in `maths.scm`. They come from the CRAN archive. For consistency, they
> > should be defined in the file
Hi simon,
> The packages r-desolve, r-quadprog, r-subplex and r-pracma are defined
> in `maths.scm`. They come from the CRAN archive. For consistency, they
> should be defined in the file `cran.scm`. Do you agree to move them?
I think moving them to cran.scm is fine. In my opinio
zimoun writes:
> On Thu, 31 Oct 2019 at 16:37, zimoun wrote:
>
>> The packages r-desolve, r-quadprog, r-subplex and r-pracma are defined
>> in `maths.scm`. They come from the CRAN archive. For consistency, they
>> should be defined in the file `cran.scm`. Do you agre
Hi,
On Thu, 31 Oct 2019 at 16:37, zimoun wrote:
> The packages r-desolve, r-quadprog, r-subplex and r-pracma are defined
> in `maths.scm`. They come from the CRAN archive. For consistency, they
> should be defined in the file `cran.scm`. Do you agree to move them?
What happens to the
1 - 100 of 760 matches
Mail list logo
