<nckx>That's another one that should be safe to change, or at least make a bit more clear (sure, ‘tabulation’ is correct, but not how we actually talk). <nckx>Please do change both, if you want. I just wanted to avoid you thinking you had to change every error in that list to an active instruction. <nckx>Some are coy for a reason. <Cairn>Hehe, yeah. I was just considering where direct instructions work and where they're unnecessary. <Cairn>I see "formatting: alright" as an empty warning. What's that about, haha <vagrantc>i do find lint suggestions without a way to override of suggest them can despoil the signal to noise ratio sometimes *vagrantc also finds vagrantc's grammer a bit off <Cairn>Yeah sorry, I don't quite understand that sentence vagrantc <vagrantc>e.g. guix lint provides no means to override the suggestion, and if it is not appropriate, then the suggestion just becomes noise <nckx>vagrantc: Traditionally, the answer to that is to add more noise: linter comments! \o/ <nckx>I am, I hope it's obvious, not a fan. <vagrantc>e.g. for a partucular case, it might make sense to ignore the override, but then it is not documented, and the next person who runs guix lint on it will get the same noise and re-evaluate weather it is appropriate, and the next person, etc. <nckx>warning: linter comment ‘ignore-long-linter-comments’ is way too long. <vagrantc>oh, yeah, i guess you could add a comment why you think it doesn't apply ... at which point, it should just be programmatic and ignored <nckx>That's my own reasoning for ‘should this code be commented or not’, so I guess I'm inconsistent. <PotentialUser-89>I'm still struggling with this. If i am building a package definition for a rust app: A, that depends on another rust app: B. Niether A nor B are on crates.io. A references B with {git = ..., rev=...} syntax. I was able to build the package for B. How do I reference B in the package definition for A? When I do it the same way I have been <PotentialUser-89>referencing normal rust packages, it doesn't work. It's still searching for B at the git reference which obviously is not available <nckx>That = will it cause each future reader to stop and think. <vagrantc>hmmm... this sounds like a bug in guix lint; I know what to do about bugs! *vagrantc fires up the kitchen sink <nckx>I actually tried M-x kitchen-sink just in case I missed an easter egg. <Cairn>Learned about that one recently. <nckx>(PotentialUser-89: You're not being ignored, I don't think anyone currently here knows either…) <jesse->pashencija[m]: tethering through usb worked great, Guix System is running now. next step is to get my wireless card to work, but at least i can start tinkering <nckx>PotentialUser-89: I recommend the help-guix@ mailing list to reach more people at the expense of speed, but a slow answer is better than, er, fast silence I guess. <nckx>And welcome, judging by your default name :) <nckx>Cairn: The first random pattern was extremely underwhelming, but now it's obviously deleting mails from my inbox. <PotentialUser-89>nckx: Alright. I may do that. Though I've also never used a mailing list before. I might dig into the build-system code myself first. And you judged correctly. thanks for the welcome <nckx>Cairn: If you're talking about tests/lint.scm: that's the name of the test: the linter should not flag anything wrong with a ‘perfect’ package. <vagrantc>opted for a mail to guix-devel rather than a bug ... <nckx>After some reconsideration, I'd support such a feature. <mitchell>hello guix. I am tryng to get set up on an ubuntu distribution. I needed to place the store on it's own partition which meant creating /gnu and making an fstab entry. I then ran the install-guix.sh script (with a slight modification so it doesn't abort on the existance of /gnu). However now my builds which are not substitutes fail due to permission errors. After much googling it appears this can be caused by messing with the store by <mitchell>hand. I double checked that /gnu was owned by root:root and /gnu/store is owned by root:guixbuild. The systemd jobs responsible for remounting the store ro are happy and the daemon is being run with the proper arguments <Gooberpatrol66>so I have linux checked out and am trying to run "make menuconfig" on it in a guix shell and i'm getting "/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include/bits/local_lim.h:38:10: fatal error: linux/limits.h: No such file or directory" <Gooberpatrol66>I don't even know why it's looking inside /gnu/store for headers because as far as I can tell I only installed build tools in the environment <Gooberpatrol66>I tried installing linux-libre and linux-libre-headers; didn't work <mitchell> `find $(guix build linux-libre-headers) -iname "limits.h"` yields a result on my system <mitchell>On my system `guix shell -D linux-libre ncurses -- make x86_64_defconfig && make menuconfig` works <mitchell>actually i lied, the combined command like that doesn't work. Running each make command in the shell does work <mitchell>Any particular reason to use a manifest? shell -D <package> will place you in an environment with the given packages build environment. You need ncurses as well to run menuconfig which is not required normally at build time so it needs to be included as well <Gooberpatrol66>mitchell: i'm actually building android, so...there's not a package definition for that <Gooberpatrol66>i had that error and fixed it with make clean, but it's not fixing it now <Gooberpatrol66>I might have to build this outside of a guix shell, because it puts a bunch of "/gnu/store" in my environment variables <mitchell>If I were you I would write an android-linux package that captures the build requirements. Then you can use guix shell -D on that package. You want your environment variables pointing into the store because you want to ensure you are targeting the correct stuff. Which variables do you think are wrong? <mitchell>is android very different than upstream? I've never built it <mitchell>You might be able to just inherit the linux-libre package and swap out the sources if you're lucky <Gooberpatrol66>mitchell: I expect any environment variable that points menuconfig into /gnu/store for headers to be wrong, seeing as I didn't install any linux headers through guix (at first) <mitchell>You shouldn't be using any linux headers from guix. They should all be in the source tree <Gooberpatrol66>mitchell: it's possible that command you posted would work for menuconfig, assuming I didn't get a ncurses error <mitchell>That command i posted was wrong. You cant do it in one line like that (or at least i dont know how to). But you should be able to run menuconfig in shell spawned by `guix shell -D linux-libre ncurses` <mitchell>Did you run make *_defconfig? does android do that? <nckx>Gooberpatrol66: $C_INCLUDE_PATH ? <mitchell>Cairn: They're just variables that you can use to fine tune your package build artifacts <Cairn>If only I was able to see them as that simple. <mitchell>Cairn: Like if you could pass make a variable to control where documentation goes you might use a `doc` output so that guix users could decide if they want to install the documentation <Cairn>I know what flags I'd like to pass for different outputs. I'm struggling to figure out how to make separate outputs that use those separate flags. <mitchell>Now as far as I understand the compiler needs the kernel headers in order to build itself. You may need to recompile gcc to use the android headers. <Cairn>Sorry, I'm sorta just venting though. I'll keep trying to figure them out. <mitchell>like add one before 'build that takes in the outputs keyword. Then search to see if whatever output is present and do whatever with it if it is. If it exists it will resolve to a store path <nckx>WDYM by ‘separate flags for separate outputs’. <Cairn>Oh shoot, that was a question for me wasn't it nckx <mitchell>like (let ((doc (assoc-ref outputs "doc"))) (if doc (invoke "make" "doc" (string-append "DOC_OUTPUT=" doc)))) or something like that. <nckx>We don't really do the conditional. <Cairn>It's got three different possibilities. I can build for SDL for example. <nckx>mitchell: And in your made-up example, you'd just make DOC_OUTPUT a regular make-flag, and (apply invoke "make" "doc" make-flags). <nckx>Cairn: Right. So. This is why I asked my question. <nckx>If you're running (the equivalent of) ‘make clean’ during the package build process to create each ‘output’, that's not really what outputs are for. <mitchell>You might also make 3 separate packages for each different build type <nckx>They are to split one(ish :) build into different component parts. <nckx>Not to build completely different builds of the package. <nckx>As mitchell once said: a separate package is more appropriate here. <nckx>You can still get all the DRY you want with inheritance, mostly. <nckx>Don't Repeat Yourself. Programming advice that some confuse for religion. <mitchell>You can make a function that contains most of the package and call like like (map harmonist-interface '(sdl browser)) <Cairn>So it's better (in this case) to have "harmonist" and variants with "-sdl" and "-wasm" instead of outputs with ":sdl" and ":wasm"? <nckx>Cairn: Both would have a /bin/wasm, right? <ml_2>Hello. Is there a good way to source my personal packages from local git directories? "git-fetch" using "file://" doesn't seem to work, presumably because the build is isolated from the rest of the filesystem. I've been able to make it work by using a local-file source and adding a build phase that checks out the correct commit, but it's not a very clean solution. <Cairn>nckx: Not sure, sorry. The hypothetical's running away from me. <nckx>Well, if so, that's a clear sign that outputs aren't the right fit. <nckx>Also, there's a remarkably well-named ‘git-checkout’ procedure for local Git checkouts. <nckx>It obviously needs more publicity. <mitchell>nckx: And ssh-agent checkouts i learned today <ml_2>mitchell: I'm pretty sure I had 3 slashes, but I'll try again just in case, thanks. <mitchell>So if you have repositories with access control you can use `git-checkout` and ssh-agent to get at them <nckx>The former enables the latter. <mitchell>ml_2: they also need to be absolute paths <Cairn>nckx: Can you think of an example of a package that has multiple versions with different build flags? <nckx>There are plenty, but ermm… <mitchell>gcc too. I learned a lot from the gcc packages lol <nckx>Cairn: glib{,-with-documentation}, cups{,-minimal}, … <nckx>I tried to choose realistic packages, because different flags usually imply different other things, too. <Cairn>mitchell: Since you brought up linux libre... Why is it not a singlularly-named package that uses the "version" mechanism? Like why not "linux-libre@5.18"? <ml_2>fatal: '/home/ml/files/info/desk/emacs-ml-init' does not appear to be a git repository <ml_2>SWH: revision "a31e2d00815998742538470bd780cb2daa2c6361" originating from file:///home/ml/files/info/desk/emacs-ml-init could not be found <mitchell>Cairn: Because different .config's yield vastly different programs <ml_2>But I can confirm that creating an empty repo and running `git fetch file:///home/ml/files/info/desk/emacs-ml-init` does work. <ml_2>So that's why I think git-fetch doesn't work with file:// urls. <mitchell>ml_2: I remember now. I set up a cgit service and got my local repositories that way. Another way I learned to use guix during testing was to define a test package that did a source transformation like ((options->transformation '((with-source. "")))). Then I could guix build, and more importantly guix system with test code. <mitchell>guix makes kernel module development way less trecherous <ml_2>mitchell: I haven't really looked at transformations yet, but it might be cleaner than my current approach. Thanks! <the_tubular>Is there a way guix can help protecting from all the licensing mess happening ? <the_tubular>Tea, from gitea was packaged in like 14 different distro's package manager as 'MIt' While it uses a dependency with no license <mitchell>lol. Well I don't think anything can get merged into guix proper without a license <pkill9>yeah it can help because all packages are vetted for licenses and bundled libs <singpolyma>the_tubular: guix or Debian or anyone with sane policies can't have that happen <mitchell>If it's packaged in guix you can be reasonably sure its properly licensed <the_tubular>I think debian was in the list ...? I'm not sure anymore <mitchell>Perhaps in debian they were letting the package download stuff at build time <pkill9>can yo upass store paths to `guix environment`? <nckx>My (Sway) clipboard is doing that cool thing where it randomly ignores ^C again. It was better for a while. <nckx>It's what has slowly driven me mad. <nckx>sneek: later tell jts: I think I've trawled through every single ‘rtl8812au’ project on GitHub (I'd say beyond, but really, it always ends up on GitHub). They all have firmware files, even if the names change. Sorry. *apteryx revives x200 libreboot hardware project <nckx>sneek: later tell jts: I've requested removal from H-node. Such a pity, they even explicitly documented a Guix System configuration… <nckx>apteryx: Oh right, you were affected too IIRC. <mroh>I feel guilty adding rtl8821ce-linux-module. <apteryx>eh, don't be. it was reviewed and added in good faith, and when a problem was found, it was (will) be acted upon. Such is our pledge to the FSDG <nckx>mroh: I added rtl8812au-aircrack-ng-linux-module. :o) <apteryx>nckx: ah, the Guix config snippet on h-node was mine :-p <Cairn>raghavgururajan: Works for me <mroh>do we have any tools to check for large arrays in source code? Something like these "rtlxxx disaster" is hard to avoid w/o, no? <mroh>or better: large binary arrays that gets executed... <oriansj>mroh: it is an open problem in bootstrapping, it is freaking crazy how much generated crap is even in GNU packages <oriansj>we spent months of effort just figuring out how to bootstrap Guile without using generated files, only for the next release of Guile to effectively throw all of our work into the trash. ***califax_ is now known as califax
<oriansj>basically at this point, if humans aren't actively concerned about actually providing source code and ensuring it can be bootstrapped; then we have a serious cultural problem. <nckx>raghavgururajan: If this is about the same error you posted previously, make sure you're invoking the right /run/setuid-programs/su (‘type su’). <mroh>oriansj: yea, it becomes very serious the more Im thinking about it... <oriansj>lots of smart and capable people on #bootstrappable and we love teaching those who wish to learn more and better <KarlJoad>sneek: later tell nckx I am not using the "split" cuirass version. I know berlin uses the newer mechanism to scale better. Mine is using just the default build assignment system. The host node is the build node. The failure happens during the `guix pull` step, because something was not fully initialized. <KarlJoad>sneek: later tell nckx I can provide the configuration if you want to see it, but I will have to PM it to you. <vivien>Hi guix, ci.guix.gnu.org seems down, and I can’t install anything :( <vivien>I’m in the installation medium, so how do I deactivate it from here? <vivien>I tried with --no-substitutes, but the amount of things to compile is insane <anhj>vivien: it seems eerything guix.gnu.org is down, at least for me too, maybe try a mirror for substitutes? <vivien>I can’t change the guix daemon configuration though, so I’ll just recompile everything. <cbaines>guix.gnu.org and ci.guix.gnu.org both seem up to me <cbaines>are you still having problems accessing them vivien, anhj ? <vivien>Christoph[m], I know, but I can’t change the daemon configuration in the installer <vivien>If ci.guix.gnu.org does not respond, the installation just stops. <vivien>Well it does not stop, it just waits indefinitely <Christoph[m]>That sounds like a bug, doesn't it? What if I want to install from a local server in order to save bandwidth? <vivien>I have to say, I’m not using the installer as intended <vivien>I first generated the configuration file with the graphical installer, and then I switched to the command-line to actually install it <vivien>So maybe there’s something I missed <vivien>But I have never seen an option to configure the substitutes, either in the graphical installer, nor in the command-line installation process <Christoph[m]>And do you really have to say --no-substitutes if the substitutes are unavailable? I always thought that compilation starts automatically. <Christoph[m]>Ah, maybe compilation starts as soon as ci.guix.gnu.org confirms that there is no substitute, but it waits for that confirmation first. <vivien>Maybe there’s some timeout and I’m too impatient to wait for it <vivien>but I would say it’s at least a minute ***Dynom_ is now known as Guest2254
<rekado>a package using rust-openssl-sys fails to build because it encounters “extern crate openssl_src;” but doesn’t know that crate. <rekado>I’m guessing that the downstream package tries to build a bundled copy of the openssl sources <rekado>how can I make it use our openssl package instead? <florhizome[m]> i would look how the package bundles openssl and the try to substitute it there i guess <rekado>this is specific to rust, I think <rekado>the rust-openssl-sys package has openssl as an input and it is patched to use it. <efraim>is 'extern crate openssl_src' in rust-openssl-sys or on the other package? <rekado>and if I read this correctly it is behind a feature switch <efraim>did you include openssl and pkg-config as inputs? <efraim>I haven't looked at the patch for rust-openssl-sys in a while <rekado>it’s only downstream packages that don’t work <rekado>FWIW I have a similar problem with rust-lzma-sys and rust-xz2 <rekado>they build fine on their own, but users of these packages will complain about missing directories that contain the lzma or xz sources <efraim>its hard to test since we don't have the package graph for crates :/ <efraim>rust-bzip2-sys-0.1 is a fun way to take care of obstinate bundle crates <VesselWave>Hello everyone! I made a package definition for alacritty@0.10.1 and for it's dependencies. And merged it localy with guix channel How do I test, it can be built in terms of this channel? ***Dynom_ is now known as Guest8548
<sneek>nckx, KarlJoad says: I am not using the "split" cuirass version. I know berlin uses the newer mechanism to scale better. Mine is using just the default build assignment system. The host node is the build node. The failure happens during the `guix pull` step, because something was not fully initialized. <sneek>nckx, KarlJoad says: I can provide the configuration if you want to see it, but I will have to PM it to you. <nckx>KarlJoad: I'm away for the day, but what is the 'something'? Any clues? <rekado>something caused a rebuild of the rust bootstrap chain <rekado>building rust 1.39.0 up to 1.57.0 on berlin now, so that we can build librsvg 2.50.7 <efraim>are you sure? I built my manifest after the icecat bump and didn't have to rebuild rust <efraim>maybe the filesystem mountings aren't correct? <rekado>oh, could be that berlin doesn’t use itself for substitutes <rekado>hmm, no idea how to make it work <rekado>maybe authorize its own signing key <rekado>nckx apteryx efraim FYI: I just reconfigured berlin and (manually) authorized its own signing key, so we can use the substitute cache. <supdood[m]>Anyone in here messed around with guix foreign install on Devuan? ***wielaard is now known as mjw
<antipode>Maybe it requests the 'vendored' feature. <rekado>I’ll check if it contains “vendored” anywhere <antipode>If so, the Cargo.toml of the dependent could be patched to remove the 'vendored' feature from the list of requested features. <rekado>it doesn’t contain the string “vendor” at all <rekado>it has this: [target."cfg(all(unix, not(target_os = \"macos\")))".dependencies.openssl-sys] <rekado>and below that “optional = true” <antipode>Nevermind, "gcs" is a feature, not a dependency ... <rekado>antipode: your comment has already helped me. I see that for libz-sys the file requests a “static” build, which explains the other problems I had. <pkill9>I wanna make a guile script you can either call as a program, or import as a library <lilyp>pkill9 the usual way to do this is to define a main method and then do the exec guile dance <antipode>Maybe you can separate it in two parts: a Guile module to be installed and used as library containing most of the functionality, and a script to be installed in $PREFIX/bin that uses that library to do most things except CLI parsing. <pkill9>lilyp: what's the exec guile dance>? <pkill9>antipode: I kinda want it to be able to all be in a single script when it comes to running it directly as a program <pkill9>so that I can easily jsut copy it and modify it for debugging/extending etc <lilyp>#!/bin/sh\nexec guile "$0" -e main "$@"\n!#, where \n are actual new lines <lilyp>maybe you want a -- after main <antipode>pkill9: To make it self-contained, such that there is only a single file to copy to share it with other people or copy to other machines, to only have a single file to back-up, etc.? <lilyp>another way of writing the second line is guile -e main -s "$0" "$@", which keeps the shell arguments in the same order <antipode>I don't see how a single file helps with debugging and extending but ok. <pkill9>because I can quickly modfy adn run it iteratively <pkill9>and not worry about where the libraries are <antipode>Right, not needing to add "-L." or such. <antipode>It's possible to determine the location of the script at runtime (something with port-filename?) -- assuming you've set up things such that there is a relationship between the locations of the script and its modules on the filesystem, you could then add the right locations to %load-path automatically. <antipode>Might not be worth the complexity in your case though. <vldn>is it possible to guix pull from a local directory? <vldn>via a channel definition with a local path instead of an url? <antipode>"/home/foobar/etc" is a valid URL IIUC, if not try "file:///home/foobar/etc" <vldn>is there a reason between a guix pull to a profile path or a guix package -m to a profile path? i remember breaking something in the past.. <vldn>reason = difference :D sry <tricon>Cairn: Top o' the mornin' to ya. <Cairn>I'm having a hard time understanding the build systems, but I just have a small question I'd like to solve. The go build system has the "#:build-flags" option. Is that flag also used for tests? <Cairn>I'm guessing it is, but I can't find how that phase is defined. Does it just inherit everything in the build phase? ***stikonas_ is now known as stikonas
<KarlJoad>sneek: later tell nckx: Just checked because I had this issue a few months ago and pushed solving it to now. I have a syntax error "invalid field specifier" on the (list (machine (operating-system %system))) part of a deploy. <VesselWave>Hello everyone! I made a package definition for alacritty@0.10.1 and for it's dependencies. And merged it localy with guix channel. How do I test, it can be built in terms of this channel? <rekado>apteryx: that one says “succeeded” right now <podiki[m]>two: sourcing the profile sets up all the needed env variables so that you will use guix properly (e.g. latest guix you get from guix pull, anything you install to be in your PATH) <podiki[m]>you can look at the file to see it, for the one you pasted, ~/.guix-profile/etc/profile will just be a short script <two[m]>podiki[m]: thank you, i know what the profile does, i wanted to know why is there a semicolon and a backslash? <podiki[m]>as a way of showing the two separate lines to paste directly I guess? <podiki[m]>; as in end of command, \ as in continues to next line <two[m]>wouldn't a newline have the same effect? <two[m]> * does it behave differently from a newline have the same effect? <two[m]> * does it behave differently from a newline? <podiki[m]>anyway, the point is to source that profile, however you want to do it <podiki[m]>(i mean the backslash here doesn't matter, but usually you need it for multi line commands when pasting, if I remember correctly) <podiki[m]>so \<newline> is a continuation; here a bit redundent with the ; I guess <podiki[m]>err backslash new line (if that got escaped on your client) <podiki[m]>i.e. it escapes the newline so the command you are writing will continue to be parsed (here it didn't matter) <two[m]>> you need it for multi line commands when pasting <two[m]>you don't, newlines are kept in pasted text, but the commands are executed after you press enter <two[m]> * > you need it for multi line commands when pasting <two[m]>you don't, newlines are kept in pasted text, but the commands are executed after you press enter <raghavgururajan>sneek, later tell nckx: Oh you're right! Interesting, some package installed su in my home-profile. <podiki[m]>probably depends on your terminal, but sure, usually newlines are kept in my experience <two[m]>del key doesn't work in guix shell --container <two[m]>s/that/the/, s/a/bug/, s/known bug/reported/ <two[m]>s/is that a known bug?/is the bug reported or has a known fix?/ <two[m]>could that be inherited from the host? would that break reproducibility? <nckx>sneek: later tell lfam: We definitely do want to set CONFIG_INITRAMFS_PRESERVE_MTIME=y. <sneek>Welcome back nckx, you have 2 messages! <sneek>nckx, KarlJoad says: Just checked because I had this issue a few months ago and pushed solving it to now. I have a syntax error "invalid field specifier" on the (list (machine (operating-system %system))) part of a deploy. <sneek>nckx, raghavgururajan says: Oh you're right! Interesting, some package installed su in my home-profile. <two[m]>probably not but there might be a weird build script that dumps env into about window or debug data... <unmatched-paren>two[m]: Yeah, it probably won't break reproducibility in practise too much <podiki[m]>guix shell has options to preserve things from the host <linj>unmatched-paren: is there any interest in pure evaluation in guix community? <linj>just see your discussion of env vars and reproducibility <unmatched-paren>for the same inputs they will always in theory produce the same outputs <unmatched-paren>in practise, there are sometimes issues like timestamps and random numbers embedded in the build <linj>in nix, there are two stages: 1. evaluation of nix expression into foo.drv and 2. build foo.drv <linj>I mean the evaluation stage <linj>not sure what the guix part of it though <unmatched-paren>(1) "compile" a high-level object like a <package>, <local-file>, or <origin> to a gexp (2) evaluate the gexp into a derivation (3) build the derivation <linj>then my question that is the first two phases pure, i.e. not changed but something like env vars <unmatched-paren>i think they might not be containerized, but they aren't affected by the environment <acrow>Another good day to be working with guix! <Cairn>Hey, should I use the most recent version tag, or the most recent "release" version? The linter said that I can use the most recent version tag, but that's not the version listed in the "release" section of github... <efraim>I have a go package I want to run tests only when building with go and not gccgo, any suggestions on how to detect which "go" I'm using? <antipode>two[m]: AFAIK IRC does not have multi-line messages (IIUC it's different for Matrix) <efraim>doh, I thought I could make it work with shift+enter for a new line <unmatched-paren>I think there are a few fancy clients that pretend to support multiple lines, but actually just send several messages <antipode>linj: In principle, you could do #$(current-time) in a phase or such to make a different derivation each time "guix build the-package-or-a-dependent" is run. <Cairn>Got it, thanks unmatched-paren <antipode>Would easily be caught by package review <unmatched-paren>efraim: Also, GOROOT and GOTOOLDIR differ based on the compiler used <efraim>I'm hoping to put something in #:tests?, so not sure I can use GOROOT <efraim>right now I'm trying to write out (= (package-version (this-package-input "go")) (package-version go)) ***mark__ is now known as mjw
<unmatched-paren>Hmm, maybe you can use #$(this-package-input "gccgo"), and if it's false, run tests <unmatched-paren>so (replace 'check (lambda* (#:key tests? #:allow-other-keys) (when (and tests? (not #$(this-package-input "gccgo"))) ...))) <efraim>I'll probably go with that, but I'm going to keep on trying this first :) <efraim>so far #~(equal? "1.17.11" #$(package-version go)) works <unmatched-paren>silly me. Anyway, you should be able to do #:tests? (this-package-input "gccgo") <efraim>yeah, (this-package-input "go") keeps on evaluating to false <unmatched-paren>silly me. Anyway, you should be able to do #:tests? (not (this-package-input "gccgo")) <efraim>(this-package-input "gccgo") always evaluates to #f in #:tests? <vivien>Compiling qt is not a whole lot of fun <antipode>efraim: go-build-system has a #:go argument, right? <antipode>Maybe you can check if it contains "bin/go" or "bin/gccgo" or such. <Cairn>I've already gotten some opinion on this, but I just wanna check. Should I add myself to the copyright section if I'm just adding some packages? <efraim>antipode: yeah. gccgo is called as bin/gccgo <Cairn>unmatched-paren: Cool, thank you <vivien>If it contains rust, qt and libreoffice, you are allowed to shout "bin/go!" and win a prize. <antipode>librsvg now builds with antioxidant-build-system <efraim>might need false-if-exception for search-input-file <efraim>(replace 'check (lambda* (#:key tests inputs #:allow-other-keys #:rest args) (when (and tests? (not (false-if-exception (search-input-file inputs "/bin/gccgo")))) (apply (assoc-ref %standard-phases 'check) args))) <efraim>the args was the easiest way to invoke %standard-phases 'check <efraim>when replacing go with gccgo, the label is still 'go' <unmatched-paren>(replace 'check (lambda* (#:key go #:rest args) (when (string=? go "go") (apply (assoc-ref %standard-phases 'check) args)))) should work <efraim>#$(package-name go) is checking the absolute package go <unmatched-paren>but it will check the go used by the build system if you remove the ungexp <unmatched-paren>(replace 'check (lambda* (#:key go #:rest args) (when (string=? (package-name go) "go") (apply (assoc-ref %standard-phases 'check) #:go go args)))) <efraim>I think I'm going with (unless (false-if-exception (search-input-file inputs "/bin/gccgo")) (apply ... <VesselWave>Hey everyone! I cloned guix main repository and made changes to some packages. How do I test they can be built? <VesselWave>mbakke: I don't have that file how do I get it? Make? <mbakke>VesselWave: you need to run './bootstrap' and './configure --localstatedir=/var' beforehand ... also 'make -j $(nproc)' to speed things up a bit in the long run <mbakke>I recommend reading that manual section ;) <vivien>Before that, be sure to run "guix shell -D guix" <vivien>To have all build dependencies ready <VesselWave>BTW I made a package definition for alacritty 0.10.1, previous version had a bug: transparency could be turned on <VesselWave>Yes I updated it. It will be my first contribution to guix <VesselWave>No, but packaging tutorial by Andrew Tropin is great source <vivien>Some time ago, someone complained that the download page contains the phrase: "GNU Guix can be installed as an additional package manager on top of an installed Linux-based system." I think this is indeed not clear. Maybe "on top of any system running the Linux kernel" would make sure that the thing that matters is the kernel, not the system. <vivien>Au passage, en français on dit « fondé sur » et pas « basé sur » <vivien>(parce qu’on parle des fondations, pas de la base) <VesselWave>Thank you. Should I split every update of package to separate commit and separate patch? <unmatched-paren>The -${n} flag of git format-patch and git send-email sends the last n patches, so no need to run them for each patch <VesselWave>Andrew Tropin broke guix pull for several hours because of sign issues. I saw it from last commit at that time <davidl>to package anything for node t takes a grandiose effort to bootstrap the node bundle tools like rollup etc. <davidl>I have a recursive importer written in Bash. Still, everything is a recursive dependency and I need to find earlier versions to bootstrap significant packages. <yewscion>Do You have a link to Your recursive importer? I'd be interested to see the process. <davidl>yewscion: it's not refined work fyi. Just temporary to get some packages working together. Completely ignores the license field for example. <davidl>s/everything is a recursive dependency/everything is a circular dependency/g <davidl>(second time mixing up recursive and circular) <nikola_>Hare defer is not finalized yet right <jpoiret>unmatched-paren: I like working on branches that have origin/master as upstream <apteryx>for your info, if you use a Guix System mahcine and it starts throwing TLS certs errors on git clone operations, make sure use-pam? is #t for your openssh-configuration. It causes /etc/environment to be sourced for non-login SSH sessions, which contains GIT_SSL_CAINFO and SSL_CERT_DIR, among others <jackhill>vagrantc: re: scummvm games: what if I wanted to charge an unreasonable copying fee. That I'm allowed to do so for all our other packages except scummvm-games seems like a potentially interesting distinction? <vagrantc>jackhill: though getting a definition of reasonable from a court would be an adventure ***justache is now known as justDeez
<vagrantc>"it's reasonable that you would want to profit greatly from this transaction!" :) <pkill9>does anyone know of a decent laptop they can recommend for running guix?