Re: Creating a package using two sources/origins
Heya, On Mon Dec 12, 2022 at 11:58 PM GMT, dabb...@gmail.com wrote: > (define-public my-help > (package > (inherit hello) > (name "my-help") > (arguments > #~(modify-phases %standard-phases > (add-after 'unpack 'unpack-extra-sources > (lambda _ > (copy-recursively #+xenomai-origin > "extra-source-directory"))) Nope, that's not quite correct. Your ARGUMENTS should look like this: (arguments (list #:phases #~(modify-phases %standard-phases (add-after 'unpack 'unpack-extra-sources (lambda _ (copy-recursively #+xenomai-origin "extra-source-directory")) You can think of ARGUMENTS as a bunch of keyword arguments to pass to the procedure that runs the build. > Finally, if not too much out of scope, can you explain me why the #+ > ungexp can accept an origin object instead of a package? I assumed > from the documentation that gexp where used only to reference among > derivation of packages. You've seen a ``.drv'' path being printed out by the CLI, right? They contain instructions to build a store item. Packages are /lowered/ into DERIVATIONs, but so are ORIGINs, LOCAL-FILEs, COMPUTED-FILEs, and any other kind of "file-like object" or "lowerable object", such as the object you create with FILE-APPEND. The thing they all have it common is that they all have a lowering procedure defined using DEFINE-GEXP-COMPILER; you can see a few examples of that in ``guix/gexp.scm'' and ``guix/packages.scm''. So, you can use UNGEXP and UNGEXP-NATIVE on anything that has been DEFINE-GEXP-COMPILERed, and its derivation will be built and its store path substituted. -- ( signature.asc Description: PGP signature
Problems running Guix System initrd on an i.MX6 ARM board
Hi Guix! I've been trying for some time to run Guix System on an ARM board (a TS-7970 with an i.MX6 Cortex A9 CPU). I wanted to cross-compile the image for speed and efficiency, and stumbled upon some problems on the way, such as https://issues.guix.gnu.org/44924, fixed on core-updates. Then it took me some time to figure out that Guile 3.0.7 was segfaulting when running the initrd's init script, which would cause the following kernel panic and backtrace: --8<---cut here---start->8--- [5.913371] ALSA device list: [5.913374] #0: On-board Codec [5.913376] #1: imx-hdmi-soc [5.921483] sdhci-esdhc-imx 219.usdhc: card claims to support voltages below defined range [5.938332] mmc0: new SDIO card at address 0001 [5.987225] mmc2: new DDR MMC card at address 0001 [5.998025] mmcblk2: mmc2:0001 MMC04G 3.60 GiB [6.009623] mmcblk2boot0: mmc2:0001 MMC04G partition 1 16.0 MiB [6.020181] mmcblk2boot1: mmc2:0001 MMC04G partition 2 16.0 MiB [6.031772] mmcblk2rpmb: mmc2:0001 MMC04G partition 3 128 KiB [6.957080] Freeing unused kernel memory: 1024K (80e0 - 80f0) [6.967865] Kernel panic - not syncing: Attempted to kill init! exitcode=0x8b00 [6.967865] [6.977015] CPU3: stopping [6.979732] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.9.11-tsimx #1 [6.986174] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [6.992704] Backtrace: [6.995189] [<80111d48>] (dump_backtrace) from [<80111f38>] (show_stack+0x18/0x1c) [7.002765] r7: r6:2193 r5: r4:80f2fecc [7.008437] [<80111f20>] (show_stack) from [<8054d61c>] (dump_stack+0x80/0x9c) [7.015669] [<8054d59c>] (dump_stack) from [<8010d8dc>] (handle_IPI+0xe0/0x178) [7.022981] r7: r6:d80b1f18 r5:0003 r4:80e7f034 [7.028648] [<8010d7fc>] (handle_IPI) from [<801014d8>] (gic_handle_irq+0x70/0x78) [7.036222] r7:f4a01100 r6:80f0358c r5:f4a00100 r4:d80b1f18 [7.041895] [<80101468>] (gic_handle_irq) from [<80a0a34c>] (__irq_svc+0x6c/0xa8) [7.049380] Exception stack(0xd80b1f18 to 0xd80b1f60) [7.054434] 1f00: 0001 [7.062617] 1f20: 59eaf000 dad2fec0 9fdcb41d 9f4ecbfd dad2f1a8 0001 [7.070800] 1f40: 0001 d80b1f9c d80b1f68 d80b1f68 80826350 80826374 6113 [7.078981] r7:d80b1f4c r6: r5:6113 r4:80826374 [7.084651] [<80826284>] (cpuidle_enter_state) from [<80826488>] (cpuidle_enter+0x1c/0x20) [7.092921] r10:d80b1fc0 r9:80e801a0 r8:80f030f4 r7:d80b r6:0003 r5:80f08cd4 [7.100752] r4:dad2f1a8 [7.103301] [<8082646c>] (cpuidle_enter) from [<80165ccc>] (call_cpuidle+0x3c/0x40) [7.110966] [<80165c90>] (call_cpuidle) from [<80165f48>] (cpu_startup_entry+0x188/0x1a8) [7.119149] [<80165dc0>] (cpu_startup_entry) from [<8010d5b8>] (secondary_start_kernel+0x134/0x164) [7.128196] r7:80f8d320 r4:80f14490 [7.131779] [<8010d484>] (secondary_start_kernel) from [<1010156c>] (0x1010156c) [7.139178] r7:80f8d320 r6:10c03c7d r5:0051 r4:6809806a [7.144839] CPU1: stopping [7.147554] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.11-tsimx #1 [7.153996] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [7.160524] Backtrace: [7.162999] [<80111d48>] (dump_backtrace) from [<80111f38>] (show_stack+0x18/0x1c) [7.170573] r7: r6:2193 r5: r4:80f2fecc [7.176242] [<80111f20>] (show_stack) from [<8054d61c>] (dump_stack+0x80/0x9c) [7.183471] [<8054d59c>] (dump_stack) from [<8010d8dc>] (handle_IPI+0xe0/0x178) [7.190783] r7: r6:d80adf18 r5:0001 r4:80e7f034 [7.196449] [<8010d7fc>] (handle_IPI) from [<801014d8>] (gic_handle_irq+0x70/0x78) [7.204022] r7:f4a01100 r6:80f0358c r5:f4a00100 r4:d80adf18 [7.209689] [<80101468>] (gic_handle_irq) from [<80a0a34c>] (__irq_svc+0x6c/0xa8) [7.217173] Exception stack(0xd80adf18 to 0xd80adf60) [7.27] df00: 0001 [7.230410] df20: 59e93000 dad13ec0 9fdcb2cf 9f4ecbfd dad131a8 0001 [7.238592] df40: 0001 d80adf9c d80adf68 d80adf68 80826350 80826374 6013 [7.246773] r7:d80adf4c r6: r5:6013 r4:80826374 [7.252439] [<80826284>] (cpuidle_enter_state) from [<80826488>] (cpuidle_enter+0x1c/0x20) [7.260709] r10:d80adfc0 r9:80e801a0 r8:80f030f4 r7:d80ac000 r6:0001 r5:80f08cd4 [7.268539] r4:dad131a8 [7.271082] [<8082646c>] (cpuidle_enter) from [<80165ccc>] (call_cpuidle+0x3c/0x40) [7.278746] [<80165c90>] (call_cpuidle) from [<80165f48>] (cpu_startup_entry+0x188/0x1a8) [7.286931] [<80165dc0>] (cpu_startup_entry) from [<8010d5b8>] (secondary_start_kernel+0x134/0x164) [7.295979] r7:80f8d320 r4:80f14490 [7.299560] [<8010d484>] (secondary_start_kernel) from [<
Re: Creating a package using two sources/origins
Hi (
as you see I'm not yet practical with G-exp and I still have to
understand where exactly they are useful or not.
On Mon, Dec 12, 2022 at 11:43 PM ( wrote:
>
> Heya,
>
> What you need to do is combine ORIGIN with UNGEXP-NATIVE:
>
> #~(modify-phases %standard-phases
> (add-after 'unpack 'unpack-extra-sources
> (lambda _
> (copy-recursively #+(origin ...)
> "extra-source-directory"
>
> When the build script implementing the phases is... built, this lambda will
> look
> like this:
>
> (lambda _
> (copy-recursively "/gnu/store/...-extra-sources"
> "extra-source-directory"))
>
> Roughly, the UNGEXP-NATIVE compiles the origin directory for the host
> architecture, then substitutes itself for a string containing the output path
> of
> the compiled store item.
>
> -- (
This is a short extract of my custom .scm file:
(define xenomai-version "3.1")
(define xenomai-origin
(origin
(method url-fetch)
(uri (string-append
"https://xenomai.org/downloads/xenomai/stable/xenomai-";
xenomai-version
".tar.bz2"))
(sha256
(base32
"1064l80p9fdbp553mrbin4s7f5qhnwifhfds8a9wl6p6s10alsb4"
(define-public my-help
(package
(inherit hello)
(name "my-help")
(arguments
#~(modify-phases %standard-phases
(add-after 'unpack 'unpack-extra-sources
(lambda _
(copy-recursively #+xenomai-origin
"extra-source-directory")))
First of all, I'm not sure whether the gexp that you suggested is
placed correctly within the "arguments" field of the package.
Second, if I try to build the above my-help package I get an exception
with this backtrace:
pcp@PCP3600 ~/guix [env]$ ./pre-inst-env guix build --keep-failed my-help
Backtrace:
In ice-9/boot-9.scm:
1747:15 19 (with-exception-handler # ?)
1752:10 18 (with-exception-handler _ _ #:unwind? _ # _)
In guix/ui.scm:
449:6 17 (_)
In guix/scripts/build.scm:
714:5 16 (_)
In srfi/srfi-1.scm:
673:15 15 (append-map # ?)
586:17 14 (map1 ("x86_64-linux"))
In guix/scripts/build.scm:
716:21 13 (_ _)
In guix/store.scm:
1382:11 12 (map/accumulate-builds # ?)
1300:8 11 (call-with-build-handler # ?)
In guix/scripts/build.scm:
670:16 10 (_ #)
659:24 9 (_ # ?)
In guix/packages.scm:
1317:17 8 (supported-package? # ?)
In guix/memoization.scm:
101:0 7 (_ # # ?)
In guix/packages.scm:
1295:37 6 (_)
1555:16 5 (package->bag _ _ _ #:graft? _)
1652:22 4 (thunk)
In unknown file:
3 (_ "my-help-2.12.1" #:system "x86_64-linux" #:source # # ?)
In ice-9/boot-9.scm:
1685:16 2 (raise-exception _ #:continuable? _)
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure apply: Apply to non-list: #https://xenomai.org/downloads/xenomai/stable/xenomai-3.1.tar.bz2";
#
() 7f52ce4af960>:out> "extra-source-directory"
/home/pcp/guix/gnu/packages/dabbede.scm:31:6 7f52cc88c9c0>
Finally, if not too much out of scope, can you explain me why the #+
ungexp can accept an origin object instead of a package? I assumed
from the documentation that gexp where used only to reference among
derivation of packages.
Regards
Re: Creating a package using two sources/origins
Heya, On Mon Dec 12, 2022 at 10:35 PM GMT, dabb...@gmail.com wrote: > By looking into linux-libre package definition, I see no problem in > downloading and patching the proper kernel source, however I don't > understand how I am supposed to specify in the package definition that > we need an additional source tree in the build process. > What would you suggest? Using snippets or additional build-phases? > Either way, I'm not skilled enough to download a compressed tar and > unpack it in a reachable directory at the build stage. I'm only aware > of the package's "origin" function to accomplish that. What is the > best way to do the same in a snippet or phase? What you need to do is combine ORIGIN with UNGEXP-NATIVE: #~(modify-phases %standard-phases (add-after 'unpack 'unpack-extra-sources (lambda _ (copy-recursively #+(origin ...) "extra-source-directory" When the build script implementing the phases is... built, this lambda will look like this: (lambda _ (copy-recursively "/gnu/store/...-extra-sources" "extra-source-directory")) Roughly, the UNGEXP-NATIVE compiles the origin directory for the host architecture, then substitutes itself for a string containing the output path of the compiled store item. -- ( signature.asc Description: PGP signature
Creating a package using two sources/origins
Dear Guix members, I would like to contribute to the project by creating a package for linux-xenomai (a real-time extension to the linux kernel, see https://source.denx.de/Xenomai/xenomai/-/wikis/home). My issue is that, according to xenomai's build instructions, I am supposed to use both a mainstream patched kernel (I'm pretty sure that a deblobbed linux-libre kernel can work too) and a .tar.bz2 source tree that contains the user-space libraries and binaries but also some scripts for preparing the kernel before building. By looking into linux-libre package definition, I see no problem in downloading and patching the proper kernel source, however I don't understand how I am supposed to specify in the package definition that we need an additional source tree in the build process. What would you suggest? Using snippets or additional build-phases? Either way, I'm not skilled enough to download a compressed tar and unpack it in a reachable directory at the build stage. I'm only aware of the package's "origin" function to accomplish that. What is the best way to do the same in a snippet or phase? Thanks for the advice. I need this input to study more the topic ;-) Regards, Davide
Re: Using Makefile to run guix shell?
> > So the true question is how to implement? If using Shell script > > Using shell scripts would mean one script per command? I usually > have a set of commands that I would like to be able to run for > every project. I would like to minimize the number of extra files > in my project directory, so I would lean towards your Scheme API > option. There's nothing that stops a shell script from exposing multiple commands. Consider for example the SysV init scripts. They typically utilize the `case` statement to support commands like "start", "stop", "status", etc. So you could craft a solution where from the root of your project you can run `./my-script.sh command1`, `./my-script.sh command2`, etc. Also, you mentioned you "would like to minimize the number of extra files" in your "project directory". Does that mean you don't actually mind creating more files in a *subdirectory* thereof? If you don't, how about putting command scripts under, say, `my-scripts/` and running them as `my-scripts/command1.sh`, `my-scripts/command2.sh`, etc.? Wojtek -- (sig_start) website: https://koszko.org/koszko.html PGP: https://koszko.org/key.gpg fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A Meet Kraków saints! #25: blessed Maksymilian Binkiewicz Poznaj świętych krakowskich! #25: błogosławiony Maksymilian Binkiewicz https://pl.wikipedia.org/wiki/Maksymilian_Binkiewicz -- (sig_end) On Mon, 12 Dec 2022 12:55:39 -0500 Peter Polidoro wrote: > zimoun writes: > > > Because calling “guix serial-shell PORT=/dev/ttyUSB0” or > > “guix-serial-shell PORT=/dev/ttyUSB0” is almost identical. :-) > > Yes good point. > > > > > So the true question is how to implement? If using Shell script > > Using shell scripts would mean one script per command? I usually > have a set of commands that I would like to be able to run for > every project. I would like to minimize the number of extra files > in my project directory, so I would lean towards your Scheme API > option. > > > From my point of view, in this case, maybe an extension is a > > heavy > > solution when a quick script would just smooth the workflow. > > Maybe it is too heavy a solution, but I do like the idea of just > needing the channels.scm, the guix.scm, and maybe a Makefile for > people who do not use guix. Or am I wrong and I would need more > files than that? > > I also like that a user could find information about the project > commands using guix help. Can command extensions be grouped into a > single sub-command so I would not feel like I am polluting the > guix command namespace? Like could I run something like "guix > project serial-shell PORT=/dev/ttyUSB0" or "guix project help" to > get the set of project-specific commands that I added as > extensions? > > Is there some sort of extension bootstrap process where you run an > intial command in the project directory every session to add the > extensions, then the extensions are available for future commands? pgpvd0lQ5tFWA.pgp Description: OpenPGP digital signature
Re: Using Makefile to run guix shell?
zimoun writes: Because calling “guix serial-shell PORT=/dev/ttyUSB0” or “guix-serial-shell PORT=/dev/ttyUSB0” is almost identical. :-) Yes good point. So the true question is how to implement? If using Shell script Using shell scripts would mean one script per command? I usually have a set of commands that I would like to be able to run for every project. I would like to minimize the number of extra files in my project directory, so I would lean towards your Scheme API option. From my point of view, in this case, maybe an extension is a heavy solution when a quick script would just smooth the workflow. Maybe it is too heavy a solution, but I do like the idea of just needing the channels.scm, the guix.scm, and maybe a Makefile for people who do not use guix. Or am I wrong and I would need more files than that? I also like that a user could find information about the project commands using guix help. Can command extensions be grouped into a single sub-command so I would not feel like I am polluting the guix command namespace? Like could I run something like "guix project serial-shell PORT=/dev/ttyUSB0" or "guix project help" to get the set of project-specific commands that I added as extensions? Is there some sort of extension bootstrap process where you run an intial command in the project directory every session to add the extensions, then the extensions are available for future commands?
Running test for a package gives me an error 243
Hi Guixers Running the openfoam-10 tests during the package build gives me an error 243 [1]. Running these tests locally in a guix shell does not produce any errors. I could not figure out what this error code means, but I found similar problems on the internet (mostly regarding docker and npm) which had something to do with running as root vs. running as a user. Has someone an idea what might be the issue? I tried making the files writable, but that did not had any effect. Cheers, Reza [1] starting phase `check' wmake Test-fvMeshTools make[1]: Entering directory '/tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/test/fvMeshTools/Test-fvMeshTools' Making dependency list for source file Test-fvMeshTools.C g++ -std=c++14 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -IfaceSelection -I/tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/src/finiteVolume/lnInclude -I/tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/src/dynamicMesh/lnInclude -I/tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/src/meshTools/lnInclude -IlnInclude -I. -I/tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/src/OpenFOAM/lnInclude -I/tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/src/OSspecific/POSIX/lnInclude -fPIC -c Test-fvMeshTools.C -o /tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/platforms/linux64GccDPInt32Opt/test/fvMeshTools/Test-fvMeshTools/Test-fvMeshTools.o g++ -std=c++14 -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -O3 -DNoRepository -ftemplate-depth-100 -IfaceSelection -I/tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/src/finiteVolume/lnInclude -I/tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/src/dynamicMesh/lnInclude -I/tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/src/meshTools/lnInclude -IlnInclude -I. -I/tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/src/OpenFOAM/lnInclude -I/tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/src/OSspecific/POSIX/lnInclude -fPIC -Wl,-rpath=/gnu/store/2656bcxjnjc3x0rkjafz4fdp20vdlc93-paraview-5.9.1/lib,-rpath=/gnu/store/8qv5kb2fgm4c3bf70zcg9l6hkf3qzpw9-zlib-1.2.11/lib,-rpath=/gnu/store/1akza97k9ssrkj9n2yzb6abvzba6b6d3-openmpi-4.1.4/lib,-rpath=/gnu/store/mk4schdzprjas1d4jcwl43rlslgy4f7r-pt-scotch32-7.0.1/lib,-rpath=/gnu/store/pmq05n0q25v4qjyibxfrp53v4391k7vh-mpfr-4.1.0/lib,-rpath=/gnu/store/14cqc52mfhkbl2sp76ilcnwmkm65kmly-metis-5.1.0/lib,-rpath=/gnu/store/fwbiihd2sbhai63y1pvvdh0f2bakfzrf-gmp-6.2.1/lib,-rpath=/gnu/store/xdayvzcay9fp8px077qwk6mw9qgzj249-cgal-5.2.2/lib,-rpath=/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/lib,-rpath=/gnu/store/s0a9z2n8bxvv625y7vsx5268zrcn5q4z-openfoam-10.20221128/lib/OpenFOAM-10/platforms/linux64GccDPInt32Opt/lib,-rpath=/gnu/store/s0a9z2n8bxvv625y7vsx5268zrcn5q4z-openfoam-10.20221128/lib/OpenFOAM-10/platforms/linux64GccDPInt32Opt/lib/dummy,-rpath=/gnu/store/s0a9z2n8bxvv625y7vsx5268zrcn5q4z-openfoam-10.20221128/lib/OpenFOAM-10/platforms/linux64GccDPInt32Opt/lib/paraview-5.9.1 -fuse-ld=bfd -Xlinker --add-needed -Xlinker --no-as-needed /tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/platforms/linux64GccDPInt32Opt/test/fvMeshTools/Test-fvMeshTools/Test-fvMeshTools.o -L/tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/platforms/linux64GccDPInt32Opt/lib \ -ldynamicMesh -lmeshTools -lfiniteVolume -lgenericPatchFields -lOpenFOAM -ldl \ -lm -o /tmp/OpenFOAM/-10/platforms/linux64GccDPInt32Opt/bin/Test-fvMeshTools make[1]: Leaving directory '/tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/test/fvMeshTools/Test-fvMeshTools' Running blockMesh on /tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/test/fvMeshTools/cavity Running Test-fvMeshTools on /tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/test/fvMeshTools/cavity Running checkMesh on /tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/test/fvMeshTools/cavity Running foamToVTK on /tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/test/fvMeshTools/cavity Running decomposePar on /tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/test/fvMeshTools/cavity Running Test-fvMeshTools in parallel on /tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/test/fvMeshTools/cavity using 3 processes Running checkMesh in parallel on /tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/test/fvMeshTools/cavity using 3 processes Running foamToEnsight in parallel on /tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/test/fvMeshTools/cavity using 3 processes Running reconstructParMesh on /tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/test/fvMeshTools/cavity Running reconstructPar on /tmp/guix-build-openfoam-10.20221128.drv-0/OpenFOAM-10/test/fvMeshT
