Re: Using (recursive #t) in (origin git-reference)
John Kehayias writes: > This happens enough I feel like it should be explicitly mentioned as a > potential > "gotcha" in the manual, even if one can gleam it from understanding package > definitions and hashes, if it isn't already. Or maybe a little "tips" section > on > packaging (or in the cookbook) with something like this and related ones like > idiosyncrasies/conventions in certain language ecosystems. We all accumulate a > lot of institutional knowledge as we do and pass it along, but better to have > it > properly referenced. Sounds like an idea. I definitely think it should go in the manual, though, as it'll be far more visible there. (I, personally, have never read the cookbook in all that much detail...) -- (
Re: Using (recursive #t) in (origin git-reference)
On Tue, Jun 20, 2023 at 12:33 PM, Felix Lechner via \"Development of GNU Guix and the GNU System distribution.\" wrote: > Hi unmatched-paren! > > On Tue, Jun 20, 2023 at 11:52 AM ( wrote: >> >> (If you've already tried building it without the RECURSIVE?, then this >> issue will go unnoticed, as the derivation paths [...] >> are *exactly the same* > > Okay, that nipped me in the hiney. Now it works! > > Thanks for explaining! You are an invaluable as well as instant > resource for this list. > Yes, thanks for the quick response (! This happens enough I feel like it should be explicitly mentioned as a potential "gotcha" in the manual, even if one can gleam it from understanding package definitions and hashes, if it isn't already. Or maybe a little "tips" section on packaging (or in the cookbook) with something like this and related ones like idiosyncrasies/conventions in certain language ecosystems. We all accumulate a lot of institutional knowledge as we do and pass it along, but better to have it properly referenced. John
Re: Using (recursive #t) in (origin git-reference)
Hi unmatched-paren! On Tue, Jun 20, 2023 at 11:52 AM ( wrote: > > (If you've already tried building it without the RECURSIVE?, then this > issue will go unnoticed, as the derivation paths [...] > are *exactly the same* Okay, that nipped me in the hiney. Now it works! Thanks for explaining! You are an invaluable as well as instant resource for this list. Kind regards Felix
Re: Using (recursive #t) in (origin git-reference)
Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > Is there a trick to fetching Git submodules with (recursive? #t)? It > does not seem to work with the package definition below. > > The code uses Ekaitz's proposed Zig build system. [1] Thank you! Not sure whether or not you've already done this, but when you're doing ``(recursive? #t)'' the hash will be for the source code with submodules checked out, so you need to fetch them all in your ``git clone'' before doing ``guix hash -rx .''. (If you've already tried building it without the RECURSIVE?, then this issue will go unnoticed, as the derivation paths for these two objects: (origin (method git-fetch) (uri (git-reference (url "…") (commit (string-append "v" version …) (origin (method git-fetch) (uri (git-reference (url "…") (commit (string-append "v" version)) (recursive? #t))) …) are *exactly the same*, as the output path is the hash, followed by a dash, followed by whatever's given in FILE-NAME. Thus, they are treated as exactly the same object, making rebuilding pointless in Guix's eyes, because you've already got that "same" output in your store from the first build without RECURSIVE?. This is also, funnily enough, why it's not a great idea to first copy another origin's hash, then try to build, in the hopes of getting the actual hash from the "expected hash: …" message; if you haven't changed the FILE-NAME, or haven't included one, the output path will be exactly the same as the original package's, meaning that one will be used as the source if you happen to have it in your store! [IIUC, of course.]) That being said, you may know all this and have already taken it into account, in which case I'm not sure what's going on here :) -- (
Using (recursive #t) in (origin git-reference)
Hi, Is there a trick to fetching Git submodules with (recursive? #t)? It does not seem to work with the package definition below. The code uses Ekaitz's proposed Zig build system. [1] Thank you! Kind regards Felix [1] https://issues.guix.gnu.org/60889 * * * gnu: Add river. * gnu/packages/zig.scm (river): New variable. 1 file changed, 45 insertions(+), 2 deletions(-) gnu/packages/zig-xyz.scm | 47 +-- modified gnu/packages/zig-xyz.scm @@ -21,10 +22,52 @@ (define-module (gnu packages zig-xyz) #:use-module (guix git-download) #:use-module ((guix licenses) #:prefix license:) #:use-module (guix build-system gnu) + #:use-module (guix build-system zig) #:use-module (guix gexp) #:use-module (gnu packages) - #:use-module (gnu packages zig) - #:use-module (gnu packages python)) + #:use-module (gnu packages freedesktop) + #:use-module (gnu packages man) + #:use-module (gnu packages pkg-config) + #:use-module (gnu packages python) + #:use-module (gnu packages wm) + #:use-module (gnu packages xdisorg) + #:use-module (gnu packages xorg) + #:use-module (gnu packages zig)) + +(define-public river + (package +(name "river") +(version "0.2.4") +(source (origin + (method git-fetch) + (uri (git-reference +(url "https://github.com/riverwm/river;) +(commit (string-append "v" version)) +(recursive? #t))) + (file-name (git-file-name name version)) + (sha256 + (base32 +"1kh5yh2a47vr2q9paivmm3d57rcbb3f2p6d4f4r4k6f7jf62391n" +(build-system zig-build-system) +(arguments + (list + #:zig-build-flags #~(list "-Dxwayland") ;experimental xwayland support + #:zig-release-type "safe")) +(native-inputs (list +libevdev +libxkbcommon +pkg-config +pixman +scdoc +wayland +wayland-protocols +wlroots)) +(home-page "https://github.com/riverwm/river;) +(synopsis "Dynamic tiling Wayland compositor") +(description "River is a dynamic tiling Wayland compositor with flexible +runtime configuration. It can run nested in an X11/Wayland session or also +directly from a tty using KMS/DRM.") +(license license:gpl3))) (define-public zig-zls (package
