Re: merging r-team branch

[Z572]

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 merged:
>>
>> core-updates #70456
>> tex-team #70915
>> python-team  #71408
>> kde-team #71614
>> rust-team#71703
>> r-team   #71901
>>
>> It touches very few packages that are not related to R.  The exception
>> is apache-arrow.
>>
>> I know that while the python-team branch is farther up the queue it is
>> not actually ready to be merged, pushing up kde-team, rust-team, and
>> r-team.  What is the status of the other branches in the queue?
>
> Kde-team wasn't ready yet and I opened question to get qa to show the broken 
> package

I think kde-team now is ready, if nothing else, I plan to merge in two days.


signature.asc
Description: PGP signature

Re: merging r-team branch

[Efraim Flashner]

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-updates #70456
> tex-team #70915
> python-team  #71408
> kde-team #71614
> rust-team#71703
> r-team   #71901
> 
> It touches very few packages that are not related to R.  The exception
> is apache-arrow.
> 
> I know that while the python-team branch is farther up the queue it is
> not actually ready to be merged, pushing up kde-team, rust-team, and
> r-team.  What is the status of the other branches in the queue?

The rust-team has no objections to you merging first.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: merging r-team branch

[Andreas Enge]

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.

answering the subtext of the question, I think it would be okay to merge
the branch before the others (or rather, independently).

I see that there is a new patch on core-updates related to R:
Author: Ludovic Courtès 
Date:   Sun Jul 7 00:42:43 2024 +0200
gnu: r-minimal: Add dependency on ‘texlive-etoolbox’.
* gnu/packages/statistics.scm (r-with-tests)[native-inputs]: Add
TEXLIVE-ETOOLBOX.
Change-Id: I1ea48e5afa013d8c36054f423e57252dbc02f12a

So when merging first r-team and then core-updates or the other way round,
it would be good to pay attention to it.

Andreas

Re: merging r-team branch

[Development of GNU Guix and the GNU System distribution.]

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
> python-team  #71408
> kde-team #71614
>     rust-team#71703
> r-team   #71901
>
> It touches very few packages that are not related to R.  The exception
> is apache-arrow.
>
> I know that while the python-team branch is farther up the queue it is
> not actually ready to be merged, pushing up kde-team, rust-team, and
> r-team.  What is the status of the other branches in the queue?

The tex-team branch is included in core-updates and currently being
built by the bordeaux farm. So it can be ignored.

Regards,
-- 
Nicolas Goaziou

Re: merging r-team branch

[Zheng Junjie]

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 #70915
> python-team  #71408
> kde-team #71614
> rust-team#71703
> r-team   #71901
>
> It touches very few packages that are not related to R.  The exception
> is apache-arrow.
>
> I know that while the python-team branch is farther up the queue it is
> not actually ready to be merged, pushing up kde-team, rust-team, and
> r-team.  What is the status of the other branches in the queue?

Kde-team wasn't ready yet and I opened question to get qa to show the broken 
package


signature.asc
Description: PGP signature

merging r-team branch

[Ricardo Wurmus]

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#71703
r-team   #71901

It touches very few packages that are not related to R.  The exception
is apache-arrow.

I know that while the python-team branch is farther up the queue it is
not actually ready to be merged, pushing up kde-team, rust-team, and
r-team.  What is the status of the other branches in the queue?

-- 
Ricardo

guix system container -r: write to profile?

[Ricardo Wurmus]

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 with roll backs.  Would it
be a good idea to either extend “--root” to manage a symlink forest
(instead of just creating a single link) or to extend “guix system
container” to add its generated launcher script to a profile’s bin
directory?

-- 
Ricardo

Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Simon Tournier]

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 that it is not the default.  However, it can be annoying to
>> update manifest files when this -next is becoming default.
>
> To me it’s mostly a packaging issue: I would expect ‘ocaml’ to be able
> to use ‘ocaml-ppxlib’.  If not, then it should indeed be ‘-next’.

Currently, yes it is a packaging issue.  And yes, the usual trick to fix
the issue is to append -next to the package name.  As I have tried to
explain in bug#60200 [1]. ;-)

About this -next, Lars’s answer is, quoting [2]:

The -next suffix has the obvious disadvantage that
specifications may become invalid as we move -next to the
“regular” package. So maybe marking packages “default” like the
attached patch does could improve the current situation. Not
just for gcc, but also Haskell and Python come to mind.

Hence this discussion. :-)

The addition of a ’properties’ to make the difference between “current”
and “next” packages appears to be a cleaner fix than to append -next to
package name.

Consider the manifest:

(specifications->manifest (list "ghc-next@9.2"))

and note that currently the Haskell compiler used by
haskell-build-system is ghc@8.10.7.

When this default is updated to an higher version of GHC, says version
9.4, then this manifest breaks because ghc-next@9.2 is renamed ghc@9.2;
the -next suffix is only applied to version higher than the one used by
the Haskell build system.


1: 
2: 


> I’m slightly reluctant because then you can have several packages that
> declare themselves as “default”, which looks weird.  Reasoning about why
> a given package was chosen would now involve more than version strings.

As similarly we can have several packages that declare themselves with
the same name and version. :-)

If we go for -next, then the two packages gcc-toolchain@{11,12} must be
renamed gcc-toolchain-next@{11,12} to be compliant and fixes bug#60200.


Why a given package was chosen as “default”?  Because the packages
marked as “default” are – if and only if several versions are publicly
declared – the ones used by the build-systems and also the ones with
many dependents as Numpy.  It avoids the -next dance.

Well, all in all this “default” property appears to me more elegant than
append -next to package name.

Cheers,
simon

Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Development of GNU Guix and the GNU System distribution.]

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 Lechner

Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Ludovic Courtès]

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 user does not get the ones used
> as default by build system.
>
> In addition to [1], another example:
>
> $ guix shell ocaml ocaml-ppxlib -- ocaml --version
> The OCaml toplevel, version 5.0.0
>
>
> But the OCaml libraries are built using OCaml compiler v4.14, thus it
> leads to error as:
>
> Error: 
> /gnu/store/vglxlc8riynj1g937clvwv8yg40lln6z-profile/lib/ocaml/site-lib/ppxlib/ppxlib.cmi
>is not a compiled interface for this version of OCaml.
> It seems to be for an older version of OCaml.
>
> 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 that it is not the default.  However, it can be annoying to
> update manifest files when this -next is becoming default.

To me it’s mostly a packaging issue: I would expect ‘ocaml’ to be able
to use ‘ocaml-ppxlib’.  If not, then it should indeed be ‘-next’.

