Re: creating a profile
Il giorno mer, 18/08/2021 alle 19.48 +0200, Edouard Klein ha scritto: > Hi ! > > You can pass the --profile option to most guix subcommands. > > To install guile-commonmark in a profile, it would be a simple: > > guix install --profile=/tmp/toto guile-commonmark > > To install only its dependencies, the following bash one liner will do: > > guix install --profile=/tmp/toto $(guix show guile-commonmark | grep > dependencies: | sed -e 's/dependencies://') Thank you ! But I think I found the answer I was looking for: guix environment -r some/path/to/some_file https://guix.gnu.org/zh-CN/manual/en/html_node/Invoking-guix-environment.html#Invoking-guix-environment
guix pack and exposing ports
Hello, Please bear with me since I am not that very docker savvy. As far as I understand, normally, one can expose certain ports in a docker description file. But, how to do that when using `guix pack -f docker` command where the docker recipe is hidden from the user? Also, I note I'm getting ~10 GiG image for a flimsy program depending on R and shiny. Somehow that doesn't feel right. :)
Re: creating a profile
Hi ! You can pass the --profile option to most guix subcommands. To install guile-commonmark in a profile, it would be a simple: guix install --profile=/tmp/toto guile-commonmark To install only its dependencies, the following bash one liner will do: guix install --profile=/tmp/toto $(guix show guile-commonmark | grep dependencies: | sed -e 's/dependencies://') Enjoy ! Cheers, Edouard. Adriano Peluso writes: > I'd like to create a profile containing the dependencies of guile- > commonmark and I'm a bit confused about how to
creating a profile
I'd like to create a profile containing the dependencies of guile- commonmark and I'm a bit confused about how to
Re: File not found during package build
Hi,
On Sat, 24 Jul 2021 at 18:32, phodina wrote:
> (define-public novaboot
> (package
> (name "novaboot")
> (version "20210126a")
> (source (origin
> (method git-fetch)
> (uri
> (git-reference
> (url "https://github.com/wentasah/novaboot";)
> (commit version)))
> (sha256
> (base32
> "1xwgxpngjp345fg4xmacyxm21wqvx4h6n6b51wnvivvzjj9vga4z"
> (build-system gnu-build-system)
> (inputs `(("perl" ,perl) ("perl-expect" ,perl-expect)))
Where is defined the symbol ’perl-expect’?
> (arguments
> '(#:phases (modify-phases %standard-phases
> (delete 'configure)
>(add-before 'build 'set-prefix-in-makefile
> (lambda* (#:key outputs #:allow-other-keys)
> (let ((out (assoc-ref outputs "out")))
> (substitute* "Makefile"
> (("PREFIX=.*")
>(string-append "PREFIX="
>"\n")))
> (substitute* "Makefile"
>(("DESTDIR=.*")
> (string-append "DESTDIR=" out "\n"
> ))
>(replace 'check
>(lambda* (#:key outputs #:allow-other-keys)
> (chdir "tests")
>(chmod "wvtool" #o555)
>(invoke "make"))
> (synopsis "A tool that automates booting of operating systems on target
> hardware or in qemu")
> (description "Novaboot is a tool that automates booting of operating
> systems on target hardware (typically embedded boards) or in Qemu. Initially,
> it was developed to boot NOVA Microhypervisor (hence the name), but nowadays
> is well suited for booting Linux (and perhaps other OSes) too.")
> (home-page "https://github.com/wentasah/novaboot";)
> (license license:gpl2)))
Then I get this, which means that it also depends on Python. See in the log:
--8<---cut here---start->8---
starting phase `patch-generated-file-shebangs'
[...]
patch-shebang: ./tests/wvtool: warning: no binary for interpreter `python3'
found in $PATH
--8<---cut here---end--->8---
Adding Python in the ’inputs’ list, I get:
--8<---cut here---start->8---
starting phase `check'
./wvtool runall ./novaboot.wv ./parser.wv ./expect.wv ./server.wv ./uboot.wv
Traceback (most recent call last):
File "./wvtool", line 131, in
term = Term()
File "./wvtool", line 71, in __init__
if os.environ['TERM'] == 'dumb':
File
"/gnu/store/9w9jvy3bgjg4qaqmrij01nbppiccqr7c-python-3.8.2/lib/python3.8/os.py",
line 675, in __getitem__
raise KeyError(key) from None
KeyError: 'TERM'
make: *** [Makefile:6: all] Error 1
--8<---cut here---end--->8---
Note that I am not convinced that ’chmod’ is required here.
Well to be continued to have the package working. ;-)
Hope that helps,
simon
Re: Guix Hang Out Attempt 2 and an Unoffical Guix Hackathon/config party
Hi Joshua, On Thu, 22 Jul 2021 at 21:12, jbra...@dismail.de wrote: > Let's try to do another guix hang out next Tuesday, July 27th! We'll meet > at 7pm UTC. (I think that is 3pm EST). That is one of the few days I > usually have officially off, so I will meet you all with jitsi: Cool! Thanks for the initiative even if I am late to the party. Maybe next time. All the best, simon
Re: Package variant defined in manifest not visible by Guix
Hi Philippe, On Wed, 18 Aug 2021 at 10:57, Philippe SWARTVAGHER wrote: > Le 16/08/2021 à 16:34, Ricardo Wurmus a écrit : >> There seems to be a small misunderstanding. You defined a package >> variant, but that’s not a manifest. A manifest describes the complete >> contents of a profile; i.e. it’s a list of packages that Guix should >> install. >> >> Here are three different ways that should work for you: >> >> 1) Build a single package from a file. >> >> Now we can build the package specified in the file: >> >> guix build --file=this-file.scm >> >> >> 2) Build a whole manifest from a file. >> >> Here the file must evaluate to a manifest value, not just a single >> package. > > Ok, I was missing the line to evaluate to a manifest, instead of a > single package. > > >> Then build the profile from the manifest file: >> >> guix build --manifest=this-file.scm >> >> >> 3) Create a module and use it however you want. >> >> You can make the custom package available to any Guix command by >> putting it into a Guile module and then informing Guix about the >> module. This is a little more effort as you need more boilerplate >> code to define the module (and the file name needs to match the moule >> header, etc). >> >> Hope this helps! > > Sure, it helps ! Thanks a lot ! However, I still have some questions: > > - I don't really see the difference, or more precisely: the difference > of goal, between defining the package in a simple file (solution 1) and > using a manifest (solution 2). Solution #1 (option --file) builds the package defined by FILE. Solution #2 (option --manifest) builds the packages listed in FILE. > - The following command builds the package as defined in the *file*, > without running tests: > > guix build -c 2 -f starpu-maxnodes1-file.scm > --without-tests=starpu-maxnodes1 > > So package transformations seem to work. However: > > guix build -c 2 -f starpu-maxnodes1-file.scm chameleon > --with-input=starpu=starpu-maxnodes1 --with-input=openblas=mkl > --without-tests=starpu-maxnodes1 > > doesn't work: starpu-maxnodes1 is an unknown package... > > The same happens if I use a manifest instead of a file to define > starpu-maxnodes1: > > guix build -c 2 -m starpu-maxnodes1.scm --with-input=openmpi=nmad > --without-tests=starpu-maxnodes1 > > works (without running tests), however: > > guix build -c 2 -m starpu-maxnodes1.scm chameleon > --with-input=starpu=starpu-maxnodes1 --with-input=openblas=mkl > --with-input=openmpi=nmad --without-tests=starpu-maxnodes1 > > doesn't. I think what you want is the option --load-path. Create a folder and put the file starpu-maxnodes1.scm inside; for instance ’/tmp/example/starpu-maxnodes1.scm’. Then, the command-line: guix build -c 2 -L /tmp/example chameleon --with-input=starpu=starpu-maxnodes1 should do the job. In this case, the file ’/tmp/example/starpu-maxnodes1.scm’ does not have to return a package or a manifest but instead define a module. Does it make sense? > I guess I have to put all transformations of several packages in a > single manifest, one cannot combine manifest and CLI options; packages > defined in manifest aren't available for use in CLI transformations > (although the working --without-tests seems to be a counter argument). > Am I right ? As Ricardo explained, the aim manifest is to describe the complete contents of a profile, so from my understanding, the manifest should also contain the transformation. Well, I think what you want is the option ’--load-path’ and not a manifest or the option ’--file’. Hope that helps, simon
Re: Package variant defined in manifest not visible by Guix
Hello, Le 16/08/2021 à 16:34, Ricardo Wurmus a écrit : > There seems to be a small misunderstanding. You defined a package > variant, but that’s not a manifest. A manifest describes the complete > contents of a profile; i.e. it’s a list of packages that Guix should > install. > > Here are three different ways that should work for you: > > 1) Build a single package from a file. > > Now we can build the package specified in the file: > > guix build --file=this-file.scm > > > 2) Build a whole manifest from a file. > > Here the file must evaluate to a manifest value, not just a single > package. Ok, I was missing the line to evaluate to a manifest, instead of a single package. > Then build the profile from the manifest file: > > guix build --manifest=this-file.scm > > > 3) Create a module and use it however you want. > > You can make the custom package available to any Guix command by > putting it into a Guile module and then informing Guix about the > module. This is a little more effort as you need more boilerplate > code to define the module (and the file name needs to match the moule > header, etc). > > Hope this helps! Sure, it helps ! Thanks a lot ! However, I still have some questions: - I don't really see the difference, or more precisely: the difference of goal, between defining the package in a simple file (solution 1) and using a manifest (solution 2). - The following command builds the package as defined in the *file*, without running tests: guix build -c 2 -f starpu-maxnodes1-file.scm --without-tests=starpu-maxnodes1 So package transformations seem to work. However: guix build -c 2 -f starpu-maxnodes1-file.scm chameleon --with-input=starpu=starpu-maxnodes1 --with-input=openblas=mkl --without-tests=starpu-maxnodes1 doesn't work: starpu-maxnodes1 is an unknown package... The same happens if I use a manifest instead of a file to define starpu-maxnodes1: guix build -c 2 -m starpu-maxnodes1.scm --with-input=openmpi=nmad --without-tests=starpu-maxnodes1 works (without running tests), however: guix build -c 2 -m starpu-maxnodes1.scm chameleon --with-input=starpu=starpu-maxnodes1 --with-input=openblas=mkl --with-input=openmpi=nmad --without-tests=starpu-maxnodes1 doesn't. I guess I have to put all transformations of several packages in a single manifest, one cannot combine manifest and CLI options; packages defined in manifest aren't available for use in CLI transformations (although the working --without-tests seems to be a counter argument). Am I right ? Thanks again for your help ! -- Philippe SWARTVAGHER PhD Student TADaaM team, Inria Bordeaux Sud-Ouest
