Re: NFS mounts
Hi Ludo, > Indeed, the initrd would need an extra package, like this: ... > Can you try if it works? I will! However, I am almost sure that this is not sufficient. For a first test, I installed nfs-utils for manually mounting my NFS share. It fails because the daemon rpc.statd is not running. I suspect this will require an additional service, as I don't see any existing service that refers to rpc.statd. Konrad.
Re: 01/01: gnu: red-eclipse: Add store "data" package path as default.
On Tue, Oct 10, 2017 at 08:26:31AM -0400, Kei Kebreau wrote: > kkebreau pushed a commit to branch master > in repository guix. > > commit 42abb842f64f5dd7834cabd445a5f4d01f1e68a4 > Author: Adonay Felipe Nogueira > Date: Sun Aug 20 15:28:20 2017 -0300 > > gnu: red-eclipse: Add store "data" package path as default. > > * gnu/packages/games.scm (red-eclipse): Remove extra spaces. Make version > respect documentation. > [arguments]: Add "prefix" to make-flags. Add > "add-store-data-package-path-as-default" phase. Improve "copy-data" phase. > > Signed-off-by: Kei Kebreau > --- > gnu/packages/games.scm | 110 > ++--- > 1 file changed, 68 insertions(+), 42 deletions(-) [...] > @@ -133,6 +133,7 @@ >#:use-module (gnu packages gnuzilla) >#:use-module (gnu packages icu4c) >#:use-module (gnu packages networking) > + #:use-module (guix build utils) >#:use-module (guix build-system gnu) >#:use-module (guix build-system haskell) >#:use-module (guix build-system python) This module import created an ambiguous reference to 'which': WARNING: (gnu packages games): `which' imported from both (gnu packages base) and (guix build utils) I don't know if it will be a problem in practice. signature.asc Description: PGP signature
Fwd: HPC sysadmin job offer in Berlin
Hi all, the Berlin Institute of Health (a collaboration between the Charité and the MDC) is looking for an HPC sysadmin / team leader: https://www.mdc-berlin.de/jobs/808418/10832 The MDC is one of the largest institutional users of Guix. The BIH is using separate HPC clusters, so I’m pretty sure they don’t use Guix yet. But since the MDC has already accumulated some experience with the use of Guix in HPC environments, I don’t think it would be impossible to deploy it also at the BIH after some trials. Applications close in 5 days (15 Oct 2017). (I’m not making any decisions wrt this position.) -- Ricardo
Re: Go packaging
On Wed, Oct 04, 2017 at 10:22:25AM -0400, Leo Famulari wrote: > That package.json file is not a standard thing in the Go world. > I've found that Go applications use a variety of dependency manifest > formats, or just use Git submodules. Guix is a good thing then :). Also it means that they don't really enforce a dependency graph. How can you enforce something if you have many implementations? The enforcement is only at the single package level. > Rather, I think we should have a special go-package procedure, used in > the inputs field of the calling application, which would build the > relevant library modules of the correct Git commit. Does that make > sense? Yes. Since you can do a 'go build' I think it is possible to do this in a traditional way. It sucks that GO has so many small dependencies (similar to the node mess). But maybe we can import them somehow. Does the build tool show the graph? It is interesting that different packages have different git checkout dependencies (so different hash values for the same package go-ssl or whatever). For developers this is great because users end up with the exact same dependency graph. But for Guix I think we can ignore this. It is what we are doing today. It is easy to create a deployment environment in Guix that was never tried before. Therefore, we also don't really care. We just provide the latest and see if that works. So, I suggest to import just one version of go-ssl and cross fingers it works. If it doesn't - well then it gets a bit harder and we'll have to deal with multiple versions. > > We ought to have a look at how Nix packaged Go builds because they are > > already have a solution. Be interesting to see if they found a way to > > compile packages 'greedily', the way Python does it. > > I looked at their build system itself a few weeks ago when I was still > learning how Go compilation works. I agree, it would be fruitful to see > how they handle the issues I've raised here. Any update? Pj. --
Re: Go packaging
Ludovic Courtès transcribed 0.4K bytes: > Leo Famulari skribis: > > > I think we should do "go-$upstreamname" instead. Golang is not the name > > of the language, but rather the domain name (go.org was apparently not > > available), and a term that has been adopted by the community. But, it > > would be good to save 4 characters here. > > I’m all for “go-” instead of “golang-”. > > Ludo’, happy to help paint the shed. :-) Yes, go for it. My 2go's (and good to see some progress in Go on Guix). -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://dist.ng0.infotropique.org/dist/keys/ https://www.infotropique.org https://ng0.infotropique.org signature.asc Description: PGP signature
Re: 01/01: gnu: red-eclipse: Add store "data" package path as default.
Leo Famulari writes: > On Tue, Oct 10, 2017 at 08:26:31AM -0400, Kei Kebreau wrote: >> kkebreau pushed a commit to branch master >> in repository guix. >> >> commit 42abb842f64f5dd7834cabd445a5f4d01f1e68a4 >> Author: Adonay Felipe Nogueira >> Date: Sun Aug 20 15:28:20 2017 -0300 >> >> gnu: red-eclipse: Add store "data" package path as default. >> >> * gnu/packages/games.scm (red-eclipse): Remove extra spaces. Make version >> respect documentation. >> [arguments]: Add "prefix" to make-flags. Add >> "add-store-data-package-path-as-default" phase. Improve "copy-data" >> phase. >> >> Signed-off-by: Kei Kebreau >> --- >> gnu/packages/games.scm | 110 >> ++--- >> 1 file changed, 68 insertions(+), 42 deletions(-) > > [...] > >> @@ -133,6 +133,7 @@ >>#:use-module (gnu packages gnuzilla) >>#:use-module (gnu packages icu4c) >>#:use-module (gnu packages networking) >> + #:use-module (guix build utils) >>#:use-module (guix build-system gnu) >>#:use-module (guix build-system haskell) >>#:use-module (guix build-system python) > > This module import created an ambiguous reference to 'which': > > WARNING: (gnu packages games): `which' imported from both (gnu > packages base) and (guix build utils) > > I don't know if it will be a problem in practice. It looks like Ludovic took care of this in commit db9c49f4999d4e5f6eb0565a6a80892131c55670. Thank you for the notification, though. signature.asc Description: PGP signature