> Well, what do people think about this Lars’s patch?
>
> diff --git a/gnu/packages.scm b/gnu/packages.scm
> index 61345f75a9..7e5a6d49c2 100644
> --- a/gnu/packages.scm
> +++ b/gnu/packages.scm
> @@ -356,20 +356,24 @@ (define cache
> (find-packages-by-name/direct name version
>  
>  (define (find-best-packages-by-name name version)
> -  "If version is #f, return the list of packages named NAME with the highest
> -version numbers; otherwise, return the list of packages named NAME and at
> -VERSION."
> +  "If version is #f, return the list of packages named NAME with only
> +packages marked default? or, if none exist, the highest version numbers;
> +otherwise, return the list of packages named NAME and at VERSION."
>(if version
>(find-packages-by-name name version)
>(match (find-packages-by-name name)
>  (()
>   '())
>  ((matches ...)
> - ;; Return the subset of MATCHES with the higher version number.
> - (let ((highest (package-version (first matches
> -   (take-while (lambda (p)
> - (string=? (package-version p) highest))
> -   matches))
> + ;; Return the subset of MATCHES which are marked default or those 
> with
> + ;; the higher version number.
> + (let ((highest (package-version (first matches)))
> +   (default (filter (lambda (p) (assoc-ref (package-properties 
> p) 'default?)) matches)))
> +   (if (not (null? default))
> +   default
> +   (take-while (lambda (p)
> + (string=? (package-version p) highest))
> +   matches)))

I’m slightly reluctant because then you can have several packages that
declare themselves as “default”, which looks weird.  Reasoning about why
a given package was chosen would now involve more than version strings.

Thoughts?

Ludo’.

Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[pukkamustard]

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 to
> update manifest files when this -next is becoming default.
>
> Well, what do people think about this Lars’s patch?

I like it.

I think adding the `default?` property is nicer than the -next
trick. Only nitpick: I would maybe call the property `default-version?`
to make meaning of the property more explicit.

Cheers,
pukkamustard

Re: properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Csepp]

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 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 user does not get the ones used
> as default by build system.
>
> In addition to [1], another example:
>
> $ guix shell ocaml ocaml-ppxlib -- ocaml --version
> The OCaml toplevel, version 5.0.0
>
>
> But the OCaml libraries are built using OCaml compiler v4.14, thus it
> leads to error as:
>
> Error: 
> /gnu/store/vglxlc8riynj1g937clvwv8yg40lln6z-profile/lib/ocaml/site-lib/ppxlib/ppxlib.cmi
>is not a compiled interface for this version of OCaml.
> It seems to be for an older version of OCaml.
>
> 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 that it is not the default.  However, it can be annoying to
> update manifest files when this -next is becoming default.
>
> Well, what do people think about this Lars’s patch?

As I *just* ran into some OCaml and GCC related issues a few days ago,
I'm in favor of either the default flag or expanding the -next suffix
naming convention to more packages.

properties for default version? (was bug#60200: Incompatibilities between gcc-toolchain and R packages)

[Simon Tournier]

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 leads to the issue when selecting the name of a compiler
or tool (command line or manifest).  The user does not get the ones used
as default by build system.

In addition to [1], another example:

--8<---cut here---start->8---
$ guix shell ocaml ocaml-ppxlib -- ocaml --version
The OCaml toplevel, version 5.0.0
--8<---cut here---end--->8---

But the OCaml libraries are built using OCaml compiler v4.14, thus it
leads to error as:

--8<---cut here---start->8---
Error: 
/gnu/store/vglxlc8riynj1g937clvwv8yg40lln6z-profile/lib/ocaml/site-lib/ppxlib/ppxlib.cmi
   is not a compiled interface for this version of OCaml.
It seems to be for an older version of OCaml.
--8<---cut here---end--->8---

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 that it is not the default.  However, it can be annoying to
update manifest files when this -next is becoming default.

Well, what do people think about this Lars’s patch?

diff --git a/gnu/packages.scm b/gnu/packages.scm
index 61345f75a9..7e5a6d49c2 100644
--- a/gnu/packages.scm
+++ b/gnu/packages.scm
@@ -356,20 +356,24 @@ (define cache
(find-packages-by-name/direct name version
 
 (define (find-best-packages-by-name name version)
-  "If version is #f, return the list of packages named NAME with the highest
-version numbers; otherwise, return the list of packages named NAME and at
-VERSION."
+  "If version is #f, return the list of packages named NAME with only
+packages marked default? or, if none exist, the highest version numbers;
+otherwise, return the list of packages named NAME and at VERSION."
   (if version
   (find-packages-by-name name version)
   (match (find-packages-by-name name)
 (()
  '())
 ((matches ...)
- ;; Return the subset of MATCHES with the higher version number.
- (let ((highest (package-version (first matches
-   (take-while (lambda (p)
- (string=? (package-version p) highest))
-   matches))
+ ;; Return the subset of MATCHES which are marked default or those with
+ ;; the higher version number.
+ (let ((highest (package-version (first matches)))
+   (default (filter (lambda (p) (assoc-ref (package-properties p) 'default?)) matches)))
+   (if (not (null? default))
+   default
+   (take-while (lambda (p)
+ (string=? (package-version p) highest))
+   matches)))
 
 ;; Prevent Guile 3 from inlining this procedure so we can mock it in tests.
 (set! find-best-packages-by-name find-best-packages-by-name)
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index b4566b41cc..2d5e0add26 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -3855,7 +3855,10 @@ (define* (make-gcc-toolchain gcc
 ("libc-static" ,libc "static"))
 
 (define-public gcc-toolchain
-  (make-gcc-toolchain gcc-final))
+  (let ((parent (make-gcc-toolchain gcc-final)))
+(package
+  (inherit parent)
+  (properties (alist-cons 'default? #t (package-properties parent))
 
 (define-public gcc-toolchain-4.8
   (make-gcc-toolchain gcc-4.8))


1: 

Cheers,
simon

Re: r-mathjaxr

[Guillaume Le Vaillant]

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 soon build a
>> slightly degraded version of mathjaxr completely from source.
>
> I have restored the commits, changing r-mathjaxr to use the files we’ve
> built in the js-mathjax-for-r-mathjaxr package.
>
> I decided not to delete the a11y directory from r-mathjaxr (which we
> couldn’t build in js-mathjax-for-r-mathjaxr), because these files are
> not minified and rather short, so it doesn’t hurt to keep them.

Ok. Thanks for fixing it.


signature.asc
Description: PGP signature

Re: r-mathjaxr

[Ricardo Wurmus]

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 mathjaxr completely from source.

I have restored the commits, changing r-mathjaxr to use the files we’ve
built in the js-mathjax-for-r-mathjaxr package.

I decided not to delete the a11y directory from r-mathjaxr (which we
couldn’t build in js-mathjax-for-r-mathjaxr), because these files are
not minified and rather short, so it doesn’t hurt to keep them.

-- 
Ricardo

r-mathjaxr

[Ricardo Wurmus]

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 packaging this
properly for a very long time, but it’s still work in progress.  We
cannot include packages that merely wrap megabytes of minified
JavaScript — we need to actually build this from source.

There are a couple more R package updates that I’ve had to hold back
because of issues like that.  The good news is that we can soon build a
slightly degraded version of mathjaxr completely from source.

-- 
Ricardo

Re: Guix "R" Us - GNU's joy store!

[jgart]

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 and the whereiseverone community.

For example, as a small community we are planning to organize a monthly
channel cleanup day in which we look at all the packages in guixrus and
determine which packages should be sent upstream and which packages still
need more work. This style of iteration can serve as an additional and
more intimate layer of onboarding for newer users because we review
patches on https://lists.sr.ht/~whereiseveryone/guixrus as well as
discuss package issues on #whereiseveryone (libera.chat) in a short
feedback loop. In the process of doing the above we also explain the
upstream contribution process to newcomers. My hope is that higher-quality
packages by first-time Guixers will become more commonplace in upstream
issue trackers.

We are also experimenting with using builds.sr.ht to run the guix lint
checker, and more when submitting patches to guixrus/upstream thanks
to dhruvin:

https://builds.sr.ht/~dhruvin/job/665098
https://builds.sr.ht/~dhruvin/job/665205

We are developing a package search[1] in the context of the guixrus
channel web site:

https://paste.sr.ht/~dhruvin/0828f7b1df2ffa7b7b31c50e07ef043d94caeea0

guixrus had 83 packages that day. If interested in the library that was
used to generate the json paste output see this repo:

https://git.sr.ht/~dhruvin/doug

A top priority goal of the whereiseveryone community is to encourage
new Guixers to contribute to Guix (upstream as well as whereiseveryone
community projects). We want to facilitate, develop, and discuss that
process, as well as experiment with fun ideas and tools for Guix. It's
ambitious, I know. We'll take it one S-expression at a time.

happy hacking,

https://sr.ht/~whereiseveryone/

Re: Guix "R" Us - GNU's joy store!

[Katherine Cox-Buday]

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 
contributing to Guix at my own pace, in my own way, until I can get enough 
velocity to really internalize contributing in the way Guix would like me to. I 
also tend to hack on things there, and then batch my changes for upstream so 
that I can keep everything consistent and make sure all my code meets upstream 
standards. In the meantime, I'm able to actually use the code.

My only concern with organizing this activity into a group is that it is a kind 
of "community fork". 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.

At any rate, any energy put into the ecosystem is good in my book. Cheers! :)

--
Katherine

Re: Guix "R" Us - GNU's joy store!

[jgart]

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 and send a patch to upstream. Just add
the original packager as co-author out of courtesy. Also, let us know by
linking the ticket number so that we can remove them from the channel. We
also read the commit history daily to stay up to date as we are also
regular contributors to upstream.

If there are any packages that build solely with package transformation
options from the cli and they are currently in GuixRUs also let us know and
we'll remove them after testing.

See the other points in my previous email for more reasons to
have GuixRUs (pre-releases, nightlies (olive), alpha software
(https://issues.guix.gnu.org/47104), vis-lsp, etc...).  I think people
should explore having channels for the sake of just exploring having a
channel. It allows those without commit access to have the freedom to
explore and navigate Guix how they want and at the pace that they'd
like to develop at without fully depending on upstream. Channels can
assist upstream when proper communication is involved. I also think
channels can function as a testing ground before sending a patch for
review to upstream.

The following is just two example channels that have served as a testbed
before sending to upstream:

https://git.genenetwork.org/guix-bioinformatics/guix-bioinformatics
https://github.com/ryanprior/guix-packages

GuixRUs is not a new idea. GuixRUs is like any other guix channel out
in the wild. We just want to have our own small channel as a small
community. We encourage others to start their own channels and we're
working on making starting a channel easier for newcomers in the near
future. Stay tuned!

I hope that further clarified/contextualized some points on GuixRUs I made
in previous emails. If not, feel free to reply with further questions. Thank
you for your interest.

all best,

jgart

Re: Guix "R" Us - GNU's joy store!

[raingloom]

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:
> 
> ```
> The goal of this guix channel is to provide packages and services
> that are:
> 
> * Yet to be merged upstream.
> * In alpha or beta stage of development.
> * Customized to certain use-cases.
> * Nightly releases.
> ```
> 
> To expound on the above a bit:
> 
> > Yet to be merged upstream.  
> 
> You can think of GuixRUs as a pre-release channel for software that
> is waiting to be reviewed upstream.
> 
> Sometimes patches can sit for a while while waiting for upstream
> review and GuixRUs hopes to alleviate some of this anxiety by
> providing those patches as "pre-releases" in a community channel that
> makes them available through an expedited review process. We're
> interested in developing tooling to help facilitate this ambitious
> endeavour.

I think guix time-machine and some options to guix pull already let you
build with some patches or from a custom git URL. If not, maybe making
that easier would be preferable to making a separate channel.

> > In alpha or beta stage of development.  
> 
> We'll make grumble available through GuixRUs and provide a service:
> 
> https://issues.guix.gnu.org/
> 
> Another software that is in heavy development but useable:
> 
> https://wahay.org/
> 
> > Nightly releases.  
> 
> GuixRUs will start by tracking olive-editor nightlies:
> 
> https://www.olivevideoeditor.org/nightly.php

What's the improvement with this channel compared to just using the
various package transformations, like --with-latest or --with-branch or
whatever?

> > What's the intended process to avoid this?  
> 
> Packages that are suitable for upstream will be sent in batches. 
> 
> whereiseveryone community are active contributors and we'll make sure
> to send over any developments suitable for upstream.
> 
> We welcome anyone to help contribute in those efforts. 
> 
> Feel free to upstream anything in GuixRUs that you see suitable if we
> don't get around to it.
> 
> If you remember to list the original author/packager when upstreaming
> from GuixRUs it would be much appreciated.
> 
> The first batch to be sent from GuixRUs for upstream will be these
> emacs packages we recently packaged:
> 
> https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/emacs.scm
> 
> > Customized to certain use-cases.  
> 
> I recently forked vis to provide language server protocol support
> "out of the box".[1]
> 
> We're also packaging all the suckless patches for dwm, st, dmenu,
> surf, etc... and making them available as guile variables/code in
> order to easily assemble your own suckless forks with guix[2][3]. In
> other words, GuixRUs can also be thought of as a library for
> assembling your own suckless fork.

Again, package transformations already let you do this. Might make more
sense to just set up a substitute server.

> > Is only free software acceptable in this channel?  
> 
> Yes, we only accept free software. GuixRUs is a free software bazaar.
> 
> GuixRUs is at the service of assisting upstream and the Guix
> community at large.
> 
> all best,
> 
> jgart
> 
> 
> [1]
> https://github.com/fischerling/vis-lspc#easy-vis-lspc-installation-with-guixrus
> [2]
> https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/patches/suckless.scm#L28
> [3]
> https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/suckless.scm#L44
> 

TLDR how much of the effort spent on this channel is really justified
compared to making the underserved use-cases easier in upstream Guix?

Re: Guix "R" Us - GNU's joy store!

[jgart]

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:

* Yet to be merged upstream.
* In alpha or beta stage of development.
* Customized to certain use-cases.
* Nightly releases.
```

To expound on the above a bit:

> Yet to be merged upstream.

You can think of GuixRUs as a pre-release channel for software that is waiting 
to be reviewed upstream.

Sometimes patches can sit for a while while waiting for upstream review
and GuixRUs hopes to alleviate some of this anxiety by providing those
patches as "pre-releases" in a community channel that makes them available
through an expedited review process. We're interested in developing tooling
to help facilitate this ambitious endeavour.

> In alpha or beta stage of development.

We'll make grumble available through GuixRUs and provide a service:

https://issues.guix.gnu.org/

Another software that is in heavy development but useable:

https://wahay.org/

> Nightly releases.

GuixRUs will start by tracking olive-editor nightlies:

https://www.olivevideoeditor.org/nightly.php

> What's the intended process to avoid this?

Packages that are suitable for upstream will be sent in batches. 

whereiseveryone community are active contributors and we'll make sure to send 
over any developments suitable for upstream.

We welcome anyone to help contribute in those efforts. 

Feel free to upstream anything in GuixRUs that you see suitable if we don't get 
around to it.

If you remember to list the original author/packager when upstreaming from 
GuixRUs it would be much appreciated.

The first batch to be sent from GuixRUs for upstream will be these emacs 
packages we recently packaged:

https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/emacs.scm

> Customized to certain use-cases.

I recently forked vis to provide language server protocol support "out of the 
box".[1]

We're also packaging all the suckless patches for dwm, st, dmenu,
surf, etc... and making them available as guile variables/code in order
to easily assemble your own suckless forks with guix[2][3]. In other words,
GuixRUs can also be thought of as a library for assembling your own suckless 
fork.

> Is only free software acceptable in this channel?

Yes, we only accept free software. GuixRUs is a free software bazaar.

GuixRUs is at the service of assisting upstream and the Guix community at large.

all best,

jgart


[1] 
https://github.com/fischerling/vis-lspc#easy-vis-lspc-installation-with-guixrus
[2] 
https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/patches/suckless.scm#L28
[3] 
https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/suckless.scm#L44

Re: Guix "R" Us - GNU's joy store!

[Ricardo Wurmus]

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 extra effort to move them.

What’s the intended process to avoid this?

Is only free software acceptable in this channel?

-- 
Ricardo

Guix "R" Us - GNU's joy store!

[jgart]

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.

The goal of the GuixRUs channel is to provide packages and services that are:

* Yet to be merged upstream.
* In alpha or beta stage of development.
* Customized to certain use-cases.
* Nightly releases.

Let's hack! GNU's joy store. It's worth the journey!

regards, 
jgart and RG

[1]: https://sr.ht/~whereiseveryone/guixrus
[2]: https://web.libera.chat/gamja/#whereiseveryone

Re: minification R: build-system

[Charles]

I think what would be ideal is packaging the Javascript dependencies 
separately, then including them as inputs. I wouldn't be suprised if someone 
has tried this, but I don't know the history.

‐‐‐ Original Message ‐‐‐

On Monday, September 27th, 2021 at 12:28 PM, zimoun  
wrote:

> 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 minifier means grep and replace all by hand, i.e., prone-error.
>
> It should be nice to add a step for the R packages. WDYT?
>
> All the best,
>
> simon

minification R: build-system

[zimoun]

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 minifier means grep and replace all by hand, i.e., prone-error.
It should be nice to add a step for the R packages.  WDYT?


All the best,
simon

Re: 08/10: gnu: r-snpstats: Move to (gnu packages bioconductor).

[zimoun]

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 an “Unbound
> variable” error then.

Oh, sorry.

> I’ll move that package from cran.scm to bioconductor.scm as we did in
> similar cases.

Thanks,
simon

Re: 08/10: gnu: r-snpstats: Move to (gnu packages bioconductor).

[Ricardo Wurmus]

Mathieu Othacehe  writes:

> 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 variable: ~S") (value 
> (r-snpstats)) (value #f))
> builder for 
> `/gnu/store/g546w6qi19001rcx7si7imrb1z7yzf3g-guix-package-cache.drv' failed 
> to produce output path 
> `/gnu/store/sjy574qw76kdrria4grhx16xqqs9w78z-guix-package-cache'
> @ build-failed 
> /gnu/store/g546w6qi19001rcx7si7imrb1z7yzf3g-guix-package-cache.drv - 1 
> builder for 
> `/gnu/store/g546w6qi19001rcx7si7imrb1z7yzf3g-guix-package-cache.drv' failed 
> to produce output path `/gnu/store/sjy574qw76kdrria4grhx16xqqs9w78z-guix-
> --8<---cut here---end--->8---
>
> 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 an “Unbound
variable” error then.

I’ll move that package from cran.scm to bioconductor.scm as we did in
similar cases.

-- 
Ricardo

Re: 08/10: gnu: r-snpstats: Move to (gnu packages bioconductor).

[Mathieu Othacehe]

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 variable: ~S") (value 
(r-snpstats)) (value #f))
builder for 
`/gnu/store/g546w6qi19001rcx7si7imrb1z7yzf3g-guix-package-cache.drv' failed to 
produce output path 
`/gnu/store/sjy574qw76kdrria4grhx16xqqs9w78z-guix-package-cache'
@ build-failed 
/gnu/store/g546w6qi19001rcx7si7imrb1z7yzf3g-guix-package-cache.drv - 1 builder 
for `/gnu/store/g546w6qi19001rcx7si7imrb1z7yzf3g-guix-package-cache.drv' failed 
to produce output path `/gnu/store/sjy574qw76kdrria4grhx16xqqs9w78z-guix-
--8<---cut here---end--->8---

I fixed it with 0c8bb20b7cbd39537999fce29979a6acaf64e601, which is maybe
not the better solution.

Mathieu

Re: “guix pack -RR r“ fails?

[zimoun]

Hi,

On Thu, 12 Nov 2020 at 21:41, Ludovic Courtès  wrote:

>> Hum?  I do not know if I am doing correctly.  The packages
>> fakechroot-2.9-24.5.el6_1.1.x86_64.rpm and
>> fakechroot-libs-2.9-24.5.el6_1.1.x86_64.rpm are installed.  And I get
>> as regular user:
>
> 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: unsupported Guix execution engine; ignoring
>
> You would need to use ‘guix pack -RR’ instead of ‘guix pack -R’ to get
> the ‘fakechroot’ execution engine.
>
>> However, as root, simply running ./bin/R returns:
>>
>> # ./bin/R
>> R: run.c:245: disallow_setgroups: Unexpected error: No such file or 
>> directory.
>> Abandon
>
> That indicates that user namespaces are not supported.

I have used ’-RR’ but because it is not working, then I tried to install
extra stuff in case.  But if the kernel is not supporting the namespace,
that’s a end.  Period.


> But wait, if you’re root, you can just as well upgrade to a kernel that
> supports unprivileged user namespaces… or even install Guix?  :-)

That’s not so simple.  It is an old RHEL and I am not sure that the
upgrading path is smooth…  So I am applying the well-known rule: do not
fix it if it is not broken. ;-) Well, I do not want to spend hours to
figure out what is wrong with the new configuration (hardware).

Installing Guix (the package manager) cannot work because the same
problem: kernel.

I am configuring another machine (Dell T620) to smooth the switch.  But
I hit the very same problem: spending hours to figure out what’s wrong
because I am missing obscure hardware configurations.


Thank you for your help.

Cheers,
simon

Re: “guix pack -RR r“ fails?

[Ludovic Courtès]

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
>>   strace -f -s 500 -o log ./bin/R
>
> Hum?  I do not know if I am doing correctly.  The packages
> fakechroot-2.9-24.5.el6_1.1.x86_64.rpm and
> fakechroot-libs-2.9-24.5.el6_1.1.x86_64.rpm are installed.  And I get
> as regular user:

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: unsupported Guix execution engine; ignoring

You would need to use ‘guix pack -RR’ instead of ‘guix pack -R’ to get
the ‘fakechroot’ execution engine.

> However, as root, simply running ./bin/R returns:
>
> # ./bin/R
> R: run.c:245: disallow_setgroups: Unexpected error: No such file or directory.
> Abandon

That indicates that user namespaces are not supported.

But wait, if you’re root, you can just as well upgrade to a kernel that
supports unprivileged user namespaces… or even install Guix?  :-)

HTH,
Ludo’.

Re: “guix pack -RR r“ fails?

[zimoun]

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 do not know if I am doing correctly.  The packages
fakechroot-2.9-24.5.el6_1.1.x86_64.rpm and
fakechroot-libs-2.9-24.5.el6_1.1.x86_64.rpm are installed.  And I get
as regular user:

--8<---cut here---start->8---
$ export GUIX_EXECUTION_ENGINE=fakechroot
$ strace -f -s 500 -o logg ./bin/R
fakechroot: unsupported Guix execution engine; ignoring
./bin/Rproot 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:
  * the program is a script but its interpreter (eg. /bin/sh) was not found;
  * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
  * the program is a foreign binary but qemu was not specified;
  * qemu does not work correctly (if specified);
  * the loader was not found or doesn't work.
fatal error: see `proot --help`.
proot error: can't chmod '/tmp/proot-41950-9kDMBf': No such file or directory
--8<---cut here---end--->8---
However, as root, simply running ./bin/R returns:

--8<---cut here-------start->8---
# ./bin/R
R: run.c:245: disallow_setgroups: Unexpected error: No such file or directory.
Abandon
[root@HEAD foo]#
R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

During startup - Warning messages:
1: Setting LC_CTYPE failed, using "C"
2: Setting LC_COLLATE failed, using "C"
3: Setting LC_TIME failed, using "C"
4: Setting LC_MESSAGES failed, using "C"
5: Setting LC_MONETARY failed, using "C"
6: Setting LC_PAPER failed, using "C"
7: Setting LC_MEASUREMENT failed, using "C"
>
--8<---cut here---end--->8---


All the best,
simon

Re: “guix pack -RR r“ fails?

[Ludovic Courtès]

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:
>   * the program is a script but its interpreter (eg. /bin/sh) was not found;
>   * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
>   * the program is a foreign binary but qemu was not specified;
>   * qemu does not work correctly (if specified);
>   * the loader was not found or doesn't work.
> fatal error: see `proot --help`.
> proot error: can't chmod '/tmp/proot-12809-PB78qJ': No such file or directory

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

HTH,
Ludo’.

Re: “guix pack -RR r“ fails?

[zimoun]

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 my experience you need
> at least 2G of memory available.

Thank you for sharing.  I am on the master node and launched as a
regular user (not tried as root).

If I understand correctly, my issue should come from the kernel which is
too old and/or not compiled with the correct options.


All the best,
simon

Re: “guix pack -RR r“ fails?

[zimoun]

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 to open the manual and check which one is the default.

The result is the same with the default.


> Can you try ‘strace -f -s 500 -o log ./bin/R’ and send the tail of the
> ‘log’ file?

--8<---cut here---start->8---
$ 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:
  * the program is a script but its interpreter (eg. /bin/sh) was not found;
  * the program is an ELF but its interpreter (eg. ld-linux.so) was not found;
  * the program is a foreign binary but qemu was not specified;
  * qemu does not work correctly (if specified);
  * the loader was not found or doesn't work.
fatal error: see `proot --help`.
proot error: can't chmod '/tmp/proot-12809-PB78qJ': No such file or directory
--8<---cut here---end--->8---

and then the tail of ’log’:

--8<---cut here---start->8---
[..]
12809 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 1}], __WALL, NULL) = 12810
12809 ptrace(PTRACE_SYSCALL, 12810, 0, SIG_0) = -1 ESRCH (No such process)
12809 wait4(-1, 0x7ffe63a965cc, __WALL, NULL) = -1 ECHILD (No child processes)
12809 stat(".", {st_mode=S_IFDIR|0775, st_size=3864, ...}) = 0
12809 stat("/data2/tmp/foo", {st_mode=S_IFDIR|0775, st_size=3864, ...}) = 0
12809 chmod("/tmp/proot-12809-PB78qJ", 0700) = -1 ENOENT (No such file or 
directory)
12809 write(2, "proot error: ", 13) = 13
12809 write(2, "can't chmod '/tmp/proot-12809-PB78qJ'", 37) = 37
12809 write(2, ": ", 2) = 2
12809 write(2, "No such file or directory\n", 26) = 26
12809 chdir("/data2/tmp/foo")   = 0
12809 exit_group(1) = ?
--8<---cut here---end--->8---




>> The cluster machine is an old kernel:
>>
>> 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
>
> Our libc is built with ‘--enable-kernel=3.2.0’ so it’s not clear whether
> this can work at all (this ‘2.6’ kernel certainly contains stuff
> backported from 3.x though, who knows.)

Ok.  I will be annoyed if it does not work…


All the best,
simon

Re: “guix pack -RR r“ fails?

[Ludovic Courtès]

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"
>
> [...]
>
>  *** caught segfault ***
> address 0x7f44f4b11008, cause 'memory not mapped'

[...]

> Error: package or namespace load failed for 'grDevices' in dyn.load(file, 
> DLLpath = DLLpath, ...):
>  unable to load shared object 
> '/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so':
>   
> /gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so:
>  cannot open shared object file: Bad address
> Error: package or namespace load failed for 'graphics' in dyn.load(file, 
> DLLpath = DLLpath, ...):
>  unable to load shared object 
> '/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so':
>   
> /gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so:
>  cannot open shared object file: Bad address
> Error: package or namespace load failed for 'stats' in dyn.load(file, DLLpath 
> = DLLpath, ...):
>  unable to load shared object 
> '/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so':

Can you try ‘strace -f -s 500 -o log ./bin/R’ and send the tail of the
‘log’ file?

> The cluster machine is an old kernel:
>
> 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

Our libc is built with ‘--enable-kernel=3.2.0’ so it’s not clear whether
this can work at all (this ‘2.6’ kernel certainly contains stuff
backported from 3.x though, who knows.)

HTH,
Ludo’.

Re: “guix pack -RR r“ fails?

[Roel Janssen]

Hi Simon,

On Wed, 2020-11-04 at 19:13 +0100, zimoun wrote:
> Dear,
> 
> Using Guix fd0ef0e, I run:
> 
> --8<---cut here---start->8---
> rsync -av --progress    \
>   $(guix pack -RR --save-provenance \
>   -S /bin=bin   \
>   -S /etc=etc   \
>   -S /include=include   \
>   -S /lib=lib   \
>   -S /share=share   \
>   -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<---cut here---start->8---
> $ ls -ahl
> total 422M
> drwxrwxr-x   3 sitour sitour 3.8K Nov  4 19:05 .
> drwxrwxrwx. 15 root   root   3.8K Nov  4 19:02 ..
> -r--r--r--   1 sitour sitour 421M Jan  1  1970
> 5n55mgjcj33s700g91x0zzf3ngflnba7-tarball-pack.tar.gz
> lrwxrwxrwx   1 sitour sitour   54 Nov  4 19:05 bin ->
> gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/bin
> lrwxrwxrwx   1 sitour sitour   54 Nov  4 19:05 etc ->
> gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/etc
> drwxrwxr-x   3 sitour sitour 3.8K Nov  4 19:03 gnu
> lrwxrwxrwx   1 sitour sitour   58 Nov  4 19:05 include ->
> gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/include
> lrwxrwxrwx   1 sitour sitour   54 Nov  4 19:05 lib ->
> gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/lib
> lrwxrwxrwx   1 sitour sitour   56 Nov  4 19:05 share ->
> gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/share
> lrwxrwxrwx   1 sitour sitour   63 Nov  4 19:05 site-library ->
> gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/site-library
> --8<---cut here---end--->8---
> 
> The usual ‘./bin/R’ fails with:
> 
> --8<---cut here---start->8---
> $ ./bin/R
> : unsupported Guix execution engine; ignoring
> ./bin/R
> R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
> 
> [...]
> 
>  *** caught segfault ***
> address 0x7f44f4b11008, cause 'memory not mapped'
> --8<---cut here---end--->8---
> 
> and then has to be killed.  Last,
> 
> --8<---cut here---start->8---
> $ gdb ./bin/R
> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-92.el6)
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from
> /data2/tmp/foo/gnu/store/yz0zww6i4pafvwh6ysmqxr5pm72ks7lv-r-minimal-
> 4.0.3R/bin/R...(no debugging symbols found)...done.
> (gdb) run
> Starting program:
> /data2/tmp/foo/gnu/store/yz0zww6i4pafvwh6ysmqxr5pm72ks7lv-r-minimal-
> 4.0.3R/bin/R 
> : unsupported Guix execution engine; ignoring
> /data2/tmp/foo/gnu/store/yz0zww6i4pafvwh6ysmqxr5pm72ks7lv-r-minimal-
> 4.0.3R/bin/Rprocess 36927 is executing new program:
> /data2/tmp/foo/gnu/store/jwdvnklncaqw15376vbbr1vgpfr17j18-proot-
> static-5.1.0/bin/proot
> Detaching after fork from child process 36930.
> 
> R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
> Copyright (C) 2020 The R Foundation for Statistical Computing
> Platform: x86_64-unknown-linux-gnu (64-bit)
> 
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
> 
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
> 
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
> 
> Error: package or namespace load failed for 'grDevices' in
> dyn.load(file, DLLpath = DLLpath, ...):
>  unable to load shared object
> '/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-
> 4.0.3/lib/R/library/grDevices/libs/grDevices.so':
>   /gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-
> 4.0.3/lib/R/libra

“guix pack -RR r“ fails?

[zimoun]

Dear,

Using Guix fd0ef0e, I run:

--8<---cut here---start->8---
rsync -av --progress\
  $(guix pack -RR --save-provenance \
  -S /bin=bin   \
  -S /etc=etc   \
  -S /include=include   \
  -S /lib=lib   \
  -S /share=share   \
  -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<---cut here---start->8---
$ ls -ahl
total 422M
drwxrwxr-x   3 sitour sitour 3.8K Nov  4 19:05 .
drwxrwxrwx. 15 root   root   3.8K Nov  4 19:02 ..
-r--r--r--   1 sitour sitour 421M Jan  1  1970 
5n55mgjcj33s700g91x0zzf3ngflnba7-tarball-pack.tar.gz
lrwxrwxrwx   1 sitour sitour   54 Nov  4 19:05 bin -> 
gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/bin
lrwxrwxrwx   1 sitour sitour   54 Nov  4 19:05 etc -> 
gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/etc
drwxrwxr-x   3 sitour sitour 3.8K Nov  4 19:03 gnu
lrwxrwxrwx   1 sitour sitour   58 Nov  4 19:05 include -> 
gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/include
lrwxrwxrwx   1 sitour sitour   54 Nov  4 19:05 lib -> 
gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/lib
lrwxrwxrwx   1 sitour sitour   56 Nov  4 19:05 share -> 
gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/share
lrwxrwxrwx   1 sitour sitour   63 Nov  4 19:05 site-library -> 
gnu/store/fvvn6mc4s7p52frdlsfj502k4zbqb9j7-profile/site-library
--8<---cut here---end--->8---

The usual ‘./bin/R’ fails with:

--8<---cut here---start->8---
$ ./bin/R
: unsupported Guix execution engine; ignoring
./bin/R
R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"

[...]

 *** caught segfault ***
address 0x7f44f4b11008, cause 'memory not mapped'
--8<---cut here---end--->8---

and then has to be killed.  Last,

--8<-------cut here---start->8---
$ gdb ./bin/R
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-92.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from 
/data2/tmp/foo/gnu/store/yz0zww6i4pafvwh6ysmqxr5pm72ks7lv-r-minimal-4.0.3R/bin/R...(no
 debugging symbols found)...done.
(gdb) run
Starting program: 
/data2/tmp/foo/gnu/store/yz0zww6i4pafvwh6ysmqxr5pm72ks7lv-r-minimal-4.0.3R/bin/R
 
: unsupported Guix execution engine; ignoring
/data2/tmp/foo/gnu/store/yz0zww6i4pafvwh6ysmqxr5pm72ks7lv-r-minimal-4.0.3R/bin/Rprocess
 36927 is executing new program: 
/data2/tmp/foo/gnu/store/jwdvnklncaqw15376vbbr1vgpfr17j18-proot-static-5.1.0/bin/proot
Detaching after fork from child process 36930.

R version 4.0.3 (2020-10-10) -- "Bunny-Wunnies Freak Out"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

Error: package or namespace load failed for 'grDevices' in dyn.load(file, 
DLLpath = DLLpath, ...):
 unable to load shared object 
'/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so':
  
/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so:
 cannot open shared object file: Bad address
Error: package or namespace load failed for 'graphics' in dyn.load(file, 
DLLpath = DLLpath, ...):
 unable to load shared object 
'/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so':
  
/gnu/store/nqqhaz59gdr5q6mb6mw9dd8jk133rna2-r-minimal-4.0.3/lib/R/library/grDevices/libs/grDevices.so:
 cannot open shared object file: Bad address
Error: package or namespace load failed for 'stats' in dyn.load(file, DLLpath = 
DLLpath, ...):
 unable to load shared obje

Re: branch master updated: gnu: Add r-bisquerna.

[zimoun]

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).  It’s not
> > supremely important, but I think in the long term we’d like to have
> > CRAN
> > things in (gnu packages cran) and Bioconductor things in (gnu
> > packages
> > bioconductor), because it’s deliciously unsurprising. :)
>
> I fully agree that it would be nice to have all packages originating
> from CRAN in (gnu packages cram) and all things Bioconductor in (gnu
> packages bioconductor).

I have tried to move almost all the CRAN remaining from (gnu packages
bioinformatics) graphs and machine-learning in 43345
<http://issues.guix.gnu.org/issue/43345>.  Now, still missing the
Bioconductor ones.  And the *big* statistics...

Cheers,
simon

Re: branch master updated: gnu: Add r-useful.

[Roel Janssen]

On Wed, 2020-09-09 at 18:05 +0200, Ricardo Wurmus wrote:
> 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 described below
> > 
> > commit a9401b4c948552d6a5a95bbd295e61871f4c6d74
> > Author: Roel Janssen 
> > AuthorDate: Wed Sep 9 16:59:42 2020 +0200
> > 
> > gnu: Add r-useful.
> > 
> > * gnu/packages/cran.scm (r-useful): New variable.
> > ---
> >  gnu/packages/cran.scm | 30 ++
> >  1 file changed, 30 insertions(+)
> > 
> > diff --git a/gnu/packages/cran.scm b/gnu/packages/cran.scm
> > index 3b13bbd..8f7e379 100644
> > --- a/gnu/packages/cran.scm
> > +++ b/gnu/packages/cran.scm
> > @@ -3724,6 +3724,36 @@ algorithm.  The interface of @code{ucminf}
> > is designed for easy interchange
> >  with the package @code{optim}.")
> >  (license license:gpl2+)))
> >  
> > +(define-public r-useful
> > +  (package
> > +   (name "r-useful")
> > +   (version "1.2.6")
> > +   (source (origin
> > +(method url-fetch)
> > +    (uri (cran-uri "useful" version))
> > +    (sha256
> > +     (base32
> > +      "0n50v1q75k518sq23id14jphwla35q4sasahrnrnllwrachl67v
> > 1"
> > +   (properties `((upstream-name . "useful")))
> > +   (build-system r-build-system)
> > +   (propagated-inputs
> > +`(("r-assertthat" ,r-assertthat)
> > +  ("r-dplyr" ,r-dplyr)
> > +  ("r-ggplot2" ,r-ggplot2)
> > +  ("r-magrittr" ,r-magrittr)
> > +  ("r-matrix" ,r-matrix)
> > +  ("r-plyr" ,r-plyr)
> > +  ("r-purrr" ,r-purrr)
> > +  ("r-scales" ,r-scales)))
> > +   (home-page "https://github.com/jaredlander/useful;)
> > +   (synopsis "A Collection of Handy, Useful Functions")
> 
> “guix lint” should have complained about the leading “A”.  Please
> also
> use lowercase.

Fixed in 811985a7e0b8e7aad5a3c3818482b06996c94d02.

Kind regards,
Roel Janssen

Re: branch master updated: gnu: Add r-bisquerna.

[Roel Janssen]

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")
> > > > +   (source (origin
> > > > +(method url-fetch)
> > > > +(uri (cran-uri "BisqueRNA" version))
> > > > +(sha256
> > > > + (base32
> > > > +  "01g34n87ml7n3pck77497ddgbv3rr5p4153ac8ninpgjijl
> > > > m3jw
> > > > 2"
> > > 
> > > Why is this in (gnu packages bioinformatics) and not in (gnu
> > > packages
> > > cran)?
> > 
> > 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 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
> things in (gnu packages cran) and Bioconductor things in (gnu
> packages
> bioconductor), because it’s deliciously unsurprising. :)

I fully agree that it would be nice to have all packages originating
from CRAN in (gnu packages cram) and all things Bioconductor in (gnu
packages bioconductor).

I moved r-bisquerna and lowercased its synopsis in
66be746dc0c0f4ba3d748ed8d0983b2f9afdace8.

Kind regards,
Roel Janssen

Re: branch master updated: gnu: Add r-bisquerna.

[Ricardo Wurmus]

zimoun  writes:

> 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 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
>> things in (gnu packages cran) and Bioconductor things in (gnu packages
>> bioconductor), because it’s deliciously unsurprising. :)
>
> I agree.  And it is also on my TODO but the Copyright lines lead to a
> boring task. :-)

It becomes a little easier with “git log --grep=package-name”.

> Does it make sense to add a subsection to:
> https://guix.gnu.org/manual/devel/en/guix.html#Packaging-Guidelines
> about R packages?

Perhaps not.  I think it may not be necessary because we don’t have that
many people contributing R packages to us and the manual already has a
lot of information that might be overwhelming.

So far we’ve been doing fine without it.  It’s a really minor point, in
my opinion.

-- 
Ricardo

Re: branch master updated: gnu: Add r-loomr.

[Ricardo Wurmus]

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

Re: branch master updated: gnu: Add r-loomr.

[zimoun]

On Thu, 10 Sep 2020 at 12:40, Ricardo Wurmus  wrote:

> > Where would I add a non-CRAN and non-Bioconductor package to?  Perhaps
> > this situation won't occur again, and should raise a flag, because I
> > think I've never had this case before.
>
> We don’t have 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.scm or machine-learning.scm or
name-it.scm.

However, some dependency issues could happen, and e.g., CRAN package
could be in bioconductor.scm as r-deconstructsigs -- with a comment.

Last, should CRAN packages in statistics.scm go in cran..scm or not?


All the best,
simon

Re: branch master updated: gnu: Add r-bisquerna.

[zimoun]

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 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
> things in (gnu packages cran) and Bioconductor things in (gnu packages
> bioconductor), because it’s deliciously unsurprising. :)

I agree.  And it is also on my TODO but the Copyright lines lead to a
boring task. :-)

Does it make sense to add a subsection to:
https://guix.gnu.org/manual/devel/en/guix.html#Packaging-Guidelines
about R packages?

Cheers,
simon

Re: branch master updated: gnu: Add r-bisquerna.

[Ricardo Wurmus]

Roel Janssen  writes:

>> > +(define-public r-bisquerna
>> > +  (package
>> > +   (name "r-bisquerna")
>> > +   (version "1.0.4")
>> > +   (source (origin
>> > +(method url-fetch)
>> > +(uri (cran-uri "BisqueRNA" version))
>> > +(sha256
>> > + (base32
>> > +  "01g34n87ml7n3pck77497ddgbv3rr5p4153ac8ninpgjijlm3jw
>> > 2"
>> 
>> Why is this in (gnu packages bioinformatics) and not in (gnu packages
>> cran)?
>
> 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 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
things in (gnu packages cran) and Bioconductor things in (gnu packages
bioconductor), because it’s deliciously unsurprising. :)

>> > +   (synopsis "Decomposition of Bulk Expression with Single-Cell
>> > Sequencing")
>> 
>> Please use lowercase where it would be normally used.
>
> My mistake. I will take better care of this in the future.

Thank you!

Perhaps we could sprinkle some smarts over the CRAN importer to do this
automatically, but with R packages we often have names of methods that
should be upper case (like “Bayes*” or “SNPs”), so I have shied away
from developing heuristics for that.

Thanks for adding more R packages!

-- 
Ricardo

Re: branch master updated: gnu: Add r-bisquerna.

[Roel Janssen]

Hi Ricardo,

On Wed, 2020-09-09 at 18:04 +0200, Ricardo Wurmus wrote:
> 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.
> > 0574446 is described below
> > 
> > commit 0574446be82ef54b925441e4283bf754a86918a9
> > Author: Roel Janssen 
> > AuthorDate: Wed Sep 9 17:02:55 2020 +0200
> > 
> > gnu: Add r-bisquerna.
> > 
> > * gnu/packages/bioinformatics.scm (r-bisquerna): New variable.
> > ---
> >  gnu/packages/bioinformatics.scm | 25 +
> >  1 file changed, 25 insertions(+)
> > 
> > diff --git a/gnu/packages/bioinformatics.scm
> > b/gnu/packages/bioinformatics.scm
> > index f8792ef..9f2fd86 100644
> > --- a/gnu/packages/bioinformatics.scm
> > +++ b/gnu/packages/bioinformatics.scm
> > @@ -7923,6 +7923,31 @@ manipulating genomic intervals and variables
> > defined along a genome.")
> >  on Bioconductor or which replace R functions.")
> >  (license license:artistic2.0)))
> >  
> > +(define-public r-bisquerna
> > +  (package
> > +   (name "r-bisquerna")
> > +   (version "1.0.4")
> > +   (source (origin
> > +(method url-fetch)
> > +(uri (cran-uri "BisqueRNA" version))
> > +(sha256
> > + (base32
> > +  "01g34n87ml7n3pck77497ddgbv3rr5p4153ac8ninpgjijlm3jw
> > 2"
> 
> Why is this in (gnu packages bioinformatics) and not in (gnu packages
> cran)?

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?

> > +   (synopsis "Decomposition of Bulk Expression with Single-Cell
> > Sequencing")
> 
> Please use lowercase where it would be normally used.

My mistake. I will take better care of this in the future.

Kind regards,
Roel Janssen

Re: branch master updated: gnu: Add r-loomr.

[Ricardo Wurmus]

Roel Janssen  writes:

>> > commit 1f56ec08af704bdc7aa3e143bf5ce351c5306dea
>> > Author: Roel Janssen 
>> > AuthorDate: Wed Sep 9 16:56:02 2020 +0200
>> > 
>> > gnu: Add r-loomr.
>> > 
>> > * gnu/packages/bioinformatics.scm (r-loomr): New variable.
>> 
>> This is not free software.  See
>> 
>>https://github.com/mojaveazure/loomR/pull/24
>
>
> Oh shoot. I'm sorry I didn't see this discussion!

It’s really not obvious.  I know because it happened to me too.  In 2018
I added r-loomr with commit fab43c6b84635200070c708d4220132be18dd239.
Then in 2019 I removed it with commit
bc70516bbae8a6388f3ed19008d3e10efd1577a7 after noticing that the author
only used GPL in the DESCRIPTION file to stop the CRAN tools from
complaining.

It’s definitely unusual and very easy to miss.

>> Aside from this, I would like to say two things:
>> 
>> >  gnu/packages/bioinformatics.scm | 26 ++
>> 
>> Let’s please not add R packages to (gnu packages bioinformatics) when
>> it
>> can be avoided.  (In this case there’s no CRAN package, so it’s
>> fine.)
>
> Where would I add a non-CRAN and non-Bioconductor package to?  Perhaps
> this situation won't occur again, and should raise a flag, because I
> think I've never had this case before.

We don’t have 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.

> I will default to submitting patches to guix-patches again.  I thought
> it was trivial enough to just push.  My mistake.

I’d say if it’s on CRAN you can go ahead and push directly (after
running “guix lint” to catch some obvious mistakes).  Bioconductor
packages need a little extra care because they are sometimes playing
loose with licenses and included third-party code; but if you feel
you’ve checked things carefully then you can also push those directly.

For third-party R packages we don’t benefit from even the little bit of
quality control that CRAN and Bioconductor impose, so we need to be
extra careful.  There it helps to send patches to guix-patches and push
them after some time.

-- 
Ricardo

Re: branch master updated: gnu: Add r-loomr.

[Roel Janssen]

Hi Ricardo,


On Wed, 2020-09-09 at 18:02 +0200, Ricardo Wurmus wrote:
> 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 described below
> > 
> > commit 1f56ec08af704bdc7aa3e143bf5ce351c5306dea
> > Author: Roel Janssen 
> > AuthorDate: Wed Sep 9 16:56:02 2020 +0200
> > 
> > gnu: Add r-loomr.
> > 
> > * gnu/packages/bioinformatics.scm (r-loomr): New variable.
> 
> This is not free software.  See
> 
>https://github.com/mojaveazure/loomR/pull/24


Oh shoot. I'm sorry I didn't see this discussion!


> Aside from this, I would like to say two things:
> 
> >  gnu/packages/bioinformatics.scm | 26 ++
> 
> Let’s please not add R packages to (gnu packages bioinformatics) when
> it
> can be avoided.  (In this case there’s no CRAN package, so it’s
> fine.)

Where would I add a non-CRAN and non-Bioconductor package to?  Perhaps
this situation won't occur again, and should raise a flag, because I
think I've never had this case before.

> > +(define-public r-loomr
> > +  (package
> > +   (name "r-loomr")
> > +   (version "0.2.0-beta")
> > +   (source (origin
> > +(method url-fetch)
> > +(uri (string-append
> > +  "https://github.com/mojaveazure/loomR/archive/;
> > +  version ".tar.gz"))
> 
> This is not okay as these generated tarballs are not stable.  I
> haven’t
> seen these patches on guix-patches before — maybe I missed them.  But
> we
> have been avoiding these kind of URLs since a long time and had I
> seen
> the patches on guix-patches I and other would probably have pointed
> this
> out.
> 
> Can you please revert this ASAP?

I see you've reverted it already. Thanks for that!

I will default to submitting patches to guix-patches again.  I thought
it was trivial enough to just push.  My mistake.

Kind regards,
Roel Janssen

Re: branch master updated: gnu: Add r-useful.

[Ricardo Wurmus]

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 described below
>
> commit a9401b4c948552d6a5a95bbd295e61871f4c6d74
> Author: Roel Janssen 
> AuthorDate: Wed Sep 9 16:59:42 2020 +0200
>
> gnu: Add r-useful.
> 
> * gnu/packages/cran.scm (r-useful): New variable.
> ---
>  gnu/packages/cran.scm | 30 ++
>  1 file changed, 30 insertions(+)
>
> diff --git a/gnu/packages/cran.scm b/gnu/packages/cran.scm
> index 3b13bbd..8f7e379 100644
> --- a/gnu/packages/cran.scm
> +++ b/gnu/packages/cran.scm
> @@ -3724,6 +3724,36 @@ algorithm.  The interface of @code{ucminf} is designed 
> for easy interchange
>  with the package @code{optim}.")
>  (license license:gpl2+)))
>  
> +(define-public r-useful
> +  (package
> +   (name "r-useful")
> +   (version "1.2.6")
> +   (source (origin
> +(method url-fetch)
> +(uri (cran-uri "useful" version))
> +(sha256
> + (base32
> +  "0n50v1q75k518sq23id14jphwla35q4sasahrnrnllwrachl67v1"
> +   (properties `((upstream-name . "useful")))
> +   (build-system r-build-system)
> +   (propagated-inputs
> +`(("r-assertthat" ,r-assertthat)
> +  ("r-dplyr" ,r-dplyr)
> +  ("r-ggplot2" ,r-ggplot2)
> +  ("r-magrittr" ,r-magrittr)
> +  ("r-matrix" ,r-matrix)
> +  ("r-plyr" ,r-plyr)
> +  ("r-purrr" ,r-purrr)
> +  ("r-scales" ,r-scales)))
> +   (home-page "https://github.com/jaredlander/useful;)
> +   (synopsis "A Collection of Handy, Useful Functions")

“guix lint” should have complained about the leading “A”.  Please also
use lowercase.

-- 
Ricardo

Re: branch master updated: gnu: Add r-bisquerna.

[Ricardo Wurmus]

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.
> 0574446 is described below
>
> commit 0574446be82ef54b925441e4283bf754a86918a9
> Author: Roel Janssen 
> AuthorDate: Wed Sep 9 17:02:55 2020 +0200
>
> gnu: Add r-bisquerna.
>     
> * gnu/packages/bioinformatics.scm (r-bisquerna): New variable.
> ---
>  gnu/packages/bioinformatics.scm | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/gnu/packages/bioinformatics.scm b/gnu/packages/bioinformatics.scm
> index f8792ef..9f2fd86 100644
> --- a/gnu/packages/bioinformatics.scm
> +++ b/gnu/packages/bioinformatics.scm
> @@ -7923,6 +7923,31 @@ manipulating genomic intervals and variables defined 
> along a genome.")
>  on Bioconductor or which replace R functions.")
>  (license license:artistic2.0)))
>  
> +(define-public r-bisquerna
> +  (package
> +   (name "r-bisquerna")
> +   (version "1.0.4")
> +   (source (origin
> +(method url-fetch)
> +(uri (cran-uri "BisqueRNA" version))
> +(sha256
> + (base32
> +  "01g34n87ml7n3pck77497ddgbv3rr5p4153ac8ninpgjijlm3jw2"

Why is this in (gnu packages bioinformatics) and not in (gnu packages
cran)?

> +   (synopsis "Decomposition of Bulk Expression with Single-Cell
> Sequencing")

Please use lowercase where it would be normally used.

-- 
Ricardo

Re: branch master updated: gnu: Add r-loomr.

[Ricardo Wurmus]

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 described below
>
> commit 1f56ec08af704bdc7aa3e143bf5ce351c5306dea
> Author: Roel Janssen 
> AuthorDate: Wed Sep 9 16:56:02 2020 +0200
>
> gnu: Add r-loomr.
>     
> * gnu/packages/bioinformatics.scm (r-loomr): New variable.

This is not free software.  See

   https://github.com/mojaveazure/loomR/pull/24

Aside from this, I would like to say two things:

>  gnu/packages/bioinformatics.scm | 26 ++

Let’s please not add R packages to (gnu packages bioinformatics) when it
can be avoided.  (In this case there’s no CRAN package, so it’s fine.)

> +(define-public r-loomr
> +  (package
> +   (name "r-loomr")
> +   (version "0.2.0-beta")
> +   (source (origin
> +(method url-fetch)
> +(uri (string-append
> +  "https://github.com/mojaveazure/loomR/archive/;
> +  version ".tar.gz"))

This is not okay as these generated tarballs are not stable.  I haven’t
seen these patches on guix-patches before — maybe I missed them.  But we
have been avoiding these kind of URLs since a long time and had I seen
the patches on guix-patches I and other would probably have pointed this
out.

Can you please revert this ASAP?

-- 
Ricardo

Re: Building R Packages

[sirgazil]

  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: `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 commands shown in 
 > https://guix.gnu.org/videos/packaging,-part-one/index.html before running 
 > "./pre-inst-env"?
 >  > 
 > 
 > Actually, I just pull the guix repository and make fails with the following 
 > error (other people on #guix see the same error):

Daniela, just in case you are not subscribed to the guix-devel list, someone 
else reported the issue and there is a workaround in the following message:

https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00341.html

I saw several warnings during the process, but after "make" finished I could 
run guix commands prepending them with "./pre-inst-env".

Hope that helps.

Re: Building R Packages

[sirgazil]

  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 another shell and it can't recognize pre-inst-env. 
 > 
 > Did you run the recommended commands shown in 
 > https://guix.gnu.org/videos/packaging,-part-one/index.html before running 
 > "./pre-inst-env"?
 > 

Actually, I just pull the guix repository and make fails with the following 
error (other people on #guix see the same error):

$ make
  GEN  doc/os-config-bare-bones.texi
  GEN  doc/os-config-desktop.texi
  GEN  doc/os-config-lightweight-desktop.texi
  PO4A doc/contributing.de.texi
Your input po file po/doc/guix-manual.de.po seems outdated (The amount of 
entries differ between files: 8727 is not 298
). Please consider running po4a-updatepo to refresh it.
  POXREF doc/contributing.de.texi
mv "doc/contributing.de.texi.tmp" "doc/contributing.de.texi"
  PO4A doc/guix.de.texi
Your input po file po/doc/guix-manual.de.po seems outdated (The amount of 
entries differ between files: 8727 is not 8512
). Please consider running po4a-updatepo to refresh it.
sed -i "s|guix\.info|$(basename "doc/guix.de.texi" | sed 's|texi$|info|')|" 
"doc/guix.de.texi.tmp"
  POXREF doc/guix.de.texi
mv "doc/guix.de.texi.tmp" "doc/guix.de.texi"
  PO4A doc/contributing.es.texi
Your input po file po/doc/guix-manual.es.po seems outdated (The amount of 
entries differ between files: 8727 is not 298
). Please consider running po4a-updatepo to refresh it.
  POXREF doc/contributing.es.texi
mv "doc/contributing.es.texi.tmp" "doc/contributing.es.texi"
  PO4A doc/guix.es.texi
Your input po file po/doc/guix-manual.es.po seems outdated (The amount of 
entries differ between files: 8727 is not 8512
). Please consider running po4a-updatepo to refresh it.
sed -i "s|guix\.info|$(basename "doc/guix.es.texi" | sed 's|texi$|info|')|" 
"doc/guix.es.texi.tmp"
  POXREF doc/guix.es.texi
mv "doc/guix.es.texi.tmp" "doc/guix.es.texi"
  PO4A doc/contributing.fr.texi
Your input po file po/doc/guix-manual.fr.po seems outdated (The amount of 
entries differ between files: 7994 is not 298
). Please consider running po4a-updatepo to refresh it.
  POXREF doc/contributing.fr.texi
mv "doc/contributing.fr.texi.tmp" "doc/contributing.fr.texi"
  PO4A doc/guix.fr.texi
Your input po file po/doc/guix-manual.fr.po seems outdated (The amount of 
entries differ between files: 7994 is not 8512
). Please consider running po4a-updatepo to refresh it.
sed -i "s|guix\.info|$(basename "doc/guix.fr.texi" | sed 's|texi$|info|')|" 
"doc/guix.fr.texi.tmp"
  POXREF doc/guix.fr.texi
mv "doc/guix.fr.texi.tmp" "doc/guix.fr.texi"
  PO4A doc/contributing.ru.texi
Your input po file po/doc/guix-manual.ru.po seems outdated (The amount of 
entries differ between files: 8727 is not 298
). Please consider running po4a-updatepo to refresh it.
  POXREF doc/contributing.ru.texi
mv "doc/contributing.ru.texi.tmp" "doc/contributing.ru.texi"
  PO4A doc/guix.ru.texi
Your input po file po/doc/guix-manual.ru.po seems outdated (The amount of 
entries differ between files: 8727 is not 8512
). Please consider running po4a-updatepo to refresh it.
sed -i "s|guix\.info|$(basename "doc/guix.ru.texi" | sed 's|texi$|info|')|" 
"doc/guix.ru.texi.tmp"
  POXREF doc/guix.ru.texi
mv "doc/guix.ru.texi.tmp" "doc/guix.ru.texi"
  PO4A doc/contributing.zh_CN.texi
Your input po file po/doc/guix-manual.zh_CN.po seems outdated (The amount of 
entries differ between files: 7994 is not 298
). Please consider running po4a-updatepo to refresh it.
  POXREF doc/contributing.zh_CN.texi
mv "doc/contributing.zh_CN.texi.tmp" "doc/contributing.zh_CN.texi"
  PO4A doc/guix.zh_CN.texi
Your input po file po/doc/guix-manual.zh_CN.po seems outdated (The amount of 
entries differ between files: 7994 is not 8512
). Please consider running po4a-updatepo to refresh it.
sed -i "s|guix\.info|$(basename "doc/guix.zh_CN.texi" | sed 's|texi$|info|')|" 
"doc/guix.zh_CN.texi.tmp"
  POXREF doc/guix.zh_CN.texi
mv "doc/guix.zh_CN.texi.tmp" "doc/guix.zh_CN.texi"
  GEN  nix/libstore/schema.sql.hh
echo UNKNOWN > ".version-t" && mv ".version-t" ".version"
make  all-recursive
make[1]: Entering directory '/home/sirgazil/Documentos/guix'
Making all in po/guix
make[2]: Entering directory '/home/sirgazil/Documentos/guix/po/guix'
make guix.pot-update
make[3]: Entering directory '/home/sirgazil/Documentos/guix/po/guix'
sed -e '/^#/d' remove-potcdate.sin > t-remove-potcdate.sed
mv t-remove-potcdate.sed remove-potcdate.sed
if LC_ALL=C grep 'GNU guix' ../../* 2>/dev/null | grep -v 'libtool:' 
>/dev/null; then \
  package_gnu='GNU '; \
else \
  package_gnu=''; \
fi; \
if test -n 'l...@gnu.org' || test 'bug-g...@gnu.org' = '@'PACKAGE_BUGREPORT'@'; 
then \
  msgid_bugs_address='l...@gnu.org'; \
else \
  msgid_bugs_address='bug-g...@gnu.org'; \
fi; \
case 

Re: Building R Packages

[sirgazil]

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 commands shown in 
https://guix.gnu.org/videos/packaging,-part-one/index.html before running 
"./pre-inst-env"?

Re: Building R Packages

[Daniela Lura]

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 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 Guix.  Your modifications will be seen by this command after
> you submit a patch, it is committed, then you update your installed
> version with a 'guix pull'.
>
> Best regards,
>
> Paul.
>
>

Re: Building R Packages

[Paul Garlick]

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 Guix.  Your modifications will be seen by this command after
you submit a patch, it is committed, then you update your installed
version with a 'guix pull'.

Best regards,

Paul.

Building R Packages

[Daniela Lura]

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_PATH and running `guix build ` again, I get this
message: guix build: error: r-oenb: unknown package,  and I can't seem to
grasp the reason because I have already added the package definition to
gnu/packages/cran.scm.

Any assistance you can provide would be greatly appreciated.

Regards,

Dan

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Gábor Boskovits]

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:48:05AM +0100, Gábor Boskovits wrote:
> > > >Hello,
> > > >Veera <[1]v...@vkten.in> 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:
> > > >  >
> > > >  > To get started you should install guix. For this project it
> might
> > > >  make
> > > >  > sense to install guix system also. You should also set up a
> guix
> > > >  > development environment, by checking out the source code, and
> > > >  building it.
> > > >  >
> > > >  I am installing GuixSD.
> > > >
> > > >How did the install go?
> > > >Could you do it? Please feel free to reach out to me should you
> have
> > > >any questions.
> > > >
> > >
> > > Install from ISO did not go well. Could not complete install.
> > >
> >
> > What went wrong with the iso?
> > Did you try the guided on the manual install?
> > Was this on a VM or in bare metal?
> >
>
> oops in bochs_drm video module actually some depended bo_ttm module.
> There were kernel trap faults occurred as seen in dmesg.
>
> >
> > > So I tried VM img install and it is successfull.
> > >
> >
> > I am glad that you have a working system. Please check if you have enough
> > disk space, as the default VM image is small. It should be extended
> before
> > use.
> >
> > Now I am reading docs about guix. And how to get my way around.
> > >
> >
> > Great. The next step to 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 sources. And then building it. As in other distros is it
> possible to just install binary buildtools and only download the source
> for needed pkgs and install them?
>

No. You will get binary substitutes for the build tools, and you will only
need the guix source repository from git.


> > >
> > > >  > 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
> > >
> > Best regards,
> > g_bor
> >
>
>
> Regards,
> Veera
>
Best regards,
g_bor

>

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[R Veera Kumar]

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:48:05AM +0100, Gábor Boskovits wrote:
> > >Hello,
> > >Veera <[1]v...@vkten.in> 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:
> > >  >
> > >  > To get started you should install guix. For this project it might
> > >  make
> > >  > sense to install guix system also. You should also set up a guix
> > >  > development environment, by checking out the source code, and
> > >  building it.
> > >  >
> > >  I am installing GuixSD.
> > >
> > >How did the install go?
> > >Could you do it? Please feel free to reach out to me should you have
> > >any questions.
> > >
> >
> > Install from ISO did not go well. Could not complete install.
> >
> 
> What went wrong with the iso?
> Did you try the guided on the manual install?
> Was this on a VM or in bare metal?
> 

oops in bochs_drm video module actually some depended bo_ttm module.
There were kernel trap faults occurred as seen in dmesg.

> 
> > So I tried VM img install and it is successfull.
> >
> 
> I am glad that you have a working system. Please check if you have enough
> disk space, as the default VM image is small. It should be extended before
> use.
> 
> Now I am reading docs about guix. And how to get my way around.
> >
> 
> Great. The next step to 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 sources. And then building it. As in other distros is it
possible to just install binary buildtools and only download the source
for needed pkgs and install them?

> >
> > >  > 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
> >
> Best regards,
> g_bor
> 


Regards,
Veera

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Gábor Boskovits]

Hello,

Veera  ezt írta (időpont: 2020. márc. 11., Sze 1:31):

> On Tue, Mar 10, 2020 at 08:48:05AM +0100, Gábor Boskovits wrote:
> >Hello,
> >Veera <[1]v...@vkten.in> 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:
> >  >
> >  > To get started you should install guix. For this project it might
> >  make
> >  > sense to install guix system also. You should also set up a guix
> >  > development environment, by checking out the source code, and
> >  building it.
> >  >
> >  I am installing GuixSD.
> >
> >How did the install go?
> >Could you do it? Please feel free to reach out to me should you have
> >any questions.
> >
>
> Install from ISO did not go well. Could not complete install.
>

What went wrong with the iso?
Did you try the guided on the manual install?
Was this on a VM or in bare metal?


> So I tried VM img install and it is successfull.
>

I am glad that you have a working system. Please check if you have enough
disk space, as the default VM image is small. It should be extended before
use.

Now I am reading docs about guix. And how to get my way around.
>

Great. The next step to 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.

>
> >  > 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
>
Best regards,
g_bor

>

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Veera]

On Tue, Mar 10, 2020 at 08:48:05AM +0100, Gábor Boskovits wrote:
>Hello,
>Veera <[1]v...@vkten.in> 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:
>  >
>  > To get started you should install guix. For this project it might
>  make
>  > sense to install guix system also. You should also set up a guix
>  > development environment, by checking out the source code, and
>  building it.
>  >
>  I am installing GuixSD.
> 
>How did the install go?
>Could you do it? Please feel free to reach out to me should you have
>any questions.
> 

Install from ISO did not go well. Could not complete install.

So I tried VM img install and it is successfull.
Now I am reading docs about guix. And how to get my way 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

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Gábor Boskovits]

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 Veera Kumar from India. I have been selected as Outreachy
> applicant
> > > for May 2020 round.
> > >
> > Nice to see you around.
> >
>
> Thanks!
>
> >
> > >
> > > I have heard about Guix from news and have checked about it a little
> > > before.
> > > I do not know Scheme/Guile Language.
> > >
> > This is not a problem. I believe it can be picked up easily. This won't
> be
> > the biggest burden in the project.
> >
>
> Oh well.
>
> > >
> > > How do I get started?
> > > What contributions can I make?
> > >
> >
> > To get started you should install guix. For this project it might make
> > sense to install guix system also. You should also set up a guix
> > development environment, by checking out the source code, and building
> it.
> >
>
> I am installing GuixSD.
>

How did the install go?

Could you do it? Please feel free to reach out to me should you have any
questions.

>
> > 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.
> >
> > You can also check out http://issues.guix.gnu.org/easy and work on some
> > easy bugs.
> >
>
> Yes. I checked that.
>
> > Thanks for your interest. I hope that I could give you useful
> information.
> >
> > Best regards,
> > g_bor
> >
>
> Thanks for the welcome!
>
> Regards,
> Veera
>
Best regards,
G_bor

>

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Veera]

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.
> >
> Nice to see you around.
> 

Thanks!

> 
> >
> > I have heard about Guix from news and have checked about it a little
> > before.
> > I do not know Scheme/Guile Language.
> >
> This is not a problem. I believe it can be picked up easily. This won't be
> the biggest burden in the project.
> 

Oh well.

> >
> > How do I get started?
> > What contributions can I make?
> >
> 
> To get started you should install guix. For this project it might make
> sense to install guix system also. You should also set up a guix
> development environment, by checking out the source code, and building it.
> 

I am installing GuixSD.

> 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.
> 
> You can also check out http://issues.guix.gnu.org/easy and work on some
> easy bugs.
> 

Yes. I checked that.

> Thanks for your interest. I hope that I could give you useful information.
> 
> Best regards,
> g_bor
> 

Thanks for the welcome!

Regards,
Veera

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Gábor Boskovits]

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:
>  Guix Integration of desktop environments into GNU Guix
>
> I am a self taught computer and software user. I am a Linux user for 15
> years.
> I have used Redhat, Fedora, Debian and others. I have built
> Linuxfromscratch
> and Beyond LFS and used them for a custom distro for myself. I know some C,
> Shell, awk, Perl, Python, Lua and basic system administration.
>
That is impressive. It looks like we can also learn from you.

>
> I have heard about Guix from news and have checked about it a little
> before.
> I do not know Scheme/Guile Language.
>
This is not a problem. I believe it can be picked up easily. This won't be
the biggest burden in the project.

>
> How do I get started?
> What contributions can I make?
>

To get started you should install guix. For this project it might make
sense to install guix system also. You should also set up a guix
development environment, by checking out the source code, and building it.

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.

You can also check out http://issues.guix.gnu.org/easy and work on some
easy bugs.


> Thanks,
> R Veera Kumar
> mail: v...@vkten.in, veerakuma...@gmail.com
> India
>

Thanks for your interest. I hope that I could give you useful information.

Best regards,
g_bor

>
>

Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Veera]

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!
> Do you have a link to share the description of the assignment?
> 

It is a protected page.

> > I have heard about Guix from news and have checked about it a little before.
> > I do not know Scheme/Guile Language.
> 
> Since you are already familiar with programming, I suggest the book
> Structure and Interpretation of Computer Programming.
> It's available for free online:
> 
> https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book.html
> 
> With modern editing:
> 
> http://sarabander.github.io/sicp/
> 
> It's available as a Texinfo manual which is packaged in Guix.
> 

I will see it.

> Finally, the video recordings of the class are insightful and to the
> point:
> 
> https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book.html
> 
> Cheers!
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz/

Regards,
Veera

Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Veera]

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 years.
I have used Redhat, Fedora, Debian and others. I have built Linuxfromscratch
and Beyond LFS and used them for a custom distro for myself. I know some C,
Shell, awk, Perl, Python, Lua and basic system administration.

I have heard about Guix from news and have checked about it a little before.
I do not know Scheme/Guile Language.

How do I get started?
What contributions can I make?

Thanks,
R Veera Kumar
mail: v...@vkten.in, veerakuma...@gmail.com
India

Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Veera]

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 years.
I have used Redhat, Fedora, Debian and others. I have built Linuxfromscratch
and Beyond LFS and used them for a custom distro for myself. I know some C,
Shell, awk, Perl, Python, Lua and basic system administration.

I have heard about Guix from news and have checked about it a little before.
I do not know Scheme/Guile Language.

How do I get started?
What contributions can I make?

Thanks,
R Veera Kumar
mail: v...@vkten.in, veerakuma...@gmail.com
India

Hi, I am R Veera Kumar - Current Outreachy selected Applicant

[Veera]

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 years.
I have used Redhat, Fedora, Debian and others. I have built Linuxfromscratch
and Beyond LFS and used them for a custom distro for myself. I know some C,
Shell, awk, Perl, Python, Lua and basic system administration.

I have heard about Guix from news and have checked about it a little before.
I do not know Scheme/Guile Language.

How do I get started?
What contributions can I make?

Thanks,
R Veera Kumar
mail: v...@vkten.in, veerakuma...@gmail.com
India

Re: Move r-{desolve, quadprog, pracma, subplex} from maths.scm to cran.scm

[Ricardo Wurmus]

zimoun  writes:

> If I understand well, the policy is: the packages in the file cran.scm
> cannot import '(gnu packages bioconductor).

Yes.  It’s not official policy, but I think we should avoid mutually
recursive module imports when we have a choice.

> In the file cran.scm, for 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 also very easy to miss them
when doing mass upgrades, hidden among all these CRAN packages.

>> > 2.
>> > The second point is that the file statistics.scm contains 227 packages
>> > and 206 are cran-uri. And the file cran.scm already contains 602
>> > packages, so it will be almost as python-xyz.scm is. Why not. Then,
>> > this file statistics.scm will be almost empty and I propose instead to
>> > populate the files maths.scm, python-xyz.scm.
>> >
>> > What do you think?
>>
>> statistics.scm was the only thing we had for R in the beginning.  When
>> it grew and it became apparent that more and more CRAN packages would be
>> added, I felt that the module became less suitable.
>
> Sorry, my words was not good enough. I propose to remove the file
> statistics.scm by reordering the packages.

I think it’s fine to keep statistics.scm even when it’s small.  R and
pspp *are* stats packages after all, so this module remains the perfect
location for them.

>> I don’t understand your comment about “maths.scm” and “python-xyz.scm”.
>> I think it’s good to move CRAN and Bioconductor packages out of
>> statistics.scm whenever possible.  We can leave the actual statistics
>> programs there as well as potentially unmovable CRAN packages.
>
> In the file statistics.scm, once move to cran.scm or bioconductor.scm,
> there is few packages. For example 2 packages coming from PyPI and I
> propose to move them to the file python-xyz.scm. The other ones could
> be moved to the file maths.scm or the unamed (yet) file (see above).

I’d like to avoid moving anything *to* python-xyz.scm, because it’s a
bit of a dump.  I think it’s fine to just focus on the R packages for
now and address the rest later — if at all.

--
Ricardo

Re: Move r-{desolve, quadprog, pracma, subplex} from maths.scm to cran.scm

[zimoun]

Hi,

On Tue, 10 Dec 2019 at 09:41, Ricardo Wurmus  wrote:

> > --8<---cut here---start->8---
> > ;; This is a CRAN package, but it uncharacteristically depends on a
> > ;; Bioconductor package
> > --8<---cut here---end--->8---
> >
> > Do you remember a special motivation?
>
> Yes, the comments say why.  It’s very unusual for a CRAN package to
> depend on Bioconductor packages.  Usually, it is the other way around.
> I just didn’t want (gnu packages cran) to point 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 packages bioconductor).

In the file cran.scm, for 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?


> > 2.
> > The second point is that the file statistics.scm contains 227 packages
> > and 206 are cran-uri. And the file cran.scm already contains 602
> > packages, so it will be almost as python-xyz.scm is. Why not. Then,
> > this file statistics.scm will be almost empty and I propose instead to
> > populate the files maths.scm, python-xyz.scm.
> >
> > What do you think?
>
> statistics.scm was the only thing we had for R in the beginning.  When
> it grew and it became apparent that more and more CRAN packages would be
> added, I felt that the module became less suitable.

Sorry, my words was not good enough. I propose to remove the file
statistics.scm by reordering the packages.


> I don’t understand your comment about “maths.scm” and “python-xyz.scm”.
> I think it’s good to move CRAN and Bioconductor packages out of
> statistics.scm whenever possible.  We can leave the actual statistics
> programs there as well as potentially unmovable CRAN packages.

In the file statistics.scm, once move to cran.scm or bioconductor.scm,
there is few packages. For example 2 packages coming from PyPI and I
propose to move them to the file python-xyz.scm. The other ones could
be moved to the file maths.scm or the unamed (yet) file (see above).


> > 3.
> > It is a big move. Do you prefer
> >  - a commit per package, so more or less 300 commits?
> >  - or a commit bioconductor.scm->cran.scm, another
> > statistics.scm->cran.scm, bioinformatics.scm->bioconductor.scm and
> > bioconductor->bioinformatics.scm, etc.?
>
> I prefer one commit per moved package.  I guess this is not what you
> hoped for, but it makes for a more fine-grained log — and it boosts your
> commit stats ;)

Ahah! I was almost sure you answered that. :-)
Ok, I will.
Be prepared for the storm. ;-)


All the best,
simon

Re: Move r-{desolve, quadprog, pracma, subplex} from maths.scm to cran.scm

[Ricardo Wurmus]

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.
> : 7ed869f796 gnu: Add r-nbpseq.
> : 80eb01c776 gnu: r-gkmsvm: Move to (gnu packages bioconductor).
>
> with some comments  as
>
> --8<---cut here---start->8---
> ;; This is a CRAN package, but it uncharacteristically depends on a
> ;; Bioconductor package
> --8<---cut here---end--->8---
>
> Do you remember a special motivation?

Yes, the comments say why.  It’s very unusual for a CRAN package to
depend on Bioconductor packages.  Usually, it is the other way around.
I just didn’t want (gnu packages cran) to point 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.

> 2.
> The second point is that the file statistics.scm contains 227 packages
> and 206 are cran-uri. And the file cran.scm already contains 602
> packages, so it will be almost as python-xyz.scm is. Why not. Then,
> this file statistics.scm will be almost empty and I propose instead to
> populate the files maths.scm, python-xyz.scm.
>
> What do you think?

statistics.scm was the only thing we had for R in the beginning.  When
it grew and it became apparent that more and more CRAN packages would be
added, I felt that the module became less suitable.

I don’t understand your comment about “maths.scm” and “python-xyz.scm”.
I think it’s good to move CRAN and Bioconductor packages out of
statistics.scm whenever possible.  We can leave the actual statistics
programs there as well as potentially unmovable CRAN packages.

> 3.
> It is a big move. Do you prefer
>  - a commit per package, so more or less 300 commits?
>  - or a commit bioconductor.scm->cran.scm, another
> statistics.scm->cran.scm, bioinformatics.scm->bioconductor.scm and
> bioconductor->bioinformatics.scm, etc.?

I prefer one commit per moved package.  I guess this is not what you
hoped for, but it makes for a more fine-grained log — and it boosts your
commit stats ;)

--
Ricardo

Re: Move r-{desolve, quadprog, pracma, subplex} from maths.scm to cran.scm

[zimoun]

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
> bioconductor.scm where possible.)

I am working on that.

Let consider some quick stats with "grep".

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.
: 7ed869f796 gnu: Add r-nbpseq.
: 80eb01c776 gnu: r-gkmsvm: Move to (gnu packages bioconductor).

with some comments  as

--8<---cut here---start->8---
;; This is a CRAN package, but it uncharacteristically depends on a
;; Bioconductor package
--8<---cut here---end--->8---

Do you remember a special motivation?


2.
The second point is that the file statistics.scm contains 227 packages
and 206 are cran-uri. And the file cran.scm already contains 602
packages, so it will be almost as python-xyz.scm is. Why not. Then,
this file statistics.scm will be almost empty and I propose instead to
populate the files maths.scm, python-xyz.scm.

What do you think?


3.
It is a big move. Do you prefer
 - a commit per package, so more or less 300 commits?
 - or a commit bioconductor.scm->cran.scm, another
statistics.scm->cran.scm, bioinformatics.scm->bioconductor.scm and
bioconductor->bioinformatics.scm, etc.?


Thank you for your insights.

All the best,
simon

Re: Move r-{desolve, quadprog, pracma, subplex} from maths.scm to cran.scm

[zimoun]

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 `cran.scm`. Do you agree to move them?
>
> I think moving them to cran.scm is fine.  In my opinion both of these
> places are similarly poor choices: maths.scm because we drag in the R
> build system and dependencies, and cran.scm because it’s huge and will
> only get bigger.
>
> On the plus side, R code is rarely as “involved” as Python code, so I
> don’t expect cran.scm to become as tangled up with dependencies from all
> over the place as python-xyz.scm, so letting cran.scm grow is probably
> just fine.

Do you agree that we should document this rationale somewhere?
AFAIK, nothing is written down about the lang-xyz.scm or the R land
(cran vs bioconductor vs bioinformatics vs math vs statistiscs).
I will read our materials and come back with a proposal: manual or
cookbook or plain text in repo or etc.
What do you think?


> Since nobody else seems to hold any strong opinions on this issue, I’d
> say you’re welcome to move these package definitions to cran.scm.
> Please also update the Copyright comments at the top of the file where
> needed (use “git blame” and “git log” to simplify this task) and remove
> whatever spurious module imports there may be in maths.scm after
> removing the R package definitions.

I submitted patches [1] that respect these advices. I hope so. :-)

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38184


> 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
> bioconductor.scm where possible.)

I will do.
I will dig into the big move of Haskell or Lisp to see how it is
better to split the commits.


Thanks.
simon

Re: Move r-{desolve, quadprog, pracma, subplex} from maths.scm to cran.scm

[Ricardo Wurmus]

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 opinion both of these
places are similarly poor choices: maths.scm because we drag in the R
build system and dependencies, and cran.scm because it’s huge and will
only get bigger.

On the plus side, R code is rarely as “involved” as Python code, so I
don’t expect cran.scm to become as tangled up with dependencies from all
over the place as python-xyz.scm, so letting cran.scm grow is probably
just fine.

Since nobody else seems to hold any strong opinions on this issue, I’d
say you’re welcome to move these package definitions to cran.scm.
Please also update the Copyright comments at the top of the file where
needed (use “git blame” and “git log” to simplify this task) and remove
whatever spurious module imports there may be in maths.scm after
removing the R package definitions.

Thank you!

--
Ricardo

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
bioconductor.scm where possible.)

Re: Move r-{desolve, quadprog, pracma, subplex} from maths.scm to cran.scm

[Ricardo Wurmus]

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 agree to move them?
>
> What happens to the Copyright?
>
> No issue with the Ricardo's one. Full of years. :-)
>
> Roel and Leo have Copyright 2016 in the file maths.scm.
> But Copytright 2017,2018 and 2018 in the file cran.scm.
>
> Does a transfer of copyright between the two files apply?

Yes, we should update the copyright lines.  I usually rely on the
information provided by the git log.

-- 
Ricardo

Re: Move r-{desolve, quadprog, pracma, subplex} from maths.scm to cran.scm

[zimoun]

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 Copyright?

No issue with the Ricardo's one. Full of years. :-)

Roel and Leo have Copyright 2016 in the file maths.scm.
But Copytright 2017,2018 and 2018 in the file cran.scm.

Does a transfer of copyright between the two files apply?


Thank in advance.

All the best,
simon

Move r-{desolve,quadprog,pracma,subplex} from maths.scm to cran.scm

[zimoun]

Dear,

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?

All the best,
simon

Re: 02/02: gnu: Remove r-biocinstaller does not evaluate

[Ricardo Wurmus]

Tobias Geerinckx-Rice  writes:

>>   (define-public r-biocinstaller
>
> […]
>
>> +  (deprecated-package "r-biocinstaller" r-biocmanager))
>
> This breaks things […]

In this case I think it’s fine to just remove it and not set up the
deprecation redirection to r-biocmanager.

--
Ricardo

Re: 02/02: gnu: Remove r-biocinstaller does not evaluate

[Tobias Geerinckx-Rice]

Guix,

guix-comm...@gnu.org wrote:

nckx pushed a commit to branch master
in repository guix.

commit 0971f8bd884b6e92b77d9e12030cd58279699183
Author: Tobias Geerinckx-Rice 
Date:   Mon Jul 8 16:09:46 2019 +0200

gnu: Remove r-biocinstaller.

It requires R < 3.6 and is no longer supported.

* gnu/packages/bioinformatics.scm (r-biocinstaller): Define 
as

deprecated in favour of r-biocmanager.
---
 gnu/packages/bioinformatics.scm | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/gnu/packages/bioinformatics.scm 
b/gnu/packages/bioinformatics.scm

index b6f5a35..62d1cbd 100644
--- a/gnu/packages/bioinformatics.scm
+++ b/gnu/packages/bioinformatics.scm
@@ -7238,23 +7238,7 @@ BLAST, KEGG, GenBank, MEDLINE and GO.")
 (license (list license:ruby license:lgpl2.1+ license:gpl2+ 
 
 
 (define-public r-biocinstaller


[…]


+  (deprecated-package "r-biocinstaller" r-biocmanager))


This breaks things like:

--8<---cut here---start->8---
~ λ guix refresh -l grpc
Backtrace:
In ice-9/boot-9.scm:
  2874:4 19 (define-module* _ #:filename _ #:pure _ #:version _ 
  #:imports _ #:exports _ #:replacements _ #:re-exports _ 
  #:autoloads _ #:duplicates _ #:transformer _)

 2887:24 18 (_)
  222:29 17 (map1 (((guix licenses) #:prefix license:) ((guix 
  packages)) ((guix download)) ((guix git-download)) ((guix 
  utils)) ((guix build-system r)) ((gnu packages algebra)) ((gnu 
  packages base)) ((gnu packages #)) (#) …))
  222:29 16 (map1 (((guix packages)) ((guix download)) ((guix 
  git-download)) ((guix utils)) ((guix build-system r)) ((gnu 
  packages algebra)) ((gnu packages base)) ((gnu packages 
  bioinformatics)) ((gnu packages c)) ((# …)) …))
  222:29 15 (map1 (((guix download)) ((guix git-download)) ((guix 
  utils)) ((guix build-system r)) ((gnu packages algebra)) ((gnu 
  packages base)) ((gnu packages bioinformatics)) ((gnu packages 
  c)) ((gnu packages #)) ((…)) …))
  222:29 14 (map1 (((guix git-download)) ((guix utils)) ((guix 
  build-system r)) ((gnu packages algebra)) ((gnu packages base)) 
  ((gnu packages bioinformatics)) ((gnu packages c)) ((gnu 
  packages compression)) ((gnu # #)) # …))
  222:29 13 (map1 (((guix utils)) ((guix build-system r)) ((gnu 
  packages algebra)) ((gnu packages base)) ((gnu packages 
  bioinformatics)) ((gnu packages c)) ((gnu packages 
  compression)) ((gnu packages curl)) ((gnu # #)) # …))
  222:29 12 (map1 (((guix build-system r)) ((gnu packages 
  algebra)) ((gnu packages base)) ((gnu packages bioinformatics)) 
  ((gnu packages c)) ((gnu packages compression)) ((gnu packages 
  curl)) ((gnu packages databases)) # …))
  222:29 11 (map1 (((gnu packages algebra)) ((gnu packages base)) 
  ((gnu packages bioinformatics)) ((gnu packages c)) ((gnu 
  packages compression)) ((gnu packages curl)) ((gnu packages 
  databases)) ((gnu packages #)) ((# …)) …))
  222:29 10 (map1 (((gnu packages base)) ((gnu packages 
  bioinformatics)) ((gnu packages c)) ((gnu packages 
  compression)) ((gnu packages curl)) ((gnu packages databases)) 
  ((gnu packages fontutils)) ((gnu packages gcc)) (#) …))
  222:17  9 (map1 (((gnu packages bioinformatics)) ((gnu packages 
  c)) ((gnu packages compression)) ((gnu packages curl)) ((gnu 
  packages databases)) ((gnu packages fontutils)) ((gnu packages 
  gcc)) ((gnu packages geo)) (#) …))
 2800:17  8 (resolve-interface (gnu packages bioinformatics) 
 #:select _ #:hide _ #:prefix _ #:renamer _ #:version _)

In ice-9/threads.scm:
   390:8  7 (_ _)
In ice-9/boot-9.scm:
 2726:13  6 (_)
In ice-9/threads.scm:
   390:8  5 (_ _)
In ice-9/boot-9.scm:
 2994:20  4 (_)
  2312:4  3 (save-module-excursion #  ice-9/boot-9.scm:2995:21 ()>)

 3014:26  2 (_)
In unknown file:
  1 (primitive-load-path "gnu/packages/bioinformatics" 
  #)

In gnu/packages/bioinformatics.scm:
 7246:22  0 (_)

gnu/packages/bioinformatics.scm:7246:16: error: r-biocmanager: 
unbound variable

--8<---cut here---end--->8---

Replacing DEPRECATED-PACKAGE with the more explicit (and 
desperate)


--8<---cut here---start->8---
(define-public r-biocinstaller
 ;; DEPRECATED-PACKAGE can only refer to a package variable 
 within the calling

 ;; module.  r-biocmanager is in (gnu packages cran).
 (package
   (inherit r-biocmanager)
   (name "r-biocinstaller")
   (properties `((superseded . ,r-biocmanager)
--8<---cut here---end--->8---

didn't help.

I half-understand why this is a problem (every single use of 
DEPRECATED-PACKAGE in Guix is intra-module, it's obviously not 
meant to span modules like this), but not the root cause or how to 
fix it without moving things around & breaking part of the 
backwards compatibility that DEPRECATED-PACKAGE is there to 
provide.


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: 41/92: gnu: r-iranges: Update to 2.14.12.

[Ricardo Wurmus]

Hi Mark,

> Hydra failed to download the source tarball for IRanges-2.14.12, and I
> can't build it locally either:
>
> --8<---cut here---start->8---
> mhw@jojen ~$ guix build -S r-iranges
> The following derivation will be built:
>/gnu/store/0wsvsrb2888fv8y6w511lwrwkphdga61-IRanges_2.14.12.tar.gz.drv
> building 
> /gnu/store/0wsvsrb2888fv8y6w511lwrwkphdga61-IRanges_2.14.12.tar.gz.drv...
>
> Starting download of 
> /gnu/store/ydsyylgwyqi7ljvzv01l8zrnc4jx5a4r-IRanges_2.14.12.tar.gz
> From 
> https://bioconductor.org/packages/release/bioc/src/contrib/IRanges_2.14.12.tar.gz...
> download failed 
> "https://bioconductor.org/packages/release/bioc/src/contrib/IRanges_2.14.12.tar.gz;
>  404 "Not Found"
>
> Starting download of 
> /gnu/store/ydsyylgwyqi7ljvzv01l8zrnc4jx5a4r-IRanges_2.14.12.tar.gz
> From 
> https://bioconductor.org/packages/3.7/bioc/src/contrib/Archive/IRanges_2.14.12.tar.gz...
> download failed 
> "https://bioconductor.org/packages/3.7/bioc/src/contrib/Archive/IRanges_2.14.12.tar.gz;
>  404 "Not Found"

Since the upgrade Bioconductor 3.8 has been released, so the new archive
URL would now be:

   
https://bioconductor.org/packages/3.8/bioc/src/contrib/Archive/IRanges_2.14.12.tar.gz

(I still have the source tarball for this version from before the
upgrade to 3.8.)

Unfortunately, Bioconductor does not keep an archive, so this particular
version of IRanges has completely disappeared since the upgrade to
2.16.0.

I’ll upgrade all Bioconductor packages today.

--
Ricardo

Re: 41/92: gnu: r-iranges: Update to 2.14.12.

[Mark H Weaver]

Hi Ricardo,

rek...@elephly.net (Ricardo Wurmus) writes:

> rekado pushed a commit to branch master
> in repository guix.
>
> commit e563acb96b1d485b733484a81869144b2793c41a
> Author: Ricardo Wurmus 
> Date:   Tue Oct 30 07:44:32 2018 +0100
>
> gnu: r-iranges: Update to 2.14.12.
> 
> * gnu/packages/bioinformatics.scm (r-iranges): Update to 2.14.12.

Hydra failed to download the source tarball for IRanges-2.14.12, and I
can't build it locally either:

--8<---cut here---start->8---
mhw@jojen ~$ guix build -S r-iranges
The following derivation will be built:
   /gnu/store/0wsvsrb2888fv8y6w511lwrwkphdga61-IRanges_2.14.12.tar.gz.drv
building 
/gnu/store/0wsvsrb2888fv8y6w511lwrwkphdga61-IRanges_2.14.12.tar.gz.drv...

Starting download of 
/gnu/store/ydsyylgwyqi7ljvzv01l8zrnc4jx5a4r-IRanges_2.14.12.tar.gz
>From 
>https://bioconductor.org/packages/release/bioc/src/contrib/IRanges_2.14.12.tar.gz...
download failed 
"https://bioconductor.org/packages/release/bioc/src/contrib/IRanges_2.14.12.tar.gz;
 404 "Not Found"

Starting download of 
/gnu/store/ydsyylgwyqi7ljvzv01l8zrnc4jx5a4r-IRanges_2.14.12.tar.gz
>From 
>https://bioconductor.org/packages/3.7/bioc/src/contrib/Archive/IRanges_2.14.12.tar.gz...
download failed 
"https://bioconductor.org/packages/3.7/bioc/src/contrib/Archive/IRanges_2.14.12.tar.gz;
 404 "Not Found"

Starting download of 
/gnu/store/ydsyylgwyqi7ljvzv01l8zrnc4jx5a4r-IRanges_2.14.12.tar.gz
>From 
>http://mirror.hydra.gnu.org/file/IRanges_2.14.12.tar.gz/sha256/1ar8sqqgjdy00dbgrxnacqy6gwir5xax76yf0vjxi2vj2skqb0kn...
download failed 
"http://mirror.hydra.gnu.org/file/IRanges_2.14.12.tar.gz/sha256/1ar8sqqgjdy00dbgrxnacqy6gwir5xax76yf0vjxi2vj2skqb0kn;
 404 "Not Found"

Starting download of 
/gnu/store/ydsyylgwyqi7ljvzv01l8zrnc4jx5a4r-IRanges_2.14.12.tar.gz
>From 
>http://tarballs.nixos.org/sha256/1ar8sqqgjdy00dbgrxnacqy6gwir5xax76yf0vjxi2vj2skqb0kn...
download failed 
"http://tarballs.nixos.org/sha256/1ar8sqqgjdy00dbgrxnacqy6gwir5xax76yf0vjxi2vj2skqb0kn;
 404 "Not Found"
failed to download 
"/gnu/store/ydsyylgwyqi7ljvzv01l8zrnc4jx5a4r-IRanges_2.14.12.tar.gz" from 
("https://bioconductor.org/packages/release/bioc/src/contrib/IRanges_2.14.12.tar.gz;
 
"https://bioconductor.org/packages/3.7/bioc/src/contrib/Archive/IRanges_2.14.12.tar.gz;)
builder for 
`/gnu/store/0wsvsrb2888fv8y6w511lwrwkphdga61-IRanges_2.14.12.tar.gz.drv' failed 
to produce output path 
`/gnu/store/ydsyylgwyqi7ljvzv01l8zrnc4jx5a4r-IRanges_2.14.12.tar.gz'
build of /gnu/store/0wsvsrb2888fv8y6w511lwrwkphdga61-IRanges_2.14.12.tar.gz.drv 
failed
View build log at 
'/var/log/guix/drvs/0w/svsrb2888fv8y6w511lwrwkphdga61-IRanges_2.14.12.tar.gz.drv.bz2'.
guix build: error: build failed: build of 
`/gnu/store/0wsvsrb2888fv8y6w511lwrwkphdga61-IRanges_2.14.12.tar.gz.drv' failed
mhw@jojen ~$ 
--8<---cut here---end--->8---

Could you take a look?

 Thanks,
   Mark

Re: [outreach] Help trying to create R package

[Laura Lazzati]

Thank you :)
Ok, i'll move to the texinfo task.
Regards!
Laura

Re: [outreach] Help trying to create R package

[Gábor Boskovits]

Hello Laura,

Laura Lazzati  ezt írta (időpont: 2018.
nov. 2., P, 20:45):
>>
>>
>> I tracked it down:
>>
>> The cause is that:
>>
>> guix/import/cran.scm:
>>
>> (define (latest-bioconductor-package-version name)
>>   "Return the version string corresponding to the latest release of the
>> bioconductor package NAME, or #F if the package is unknown."
>>
>> actually returns #f. It's a bit said that this #f is not checked
>> further down. The problem is the package name. If you add an "r" before
>> the package name, it should work (suppose you fixed the first problem):
>>
>> guix import cran --archive=bioconductor rtracklayer
>
> Sorry for writing again on this topic.
> Today I wanted to practice packaging an r package belonging to bioconductor, 
> to then go on and read and work with texinfo.
> After writing on IRC channel, I realized I already had this exact problem, 
> but thought it was a problem of other packages.
> I ran again this same command, and I am getting:
>
> $guix import cran -a bioconductor rtracklayer
> guile: warning: failed to install locale
> hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package 
> and defining `GUIX_LOCPATH', along these lines:
>
>  guix package -i glibc-utf8-locales
>  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
>
> See the "Application Setup" section in the manual, for more info.
>
>
>
> Starting download of /tmp/guix-file.kBVFop
> From 
> https://bioconductor.org/packages/release/bioc/src/contrib/rtracklayer_1.40.6.tar.gz...
> download failed 
> "https://bioconductor.org/packages/release/bioc/src/contrib/rtracklayer_1.40.6.tar.gz;
>  404 "Not Found"
> failed to download "/tmp/guix-file.kBVFop" from 
> "https://bioconductor.org/packages/release/bioc/src/contrib/rtracklayer_1.40.6.tar.gz;
> Backtrace
> (and the backtrace is the same).
>
> I am also new to schemas, but opened guix/import/cran.scm and saw what Bjorn 
> was saying. I don't know why if it is not the latest package there should be 
> a false condition, but I don't know either why I am not getting the latest 
> version from bioconductor if it is real that, for tracklayer the latest is 42 
> and that file does not exist.
> Any ideas? Should I spend more time trying to figure this out or should I 
> move on to another task, like knowing guix more deeply or learning texinfo?
>

This is not your fault, you were simply at the wrong place at the wrong time :)
Bioconductor 3.8 was released on October 31., so the importer, and
most probably all packages not having the substitues from
bioconductor are off. (It seems the release tarballs from 3.7 were
removed.) There is a comment in the importer that all bioconductor
packages should be updated together. We should ask Ricardo later how
to proceed regarding this.

>
> Regards!
> Laura

Best regards,
g_bor

Re: [outreach] Help trying to create R package

[Laura Lazzati]

>
>
> I tracked it down:
>
> The cause is that:
>
> guix/import/cran.scm:
>
> (define (latest-bioconductor-package-version name)
>   "Return the version string corresponding to the latest release of the
> bioconductor package NAME, or #F if the package is unknown."
>
> actually returns #f. It's a bit said that this #f is not checked
> further down. The problem is the package name. If you add an "r" before
> the package name, it should work (suppose you fixed the first problem):
>
> guix import cran --archive=bioconductor rtracklayer
>
Sorry for writing again on this topic.
Today I wanted to practice packaging an r package belonging to
bioconductor, to then go on and read and work with texinfo.
After writing on IRC channel, I realized I already had this exact problem,
but thought it was a problem of other packages.
I ran again this same command, and I am getting:

$guix import cran -a bioconductor rtracklayer
guile: warning: failed to install locale
hint: Consider installing the `glibc-utf8-locales' or `glibc-locales'
package and defining `GUIX_LOCPATH', along these lines:

 guix package -i glibc-utf8-locales
 export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.



Starting download of /tmp/guix-file.kBVFop
From
https://bioconductor.org/packages/release/bioc/src/contrib/rtracklayer_1.40.6.tar.gz.
..
download failed "
https://bioconductor.org/packages/release/bioc/src/contrib/rtracklayer_1.40.6.tar.gz;
404 "Not Found"
failed to download "/tmp/guix-file.kBVFop" from "
https://bioconductor.org/packages/release/bioc/src/contrib/rtracklayer_1.40.6.tar.gz
"
Backtrace
(and the backtrace is the same).

I am also new to schemas, but opened guix/import/cran.scm and saw what
Bjorn was saying. I don't know why if it is not the latest package there
should be a false condition, but I don't know either why I am not getting
the latest version from bioconductor if it is real that, for tracklayer the
latest is 42 and that file does not exist.
Any ideas? Should I spend more time trying to figure this out or should I
move on to another task, like knowing guix more deeply or learning texinfo?


Regards!
Laura

Re: [outreach] Help trying to create R package

[Ludovic Courtès]

Hello!

Björn Höfling  skribis:

> On Fri, 19 Oct 2018 20:10:03 -0300
> Laura Lazzati  wrote:
>
>
>> I ended up sending the patch in plain text mode directly from my
>> email, because even I installed the send-mail command for git, my
>> second factor authenticator complained. I will take a look about how
>> to configure the command properly.
>> Please, let me know if you received it fine, and if so, if you would
>> like me to work on other contributions meanwhile (maybe another r
>> package, or let me know what alse would you like me to do)
>
> Congratulations! Your patch went through:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33099

Or, for a nicer view:

  https://issues.guix.info/issue/33099

Thank you for this first patch, Laura!

Ludo’.

Re: [outreach] Help trying to create R package

[Laura Lazzati]

On Sat, Oct 20, 2018 at 3:34 AM Gábor Boskovits  wrote:
>
> Hello Laura,
>
> Björn Höfling  ezt írta (időpont:
> 2018. okt. 20., Szo, 8:08):
> >
> > Hi Laura,
> >
> > On Fri, 19 Oct 2018 20:10:03 -0300
> > Laura Lazzati  wrote:
> >
> >
> > > I ended up sending the patch in plain text mode directly from my
> > > email, because even I installed the send-mail command for git, my
> > > second factor authenticator complained. I will take a look about how
> > > to configure the command properly.
>
> I guess you are using gmail with two factor authentication.
> Then you will have to create an app password, and after that
> you can use git credentials to set up authentication using the app
> password, but sending as plain text is fine for now.
Yes, I will try that for a second commit
>
> > > Please, let me know if you received it fine, and if so, if you would
> > > like me to work on other contributions meanwhile (maybe another r
> > > package, or let me know what alse would you like me to do)
>
> Another R package would be great, in the meanwhile I will have a look
> around what else to do.
Sure, as I said before, once I learn how to package one, I will be
able to package more. I will take a look at the page and check other
packages that are not already in guix. And yes, if you find other
tasks that I can do it is fine for me. I would like to go on
contributing even after November 6th (the outreachy deadline for
applying). Maybe after that I can go on playing with GuixSD and
reading the whole documentation ;)
>
> >
> > Congratulations! Your patch went through:
> >
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33099
> >
>
> That is great!
>
> > Either follow its status on that page and/or subscribe to the
> > guix-patches list:
> >
> > https://lists.gnu.org/mailman/listinfo/guix-patches
> >
> > Someone will review it and give you feedback.
Thank you, I saw that they wrote about it :) But I will ask in that
thread of mails about how to make my changes to be accespted
> >
>
> I will review it later today.
>
> > For Outreachy it is important to document your contributions. So,
> > please also go to the Guix-Outreachy page, there you should find a link
> > to formally report your contribution. When I have understood that
> > right, it is not important that your contribution really get's accepted
> > for that, just that you made one.
Yes, I reported the in progress contribution.
> >
>
> Yes, now you can record this contribution.
>
> > Björn
> >
> Best regards,
> g_bor
Regards :)

Laura

Re: [outreach] Help trying to create R package

[Gábor Boskovits]

Hello Laura,

Björn Höfling  ezt írta (időpont:
2018. okt. 20., Szo, 8:08):
>
> Hi Laura,
>
> On Fri, 19 Oct 2018 20:10:03 -0300
> Laura Lazzati  wrote:
>
>
> > I ended up sending the patch in plain text mode directly from my
> > email, because even I installed the send-mail command for git, my
> > second factor authenticator complained. I will take a look about how
> > to configure the command properly.

I guess you are using gmail with two factor authentication.
Then you will have to create an app password, and after that
you can use git credentials to set up authentication using the app
password, but sending as plain text is fine for now.

> > Please, let me know if you received it fine, and if so, if you would
> > like me to work on other contributions meanwhile (maybe another r
> > package, or let me know what alse would you like me to do)

Another R package would be great, in the meanwhile I will have a look
around what else to do.

>
> Congratulations! Your patch went through:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33099
>

That is great!

> Either follow its status on that page and/or subscribe to the
> guix-patches list:
>
> https://lists.gnu.org/mailman/listinfo/guix-patches
>
> Someone will review it and give you feedback.
>

I will review it later today.

> For Outreachy it is important to document your contributions. So,
> please also go to the Guix-Outreachy page, there you should find a link
> to formally report your contribution. When I have understood that
> right, it is not important that your contribution really get's accepted
> for that, just that you made one.
>

Yes, now you can record this contribution.

> Björn
>
Best regards,
g_bor

Re: [outreach] Help trying to create R package

[Björn Höfling]

Hi Laura,

On Fri, 19 Oct 2018 20:10:03 -0300
Laura Lazzati  wrote:


> I ended up sending the patch in plain text mode directly from my
> email, because even I installed the send-mail command for git, my
> second factor authenticator complained. I will take a look about how
> to configure the command properly.
> Please, let me know if you received it fine, and if so, if you would
> like me to work on other contributions meanwhile (maybe another r
> package, or let me know what alse would you like me to do)

Congratulations! Your patch went through:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33099

Either follow its status on that page and/or subscribe to the
guix-patches list:

https://lists.gnu.org/mailman/listinfo/guix-patches

Someone will review it and give you feedback.

For Outreachy it is important to document your contributions. So,
please also go to the Guix-Outreachy page, there you should find a link
to formally report your contribution. When I have understood that
right, it is not important that your contribution really get's accepted
for that, just that you made one.

Björn



pgpDWoEwWssY5.pgp
Description: OpenPGP digital signature

Re: [outreach] Help trying to create R package

[Laura Lazzati]

On Fri, Oct 19, 2018 at 6:25 PM Gábor Boskovits  wrote:
>
> Hello Laura,
>
> Laura Lazzati  ezt írta (időpont: 2018.
> okt. 19., P, 22:35):
> >
> > On Fri, Oct 19, 2018 at 3:45 PM Gábor Boskovits  wrote:
> > >
> > > Hello Laura,
> > >
> > > Laura Lazzati  ezt írta (időpont: 2018.
> > > okt. 19., P, 20:37):
> > > >
> > > > On Fri, Oct 19, 2018 at 4:29 AM Gábor Boskovits  
> > > > wrote:
> > > > >
> > > > > Hello Ricardo,
> > > > >
> > > > > Ricardo Wurmus  ezt írta (időpont: 2018. okt. 
> > > > > 19., P 9:10):
> > > > >>
> > > > >>
> > > > >> Hi Laura,
> > > > >>
> > > > >> > with guix environment --pure guix --ad-hoc coreutils findutils 
> > > > >> > which (or -C)
> > > > >> > I get, the output:
> > > > >> > Command 'lesspipe' is available in the following places
> > > > >> >  * /bin/lesspipe
> > > > >> >  * /usr/bin/lesspipe
> > > > >> > The command could not be located because '/bin:/usr/bin' is not
> > > > >> > included in the PATH environment variable.
> > > > >> > lesspipe: command not found
> > > > >>
> > > > >> This is because your shell initialization code (e.g. to set up the
> > > > >> prompt) refers to lesspipe.  You can ignore this or remove the fancy
> > > > >> initialization.
> > > > >>
> > > > >> > There, I run which guix and get:
> > > > >> > which: no guix in
> > > > >> > (/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)
> > > > >>
> > > > >> That’s because “--pure” resets the PATH; that’s by design.  The only
> > > > >> problem you have is that your Guix is located elsewhere.  But why do 
> > > > >> you
> > > > >> need Guix itself inside of an environment to build Guix?
> > > > >>
> > > > >> The point of using “guix environment --pure guix” is only to enter a
> > > > >> clean environment containing everything you need to build Guix from
> > > > >> source.  So once you’re inside of this environment you can run the
> > > > >> bootstrap and configure scripts, and run make to compile the sources.
> > > > >>
> > > > >> To *use* that Guix you just built you need to use “./pre-inst-env 
> > > > >> guix”
> > > > >> from the source directory.
> > > > >>
> > > > >> > The closest I got was by setting:
> > > > >> > PATH=$PATH:/usr/bin/:/bin
> > > > >> > PATH=$PATH:/usr/local/bin
> > > > >>
> > > > >> This defeats the purpose of using “--pure” as these directories 
> > > > >> contain
> > > > >> all sorts of things on a foreign distro, so you lose control over the
> > > > >> environment.
> > > >
> > > > I am glad to tell you that I have followed all the commands, I will
> > > > copy some of them here just in case, and saved the output in my daily
> > > > journal of everything :)
> > > >
> > > > guix environment --pure guix --ad-hoc coreutils findutils which
> > > > ./bootstrap
> > > > ./configure --localstatedir=/var
> > > > make
> > > > echo $? ->got 0
> > > > which guix -> got
> > > > no guix in 
> > > > (/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)
> > > > ./pre-inst-env guix package --help -> worked fine!
> > > > ./pre-inst-env guix package -i hello -> the same
> > > > ./pre-inst-env guix package -i emacs
> > > > export PATH="/home/laura/.guix-profile/bin${PATH:+:}$PATH"
> > > > export 
> > > > INFOPATH="/home/laura/.guix-profile/share/info${INFOPATH:+:}$INFOPATH"
> > > > (with this two exports, I could run hello and emacs without problems)
> > > > ./pre-inst-env guix package -i nss-certs
> > > > Played a lot with
> > > > ./pre-inst-env guix build r-aspi
> > > > and
> > > > emacs gnu/packages/cran.scm
> > > > until I fou

Re: [outreach] Help trying to create R package

[Gábor Boskovits]

Hello Laura,

Laura Lazzati  ezt írta (időpont: 2018.
okt. 19., P, 22:35):
>
> On Fri, Oct 19, 2018 at 3:45 PM Gábor Boskovits  wrote:
> >
> > Hello Laura,
> >
> > Laura Lazzati  ezt írta (időpont: 2018.
> > okt. 19., P, 20:37):
> > >
> > > On Fri, Oct 19, 2018 at 4:29 AM Gábor Boskovits  
> > > wrote:
> > > >
> > > > Hello Ricardo,
> > > >
> > > > Ricardo Wurmus  ezt írta (időpont: 2018. okt. 19., 
> > > > P 9:10):
> > > >>
> > > >>
> > > >> Hi Laura,
> > > >>
> > > >> > with guix environment --pure guix --ad-hoc coreutils findutils which 
> > > >> > (or -C)
> > > >> > I get, the output:
> > > >> > Command 'lesspipe' is available in the following places
> > > >> >  * /bin/lesspipe
> > > >> >  * /usr/bin/lesspipe
> > > >> > The command could not be located because '/bin:/usr/bin' is not
> > > >> > included in the PATH environment variable.
> > > >> > lesspipe: command not found
> > > >>
> > > >> This is because your shell initialization code (e.g. to set up the
> > > >> prompt) refers to lesspipe.  You can ignore this or remove the fancy
> > > >> initialization.
> > > >>
> > > >> > There, I run which guix and get:
> > > >> > which: no guix in
> > > >> > (/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)
> > > >>
> > > >> That’s because “--pure” resets the PATH; that’s by design.  The only
> > > >> problem you have is that your Guix is located elsewhere.  But why do 
> > > >> you
> > > >> need Guix itself inside of an environment to build Guix?
> > > >>
> > > >> The point of using “guix environment --pure guix” is only to enter a
> > > >> clean environment containing everything you need to build Guix from
> > > >> source.  So once you’re inside of this environment you can run the
> > > >> bootstrap and configure scripts, and run make to compile the sources.
> > > >>
> > > >> To *use* that Guix you just built you need to use “./pre-inst-env guix”
> > > >> from the source directory.
> > > >>
> > > >> > The closest I got was by setting:
> > > >> > PATH=$PATH:/usr/bin/:/bin
> > > >> > PATH=$PATH:/usr/local/bin
> > > >>
> > > >> This defeats the purpose of using “--pure” as these directories contain
> > > >> all sorts of things on a foreign distro, so you lose control over the
> > > >> environment.
> > >
> > > I am glad to tell you that I have followed all the commands, I will
> > > copy some of them here just in case, and saved the output in my daily
> > > journal of everything :)
> > >
> > > guix environment --pure guix --ad-hoc coreutils findutils which
> > > ./bootstrap
> > > ./configure --localstatedir=/var
> > > make
> > > echo $? ->got 0
> > > which guix -> got
> > > no guix in 
> > > (/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)
> > > ./pre-inst-env guix package --help -> worked fine!
> > > ./pre-inst-env guix package -i hello -> the same
> > > ./pre-inst-env guix package -i emacs
> > > export PATH="/home/laura/.guix-profile/bin${PATH:+:}$PATH"
> > > export 
> > > INFOPATH="/home/laura/.guix-profile/share/info${INFOPATH:+:}$INFOPATH"
> > > (with this two exports, I could run hello and emacs without problems)
> > > ./pre-inst-env guix package -i nss-certs
> > > Played a lot with
> > > ./pre-inst-env guix build r-aspi
> > > and
> > > emacs gnu/packages/cran.scm
> > > until I found out that there were syntax errors, mismatches in
> > > parenthesis and so on, and in the last
> > > ./pre-inst-env guix build r-aspi got:
> > > ;;; note: source file /home/laura/guix/gnu/packages/cran.scm
> > > ;;;   newer than compiled /home/laura/guix/gnu/packages/cran.go
> > > (still that) but:
> >
> > This is not a problem, it just indicates that you modified cran.scm, and it 
> > will
> > use the .scm file instead, as the .go file was compiled from an older 
> > source.
&g

Re: [outreach] Help trying to create R package

[Laura Lazzati]

On Fri, Oct 19, 2018 at 3:45 PM Gábor Boskovits  wrote:
>
> Hello Laura,
>
> Laura Lazzati  ezt írta (időpont: 2018.
> okt. 19., P, 20:37):
> >
> > On Fri, Oct 19, 2018 at 4:29 AM Gábor Boskovits  wrote:
> > >
> > > Hello Ricardo,
> > >
> > > Ricardo Wurmus  ezt írta (időpont: 2018. okt. 19., P 
> > > 9:10):
> > >>
> > >>
> > >> Hi Laura,
> > >>
> > >> > with guix environment --pure guix --ad-hoc coreutils findutils which 
> > >> > (or -C)
> > >> > I get, the output:
> > >> > Command 'lesspipe' is available in the following places
> > >> >  * /bin/lesspipe
> > >> >  * /usr/bin/lesspipe
> > >> > The command could not be located because '/bin:/usr/bin' is not
> > >> > included in the PATH environment variable.
> > >> > lesspipe: command not found
> > >>
> > >> This is because your shell initialization code (e.g. to set up the
> > >> prompt) refers to lesspipe.  You can ignore this or remove the fancy
> > >> initialization.
> > >>
> > >> > There, I run which guix and get:
> > >> > which: no guix in
> > >> > (/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)
> > >>
> > >> That’s because “--pure” resets the PATH; that’s by design.  The only
> > >> problem you have is that your Guix is located elsewhere.  But why do you
> > >> need Guix itself inside of an environment to build Guix?
> > >>
> > >> The point of using “guix environment --pure guix” is only to enter a
> > >> clean environment containing everything you need to build Guix from
> > >> source.  So once you’re inside of this environment you can run the
> > >> bootstrap and configure scripts, and run make to compile the sources.
> > >>
> > >> To *use* that Guix you just built you need to use “./pre-inst-env guix”
> > >> from the source directory.
> > >>
> > >> > The closest I got was by setting:
> > >> > PATH=$PATH:/usr/bin/:/bin
> > >> > PATH=$PATH:/usr/local/bin
> > >>
> > >> This defeats the purpose of using “--pure” as these directories contain
> > >> all sorts of things on a foreign distro, so you lose control over the
> > >> environment.
> >
> > I am glad to tell you that I have followed all the commands, I will
> > copy some of them here just in case, and saved the output in my daily
> > journal of everything :)
> >
> > guix environment --pure guix --ad-hoc coreutils findutils which
> > ./bootstrap
> > ./configure --localstatedir=/var
> > make
> > echo $? ->got 0
> > which guix -> got
> > no guix in 
> > (/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)
> > ./pre-inst-env guix package --help -> worked fine!
> > ./pre-inst-env guix package -i hello -> the same
> > ./pre-inst-env guix package -i emacs
> > export PATH="/home/laura/.guix-profile/bin${PATH:+:}$PATH"
> > export 
> > INFOPATH="/home/laura/.guix-profile/share/info${INFOPATH:+:}$INFOPATH"
> > (with this two exports, I could run hello and emacs without problems)
> > ./pre-inst-env guix package -i nss-certs
> > Played a lot with
> > ./pre-inst-env guix build r-aspi
> > and
> > emacs gnu/packages/cran.scm
> > until I found out that there were syntax errors, mismatches in
> > parenthesis and so on, and in the last
> > ./pre-inst-env guix build r-aspi got:
> > ;;; note: source file /home/laura/guix/gnu/packages/cran.scm
> > ;;;   newer than compiled /home/laura/guix/gnu/packages/cran.go
> > (still that) but:
>
> This is not a problem, it just indicates that you modified cran.scm, and it 
> will
> use the .scm file instead, as the .go file was compiled from an older source.
>
> > successfully built 
> > /gnu/store/bmapswnk9li1nscfpirgzsy3npw9hyql-r-aspi-0.2.0.drv
> > /gnu/store/a3apqwf4hy67ms462hn802gk89x99mzh-r-aspi-0.2.0
> >
>
> That's great!
>
> > I am following the contribution guide now, to send the patch, I ran
> > ./pre-inst-env guix lint r-aspi
> > ;;; note: source file /home/laura/guix/gnu/packages/cran.scm
> > ;;;   newer than compiled /home/laura/guix/gnu/packages/cran.go
> > fetching CVE database for 2018...
> > fetching CVE database for 2017...
> > fetching CVE database for 2016...
> > fetching CVE database for 2015...
> >
> > Is this output OK?
> >
>
> Yes, this output is just fine.
I have already run all the commands suggested in
https://www.gnu.org/software/guix/manual/en/html_node/Submitting-Patches.html#Submitting-Patches
I have never used git format-patch before, I am reading documentation
about it but I am not very sure about how to apply it to my package,
could you help me in clarifying this last step?
>
> > >
> > >
> > > Sorry, my bad, I missed that.
> > >
> > >>
> > >> --
> > >> Ricardo
> > >
> > > g_bor
> >
> > Regards!
> > Laura
> Best regards,
> g_bor

Regards :)
Laura

Re: [outreach] Help trying to create R package

[Gábor Boskovits]

Hello Laura,

Laura Lazzati  ezt írta (időpont: 2018.
okt. 19., P, 20:37):
>
> On Fri, Oct 19, 2018 at 4:29 AM Gábor Boskovits  wrote:
> >
> > Hello Ricardo,
> >
> > Ricardo Wurmus  ezt írta (időpont: 2018. okt. 19., P 
> > 9:10):
> >>
> >>
> >> Hi Laura,
> >>
> >> > with guix environment --pure guix --ad-hoc coreutils findutils which (or 
> >> > -C)
> >> > I get, the output:
> >> > Command 'lesspipe' is available in the following places
> >> >  * /bin/lesspipe
> >> >  * /usr/bin/lesspipe
> >> > The command could not be located because '/bin:/usr/bin' is not
> >> > included in the PATH environment variable.
> >> > lesspipe: command not found
> >>
> >> This is because your shell initialization code (e.g. to set up the
> >> prompt) refers to lesspipe.  You can ignore this or remove the fancy
> >> initialization.
> >>
> >> > There, I run which guix and get:
> >> > which: no guix in
> >> > (/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)
> >>
> >> That’s because “--pure” resets the PATH; that’s by design.  The only
> >> problem you have is that your Guix is located elsewhere.  But why do you
> >> need Guix itself inside of an environment to build Guix?
> >>
> >> The point of using “guix environment --pure guix” is only to enter a
> >> clean environment containing everything you need to build Guix from
> >> source.  So once you’re inside of this environment you can run the
> >> bootstrap and configure scripts, and run make to compile the sources.
> >>
> >> To *use* that Guix you just built you need to use “./pre-inst-env guix”
> >> from the source directory.
> >>
> >> > The closest I got was by setting:
> >> > PATH=$PATH:/usr/bin/:/bin
> >> > PATH=$PATH:/usr/local/bin
> >>
> >> This defeats the purpose of using “--pure” as these directories contain
> >> all sorts of things on a foreign distro, so you lose control over the
> >> environment.
>
> I am glad to tell you that I have followed all the commands, I will
> copy some of them here just in case, and saved the output in my daily
> journal of everything :)
>
> guix environment --pure guix --ad-hoc coreutils findutils which
> ./bootstrap
> ./configure --localstatedir=/var
> make
> echo $? ->got 0
> which guix -> got
> no guix in 
> (/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)
> ./pre-inst-env guix package --help -> worked fine!
> ./pre-inst-env guix package -i hello -> the same
> ./pre-inst-env guix package -i emacs
> export PATH="/home/laura/.guix-profile/bin${PATH:+:}$PATH"
> export INFOPATH="/home/laura/.guix-profile/share/info${INFOPATH:+:}$INFOPATH"
> (with this two exports, I could run hello and emacs without problems)
> ./pre-inst-env guix package -i nss-certs
> Played a lot with
> ./pre-inst-env guix build r-aspi
> and
> emacs gnu/packages/cran.scm
> until I found out that there were syntax errors, mismatches in
> parenthesis and so on, and in the last
> ./pre-inst-env guix build r-aspi got:
> ;;; note: source file /home/laura/guix/gnu/packages/cran.scm
> ;;;   newer than compiled /home/laura/guix/gnu/packages/cran.go
> (still that) but:

This is not a problem, it just indicates that you modified cran.scm, and it will
use the .scm file instead, as the .go file was compiled from an older source.

> successfully built 
> /gnu/store/bmapswnk9li1nscfpirgzsy3npw9hyql-r-aspi-0.2.0.drv
> /gnu/store/a3apqwf4hy67ms462hn802gk89x99mzh-r-aspi-0.2.0
>

That's great!

> I am following the contribution guide now, to send the patch, I ran
> ./pre-inst-env guix lint r-aspi
> ;;; note: source file /home/laura/guix/gnu/packages/cran.scm
> ;;;   newer than compiled /home/laura/guix/gnu/packages/cran.go
> fetching CVE database for 2018...
> fetching CVE database for 2017...
> fetching CVE database for 2016...
> fetching CVE database for 2015...
>
> Is this output OK?
>

Yes, this output is just fine.

> >
> >
> > Sorry, my bad, I missed that.
> >
> >>
> >> --
> >> Ricardo
> >
> > g_bor
>
> Regards!
> Laura
Best regards,
g_bor

Re: [outreach] Help trying to create R package

[Laura Lazzati]

On Fri, Oct 19, 2018 at 4:29 AM Gábor Boskovits  wrote:
>
> Hello Ricardo,
>
> Ricardo Wurmus  ezt írta (időpont: 2018. okt. 19., P 
> 9:10):
>>
>>
>> Hi Laura,
>>
>> > with guix environment --pure guix --ad-hoc coreutils findutils which (or 
>> > -C)
>> > I get, the output:
>> > Command 'lesspipe' is available in the following places
>> >  * /bin/lesspipe
>> >  * /usr/bin/lesspipe
>> > The command could not be located because '/bin:/usr/bin' is not
>> > included in the PATH environment variable.
>> > lesspipe: command not found
>>
>> This is because your shell initialization code (e.g. to set up the
>> prompt) refers to lesspipe.  You can ignore this or remove the fancy
>> initialization.
>>
>> > There, I run which guix and get:
>> > which: no guix in
>> > (/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)
>>
>> That’s because “--pure” resets the PATH; that’s by design.  The only
>> problem you have is that your Guix is located elsewhere.  But why do you
>> need Guix itself inside of an environment to build Guix?
>>
>> The point of using “guix environment --pure guix” is only to enter a
>> clean environment containing everything you need to build Guix from
>> source.  So once you’re inside of this environment you can run the
>> bootstrap and configure scripts, and run make to compile the sources.
>>
>> To *use* that Guix you just built you need to use “./pre-inst-env guix”
>> from the source directory.
>>
>> > The closest I got was by setting:
>> > PATH=$PATH:/usr/bin/:/bin
>> > PATH=$PATH:/usr/local/bin
>>
>> This defeats the purpose of using “--pure” as these directories contain
>> all sorts of things on a foreign distro, so you lose control over the
>> environment.

I am glad to tell you that I have followed all the commands, I will
copy some of them here just in case, and saved the output in my daily
journal of everything :)

guix environment --pure guix --ad-hoc coreutils findutils which
./bootstrap
./configure --localstatedir=/var
make
echo $? ->got 0
which guix -> got
no guix in 
(/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)
./pre-inst-env guix package --help -> worked fine!
./pre-inst-env guix package -i hello -> the same
./pre-inst-env guix package -i emacs
export PATH="/home/laura/.guix-profile/bin${PATH:+:}$PATH"
export INFOPATH="/home/laura/.guix-profile/share/info${INFOPATH:+:}$INFOPATH"
(with this two exports, I could run hello and emacs without problems)
./pre-inst-env guix package -i nss-certs
Played a lot with
./pre-inst-env guix build r-aspi
and
emacs gnu/packages/cran.scm
until I found out that there were syntax errors, mismatches in
parenthesis and so on, and in the last
./pre-inst-env guix build r-aspi got:
;;; note: source file /home/laura/guix/gnu/packages/cran.scm
;;;   newer than compiled /home/laura/guix/gnu/packages/cran.go
(still that) but:
successfully built /gnu/store/bmapswnk9li1nscfpirgzsy3npw9hyql-r-aspi-0.2.0.drv
/gnu/store/a3apqwf4hy67ms462hn802gk89x99mzh-r-aspi-0.2.0

I am following the contribution guide now, to send the patch, I ran
./pre-inst-env guix lint r-aspi
;;; note: source file /home/laura/guix/gnu/packages/cran.scm
;;;   newer than compiled /home/laura/guix/gnu/packages/cran.go
fetching CVE database for 2018...
fetching CVE database for 2017...
fetching CVE database for 2016...
fetching CVE database for 2015...

Is this output OK?

>
>
> Sorry, my bad, I missed that.
>
>>
>> --
>> Ricardo
>
> g_bor

Regards!
Laura

Re: [outreach] Help trying to create R package

[Gábor Boskovits]

Hello Ricardo,

Ricardo Wurmus  ezt írta (időpont: 2018. okt. 19., P
9:10):

>
> Hi Laura,
>
> > with guix environment --pure guix --ad-hoc coreutils findutils which (or
> -C)
> > I get, the output:
> > Command 'lesspipe' is available in the following places
> >  * /bin/lesspipe
> >  * /usr/bin/lesspipe
> > The command could not be located because '/bin:/usr/bin' is not
> > included in the PATH environment variable.
> > lesspipe: command not found
>
> This is because your shell initialization code (e.g. to set up the
> prompt) refers to lesspipe.  You can ignore this or remove the fancy
> initialization.
>
> > There, I run which guix and get:
> > which: no guix in
> >
> (/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)
>
> That’s because “--pure” resets the PATH; that’s by design.  The only
> problem you have is that your Guix is located elsewhere.  But why do you
> need Guix itself inside of an environment to build Guix?
>
> The point of using “guix environment --pure guix” is only to enter a
> clean environment containing everything you need to build Guix from
> source.  So once you’re inside of this environment you can run the
> bootstrap and configure scripts, and run make to compile the sources.
>
> To *use* that Guix you just built you need to use “./pre-inst-env guix”
> from the source directory.
>
> > The closest I got was by setting:
> > PATH=$PATH:/usr/bin/:/bin
> > PATH=$PATH:/usr/local/bin
>
> This defeats the purpose of using “--pure” as these directories contain
> all sorts of things on a foreign distro, so you lose control over the
> environment.
>

Sorry, my bad, I missed that.


> --
> Ricardo
>
g_bor

>

Re: [outreach] Help trying to create R package

[Ricardo Wurmus]

Hi Laura,

> with guix environment --pure guix --ad-hoc coreutils findutils which (or -C)
> I get, the output:
> Command 'lesspipe' is available in the following places
>  * /bin/lesspipe
>  * /usr/bin/lesspipe
> The command could not be located because '/bin:/usr/bin' is not
> included in the PATH environment variable.
> lesspipe: command not found

This is because your shell initialization code (e.g. to set up the
prompt) refers to lesspipe.  You can ignore this or remove the fancy
initialization.

> There, I run which guix and get:
> which: no guix in
> (/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)

That’s because “--pure” resets the PATH; that’s by design.  The only
problem you have is that your Guix is located elsewhere.  But why do you
need Guix itself inside of an environment to build Guix?

The point of using “guix environment --pure guix” is only to enter a
clean environment containing everything you need to build Guix from
source.  So once you’re inside of this environment you can run the
bootstrap and configure scripts, and run make to compile the sources.

To *use* that Guix you just built you need to use “./pre-inst-env guix”
from the source directory.

> The closest I got was by setting:
> PATH=$PATH:/usr/bin/:/bin
> PATH=$PATH:/usr/local/bin

This defeats the purpose of using “--pure” as these directories contain
all sorts of things on a foreign distro, so you lose control over the
environment.

--
Ricardo

Re: [outreach] Help trying to create R package

[Gábor Boskovits]

Helllo Laura,

Laura Lazzati  ezt írta (időpont: 2018.
okt. 19., P, 5:48):
>
> On Thu, Oct 18, 2018 at 10:05 PM Laura Lazzati
>  wrote:
> >
> > On Thu, Oct 18, 2018 at 3:17 PM Laura Lazzati
> >  wrote:
> > >
> > > On Thu, Oct 18, 2018 at 3:15 PM Ricardo Wurmus  wrote:
> > > >
> > > >
> > > > Hi Laura,
> > > >
> > > > > configure: checking for guile 2.2
> > > > > configure: found guile 2.2
> > > > > checking for guile-2.2... /usr/bin/guile-2.2
> > > > > checking for Guile version >= 2.2... 2.2.3
> > > > > checking for guild-2.2... no
> > > > > checking for guile-config-2.2... no
> > > > > checking for guile-tools-2.2... no
> > > > > configure: error: 'guild' binary not found; please check your
> > > > > guile-2.x installation.
> > > >
> > > > I recommend using “guix environment --pure guix” when on a foreign
> > > > distribution.
> > > Yes, I am trying that right now :) I'll let you know after reading
> > > Invoking guix environment and trying that. Hope this works
> > > >
> > I have tried lots of things today, not successfully.
> >
> > with guix environment guix, I get the same output that I get without
> > using guix environment (I mean, it uses the installed guix that I tend
> > to use generally)
> > the output of which guix in both cases is:
> > /home/laura/.config/guix/current/bin/guix
> >
> > with guix environment --pure guix --ad-hoc coreutils findutils which (or -C)
> > I get, the output:
> > Command 'lesspipe' is available in the following places
> >  * /bin/lesspipe
> >  * /usr/bin/lesspipe
> > The command could not be located because '/bin:/usr/bin' is not
> > included in the PATH environment variable.
> > lesspipe: command not found
> > There, I run which guix and get:
> > which: no guix in
> > (/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)
> >
> > The closest I got was by setting:
> > PATH=$PATH:/usr/bin/:/bin
> > PATH=$PATH:/usr/local/bin
> > And since I still got the issue with guile, I went to
> > /usr/bin/
> > and created a symlink
> > sudo ln -s /gnu/store/p9wm67w3rfw3hlb9iljgvsfn84mz4w9d-guile-2.2.4 
> > guile-2.2.4
> > (setting guile-2.2 that whas already there to a hidden file)
> >  Then the ./configure --localstatedir=/var
> > Worked fine, as well as the make (echo $? of both 0)
> > There, the result of which guix is:
> > /usr/local/bin/guix
> > ( a symlink to -> /var/guix/profiles/per-user/root/guix-profile/bin/guix)
> > I could run the ./pre-inst-env guix package -i hello, took a while but 
> > worked.
> > Complained about having to do:
> > export PATH="/home/laura/.guix-profile/bin${PATH:+:}$PATH"
> > Did so.

This seems to be ok so far.

> > And finally I appended my r-aspi definition to cran.scm
> > However, everything went wrong when trying to run: (sorry, the output
> > is long and I also get the same output with ./pre-inst-env lint
> > r-aspi)
> > ./pre-inst-env guix build r-aspi
> > ;;; note: source file /home/laura/guix/gnu/packages/cran.scm
> > ;;;   newer than compiled /home/laura/guix/gnu/packages/cran.go
> > guix build: warning: failed to load '(gnu packages abiword)':
> > exception thrown: # > #\t string: "a7izhueiqsdjs2eo7dfyb63cqje7mbqz6ennlyoynxxucbhpdnta"]

If I get you right, then the problem is introduced when you add the
package definition to cran.scm, since
./pre-inst-env guix package -i hello worked.

Since essentially everything is broken by the change, it is most
probable that you have some forms that
is not closed properly.
I would at first check for mismatching parenthesis.

If you can see nothing suspicious, then could you send a diff, so that
I can have a look?

> I have an update here, sorry, I can't help trying to figure out what's
> wrong. In the definition of my r-aspi, I found that the base32 was not
> well calculated, and I have already corrected that. Now this line does
> not appear anymore when throwing the same commands. the other warnings
> do. and the In procedure module-lookup: Unbound variable: continue
> too.  I also tried generating the new cran.go with guild compile
> cran.scm but the output was really awful. If you need it, when you
> answer back I paste it.
> > 262f6c0>
> > guix build: warning: failed to load '(gnu packages android)':
> > In procedure module-lookup: Unbound variable: googletest
> > guix build: warnin

Re: [outreach] Help trying to create R package

[Laura Lazzati]

On Thu, Oct 18, 2018 at 10:05 PM Laura Lazzati
 wrote:
>
> On Thu, Oct 18, 2018 at 3:17 PM Laura Lazzati
>  wrote:
> >
> > On Thu, Oct 18, 2018 at 3:15 PM Ricardo Wurmus  wrote:
> > >
> > >
> > > Hi Laura,
> > >
> > > > configure: checking for guile 2.2
> > > > configure: found guile 2.2
> > > > checking for guile-2.2... /usr/bin/guile-2.2
> > > > checking for Guile version >= 2.2... 2.2.3
> > > > checking for guild-2.2... no
> > > > checking for guile-config-2.2... no
> > > > checking for guile-tools-2.2... no
> > > > configure: error: 'guild' binary not found; please check your
> > > > guile-2.x installation.
> > >
> > > I recommend using “guix environment --pure guix” when on a foreign
> > > distribution.
> > Yes, I am trying that right now :) I'll let you know after reading
> > Invoking guix environment and trying that. Hope this works
> > >
> I have tried lots of things today, not successfully.
>
> with guix environment guix, I get the same output that I get without
> using guix environment (I mean, it uses the installed guix that I tend
> to use generally)
> the output of which guix in both cases is:
> /home/laura/.config/guix/current/bin/guix
>
> with guix environment --pure guix --ad-hoc coreutils findutils which (or -C)
> I get, the output:
> Command 'lesspipe' is available in the following places
>  * /bin/lesspipe
>  * /usr/bin/lesspipe
> The command could not be located because '/bin:/usr/bin' is not
> included in the PATH environment variable.
> lesspipe: command not found
> There, I run which guix and get:
> which: no guix in
> (/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)
>
> The closest I got was by setting:
> PATH=$PATH:/usr/bin/:/bin
> PATH=$PATH:/usr/local/bin
> And since I still got the issue with guile, I went to
> /usr/bin/
> and created a symlink
> sudo ln -s /gnu/store/p9wm67w3rfw3hlb9iljgvsfn84mz4w9d-guile-2.2.4 guile-2.2.4
> (setting guile-2.2 that whas already there to a hidden file)
>  Then the ./configure --localstatedir=/var
> Worked fine, as well as the make (echo $? of both 0)
> There, the result of which guix is:
> /usr/local/bin/guix
> ( a symlink to -> /var/guix/profiles/per-user/root/guix-profile/bin/guix)
> I could run the ./pre-inst-env guix package -i hello, took a while but worked.
> Complained about having to do:
> export PATH="/home/laura/.guix-profile/bin${PATH:+:}$PATH"
> Did so.
> And finally I appended my r-aspi definition to cran.scm
> However, everything went wrong when trying to run: (sorry, the output
> is long and I also get the same output with ./pre-inst-env lint
> r-aspi)
> ./pre-inst-env guix build r-aspi
> ;;; note: source file /home/laura/guix/gnu/packages/cran.scm
> ;;;   newer than compiled /home/laura/guix/gnu/packages/cran.go
> guix build: warning: failed to load '(gnu packages abiword)':
> exception thrown: # #\t string: "a7izhueiqsdjs2eo7dfyb63cqje7mbqz6ennlyoynxxucbhpdnta"]
I have an update here, sorry, I can't help trying to figure out what's
wrong. In the definition of my r-aspi, I found that the base32 was not
well calculated, and I have already corrected that. Now this line does
not appear anymore when throwing the same commands. the other warnings
do. and the In procedure module-lookup: Unbound variable: continue
too.  I also tried generating the new cran.go with guild compile
cran.scm but the output was really awful. If you need it, when you
answer back I paste it.
> 262f6c0>
> guix build: warning: failed to load '(gnu packages android)':
> In procedure module-lookup: Unbound variable: googletest
> guix build: warning: failed to load '(gnu packages avr)':
> In procedure module-lookup: Unbound variable: binutils
> guix build: warning: failed to load '(gnu packages axoloti)':
> In procedure module-lookup: Unbound variable: gcc-4.9
> guix build: warning: failed to load '(gnu packages bioconductor)':
> In procedure module-lookup: Unbound variable: perl-module-build
> guix build: warning: failed to load '(gnu packages bootloaders)':
> no binding `bc' in module (gnu packages algebra)
> guix build: warning: failed to load '(gnu packages chemistry)':
> In procedure module-lookup: Unbound variable: python2-numpy
> guix build: warning: failed to load '(gnu packages commencement)':
> In procedure module-lookup: Unbound variable: gnu-make
> guix build: warning: failed to load '(gnu packages debug)':
> In procedure module-lookup: Unbound variable: gnu-make
> guix build: warning: failed to load '(gnu packages display-managers)':
> In procedure m

Re: [outreach] Help trying to create R package

[Laura Lazzati]

On Thu, Oct 18, 2018 at 3:17 PM Laura Lazzati
 wrote:
>
> On Thu, Oct 18, 2018 at 3:15 PM Ricardo Wurmus  wrote:
> >
> >
> > Hi Laura,
> >
> > > configure: checking for guile 2.2
> > > configure: found guile 2.2
> > > checking for guile-2.2... /usr/bin/guile-2.2
> > > checking for Guile version >= 2.2... 2.2.3
> > > checking for guild-2.2... no
> > > checking for guile-config-2.2... no
> > > checking for guile-tools-2.2... no
> > > configure: error: 'guild' binary not found; please check your
> > > guile-2.x installation.
> >
> > I recommend using “guix environment --pure guix” when on a foreign
> > distribution.
> Yes, I am trying that right now :) I'll let you know after reading
> Invoking guix environment and trying that. Hope this works
> >
I have tried lots of things today, not successfully.

with guix environment guix, I get the same output that I get without
using guix environment (I mean, it uses the installed guix that I tend
to use generally)
the output of which guix in both cases is:
/home/laura/.config/guix/current/bin/guix

with guix environment --pure guix --ad-hoc coreutils findutils which (or -C)
I get, the output:
Command 'lesspipe' is available in the following places
 * /bin/lesspipe
 * /usr/bin/lesspipe
The command could not be located because '/bin:/usr/bin' is not
included in the PATH environment variable.
lesspipe: command not found
There, I run which guix and get:
which: no guix in
(/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/bin:/gnu/store/khk3lpx1li9y5zxzdppn9wi4n5g1qsgs-profile/sbin)

The closest I got was by setting:
PATH=$PATH:/usr/bin/:/bin
PATH=$PATH:/usr/local/bin
And since I still got the issue with guile, I went to
/usr/bin/
and created a symlink
sudo ln -s /gnu/store/p9wm67w3rfw3hlb9iljgvsfn84mz4w9d-guile-2.2.4 guile-2.2.4
(setting guile-2.2 that whas already there to a hidden file)
 Then the ./configure --localstatedir=/var
Worked fine, as well as the make (echo $? of both 0)
There, the result of which guix is:
/usr/local/bin/guix
( a symlink to -> /var/guix/profiles/per-user/root/guix-profile/bin/guix)
I could run the ./pre-inst-env guix package -i hello, took a while but worked.
Complained about having to do:
export PATH="/home/laura/.guix-profile/bin${PATH:+:}$PATH"
Did so.
And finally I appended my r-aspi definition to cran.scm
However, everything went wrong when trying to run: (sorry, the output
is long and I also get the same output with ./pre-inst-env lint
r-aspi)
./pre-inst-env guix build r-aspi
;;; note: source file /home/laura/guix/gnu/packages/cran.scm
;;;   newer than compiled /home/laura/guix/gnu/packages/cran.go
guix build: warning: failed to load '(gnu packages abiword)':
exception thrown: #
guix build: warning: failed to load '(gnu packages android)':
In procedure module-lookup: Unbound variable: googletest
guix build: warning: failed to load '(gnu packages avr)':
In procedure module-lookup: Unbound variable: binutils
guix build: warning: failed to load '(gnu packages axoloti)':
In procedure module-lookup: Unbound variable: gcc-4.9
guix build: warning: failed to load '(gnu packages bioconductor)':
In procedure module-lookup: Unbound variable: perl-module-build
guix build: warning: failed to load '(gnu packages bootloaders)':
no binding `bc' in module (gnu packages algebra)
guix build: warning: failed to load '(gnu packages chemistry)':
In procedure module-lookup: Unbound variable: python2-numpy
guix build: warning: failed to load '(gnu packages commencement)':
In procedure module-lookup: Unbound variable: gnu-make
guix build: warning: failed to load '(gnu packages debug)':
In procedure module-lookup: Unbound variable: gnu-make
guix build: warning: failed to load '(gnu packages display-managers)':
In procedure module-lookup: Unbound variable: gpgme
guix build: warning: failed to load '(gnu packages games)':
In procedure module-lookup: Unbound variable: unzip
guix build: warning: failed to load '(gnu packages image-viewers)':
In procedure module-lookup: Unbound variable: curl
guix build: warning: failed to load '(gnu packages license)':
In procedure module-lookup: Unbound variable: perl
guix build: warning: failed to load '(gnu packages make-bootstrap)':
In procedure module-lookup: Unbound variable: coreutils
guix build: warning: failed to load '(gnu packages maven)':
In procedure module-lookup: Unbound variable: java-plexus-container-default
guix build: warning: failed to load '(gnu packages syndication)':
In procedure module-lookup: Unbound variable: curl
guix build: warning: failed to load '(gnu packages unrtf)':
In procedure module-lookup: Unbound variable: coreutils
guix build: error: r-aspi: unknown package




> >
> > Ricardo
> >
Regards,
Laura

Re: [outreach] Help trying to create R package

[Laura Lazzati]

On Thu, Oct 18, 2018 at 3:15 PM Ricardo Wurmus  wrote:
>
>
> Hi Laura,
>
> > configure: checking for guile 2.2
> > configure: found guile 2.2
> > checking for guile-2.2... /usr/bin/guile-2.2
> > checking for Guile version >= 2.2... 2.2.3
> > checking for guild-2.2... no
> > checking for guile-config-2.2... no
> > checking for guile-tools-2.2... no
> > configure: error: 'guild' binary not found; please check your
> > guile-2.x installation.
>
> I recommend using “guix environment --pure guix” when on a foreign
> distribution.
Yes, I am trying that right now :) I'll let you know after reading
Invoking guix environment and trying that. Hope this works
>
> --
> Ricardo
>

Re: [outreach] Help trying to create R package

[Ricardo Wurmus]

Hi Laura,

> configure: checking for guile 2.2
> configure: found guile 2.2
> checking for guile-2.2... /usr/bin/guile-2.2
> checking for Guile version >= 2.2... 2.2.3
> checking for guild-2.2... no
> checking for guile-config-2.2... no
> checking for guile-tools-2.2... no
> configure: error: 'guild' binary not found; please check your
> guile-2.x installation.

I recommend using “guix environment --pure guix” when on a foreign
distribution.

-- 
Ricardo